mattpocock skills 怎么选？需求澄清、Bug 调试和 TDD 的分工
mattpocock skills 可以按当前卡住的环节选择：需求还没说清楚时用追问类技能，出现难以定位的错误时用 diagnosing-bugs，预期行为已经明确时用 tdd。想先判断该走哪条流程，可以使用仓库里的 ask-matt。它负责指路，具体工作交给对应技能。mattpocock 官方仓库
这套技能适合已经会用 Codex 等 Agent、希望把工程过程做得更稳定的人。一次安装很多名称并不会自动形成工作流程。先挑手头的一项需求，遇到什么问题就调用什么，效果更容易观察。
先分清是需求没定，还是实现有错
“给订单页加 CSV 导出”听起来很明确，真动手时却有不少选择：导出当前页还是全部筛选结果，时间按下单还是付款，退款怎样显示，普通成员能不能导出客户联系方式。
这些问题还没确定，直接写测试会把猜测写成规则。已有项目可以先用 grill-with-docs，把会影响结果的选择问清楚，并把项目术语和重要决定落到文档里。
给已有订单列表增加 CSV 导出。
先梳理会影响导出内容、权限和金额的业务问题。
已确定：只做手动导出，不增加邮件发送、定时任务和新报表页。
能从项目文档或现有页面查明的事项先自行确认。
把必须由我决定的问题集中列出，讨论完保存简短需求说明。
整理出的说明不必长，但要能拿来验收。例如“导出当前筛选条件下全部已付款订单，退款金额独立列出，手机号脱敏”。这句话比“用户友好的导出功能”更能约束结果。
金额不对，先用 diagnosing-bugs 找证据
如果功能已经存在，只是偶尔导出错误，任务起点就变了。先取一笔能复现的订单，核对接口原值、转换过程和 CSV 输出。是分转元发生两次，还是一笔退款被扣了两遍，修法完全不同。
diagnosing-bugs 的当前说明强调可运行的复现和逐项检验原因。你可以要求 Agent 先给出能显示错误的一条检查命令，再缩小输入，最后修复并留下回归样本。作者调试流程
日志里如果包含访问令牌或客户字段，分享给团队前先清理。保留订单编号的测试替代值、请求顺序和金额关系，通常已足够定位问题。
行为确定以后，再交给 tdd
设定一个演示规则：订单付款 1000 元，退款 200 元，导出行应分别显示付款、退款和净额 800 元。先写一个会失败的检查，再实现到通过；接着处理没有退款的订单。每一步都围绕一个清楚的行为。
当前 tdd 文档采用 red-green 的小步循环，并依赖 codebase-design 提供接口设计用语；它已经将重构阶段从该循环中移出。因此，旧资料里的 red–green–refactor 不能直接当作这个版本的执行说明。作者当前 TDD 说明
开始执行前，先确认要测试的行为与测试层级。tdd 本身是方法参考，具体的 red-green 循环需要由开发者或 implement 等执行技能推进。
对于只改一句按钮文案的小修改，没有必要强行套入一整套测试流程。金额、权限、状态转换这类可明确判断对错的行为，才值得把约束长期保留下来。
安装后看一眼实际文件
仓库提供的安装方式可以选择技能和目标 Agent：
npx skills@latest add mattpocock/skills
在交互界面选择自己使用的 Agent 和当前需要的技能。安装完核对输出路径，再打开对应 SKILL.md，看看它读什么文件、会写哪些记录、是否有依赖。只有文件存在还不够，也要确认 Agent 当前能发现它。
按仓库完整安装流程，还应选择 setup-matt-pocock-skills，并在项目里运行一次初始化，确定问题跟踪方式、标签和文档位置。已有团队文档时，先让它沿用现有入口。安装方式也要选定一种，避免同一 Agent 同时读到手动复制与插件安装的两份同名技能，后续修改一份却仍执行另一份。
不知道从哪里开始时，可以对 ask-matt 描述“导出功能已经存在，只有部分退款订单金额异常”，让它帮助选流程。它给出的顺序仍需要结合项目事实，不必把每项任务都变成一条固定流水线。ask-matt 使用说明
作者的 5 Agent Skills I Use Every Day 视频原页适合看讨论方式。准备直接动手，可以读 Codex 修分页 Bug 的完整示例；已有代码要验收，接着看 TDD 与 code-review 的区别。
如果已经把 Agent 用在日常开发中，需要续订或了解开票，可查看 ChatGPT 订阅服务。