Mattpocock Skills在 GitHub 上有超过 16 万 star是目前最火的 Claude Code Skills 合集。其中/grill-me尤其出名它像一个不依不饶的面试官追着你问直到需求边界的每个分支都厘清很多项目比如我之前推荐的Trellis都基于它改造自己的需求对齐流程。但对齐过程中有三个问题被社区反复提及一堆问题一起问、自问自答、grill 结束后直接跳实现。v1.1 把这三个问题修了同时把整套 skills 的命名和流程重新理了一遍。/grilling的三个关键修复v1.1 对/grilling技能/grill-me和/grill-with-docs实际上都依赖它做了三个修复。新旧两个版本的对比如下图修复一更清晰的提问指导原来的指令只说「asking multiple questions at once is bewildering」。模型偶尔会忽略这条指令一次性抛出一堆问题。v1.1 则加了更明确的解释问题堆在一起用户记不住对齐效率反而下降。这比简单地从反向说「不要」效果更好。修复二确认门控以前 grill 结束后agent 有时会直接跳到实现阶段。你还没确认它已经开始写代码了。v1.1 加了一道门Do not enact the plan until I confirm weve reached a shared understanding.grill 结束后agent 会暂停等你确认对齐到位再往下走。修复三防止自问自答有些情况下agent 会自己探索代码库自己回答问题。你没参与它已经把方案想好了。v1.1 加了一个区分类型定义例子Facts探索代码库发现的东西代码模式、现有实现Decisions需要用户决定的东西架构选择、功能范围只有 Decisions 才需要追问。Facts 自己找就行。修复之后实战效果如何我针对自己的项目 PromptMaster 测了一下。题目就是我想为 PromptMaster 新增一个「提示词版本历史」功能允许用户回滚到提示词的历史版本请 grill 我这个方案主要是来测问题1有没有被解决因为它最直观。强模型方面我先后试了 GPT-5.6 Terra、Gemini 3.5 flash、GLM 5.2。说实话我没感受到什么差异。这三个模型本来就不太会一次甩几十个问题出来grill 结束后也基本会等你说OK再动手。三个修复对它们来说更像是把已经在做的事写进指令行为没变。弱模型就不一样了。我拿 step 3.7 flash 做对照这个模型平时笨得流口水我根本不敢用它做需求对齐。用修之前的老版本它一上来就甩二三十个问题你还没看清楚第一个屏幕已经刷过去了用修之后的新版本它还真能一次只问一个问完等你说完再问下一个。grill 结束后它也会停住不会自己跑去写代码但看到最后一行……好吧它还是没理解推荐是啥意思真是流口水……所以这三个修复的真实定位是给弱模型加护栏。强模型不需要弱模型离了不行。改名让 skills 定位清晰全流程开发更好用了v1.1 另一件大事是改了两处命名。这看起来是小调整但改完之后每个技能在整个体系里的位置才真正清晰五步闭环才成立。改名一/to-prd → /to-spec原来的/to-prd名字有问题。PRD 是产品需求文档描述的是产品本身。但这个技能实际创建的是 specification可能包含技术细节、非技术内容范围更广。Matt 承认这个名字一直取错了。v1.1 改成/to-specspec 成为整个 skills 体系的统一术语。改名二/to-plan /to-issues → /to-tickets原来的/to-plan和/to-issues合并成一个技能/to-tickets。原因issues这个词偏向 GitHub 和 Linear 的术语但概念是更通用的 ticketsspec 下面的一层层任务切片每个切片声明自己的阻塞依赖。一个技能搞定把计划、spec 或对话分解成 tracer-bullet tickets。改名之后五步闭环才成立两处改名解决了定位模糊的问题但更重要的结果是一整条流程终于能走通了。很多人问 Mattskills 到底该按什么顺序用v1.1 第一次给出了完整答案。老版本也有流程只是碎片化、后半段模糊/grill-me → /to-prd → /to-plan 或 /to-issues → /tdd 或直接实现 → 代码审查非标准化前半段还算清晰但拆完 issues 之后事情就模糊了。/tdd只管测试循环没有技能告诉你「拿到一个 issue 怎么系统地实现完」。代码审查有做但没有专门的技能标准化。/to-plan和/to-issues功能重叠用户得自己选。大型项目易超出单次会话的上下文只能靠/grill-with-docs硬扛。旧版核心问题是「规划有流程、落地靠自觉」。v1.1 补上了后半段五步闭环grilling用/grill-me、/grill-with-docs或/wayfinder把需求聊透spec用/to-spec生成规格文档原/to-prd更准确tickets用/to-tickets分解成任务切片合并原/to-plan/to-issuesimplement用/implement逐个实现旧版缺失的标准化环节code review/implement结束后自动调用/code-review审查旧版没有专门的审查技能这条流程解决了「我先该用哪个技能」的问题更关键的是它把后半段从「靠自觉」变成了「有技能兜底」。grilling 环节怎么选五步流程的第一步是 grilling但 v1.1 给了三个入口/grill-me、/grill-with-docs、/wayfinder。选哪个已有代码库用/grill-with-docs。大多数编码场景的首选。它读取项目里的 CONTEXT.md、ADR 等文档追问过程中自动更新 glossary 和决策记录领域对齐比/grill-me更扎实。Matt 本人也转向优先推荐带 docs 的变体。项目很早期、没有代码库用/grill-me。最轻量的纯对话追问适合非编码场景纯产品讨论或快速验证小想法。项目太大、太模糊单次 session 跑不完用/wayfinder。它把大项目拆成 GitHub issues每个 issue 是一个决策单元用阻塞依赖组织顺序。你逐个关闭 issuewayfinder 逐步构建完整地图。四种子任务类型类型用途特点Research调研技术方案、竞品实现、代码库现有模式AFK 任务agent 自主完成不需要实时交互Grilling澄清架构选择、功能范围、体验细节一次一个问题直到达成 shared understandingPrototype快速搭建 Logic 或 UI 原型提高讨论保真度让你看到方案再决策前端尤其有用Task配置环境、添加依赖、写工具函数等机械性工作不需要追问直接推进所有子任务完成后信息汇总在 GitHub issues 里可以直接转成 spec。/research、/prototype、TDD这三个技能是辅助位简单过一下。/research启动后台 agent 调研你继续工作它把发现写成 markdown 文件。/prototype两种模式Logic prototype 测试行为逻辑UI prototype 测试外观交互。v1.1 把它改成 model-invoked让 Wayfinder 可以自动调用。TDD原来 Red-Green-Refactor 循环里的 Refactor 被 v1.1 移出去了放到 code review 阶段处理。**原因是在实现阶段同时做重构负担太重。**新的 TDD 技能变成纯参考材料只保留核心顺序Red → Green → Refactor在 review 阶段。mattpocock skills 应该在啥情况下使用哪个平台最好我已经写了两篇文章极力推荐Trellis它真的很好用对各种规模的任务都有很好的支持小任务快速实现大改动步步为营。但它有个问题Trellis以上下文注入为核心思路又极度依赖hooks实现上下文注入一旦平台不支持hooks功能哪怕只是不支持子代理的hooks功能它的性能就会变得极不稳定。这点知乎的评论区就有人提过当然这不能怪它hooks的确很可靠。根据官网指南其最佳使用平台如下Claude CodeCursorOpenCodeCodebuddyDroidPi AgentOh My Pi如果你在用其它平台那我很建议你用Mattpocock Skills。在这里我尤其推荐新手使用Antigravity IDE别下成 2.0 版本了因为它内置的功能已十分完整几乎是自己实现了一套 mattpocock 软件开发流。它自带/grill-me而且交互体验比原版更好——选择的时候有UI了它还有/schedule和/goal帮你规划任务和设定目标。实施计划和实施清单是每条对话必做的不需要你手动生成。TDD 也是内置的会自动驱动测试先行尤其是你在AGNETS.md中要求的情况下。会话交接更省心agent 会自己维护 walkthrough你下载到项目内就可以实现/handoff一模一样的功能。所以 mattpocock skills 里激进一点的话比如我的用法可以只留两个/improve-codebase-architecture和/diagnose。/improve-codebase-architecture会系统性扫描代码库找浅模块、找可测试性薄弱的地方、找垂直切片的机会生成可视化 HTML 报告。antigravity 的架构审查维度覆盖了一部分但没有这么系统化。/diagnose是一个结构化调试循环复现→最小化→假设→仪器化→修复→回归测试。antigravity 的 Autonomous Debugging 可以自动诊断 Bug但没有这个强制走完六步的 phase gate。如果你调试时容易跳步、容易漏回归测试这个 skill 能帮你按住自己。其他技能根据你自己的情况判断。比如/caveman如果你需要省 token、/triage如果你有大量 issues 需要分拣、/research如果你经常需要后台调研。但核心配置就这两个/improve-codebase-architecture和/diagnose。少而精够用就行。在第一篇推荐Trellis的文章评论区有人这样问过现在有了 antigravity这个问题有了更简单的答案。antigravity 已经把这些流程内置了——追问、规划、分解、实现、审查一条对话自动走完。你只需要额外加/improve-codebase-architecture和/diagnose补上系统化架构审查和结构化调试循环。
