变更实现计划

---
name: change-implementation-planning
description: 把影响分析变成一份可执行、可验收、可回滚的实现计划。用于变更立项后的方案设计与任务拆解。产出 `变更/<id>/实现计划.md` 与 `任务与进度.md`。
---

# 变更实现计划

## 何时使用

- `代码库理解与影响分析` 已完成，影响面清楚了。
- 需求中途变更，需要重排实现方案。
- 需要把一个大需求拆成可独立提交、可独立回滚的小步。

## 前置

- `变更/<id>/影响分析.md` 已存在且无"未决的高风险项"（有则先解决）。
- 已读 `.agents/rules/开发原则.md`、`架构边界.md`、`Git与PR规则.md`。
- 已读 `.agents/rules/测试规则.md`（计划里要写清怎么验证）。

## 输入

- `变更/<id>/影响分析.md`、`变更说明.md`、`产品输入/`
- `.agents/context/` 相关条目

## 步骤

1. **确认目标与验收标准**：把需求翻译成可判定的验收条件（Given/When/Then 或清单）。
2. **确认非目标**：明确这次**不做**什么，防止范围蔓延（写进计划）。
3. **设计实现方案**：给出主方案；如有必要，给 1 个备选并说明取舍。写明：
   - 涉及模块与文件；
   - 关键数据结构 / 函数签名（草案级，细节留给契约技能）；
   - 是否需要 Feature Flag。
4. **拆任务**：每个任务满足"独立可提交、独立可验证、独立可回滚"。标注：
   - 任务编号、描述、依赖关系、预估规模（S/M/L，不写具体工时）；
   - 每个任务的**验证方式**（跑什么测试 / 手工怎么验）。
5. **定义回滚策略**：本变更怎么回滚（代码回退 / Flag 关闭 / 数据回滚），写出具体操作。
6. **标出开放问题**：需要产品 / 架构 / 用户拍板的点，集中列出。
7. **写"任务与进度"看板**：状态用 `待开始 / 进行中 / 待验证 / 已完成 / 阻塞`。

## 输出

- `变更/<id>/实现计划.md`（模板：`.agents/templates/变更/实现计划.md`）
- `变更/<id>/任务与进度.md`（模板：`.agents/templates/变更/实现计划.md` 内的任务区，或独立维护）

## 检查清单

- [ ] 验收标准可判定（不是"好用""流畅"这类空话）。
- [ ] 明确写了非目标。
- [ ] 每个任务都有独立验证方式。
- [ ] 有回滚策略，且具体到可执行操作。
- [ ] 风险高或不可逆的步骤已单独标红并安排确认点。
- [ ] 计划中涉及契约变更的部分已标注"需 `API与数据契约设计`"。

## 边界与禁止

- **禁止**跳过任务拆解直接开写（大块改动不可回滚）。
- **禁止**把工时估算当成承诺；只给规模与顺序。
- **禁止**在计划阶段擅自扩大范围——超出的部分记为"后续变更"。
- 若计划中发现影响分析有误，**回到**上一个技能修正，不要带病前进。