implement-spec

用途\nimplement-spec 用于把 /to-spec 与 /to-tickets 生成的规格说明和工单转化为可运行的代码。核心做法是把整份规格放在一个集成分支上实现，并将工单之间的阻塞关系视为依赖图，由一名协调者统一负责合并、维护项目规范产物和追踪器更新。\n\n主要能力\n- 读取并复用完整规格、工单、阻塞边、现有分支状态和已配置的追踪器，作为唯一事实来源。若未配置追踪器，会提示用户先运行 /setup-matt-pocock-skills；在此之前可由本地产物承载依赖图，不做外部发布。\n- 在改动代码前调用 /domain-modeling 解析项目文档，并调用 /principles 获取实现相关原则。\n- 创建或复用受控的集成分支；在获得发布授权且追踪器通过 PR 收尾或用户要求时，可在首次合并后打开草稿 PR，并标记为关闭对应规格与工单。\n- 在需要时进行一次有边界的共享探索，把笔记保存在仓库之外且所有写入者可读的位置。\n- 调用 /swarm 在宿主容量内派发就绪工单，每个写入者基于已验证的集成修订使用独立工作树；向写入者指明规格、工单、笔记与提交，并委派 /tdd、实现原则、已接受的设计决策与验收标准。写入者在报告完成前需先把集成尖端合并进自己的分支。\n- 若发现工作树基线错误，先检查并保留其改动再修复，绝不重置未知工作。\n- 逐个检查终态结果，串行合并通过的改动，只有声明中的工单或迁移阶段检查通过后才更新依赖前沿；耦合迁移可借助 /principle-migrate-callers-then-delete-legacy-apis 判断完成与后续依赖门槛。\n- 写入者提交的领域文档修改需经 /domain-modeling 调和后才能改动规范文档；沿用现有追踪器依赖图并关联执行证据，不重复建单。\n- 所有必需工单集成后，重新核对 /principles 的验证要求，运行相关的整规格检查，并在最终修订上调用一次 /review-loop，传入覆盖该产物的评审证据；修复后重新检查受影响的整规格行为。\n- 默认在获授权时交付草稿 PR，使用 /pr 并复用第二步已打开的 PR；就绪状态、工单关闭与合并保持在明确授权的项目边界内。\n- 对受管检出的工作树，在确认保留需求后使用原生归档/移除方式清理，确保所有写入者都有交代、证据留存且未删除未知工作。\n\n使用方式\n通常由智能体按上述流程自动执行：先读取规格与工单并解析依赖，再建立集成分支、派发就绪工单、串行审查合并、逐项验证，最后进行整体检查与评审并交付草稿 PR。用户需提供已生成的规格与工单，并配置追踪器或接受本地模式。\n\n适用场景\n适合已经通过 /to-spec 和 /to-tickets 完成规格拆分、希望由智能体协调多任务并行实现并保持依赖顺序与文档一致性的开发项目，尤其是涉及耦合迁移和需要执行证据追踪的工程。\n\n限制\n资料未提供具体安装命令、支持平台、性能指标或收费信息。流程依赖 /domain-modeling、/principles、/swarm、/tdd、/review-loop、/pr 等配套技能及追踪器配置；外部发布与 PR 交付需明确授权，未合并分支上的代码不会自动发布。