Implement Spec - 用子智能体并行实现规格说明

技能概述

读取一份规格说明（spec）及其关联的 ticket 任务图，调度多个实现子智能体在各自独立的 git worktree 中并行编码，最终汇总成一个实现完整 spec 的 PR。

适用场景

1. 已有规格说明和拆解好的 tickets，需要端到端实现。 规格和 ticket 都已就绪，缺的是把它们变成代码的过程。这个技能负责建分支、建草稿 PR、按依赖顺序推进 ticket，直到整个规格实现完毕。
2. 大型改动需要跨模块并行推进。 当一份 spec 涉及多个互不阻塞的模块时，顺序实现会把时间浪费在等待上。技能会持续计算当前可开工的 ticket 集合（也就是前沿），让互不依赖的工作同时进行。
3. 需要把整个规格落成一个可评审的 PR。 所有实现子智能体的产出都会被合并子智能体汇入同一条 PR 分支，最后统一走一遍代码审查，交付物是一个完整、可读、可评审的 PR，而不是散落的一堆分支。

核心功能

1. 按任务图推进，而不是按步骤清单。 技能把 tickets 当作带阻塞关系的任务图来处理。任意时刻都存在一个"前沿"——那些所有前置依赖都已满足、可以立刻开工的 ticket。技能读取任务图后，从当前前沿取出可并行的 ticket 分派出去。
2. 实现子智能体在独立 worktree 中并发工作。 每个实现子智能体拥有自己的 git worktree 和自己的分支，互不干扰，因此可以安全地并行运行，并且尽可能放在后台执行以最大化并发度。
3. 合并子智能体收口，最后统一过代码审查。 每个实现子智能体完成后，由一个专门的合并子智能体把它的工作合入 PR 分支；合并可能释放出新的前沿，技能据此继续派发新的实现子智能体。全部 ticket 完成后，PR 分支跑一遍 /code-review，所有问题交给单个实现子智能体一次性修复，最后把 PR 标记为可评审，并清理掉全部实现子智能体的 worktree。

常见问题

只有一份 spec、没有关联的 tickets，还能用吗？

不能。这个技能的前提是规格说明已经被拆解成带阻塞关系的 tickets——它负责的是"按任务图并行实现"，不负责把 spec 拆成 ticket。如果只有 spec，请先用规划类技能把需求拆解成 ticket，再交给这个技能。

为什么每个实现子智能体都要单独开 git worktree？

因为它们是在同一时间并行改代码。共享同一个工作目录会导致互相覆盖、分支切换冲突。独立 worktree 让每个子智能体拥有干净且隔离的工作区，各自的改动先落在自己的分支上，再由合并子智能体统一汇入 PR 分支。

这个技能能被模型自动触发吗？

不能。它的定义里带有 disable-model-invocation: true，意味着只能由用户显式调用，模型不会自行判断并启动它。这是有意的设计：该技能会创建分支、拉起多个子智能体并大量消耗资源，应该由人来决定什么时候开始。

多个子智能体并行改代码会互相冲突吗？

worktree 隔离避免了工作区层面的冲突，但语义层面的冲突仍可能出现——比如两个 ticket 改到了同一个文件。技能通过任务图的阻塞关系来降低这种概率（有依赖的 ticket 不会同时开工），最终合并和代码审查阶段则是兜底。如果 ticket 拆分本身存在严重重叠，建议先调整拆分方式。