| name | plan-prds |
| description | Use when the user asks to establish a traceable PRD planning workflow from product links, screenshots, files, spoken requirements, current-product reconstruction, feature additions, redesigns, future requirements, or phased reconstruction-then-expansion work before document scope or count is settled in an Axhub Make client project. |
PRD 规划
把产品资料整理成可追溯的产品入口、来源清单和 PRD 计划。先守住事实边界并建立规划，不预设 PRD 数量，再按业务边界决定文档数量。
固定产物
默认产品目录直接使用 src/resources/prd/：
src/resources/prd/
├── PROJECT.md
├── SOURCES.md
├── PLAN.md
├── sources/
│ ├── web/
│ ├── images/
│ └── documents/
└── prd-<两位序号>-<module-id>.md
目录选择规则：
src/resources/prd/ 不存在或尚未归属产品时，选为产品目录，并按流程先创建或更新 SOURCES.md。- 先读取
src/resources/prd/PROJECT.md。确认是同一产品时沿用现有 PROJECT.md，不得按新项目处理；已有的已完成来源可以复用，新增或变化的来源仍须经过第 4 步采集门禁。
- 如果
src/resources/prd/ 已属于其他产品，当前新产品才创建同级目录 src/resources/<product-name>/。
<product-name> 使用小写字母、数字和连字符；不要创建 src/resources/prd/<product-name>/。
产品总入口是所选产品目录下的 PROJECT.md；默认路径为 src/resources/prd/PROJECT.md。
在相应步骤创建文档时，分别采用 assets/PROJECT.md、assets/SOURCES.md 和 assets/PLAN.md 的结构。生成后的产品文档删除模板注释。
工作流程
1. 先确认需求类型
先确认当前需求类型；用户已经明确说明时只需复述确认，不重复追问：
- 现状反推：根据已有产品、页面和资料还原 PRD。
- 新增或创作需求：从零规划产品，或为已有产品新增功能、改版、规划未来方案。
用户同时提出现状还原和新增要求时，按先后顺序拆分：先完成并确认现状反推，再进入新增或创作需求。两类内容分别登记来源、范围和 PRD 任务，新增内容不能写入现状事实。
补齐现状资料缺口仍属于现状反推。只有用户明确提出新增功能、改版或未来方案，才进入新增或创作需求阶段。
2. 索取核心资料
请用户提供现有材料：
- 口述需求、目标和已有产品信息。
- 产品链接、登录后页面或公开文档。
- 截图、设计图和图片资料。
- PDF、DOCX、PPTX、表格、文本和在线文档。
- Axure、飞书或其他专用来源。
同时检查所选产品目录是否已有 PROJECT.md、SOURCES.md、PLAN.md 和素材。只追问会改变产品定位、核心用户、范围或验收方式的问题。
3. 新增或创作需求可选发散
纯现状反推直接跳过本步骤；资料不足时补索来源或记录证据缺口，不用发散填空。
仅针对新增或创作需求，询问用户是否开启以下能力。两项独立选择，可以多选，也可以全部跳过；本步骤只记录选择，第 4 步登记后再执行：
- 互联网调研：选择后在第 4 步执行，REQUIRED SUB-SKILL: Use
china-customer-research。具体处理方式见 references/source-handlers.md。
- 需求拷问：选择后读取
references/requirements-interrogation.md 执行。
4. 采集并登记来源
读取 references/source-handlers.md，先创建或更新 SOURCES.md，再按来源类型选择工具、保存产物并统一命名。登记来源不等于完成采集，登记后立即继续采集。SOURCES.md 是采集清单、状态、覆盖边界和缺口的唯一详细来源。
每项来源使用稳定编号 src-<三位序号>，记录原始位置、访问时间、访问条件、本地路径、覆盖范围、处理状态和证据属性。证据属性只使用：
主采集完成条件按 references/source-handlers.md 执行。已登记的必需子项全部完成后才能标为 已完成；主采集完成后仍有已登记补采项时保持 部分完成，等待用户决定。
用户提供的来源默认都是必需来源，除非用户明确排除。逐项尝试全部必需来源，并完成所有当前可执行的主采集；主采集未完成时必须继续采集，不询问用户。主采集完成但存在补采项时，才向用户提供“继续补采”或“接受缺口并进入计划确认”两项选择；决定前不创建或更新 PROJECT.md 和 PLAN.md。规模超出单次执行时只报告进度，保持 处理中，不进入此选择。
所有必需来源均为 已完成，或用户接受已列补采项/真实阻塞后，才创建或更新 PROJECT.md 和 PLAN.md。真实阻塞仍需反馈原因和影响，请用户选择解除阻塞或接受缺口。只有用户明确接受后才能进入下一步，并在 SOURCES.md 的“来源缺口与冲突”表记录决定、接受或排除范围和日期。
5. 建立产品入口和计划
确认 PRD 模板
用户已指定模板时直接采用；未指定时确认一次并给出推荐：
- 轻量 PRD：
src/resources/templates/prd-template.md。
- 完善型 PRD：
src/resources/templates/prd-comprehensive-template.md。
- 用户自定义模板：用户提供的文件。
同一计划默认共用一个模板，用户明确指定时可覆盖单个任务。
通过采集门禁或取得用户接受已列补采项/真实阻塞的明确决定后，创建或更新 PROJECT.md 和 PLAN.md。PROJECT.md 只写产品定位、用户、核心场景、范围、产品事实、开放问题、PRD 目录和产品决策，不写采集过程或任务状态。
PLAN.md 按业务能力而不是页面数量拆分 PRD，并根据 PRD 数量、依赖关系和上下文规模动态分期。任务少且一个上下文可以完成时只设一期；仅因前置依赖、阶段性确认或上下文容量需要才增加阶段。采集不属于 PLAN.md 的阶段，不默认创建“现状基线”“证据补齐”或未提出的未来阶段。每项包含阶段、任务编号、功能模块、目标路径、范围、来源编号、待确认问题、依赖和状态。
状态固定为：
待确认 -> 待编写 -> 编写中 -> 待评审 -> 已完成
\-> 阻塞
不预设 PRD 数量；完成主采集或用户接受已列补采项/真实阻塞后，再按业务边界决定一篇或多篇及其分期。
6. 请用户确认
在写 PRD 前，把 PROJECT.md、SOURCES.md 和 PLAN.md 的路径或预览入口交给用户确认：
- 产品总信息和范围。
- 来源覆盖、缺口和事实分类。
- 模块拆分、分期、开放问题和输出路径。
- PRD 模板。
确认前不执行 write-prd；确认后把获批任务从 待确认 改为 待编写。
7. 分期执行
只执行状态为 待编写 的任务，开始时改为 编写中。默认使用子代理按 PLAN.md 的依赖顺序执行；每篇 PRD 都传入目标路径、来源集合和选定模板，REQUIRED SUB-SKILL: Use write-prd。
如果没有子代理，建议用户为每个阶段新开一个对话，并读取产品目录下的 PROJECT.md、SOURCES.md 和 PLAN.md。
写完改为 待评审，用户确认后改为 已完成。任务状态只更新 PLAN.md；新增、移除或重命名 PRD 时同步 PROJECT.md 的文档目录。
事实边界
现状反推
- 只把页面、交互、文案、文档和用户说明能够证明的内容写成事实。
- 不使用 Agent 自行发散、开放式互联网调研或需求拷问补齐未观察需求。
- 用户要求“按行业惯例补齐”“合理补充”或“不用确认”时也不执行。标为
合理推断 也不能把补造内容写入反推 PRD，只能记录证据缺口或向用户补索资料。
- 用户提供的链接和公开官方文档可以作为事实来源；行业惯例不能用来填补产品缺口。
- 未观察状态、后台逻辑和改进建议分别标为推断、待确认或建议，不能混入当前能力。
新增或创作需求
- 先确认产品目标、核心用户、关键场景、范围和成功标准。
- 互联网调研与需求拷问都以用户明确选择为前提。
- 外部结论记录链接、访问时间和用途。
- 候选方案只有在用户确认后才进入正式范围。
完成输出
说明：
- 产品目录和三个控制文档路径。
- 已处理来源、采集缺口和命名方式。
- PRD 数量、模块拆分和分期建议。
- 当前待确认事项。
- 下一阶段是在当前对话、子代理还是新对话执行。
