implementation-workflow git:20261029.640ec95A

Immutable. This exact content never changes and is served at /api/v1/blob/1fe6511877ddc59b.

---
name: implementation-workflow
description: 实施编排工作流。当用户要求实现功能、修复 Bug、重构代码、补充测试、拆分开发任务、并行编码或按质量门完成开发时使用。负责评估任务、拆分依赖、调度实施子任务，并按风险选择性调用 diff-review 和两个审计技能（complexity-audit、mutation-testing）。
user-invocable: true
---

# 实施编排工作流

多模块、跨端、复杂重构或用户要求并行时，拆分可验收任务，决定依赖顺序，实施后集成、验证并按风险审计。简单配置、文档和单文件低风险修复直接处理。

## 执行流程

### 1. 理解任务

读取项目指令文件（`AGENTS.md`、`CLAUDE.md`）、需求或 Spec、相关代码与测试、构建与测试命令、当前 git 状态。

本技能独立使用，不要求先运行需求、架构或测试设计技能。输入可以是明确的用户要求、PRD、技术方案、测试用例或其任意组合；按材料实际内容判断是否足以实施，不因缺少某种文档或技能产物就停止或要求补跑流程。小任务可直接从明确需求实施。

已有设计或测试材料时，核对有效入口、代码基线、规则／契约、用户决策和适用范围；代码变更后检查材料是否仍有效。只处理本次已授权范围，不把 AI 推荐或待决定方案当成用户选择。独立上下文必须取得必要内容，不能只收到无上下文的文件名。

需求、设计及测试材料可以是 HTML 或其他格式：直接读取语义正文、表格、章节锚点和本地引用，不固定要求文件名、Markdown 或另行生成副本。浏览器仅用于需要确认的视觉信息；不能只读首屏摘要就认定完整材料已加载，折叠区的字段、错误和阻塞项也要核对。

输出简短任务理解：目标、涉及模块、约束、验收标准、暂不处理的范围。

目标项目已有 Wiki 且本次使用其知识时，读取前检查相关模块新鲜度，核对 stale、unknown 或 blocked 的来源，不将旧知识当成当前事实。项目已配置 Wiki 复核记录时沿用其命令和配置；不为没有 Wiki 的任务强建知识库。

会影响验收的关键歧义解决后再派发。

需要新增或改变业务行为、补充测试时，复用已有规则与用例；缺少用例时在本次任务内明确必要场景、预期结果与验证办法，然后编写和运行相关测试，不要求专门的测试设计文档或自动调用其他技能。简单任务用简短用例，不为流程搭建项目没有的测试设施；已有测试设计只在规则变化或发现具体缺口时补充。

处理 Bug 修复请求时，先使用可用的 `bug-debugging` 建立症状证据、根因与修复方案，并等待用户明确同意方案后才实施；不要把初始“修复 Bug”当作对未展示方案的批准。已有诊断和具体批准则直接复用，从实施继续；已批准实施中自身引入的错误，在原方案范围内继续纠正，无需逐个重新审批。该技能不可用时仍遵守这一确认点。由本工作流进入调试的，确认后返回当前编排，不递归启动新工作流。

共享边界或关键技术路线不清楚时，只澄清影响本次实施的具体问题。确有重大取舍时比较可行方案并请用户决定；已有选择或授权直接沿用。普通局部设计在任务内处理，不把缺少完整架构文档等同于不可实施，也不自动调用架构设计或扫描技能。

### 2. 评估规模与风险

按可独立验收的结果拆任务；权限、金额、状态机、公共接口等变更优先安排验证与审计。小任务直接实施，不为并行而拆分。

### 3. 拆分任务

每个子任务须能独立验收；任务卡见 `references/task-card-template.md`。

拆分原则：

- 一个任务一个可验收结果
- 同一文件只由一个并行任务负责
- 共享接口、数据模型、公共类型先确定，再并行实现使用方
- 按业务结果切分，不按目录机械切分

细节见 `references/task-decomposition.md`。

### 4. 判断并行还是串行

**只有同时满足**以下条件才并行：无未解决依赖、不修改同一文件、不共享冲突状态、各有独立验收标准、并行收益大于调度与集成成本。

无法确认是否安全时**默认串行**。

判断规则与反例见 `references/parallel-execution.md`。

### 5. 派发实施子任务

需要独立上下文时，用宿主通用子 agent 工具实际派发；无派发能力则自行执行并说明。任务卡包含目标项目绝对路径、范围、已定约束、资源路径、验收标准和验证命令。子 agent 不继承主对话；传入必要方法，并要求只完成本任务。

等待实际结果，区分完成、部分完成和失败；记录改动文件、执行的验证与未解决问题。缺失或中断不能计为完成。并发名额不足时串行派发，仍可保留独立上下文。

### 6. 集成检查

并行任务返回后，主 Agent 亲自检查：

1. 改动是否落在声明范围内
2. 是否有同文件冲突或互相覆盖
3. 公共接口、命名、错误处理是否一致
4. 是否遗漏任务之间的集成代码
5. 测试是否覆盖真实集成路径
6. 子 agent 报告的验证是否实际执行且结果可信

**子 agent 的「已完成」不等于整体已完成。**

### 7. 统一验证

按项目实际工具运行单元测试、集成测试、Lint、类型检查、构建，必要时端到端测试。

记录实际执行的命令与结果。失败优先修复，不绕过、不伪造。

开发收尾时，项目若已配置 Wiki 同步检查，按本次 diff 核对受影响知识：有变化则在授权范围更新；无需更新则保留具体原因和证据；规则冲突未解决则标记 blocked。实际复核后才保存对应快照，并运行项目的结构检查与同步检查门。索引与工作区分别核对，不用未暂存的 Wiki 或记录替代待提交版本；不为过检查自动刷新时间或批量签认。

失败归属判断：子任务内部错误 → 重新派发原实施子任务；集成冲突 → 主 Agent 修复；测试或环境问题 → 标记为环境阻塞。

发现材料过时、设计不可行或契约／数据语义必须改变时，记录依据、证据、影响及候选办法，暂停依赖该决定的任务，无关任务可继续；涉及重大取舍时请用户决定，普通实现问题在授权内处理。按授权更新实际使用的材料、决策记录、任务与验证办法后恢复，不要求返回某个特定技能或补跑上游流程。

### 8. 选择性质量审计

根据变更风险读取 `references/quality-gates.md`，选择 `diff-review`、`complexity-audit` 和 `mutation-testing`；记录跳过或降级原因。派发时传目标目录、代码基线、范围和对应技能资源的绝对路径。评审与审计只报告，修复后重新运行相关验证。

覆盖率、构建和突变工具可能共享产物；输出路径冲突时串行。工具缺失或基线不可靠时如实说明，不将未验证写成通过。

### 9. 汇总

报告包含：任务拆分与完成状态、执行方式（串行/并行）、修改内容、实际验证命令与结果、质量审计的运行/跳过/降级结论、未解决问题与环境阻塞。

## References

- `references/task-decomposition.md` —— 拆分方法、依赖识别、文件边界
- `references/parallel-execution.md` —— 并行条件、必须串行的场景、集成清单
- `references/quality-gates.md` —— 三个审计角色的调用与跳过条件
- `references/task-card-template.md` —— 子任务卡模板
- 其他技能通过宿主技能目录定位；不要假定它们位于目标项目的 `skills/` 下。