用途：编写产品规格（PRD），即一项长期能力的持久“做什么、为什么、如何证明”。产品规格位于切片与设计之上游，定义产品契约，供后续智能体界定变更范围、推导实现设计、验证正确性，避免臆造缺失意图。
边界：适用于持久能力、产品界面、用户/系统需求或行为族；单一有界变更应改用 /slice。不得包含实现设计、架构、代码结构、算法、存储布局或阶段计划，技术方案放入 /spec-tech 或 /design。
规范结构：标题后含八节——1 Intent（问题、价值、期望结果）、2 Scope（范围内、范围外、边界）、3 Principles（不可协商的产品/领域立场）、4 Requirements（仅框架句加 Constraints 与 Invariants 列表）、5 Success Measures、6 Behaviour、7 Verification（散文，无覆盖表）、8 Open Questions。
核心规则：功能需求（FR-）与质量需求（NF-）必须作为对等 REQ-NNN 实体，用 spec req add 创建，绝不可写成 §4 散文行；约束与不变量无实体类型，保留为 §4 散文要点。FR-/NF- 是记录在 members.toml 的可移动成员标签，正文引用应使用持久的 REQ-NNN。
结构原则：身份与扁平字段在 spec-NNN.toml，叙述在 spec-NNN.md；需求实体经 spec req add 预留后，手工在 requirement-NNN.toml 中补充一行 description 与 acceptance_criteria 数组。评审或修订前用 doctrine spec show <PRD-ref> 读取重组全文，结构编辑后运行 doctrine spec validate（预期 corpus clean）。
工作流程：判断主题是长期能力还是单一变更；提取意图、范围边界与原则；将每个机械约束行为或质量门槛提取为需求实体；区分功能与质量；定义成功度量与验收门；以产品层面描述行为；§7 用散文描述验证方法；未决事项记入 Open Questions；移除设计与实现材料。
评审缺陷：意图缺失或模糊、行为中隐藏范围扩张、需求写成散文行、§7 覆盖表或引用可移动标签、FR-/NF- 混淆、约束被误升为需求、原则不约束决策、成功度量无可观察信号、行为承诺实现设计、需求无验证路径、未决问题被假设静默回答。
输出：从零起草时产出完整规范；改进现有规范时保留用户原有标题；评审反馈按 Blocking、Material、Minor、Suggested rewrite 分组；信息缺失时不编造产品意图，改用占位符、Open Question 或明确假设。
交接：规格确定后，用 /slice 界定变更范围，用 /design 做逐变更技术设计，用 /spec-tech 做持久技术规格。产品规格始终是产品意图、需求、成功度量、行为与验证义务的事实来源。