ask-matt

学习笔记 skill 2026-08-14

技能导航仪

你只需要记住一个入口：

/ask-matt，我现在想做 X，从哪里开始？

Matt 会告诉你第一步是什么，做完之后下一步是什么。你跟着走就行。

最好的工具，是让你忘记自己在用工具。

/ask-matt  是 Matt Pocock 工程技能体系的导航仪。它自己不写代码、不修 bug、不画架构图。它只做一件事：根据你现在面临的情况，在 Matt 这套工作流中告诉你用哪个命令、走哪条路径。

这套体系覆盖的是软件工程的全流程——从打磨一个模糊想法，到写出可执行的规格，到拆票、实现、审查、提交。

设计哲学：一条主路+三条匝道

想法-打磨-规格-拆分-实现-审查-提交

• grill-me
• to-spec
• to-tickets
• implement TDD + Review
• code-review

匝道

• diagnosing-bugs 难修的 bug:先建反馈循环，再推理，修改加回归测试
• triage 外部 issue 涌入，分类成 agent-ready 格式，汇入 implement
• wayfinder 巨大迷雾项目，产出决策票，雾散了交给 to-spec
• research 独立工具 后台 agent 读资料，产出带引用的 Markdown

主路之外，还有：

主路详解：从想法到交付

打磨想法

你有一个想法。但想法通常是模糊的。

/grill-with-docs 通过不断追问来帮你把想法磨锋利。它像一个不会累的面试官——追问你的目标、约束、边界条件、优先级。关键特性：

• 有状态：每个结论都写入 CONTEXT.md 和 ADR（架构决策记录）
• 不丢信息：换会话也带着走

如果你还没有代码库，只是在脑子里构思一个想法，可以用 /grill-me——同样的问题驱动，但不写入文件，纯思考。

要不要做原型？

打磨过程中，有时会卡在一个问题上：”这个交互方式到底行不行？”纯靠讨论解决不了。

这时分支出来，用  /prototype  快速做一个一次性原型——目的不是交付，而是回答那个具体问题。原型跑通了，把学到的东西带回去，代码删掉。

会话之间的衔接用  /handoff——它负责把当前对话压缩成一份 Markdown 文件，你在新会话中引用它继续。

写规格

想法磨清楚了。现在是时候把它写成一份可以构建的规格书。

/to-spec  把对话中的讨论、决策、权衡，整理成结构化的规格文档。

拆分

规格有了，但一块巨石没法施工。

/to-tickets 把规格拆成追踪子弹（tracer bullets）——每张票都声明了它的前置依赖（blocking edges）。这意味着：

• 开发顺序不是拍脑袋的，是自动推导的
• 任何阻塞解开的票都可以立即开工
• 多人协作时不会互相踩脚

实现

最后一步：写代码。

/implement  驱动 /tdd（测试驱动开发），一次一个红-绿-重构循环。实现完自动跑  /code-review，做双轴审查（代码规范 + 规格对照），通过才提交。

关键的设计决策：每个  /implement  都从干净上下文开始——不会带着前面几十轮对话的包袱去写代码。干净脑子的代码质量就是更高。

三条匝道

1.Bug 报修

有些 bug 不是一眼能看出来的。间歇性的、藏在状态交错里的、几次提交之间悄悄冒出来的。

/diagnosing-bugs  的核心原则：在形成理论之前，先建立反馈循环。你必须有一条能在当前 bug 上稳定跑红的命令，才允许往下推理。然后修复 + 回归测试。

如果复盘发现根因是”代码里没有好的接缝来锁定这个 bug”，它会把球传给  /improve-codebase-architecture——先修结构，再做功能。

2.Issue 涌入

Bug 报告、功能请求、用户反馈——全部从各种渠道涌进来。

/triage 让这些原始 issue 穿过分类角色，产出 agent-ready issue——格式干净、优先级明确、足够具体，后续 /implement 可以直接接手。

注意：Triage 只处理别人提交的 issue。/to-tickets 产出的票已经是 agent-ready，不要拿去 triage。

3.远征探险

有些东西太大了。不是”一个功能”那种大，是”我们甚至连问题是什么都不知道”那种大。

比如一个全新的产品线，或者横跨多个系统的大规模重构。地图上空白的区域。

/wayfinder 是这套体系中最重的流程。它在 issue tracker 上产出决策票（decision tickets）——一张票等于一个需要被解决的问题，产出的是一个决策而非交付物。一轮一轮地清，直到雾散开，路出现了。

然后 /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 始终干净。

ADR 是软件工程里很常见的一种文档，全称是 Architecture Decision Record，架构决策记录。

/codebase-design —— 模块设计的深层语言。/tdd 和 /improve-codebase-architecture 都使用它的词汇。

跨会话： handoff vs compact

开发者最头疼的问题之一：一个复杂任务，一个会话窗口放不下。

/ask-matt 提供两个方案：

简而言之：handoff 是分叉；compact 是继续。 不要在阶段中途 compact——agent 会迷路。

独立工具

一些完全脱离主路的技能：

前置条件

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

/setup-matt-pocock-skills

它会配置 issue tracker、triage 标签、文档布局——这些都是后面流程依赖的基础设施。也支持自定义 issue tracker。

完整命令速查表