ask-rolexlisted

# Ask Rolex 你不必记住每个 skill，问就行。 一个 **flow** 是一条贯穿多个 skill 的路径。大部分路径沿着一条 **main flow** 走，两条 **on-ramp** 汇入其中。其余的都是 standalone，或者是一个在底层运行的词汇层。 ## main flow：想法 → 交付 大多数工作走的路线。你有一个想法，想把它做出来。 1. **`/grill-with-docs`** — 通过 interview 打磨想法。只要你在**工作目录**里工作，就从这里开始：它是有状态的，会把学到的东西保留在 `CONTEXT.md` 和 ADR 中。（没有工作目录？用 `/grill-me` — 见 Standalone。两者运行同一个 `/grilling` 原语；`grill-with-docs` 是会留下书面痕迹的那个，所以只要有仓库可以留下痕迹，它就是两者中更好的那个。） 2. **分支 — 你能在对话中解决每个问题吗？** 如果一个问题需要可运行的答案（状态、业务逻辑、一个你必须亲眼看到的 UI），就绕行一个 prototype，用 **`/handoff`** 双向桥接（prototype 住在自己的目录里，这正是 `/handoff` 的用途——见 Phase boundaries）： - **`/handoff`** 转出，然后针对那个文件开一个新的 session， - **`/prototype`** 用 throwaway 代码回答那个问题， - **`/handoff`** 把你学到的东西转回来，并从原始想法线程引用它。 3. **分支 — 这是多 session 构建吗？** - **是** → **`/to-spec`**（把线程变成一份 spec），然后 **`/to-tickets`** 把它拆成 tracer-bullet tickets，每个都声明自己的 **blocking edges**。在本地 tracker 上，就是 `.scratch/<feature>/issues/` 下每个 ticket 一个文件，按 blocker 优先手工推进；在真实的 tracker 上，这些 edges 变成原生的阻塞链接，所以任何 blocker 都已完成的 ticket 都可以被拿走——对每个 ticket 启动 **`/implement`**，**每两个之间 `/clear` context**。每个 ticket 都是自包含的，所以上一个 ticket 的 context 是可以随手丢弃的。 - **否** → **`/implement`** 就在这里、在同一个 context window 里构建。 无论走哪条路，**`/implement`** 构建每个 issue 时都在内部驱动 **`/tdd`**——一次一个 red → green 切片——然后在 commit 之前用 **`/code-review`** 收尾，对 diff 做一次双轴 review（Standards + Spec）。当你只想以 test-first 的方式构建一个具体行为、不需要完整 spec 时，单独使用 **`/tdd`**；当你想针对某个 fixed point review 一个 branch 或 PR 时，单独使用 **`/code-review`**。 ### context hygiene 把步骤 1–3 保持在**一个不间断的