Menü
询问哪种技能或流程适合你的情况。本仓库中技能的路由器。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
一轮一轮地同时询问所有前沿问题，进行无情的盘问。
把你无法独自回答的决策转化为一份问卷，交给别人来填写。
使用并行子代理为一个模块生成多种截然不同的接口设计方案。当用户想要设计 API、探索接口选项、比较模块形态，或提到"设计两次"时使用。
交互式 QA 会话，用户以对话形式报告 bug 或问题，代理负责提交 GitHub Issue。在后台探索代码库以获取上下文和领域语言。当用户想要报告 bug、进行 QA、以对话形式提交 Issue，或提到"QA session"时使用。
通过用户访谈创建包含微小提交的详细重构计划，然后将其提交为 GitHub Issue。当用户想要规划重构、创建重构 RFC，或将重构拆分为安全的增量步骤时使用。
从当前对话中提取 DDD 风格的通用语言（Ubiquitous Language）词汇表，标记歧义并提出规范术语。保存到 UBIQUITOUS_LANGUAGE.md。当用户想要定义领域术语、构建词汇表、强化术语体系、创建通用语言，或提到"领域模型"或"DDD"时使用。
| name | ask-matt |
| description | 询问哪种技能或流程适合你的情况。本仓库中技能的路由器。 |
| disable-model-invocation | true |
你不必记住每个技能，所以直接问就好。
一个流程（flow）是通过多个技能的路径。大多数路径沿一条主干流程运行，外加两条入口匝道合并到主干上。其余的都是独立技能，或是运行在底层的词汇层。
大多数工作的通行路线。你有一个想法，想把它构建出来。
/grill-with-docs — 通过盘问打磨想法。从有代码库时开始：它是有状态的，将学到的东西保存在 CONTEXT.md 和 ADR 中。（没有代码库？使用 /grill-me——见独立技能部分。两者都基于同一个 /grilling 原语运行；grill-with-docs 是会留下书面痕迹的那个。）
分支——你能通过对话解决每个问题吗？ 如果某个问题需要可运行的答案（状态、业务逻辑、需要亲眼看看的 UI），绕道走原型路线，通过 /handoff 双向桥接（见跨会话）：
/handoff 跳出去，然后打开一个基于该文件的新会话，/prototype 用可丢弃的代码回答问题，/handoff 把你学到的东西带回来，并从原始想法线程中引用它。分支——这是多会话构建吗？
/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 跟踪器也可以。