implement-spec

1. Bilingual SKILL.md

左右滑动可直接切换英文版与中文版；两种语言按段落自动对齐。英文中的蓝色虚线词语可点击查看解释。共标记 21 处。

Entry SHA-256: 7a22dd2e60b8fcece478ced9d2533582adf3520d695acd3ab715341535c9e56d

2. Why This Skill Is Clever

一句话核心机制

implement-spec 把规格说明的工单依赖建模为动态任务图：让多个实现者在独立 worktree 中并行处理当前 frontier，再通过单一集成分支串行汇流、评审并完成关闭。

触发与边界

直接来源： frontmatter 明确写有 disable-model-invocation: true，正文又假定用户已经提供 spec、关联工单与 issue tracker，因此它是由人显式启动的“整份规格实施”工作流，不是模型看到任意编码需求就应自动触发的通用实现器。

支持性上下文： agents/openai.yaml 进一步声明 allow_implicit_invocation: false；to-spec 负责把讨论固化为规格，to-tickets 负责生成带 blocking edges 的纵向切片，tdd 约束单张工单的实现循环，code-review 在集成完成后按 Standards 与 Spec 两个轴验收。这些文件说明前后游契约，但不属于本次所选原文。

解释： 此 skill 的边界是“调度和集成”。它不重新发明规格、拆票、TDD 或评审方法，而是把这些独立能力放进一个依赖感知的执行拓扑中。

信息架构与执行顺序

1. 读取 spec 与 tickets，恢复完整任务图及阻塞边。
2. 必要时先委派探索，并把研究笔记存到仓库外的共享位置，避免后续实现者重复发现事实。
3. 创建唯一集成分支；首个成果合入后，才在需要时创建可关闭 spec 和 tickets 的 draft PR。
4. 从当前 frontier 领取无阻塞工单；每张工单使用独立 worktree、独立分支和一个实现者子代理，并在局部通过 tdd 实现。
5. 实现者完成前先把集成分支最新 tip 合入自己的分支，再由 merger 子代理把成果汇回集成分支。
6. 每次合并后重新计算 frontier，持续释放新一批可并行工单。
7. 全部工单完成后，对集成分支调用 code-review，再用单一实现者集中修复全部发现，避免修复阶段再次产生多写者冲突。
8. 最后按 tracker 语义关闭工单、将 draft PR 标为 ready 或报告集成分支，并清理 worktree。

最巧妙的设计点

1. 把工单从清单升级为可调度的图

They are a **task graph** with blocking relationships

直接来源： skill 明确否定“工单就是步骤列表”，并引入 task graph。解释： 这让并发度由真实依赖决定，而不是由编号或代理数量决定；调度器只需反复寻找入边已满足的节点。

2. 用动态 frontier 连接正确性与吞吐量

there is always a **frontier** of tickets which are ready to be grabbed

直接来源： 可执行集合被命名为 frontier，且每次合并后都要判断它是否变化。解释： frontier 同时是启动条件和停止条件：只有解除阻塞的工单能启动，而没有 frontier 且仍有未完成节点时就暴露了缺失依赖或环。

3. 用 context pointers 控制多代理的信息复制

Communicate primarily through **context pointers**

直接来源： 原文要求主代理和子代理保持稀疏沟通，并指向 spec、tickets、notes 与 commits。解释： 这把持久化工件变成共享记忆，减少每次委派重复粘贴上下文导致的漂移、成本和版本不一致。

4. 探索与实现分离，但证据可以复用

save its markdown notes in a directory outside the repo

直接来源： 可选探索代理必须能保存笔记，而且所有未来子代理都可访问。解释： 探索是一次性降低不确定性的读路径，实现是多路并发的写路径；把两者分离能避免每个实现者重复研究，也避免临时笔记污染产品仓库。

5. 双向同步降低集成分支漂移

merges the integration branch tip into its own branch before reporting done

直接来源： 每个实现者在报告完成前必须吸收集成分支最新 tip，随后由 merger 再把它汇入集成分支。解释： 这构成一进一出的同步门：冲突尽量在拥有局部上下文的实现者分支上暴露，而不是把过时分支直接推给中央合并者。

6. 多写者并行，单点汇流与单点收尾

merge its work to the integration branch with a **merger subagent**

Fix all issues ... in a single **implementer subagent**

直接来源： 实现阶段允许多个后台实现者，合并由专门 merger 执行，评审修复则收敛为单一实现者。解释： 这是清晰的 single-writer seam：边缘可以并行产出，中央分支的写入和最终修复保持可序列化，降低交叉覆盖和重复修复。

防失败机制与 trade-off

源中明确的不变量： 必须已有 spec、tickets 与 tracker 配置；全部成果进入单一集成分支；工单按阻塞关系形成 task graph；实现者各用独立 worktree/branch；开始前校准基线；报告完成前吸收集成 tip；合并后重新计算 frontier；全部工单完成后才做集成级 code review；最后清理 worktree。

权衡： 独立 worktree、merger 子代理和反复同步会增加分支管理成本；高度并行只在工单切分正确、共享写热点较少时有效；集中到单一修复代理能减少冲突，却可能成为尾部延迟瓶颈；“研究笔记放仓库外”便于共享临时上下文，但若缺乏生命周期管理，可能失去审计性或在后续运行中变陈旧。

可移植性风险： Skill tool、后台 subagent、独立 worktree 和 tracker 的“关闭工作”语义依赖具体 harness；某些平台不支持通过 PR 自动关闭父 spec；reset 是潜在破坏性操作，迁移时必须确保 worktree 隔离且没有未保存的人类改动。应迁移的是 task graph、frontier、context pointer 和 single-writer integration 这些机制，而不是照搬工具名称。

可迁移原则

• 把复杂计划表达为带阻塞边的任务图，而不是假装它是一条线性步骤链。
• 只对当前 frontier 并发，并在每次状态变化后重新计算可执行集合。
• 用可访问、版本明确的上下文指针替代大段重复转述。
• 让并行工作发生在隔离分支，把中央汇流点设计成 single-writer seam。
• 把“完成”定义为同步、测试、合并、评审和清理均通过，而不是子代理口头说 done。

今日实践题

假设 A、B 可并行，C 同时依赖 A 和 B，D 只依赖 A：初始 frontier 是什么？A 合并后新 frontier 如何变化？你会把哪一条状态写进 context pointer，避免 B、C、D 各自重复读取整段历史？

Evidence note

任务图、frontier、稀疏沟通、context pointers、外部共享研究笔记、独立 worktree、集成分支同步、merger 子代理、最终 code review 与清理步骤均来自所选 implement-spec 原文；显式调用边界和前后游职责来自 agents/openai.yaml、to-spec、to-tickets、tdd 与 code-review，仅作为支持性上下文；关于动态调度、共享记忆、双向同步和 single-writer seam 的归纳属于设计解释。