agentsclimarketplace

Review prd

Skill songsunny00/MySkills/skills/review-prd

根据不同角色,收集或编写日常常用skill

Install
npx -y skills add songsunny00/MySkills --skill review-prd

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

以开发视角审查产品需求文档,识别需求不清晰、交互场景遗漏、逻辑冲突、异常处理缺失等问题,输出结构化 Excel 报告

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

6.1 KB, as published. Nobody here has run it

审查产品需求文档(PRD Review)

概述

以开发者视角系统性审查产品需求文档,找出在实际开发中会导致返工、歧义或遗漏的问题。支持 Wiki 导出的混合格式文档(docx、xlsx、md、图片)。

使用方式

用户调用:/review-prd <文档目录路径>

如果用户未提供路径,询问文档目录位置。

审查流程

第一步:解析文档

  1. 扫描目标目录,识别所有文档文件
  2. 运行 parse_docs.py 将 docx/xlsx 转为可读文本:
    python .claude/skills/review-prd/parse_docs.py "<文档目录路径>"
    
  3. 脚本会在目标目录下生成 _parsed/ 子目录,包含所有解析后的文本文件
  4. 对于 .md 文件,直接用 Read 工具读取
  5. 对于图片文件(png/jpg),用 Read 工具查看(多模态),理解 UI 原型和流程图

优先级:如果存在 converted_markdown/ 目录,优先读取其中的 md 文件作为主文档,docx 作为补充参考。

多版本文档处理

  • 同一文档可能存在多个日期版本(如 PRD文档1014、1016、1018、1203),只读取最新版本
  • 通过文件名中的日期后缀识别版本,取日期最大的为最新版
  • 字段规则 Excel 同理,只读取最新版本
  • parse_docs.py 的 --latest 参数可自动去重,只解析每组文档的最新版本

第二步:建立文档全景

读完所有文档后,先梳理:

  • 系统包含哪些模块/功能
  • 各模块之间的关系和数据流向
  • 核心业务流程是什么
  • 涉及哪些角色和权限
  • 哪些功能标注了"本期暂不实现"或"待讨论"(单独记录,不作为问题但需在报告中标注)

第三步:四维审查

逐模块、逐功能进行以下四个维度的审查:

维度一:需求清晰度

  • 功能描述是否有歧义,开发能否直接实现
  • 业务规则是否明确(如:字段必填/选填、长度限制、格式要求)
  • 边界条件是否定义(如:最大数量、超时时间、并发处理)
  • 状态定义是否完整(如:枚举值是否列全、状态流转图是否有)
  • 术语是否一致(同一概念是否用了不同名称)

维度二:交互场景完整性

  • 页面跳转逻辑是否完整(从哪来、到哪去)
  • 按钮操作后的反馈是否说明(成功/失败提示)
  • 操作按钮操作前是否有防呆措施(如:删除前确认弹窗提醒)
  • 表单提交的校验规则是否明确
  • 列表的排序、筛选、分页规则是否说明
  • 弹窗/抽屉的触发条件和关闭行为是否定义
  • 批量操作的场景是否覆盖(部分成功/部分失败如何处理)
  • 权限不足时的交互是否定义
  • 大数据量场景的交互是否考虑(导入/导出进度、列表性能)

维度三:逻辑一致性

  • 同一字段在不同文档/模块中的定义是否一致
  • 状态流转是否有矛盾(如:A文档说可以从X到Y,B文档说不行)
  • 业务规则在不同场景下是否冲突
  • 数据流向是否闭环(创建的数据是否有对应的查看/编辑/删除)
  • 跨模块引用的数据是否对齐

交叉校验方法(重点):

  • 将字段规则 Excel 中的字段定义(必填/选填、类型、校验规则)与 PRD 文档中的描述逐一比对
  • 检查不同送检单之间共有字段的定义是否一致
  • 检查配置中心的配置项是否与样本中心/分析中心的引用对齐
  • 检查提示语 Excel 中的提示文案与 PRD 中描述的提示是否一致

维度四:异常处理覆盖

  • 网络异常、接口超时的处理是否说明
  • 并发操作冲突的处理(如:两人同时编辑)
  • 数据不存在或已被删除时的处理
  • 权限变更后的处理(操作中途权限被收回、角色被禁用)
  • 必要的确认操作是否有(如:删除前确认)
  • 数据回滚/撤销机制是否需要
  • 会话过期时未保存数据的保护
  • 外部系统对接的异常处理(如 HIS 推送失败、重复推送)

第四步:生成报告

将所有发现的问题整理为 JSON 数组,每个问题包含:

{
  "id": 1,
  "module": "所属模块名",
  "type": "需求清晰度|交互场景完整性|逻辑一致性|异常处理覆盖",
  "severity": "高|中|低",
  "description": "问题的具体描述",
  "source": "问题出处(文档名+章节/页码)",
  "suggestion": "给产品的修改建议"
}

将 JSON 写入临时文件,然后运行:

python .claude/skills/review-prd/generate_report.py "<JSON文件路径>" "<输出Excel路径>"

默认输出路径为文档目录下的 PRD审查报告_YYYYMMDD.xlsx

严重程度定义

级别含义示例
会导致开发阻塞或返工核心流程缺失、逻辑矛盾、关键字段未定义、空章节影响开发
开发可推进但需确认边界条件不明确、交互细节缺失、术语不一致、字段规则与PRD不一致
建议优化描述可更清晰、建议补充说明、文档格式问题

审查原则

  • 站在开发者角度:每个问题都要问"如果我来实现,这里够不够清楚?"
  • 不做产品决策:只指出问题和缺失,不替产品做选择
  • 给出具体位置:每个问题都要标注出处,方便产品定位
  • 建议要可操作:建议应该具体,而不是"请补充说明"
  • 避免吹毛求疵:聚焦真正影响开发的问题,不纠结文档格式
  • 交叉比对优先:字段规则 Excel 与 PRD 的不一致是高频问题,务必逐一比对
  • 标注延期功能:对"本期暂不实现"的功能不提问题,但在报告备注中记录,避免遗漏

来源与更新

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.