build-prdlisted

# Outcome 生成一份能够安全复制到其他项目实施的产品需求包。需求包保留用户会提供什么、产品应如何响应、输出应满足什么格式与语义、哪些结果禁止出现以及如何验收；不携带旧项目内部架构、技术栈、代码组织、宿主机私有路径或模型思考过程。 ## Routing - 已有项目：只读盘点全部用户可见能力、入口、交互、命令、提示词、文件与公开契约，再把已实现行为和目标变更分别写清。 - 产品想法：从用户描述、调研与逐项决策中补全同一套需求包，不编造已有实现。 - 已有 `docs/产品需求/`：先校验并读取现有包；保留仍有效的稳定编号，冲突和行为变化必须重新确认。 - 当前会话已完成同一主题的 `shape-idea`：复用已确认结论，只补查缺失事实、强制调研和新增决策。 - 技术架构、数据库、内部 API、部署、实现任务或商业计划不属于本 Skill；不要生成替代文档。 ## Steps 1. 建立只读事实基线 - 完整读取 `workflows/§01-research.md`。 - 区分用户输入、已验证产品事实、现有公开契约、用户已确认目标和外部实践。 - 已有项目只提取外部可观察行为；不得把内部实现直接转写为需求。 2. 划分并确认功能域 - 按用户能够理解的业务能力建立功能域地图，说明每个功能域的范围、入口、角色、依赖和主要输出。 - 只对整张功能域地图确认一次；用户确认前不进入逐域访谈，也不写正式需求包。 - 小需求同样使用一个功能域，不另设简化路径。 3. 逐功能域确认并保存过程检查点 - 完整读取 `workflows/§02-domain-confirmation.md`。 - 每次只处理一个功能域，每次只询问一个会改变用户输入、产品行为、输出、文案、边界或验收结果的问题；给出基于事实与调研的推荐答案。 - 一个功能域的总结得到用户确认后，才写入 `.build-goals/build-prd/` 的过程检查点，并用 `scripts/validate_checkpoint.py --strict` 校验，然后自动进入下一个功能域；不按问题数量或上下文长度强制切段。 - 过程检查点只用于续接 `build-prd`，不是正式需求包，不能实施；`vibe-coding` 不得读取它。 4. 完成跨域确认并生成正式需求包 - 完整读取 `workflows/§03-authoring.md`、`rules/prd-quality-standard.md` 和所需模板。 - 全部功能域完成后，核对跨域旅程、共享规则、依赖、公开契约与冲突；只询问新增的跨域决策。 - 用户确认最终总结后，一次性生成或更新 `docs/产品需求/`。只有完整包，或范围、外部依赖和验收条件都已明确且已确认的正式阶段包，才能标记为 `status=confirmed`。 5. 验证并交付 - 完整读取 `workflows/§04-validation.md` 和 `checklists/semantic-acceptance.md`。 - 使用当前 Skill 的 `scripts/validate_prd.py` 严格校验整个需求包；失败时修复并重跑。 - 对比写入范围，确保没有修改来源项目代码、配置、数据或外部状态。 ## Delivery 正式产物固定为： ```text docs/产品需求/ ├── PRD需求文档.md ├── 需求包清单