Ask Matt
你不可能记住每一个技能，所以问吧。
在说明某个技能的作用或建议跳过某个步骤之前，请先阅读该技能的 SKILL.md 文档：此处的摘要仅用于初步了解。
一个流程 (flow) 是通过这些技能的一条路径。大多数路径沿着一条主线流程 (main flow) 运行，并有两条入口 (on-ramps) 合并到它上面。其他所有技能都是独立的，或者是作为底层运行的词汇层。
主线流程：创意 → 交付
大多数工作所走的路线。你有一个想法并希望将其构建出来。
-
/grill-with-docs通过访谈来打磨想法。每当你在工作目录 (working directory) 中工作时，请从这里开始：它是有状态的，会将学到的内容保留在GLOSSARY.md和 ADR 中。（没有工作目录？请使用/grill-me，它在独立工具部分有介绍。两者都运行相同的/grilling底层技能；grill-with-docs会留下书面记录，这使得它成为更好的选择，只要存在仓库来保存这些记录。） -
分支：你能在对话中解决所有问题吗？ 如果一个问题需要可运行的答案（状态、业务逻辑、你必须看到的 UI），则通过原型绕行，由
/handoff在双向进行桥接（原型存在于自己的目录中，这正是/handoff的用途；参见阶段边界）：/handoff转出，然后针对该文件打开一个全新的会话，/prototype用一次性代码来回答问题，/handoff回传你学到的东西，并在原始创意线程中引用它。
-
分支：这是一个多会话构建吗？
- 是 →
/to-spec（将线程转化为规范），然后/to-tickets将其拆分为追踪弹头式 (tracer-bullet) 的任务 (tickets)，每个任务声明其阻塞边 (blocking edges)。然后通过以下两种方式之一处理任务：/implement处理每个任务，在每两个任务之间/clear上下文。在本地追踪器上，这是在.scratch/<feature>/issues/下每个任务一个文件，按阻塞者优先的方式手动处理；在真正的追踪器上，边 (edges) 成为原生的阻塞链接，因此任何其阻塞者已完成的任务都可以被选择。每个任务都是自包含的，所以最后一个任务的上下文是可以丢弃的。/implement-spec一次运行处理整个规范。它将任务读取为任务图 (task graph)，并行地在已准备好的前沿 (frontier) 上运行实现子代理，并将所有内容落在一个集成分支 (integration branch) 上。当你更倾向于编排构建而不是自己驱动每个任务时，请使用它。
- 否 → 直接在这里的同一个上下文窗口中运行
/implement。
无论哪种方式，代码都是通过驱动
/tdd（一次一个红-绿切片）来构建的，并以/code-review结束，这是对 diff 进行的双轴（标准 + 规范）审查。/implement为每个任务运行这两者；/implement-spec的实现者各自驱动/tdd，然后它在集成分支上运行一次/code-review。当你只想在没有完整规范的情况下，以测试优先的方式构建一个具体行为时，可单独使用/tdd；每当你想要根据一个固定点审查某个分支或 PR 时，可单独使用/code-review。当工作以拉取请求 (pull request) 的形式提交时，
/pr会塑造其主体：能展示变更的最小可视化内容、证明其有效性的前后对比证据，以及单向或双向决策门的说明。这是模型调用的，因此代理在编写 PR 时会使用它。 - 是 →
-
/retro闭环。在一个构建之后，尤其是当构建出现问题时，它会回顾会话并提出对代理的环境 (environment) 的更改建议，而不是对代码的更改：导航提示、自动化检查、/code-review强制执行的编码标准、引导文件、工具。机械性错误变成了确定性检查；判断类决策变成了编码标准。下一次构建将从更好的环境开始。
上下文卫生
将步骤 1-3 保持在一个不间断的上下文窗口中（在 /to-tickets 之前不要压缩或清除），以便访谈、规范和任务都建立在相同的思考基础上。然后每个 /implement 从任务开始，以全新状态进行。在清除之前，在你当前回顾的会话中运行 /retro；清除后，将其指向该会话的日志。
此操作的极限在于**智能区域 (smart zone)**：模型仍能清晰推理的窗口（在最新模型上约为 150k 个 token）。如果会话在 /to-tickets 之前接近此限制，不要在质量下降时继续推进；在最近的阶段边界执行 /compact 并继续（参见阶段边界）。
入口
一种起始情况，会生成工作，然后合并到主线流程上。
-
错误和请求堆积 →
/triage。它将工单 (issues) 通过分类角色进行处理，并生成代理可用的工单，这些工单随后由/implement处理。分类仅适用于不是你创建的工单：错误报告、传入的功能请求、任何原始提交的内容。由
/to-tickets生成的任务已经是代理可用的，所以不要对它们进行分类。 -
某些东西坏了 →
/diagnosing-bugs。用于处理棘手的错误：一眼看不透的问题、间歇性故障、在两个已知良好状态之间悄悄出现的回归。它拒绝在没有紧密反馈循环（tight feedback loop）（一个已经在这个错误上显示失败的命令）的情况下进行理论推测，然后通过回归测试进行修复。修复完成后，在同一会话中运行/retro以询问是什么可以阻止这个错误；如果真正的发现是没有好的接缝 (seam) 来锁定它，那么这将是/improve-codebase-architecture的任务。 -
一个庞大、模糊的任务：绿地向新项目或一个巨大的功能构建，对一个会话来说太大 →
/wayfinder，这是这里认知要求最高的流程。当从此处到目的地的路径还不可见时，它会在工单追踪器 (issue tracker) 上绘制一份共享地图，其中包含决策任务 (decision tickets)，并逐一解决这些任务，产生决策而非可交付物，直到迷雾消散，路径清晰。/grill-with-docs打磨的是一个会话内可以容纳的想法；而 wayfinder 是为你无法容纳的想法准备的，它更慢、更密集，所以请只在确需时使用它，永远不要用于范围明确的特性。当地图清晰后，它进行交接，而不是构建：在
/to-spec处合并到主线流程，该流程将地图中关联的决策压缩成一个可构建的计划，然后照常执行/to-tickets和/implement。直接将地图循环进入/implement会跳过这个压缩步骤，并丢弃关联的细节，所以只有在任务实际上很小的情况下才直接使用/implement。
代码库健康
不是特性工作，仅仅是维护。
/improve-codebase-architecture在你有一点空闲时间时运行，以保持代码库适合代理操作。它会找出加深机会 (deepening opportunities)；选择一个会产生一个想法，你可以将其带入主线流程的/grill-with-docs。它是寻找候选对象的调查；/codebase-design（见下方）是设计所选候选对象的平台。
底层词汇
两个由模型调用的参考文档，运行在其他技能之下，每个都作为其词汇的单一事实来源。当问题出在词语而非流程时，直接使用它们；或者让上方的技能来调用它们。
/domain-modeling：打磨项目的领域语言：挑战一个模糊的术语，解决一个过载的词（例如“账户(account)”在承担三项工作），将难以撤销的决策记录为 ADR。这是/grill-with-docs驱动的主动规程，以保持GLOSSARY.md为一个干净的词汇表。/codebase-design是深度模块词汇（模块、接口、深度、接缝、适配器、杠杆、局部性），用于设计模块的形状：在干净接缝处，通过一个小接口暴露大量行为。/tdd和/improve-codebase-architecture都使用此词汇。
阶段边界
一个阶段 (phase) 是会话内的一块工作：访谈、实现、质量保证。在两个阶段的边界 (boundary) 处，你有五个选择，而在这整个地图中，做出选择是最模糊的决策：
- 继续 (Continue)：原地不动。没有成本，没有损失。
/clear：清空窗口，当这里的内容对下一步不重要时。/handoff编写一个可移植的 markdown 文件。用途狭窄：仅用于新的支撑结构 (new harness)、新的目录、同事，或者在阶段中途分叉一个子任务。它带来的好处是可移植性。- 子代理 (Subagent)：将一个范围严格的任务发送到其自己的窗口并取回报告。
/compact压缩此上下文并以压缩后的内容启动一个全新的会话。这是默认选项，位于决策树的底部而不是首选。
请阅读 PHASE-BOUNDARIES.md 了解排序的决策树：五个问题，每个分支背后的推理，以及为什么主要来源的成本使得 继续 (Continue) 成为首先需要排除的选项。在边界处做出决策；在阶段中途，继续执行或将剩余部分拆分为子代理。
独立工具
完全脱离主线流程。
/grill-me：与/grill-with-docs相同的无情访谈，但是无状态的：它不会在本地保存任何内容，也不会构建GLOSSARY.md。当你不在工作目录中工作时（打磨计划、设计、文章，任何没有仓库的东西），请使用它。如果你在工作目录中，请改用/grill-with-docs：它运行相同的访谈并留下书面记录，因此严格来说是更好的选择。/grilling是访谈底层技能本身：多轮 (rounds)、前沿 (frontier)、事实是代理的工作，决策是你的。/grill-me和/grill-with-docs是两种命名的入口方式，而/triage、/wayfinder和/improve-codebase-architecture都在内部运行它。只有当你想要没有包装器的、纯粹的这个访谈时，才直接使用它。/prototype是一个小的、可丢弃的程序，用于回答一个设计问题：这个状态模型感觉对吗，或者这个 UI 应该是什么样子。可丢弃是代码编写方式的一个约束，而不是销毁它的承诺：答案会融入真正的代码，而原型本身会作为主要来源 (primary source)，保存在从主分支 (main) 分叉出来的prototype/<name>分支上，并从实现工单中引用。它是主线流程步骤 2 中的绕行路线，但任何时候当设计问题难以在纸面上解决时，都可以使用它。/research：将阅读的繁琐工作委托给后台代理：它会针对主要来源调查一个问题，然后在仓库中留下一个有引用的 Markdown 文件。在它阅读时你可以继续工作。它产生的文件是可以带入主线流程/grill-with-docs的内容，因为研究为思考提供输入，而不是替代它。/to-questionnaire在你受阻的原因不在你的头脑或代码库中，而是在别人的头脑中时使用，它会为他们编写一份问卷来填写。这与/grill-me相反：它不是向你询问主题，而是向你询问发送 (send) 对象（给谁的，你需要哪些信息），并将问题对准知识缺口。返回的内容是/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：在运行你的第一个工程流程之前运行，以配置其他技能所期望的工单追踪器、分类标签和文档布局。自定义工单追踪器同样适用。