用持久化文件创建 PRD：需求、边界情况与架构方案全程落盘…

当用户明确要求写 PRD / 产品需求文档时，用 4 个文件分阶段产出一致的 PRD 与技术设计

适用场景

解决思路

1. 先选定一个 SCOPE（简短、唯一、kebab-case 的 slug），作为所有文件名的前缀。
2. 在 docs/ 下创建四个文件：docs/{scope}-prd-notes.md（原始研究、需求、发现、架构选项）、docs/{scope}-prd-task-plan.md（PRD 创建阶段与进度）、docs/{scope}-prd.md（产品需求即 what & why）、docs/{scope}-tech.md（技术设计即 how）。
3. Step 1 初始化：用模板创建这四个文件。task-plan 模板含 Goal、Owner、Phases（7 个阶段的复选框）、Status、Progress Log（带时间戳）；notes 模板含 Raw Requirements、Constraints、Inferred Patterns 表格、Edge Cases（Auto-handled / Confirmed by User / Open Questions）、Research Findings、Architecture Options（A/B/C 各带 Pros/Cons 与 Selected）；prd 模板含 Status: DRAFT、Last updated 时间戳、Table of Contents（Problem Statement、Goals and Non-Goals、Success Criteria、Scope、Requirements、User Flows、Implementation Plan）及各章节占位；tech 模板含 Overview、Key Components、API Design、Data Flow、Implementation Details、Migration Plan。
4. Step 2 收集需求：向用户提四个核心问题——Problem（解决什么问题）、Users（谁会用）、Success（如何判断成功）、Constraints（技术/时间/预算约束），每个答案立即写入 {scope}-prd-notes.md 对应章节。
5. 收集完信息后立刻更新 {scope}-prd-task-plan.md：把 Phase 2 打勾 ✓，并把 Phase 2.5 标为 CURRENT。
6. Step 2.5 上下文感知的边界情况分析：先扫描代码库推断既有模式（删除策略、错误处理、空状态、分页），再问用户，以减少冗余提问并保持与项目一致（详细扫描命令与输出格式见 references/edge-case-analysis.md）。
7. 识别需求类型（CRUD、State Workflow、Async、Data Display、Form、File）以确定需要检查哪些边界情况。
8. 生成智能假设：代码库中已找到的模式直接沿用，不需要用户确认。
9. 只在必要时问用户：无先例、存在多个互相冲突的模式、或需要业务规则决策时才提问。
10. 把结果写入 {scope}-prd-notes.md：Inferred Patterns 表格（列：Edge Case | Source | Pattern Applied），Edge Cases 分为 Auto-handled（沿用代码库模式）与 Confirmed by User 两类。
11. Step 3 研究与分析：用 grep 搜代码库中的类似实现，例如 grep -r "keyword" packages/ --include="*.ts"；用 web search 查最佳实践，例如 "best practices for {feature}"；把发现写入 {scope}-prd-notes.md 的 Research Findings 章节。
12. Step 4 设计方案：在 {scope}-prd-notes.md 中提出 A/B/C 三个架构选项，每项写清 Pros 与 Cons，并记录 Selected: Option X 及选择原因。
13. Step 5 写 PRD：先读 {scope}-prd-notes.md 理解已收集需求、研究结论与选定的架构选项，再写 {scope}-prd.md，包含清晰的问题陈述、Goals 与 Non-Goals（显式排除项）、可衡量的成功标准（具体数字/时间）、Scope（In Scope / Out of Scope）、功能需求、非功能需求、用户流程、高层实施计划，并注明 "See {scope}-tech.md for technical design"。
14. Step 6 写技术设计：读 {scope}-prd-notes.md 中选定的架构选项，写 {scope}-tech.md，包含 Overview（技术方案概要）、Key Components（组件与职责）、API Design（签名与契约）、Data Flow（数据如何流转）、Implementation Details、Migration Plan（如适用）。
15. Step 7 验证与定稿：向用户呈现 PRD 摘要，征求反馈，纳入修改，把 Phase 7 标记完成。
16. 每个阶段结束后都要更新 {scope}-prd-task-plan.md：打勾 ✓ 并记录时间戳。
17. 遵守重要规则：思考必须落盘（不要留在记忆里，写入 {scope}-prd-notes.md）；推进前先更新 task-plan.md；决策前先读笔记；PRD 与 Tech 分开（PRD 管 what、Tech 管 how）；先记录 2-3 个带优缺点的方案而不是直接跳到结论。
18. 完成 PRD 时：把所有阶段标记完成，将状态设为 "✅ COMPLETE"，记录最终交付物。
19. 可选的文件清理：保留 {scope}-prd-notes.md 供参考（体现决策过程）；归档或删除 {scope}-prd-task-plan.md；最终产出为 {scope}-prd.md 与 {scope}-tech.md。
20. 技能完成后执行后续钩子：self-improving-agent（background，提取可复用模式并改进 PRD 质量）与 session-logger（auto，保存会话上下文）。

适用边界 · 注意事项

• 用户只说 "design solution" 或 "architecture design" 而没有提到 PRD 时，应改用 architecting-solutions 技能。