Project Plan

---
name: project-plan
description: 读取 project-prd 与 project-arch 的产出，先评审实施前架构，再按垂直切片制定实施计划并拆解标准 GitHub Issues，获得授权后发布或同步。用于实施规划、任务拆分和 Issues 管理；不替代需求定义、基于实际代码的架构复盘或业务实现。
---

# 评审架构、制定计划并拆解 Issues

流程：读取输入 → 评审架构 → 制定实施计划 → 拆解 Issues → 获得授权后发布并核验。只要求本地规划时，同样生成可以直接用作 Issue 的任务正文。

## 读取输入

- 读取 [开发流程契约](../shared/workflow-contract.md)、项目 `AGENTS.md`、`CONTEXT.md`、需求文档（含三级边界和能力地图）、复用调研、架构文档和 UI 设计引用。
- 已有项目只规划本轮增量：读取 project-prd 和 project-arch 交接的增量需求、影响分析和代码基线，不把已完成的范围重新拆成待办。
- 继承已确认的需求、术语和代决策授权，不重做需求访谈。缺少资料时先查权威入口；仍然缺失时说明影响范围，继续做不受影响的部分。没有做复用调研时记录这一缺口，不把未核查的方案当成已验证的依赖。
- 读取已有的实施计划、Issues（open 和 closed）以及实际的集成状态，保留已有的任务状态。

## 评审实施前架构

- 沿核心用户流程，对照 PRD 检查设计：需求覆盖、模块职责与依赖方向、跨模块接口与数据流、状态与错误语义、权限和非功能约束、复用兼容性、UI 交接，以及验证是否可行。按项目规模判断有没有过度设计、缺失边界或循环依赖。
- 每项发现都要引用具体的章节、需求标识或代码，说明影响、推荐的修正，以及是否阻塞。文档评审不能说成运行验证。
- 结论写入已有的架构或决策记录；没有问题时记录评审范围和“通过”结论。
- 授权范围内能确定的修正，先改需求或架构文档，再核对影响；不能在计划或 Issue 里悄悄改契约。授权解决不了的关键冲突，集中提问，受影响的部分保持草稿，不发布为可执行任务。
- 能通过实验解决的技术疑点，安排为验证任务，写明目标、成功标准以及结果会影响什么，排在依赖它的开发任务之前。
- 已有的评审仍然适用时直接复用；范围或接口有实质变化时，只补评受影响的部分。基于实际代码的复盘由 [architecture-review](../architecture-review/SKILL.md) 负责。

## 制定实施计划

按 [planning-and-task-breakdown](../agent-skills/plan/planning-and-task-breakdown/SKILL.md) 做**垂直切片**和任务大小控制（输出位置按 [参考库](../shared/reference-libraries.md) 改为本项目的计划和 Issues）。补充三条：
- **先重构**：先找能让后续任务更好做的重构，排在依赖它的任务之前（“先让改动变容易，再做容易的改动”）。
- **一个里程碑一个任务**：每个里程碑只对应一个任务（一个 Issue），里程碑本身就是一个垂直切片。一个里程碑一个会话做不完时，把它拆成多个里程碑，不在同一里程碑下挂多个任务。验证任务、前置重构和 expand–contract 的每一批也各算一个里程碑。
- **大范围机械改动**（重命名列、改共享类型）无法切成独立变绿的垂直切片时，按 expand–contract 排序：先加新形式与旧形式并存，再按影响范围分批迁移调用方（每批一个里程碑，保持 CI 通过），最后删除旧形式。

计划内容（小项目可以合并成一份简短计划）：
- **里程碑**：每一步交付什么可用能力（技术类里程碑写验证结论或迁移结果）、对应哪些需求。第一个里程碑做最小的端到端骨架。
- **任务**：标识、目标、涉及的模块、输入和产物，以及按契约“模型档位”判定的建议档位。第一个里程碑细化到可以直接执行的程度，后续里程碑先保留目标和依赖，开发过程中再细化。
- **依赖与顺序**：前置关系和可以并行的部分，不能有循环依赖。**明确标出第一个可以立即开工的任务。**不指定人员，不承诺工期。
- **验收**：可观察的完成标准和验证方式，关联到需求验收。计划中列出的命令不能标为“已执行”。

已有计划或任务系统时，只补充缺口；没有时写入 `docs/implementation-plan.md`。计划交给用户审阅，只讨论影响范围或顺序的问题，不额外设置一轮必需的批准。

## 拆解 Issues

Issue 正文模板：

```markdown
**目标**：一段话说明要实现的用户或系统行为，并关联 PRD 需求标识。

**涉及范围**：预计会改动的目录或文件，例如 `src/modules/<模块>/`、`tests/<模块>/`。超出这个范围的改动需要在 PR 或提交说明中写明理由。

**依赖**：`可立即开工` 或 `依赖 #<编号>`

**建议档位**：`强` 或 `标准` — `<一句理由>`

**参照**（可执行的 `标准` 档 Issue 必填，“待细化”的任务细化时再补）：可参照的已有文件、要遵循的接口签名、需要覆盖的边界用例。

**验收**：
- [ ] 测试：`<具体命令>`
- [ ] 构建：`<具体命令>`
- [ ] 手工验证：`<操作步骤>` → `<预期结果>`
```

- 已有项目的增量任务，标题格式为 `[v<版本>] <描述>`，版本优先采用用户指定的版本，其次采用计划中已确定的版本。
- 首个里程碑的任务写成可执行的 Issue；还不成熟的任务标为“待细化”。
- 任务描述引用需求标识和接口所在位置，可以补充本任务的验收细则，但不能定义与契约冲突的接口。

## 发布

- 用户要求了创建或同步 Issues，或授权了完整开发时，直接发布。只要求拆分任务时，只生成草稿，并询问是否发布。
- 发布前核实目标 owner/repo、身份和权限，优先用连接器或 `gh`。查询已有的 Issues，按稳定标识匹配，避免重复创建。按依赖顺序创建，拿到编号后再补上依赖链接。
- 每个 Issue 按建议档位打 `model:strong` 或 `model:standard` 标签；仓库里还没有这两个标签时先创建。“待细化”的任务也先标档位，细化时再复核档位并补写参照。
- 多行正文写入临时 UTF-8 文件，用 `--body-file` 传入，完成后删除该文件。
- 发布后在本地计划里回填编号和链接；之后任务状态以 Issues 为准，本地计划只保留里程碑和链接。

## 核验与交付

- 核对：需求是否全部覆盖、架构评审结论、任务粒度、每个里程碑恰好一个任务、依赖没有循环、每个任务是完整的垂直切片、验收命令具体可执行、每个任务都有档位和理由、可执行的 `标准` 档写明了参照。已发布的 Issues 要回读，核对仓库、正文、编号和依赖。
- 交付时给出：计划链接、评审结论位置、Issue 列表，并在答复最显眼的位置写明**首个可开工任务**、它的建议档位及开工方式（新开会话，用 `task-implement` 指定该 Issue）。
- 只请求规划时到此结束；已授权开发时交给 [task-implement](../task-implement/SKILL.md)。作为顶层任务执行时，最后执行 [task-closeout](../task-closeout/SKILL.md)。