tracer-wat

Wat

你不可能记住每项技能，所以不妨询问。

从适合当前情况的最轻量步骤开始。小而明确的请求可以直接进入 /tracer-implement；只有在访谈或规格说明能够消除不确定性或留下有用的持久上下文时，才使用它们。规模庞大、方向模糊的工作从 Wayfinder 开始。入口工作流由用户主动调用，而非自动触发。

主流程：从想法到交付

1. /tracer-interview-me — 从这里开始。彻底的访谈采用设计树的方式：每轮一次性提出当前能够回答的全部问题，为问题编号，并为每个问题给出推荐答案。事实由子 Agent 查证；决策由你做出。在代码库中，它会参考文档——现有的 CONTEXT.md/ADR 会在第 1 轮之前精简问题树，并将已确定的术语和决策写回文档；没有代码库时，则以无状态方式运行。如果树上的问题需要通过可运行的东西来回答（这种状态模型是否合适、这个 UI 应该是什么样），就转到 /tracer-prototype ——编写用于回答问题的一次性代码；保留答案，删除代码。当问题树已无待答问题，且没有任何事项被默默假定时，访谈即告完成——随后交接给 /tracer-to-spec。

2. /tracer-to-spec：将已确定的决策综合成简洁的验收标准、安全限制和有针对性的验证要求。保留明确决策，但不要把实现建议变成要求。如果小型请求已经足够明确，就跳过规格说明。

3. 分支——这是一个需要多个会话来构建的项目吗？

   • 是 → /tracer-to-tickets：将规格说明拆分成 tracer-bullet 垂直切片，并在每个切片中声明其阻塞边。然后针对每个工单启动一次 /tracer-implement，每次之间清空上下文。
   • 否 → 就在此处运行 /tracer-implement。

4. 选择要保留多少控制权：

   • /tracer-implement：批准简短的方案和有针对性的检查，在同一个上下文中完成实现，然后审查一次。在一轮内修复已确认的问题；仅当代码发生变化时，才重新检查修正结果。报告证据和顾虑，并保留当前分支。
   • /tracer-autopilot：采用同样适度的交付方式，不设置常规审批检查点，完成后由你明确选择如何结束分支。自定义基础设施或更强的保证仍需由你决策。审查和修复限制在恢复运行后仍然有效；未解决的重大工作将标记为 Blocked。

步骤 1–3 必须在同一个不中断的上下文窗口中完成——工单发布前，不要压缩或清空上下文，这样访谈、规格说明和工单才能建立在同一套思路之上。随后，每次实现或 autopilot 运行都从工单开始，并使用全新的上下文。

入门路径：规模庞大、方向模糊的工作

只有当工作规模大到无法在一个 Agent 会话中完成，且路线仍不明确时，才使用 /tracer-wayfinder——例如从零开始的项目或大型功能，当前还无法掌握撰写规格说明所需的所有决策。它会绘制一张共享的决策工单地图，每个会话处理一个决策，并推动迷雾前沿向一个明确命名的目标推进。

如果决策树能在一个会话内理清，/tracer-interview-me 就能处理这个想法；而 Wayfinder 则能将更大的决策树持续保留到多个会话中。它速度更慢，操作负担也更重，因此不要仅仅因为最终构建需要多个会话，就用它处理范围明确的功能。

地图明朗后，它会产出决策，而非交付物。将地图交给 /tracer-to-spec，它会加载所有关联的决策结果，并将其整合为可用于构建的规格说明；随后继续执行 /tracer-to-tickets 和 /tracer-implement。不要从跨多个会话的地图直接跳到实现。只有在绘制路线后确认这项工作确实能在一个会话内完成、且无需地图时，才直接进入 /tracer-implement。

并行处理工单

没有相互依赖边的前沿工单（所有阻塞项均已完成）可以同时处理——每个工单使用一个 /tracer-implement 会话：

• 每个会话都先运行 /tracer-worktrees——使用独立的检出目录、分支和 .tracer/implement/ 工作区。由于每项任务都会提交更改，并行会话不会因工作区有未提交更改而发生冲突。
• 每个会话完成工作后运行 /tracer-finish-branch——用最新证据验证测试，然后合并、创建 PR、保留或丢弃，并安全清理工作树。

独立使用

• /tracer-code-review——针对固定基准点，从两个维度（规范 + 规格）审查任意差异，为问题标注严重程度，并分别给出各维度的结论。需要独立审查时使用；Autopilot 使用自己的有界审查器。工作流调用方负责安排任何修复预算。
• /tracer-convince-me——根据已完成工作的原始目标进行证明。它会将每项预期转化为可观察的主张，在最强且切实可行的边界收集最新证据，并报告哪些已证实、已证伪或仍未验证。当你明确需要比交付中的针对性检查更深入的证明时使用。它不是 Autopilot 的自动步骤。证明报告会指出失败，但不会授权修复。
• /tracer-tdd——红 → 绿的参考指南：什么是好的测试、接缝、反模式以及循环规则。/tracer-implement 会在内部使用它；如果不需要完整规格，可单独使用它，以测试优先的方式构建一种行为。
• /tracer-worktrees / /tracer-finish-branch——任何隔离分支工作的前后置步骤，即使不属于主流程也适用。
• /tracer-prototype——用于回答一个设计问题的小型、用后即弃程序。它是第 1 步中的支线，但任何设计问题难以通过书面方式敲定时，都可以使用它。
• /tracer-research——使用一手来源，将一个事实问题委托给后台 Agent，并将附有引用的答案记录在一份 Markdown 笔记中。Wayfinder 会将它用于 AFK 研究工单；它也可以为常规访谈提供资料。

底层词汇

两个由模型调用的参考工具，运行在其他技能的底层——各自是其词汇的唯一事实来源。它们定义语言，不运行流程；当问题出在措辞上时，可直接使用它们，也可以让上面的技能调用它们。

• /tracer-domain-modeling——领域语言：质疑含糊的术语，厘清一词多义的用法，将难以逆转的决策记录为 ADR。它负责 CONTEXT.md 和 ADR 格式，/tracer-interview-me 的文档感知模式会按这些格式编写文档。
• /tracer-codebase-design——用于设计模块形态的深层模块词汇（模块、接口、深度、接缝、适配器、杠杆、局部性）。/tracer-to-spec 的接缝步骤、/tracer-tdd 和 /tracer-implement 的 Interfaces 区块都会使用这些词汇。

跨会话衔接

• /tracer-handoff——将当前对话压缩成文档，供新会话接续。在线程填满、尚未运行 /tracer-to-tickets 时使用；也可用于分支到 /tracer-prototype 会话，再将答案带回。
• /compact（内置）——留在同一对话中，将较早的轮次总结归纳。用于各阶段之间有意安排的间歇；不要在阶段中途压缩。/tracer-handoff 会分叉；/compact 会继续。

前置条件（可选）

/tracer-setup——每个代码库运行一次，用于配置问题跟踪器（docs/agents/issue-tracker.md：GitHub、GitLab、本地或自选方案）以及领域文档布局；/tracer-wayfinder、/tracer-to-spec、/tracer-to-tickets 和 /tracer-code-review 会读取这些配置。可跳过：所有内容都会回退到 .tracer/ 下的本地 Markdown 文件。

特意未包含的内容

没有分诊入口，也没有单独的头脑风暴原语——单会话探索由 /tracer-interview-me 负责，而 /tracer-wayfinder 只负责多会话的模糊问题。重量级的多审查器组合包（例如 /code-quorum）应在里程碑节点组合使用，而非针对每项任务。