ask-matt 精读：一张会撒谎的地图，为什么宁可手写也不去扫描你已经装了什么

（本文读的是 mattpocock/skills 快照 5beb35b，2026-10-19。引用的原文都能按文中的文件路径回仓库核对。这是「逐个技能精读」系列的第一篇，聚焦 ask-matt 一个技能。）

你敲它，它才活

Matt Pocock 的 skills 仓库里，随插件发布的有 27 个技能。你不可能记住每一个，于是有一个技能专门回答「我现在该用哪个」：/ask-matt。README 对它的描述只有一句——“Ask which skill or flow fits your situation. A router over the user-invoked skills in this repo.”

走一遍真实路径。触发方式是用户手动输入 /ask-matt，然后用大白话描述处境：一个不知道从哪下手的想法、一堆别人提过来的 bug、一个已经跑得太长的会话。它的产出不是代码、不是文件、也不是工单，而是一段对话：它报出你下一步该敲的技能名（或一串顺序），顺带指出这条顺序里哪些是必须由人来做的决定。

这个交互边界在 docs/engineering/ask-matt.md 里被写得很死：

It recommends and stops. It does not grill, write a spec, open a file or fire the skill it just named; what you get back is the next thing to type, and you type it.

「推荐完就停」不是修辞。它不 grill 你、不写 spec、不打开文件、也不替你触发它刚刚点名的技能。你拿到的是「下一件要输入的事」，然后由你自己输入。这在技能生态里相当反直觉：绝大多数技能的价值在于动手，而这个技能的价值恰恰在于不动手。

它怎么组织这张地图

skills/engineering/ask-matt/SKILL.md 开头先立规矩：在你说出某个技能干什么、或建议跳过某一步之前，先去读那个技能的 SKILL.md——“the summaries here are for orientation only”（这里的摘要只用于定位方向）。然后它给出四类路线：

主流程（main flow）：idea → ship，绝大多数工作走这条。
on-ramp：一个会生成工作、再汇入主流程的起点（triage、diagnosing-bugs、wayfinder）。
standalone：不在任何流程上，单独使用（prototype、research、to-questionnaire、wizard 等）。
vocabulary layer：垫在所有技能下面的两个词表技能（domain-modeling、codebase-design）。

主流程本身是四步：先用 /grill-with-docs 通过访谈把想法磨清楚；中间有个分支，只有跑起来才能回答的问题走 /prototype，用 /handoff 两头接上；再一个分支——「这是不是一个跨会话的构建」，是则 /to-spec 转成规格、/to-tickets 拆成带阻塞边（blocking edges）的 tracer-bullet 工单，然后逐张 /implement（每张之间 /clear）或整条 /implement-spec；无论走哪条，代码都由 /tdd 驱动、以 /code-review 收口；发 PR 时 /pr 负责正文形态；最后 /retro 回看这个会话，改的是 agent 的环境而不是代码。主流程之外还挂着上下文卫生规则（第 1–3 步要保持在一个不打断的上下文窗口里）和「相位边界」上五个选项的有序决策树。

这里最关键的一个词是 flow，不是 skill。SKILL.md 原文：

A flow is a path through the skills. Most paths run along one main flow, and two on-ramps merge onto it. Everything else is standalone, or a vocabulary layer that runs underneath.

所以当你说出处境，它给你的答案不是「匹配你关键词的那个技能」，而是把你放到一条流程的某一步上。这两种回答看起来像，其实完全不同：前者是查表，后者是定坐标。

它和一般技能哪里不一样

三处结构性选择，每一处都和「把 prompt 堆厚一点」相反。

第一，它是路由器，不是工人。 它只输出「下一步输入什么」，不产出任何工件。

第二，它是一张手写的地图，不扫描你的环境。 原文：

It is also a hand-written map of the skills in this repo rather than a scan of what you have installed, so it will not route you over your own skills or another author’s.

它只认识本仓库那批已发布的技能，不会去读你装了什么，也不会路由到你自己写的技能。这个取舍看着像缺点（不够聪明），实质是可核对：地图就在一个文件里，你读得完、改得动；一个动态扫描器，你没法核对它为什么给你这个答案。

第三，它是 user-invoked，只有人能打。 frontmatter 里两行：

name: ask-matt
description: Ask which skill or flow fits your situation. A router over the skills in this repo.
disable-model-invocation: true

仓库的 .agents/invocation.md 解释了这条轴：user-invoked 技能只能由人输入名字到达，配套 agents/openai.yaml 里的 policy.allow_implicit_invocation: false；并且它的 description 是给人看的——“a one-line summary read by a person browsing slash-commands. Strip trigger lists.” 一般技能靠 description 里塞满 “Use when the user mentions…” 来抢自动调用；ask-matt 反着来，把触发词全剥掉，因为模型压根不该自己路由。

它有意识摒弃了什么

摒弃了「自动发现」：不扫描已安装技能，不做动态路由。
摒弃了触发词：description 只留一句人话。
摒弃了执行权：点名之后不 fire 那个技能。
摒弃了防腐自动化：它没有用脚本来校验地图是否过时，而是把这件事写成明文规则。仓库 AGENTS.md 里那一句是本篇的核心证据：

whenever you add, rename, remove, or change how a user-reachable skill fits the flows, re-read ask-matt’s SKILL.md and update it so the map stays accurate: a new skill it never mentions, or a stale one it still routes to, is a router that lies.

它直接承认路由会撒谎：新增了却没提，或已经废弃却还在指路，都算撒谎。它选择的应对不是「让路由永不出错」，而是「把重同步写成人/agent 都能执行的义务」。这比加一个校验脚本更贴合仓库的整体姿态——机械错误交给确定性检查，判断类的事写成标准。

还有一处刻意的不一致值得学。.agents/invocation.md 规定：技能要调用另一个技能时，必须显式写成「Call the Skill tool with X」，而不是在散文里丢一个 /name。但路由散文被明确豁免——“Router prose that just names skills for a human to pick from isn’t invoking anything, so it keeps /skill-style names as plain labels.” 同一个写法，在「会触发」和「只是给人看」两种语义下规则不同：会触发的写全，只是给人看的可以简写。

可迁移结论

如果你要给自己的一堆技能写入口，可以照抄这四条：

写流程，不写目录。 别输出「N 个技能列表」，要输出「从处境出发的路径」，并标出每一步的人决定点。
把入口设成 user-invoked。 自动调用留给干活儿的技能；路由只在你敲它时活，description 就写成人话。
只推荐，不执行。 让路由器止于「下一件该输入的事」，把动作交给下游技能，边界才清楚。
给地图写一条防腐规则并指名。 承认它会腐烂，把「何时必须重读、重写这张地图」写成明文义务；“a router that lies” 这种说法本身就是让人记得去维护它的钩子。

读完 ask-matt 会得到一个反常识的结论：一个技能可以什么都不做，只负责把你放对位置——而这件事值得单独写成一个技能、单独禁掉自动调用、单独维护。