manage-prd-docs

Manage PRD Docs

围绕产品需求进行讨论，把已生效、未来已成型和正在实施的产品决策放在不同生命周期层，并保持单一权威来源。

自动推进需求生命周期

• 检测到用户在讨论、澄清、变更、计划、实现或完成产品需求时，立即进入本工作流，不要等待用户说“讨论需求”“落盘”或“合并 PRD”。
• 先判断需求是否成型：目标、范围、核心需求和可验证的验收标准已经明确，且不存在会改变产品或实施方向的关键未决项。
• 需求未成型时继续讨论，只询问对方向有实质影响的问题；不为低风险细节阻塞推进。
• 需求成型后立即按状态落盘：已生效的行为更新现行 PRD；未开始实施的未来需求进入 docs/plans/；已开始或本轮同时要求实现的需求进入 docs/work/。不再请求额外落盘授权。
• 只写入已经明确的当前结论；尚在比较的方案、随口设想和无法判断是否确认的内容暂不写入。
• 实现过程中持续同步 PRD 和 Todo。当本轮需求的实现、验证和必要文档全部完成时，主动收口，不等待用户再说“合并 PRD”。
• 把纯讨论或 PRD 编写任务的结束与实现完成区分开：未开始的成型需求保留在 docs/plans/；部分实现、验证失败、存在阻塞或仍有未决项时保留在 docs/work/。
• 只自动删除本轮已完成需求对应的精确工作目录。迁移或删除旧 Phase、历史 PRD 和其他非本轮临时文档前，仍取得用户明确授权。

识别文档约定

1. 定位仓库根目录，先读取适用的 AGENTS.md 和仓库级说明。
2. 默认使用根目录下的 docs/，优先遵循仓库已有的文档入口和命名约定。
3. 如果存在 docs/index.md，先按索引定位现行 PRD、未来计划、进行中需求和其他权威文档。
4. 读取相关 PRD、上下游计划、Todo、用户文档、README 和代码契约，避免建立重复或冲突的权威来源。
5. 增量修改并保留无关的人工内容。

使用三层文档

把文档分成现行、未来计划和进行中三层：

docs/
├── index.md                 # 稳定的文档类别与生命周期导航
├── PRD.md                   # 现行产品决策与跨主题边界
├── prd/                     # 按稳定产品模块拆分的现行 PRD
│   └── <topic>.md
├── plans/                   # 已成型但尚未开始的未来需求
│   └── <requirement>/
│       ├── PRD.md
│       └── prd/             # 计划 PRD 需按主题拆分时使用
│           └── <topic>.md
└── work/                    # 仅在存在进行中需求时使用
    └── <feature-name>/
        ├── PRD.md
        ├── TODO.md
        └── prd/             # 当前需求 PRD 过长时按主题拆分
            └── <topic>.md

• 不创建空目录。
• 把已经生效的行为或稳定承诺写入现行 PRD，把未开始的成型需求写入 docs/plans/，把正在实施的需求写入 docs/work/。
• 全新产品尚未形成现行能力时，未开始实施就使用 docs/plans/initial-release/，已开始实施就使用 docs/work/initial-release/，不要为了结构完整创建空的 docs/PRD.md。
• 版本对用户或产品确实有意义时，允许在 plans/ 和 work/ 使用 <requirement>-v2 等名称；完成后不把版本目录保留为永久历史档案。
• 只有能独立排期、验收、延期或取消的 v2、v3 才分开维护；仅为开发顺序服务的 Phase 留在同一进行中 PRD 和 Todo 中。
• 允许在进行中 PRD 或 Todo 内规划实施阶段，但完成后不保留阶段档案。
• 不强制创建发布文档、用户文档或其他项目特有文件；已有时维护链接和一致性。

维护现行 PRD

把 docs/PRD.md 视为产品当前有效决策的唯一入口。在根 PRD 保留产品级范围、跨模块行为、统一术语、全局边界和模块导航；把稳定产品模块的详细当前决策放在 docs/prd/<module>.md。

每个主题只保留：

## 翻译存储与人工覆盖

- 当前决策：……
- 为什么：……
- 边界 / 非目标：……
- 权威入口：链接到用户文档、README 或源码契约。