Matt Pocock 把自己日常使用的编码代理工作流公开在 mattpocock/skills。它不是一个替你做判断的自动开发框架，而是一组小型、可组合的 Agent Skills，覆盖需求澄清、领域建模、TDD、故障诊断、代码审查等真实工程活动。

Skills 更新很快，长期使用前仍应检查 README 和变更记录。

先选一种安装路线

官方提供两条路线，而且明确建议二选一：

  • Codex 及其他代理使用 skills.sh，把可编辑的技能文件复制到项目中，并由你选择具体技能和目标代理。
  • Claude Code使用官方市场里的 mattpocock-skills 插件，得到受管理、只读且自动更新的整套技能。

不要在同一个 Claude Code 环境中同时采用两种路线，否则每个技能会出现两份，代理到底读取哪一份也会变得模糊。

为 Codex 安装

官方命令通过 npx 运行，因此电脑需要先安装可用的 Node.js。进入目标仓库，在终端执行：

npx skills@latest add mattpocock/skills

安装器会询问复制哪些 Skills、安装给哪些编码代理。选择 Codex，并确保包含 setup-matt-pocock-skills。第一次不必全选，我建议从下面几项开始：

  • setup-matt-pocock-skills：完成仓库级配置；
  • ask-matt：不知道该走哪个流程时进行路由；
  • grill-me 或 grill-with-docs：在编码前追问需求；
  • tdd 与 diagnosing-bugs：建立实现和诊断反馈循环；
  • code-review：同时检查工程规范和需求符合度。

如果只需要一个技能，可以执行：

npx skills@latest add mattpocock/skills --skill=grill-me

准备好审查上游变化后，再显式更新某个技能：

npx skills@latest update grill-me

skills.sh 复制的是普通文件，你可以阅读和修改。第一次调用前应检查每个 SKILL.md 以及它引用的脚本。第三方 Skill 可能要求代理运行命令或修改文件，“安装成功”并不等于完成安全审查。

每个仓库配置一次

安装后在 Codex 中打开项目，输入：

请使用 $setup-matt-pocock-skills 配置这个仓库。

它会询问 Issue 放在哪里、Triage 使用哪些标签，以及生成的领域文档保存到哪里。如果团队需要共享这些约定，再把生成的仓库配置提交到版本库。不要照抄别的项目，因为任务系统、术语和文档布局本来就是当前仓库契约的一部分。

Claude Code 用户可以在终端安装官方插件：

claude plugins install mattpocock-skills

也可以在会话中输入：

/plugin install mattpocock-skills

安装后在每个仓库运行一次 /setup-matt-pocock-skills。官方插件已经位于 Claude Code 的官方市场，不需要先添加其他 Marketplace。

用具体任务调用 Skill

Codex 可以在任务匹配时自动采用 Skill，但显式写出 $skill-name 更不容易产生歧义。不要只输入一个名称，应同时给出真实输入和可验证结果：

请使用 $grill-me 质疑这个离线同步设计，确认关键分支后再实现。

请使用 $diagnosing-bugs 查明请求为何重复发送，先稳定复现，再加入回归测试。

请使用 $tdd 为上传器加入取消能力，每次只完成一个纵向切片。

Claude Code 使用仓库文档中的斜杠形式，例如 /grill-me。不要把 Claude Code 的 /skill-name 和 Codex 的 $skill-name 当成完全相同的语法。

正式修改前先验收安装

用 git status --short 检查安装器新增的文件，结果应只有你选择的 Skills 和对应代理配置。打开其中一个 SKILL.md，确认名称与准备调用的名称一致。然后先执行一个只读任务：

请使用 $ask-matt 为“偶发失败的集成测试”推荐处理流程，解释理由，但暂时不要修改文件。

回答应指出合适流程以及需要收集的证据。随后可在小问题上调用推荐的 Skill，观察行为是否符合说明：diagnosing-bugs 应先建立稳定复现和假设，tdd 应先得到失败测试，再修改生产代码。

如果 Codex 无法识别名称，先确认安装器的目标代理确实选择了 Codex，并检查文件是否位于安装器指定位置。如果发现两份同名 Skill，应删除不需要的安装路线，而不是同时维护两份。完成这些检查后，再授予写权限或处理大型 Diff。

一条可执行的工程流程

面对较大的功能，可以先用 grill-with-docs 澄清需求并统一项目术语，再把共识写成规格或 Tickets。实现时用 tdd 推进小切片；证据与假设冲突时切到 diagnosing-bugs；完成后用 code-review 同时对照仓库规范与原始规格。

Skills 的价值是强化反馈循环，而不是绕过工程检查。仍然要审阅 Diff、运行项目自己的测试、验证真实产品行为，并在授予宽泛权限前检查命令。如果 Skill 使用了错误测试命令、遗漏规则或输出风格不合适，就直接修订 Skill，或让 Codex 把这次纠正更新进去。可编辑、可反馈正是 skills.sh 路线的主要优势。

因此，稳妥起步不是“一次全装”：选择一条安装路线，先安装少量高价值 Skills，完成仓库配置，用带验收标准的任务显式调用；只有当流程通过实际验证后，再逐步扩大使用范围。