菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when handling local Git CLI daily operations such as checking status or diff, staging files, creating conventional commits, restoring local changes, reverting commits, or resolving merge/rebase/cherry-pick conflicts.
Use when explaining code, answering technical questions, comparing approaches, or providing repository-grounded analysis without entering an implementation or remediation workflow.
Use when evaluating system architecture, platform design, or high-level technical structure to identify production risks, evidence gaps, and prioritized remediation without directly redesigning or implementing the system.
Use when improving internal code structure without intentionally changing externally observable behavior, such as module splits, simplification, dependency cleanup, or maintainability and performance-oriented restructuring.
Use when a PRD, feature spec, or acceptance criteria already exist and need to be turned into a concise test plan and traceable test cases with clear priorities, coverage, and execution focus.
Use when reviewing pull requests, diffs, patches, or repository files to identify merge-blocking issues, important risks, and evidence gaps without directly fixing the reviewed artifact.
| 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 是需求收敛与 PRD 评审 lane。它的职责是：把零散、模糊、实现导向或范围失控的输入，压缩成一份短而可执行、可测试、可继续交付的 PRD。
它不替代技术设计、实现计划或测试设计。它的目标不是“把文档写长”，而是让产品、研发、测试和交付方对范围、非目标和完成定义形成同一份约定。
适用于：
以下情况不要直接进入本 skill：
遇到这些情况时，优先转交：
superpowers:brainstormingskills/develop-feature/SKILL.mdskills/writing-test-cases/SKILL.mdskills/architecture-review/SKILL.mdskills/review-code/SKILL.md目标 / 范围 / 非目标 / 主要用户 / 当前输入类型 / 关键假设。PRD 草案，不得伪装成完成态。用户故事 必须写清：谁 / 要完成什么 / 为什么；不得退化为功能列表、按钮描述或实现动作。验收标准 必须是可观察、可判定的结果；不得写点击路径、接口步骤或实现提示。Align
目标 / 范围 / 非目标 / 主要用户 / 关键假设 / 输入类型用户问题 / 提议方案 / 实现提示Challenge
XY 问题、范围膨胀、标题误导、把方案当需求、把 v1 和未来态混写Open QuestionsModel
背景/问题 -> 目标 -> 非目标 -> 用户/场景 -> 用户故事 -> 范围 -> FR -> 验收标准用户故事、FR 或验收标准Compress
Decide
PRD Status = 完成态 PRDPRD Status = PRD 草案Report
PRD Status -> Open Questions / Assumptions -> PRD Body -> Risks -> Nextskills/writing-test-cases/SKILL.md默认只保留必要章节；不适用的章节直接省略。
PRD Status
完成态 PRD 或 PRD 草案Open Questions背景 / 问题目标非目标目标用户 / 关键场景用户故事 / 关键任务范围
In ScopeOut of Scope功能需求
FR-1, FR-2, ...验收标准风险 / 待定决策仅在确实影响决策或上线时加入：
关键假设 / 约束与依赖测试重点成功指标拆期发布 / 迁移说明至少检查这些点：
v1 范围是否被悄悄放大Goal -> User Story -> FR -> Acceptance 是否可追踪按需读取以下规则或相邻 skill：
rules/output-style.md
rules/deliverable-quality-gate.md
PASS / CONDITIONAL PASS / FAIL 门槛时读取skills/writing-test-cases/SKILL.md
skills/develop-feature/SKILL.md
skills/architecture-review/SKILL.md
不要把 PRD 写成技术设计文档、任务清单或测试脚本。
出现以下信号时，说明需求收敛正在退化：
对用户的交付至少应包含：
PRD StatusOpen Questions / Assumptions目标、范围、非目标用户故事 / 功能需求 / 验收标准风险 / 待定决策Next若进入完成态，Next 默认应说明：可继续使用 skills/writing-test-cases/SKILL.md 产出测试计划与测试用例。
若当前路径没有更优替代方案，应明确写出：当前路径合理，暂无更优替代建议。
用户故事、FR 或验收标准完成态 PRD 与 PRD 草案rules/output-style.md