ask-matt

Ask Matt

你不需要记住每个 skill，所以直接问。

Flow 是穿过 skills 的一条路径。大多数路径沿着一条 main flow 前进，两个 on-ramps 会并入它。其他内容要么是 standalone，要么是在下层运行的 vocabulary layer。

The main flow: idea -> ship

这是大多数工作的路线：你有一个想法，并希望把它构建出来。

1. /grill-with-docs - 通过访谈打磨想法。在 working directory 中工作时从这里开始：它是 stateful 的，会把学到的内容保存在 CONTEXT.md 和 ADRs 中。（没有 working directory？用 /grill-me，见 Standalone。两者都运行同一个 /grilling primitive；grill-with-docs 是会留下文档痕迹的版本，只要有 repo 可记录，它就是两者中更好的那个。）

2. 分支 - 能否在对话中解决所有问题？ 如果某个问题需要可运行的答案（state、business logic，或必须亲眼看到的 UI），就通过 prototype 绕行，并用 /handoff 在两个方向桥接（prototype 住在自己的目录里，这正是 /handoff 的用途，见 Phase boundaries）：

   • /handoff 导出，然后基于该文件打开 fresh session；
   • /prototype 用 throwaway code 回答问题；
   • /handoff 把学到的内容带回来，并在原始 idea thread 中引用它。

3. 分支 - 这是 multi-session build 吗？

   • 是 -> /to-spec（把 thread 变成 spec），再用 /to-tickets 拆成 tracer-bullet tickets，每个 ticket 声明 blocking edges。Local tracker 在 .scratch/<feature>/issues/ 下每 ticket 一个文件，手动按 blockers-first 处理；真实 tracker 用 native blocking links，因此 blockers 已完成的 ticket 都可领取。每 ticket 启动一次 /implement，并在 tickets 之间用 /clear 清空 context。每个 ticket 都是自包含的，因此最后一个 ticket 的 context 可以丢弃。
   • 否 -> 在当前 context window 里直接运行 /implement。

   无论哪种方式，/implement 都会在内部驱动 /tdd 构建每个 issue：一次一个 red-green slice；然后用 /code-review 收尾，对 diff 做 Standards + Spec 双轴 review，再提交。只想在没有完整 spec 的情况下 test-first 构建一个具体 behavior 时，单独用 /tdd；想按固定点 review branch 或 PR 时，单独用 /code-review。

Context hygiene

步骤 1 到 /to-tickets 要留在 同一个未中断的 context window 中；不要 compact 或 clear，这样 grilling、spec 和 tickets 才能建立在同一组思考之上。之后每个 /implement 都从 fresh session 开始，只基于对应 ticket 工作。

限制来自 smart zone：在该窗口（最新模型大约 150k tokens）内，模型还能保持敏锐推理。如果 session 在 /to-tickets 前接近这个区间，不要硬撑降级状态；在最近的 phase boundary 用 /compact，然后继续（见 Phase boundaries）。

On-ramps

起点会生成工作，然后并入 main flow。

• Bugs 和 requests 堆积 -> /triage。它通过 triage roles 推进 issues，并产出 agent-ready issues，之后由 /implement 领取。