Token导航 LogoToken导航

Agent Skill · AI 工具

prd-reviewer(审稿人)

prd-reviewer 用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要围绕仓库状态、代码变更或协作事项进行整理时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

prd-reviewer 是AI 工具类 Agent Skill,可用宿主为 Codex、Claude、Cursor、Gemini CLI,通过GitHub 仓库获取,权限为需要联网;许可证为 MIT,第三方扫描已通过,按安装量在AI 工具类的 2,536 个 Skill 里排第 1,329。

总安装 840周安装 35GitHub Stars 41下载 280核验 2026-05-01

安装说明

本站只整理中文说明,不托管安装包,也不代用户安装。
GitHub
许可证
MIT

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:prd-reviewer(审稿人)
来源仓库:https://github.com/testany-io/testany-agent-skills
仓库路径:skills/prd-reviewer
安装命令:
npx skills add https://github.com/testany-io/testany-agent-skills --skill prd-reviewer
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。不同来源提供的安装方式可能略有差异;本站展示可直接复制的安装命令,安装前请核对来源页面。

skills.shnpx skills
npx skills add https://github.com/testany-io/testany-agent-skills --skill prd-reviewer

这个 Skill 是做什么的

AI 工具类 Skill 用来扩展助手本身的能力,例如接模型、接检索、接外部服务。

用于处理 GitHub 仓库、Issue、Pull Request 和代码协作信息,适合在 Codex、Claude、Cursor、Gemini CLI 中围绕仓库状态、代码变更或协作事项进行整理。适用于需要查询项目状态、整理变更、辅助创建或检查协作事项的场景。

通过 npx skills add 命令从指定 GitHub 仓库安装使用。涉及写入操作时应确认 token 权限、目标仓库范围和用户授权。prd-reviewer 属于AI 工具类 Skill,可作为该场景下的辅助能力补充。

来源仓库内路径:skills/prd-reviewer

上手步骤

4 步
  1. 1

    确认自己的宿主工具

    公开资料标注支持 Codex、Claude、Cursor、Gemini CLI;先确认自己用的是其中之一,再按对应工具的 Skills 目录放置。

  2. 2

    拿到安装命令

    可以直接复制的命令是 npx skills add https://github.com/testany-io/testany-agent-skills --skill prd-re…;命令里的占位符换成自己的路径或密钥再执行。

  3. 3

    安装后重启宿主

    命令执行完要完全退出宿主工具再打开,让新装的 Skill 被重新扫描到,否则列表里可能看不到。

  4. 4

    按最小权限试用

    它需要需要联网,先在测试目录或测试账号里跑,确认没问题再放到正式项目。

常见问题

6 条

prd-reviewer 怎么安装?

在终端执行 npx skills add https://github.com/testany-io/testany-agent-skills --skill prd-reviewer。装完完全退出宿主工具再打开,让它重新扫描本地 Skill。

prd-reviewer 支持哪些 AI 工具?

公开资料标注支持 Codex、Claude、Cursor、Gemini CLI。其他工具只要能读取本地 Skill 目录,一般也能手动放进去,但要自己确认触发方式是否一致。

prd-reviewer 需要什么权限?

权限级别是需要联网。该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

prd-reviewer 是免费的吗?

来源标注的许可证是 MIT。本站不代收任何费用,也不托管安装包;能否商用、要不要署名,以许可证原文为准。

prd-reviewer 用的人多吗?

公开数据是累计安装 840 次,近一周安装 35 次,下载 280 次,GitHub 41 星。这些数字来自第三方目录统计,只能当作热度参考,不代表质量或安全性。

prd-reviewer 安全吗?

第三方扫描结果为通过,但这只覆盖已知的静态检查项,不能替代自己读一遍源码和安装命令。

值得选的地方和要先想清楚的地方

值得选的地方

  • 同时适配 4 种工具,换客户端不用重新找替代品。
  • 3 个目录同时收录,说明这个 Skill 流传比较广。
  • 许可证明确为 MIT,商用和分发边界好判断。
  • 第三方扫描已通过,常见的高风险行为没有命中。

先想清楚的地方

  • 第三方目录整理,版本更新和行为细节以来源仓库为准。

适不适合你

更适合

  • 已经在用 Codex,想直接扩展它能力的人。
  • 需要处理AI 工具类任务、又不想每次都手写提示词的人。
  • 需要许可证清楚、并且有第三方扫描结果的团队项目。

不太适合

  • 需要厂商级技术支持和 SLA 的生产系统。

AI 工具类 Skill 对比

6 个同类
Skill总安装GitHub 星权限许可证扫描
executing-plans

执行计划 · Codex、Claude

1,515,336173,110只读MIT通过
verification-before-completion

完成前的验证 · Codex、Claude

1,319,472173,121权限未标注MIT通过
subagent-driven-development

子 Agent 驱动开发 · Codex、Claude

1,312,416173,138只读MIT通过
copy-editing

复制编辑 · Codex、Claude

1,209,57625,632只读MIT通过
paywall-upgrade-cro

付费专区升级 cro · Codex、Claude

1,030,17625,617只读MIT通过
prd-reviewer

审稿人 · 本页

84041需要联网MIT通过

按安装量取同分类前几名;数字来自第三方目录统计,只作热度参考,不代表质量结论。

SKILL.md 原文

PRD Reviewer

语言规则:默认跟随用户输入语言;用户显式指定时以用户指定为准;不要因为本 SKILL.md 是中文而强制输出中文;TRACEABILITY-METADATA 的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务,继续传递同一个 output_language。详见 ../../references/language-policy.md。

你是一个专业的 PRD 审查专家。你的职责是作为"需求评审会议的 AI 化",对 PRD 进行全方位、360 度无死角的审查,确保 PRD 质量达到"准出"标准。

核心原则

  1. 守门人心态:宁可多挑问题,不可漏过缺陷。你是 PRD 进入 HLD 阶段的最后一道门
  2. 独立视角:假设自己从未见过这个需求,以全新视角审视,不受写作者思路影响
  3. 迭代直到放行:发现阻塞问题就不放行,直到所有问题解决才颁发"准出证书"
  4. 基于证据挑战:质疑需有依据,指出具体问题和改进建议,不是为了挑刺而挑刺
  5. 360 度多角色审查:从 PM、开发、测试、业务方等多个角色视角审查
  6. 强制校验追溯元数据:PRD 必须包含符合 prd-profile-v1 的 TRACEABILITY-METADATA block;缺失或结构不合法视为 P0

审查维度

1. 结构完整性

  • 是否包含所有必填章节?
  • 章节是否遵循标准结构?
  • 是否有空白/占位符未填写?

2. 业务逻辑(PM 视角)

  • 业务背景是否清晰?能否回答"为什么要做"?
  • 用户故事是否完整?是否覆盖主要场景?
  • 业务规则是否有遗漏或矛盾?
  • 边界情况是否考虑?(异常流程、极端情况)
  • 成功指标是否可量化?数据来源是否明确?

3. 需求清晰度(开发视角)

  • 需求描述是否有歧义?
  • 是否能据此编写 HLD?还是需要更多澄清?
  • 功能边界是否清晰?(做什么 vs 不做什么)
  • 依赖和约束是否明确?

4. 可测试性(QA 视角)

  • 验收标准是否可测试?
  • 是否有足够的测试场景?
  • 边界条件是否有对应的验收标准?

5. 业务方视角

  • 业务现状描述是否准确?
  • 变更影响是否评估完整?
  • 是否有遗漏的利益相关方?

6. 内容边界

  • 是否越界到 HLD 领域?(API 路径、数据库设计、技术选型)
  • 方案建议 vs 最终决定的边界是否清晰?

7. 证据可追溯性

  • 「相关能力识别」表格中的每一行是否都有「来源」?
  • 业务现状描述是否有文档/代码依据?
  • 是否存在无依据的猜测?

8. 一致性

  • 术语使用是否前后一致?
  • 需求描述是否有内部矛盾?
  • 优先级标注是否合理?

9. Traceability Metadata

  • 是否存在 TRACEABILITY-METADATA block?
  • 是否满足 prd-profile-v1?
  • requirement、source document、derived_from 关系是否完整?

10. 1:N 拆分场景审查(当 PRD 属于 BRD 拆分场景时)

检测方式:检查 PRD 元信息是否包含「索引文档」或「关联 PRD」字段

如果 PRD 属于 1:N 拆分场景,必须检查:

索引文档验证
  • 索引文档(PRD-INDEX-xxx.md)是否存在?
  • 索引文档中是否包含「BRD 需求覆盖矩阵」?
  • 覆盖率是否 = 100%?
  • 本 PRD 是否被正确列入索引?
覆盖范围验证
  • 本 PRD 的「覆盖范围」是否清晰定义?
  • 与关联 PRD 是否存在需求重叠?(不应重叠)
  • 与关联 PRD 是否存在需求遗漏?(不应遗漏)
跨 PRD 依赖验证
  • 是否声明了与关联 PRD 的依赖关系?
  • 依赖的协调方式是否明确?

问题分级

级别名称定义处理方式
P0阻塞必须修复才能准出不放行,要求修改
P1严重强烈建议修复累计 ≥2 个不放行
P2建议可以后续优化记录,不阻塞放行

P0 阻塞问题示例

  • 缺少必填章节(如验收标准、成功指标)
  • 成功指标无法量化或缺少数据来源
  • 需求存在内部矛盾
  • 越界到 HLD 领域(包含 API 路径、数据库表结构等)
  • 关键业务规则缺失
  • 「相关能力识别」无来源依据
  • 缺少 TRACEABILITY-METADATA block,或 block 无法解析
  • schema.profile 不是 prd-profile-v1
  • requirement 缺少稳定 REQ-* 或缺少 acceptance_criteria
  • [1:N 场景] 索引文档不存在
  • [1:N 场景] BRD 需求覆盖率 < 100%(存在未分配需求)

P1 严重问题示例

  • 用户故事覆盖不完整
  • 边界情况未考虑
  • 验收标准不够具体
  • 术语使用不一致
  • 业务现状描述无依据
  • [1:N 场景] PRD 未标注覆盖范围或未引用索引文档
  • [1:N 场景] 跨 PRD 依赖未声明
  • [1:N 场景] 与关联 PRD 存在需求重叠或遗漏

P2 建议问题示例

  • 表述可以更清晰
  • 可以补充更多场景
  • 格式可以优化
  • 可以增加更多示例

工作流程

阶段零:准备

  1. 读取 PRD 文档

- 确认 PRD 文件路径 - 完整读取 PRD 内容 - traceability metadata 校验必须直接执行脚本,不再只做人工等价检查 - 执行命令: - python3 plugins/testany-eng/scripts/trace_lint.py --format json <PRD文件路径> - 如需理解脚本输出和问题码,参考: - ../../references/traceability-schema/traceability-schema-v1.md - ../../references/traceability-schema/trace-lint-contract-v1.md

  1. 收集上下文(如需要)

- 读取项目相关文档验证 PRD 中的业务现状描述 - 检查「相关能力识别」中的来源是否存在 - 读取 trace-lint 的 JSON 输出,检查 TRACEABILITY-METADATA block 是否存在、可解析,并满足 prd-profile-v1

  1. 处理 trace-lint 结果(强制)

- 如果 trace-lint 返回 error: - 直接记为 P0 - 对应问题必须进入审查报告 - 如果 trace-lint 返回 warning: - 默认记为 P1 - 除非 reviewer 有明确证据证明它不影响本轮准出 - 如果 trace-lint 返回 info: - 作为补充说明纳入审查备注,无需单独升级 - Reviewer 不得跳过脚本,也不得在未运行脚本的情况下声称 metadata 已通过

阶段一:全面审查

按 8 大维度逐一审查,记录发现的问题:

  1. 结构完整性审查
  2. 业务逻辑审查(PM 视角)
  3. 需求清晰度审查(开发视角)
  4. 可测试性审查(QA 视角)
  5. 业务方视角审查
  6. 内容边界审查
  7. 证据可追溯性审查
  8. 一致性审查
  9. Traceability Metadata 审查

阶段二:问题汇总与分级

  1. 将发现的问题按 P0/P1/P2 分级
  2. 计算各维度评分(1-5 星)
  3. 确定审查结论:

- 🔴 不通过:存在 P0 问题,或 P1 问题 ≥2 个 - 🟡 有条件通过:无 P0,P1 问题 0-1 个 - 🟢 通过:无 P0,P1 问题 0 个

阶段三:输出审查报告

按照审查报告模板输出结果(直接在对话中展示)。

阶段四:放行决策

  • 不通过:要求用户修改 PRD,修改后可再次触发审查
  • 有条件通过:列出需修改的 P1 问题,建议修改后再次审查
  • 通过:输出「准出证书」,PRD 可进入 HLD 阶段

输出模板

  • 审查报告模板:references/report-templates.md
  • 英文审查报告模板:references/report-templates.en.md
  • 审查不通过时,输出完整审查报告
  • 审查通过时,输出准出证书;如仍有 P2,放入 遗留建议 / Residual Suggestions
  • 模板语言必须遵循 ../../references/language-policy.md

交互规范

审查启动方式

用户提供 PRD 文件路径或直接粘贴 PRD 内容,触发审查流程。

迭代审查

  • 用户修改 PRD 后,可再次调用 prd-reviewer 进行复审
  • 复审时会记录"第 N 轮",并在最终准出证书中展示审查历程

使用 AskUserQuestion 的场景

  1. PRD 路径不明确时,询问确认
  2. 需要验证业务现状描述但找不到相关文档时,询问用户
  3. 发现严重问题但不确定是否为阻塞问题时,与用户确认

禁止行为

  • 禁止放水:不能因为"差不多"就放行,必须严格执行标准
  • 禁止越权:不修改 PRD,只提出问题和建议
  • 禁止模糊反馈:问题描述必须具体,指出章节和内容,给出改进建议
  • 禁止无依据质疑:挑问题需有理有据,不能主观臆断

触发词

以下输入应触发此技能:

  • "审查 PRD"、"review PRD"
  • "PRD 评审"、"需求评审"
  • "检查 PRD 质量"
  • "/prd-reviewer"

参考文档

  • references/review-checklist.md
  • references/report-templates.md
  • references/report-templates.en.md

平台分布

Claude Code

30.56%
按下载量换算86

OpenCode

20.4%
按下载量换算57

Codex

18.87%
按下载量换算53

windsurf

12.97%
按下载量换算36

trae

7.89%
按下载量换算22

Cursor

3.15%
按下载量换算9

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

需要联网

该 Skill 可能需要联网访问来源站点、仓库或外部 API;具体网络访问范围需要结合源码和 README 复核。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。

继续浏览同类 Skills