ask-matt

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

咨询 Matt

你不需要记住每个技能，直接问就行了。

流程是指技能之间的路线。大多数路线沿着一条主流程走，两条入口匝道汇入其中。其他所有内容要么是独立技能，要么是运行在底层的词汇层。

主流程：从想法到交付

大多数工作遵循这条路线。你有一个想法，想要把它构建出来。

1. /grill-with-docs — 通过访谈打磨想法。当你已有代码仓时从这里开始：它是有状态的，会将学到的内容保留在 CONTEXT.md 和 ADR 中。（没有代码仓？使用 /grill-me — 见独立技能。两者都运行相同的 /grilling 原语；grill-with-docs 是会留下书面记录的那个。）

2. 分支 — 你能在对话中解决所有问题吗？ 如果某个问题需要可运行的答案（状态、业务逻辑、必须亲眼看才能确定的 UI），通过原型来绕路，用 /handoff 在双向桥接（见跨会话）：

   • /handoff 传出，然后针对该文件开启一个新会话，
   • /prototype 用一次性代码来回答问题，
   • /handoff 传回你学到的东西，并在原始想法线程中引用它。

3. 分支 — 这是一个跨会话的构建吗？

   • 是 → /to-spec（将线程转为规范），然后 /to-tickets 将其拆分为 tracer-bullet 工单，每个工单声明其阻塞边界。在本地追踪器上，这是一个有序的 tickets.md 文件，你手动操作；在真正的追踪器上，边界变为原生的阻塞链接，任何阻塞项已完成的工单都可以被领取 — 按工单启动 /implement，在每个工单之间清理上下文。
   • 否 → 直接在当前上下文窗口中运行 /implement。

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

上下文卫生

将步骤 1-3 保持在一个不间断的上下文窗口中 — 在 /to-tickets 之前不要压缩或清理 — 这样访谈、规范和工单都建立在相同的思考基础上。然后每个 /implement 从工单开始，以全新上下文启动。

此处的限制是**智能区间**：模型在此窗口内（当前最先进模型约 120k token）仍能保持敏锐推理。如果会话在 /to-tickets 之前接近这个限制，不要硬撑 — 使用 /handoff 并在新线程中继续。

入口匝道

产生工作的起始场景，然后汇入主流程。

• Bug 和请求堆积如山 → /triage。它让问题通过分类角色流转，生成可供 agent 处理的工单，后续由 /implement 领取。

  分类仅适用于不是你创建的问题 — bug 报告、新功能请求、任何原始到达的内容。/to-tickets 生成的工单已经是 agent 可处理的，所以不要对它们进行分类。

• 有东西坏了 → /diagnosing-bugs。用于疑难杂症：一眼看不出的 bug、间歇性抖动、在两个已知良好状态之间悄然而入的回归。它在拥有一个紧凑反馈回路之前拒绝推测 — 即一个已经在此 bug 上变红的一条命令 — 然后用回归测试修复。如果真正的发现是没有好的缝合点来锁定 bug，其事后分析会移交给 /improve-codebase-architecture。

• 一项庞大而模糊的工作 — 一个从零开始的项目或一个大型功能构建，单个会话装不下 → /wayfinder。当从起点到终点的路径尚不可见时，它在问题追踪器上绘制一张共享地图的调查工单，并逐个解决 — 产出的是决策，而非交付物 — 直到迷雾被驱散、路径清晰可见。然后它在 /to-spec 处汇入主流程（或者，如果工作量原来很小，直接进入 /implement）。如果说 /grill-with-docs 打磨的是你一个会话内能把握的想法，那么 wayfinder 面向的是你无法在一个会话内把握的想法。

代码仓健康

不是功能开发 — 是维护。

• /improve-codebase-architecture — 有空闲时就运行，保持代码仓对 agent 友好。它会暴露深化机会；选择一个机会就_生成一个想法_，你可以将其带入主流程的 /grill-with-docs。它是找到候选方案的普查；/codebase-design（见下文）是你设计选中方案的台面。

底层词汇

两个由模型调用的参考技能，运行在其他技能的_下层_ — 各自是其词汇的单一事实来源。当词语而非流程是问题时，直接使用它们；或者让上面的技能自行拉取。

• /domain-modeling — 精炼项目的_领域_语言：挑战模糊术语、解决一个超载的词汇（一个 "account" 干了三件事）、将难以逆转的决策记录为 ADR。它是 /grill-with-docs 驱动的、保持 CONTEXT.md 成为干净词汇表的主动规程。
• /codebase-design — 深层模块词汇（module、interface、depth、seam、adapter、leverage、locality），用于设计模块的_形状_：在一个干净的缝合点后面、通过一个小接口承载大量行为。/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 — 在首次工程流程之前运行，用于配置问题追踪器、分类标签和其他技能所依赖的文档布局。自定义问题追踪器同样适用。