/ask-matt 技能

它的作用

ask-matt 是仓库内技能的路由器。你描述自己所处的情境——一个无法开始的想法、一堆进来的 bug 报告、 会话 运行了很长的——它会点名合适的技能或技能序列，以及该序列中人类决策的位置。

它推荐然后就停。它不审问、不写 spec，打开文件或触发它刚点名的技能；你得到的回复是下一步该输入什么，然后你输入它。它也是这个仓库技能的手写地图，而不是对你已安装内容的扫描，所以它不会把你路由到你自己的技能或另一位作者的技能上。

何时使用

你通过输入 /ask-matt ——智能体不会自动调用它。

前置条件

路由器点名技能；它不安装它们。它指向的一切都必须已安装，推荐才可执行，而且它只认识这个仓库里正式推广的技能。

依赖追踪器的路线——triage、 to-spec, to-tickets, implement ——假设 setup-matt-pocock-skills 已经在仓库中配置了 issue 追踪器。在那发生之前，路由器会乐此不疲地推荐它们。

是流程，不是技能

技能给你用来思考的词是 flow：一条路径 through 技能们，而不是单个。说出你的情境把你放在某个流程的某一步，这与「这是匹配你关键词的技能」是不同的答案。存在四种路线，技能自身完整携带它们：

• 主流程，从想法到交付。审问、规格、任务、实现、审查，内部有两个分支：当问题需要可运行代码来敲定时走原型绕行，以及规格与任务的拆分——后者只在构建跨越多个会话时才值回成本。
• 入口，用于会产生工作、随后汇入主流程的情境：新来的 bug 报告、某个损坏的东西，或者过于模糊庞大、无法在一次会话中承载的任务。
• 独立技能，脱离所有流程，按需单独调用——原型、问卷、你正身处其中的合并冲突。
• 位于，这两个是其他技能在「问题出在词汇而非流程」时拉取的参考。

阶段边界

它递给你的另一个想法是 阶段边界。一个阶段是会话内的一块工作—— 追问审视，实现、QA——而两者之间的边界，才是「我该怎么处理这个上下文？」这个问题唯一该出现的地方。阶段中途没有需要决策的事：继续，或把剩余部分拆成 subagents.

其中两个经常被弄错，这就是为什么路由器携带顺序而不是清单。 /handoff 读起来像窗口之间的通用桥梁，其实不是：可移植性才是它买来的全部。 /compact 是树的底部而不是首选，因为它上面的四个问题每一个都更便宜或更精确。

常见问题

不是直接有一个按正确顺序排列的技能列表吗？

人们一直在 README 里要求一个。这个技能就是那个列表——它就是为此存在的。静态表格只能说出 wayfinder → to-spec → to-tickets → implement → code-review 并且对大多数情况都是错的，因为有趣的部分在分支里——有没有代码库、构建是否跨会话、这个问题能否靠讨论解决。诚实的代价是：路由器靠手工维护，落后于仓库。 /grilling and /resolving-merge-conflicts 两者都在路由器为它们命名之前很久就已经发布了。

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

一个已知但未修复的 bug。路由器带你经过的大多数技能都会设置 disable-model-invocation: true，这意味着运行框架会把它们从注入智能体上下文的技能列表中剔除。智能体把该列表视为完整清单，于是报告它们缺失。有一次报告的会话中，它宣称整个规格与任务流程不存在，并改道到赤裸的 /grilling and /tdd。插件二十二个技能中有十三个带有该标志，所以这是常见情况而非边缘情况。它们已经安装了。直接输入斜杠命令即可，或者查看 .claude-plugin/plugin.json，它是「现有什么」的权威来源。

它描述了某个技能的行为，而那个技能并不那样做。

同样真实，同样未修复。路由器是根据自己对每个技能的一行摘要来回答，而不是根据技能本身。一份详细报告在一次会话中追踪到了三个实例，包括一个跳过 to-spec 凭着「把线索变成规格说明」的表面理解—— to-spec/SKILL.md 从未被打开。在每种情况下，它只在用户顶回去之后才验证，从不主动。跳过 to-spec 那里付出了真实的接缝检查代价，产出的任务低估了工作量。当路由器对另一个技能断言某种承重信息时，让它打开那个 SKILL.md 首先。同样的道理也适用于地图完全不覆盖的问题，比如是否使用 Plan 模式：那个答案就是 model的推理，而不是写在这里的东西。

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

一个公正的抱怨，已作为开放 issue 提交，认为大部分路由是确定性的，而叙事式描述难以快速浏览。没有什么阻止你索要压缩形式——「直接给我序列」就会得到序列。散文承载的是条件那一半：分支、哪里期望人类决策、以及在哪一步之间该清空或压缩。扁平的清单恰恰丢掉了这些。

它能在我自己的技能或另一位作者的技能之间路由吗？

不。三个独立的提案要求一个读取你本地 skills/ 目录，并根据已安装的内容给出推荐。 ask-matt 不是那样。它是某一套技能的地图，手工维护，对你编写或从别处安装的技能一无所知。

它让我编辑一个 SKILL.md。

那个建议常常正确，却很少持久。有人问它如何让 implement 关闭任务，被要求给技能加一行，然后立刻发现了问题： npx skills update 会覆盖文件，而插件安装是只读的。把常驻行为放进你自己的 CLAUDE.md or AGENTS.md，或在调用时说出来。提示词级别的适配能经受住更新——把流程指向 Linear 而不是 GitHub，或问它哪些开放任务可以并行，都是人们这样做的例子。

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

在认定它消失之前，先查更新日志有没有重命名。 writing-great-skills became writing-for-agents 没有别名， to-prd became to-spec，以及 pathfinder became wayfinder。有四个技能被直接退役，并入吸收它们的技能： ubiquitous-language, design-an-interface, qa and request-refactor-plan。相反的情况就是上面说的路由器自身的滞后。

做到以下就算成功

• 它以点明该输入什么结束，并就此打住，而不是自己开始工作。
• 它返回的路线提到在哪里清空或压缩上下文、在哪里需要你审查，而不只是技能名列表。
• 当两个技能相近时，它说出选哪个以及为什么另一个不适合你。
• 它关于另一个技能行为的任何论断，都会在追踪记录中显示为它正在阅读那个技能的 SKILL.md.
• 你在它返回的内容中认出自己的情境，而不是最接近的通用场景。

在流程中的位置

ask-matt 是一个 独立路由器 凌驾于整个技能集之上。它从来不是链上的一步；它指向每条链，是其他文档页链接回来的节点，这样它们都不必重画关系图。从这里你大多会落到 grill-with-docs，主流程的头部，或 triage，它是为「找上门的工作」而不是「你发起的工作」准备的入口。

它是一个 二手资料 覆盖它所描述的技能。当路由器和 SKILL.md 意见不合时， SKILL.md 是对的。