By 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 结构建议。
验证状态：🔵 待验证