← ClaudeAtlas

prd-reviewerlisted

Use when PM 需要评审/审核需求产出物的 AI 可执行性 —— 包括 story MD 卡片(stories/ 目录)、全本 PRD,或判断"这个 story 能不能给研发了"。触发词:「评审 story」「审 story��「story review」「跑三关」「spec 自测」「干跑验证」「检查 stories 目录」「审核 PRD」「PRD 评审」「需求评审」「AI 评审需求文档」「这份需求研发能直接用吗」「standby 评审」。也适用于研发反馈"需求有歧义/AI 编码跑偏"后回查 spec 质量。不要用于:评业务方向对错(只评 AI 可执行性)、评代码实现、评原型视觉风格(用 saas-prototype-design)。
songshishuang/Skills · ★ 1 · AI & Automation · score 74
Install: claude install-skill songshishuang/Skills
# PRD Reviewer · 三关评审 ## Overview 让 AI 当评审员,系统性审核 PM 产出的需求文档(story MD / 全本 PRD)的 **AI 可执行性**。 **核心原则:歧义不是靠"读起来通顺"发现的,是靠"被迫执行"暴露的。** 不能"把 MD 丢给 AI 说帮我看看"——那样每次评审标准漂移、意见不可执行。本 skill 固化**三道递进关卡**,每关固定 prompt、固定输出格式、明确通过标准: ``` 第一关 规则审查 lint ~2 分钟/story 审「格式与可测性」(standard 7 项 / lite 5 项) 第二关 对抗评审 猜测点 ~5 分钟/story 审「歧义与自包含」 ← 精髓 第三关 干跑验证 spec test ~15 分钟/story 审「端到端可执行」(lite 免) blocker 清零才进下一关;分级关卡全过 → spec_test: passed,spec 状态 ai-passed (转 ready 还需研发 48h 走查;两套门禁不混用;正面样例必须能过自己的门禁,负样例以 bad- 前缀标识) ``` 行业依据:Anthropic 内部对 spec 的质量标准——"写完 spec 送给 Claude Code,看它能不能建出来"。第二关与第三关就是这条标准的低成本版与全真版。 **本 skill 是三关评审 prompt 的唯一真相源**;方案背景见 MaaS 仓 `docs/pm/specs/2026-06-11-story-spec-workflow.md`。 ## 何时使用 - stories/ 目录派生完成后、交研发前(`prd-writer` Stage 4 之后的标准下一步) - 单个 story 改完重审 - 全本 PRD 写完后按 DoD 体检(模式 B) - 研发反馈"AI 编码跑偏 / 需求有歧义",回查 spec 质量定位歧义点 ## 何时不用 - ❌ 业务方向评审(做不做、优先级)→ 那是业务评审会的事,评审对象是全本 HTML,人评不是 AI 评 - ❌ 评审研发写的代码 → 用 code-review - ❌ 原型视觉走查 → 人看原型,不是本 skill 范围 ## 评审对象与分级 | 对象 | 跑哪几关 | 说明 | |---|---|---| | 标准 story(`ST-XXXX-*.md`) | 三关全跑 | P0 story 第三关必跑 | | lite story(`type: lite`) | 只跑一、二关 | 小改动干跑性价比低 | | 变更重派生的 story | 重跑一、二关 | 第三关视改动幅度 | | 全本 PRD(模式 B) | 按 prd-writer DoD 做 lint | 检查核心必填 9 项 + 永远不写 2 项,输出同格式报告 | `spec_test: passed` 的语义 = **该 story 类型分级要求的全部关卡通过**(标准 = 三关,lite = 两关)——不存在"lite 永远 pending"的死锁。 ## 工作流 ### 第一关:规则审查(lint) 机械检查,把 ready 门禁翻译为逐项可判定规则。**对每个 story 用以下 prompt**(可派 subagent 并行跑多个 story): ```text 你是 story spec 的 lint 评审员。先读 frontmatter type 选择门