ask-matt

name	ask-matt
description	询问哪种技能或流程适合你的情况。本仓库中技能的路由器。
disable-model-invocation	true

Ask Matt

你不必记住每个技能，所以直接问就好。

一个流程（flow）是通过多个技能的路径。大多数路径沿一条主干流程运行，外加两条入口匝道合并到主干上。其余的都是独立技能，或是运行在底层的词汇层。

主干流程：想法 → 交付

大多数工作的通行路线。你有一个想法，想把它构建出来。

1. /grill-with-docs — 通过盘问打磨想法。从有代码库时开始：它是有状态的，将学到的东西保存在 CONTEXT.md 和 ADR 中。（没有代码库？使用 /grill-me——见独立技能部分。两者都基于同一个 /grilling 原语运行；grill-with-docs 是会留下书面痕迹的那个。）

2. 分支——你能通过对话解决每个问题吗？ 如果某个问题需要可运行的答案（状态、业务逻辑、需要亲眼看看的 UI），绕道走原型路线，通过 /handoff 双向桥接（见跨会话）：

   • /handoff 跳出去，然后打开一个基于该文件的新会话，
   • /prototype 用可丢弃的代码回答问题，
   • /handoff 把你学到的东西带回来，并从原始想法线程中引用它。

3. 分支——这是多会话构建吗？

   • 是 → /to-spec（把对话转化为 spec），然后 /to-tickets 拆分为 tracer-bullet ticket，每个 ticket 声明其阻塞边。在本地跟踪器上，每个 ticket 对应 .scratch/<feature>/issues/ 下的一个文件，按阻塞项优先手动推进；在真实跟踪器上，阻塞边变成原生依赖链接，因此任何阻塞项已完成的 ticket 都可以被领取——每个 ticket 启动 /implement，每个之间清空上下文。
   • 否 → 就在同一个上下文窗口中 /implement。

   无论哪种方式，/implement 都在内部驱动 /tdd 构建每个 ticket——一次一个红-绿切片——然后在提交前通过运行 /code-review 收尾，对 diff 进行双轴审查（规范 + 规格）。当你只想在没有完整 spec 的情况下用测试优先的方式构建具体行为时，单独使用 /tdd；当你需要审查某个分支或 PR 时，随时单独使用 /code-review。

上下文卫生

将步骤 1-3 保持在一个不间断的上下文窗口中——不要压缩或清空，直到 /to-tickets 之后——这样盘问、spec 和 ticket 都建立在同一个思考基础上。然后每个 /implement 重新开始，基于 ticket 工作。

这里的限制是 智能区：模型仍能清晰推理的窗口（最先进模型约 120k token）。如果在 /to-tickets 之前会话就接近了这个极限，不要用降级状态硬撑——用 /handoff 在新线程中继续。

入口匝道

一个起始场景，产生工作后合并到主干流程上。

• Bug 和请求堆积中 → /triage。它通过分类角色推动 Issue 流转，产生 Agent 就绪的 Issue，后续由 /implement 接手。

  分类仅适用于非你创建的 Issue——bug 报告、外来的功能请求，任何原始内容。/to-tickets 产生的 ticket 已经是 Agent 就绪的，所以不要对它们进行分类。

• 有东西坏了 → /diagnosing-bugs。针对疑难杂症：一眼看不出的 bug、间歇性闪退、在两个已知正常状态之间溜进来的回归。它拒绝在没有紧反馈循环之前做理论化——一个已经能复现这个 bug 的命令——然后带着回归测试修复。当真正的发现是没有好的接缝来锁定 bug 时，它的事后分析会交给 /improve-codebase-architecture。

• 一个巨大、模糊的工作——绿野项目或大型功能构建，一个大到一次会话装不下 → /wayfinder，这是认知负荷最大的流程。当从这里到目的地的路线还不清晰时，它在 Issue 跟踪器上绘制一张共享地图，上面是决策 ticket，然后逐个解决——产出决策，而非可交付物——直到迷雾退散，路线清晰。/grill-with-docs 打磨的是你能在一个会话中 hold 住的想法，wayfinder 是为你 hold 不住的想法准备的——而且它更慢、更密集，所以只在这种情况下使用，绝不要用于范围明确的功能。

  当地图清晰时，它交接，而非构建：合并到主干流程，进入 /to-spec，它将地图中关联的决策压缩为可构建的计划，然后 /to-tickets 和 /implement 照常进行。将地图直接循环到 /implement 会跳过这个压缩过程，丢失关联的细节——仅在工作确实很小时直接进入 /implement。

代码库健康

不是功能开发——是维护。

• /improve-codebase-architecture — 任何时候你有空闲就运行它，保持代码库对 Agent 运行友好。它会揭示深化机会；选择一个就会产生一个想法，你可以带着它进入主干流程的 /grill-with-docs。它是找到候选的勘查；/codebase-design（见下文）是你设计选中方案的工作台。

底层词汇

两个模型调用的参考技能，运行在其他技能之下——每个都是其术语的唯一真实来源。当词语（而非流程）是问题时直接使用它们；或者让上面的技能来拉入它们。

• /domain-modeling — 打磨项目的领域语言：挑战模糊的术语、解决过载的词（"account" 身兼三职）、将难以撤销的决策记录为 ADR。这是 /grill-with-docs 用来保持 CONTEXT.md 成为干净词汇表的主动学科。
• /codebase-design — 深度模块词汇表（模块、接口、深度、接缝、适配器、杠杆、局部性），用于设计模块的形状：干净接缝后的小接口承载大量行为。/tdd 和 /improve-codebase-architecture 都使用这套语言。

跨会话

• /handoff — 当线程已满或需要分支（例如进入 /prototype 会话）时，它将对话压缩为一份 markdown 文件。你不会在原地继续——你打开一个新会话并引用那个文件来携带上下文。它是上下文窗口之间的桥梁，双向可用。当你想清空会话但又需要保留当前对话时使用。
• /compact（内置）— 保持在同一对话中，让之前的轮次被总结。在阶段之间有意的停顿时使用，如果你不介意失去逐字记录的话。不要在阶段中间压缩——Agent 可能会迷路。/handoff 是分叉；/compact 是继续。

独立技能

完全脱离主干流程。

• /grill-me — 与 /grill-with-docs 一样无休止的盘问，但适用于你没有代码库的情况。无状态：不保存任何东西到本地，不构建 CONTEXT.md。当你需要打磨任何不在仓库中的计划或设计时使用。
• /prototype — 一个小型、可丢弃的程序，回答一个设计问题：这个状态模型感觉对吗，或这个 UI 应该长什么样。从一开始就是可丢弃的——保留答案，删除代码。它是主干流程步骤 2 中的绕道，但任何时候设计问题难以在纸上决定时都可以使用。
• /research — 将阅读调查委派给后台 agent：它针对一手来源调查一个问题，然后在仓库中留下一个带引用的 Markdown 文件。让它阅读的同时你继续工作。它产生的文件是你可以带入主干流程 /grill-with-docs 的东西——研究为思考提供素材，而非替代思考。
• /teach — 通过多个会话学习一个概念，使用当前目录作为有状态工作空间。
• /writing-great-skills — 关于如何编写和编辑好技能的参考。

前置条件

/setup-matt-pocock-skills — 在第一个工程流程之前运行，配置 Issue 跟踪器、分类标签和文档布局，其他技能会用到这些。自定义 Issue 跟踪器也可以。