问 Matt
你记不住每一项技能，所以来问。
流程是一条穿过各项技能的路径。大多数路径沿着一条主流程行进，两条上匝道并入其中。其余的一切要么独立使用，要么是运行在底层的一层词汇。
主流程：从想法到交付
大多数工作走的那条路线。你有一个想法，想把它做出来。
-
/grill-with-docs通过访谈把想法打磨得更锋利。只要你在一个工作目录里工作，就从这里开始：它是有状态的，会把学到的东西留在GLOSSARY.md和 ADR 里。（没有工作目录？那就改用/grill-me，见「独立使用」一节。两者跑的是同一个/grilling原语；grill-with-docs是留下书面记录的那一个，所以只要有一个仓库可以留下这份记录，它就是两者中更好的。） -
分支：你能在对话里把每一个问题都敲定吗？ 如果某个问题需要一个能跑起来的答案（状态、业务逻辑、一个你必须亲眼看到的界面），就绕道去做原型，两个方向都由
/handoff搭桥（原型放在它自己的目录里，而这正是/handoff的用途；见「阶段边界」）：- 用
/handoff出去，然后针对那个文件开一个全新会话， - 用
/prototype以用完即弃的代码回答那个问题， - 再用
/handoff把学到的东西带回来，并从原来的想法讨论串里引用它。
- 用
-
分支：这是一次跨多个会话的构建吗？
- 是 →
/to-spec（把讨论串变成一份规格说明），然后/to-tickets把它拆成曳光弹式工单，每张都写明自己的阻塞边。接着用两种方式之一推进这些工单：- 每张工单跑一次
/implement，每做完一张就/clear清空上下文。在本地跟踪器上，那就是.scratch/<feature>/issues/下每张工单一个文件，手工按阻塞优先的顺序推进；在真实跟踪器上，这些边会变成原生的阻塞链接，于是任何阻塞项都已完成的工单都可以直接抓来做。每张工单都自包含，所以上一张的上下文用完就可以丢。 /implement-spec一次跑完整份规格说明。它把工单读成一张任务图，让实现者子代理并行跑遍已就绪的前沿，并把所有东西落到同一条集成分支上。当你更想编排整个构建、而不是自己逐个驱动工单时，就用它。
- 每张工单跑一次
- 否 → 就在这里、在同一个上下文窗口里跑
/implement。
无论走哪条路，代码都是靠驱动
/tdd（一次一个红-绿切片）建起来的，并以/code-review收尾——一次对 diff 的双轴评审（规范 + 规格说明）。/implement会按工单分别跑这两样；/implement-spec的实现者们各自驱动/tdd，然后它会在集成分支上跑一次/code-review。当你只想测试先行地做出一项具体的行为、而不需要完整规格说明时，单独用/tdd；当你想针对某个固定点评审一条分支或一个 PR 时，随时单独用/code-review。当工作以 PR 的形式提交时，
/pr会塑造正文：展示改动的最小可视化，证明它有效的改动前后证据，以及一个单向门还是双向门的判断。它是模型调用式的，所以代理每次写 PR 时都会取用它。 - 是 →
-
/retro收尾闭环。一次构建之后，尤其是走歪了的那次，它会回看这次会话，并建议修改代理的环境，而不是代码：导航指针、自动化检查、/code-review所执行的编码规范、引导文件、工具链。机械性错误变成确定性检查；需要判断的地方变成编码规范。下一次构建于是从一个更好的环境开始。
上下文卫生
把第 1–3 步保持在一个不中断的上下文窗口里（在 /to-tickets 之前不要压缩或清空），这样盘问、规格说明和工单都建立在同一套思考之上。每个 /implement 随后都从工单出发、重新开始。/retro 要在它回看的那次会话里跑，趁你还没清空；清空之后，就让它指向那次会话的日志。
这里的上限是**智能区**：模型仍能做出敏锐推理的那个窗口（在最先进的模型上约 150k tokens）。如果一次会话在 /to-tickets 之前就接近它，不要在退化状态下硬撑；在最接近的一个阶段边界处 /compact，然后继续（见「阶段边界」）。
上匝道
一种会生成工作的起始处境，随后并入主流程。
-
缺陷和需求越堆越多 →
/triage。它让议题流经各个分诊角色，并产出可供代理处理的议题，之后由/implement接走。分诊只针对不是你创建的议题：缺陷报告、外部进来的功能需求、任何未经加工就送来的东西。
/to-tickets产出的工单已经是可供代理处理的了，所以不要对它们做分诊。 -
有东西坏了 →
/diagnosing-bugs。为那些难啃的：第一眼看不出来的缺陷、时有时无的偶发失败、在两个已知良好状态之间悄悄混进来的回归。在你拥有一个紧密反馈回路（一条已经能对这个缺陷变红的命令）之前，它拒绝做理论推演，然后用一个回归测试来修复。修复到位之后，在同一次会话里跑/retro，问一问本来什么能防住这个缺陷；如果真正的发现是根本没有好的接缝可以把它固定住，那就是/improve-codebase-architecture的活。 -
一件庞大而迷雾重重的事：一个全新项目或一次巨型功能构建，大到一次会话装不下 →
/wayfinder，这是这几条流程里对认知要求最高的一条。当从这里到目的地的路还看不见时，它在议题跟踪器上画出一张由决策工单构成的共享地图，一次解决一张，产出的是决定，不是交付物，直到迷雾被推回去、路清楚为止。/grill-with-docs打磨的是你一次会话里就能把握得住的想法，wayfinder 针对的是你把握不住的那一个；它更慢、更密，所以只留给这种情况，绝不要用在范围明确的功能上。当地图清晰之后，它只交接，不构建：在
/to-spec处并入主流程，由后者把地图上相互关联的决定收敛成一份可构建的计划，然后照常/to-tickets和/implement。把地图直接接到/implement会跳过这次收敛，把关联的细节丢掉，所以只有当这件事最终被证明确实很小时，才直接去/implement。
代码库健康
不是功能开发，只是日常维护。
/improve-codebase-architecture在你手头有空、想让代码库保持适合代理在其中操作时随时跑。它找出加深机会；挑中一个就会生成一个想法，你可以把它带进主流程的/grill-with-docs。它是找出候选者的勘察；/codebase-design（见下）则是你设计所选那一个的工作台。
底层的词汇
两份由模型调用的参考资料，运行在其它技能之下，各自是其词汇的单一事实来源。当问题出在词而不是流程上时，直接取用它们；或者让上面的技能把它们拉进来。
/domain-modeling：打磨项目的领域语言：质疑一个含糊的术语，拆解一个超载的词（「account」同时干三份活），把一个难以逆转的决定记录成 ADR。它是/grill-with-docs驱动的那门主动纪律，用来让GLOSSARY.md保持是一份干净的词汇表。/codebase-design是深模块的词汇（模块、接口、深度、接缝、适配器、杠杆、局部性），用来设计一个模块的形状：在一个干净的接缝处，把大量行为放到一个小接口后面。/tdd和/improve-codebase-architecture都说这门语言。
阶段边界
阶段是会话内的一块工作：盘问、实现、验收。在两个阶段之间的边界上，你有五个选项，在它们之间做选择是整张地图里最模糊的决定：
- 继续：留在原地。不花代价，也不丢东西。
/clear：当这里没有任何东西对下一步重要时，清空窗口。/handoff写出一份可携带的 Markdown 文件。范围窄：只用于新的运行环境、新的目录、同事，或者在阶段中途把侧任务分叉出去。它换来的是可携带性。- 子代理：把一个范围收得很紧的任务送到它自己的窗口，再拿一份报告回来。
/compact压缩这份上下文，并用它给一个新会话打底。它是默认选项，位于决策树的底部，而不是第一个伸手去拿的。
读 PHASE-BOUNDARIES.md 看那棵有序的决策树：五个问题、每个分支背后的理由，以及为什么一手来源的代价，使得继续成为要最先排除的那一个。决定要在边界上做；阶段中途，要么继续，要么把其余部分拆成子代理。
独立使用
完全不在主流程上。
/grill-me：和/grill-with-docs一样不留情面的访谈，但无状态：它不在本地保存任何东西，也不建GLOSSARY.md。当你不在工作目录里工作时（打磨一个计划、一个设计、一篇文字，任何底下没有仓库的东西），用它。如果你在工作目录里，就改用/grill-with-docs：它跑同一套访谈，还会留下书面记录，所以它严格来说更好。/grilling就是访谈原语本身：轮次、前沿，事实是代理的活，决定是你的。/grill-me和/grill-with-docs是两个有名字的入口，而/triage、/wayfinder和/improve-codebase-architecture内部都会跑它。只有当你想要这场访谈、不想要外面任何包装时，才直接取用它。/prototype是一个小小的、用完即弃的程序，用来回答一个设计问题：这个状态模型感觉对吗，或者这个界面该长什么样。用完即弃是对代码怎么写的一条约束，而不是要毁掉它的承诺：答案会融进真实代码，原型本身则作为一手来源保留在从 main 拉出的prototype/<name>分支上，并从实现议题指向它。它是主流程第 2 步里的那段绕道，但当某个设计问题很难在纸上敲定时，随时都可以取用。/research：把阅读的跑腿活交给一个后台代理：它对着一手来源调查一个问题，然后在仓库里留下一份带引用的 Markdown 文件。它阅读的时候你继续干活。它产出的文件，是要带进主流程、交给/grill-with-docs的，因为调研是给思考喂料，而不是替代思考。/to-questionnaire在卡住你的东西不在你脑子里、也不在代码库里，而在别人脑子里时出场，它给对方写一份问卷去填。它是/grill-me的反面：不是就主题访谈你，而是就这次投递访谈你（要发给谁、你需要收回什么），并把问题对准那道缺口。收回来的是给/grill-with-docs或/to-spec的素材。/wizard针对只有人类才能做的步骤：开通基础设施、配置凭据或 CI 密钥、在一个陌生的第三方仪表盘里点来点去、跑一次性的迁移或切换。它生成一个交互式 bash 脚本，逐个打开 URL、逐个采集所需的值，并写进.env和 GitHub secrets，于是这套流程不再是你每次都要向代理重新解释的东西。它是模型调用式的，所以代理一撞上只有你能通过的那堵墙就会想到它。如果代理自己就能做，那它就应该自己做；这个技能是给人类确实还在回路里的场合。/wait-what是一条没落地的消息的矫正手段。在对话中途、在任何其它技能内部使用，代理会补上你当时缺失的上下文，用平实的话、用GLOSSARY.md里的词汇，把它刚说过的话重新讲一遍。它是事后补救；/grill-with-docs是事前的解药，因为早早商定的共同语言才是让行话压根不出现的东西。/teach：在多次会话里学一个概念，把当前目录当作一个有状态的工作区。/writing-for-agents是「怎么写代理要读的文档」的参考资料：技能、AGENTS.md、被指向的文档。
前提条件
/setup-matt-pocock-skills：在你第一次跑工程流程之前运行，用来配置其它技能所假定的议题跟踪器、分诊标签和文档布局。自定义的议题跟踪器也能用。
