当需求已经写成规格、又拆成多张有先后依赖的任务票时，implement-spec 可以让一个 Agent 协调多个实施子任务，把结果合到同一个集成分支。它需要用户主动调用，适合跨多次会话的大改动；一个会话能做完的小任务，直接用 implement 更容易检查。
本站已有的 to-spec 使用指南负责把讨论中已确定的决定写成规格；to-tickets 再把规格拆成可独立验收、标明阻塞关系的票。implement-spec 从这些现成材料开始实施，不负责重新决定需求或替你拆票。
安装和开始前的准备
在项目终端按作者 README 的方法安装，再在交互选择中至少选 implement-spec、setup-matt-pocock-skills、to-tickets、tdd 和 code-review；如果还没写规格，也选 to-spec。将 Skill 安装到你实际使用的 Claude Code 或 Codex 环境。安装入口：
npx skills@latest add mattpocock/skills
如果已使用完整的 Claude Code 插件，直接使用其中的 Skill，避免把同一套文件再装一份。首次在项目中运行 setup-matt-pocock-skills，选定 GitHub、GitLab、本地 Markdown 或自己的跟踪方式；它会记录票据在哪里、如何关闭。没有这份配置，implement-spec 会停下让你先配置，而不是猜测仓库使用 GitHub。
真正启动前，检查三件事：规格已经确定范围和验收方式；to-tickets 已创建票据，每张票能单独演示一个行为并写清“被哪些票阻塞”；所用 Agent 环境能并行运行子 Agent，并让它们各自在 Git worktree 工作。若票据都没有阻塞边，它们会同时进入待实施队列；共享文件或命名约定要先协调。
第一次怎么调用
例如，你已有“账户活动日志”规格和三张相关票：记录事件、提供查询、展示列表；把示例编号换成自己的真实规格链接或本地路径。打开一个新的 Agent 会话，在 Claude Code 输入：
/implement-spec #42
请按这份已确定的规格和关联票据实施。先读票据的阻塞关系与测试约定，再建立集成分支；每张可并行的票在独立工作树完成。每次合入后核对新的待实施票，最后审查整个规格的实现，并报告分支、票据状态和验证结果。
如果本地跟踪器使用文件，就把 #42 换成真实规格路径。Codex 安装为本地 Skill 时按它的调用方式使用 implement-spec，例如输入“用 implement-spec Skill 实施这份规格：<路径>”。不要把示例编号当作固定命令。开始前还应确认当前仓库工作树干净，并保留已有工作；这个 Skill 会创建分支、修改代码和更新票据。
运行时看什么
它应先建一个集成分支，然后从没有未完成前置任务的票开始派出实施子 Agent。每个子任务在自己的工作树里改代码、运行 tdd，再把集成分支最新进度合入自己的分支；完成后由合并子 Agent 把结果收回集成分支。下一轮只能启动阻塞条件已经满足的票。若所有票一开始都启动，先看阻塞边是否真的记录了依赖；若两张票会编辑同一配置、类型或文案文件，最好先把共享命名写清，必要时让其中一张依赖另一张。
所有票完成后才对整份规格运行 code-review。检查集成分支是否包含各张票的提交、相关测试是否真正执行，以及审查发现的问题是否修复。GitHub 等跟踪器可能要求 PR；使用本地 Markdown 跟踪器时，当前正式版可停在集成分支，不应凭旧版反馈断言一定会发 PR。不要把“子 Agent 报告绿色”当作唯一验收：被 git 忽略的测试夹具或本地数据库不会自动进入工作树，相关检查可能被跳过，必要时要回主检出目录复核。
常见卡点
- 找不到票据： 先运行 setup-matt-pocock-skills，确认跟踪器配置和规格/票据位置；只有规格还没票时，先运行 to-tickets。
- 任务卡在等待： 对照集成分支已合入的票，而不只看跟踪器的“阻塞中”标签；GitHub 上的阻塞状态可能要到最终 PR 合并才变化。
- 合并冲突或名字不一致： 工作树隔离不会消除共享文件冲突。给共同修改的表面加阻塞边，或事先写明字段和组件名。
- 审查反复运行： 整体审查应放在全部票合入后；如果修复一个审查发现后又启动完整大范围审查，可改为只检查该修复和受影响的行为。