用途：执行开发工作流的第 6 阶段（Revision）。评审发现实现问题后，本技能负责派发子代理修复，然后重新运行评审，直到通过；若 3 次迭代仍未解决则升级。调用形式为：Execute revision based on review findings: $ARGUMENTS。
前置条件：.workflow/state.json 存在且 currentStage 为 "revision"；评审发现存在（作为参数传入或位于 stages.review.artifacts.findings）；工作区有实现阶段留下的未提交改动（提交发生在评审之后）。
主要流程：
- 分类评审发现：claim failure（重新派发子代理处理具体断言）、test gap（补充测试覆盖）、spec divergence（改代码或更新规格并说明理由）、ADR conflict（提交用户决策）、style/quality（直接内联修复）。
- 派发修复：需子代理的发现附带具体问题、相关规格章节、待改文件，并要求返回结构化摘要，返回后立即落盘；内联修复记入修订日志；ADR 冲突需向用户呈现四种处置：STILL VALID、NEEDS AMENDMENT、SUPERSEDED、INVALIDATED，等待用户决定。
- 处理规格更新：若发现表明规格有误，可更新规格（与代码修复同一提交）；若涉及 ADR 推理，必须升级用户，不得静默修改 ADR。
- 重跑评审：递增 stages.revision.iterations，派发 /workflows-review；通过则置 stages.revision.status 为 "completed"、currentStage 为 "compound" 并交接；未通过则对照 maxIterations（默认 3）决定循环或升级。
- 升级：达到 3 次迭代仍未解决时输出 REVISION ESCALATION，列出剩余发现与尝试结果，给出选项 A 接受现状、B 回到 Planning、C 回到 Dev-Docs、D 放弃工作流，并附推荐，等待用户决定。
状态文件需维护 revision 的 status、iterations、maxIterations、findings（含 id、category、description、status）。
操作规则：每个修复对应一个子代理（评审通过后 1 修复 = 1 提交）；修订期间不要提交；新引入的问题计入迭代预算；内联样式修复不消耗迭代；子代理摘要必须先落盘。
反模式：修复后跳过评审、未经用户批准提高 maxIterations、通过删除测试或弱化断言来“修复”、未经用户批准修改 ADR（规格可改，ADR 不可）。
限制：资料未提供具体安装命令、收费方式、支持平台或运行环境要求。