| name | reviewing-product-requirements |
| description | Use when feature ideas, issues, stakeholder notes, or partial specs need to be reviewed and turned into a concise, testable PRD with clear scope, user stories, acceptance criteria, and explicit open decisions. |
Reviewing Product Requirements
Overview
reviewing-product-requirements 是需求收敛与 PRD 评审 lane。它的职责是：把零散、模糊、实现导向或范围失控的输入，压缩成一份短而可执行、可测试、可继续交付的 PRD。
它不替代技术设计、实现计划或测试设计。它的目标不是“把文档写长”，而是让产品、研发、测试和交付方对范围、非目标和完成定义形成同一份约定。
When to Use
适用于：
- 粗糙想法、issue、会议纪要、评论串、口头需求，需要收敛成正式需求
- 已有 PRD，但过长、偏实现、范围膨胀或验收不可测，需要纠偏与压缩
- 需要把“为什么做、给谁做、做到什么算完成”从实现细节中分离出来
- 需要暴露影响排期、范围或上线方式的待定业务决策
When Not to Use
以下情况不要直接进入本 skill：
- 需求已经稳定，当前工作是技术设计、任务拆解或实现落地
- 任务重点是写测试计划与测试用例，而不是确认需求边界
- 用户要的是架构评审、代码评审、缺陷修复或功能开发
- 当前输入过于空泛，连问题、用户或目标都无法识别，必须先澄清
遇到这些情况时，优先转交：
- 方案仍需澄清与收敛：
superpowers:brainstorming
- 功能交付：
skills/develop-feature/SKILL.md
- 测试设计：
skills/writing-test-cases/SKILL.md
- 架构评审：
skills/architecture-review/SKILL.md
- 代码评审：
skills/review-code/SKILL.md
Hard Gates
- 在产出 PRD 前，必须先对齐：
目标 / 范围 / 非目标 / 主要用户 / 当前输入类型 / 关键假设。
- 必须先定义问题，再评价方案；不得把用户提出的做法直接包装成需求本身。
- 若存在会改变范围、优先级、上线方式或测试覆盖的关键业务决策未定，结果只能标记为
PRD 草案，不得伪装成完成态。
用户故事 必须写清：谁 / 要完成什么 / 为什么；不得退化为功能列表、按钮描述或实现动作。验收标准 必须是可观察、可判定的结果；不得写点击路径、接口步骤或实现提示。- 不得把技术实现细节、架构方案、迁移脚本或测试步骤混入 PRD 主体，除非它们直接影响范围或上线决策。
- 在没有证据或明确输入支撑的情况下，不得臆造用户、业务约束、成功指标或优先级。
Operating Loop
Align
- 用 3-5 行归一化输入：
目标 / 范围 / 非目标 / 主要用户 / 关键假设 / 输入类型
- 若输入是 issue、评论或想法草稿，先区分：
用户问题 / 提议方案 / 实现提示
Challenge
- 检查是否存在
XY 问题、范围膨胀、标题误导、把方案当需求、把 v1 和未来态混写
- 会影响范围或上线的业务决策，必须提升为
Open Questions
Model
- 先建模：
背景/问题 -> 目标 -> 非目标 -> 用户/场景 -> 用户故事 -> 范围 -> FR -> 验收标准
- 每个核心目标都应能追踪到
用户故事、FR 或验收标准
- 无法验证的需求，不算完成
Compress
- 删除背景铺垫、实现猜测、重复解释和空泛路线图
- 默认保持短文档可决策，而不是扩成说明书
Decide
- 输入完整且关键决策已落定：
PRD Status = 完成态 PRD
- 仍有关键待决问题或证据缺口：
PRD Status = PRD 草案
Report
- 输出
PRD Status -> Open Questions / Assumptions -> PRD Body -> Risks -> Next
- 若进入完成态，并需要继续测试设计，显式交接到
skills/writing-test-cases/SKILL.md
Default Output Model
默认只保留必要章节；不适用的章节直接省略。
PRD Status
完成态 PRD 或 PRD 草案- 若是草案，先列
Open Questions
背景 / 问题目标非目标目标用户 / 关键场景用户故事 / 关键任务范围
功能需求
验收标准风险 / 待定决策
仅在确实影响决策或上线时加入：
关键假设 / 约束与依赖测试重点成功指标拆期发布 / 迁移说明
Quality Checks
至少检查这些点：
- 问题是否独立于方案存在
v1 范围是否被悄悄放大- 目标、用户、非目标和约束是否清楚
- 用户故事是否真实描述用户任务，而不是实现动作
Goal -> User Story -> FR -> Acceptance 是否可追踪- 验收标准是否可测试、可判定
- 关键假设是否只保留真正影响范围、优先级、上线或测试覆盖的项
- 待决业务问题是否被如实暴露，而不是藏进默认假设
Load Only What You Need
按需读取以下规则或相邻 skill：
rules/output-style.md
rules/deliverable-quality-gate.md
- 需要确认文档类交付的
PASS / CONDITIONAL PASS / FAIL 门槛时读取
skills/writing-test-cases/SKILL.md
- PRD 进入完成态后，需要继续产出测试计划与测试用例时读取
skills/develop-feature/SKILL.md
skills/architecture-review/SKILL.md
- 需求讨论已上升到系统边界、容量、可靠性或治理约束时读取
不要把 PRD 写成技术设计文档、任务清单或测试脚本。
Red Flags
出现以下信号时，说明需求收敛正在退化：
- 还没说清问题，就开始堆功能列表
- 需求标题、描述和实际目标不一致
- 把未来态、迁移、企业边角场景和 v1 混在一起
- 用户故事写成按钮操作、接口流程或实现动作
- 验收标准不可测试，只是模糊愿景
- 关键业务决策未定，却输出“完成态 PRD”
- 为了显得完整，加入大量不影响当前决策的章节
Deliverable Contract
对用户的交付至少应包含：
PRD StatusOpen Questions / Assumptions目标、范围、非目标用户故事 / 功能需求 / 验收标准风险 / 待定决策Next
若进入完成态，Next 默认应说明：可继续使用 skills/writing-test-cases/SKILL.md 产出测试计划与测试用例。
若当前路径没有更优替代方案，应明确写出：当前路径合理，暂无更优替代建议。
Exit Criteria
- 已明确问题、目标、非目标、主要用户与范围
- 核心目标可追踪到
用户故事、FR 或验收标准
- 验收标准具备可测试性
- 关键假设、约束与待决业务问题已如实暴露
- 已正确区分
完成态 PRD 与 PRD 草案
- 对外表达满足仓库内
rules/output-style.md
