询问 Matt

它做什么¶

ask-matt 是此仓库中各技能的路由器。你描述自己当前的处境（一个无法启动的想法、一堆涌入的 bug 报告、一个已经运行过久的会话），它会指出适合的技能或技能序列，以及该序列中人类决策所处的位置。

它只给出建议然后停下。它不会进行追问、撰写规格、打开文件，或触发它刚刚命名的技能；你得到的是接下来要输入的内容，然后由你输入。它也是此仓库中技能的一张手写地图，而不是扫描你已安装的内容，因此它不会把你路由到你自己的技能或其他作者的技能上。

何时使用它¶

你通过输入 /ask-matt 来调用它；代理不会自行使用它。

前提条件¶

路由器只命名技能；它不安装它们。它指向的一切都必须已安装，建议才可执行，而且它只知道此仓库中已推广的技能。

依赖跟踪器的路由（triage、to-spec、to-tickets、implement）假定 setup-matt-pocock-skills 已在仓库中配置好问题跟踪器。即使在那之前，路由器也会推荐它们。

流程，而非技能¶

该技能的核心词是 流程，一条穿过各技能的路径，而非单个技能。当你说出自己的处境时，路由器会把你放到某个流程的某一步。这与“这里是匹配你关键词的技能”是不同的答案。共有五种路由，技能本身完整描述了它们：

• 主流程，从想法到发布。追问、规格、工单、实现（一次一个工单，或使用 implement-spec 并行处理整个任务图）、评审，然后是 retro，它将构建所教的内容反馈到代理的环境中。它有两个分支。一个是原型绕行，用于某个问题需要可运行代码来定夺时。另一个是规格与工单拆分，只有当构建跨越多个会话时才值得其成本。
• 入口，用于产生工作然后并入主流程的处境：涌入的 bug 报告、某处损坏，或一个太模糊、太大而无法在一个会话中容纳的工作量。
• 代码库健康，维护而非功能工作。improve-codebase-architecture 扫描代码以寻找深化机会，它发现的每一个机会都作为想法重新进入主流程。
• 独立项，位于所有流程之外，供你单独使用：原型、问卷、研究运行。
• 底层词汇层，当问题在于措辞而非流程时，其他技能会引用的两个参考。

阶段边界¶

该技能另一个关键概念是 阶段边界。阶段是会话内的一块工作（追问、实现、QA），两个阶段之间的边界是“这个上下文我该怎么处理？”这个问题唯一所属的位置。阶段中途没有可决策的事项：继续，或将剩余部分拆分为子代理。

人们常常弄错其中两个，这就是为什么路由器给出的是顺序，而不仅仅是列表。/handoff 看起来像是在上下文窗口之间移动的一般方式，但事实并非如此。它只给你可移植性。/compact 是树中的最后一个选项，而不是第一个，因为它上面的四个选项中的每一个都更便宜或更精确。

常见问题¶

难道没有一份按正确顺序排列的技能列表吗？

人们一直在 README 中要求这样一份列表。这个技能就是那份列表。一张静态表格会写 wayfinder → to-spec → to-tickets → implement → code-review → retro，并对大多数情况都是错误的。重要部分是分支：是否存在代码库、构建是否跨越会话、能否通过交谈解决这个问题。代价是路由器由人工维护，因此它会落后于仓库。/grilling 早在路由器命名它之前就已发布。

它告诉我一半技能没有安装。

这是一个已知 bug，且尚未修复。路由器引导你使用的大多数技能都设置了 disable-model-invocation: true，这意味着执行框架会将它们排除在注入到代理上下文的技能列表之外。代理会把该列表视为完整列表，并报告它们缺失。在一个报告的会话中，它声称整个规格与工单流程不存在，并重新路由到裸的 /grilling 和 /tdd。插件的二十七个技能中有十六个带有该标志，因此这是常见情况，而不是边缘情况。它们已经安装。仍然输入斜杠命令，或者检查 .claude-plugin/plugin.json，它是关于存在什么的权威来源。

它描述了一个技能的行为，但该技能并不那样做。

这也是一个真实 bug，同样尚未修复。路由器根据它自己对每个技能的一行摘要来回答，而不是根据技能本身。一份详细报告追踪了单个会话中的三个实例，包括仅根据摘要“将线程转换为规格”就建议跳过 to-spec。路由器从未打开 to-spec/SKILL.md。在每种情况下，它都只在用户反驳后才核实，且从未主动核实。在那里跳过 to-spec 导致一次真实的接缝检查缺失，而产出的工单低估了工作量。当路由器陈述了关于另一个技能、而你将要据此行动的内容时，先要求它打开该 SKILL.md。对于地图完全未覆盖的问题也是如此，例如是否使用 计划模式：那个答案是 模型 的推断，而不是这里写下的内容。

为什么它是散文而不是编号检查清单？

这是一个合理的抱怨。一个开放 issue 认为，大多数路由是确定性的，而叙述使其难以快速浏览。没有任何东西阻止你要求压缩形式：“只给我序列”会得到序列。散文承载了条件部分：分支、预期需要人工决策的地方，以及步骤之间在哪里清除或压缩上下文。一个扁平的检查清单恰恰会丢掉这些。

它能否路由我自己的技能，或其他作者的技能？

不能。三个独立提案都要求一个路由器，它能读取你本地的 skills/ 目录，并根据已安装的内容进行推荐。ask-matt 不是那样。它是一套固定集合的地图，由人工维护，并且对你自己编写或从其他地方安装的技能一无所知。

它告诉我编辑一个 SKILL.md。

这个建议通常是正确的，但编辑很少能持久。有人问它如何让 implement 关闭工单，被告知在技能中添加一行，并立刻看到了问题。npx skills update 会覆盖该文件，并且插件安装是只读的。将持久行为放在你自己的 CLAUDE.md 或 AGENTS.md 中，或者在调用时说明。你在提示中做的更改会在更新后保留。人们通过这种方式将流程指向 Linear 而不是 GitHub，或者询问哪些未关闭工单可以并行运行。

它命名了一个我没有的技能，或漏掉了我有的技能。

在假设它已消失之前，先检查 changelog 中是否有重命名。writing-great-skills 变成了 writing-for-agents，没有别名；to-prd 变成了 to-spec；pathfinder 变成了 wayfinder。四个技能被直接退役并合并到吸收它们的技能中：ubiquitous-language、design-an-interface、qa 和 request-refactor-plan。如果它漏掉了一个你拥有的技能，那是路由器自身的滞后，如上所述。

它正常工作的标志¶

• 它以说明要输入什么结束，并停在那里，而不是自己开始工作。
• 它给出的路线提到了在哪里清除或压缩上下文，以及在哪里预期你进行审查，而不仅仅是技能名称列表。
• 当两个技能很接近时，它会说明用哪一个，以及为什么另一个对你不合适。
• 它对另一个技能行为做出的任何声明，都会以它读取该技能的 SKILL.md 的形式出现在 trace 中。
• 你从它返回的内容中认出自己的情况，而不是最近的通用场景。

它的位置¶

ask-matt 是一个独立路由器，位于整个集合之上。它从不是链中的一个步骤。它指向每条链，而其他文档页面链接回它，因此它们都不必重新绘制图。从这里，你最常到达 grill-with-docs，主流程的头部，或 triage，为到达的工作而非你启动的工作提供的入口。

它是它所描述技能的次要来源。当路由器与某个 SKILL.md 不一致时，SKILL.md 是正确的。