Ask Matt

你不必记住每一个技能，所以来问。

在说明某个技能的作用或建议跳过某一步之前，先阅读该技能的 SKILL.md：这里的摘要仅用于定位。

流程（flow）是穿过技能的一条路径。大多数路径沿一条主干流程行进，两条入口匝道汇入其中。其余的都是独立技能，或者是在底层运行的词汇层。

主干流程：想法 → 交付

大多数工作走的路线。你有一个想法，想把它建出来。

1. /grill-with-docs：通过盘问打磨想法。只要你在工作目录里就从这里开始：它是有状态的，会把学到的东西保存在 GLOSSARY.md 和 ADR 中。（没有工作目录？用 /grill-me，见"独立技能"。两者跑的是同一个 /grilling 原语；grill-with-docs 是会留下书面痕迹的那个，所以只要有仓库可以留痕迹，它就是更好的选择。）

2. 分支：所有问题都能在对话中解决吗？ 如果某个问题需要一个可运行的答案（状态、业务逻辑、必须亲眼看到的 UI），就绕道原型，由 /handoff 双向桥接（原型住在自己的目录里，这正是 /handoff 的用武之地，见"阶段边界"）：

   • /handoff 跳出去，然后针对那个文件开一个新会话，
   • /prototype 用一次性代码回答问题，
   • /handoff 把你学到的东西带回来，并在原始想法线程中引用它。

3. 分支：这是多会话构建吗？

   • 是 → /to-spec（把对话变成 spec），然后 /to-tickets 把它拆成示踪子弹式 ticket，每个都声明自己的阻塞边。接着用两种方式之一推进 ticket：
     • /implement 逐个 ticket 实现，每个之间用 /clear 清空上下文。在本地跟踪器上，每个 ticket 是 .scratch/<feature>/issues/ 下的一个文件，按阻塞优先的顺序人工推进；在真实跟踪器上，阻塞边变成原生阻塞链接，所以任何阻塞项已完成的 ticket 都可以被领取。每个 ticket 自包含，所以上一个的上下文可以丢弃。
     • /implement-spec 一次性实现整份 spec。它把 ticket 读成一张任务图，在可领取的前沿上并行运行实施者子代理，把一切落到一条集成分支上。当你更想编排整个构建、而不是亲自逐张驱动 ticket 时用它。
   • 否 → 就在同一个上下文窗口里 /implement。

   无论哪种方式，代码都靠驱动 /tdd（一次一个红-绿切片）来构建，并以 /code-review 收尾，对 diff 做双轴审查（标准 + 规格）。/implement 对每张 ticket 各跑一遍这两步；/implement-spec 的每个实施者各自驱动 /tdd，然后在集成分支上跑一次 /code-review。只想在没有完整 spec 的情况下测试优先地构建一个具体行为时，单独用 /tdd；任何时候想对照固定点审查分支或 PR，单独用 /code-review。

   当工作要以 PR 提交时，/pr 负责塑造 PR body：能说清变更的最小可视化、证明其可行的 before/after 证据、以及单向门/双向门的判断。它是模型调用的，所以 agent 每次写 PR 都会主动拿起来用。

4. /retro 闭合这个循环。一次构建之后（尤其是跑偏的那种），它会回顾整个会话，为 agent 的环境（而非代码）提出改动建议：导航指针、自动化检查、/code-review 执行的编码规范、引导文件、工具。机械性错误变成确定性检查；判断题变成编码规范。下一次构建就从更好的环境开始。

上下文卫生

把步骤 1, 3 保持在一个不间断的上下文窗口里（在 /to-tickets 之前不要压缩或清空），这样盘问、spec 和 ticket 都建立在同一个思考之上。之后每次 /implement 从 ticket 出发、重新开始。在它所回顾的那次会话里、清空之前运行 /retro；清空之后，就把它指向那次会话的日志。