Matt Pocock 的 38 个 Agent Skills 速通：从想法到代码的 AI 研发流水线

一条命令装完 Matt Pocock 开源的 38 个 Agent Skills：

1
npx skills@latest add mattpocock/skills

装完你会发现，终端多了一整排 /grill-me、/to-spec、/to-tickets、/implement、/diagnosing-bugs。

说实话，装完跑了一圈之后，我觉得这是目前社区把「人类如何给 AI 研发立规矩」想得最透彻的一套开源 SOP。

这套体系大概率会评价两极：喜欢的人觉得它把天马行空、喜欢直接乱写代码的 Agent 关进了工程工程化的铁笼子里；不喜欢的人会嫌它太重——改两行 CSS 还要先做 Grilling 拷问和 Tickets 拆解，简直是给自己找罪受。

这篇聊清楚三个问题：它到底解决什么？哪些命令该你手动点，哪些让 LLM 自己触发？这 38 个 Skill 该怎么选？

核心心智：人类掌舵还是 LLM 自主？#

玩这套 Skill，最重要的一点不是背命令，而是看懂它的配置控制：为什么有的命令严禁 LLM 自己调用（disable-model-invocation: true），有的却鼓励 LLM 自主触发？

用一行公式拆解它的架构心智：

1
AI 研发体系 = 人类决定节奏的「控制流」（手动） + LLM 随需取用的「词汇与工具箱」（自动）

翻看每个 Skill 的 SKILL.md frontmatter，你会发现一个清晰的边界：

关键节点（手动 /command）：立项（/grill-me）、定规范（/to-spec）、拆任务（/to-tickets）、领任务动手（/implement）。这些涉及方向抉择、上下文边界清空、阶段性验收的操作，全部打上了 disable-model-invocation: true。必须由人类在键盘前显式敲下，AI 绝不能自作主张。
执行细节与词汇层（LLM 自动加载）：测试驱动（tdd）、深层模块规范（codebase-design）、领域建模（domain-modeling）、冲突化解（resolving-merge-conflicts）。这些是具体的「怎么做」规范，写在 Prompt 或代码里，LLM 在进入具体编码场景时会自动激活。

弄清楚这个心智，你就不会迷失在 38 个命令里：你负责点发令枪，AI 负责在赛道里按规范冲刺。

主线流程速通：从想法到代码的 4 步走#

Matt Pocock 设计的「Main Flow（主线流）」只有一条闭环路径：

1
[想法] ──> 1. Grilling (拷问) ──> 2. Spec / Tickets (拆单) ──> 3. Implement (TDD) ──> 4. Code Review (双维审查) ──> [交付]

1. 想法打磨：Grilling（质询）#

有想法想动手时，先别让 AI 写代码，让它先来「拷问」你：

在空目录或探索期：敲 /grill-me。纯文本无状态对话，AI 会无休止地追问你的边界条件、核心假设，把你脑子里的模糊概念逼问清楚。
在成熟项目目录：敲 /grill-with-docs。带状态的质询，AI 会把讨论出的关键共识落盘为 CONTEXT.md，硬性技术选型记录进 ADR（架构决策记录）。

在这个阶段，事实是 AI 的，但决策是你的。

2. 规范与工单：To-Spec 与 To-Tickets#

当想法在质询中达成闭环后，不要直接写代码，走两步结构化拆解：

/to-spec：AI 把上一阶段所有的对话、背景、边界整合压缩成一份标准的 Spec 说明书。
/to-tickets：把 Spec 拆成一张张 Tracer-bullet 工单。每张工单都标明自己的阻塞依赖（Blocking Edges），并且是一张单次会话就能吃透的独立任务。

为什么在这个节点清空上下文？
从 /grill-me 到 /to-tickets 建议保持在一个会话窗口内，确保背景记忆连贯。但一旦 Tickets 拆分完毕，立即清空（/clear）或开启新窗口。之后的每一个开发任务只喂当前那张 Ticket，远离上下文腐烂。

3. 功能开发：Implement 与 TDD#

拿到某张具体的 Ticket 后，运行 /implement。它内部会自动拉起两项能力：

自动遵守 tdd：红绿重构。先写最小失败测试用例，再写业务实现，严禁无测试直接贴大段业务代码。
遵循 codebase-design：按照 Deep Module（深层模块）哲学设计接口，接口尽量小，行为尽量深，隐藏实现细节。

4. 交付把关：Code-Review#

代码写完，自动或手动调起 /code-review。它会并行拉起两个维度的检查：

Standards 维度：代码风格、测试覆盖度、项目约定、命名规范。
Spec 维度：这次提交的代码到底有没有完全满足最初 Ticket 里要求的所有验收项？有没有偷跑偏门？

两项全绿，这道流水线才算走到终点。

外挂与应急通道：排障、冲突与向导#

除了上述主线，套件里最让人惊艳的是几个特定场景的「应急工具」：

遇上偶发诡异 Bug：diagnosing-bugs（LLM 自动）
当系统抛出神秘报错、性能莫名下降时，AI 经常会天马行空胡乱猜因。这个 Skill 会强行制止 AI 瞎猜，逼它先写出一个稳定变红（一键必现）的回归测试命令，锁定反馈环，然后才准查源码修复。
合并分支冲突：resolving-merge-conflicts（LLM 自动）
绝不图省事执行 --abort。AI 会自动追踪冲突两侧代码背后的提交意图，逐段完成意图合并，而非机械选择保留 HEAD 或传入分支。
遇到人机边界：wizard（LLM 自动）
AI 经常卡在需要人类干预的地方（例如去云平台控制台申请 API Key、配置环境变量、跑单次迁移）。触发此 Skill 时，AI 不会只甩一句冷冰冰的“请你自己配”，而是会自动编写并弹出一个交互式 Bash 向导脚本，一步步引导你把 URL 打开、输入值并自动灌进 .env。

速查清单：38 个 Skill 分类与调用方式#

以下为 mattpocock/skills 完整 38 个技能的用途速查。

模块分类	Skill 名称	调用机制	核心用途与触发时机
主流程	`grill-me`	仅手动	纯文本无状态的需求连续质询，用于萌芽期梳理。
	`grill-with-docs`	仅手动	项目内需求质询，产物落盘为 `CONTEXT.md` 与 ADR。
	`grilling`	LLM 自动	质询/拷问底层逻辑原语。
	`prototype`	LLM 自动	快速抛弃型原型编写，通过可运行代码澄清分歧。
	`handoff` / `claude-handoff`	仅手动	阶段交接与会话上下文搬迁，生成便携式说明。
	`to-spec`	仅手动	整理提炼完整的需求规范说明书（Spec）。
	`to-tickets`	仅手动	将 Spec 拆分为独立、具依赖关系的工单集。
	`implement`	仅手动	领取具体工单，内部驱动 TDD 开发与提交前评审。
	`implement-spec`	仅手动	跳过拆单，直接按 Spec 完整实现（适合小需求）。
	`tdd`	LLM 自动	红绿重构测试驱动开发标准流程。
	`code-review`	LLM 自动	双维度（规范 + 需求）Diff 审查。
分流与排错	`triage`	仅手动	对外部传入的原始 Bug 报告进行分诊与标准化。
	`diagnosing-bugs`	LLM 自动	疑难 Bug 排查，坚持“先有必红测试，再行动手”。
	`wayfinder`	仅手动	超大模糊项目（Greenfield）的决策路径推导演化。
架构与领域	`domain-modeling`	LLM 自动	统一领域命名概念，消除同名异义，记录 ADR。
	`codebase-design`	LLM 自动	深层模块（Deep Module）设计规范。
	`improve-codebase-architecture`	仅手动	架构体检，识别加深模块、重构接缝的机会。
	`setup-ts-deep-modules`	仅手动	初始化 TypeScript 深层模块项目配置。
人机协作	`ask-matt`	仅手动	整个工作流的导航仪与用法问答。
	`research`	LLM 自动	委派子 Agent 调研一手资料并沉淀 Markdown 文档。
	`wizard`	LLM 自动	生成交互式向导脚本，引导人类完成敏感凭证录入。
	`resolving-merge-conflicts`	LLM 自动	按意图逐段合并 Git 冲突，不轻易回滚。
	`to-questionnaire`	仅手动	向外部人员生成调查问卷，补全关键缺失信息。
	`wait-what`	仅手动	强制 AI 停止使用黑话，用通俗语言重讲一遍。
	`loop-me`	仅手动	启动多轮迭代优化循环。
	`teach`	仅手动	交互式教学某个技术概念。
	`retro`	仅手动	项目复盘与总结。
文档与 Prompt	`writing-for-agents`	LLM 自动	编写专供 AI 消费的系统提示词（SKILL/AGENTS）。
	`writing-beats`	仅手动	按节拍梳理长文叙事大纲。
	`writing-fragments`	仅手动	零散想法与碎片化灵感整合。
	`writing-shape`	仅手动	调整文章的宏观篇幅与注意力节奏。
脚手架防线	`git-guardrails-claude-code`	LLM 自动	拦截强制推送与重置等危险 Git 命令。
	`setup-pre-commit`	LLM 自动	配置 Husky / lint-staged 提交质检门禁。
	`migrate-to-shoehorn`	LLM 自动	移除测试中危险的 `as` 类型强转。
	`scaffold-exercises`	LLM 自动	快速搭建教学题库与章节解题目录。
	`setup-matt-pocock-skills`	仅手动	初始化本套件所需的 Label 体系与目录。

哪里劝退：这套工作流的真实门槛#

这套东西虽然精巧，但真正在团队或个人项目中推行，有两道非常真实的门槛：

强纪律性要求带来的心智负担：
如果你习惯了对 AI 说「帮我把这个功能写了，然后我改改就能用」，这套流程会让你觉得非常繁琐。它要求你在动手前做 Grilling，在实现前拆 Tickets，要求每个功能必须配测试。如果代码量极小或是一次性脚本，直接套这套流程属于过度设计。
多会话上下文管理的切换成本：
这套体系的灵魂在于「阶段交接与上下文隔离」（用 /handoff 换会话、用 /clear 清空记忆）。但在日常开发中，很多开发者习惯在一个对话框里一路聊到底。如果不遵循它的清空纪律，上下文很快会产生疲劳（Token 上限、幻觉增多），导致工单拆分与执行变形。

适合它的场景非常纯粹：一个人或者小团队在维护一个长周期的核心代码库，希望用严格的工程规范管住 AI 的手脚，而不是放任它把项目写成一团乱麻。

L1ngg's Home

核心心智：人类掌舵还是 LLM 自主？#

主线流程速通：从想法到代码的 4 步走#

1. 想法打磨：Grilling（质询）#

2. 规范与工单：To-Spec 与 To-Tickets#

3. 功能开发：Implement 与 TDD#

4. 交付把关：Code-Review#

外挂与应急通道：排障、冲突与向导#

速查清单：38 个 Skill 分类与调用方式#

哪里劝退：这套工作流的真实门槛#

目录