| name | prd |
| description | 产品需求全流程技能。Phase 1: 交互式 PRD 编写（用户访谈 + 代码库探索 + 深模块设计）。Phase 2: PRD 拆解为垂直切片实施规格。 |
| metadata | {"filePattern":["**/docs/prd/**/*","**/prd.md","**/docs/specs/**/*","**/docs/plans/**/*"],"bashPattern":["prd|product.requirements|需求"],"priority":9} |
PRD — 从需求到实施规格
就像记者采访一样——先深挖问题全貌，再写报道，最后把报道拆成施工工序。
When to Activate
- 用户想要定义新功能或产品需求
- 用户说"写 PRD"、"需求文档"、"feature request"
- 用户有现成 PRD 需要拆解为实施规格
- 用户说"拆 spec"、"实施规格"、"拆任务"
Workflow
Phase 1: 编写 PRD
1.1 收集问题描述
向用户询问：
- 问题是什么？ 用户遇到的痛点或需要的功能
- 初步方案？ 用户心中的解决思路（如有）
- 目标用户？ 谁会受益
不要急于深入——先拿到全貌。
1.2 探索代码库
用 Agent (Explore) 或 Grep/Glob 验证用户的断言：
- 现有相关功能的实现方式
- 受影响的模块和边界
- 当前架构约束和技术债
目的：用代码事实校准用户的描述，发现用户未提及的影响面。
1.3 Grill-Me 追问
调用 grill-me 技能，对步骤 1.1-1.2 收集到的信息进行深度追问。
追问完成后，将决策摘要作为 PRD 生成的输入。
1.4 深模块设计
识别主要模块，追求深模块设计（小接口隐藏大量复杂性）：
- 列出 3-5 个核心模块
- 每个模块：接口（输入/输出）+ 隐藏的复杂性
- 模块间的依赖关系
- Schema 变更、API 契约、架构决策
向用户展示模块设计，确认后继续。
禁止写入 PRD 的内容：
- 具体文件路径（会过时）
- 代码片段（会过时）
- 实现细节（属于 spec，不属于 PRD）
1.5 生成 PRD
使用 references/prd-template.md 模板生成 PRD。
输出方式：直接输出 PRD 文档内容，保存到 docs/prds/ 目录。
测试决策原则：只描述外部行为的验证，不描述实现细节的测试。
Phase 1 审查
Phase 2: 拆解为实施规格
就像把建筑蓝图拆成施工工序——每道工序切穿所有楼层（地基→结构→水电→装修），而不是先做完所有地基再做所有结构。
2.1 确认 PRD
确认 PRD 在上下文中：
- Phase 1 刚生成的 PRD
- 对话中直接提供的文本
- 本地文件路径
如果 PRD 不完整或模糊，建议用户先运行 Phase 1。
2.2 探索代码库
用 Agent (Explore) 理解现有架构：
- 路由结构和页面组织
- 数据模型和 Schema
- 认证/授权模式
- 第三方集成边界
- 测试基础设施
目的：找到实施的着力点和约束。
2.3 识别持久架构决策
从 PRD 和代码库中提取不会随实现变化的决策：
- 路由: 新增/修改的路由路径
- Schema: 数据模型变更（表、字段、关系）
- 数据流: 模块间的数据流向
- 认证: 权限模型变更
- 第三方边界: 外部 API/服务集成点
这些决策写入 spec，具体文件名/函数名不写。
2.4 拆分垂直切片
将功能拆为垂直切片（tracer bullets），每个切片切穿所有集成层：
切片结构: Schema → API → UI → 测试
分类：
- HITL (Human-in-the-Loop): 需要人工决策或确认的切片
- AFK (Away-from-Keyboard): 可自主完成的切片
原则：
- 每个切片可独立演示或验证
- 切片间依赖关系明确（哪个必须先完成）
- 第一个切片是最小可验证路径（tracer bullet）
- 不含具体文件名/函数名，只含持久决策
2.5 用户确认
向用户展示切片列表：
- 切片名称和范围
- HITL vs AFK 分类
- 依赖关系图（哪些可并行）
- 预估粒度是否合适
根据反馈调整切片粒度和顺序。
2.6 输出
Phase 2 审查
