Ask Matt

你记不住每个 skill，所以来问。

流程（flow） 是穿越各 skill 的路径。多数路径沿一条 主流程（main flow） 行进，两条 入口匝道（on-ramps） 汇入其中。其余均为独立 skill。

主流程：idea → ship

大多数工作走这条路。你有一个想法，想把它做出来。

1. /grill-with-docs — 通过质询 sharpen 想法。有代码库时从这里开始：它有状态，把所学保留在 CONTEXT.md 和 ADR 中。（没有代码库？用 /grill-me — 见 Standalone。）
2. 分支 — 能否在对话中敲定每个问题？ 若问题需要可运行答案（state、业务逻辑、必须亲眼看的 UI），绕道 prototype，由 /handoff 双向桥接（见 Crossing sessions）：
   - /handoff 出去，然后针对该文件开新 session，
   - /prototype 用可丢弃代码回答问题，
   - /handoff 把所学带回，并在原始想法线程中引用。
3. 分支 — 这是多 session 构建吗？
   - 是 → /to-prd（把线程转为 PRD）→ /to-issues（把 PRD 拆成可独立领取的 issue）。因为 issue 相互独立，每个之间清空 context：每个 issue 开新 session，把 PRD 和单个 issue 传给 /implement 启动。
   - 否 → 就在当前 context window 中直接 /implement。

Context 卫生

步骤 1–3 保持在 一个不间断的 context window 中 — 在 /to-issues 之前不要 compact 或清空 — 这样 grilling、PRD 和 issue 都建立在同一套思考上。然后每个 /implement 重新开跑，从 issue 出发。

限制在于 smart zone：前沿模型约 ~120k token 的窗口，模型仍能敏锐推理。若 session 在 /to-issues 之前就接近它，不要在退化状态下硬撑 — /handoff 并在新线程继续。

入口匝道

产生工作然后汇入主流程的起始情境。

• Bug 和请求堆积 → /triage。把 issue 移过分诊角色，产出 agent-ready issue，之后由 /implement 领取。

分诊仅针对 非你创建的 issue — bug 报告、incoming feature request、任何原始到达的内容。/to-issues 产出的 issue 已是 agent-ready，不要对它们分诊。

代码库健康

非功能工作 — 维护。

• /improve-codebase-architecture — 有空就跑，保持代码库便于 agent 操作。它 surface deepening 机会；选一个会 生成一个想法，可在主流程的 /grill-with-docs 入口使用。

Crossing sessions

• /handoff — 线程满了或需要分支（如进入 /prototype session）时，把对话 compact 成 markdown 文件。不在原地继续 — 开新 session 并引用该文件 跨 context window 携带 context。双向桥接。想要 新 session 但需 保留当前对话 时用。
• /compact（内置）— 留在 同一对话，让较早轮次被摘要。在 阶段间有意 break 时用，不介意丢失逐字历史。不要阶段中途 compact — agent 可能迷路。/handoff 分叉；/compact 延续。

Standalone

完全脱离主流程。

• /grill-me — 与 /grill-with-docs 同样 relentless 的质询，但用于 没有代码库 时。无状态：不本地保存、不建 CONTEXT.md。用于 sharpen 任何不在 repo 里的计划或设计。
• /teach — 多 session 学习概念，以当前目录为有状态工作区。
• /writing-great-skills — 写好、编好 skill 的参考。

Precondition

/setup-matt-pocock-skills — 在首次 engineering 流程前运行，配置 issue tracker、分诊 label 和文档 layout，其他 skill 依赖这些。自定义 issue tracker 也可以。