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（把线程转化为一份规格说明），然后 /to-tickets 把它拆分成曳光弹式工单，每张都声明它的阻塞边。在本地跟踪器上，这表现为 .scratch/<feature>/issues/ 下每张工单一个文件，按阻塞优先手工处理；在真实跟踪器上，这些边会变成原生阻塞链接，因此任何阻塞项已完成的工单都可以被认领——为每张工单启动 /implement，并在每张工单之间清空上下文。
   • 否 → 就在这里、在同一个上下文窗口中直接 /implement。

   无论哪种方式，/implement 都会通过在内部驱动 /tdd 来构建每个 issue——一次一个红-绿切片——然后在提交前运行 /code-review 收尾，这是对 diff 的双轴评审（标准 + 规格）。当你只想不带完整规格、以测试先行的方式构建一个具体行为时，单独使用 /tdd；当你想针对某个固定基点评审一个分支或 PR 时，单独使用 /code-review。

上下文卫生

把第 1–3 步保持在一个不间断的上下文窗口中——在 /to-tickets 之前不要压缩或清空——这样拷问、规格和工单都建立在同一套思考之上。之后每次 /implement 都从工单出发、重新开始。

对此的限制是**smart zone**：即模型仍能敏锐推理的那个窗口（在最先进的模型上约为 120k tokens）。如果某个会话在 /to-tickets 之前就逼近了它，不要在能力退化的状态下硬撑——/handoff 后在一个全新线程中继续。

入口匝道

一种会产生工作的起始处境，随后汇入主流程。

• bug 和请求堆积如山 → /triage。它让 issue 在分诊角色间流转，产出可供 agent 直接处理的 issue，供 /implement 之后接手。

  分诊只适用于不是你自己创建的 issue——bug 报告、进来的功能请求，任何以原始形态到达的东西。/to-tickets 产出的工单已经是 agent-ready 的，所以不要对它们做分诊。

• 有东西坏了 → /diagnosing-bugs。用于那些棘手的：第一眼看不出、时有时无的偶发问题、在两个已知良好状态之间悄悄溜进来的回归。它拒绝在拥有一个紧凑反馈循环之前进行理论推测——即一条已经对这个bug变红的命令——然后用回归测试来修复。当真正的发现是"没有一个好的接缝能把这个 bug 锁死"时，它的复盘会移交给 /improve-codebase-architecture。

• 一项庞大而朦胧的工作——一个全新项目或一次庞大的功能构建，大到一个会话装不下 → /wayfinder，这里认知负担最重的流程。当从此处通往目的地的道路尚不可见时，它会在 issue 跟踪器上绘制一张由决策工单组成的共享地图，逐个解决它们——产出的是决策，而非交付物——直到迷雾被推开、道路清晰。/grill-with-docs 打磨的是你能在一个会话里把握住的想法，而 wayfinder 则针对你把握不住的那种想法——它更慢、更密，所以要专门留给恰恰是这种情形，绝不用于界定良好的功能。

  当地图明朗时，它是移交，而不是构建：在 /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 跟踪器同样可行。