| name | 507-prd |
| description | 把当前对话、方案或 PRD 沉淀成产品需求文档（PRD）。承接对齐结果到执行的中间规格化层——把方案落成需求规格（要解决什么问题、给谁、怎么验证）。不拆 issue 工单（归 507-issue）、不做架构体检（归 507-inspect）。Use when user mentions 写 PRD, 拆 PRD, 做个 PRD, 沉淀 PRD, 形成需求文档, 把刚才整理成需求, 需求规格, 落成 PRD, to-prd, product requirements. |
产品需求文档（prd）
把讨论过的上下文沉淀成 PRD（产品需求文档）——回答要解决什么问题、给谁、怎么验证。
解决的核心问题是 misalignment（对齐失败）的后置兜底——方案问透后，如果不落成一份需求规格，直接进执行，agent 容易按自己的理解跑偏。507-prd 是对齐到执行之间的可选规格化层：轻任务可直接执行；重任务或需要留档的需求，先写 PRD 再执行。
507-prd 做的是：对话/方案 → PRD 需求规格。
覆盖什么
- 从当前对话/方案合成 PRD（不重新访谈，只综合已有信息）
- 把 grill 的对齐结论落成可留档的需求文档
- 为执行提供需求规格基准
不覆盖什么
- 执行前把方案问透 → 用
507-grill（507-prd 是对齐的下游：先问清要做什么，再写 PRD）
- 把方案拆成可领取的 GitHub issue → 用
507-issue（issue 是可领取的执行单元，PRD 是需求规格，两件事）
- 写面向人的活动、培训、合作或项目方案 → 用
507-frame
- 架构审查找重构机会 → 用
507-inspect
- 执行编排 → 不在本 skill 范围（
507-prd 产需求规格，不编排执行）
核心纪律（不可违反）
- 不空访谈：综合已经说过的内容，不重复询问用户。缺关键事实时，一次只问一个问题，并附推荐答案。
- 用项目语言：先读
doc/术语表.md 和相关 doc/决策档案/；PRD 标题和正文使用项目术语。
- 测试接缝先想清楚：写 PRD 时先想"这个功能会在哪个公开接缝验证"；优先已有接缝，必要时才提新接缝。
- 只写稳定信息：PRD 默认不塞具体文件路径和代码片段，因为很快过期。例外：原型产出的状态机、schema、reducer、类型形状等能比文字更精确地表达决策时，可截取关键片段并注明来源。
- 落点是"要做什么/为什么"，不是"怎么改"：PRD 描述需求和行为，不规定实现步骤。
PRD 模板
适用：用户说"写 PRD / 把刚才整理成需求 / 形成需求文档"。
流程：
- 读已有上下文和项目文档，理解当前代码状态。
- agent 自行设计测试接缝：优先项目已有公开接口、用户路径和测试先例；只有测试接缝会改变产品行为、权限、成本或风险取舍时，才回到
507-grill 让用户决定。
- 写 PRD。
- 做局部自检并直接修正文档，再交给下游。
## Problem Statement
从用户视角描述问题。
## Solution
从用户视角描述解决方案。
## User Stories
1. As a <actor>, I want <feature>, so that <benefit>.
2. ...
## Implementation Decisions
- 需要构建/修改哪些 module（模块）或 interface（接口）
- 技术澄清、架构选择、schema/API/交互约定
- 不写易过期的具体文件路径，除非是决策级原型片段
## Testing Decisions
- 好测试验证外部行为，不测实现细节
- 计划在哪些公开接缝测试
- 代码库里已有的相似测试先例
## Out of Scope
明确不做什么。
## Further Notes
补充说明、风险或开放问题。
产物自检
写完 PRD 后，从后续执行者和验收者的视角完整重读一次；发现问题直接修正文档，不把检查清单原样附进 PRD：
- 完整性：没有
TODO、TBD、空章节或未替换占位符；关键事实缺口没有伪装成确定需求。
- 内部一致性：Problem、Solution、User Stories、Implementation Decisions、Testing Decisions 与 Out of Scope 互不矛盾，项目术语前后一致。
- 范围：内容足以形成一个可执行目标；多个相互独立的目标已拆开，不把未来可能性塞进本次规格。
- 无歧义：每项需求只有一种合理解释；角色、触发条件、成功结果、失败结果和边界明确。
- 可验证：每项用户可见行为都能落到公开接缝或用户路径；验收不依赖内部实现细节。
若仍有会改变需求、范围或验收的关键问题，停止下游路由并回到 507-grill 对齐；不要把阻塞性未知项藏进 Further Notes 后继续执行。
和其他 skill 的边界
| skill | 分工 |
|---|
| prd | 对话/方案 → PRD 需求规格（本 skill，想清楚要做什么） |
| issue | 任务 → GitHub issue（507-prd 的可选下游；PRD 想清楚后，拆成可领取 issue） |
| grill | 把方案/改动问透（507-prd 的上游） |
| 执行入口 | 编排执行（507-prd 产需求规格，不编排执行） |
时序：对齐 → 写 PRD（可选）→ 拆 GitHub issue（可选）→ 执行。
507-prd 和 507-issue 的区别：PRD 是“想清楚要做什么”（需求规格），issue 是“把要做的事写成可领取的任务”（执行单元）。它们是两件事——PRD 给项目自己看，issue 给 GitHub 上的 AI/协作者领取。重任务两者都走（先 PRD 再拆 issue），轻任务都可以跳过直接执行。
启动姿势
当用户说"写 PRD""把刚才整理成需求""形成需求文档"时：
- 读已有上下文和
doc/术语表.md，用项目语言。
- 自行设计并写明测试接缝；把选择和依据告知用户，不要求用户替 agent 完成工程设计。
- 按 PRD 模板写需求规格。
- 完成局部自检并直接修正占位符、矛盾、范围、歧义和不可验证表述。
- 提示下一步：需要拆成可领取工单 →
507-issue；直接执行 → 交执行入口。
完成与接力
- 完成信号：需求、范围、用户行为、失败边界和测试接缝前后一致，没有需要用户决定的阻塞项。
- 产物：项目既有规格目录中的 PRD，或用户明确要求的一次性 PRD 文档。
- 候选出口：需要调查或跟踪执行时进入
507-issue；存在低成本可验证的关键假设时进入 507-prototype 并回写结论；已授权且任务足够清楚时直接实施；仍缺用户取舍时返回 507-grill。
- 边界提醒：
507-prd 写具体产品应做什么；面向人的活动、培训、合作或项目提案归 507-frame。
红线
- 不拆 issue 工单（归
507-issue）。
- 不写实现步骤（写需求和行为，实现走执行入口）。
- 不空访谈（综合已有上下文）。
- 不塞易过期的文件路径/行号（耐久优先）。
- 不在和
507-issue 的边界上抢“创建 issue”的工作。
