Menú
询问哪种技能或流程适合你的情况。本仓库技能的导航器。
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
| name | ask-matt |
| description | 询问哪种技能或流程适合你的情况。本仓库技能的导航器。 |
| disable-model-invocation | true |
你不需要记住每个技能，直接问就行了。
流程是指技能之间的路线。大多数路线沿着一条主流程走，两条入口匝道汇入其中。其他所有内容要么是独立技能，要么是运行在底层的词汇层。
大多数工作遵循这条路线。你有一个想法，想要把它构建出来。
/grill-with-docs — 通过访谈打磨想法。当你已有代码仓时从这里开始：它是有状态的，会将学到的内容保留在 CONTEXT.md 和 ADR 中。（没有代码仓？使用 /grill-me — 见独立技能。两者都运行相同的 /grilling 原语；grill-with-docs 是会留下书面记录的那个。）
分支 — 你能在对话中解决所有问题吗？ 如果某个问题需要可运行的答案（状态、业务逻辑、必须亲眼看才能确定的 UI），通过原型来绕路，用 /handoff 在双向桥接（见跨会话）：
/handoff 传出，然后针对该文件开启一个新会话，/prototype 用一次性代码来回答问题，/handoff 传回你学到的东西，并在原始想法线程中引用它。分支 — 这是一个跨会话的构建吗？
/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 — 在首次工程流程之前运行，用于配置问题追踪器、分类标签和其他技能所依赖的文档布局。自定义问题追踪器同样适用。
沿两个轴线审查自某个固定点（commit、分支、tag 或合并基准）以来的变更 — 标准（代码是否遵循此仓库已记录的编码规范？）和规范（代码是否匹配原始 issue/PRD 要求的内容？）。以并行子 agent 运行两项审查，并将结果并排呈现。当用户想要审查分支、PR、进行中的变更，或要求"从 X 开始审查"时使用。
设计深层模块的共享词汇。当用户想要设计或改进模块接口、寻找深化机会、决定缝合点放在哪里、使代码更可测试或更适合 AI 导航，或当其他技能需要深层模块词汇时使用。
针对疑难 bug 和性能回归的诊断循环。当用户说"诊断"/"调试这个"，或报告有东西损坏/抛出异常/失败/变慢时使用。
构建和精炼项目的领域模型。当用户想要确定领域术语或通用语言、记录架构决策，或当其他技能需要维护领域模型时使用。
一场无情的面试，用于打磨方案或设计。
一场无情的访谈，用于打磨计划或设计，同时在此过程中创建文档（ADR 和词汇表）。