Claude Code 最强Skills路由器：/ask-matt 完全上手指南（入门篇）
很多人兴致勃勃地装了 Matt Pocock 的 Skills 之后，大概率只用过其中两三个。剩下的一直躺在列表里------不是没用，是你不知道什么时候 用、按什么顺序 用、用完之后下一步接什么。
但 Matt Pocock 提供的是一整套 Claude Code 的工程技能，18 个命令各有各的使用姿势。想法来了，是该
/grill-with-docs还是/grill-me？打磨完了，是该直接/implement还是先/to-spec？bug 修到一半发现根因是架构问题------该切哪个命令？好消息：Matt 在设计这套体系时就留了一个答案------
/ask-matt。它不是另一个干活命令，它是这套东西的内置导航。
一、一句话说清楚它是什么
/ask-matt 是 Matt Pocock 工程技能体系的导航仪。
它自己不写代码、不修 bug、不画架构图。它只做一件事：根据你现在面临的情况，在 Matt 这套工作流中告诉你用哪个命令、走哪条路径。
这套体系覆盖的是软件工程的全流程 ------从打磨一个模糊想法，到写出可执行的规格，到拆票、实现、审查、提交。它不是你装的所有 skill 的通用路由，而是 Matt 精心设计的一条**"从想法到交付"的流水线**。
二、设计哲学：一个主路 + 三条匝道
/ask-matt 管理的所有技能，按照一条统一的设计思路组织：
想法 ──→ 打磨 ──→ 规格 ──→ 拆票 ──→ 实现 ──→ 审查 ──→ 提交
↑ ↑
│ │
grill-with-docs prototype（可选分支）这条主路叫做 idea → ship（从想法到交付），它覆盖了 90% 的日常编码工作。
主路之外，还有：
| 类型 | 角色 | 例子 |
|---|---|---|
| 匝道（On-ramps） | 从特定场景汇入主路 | bug 修复、issue 涌入、巨型探索 |
| 代码健康 | 日常维护，不是功能开发 | 改善架构、重整模块 |
| 独立工具 | 完全不经过主路 | 研究、原型、学习 |
| 词汇层 | 运行在其他技能之下 | 领域建模、模块设计 |
三、主路详解：从想法到交付
第一步：打磨想法------/grill-with-docs
你有一个想法。但想法通常是模糊的。
/grill-with-docs 通过不断追问来帮你把想法磨锋利。它像一个不会累的面试官------追问你的目标、约束、边界条件、优先级。关键特性：
- 有状态 ：每个结论都写入
CONTEXT.md和 ADR（架构决策记录） - 不丢信息：换会话也带着走
如果你还没有代码库，只是在脑子里构思一个想法，可以用 /grill-me------同样的问题驱动，但不写入文件，纯思考。
第二步：要不要做原型？
打磨过程中，有时会卡在一个问题上："这个交互方式到底行不行？"纯靠讨论解决不了。
这时分支出来，用 /prototype 快速做一个一次性原型------目的不是交付，而是回答那个具体问题。原型跑通了，把学到的东西带回去，代码删掉。
会话之间的衔接用 /handoff------它负责把当前对话压缩成一份 Markdown 文件，你在新会话中引用它继续。
第三步：写规格------/to-spec
想法磨清楚了。现在是时候把它写成一份可以构建的规格书。
/to-spec 把对话中的讨论、决策、权衡，整理成结构化的规格文档。
第四步：拆票------/to-tickets
规格有了，但一块巨石没法施工。
/to-tickets 把规格拆成追踪子弹（tracer bullets） ------每张票都声明了它的前置依赖（blocking edges）。这意味着：
- 开发顺序不是拍脑袋的，是自动推导的
- 任何阻塞解开的票都可以立即开工
- 多人协作时不会互相踩脚
第五步：实现------/implement
最后一步：写代码。
/implement 驱动 /tdd （测试驱动开发），一次一个红-绿-重构循环。实现完自动跑 /code-review，做双轴审查（代码规范 + 规格对照），通过才提交。
关键的设计决策：每个 /implement 都从干净上下文开始------不会带着前面几十轮对话的包袱去写代码。干净脑子的代码质量就是更高。
四、三条匝道：从 Bug、Issue 和迷雾汇入主路
匝道一：Bug 报修------/diagnosing-bugs
有些 bug 不是一眼能看出来的。间歇性的、藏在状态交错里的、几次提交之间悄悄冒出来的。
/diagnosing-bugs 的核心原则：在形成理论之前，先建立反馈循环。你必须有一条能在当前 bug 上稳定跑红的命令，才允许往下推理。然后修复 + 回归测试。
如果复盘发现根因是"代码里没有好的接缝来锁定这个 bug"，它会把球传给 /improve-codebase-architecture------先修结构，再做功能。
匝道二：Issue 涌入------/triage
Bug 报告、功能请求、用户反馈------全部从各种渠道涌进来。
/triage 让这些原始 issue 穿过分类角色，产出agent-ready issue ------格式干净、优先级明确、足够具体，后续 /implement 可以直接接手。
注意 ：Triage 只处理别人提交的 issue。
/to-tickets产出的票已经是 agent-ready，不要拿去 triage。
匝道三：远征探险------/wayfinder
有些东西太大了。不是"一个功能"那种大，是"我们甚至连问题是什么都不知道"那种大。
比如一个全新的产品线，或者横跨多个系统的大规模重构。地图上空白的区域。
/wayfinder 是这套体系中最重的流程。它在 issue tracker 上产出决策票（decision tickets） ------一张票等于一个需要被解决的问题，产出的是一个决策 而非交付物。一轮一轮地清，直到雾散开，路出现了。
然后 /wayfinder 交接而非建造 ：它把地图交给 /to-spec，后者把关联决策拧成可执行的计划，再走主路 /to-tickets → /implement。
匝道和主路的关系：
| 如果场景是 | 起点（匝道） | 汇入主路 |
|---|---|---|
| 用户报了一个 bug："代码块转换把中文注释里的括号也转了" | /diagnosing-bugs → 复现 → 修 → CONTEXT.md |
/implement 直接修 |
| 外部提了 5 个需求、3 个 bug，全堆在 issue 列表里 | /triage → 分类 → 标优先级 → 产出 agent-ready issue |
/implement 逐个处理 |
| "我要重构整个发布 pipeline，涉及 N 个系统，需求还不知道" | /wayfinder → 探索 → 决策票 → 雾散了 |
/to-spec → /to-tickets → /implement |
简单来说："做新东西"走主路，"有东西找我"走匝道。
五、代码健康：日常体检
主路是做新功能的。但好的代码库不能只盖楼不维护。
/improve-codebase-architecture ------ 有空就跑一下，它会扫描代码库，找出该加深的设计点。你挑一个方向去做，就产生了一个可以走主路去实现的想法。
/codebase-design ------ 上面查出来的方向有了，这个技能提供模块设计的词汇表 （module, interface, depth, seam, adapter, leverage, locality）。它的核心原则：很多行为，藏在很小的接口后面，从干净的接缝切入。
六、词汇层：运行在底层
两个基础技能不直接面对终端用户，而是被其他技能调用：
/domain-modeling ------ 挑战模糊术语，解决一词多义（"account" 干了三件不同的事？），把不可逆的决策写成 ADR。/grill-with-docs 就是靠它来保持 CONTEXT.md 始终干净。
/codebase-design ------ 模块设计的深层语言。/tdd 和 /improve-codebase-architecture 都使用它的词汇。
七、跨会话：handoff vs compact
开发者最头疼的问题之一：一个复杂任务，一个会话窗口放不下。
/ask-matt 提供两个方案：
| 方式 | 机制 | 适用场景 |
|---|---|---|
/handoff |
压缩对话→Markdown 文件→新会话引用 | 需要保留详细历史的分支（比如 prototype 会话） |
/compact（内置） |
同一个会话→早期轮次被摘要 | 阶段间的自然停顿，不介意丢失逐字历史 |
简而言之：handoff 是分叉；compact 是继续。 不要在阶段中途 compact------agent 会迷路。
八、独立工具
一些完全脱离主路的技能：
| 工具 | 用途 |
|---|---|
/grill-me |
和 /grill-with-docs 同样的追问引擎，但没有代码库------不写文件，纯思考 |
/prototype |
一次性、可丢弃的小程序，回答一个设计问题 |
/research |
把读资料的体力活交给后台 agent，返回带引用的 Markdown 文件 |
/teach |
多会话学习一个概念，当前目录作为状态工作区 |
/writing-great-skills |
编写和编辑 skill 的参考手册 |
九、前置条件
在第一次使用工程流程之前，需要先跑：
bash
/setup-matt-pocock-skills它会配置 issue tracker、triage 标签、文档布局------这些都是后面流程依赖的基础设施。也支持自定义 issue tracker。
十、完整命令速查表
| 命令 | 一句话 |
|---|---|
/ask-matt |
我不知道该用哪个------帮我选 |
/setup-matt-pocock-skills |
首次使用前的环境配置 |
/grill-with-docs |
有代码库，打磨想法 |
/grill-me |
没代码库，纯聊天打磨 |
/to-spec |
把对话输出为规格书 |
/to-tickets |
规格拆成可执行的任务票 |
/implement |
TDD + Code Review，标准交付流程 |
/tdd |
纯测试驱动开发 |
/code-review |
对 diff 做两轴审查 |
/triage |
整理外部涌入的 issue |
/diagnosing-bugs |
难修的 bug：先建反馈循环 |
/wayfinder |
巨大模糊项目的探索工具 |
/prototype |
一个问题的可丢弃原型 |
/handoff |
会话压缩→文件→新会话继续 |
/research |
后台资料调研 |
/improve-codebase-architecture |
扫描可改进的结构 |
/codebase-design |
模块设计深层词汇 |
/domain-modeling |
领域语言淬炼 |
/teach |
多会话学习 |
/writing-great-skills |
Skill 编写参考 |
小结
你不需要背 20 个命令、记住 5 条工作流、每次纠结"这个情况应该用哪个"。
你只需要记住一个入口：
/ask-matt，我现在想做 X，从哪里开始？
Matt 会告诉你第一步是什么，做完之后下一步是什么。你跟着走就行。
最好的工具，是让你忘记自己在用工具。
本文基于 ask-matt skill v1.0 撰写于 2026 年 7 月。所有命令和流程可能随版本更新变化，请以 SKILL.md 为准。
下集（实战篇）：从零构建 CLI 工具的完整 walkthrough