很多人兴致勃勃地装了 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 的参考手册

---

九、前置条件

在第一次使用工程流程之前，需要先跑：

/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 为准。