remediation-planner

name	remediation-planner
description	整改计划制定 Skill。将差距报告、审核发现、或不兼容分析转化为有优先级、有验收标准的可执行整改计划。每个步骤配对验证方法，防止「计划没有验证」的情况。触发词：「基于这个分析制定整改计划」「怎么修复这些问题」「制定改进方案」「这些差距怎么补」「把发现转成行动计划」。

整改计划制定（remediation-planner）

把分析结论变成可执行、可验证的行动计划。 没有验收标准的计划不算计划。 基于 closure-orchestration-package 的 remediation-planner-verifier 本地化。

---

激活后立即执行

Step 1  读取输入
        需要：
        - 差距报告 / 审核报告 / 发现清单（来自 architecture-gap-mapper / verifier / arch-destroyer 等）
        - 约束条件（时间/资源/技术限制）
        - 现有真源文档或代码结构

Step 2  按依赖和严重度分组
        
        【P0 阻断级】不处理会导致系统无法正常运行
        【P1 重要级】影响核心功能或重大风险
        【P2 优化级】改善体验或减少技术债
        
        同时识别依赖关系：哪些问题必须先解决，才能处理其他问题

Step 3  拆解为最小安全步骤
        每个步骤必须：
        - 有明确的负责角色（哪个 Skill/Role 执行）
        - 有明确的写入范围（allowed_write_set）
        - 有明确的完成判断标准（done_criteria）
        - 不能一步改超过 3 个独立的模块

Step 4  为每个步骤配对验证方法
        每个整改步骤必须对应一个验证步骤：
        - 文档修改 → 读者能否按文档走通？
        - 代码修改 → 测试是否通过？
        - 架构调整 → gap-mapper 能否确认差距已消除？

Step 5  标注 branch 结构建议
        输出建议的 branch 划分（供 project-retrospective 参考）：
        - 哪些步骤可以并行（互不影响的独立 branch）
        - 哪些步骤必须串行（有依赖的 branch）

Step 6  输出整改计划文档
        写入：[相关目录]/remediation-plan-YYYYMMDD.md

---

输出格式

# 整改计划

**制定日期**：YYYY-MM-DD
**输入来源**：[差距报告/审核报告名称]
**约束条件**：[时间/资源/技术]

## P0 阻断级整改（必须优先处理）

### P0-01 [整改项名称]
- **问题**：[描述]
- **负责**：[Skill/Role]
- **写入范围**：[文件列表]
- **完成标准**：[可验证条件]
- **验证方法**：[如何验证已修复]
- **依赖**：[必须在此之前完成的项目]

## P1 重要级整改

[同上格式]

## P2 优化级整改

[同上格式]

## 建议 Branch 结构

并行 branch： branch-A: [P0-01 + P0-02]（无依赖关系） branch-B: [P1-01]（与A无交叉）

串行 branch： branch-C: P0-03（依赖 branch-A 完成）

## 验收总清单

所有 P0/P1 项通过验证后，整改才算完成。

---

注意事项

• 没有验证标准的步骤不写入计划：每步必须配验证方法
• 最小步骤原则：一步只做一件事，方便单独验证和回滚
• branch 边界清晰：并行的步骤不能写同一真源

---

变更记录

v1.0 — 2026-03-19 — 初始创建

根因：审核/分析类 Skill（verifier/arch-destroyer/architecture-gap-mapper）产出发现报告后，缺乏一个专门将发现转化为可执行计划的 Skill。基于外部包 remediation-planner-verifier 本地化，加入 branch 结构建议。

验证状态：🔵 待验证