1. 为什么你的 AI Coding Agent 总在“自由发挥”
如果你用 Claude Code 或类似的 AI Coding Agent 写过稍复杂的模块，大概率遇到过这种场景：你说“帮我加个权限控制”，它很快吐出一大段代码，结构看着挺像回事。结果一跑，权限边界理解错了；再看 diff，它还顺手改了两个无关文件；你让它修，它开始在错误方向上打补丁，越修越乱。
问题不在模型智商，而在流程。Agent 从第一步就没有被放进“需求澄清 → 规格 → 测试 → 实现 → 评审”的反馈环里，它只能靠猜。猜对了是运气，猜错了就是技术债。
mattpocock-skills 这套 Agent Skills 解决的就是这件事。它不是又一个“帮我写代码”的提示词包，而是一组面向真实工程开发的 skill 集合，可以通过 skills.sh 安装到兼容 Agent Skills 标准的工具，也可以作为 Claude Code plugin 使用。核心思路一句话：不是教 Agent 更会猜，而是逼 Agent 少猜。
这篇聚焦它在 Claude Code plugin 场景下的落地，交付可复制的 skills 目录骨架、settings.json 配置片段、一次完整 TDD 循环的验证动作，以及 TaoToken 统一 Key/API 通道的接入位置。适合已经在用 Claude Code、想让 Agent 按测试先行执行的开发者。
2. TaoToken 前置：把 Key 和 API 通道先理顺
在配置 skills 之前，建议先把模型调用通道固定下来。原因很实际：Agent Skills 会频繁触发模型请求，TDD 循环里一次/implement可能连续调用十几次，如果 Key 散落在多个环境变量、多个 provider 配置里，排障时你根本分不清是 skill 逻辑问题还是通道问题。
TaoToken 在这里的角色是统一 Key 和 API 通道。你可以在官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 了解整体能力，API 入口是 https://taotoken.net/api（不加 UTM）。实际接入时，把 Claude Code 的模型请求指向这个统一通道，Key 只维护一份。
具体操作路径：先到 API Keys 页面生成一个 Key，地址是 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。生成后不要直接写进项目仓库，而是放进 shell 的环境变量或 Claude Code 的 settings 文件里。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，里面有各客户端的配置示例。
注意：Key 只放本地环境变量或用户级 settings，不要提交到 git。团队协作时用各自的 Key，不要共用。
如果你还没决定用哪个模型跑 TDD 循环，可以先去模型对话页面 https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 试一下同一段需求在不同模型下的追问质量。TDD 场景对模型的指令遵循要求高，先试再定，比配好了再换省事。
3. 可复制配置：skills 目录骨架与 settings.json
3.1 安装 mattpocock-skills
官方推荐的安装方式是通过 skills.sh：
npx skills@latest add mattpocock/skills安装过程中会让你选择目标 agent，务必勾选/setup-matt-pocock-skills。这个 setup skill 是后续所有流程的入口，漏了它后面命令会找不到。
如果你用的是 Claude Code plugin 方式，安装后 skills 会落在项目的.claude/skills/目录下。一个典型的目录骨架长这样：
.claude/ ├── settings.json └── skills/ ├── setup-matt-pocock-skills/ │ └── SKILL.md ├── grill-with-docs/ │ └── SKILL.md ├── to-spec/ │ └── SKILL.md ├── to-tickets/ │ └── SKILL.md ├── implement/ │ └── SKILL.md ├── tdd/ │ └── SKILL.md ├── code-review/ │ └── SKILL.md └── ask-matt/ └── SKILL.md每个SKILL.md里定义了这个 skill 的触发条件、执行步骤和约束。/implement会驱动/tdd，/code-review会分标准和规格两条线，这些关系都写在各自的 SKILL.md 里。
3.2 settings.json 配置片段
Claude Code 的 settings.json 需要配置模型通道和 skill 加载路径。下面是一个可复制的片段，把模型请求指向 TaoToken 统一通道：
{ "env": { "ANTHROPIC_BASE_URL": "https://taotoken.net/api", "ANTHROPIC_API_KEY": "sk-your-taotoken-key" }, "skills": { "enabled": true, "paths": [".claude/skills"] }, "permissions": { "allow": [ "Bash(npm test:*)", "Bash(npx vitest:*)", "Read", "Edit" ] } }几个关键点。ANTHROPIC_BASE_URL指向 TaoToken 的 API 入口，这样 Claude Code 的所有模型请求都走统一通道。ANTHROPIC_API_KEY填你在 API Keys 页面生成的 Key。permissions.allow里放测试命令，TDD 循环需要频繁跑测试，提前放行能减少中断。
提示：如果你在多个项目里用同一套 skills，可以把 settings.json 放到用户级目录
~/.claude/settings.json，项目级只覆盖差异部分。
3.3 初始化项目配置
装好之后，在项目根目录跑一次：
/setup-matt-pocock-skills它会问你三件事：Issue tracker 存在哪（比如 GitHub Issues 或本地 markdown）、Triage labels 哪些标签代表待处理和阻塞中、Domain documents 领域文档放哪个目录。回答完，它会在项目里生成对应的配置文件和初始的CONTEXT.md。
这一步别跳过。后面/to-tickets拆工单、/code-review按规格线评审，都依赖这里定义的 tracker 和文档路径。
4. 验证请求：跑一次完整的 TDD 循环
配置就绪后，用一个真实小需求验证整条链路。假设要给一个已有的用户模块加“邮箱格式校验”，需求边界清楚，适合走完整流程。
4.1 需求拷问
/grill-with-docs 我要给用户注册加邮箱格式校验Agent 会开始追问：校验在客户端还是服务端？空邮箱怎么处理？国际化域名要不要支持？错误信息返回什么结构？每个问题都逼你把模糊点提前暴露。追问结束后，它会把术语和规则写进CONTEXT.md，把设计决定写进 ADR。
4.2 规格与工单
/to-spec /to-tickets/to-spec把刚才的讨论整理成规格文档，/to-tickets按规格拆成边界清楚的小工单，并标清阻塞关系。你会看到类似这样的输出：
TICKET-001 [ready] 定义邮箱校验的公开接口签名 TICKET-002 [blocked by 001] 实现基础格式校验 TICKET-003 [blocked by 002] 补充边界用例测试 TICKET-004 [blocked by 003] 接入注册流程4.3 TDD 实现
/implement TICKET-002/implement会驱动/tdd，按红灯、绿灯、小步推进。第一步先确认测试边界，然后写一个会失败的测试：
// email.test.ts import { validateEmail } from './email'; describe('validateEmail', () => { it('rejects email without @', () => { expect(validateEmail('userexample.com')).toBe(false); }); });跑测试，红灯：
npx vitest run email.test.ts # FAIL: validateEmail is not a function然后写最小实现让测试通过：
// email.ts export function validateEmail(input: string): boolean { return input.includes('@'); }再跑，绿灯。接着补下一个边界用例，重复红灯绿灯。整个过程 Agent 不会一次性生成一大坨代码，而是小步走，每步都有测试兜底。
4.4 双轴评审
/code-review评审分两条线。Standards review 看代码质量、风格、安全；Spec review 看需求实现是否正确、边界是否覆盖。两条线分开出结论，避免“代码漂亮但需求做错”或“需求对了但质量透支”这类混淆。
5. 本篇常见错排查
5.1/setup-matt-pocock-skills找不到
安装时没勾选这个 skill。重新跑npx skills@latest add mattpocock/skills，在选择列表里确认勾上。或者手动检查.claude/skills/下有没有setup-matt-pocock-skills目录。
5.2 模型请求 401 或超时
先确认 settings.json 里的ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY是否正确。Key 去 API Keys 页面重新生成一个对比。如果用的是项目级 settings，检查有没有被用户级配置覆盖。接入文档里有各客户端的完整配置示例，对照排查。
5.3/tdd不按红灯绿灯走
检查/implement是否真的驱动了/tdd。有时候 Agent 会跳过测试直接写实现，这时候在会话里明确说“先写失败测试，跑给我看”。另外确认permissions.allow里放行了测试命令，否则 Agent 跑测试会被中断，它可能就绕过测试了。
5.4/to-tickets拆出来的工单还是太大
规格文档写得太粗。回到/to-spec，把验收标准写具体，每个工单应该能在一次 TDD 循环里完成。如果工单超过半天工作量，说明拆得不够细。
5.5 CONTEXT.md 没生成
/grill-with-docs的追问还没结束就中断了。这个 skill 需要你把所有分支问题回答完才会沉淀文档。如果中途退出，重新跑一次，它会接着问。
5.6 评审结论和预期不符
/code-review依赖规格文档和代码标准两份输入。如果规格文档缺失或太简略，Spec review 就没法判断。先确认/to-spec的输出存在且完整。
6. 把 Agent 放进工程纪律里
这套 skills 用下来，最大的感受不是提示词多高级，而是它很清楚软件工程难在哪。难点从来不是让 AI 多写几行代码，而是需求怎么对齐、边界怎么切、反馈怎么变快、代码怎么在几轮迭代后还站得住。
如果你打算长期在项目里用 Claude Code 跑编码任务，建议把 Coding Plan 也配上，地址是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= 。它和 Agent Skills 配合，能把模型调用和工程流程一起固定下来，减少每次开新会话重新配环境的摩擦。
先从一个小需求走完整流程，跑通一次 TDD 循环，再逐步把/grill-with-docs、/to-spec、/to-tickets加进日常。别一上来全量铺开，流程本身也需要你适应。Agent 越强，越要给它轨道，不然它跑得越快，偏得也越快。
