{"id":"d58bc347-4293-4431-91eb-f2cd93b5b166","entityType":"agent","slug":"clawhub-kokxi-qa-requirement-review","name":"qa-requirement-review","canonicalUrl":"https://www.xpersona.co/agent/clawhub-kokxi-qa-requirement-review","canonicalPath":"/agent/clawhub-kokxi-qa-requirement-review","generatedAt":"2026-10-11T05:34:32.801Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T03:32:26.984Z","emptyReason":null},"description":"从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibility before test design starts. Skill: qa-requirement-review Owner: kokxi Summary: 从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibilit","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1.2K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-requirement-review","sourceUrl":"https://clawhub.ai/kokxi/qa-requirement-review","homepage":"https://clawhub.ai/kokxi/skills/qa-requirement-review","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/kokxi/qa-requirement-review","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/kokxi/skills/qa-requirement-review","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":61,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试"},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T03:32:26.984Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T03:32:26.984Z","emptyReason":null},"stars":null,"forks":null,"downloads":1172,"packageName":null,"latestVersion":"1.8.0","tractionLabel":"1.2K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T03:32:26.909Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T03:32:26.984Z","lastCrawledAt":"2026-10-11T03:32:26.909Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T03:32:26.909Z","lastVerifiedAt":null,"highlights":[{"version":"1.8.0","createdAt":"2026-09-29T04:27:46.322Z","changelog":"Version 1.8.0 introduces metadata restructuring for easier toolchain integration. - Skill metadata fields (version, display name, when-to-use, structure, etc.) moved to a top-level metadata section in SKILL.md. - Added English-language summary and explicit \"触发场景\" (trigger scenarios) to description for clarity. - Clarified when to load reference documents (on-demand instead of always). - Updated traceability format and minor adjustments in output structure descriptions. - Removed redundant skill-card.md file.","fileCount":5,"zipByteSize":7447},{"version":"1.7.7","createdAt":"2026-09-27T14:37:25.101Z","changelog":"1.7.7","fileCount":5,"zipByteSize":7321},{"version":"1.7.6","createdAt":"2026-09-01T12:43:38.903Z","changelog":"显示名改中文","fileCount":5,"zipByteSize":7486},{"version":"1.7.5","createdAt":"2026-08-30T15:17:03.603Z","changelog":"1.7.5: 版本号升级","fileCount":5,"zipByteSize":7333},{"version":"1.7.0","createdAt":"2026-08-16T14:32:09.780Z","changelog":"Version 1.7.0 - Removed the file skill-card.md. - Updated SKILL.md with no structural changes detected in the main content. - No new features or breaking changes introduced. - Documentation and file structure cleanup.","fileCount":5,"zipByteSize":6724},{"version":"1.6.3","createdAt":"2026-08-12T15:26:17.766Z","changelog":"- Added missing metadata fields: slug and displayName, improving discoverability. - Bumped version to 1.6.3. - Removed outdated skill-card.md for simplification. - No logic or process changes; content and specification remain the same. - Minor formatting harmonization in SKILL.md.","fileCount":5,"zipByteSize":6775},{"version":"1.6.0","createdAt":"2026-07-06T17:16:42.335Z","changelog":"- Added \"references\" section to define explicit dependencies on report and review standard templates. - Introduced traceability requirements: each report now has a unique ID and linkage to associated requirement IDs. - Added \"categories\" metadata for organizational tagging. - Included a \"depth_requirement_quantification\" section to guide review depth based on requirement complexity. - Removed the sample file skill-card.md.","fileCount":5,"zipByteSize":6818},{"version":"1.5.0","createdAt":"2026-06-29T12:34:32.390Z","changelog":"Version 1.5.0 introduces major structure & standards upgrades. - Restructured SKILL.md: 明确输入输出格式，增加 version、input_format、output_format、error_recovery_guidance 等字段，全面提升标准化和兼容性。 - 拆分详细评审标准与模板至 references/report-template.md 和 references/review-standards.md，主文档更简明，便于查阅和维护。 - 明确五维评分机制，输出格式含评分、问题清单和建议，确保评审结论可量化。 - 移除 skill-card.md，简化冗余，提升技能管理清晰度。 - 强化“任何涉及需求文档的任务都应先需求评审”理念，扩展适用场景。","fileCount":5,"zipByteSize":6564}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s170jw3s1atcj5jwhqb4r7v7eh8912kp:qa-requirement-review","setupComplexity":"low","setupSteps":["Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T05:34:32.798Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-kokxi-qa-requirement-review/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T03:32:26.984Z","emptyReason":null},"readme":"Skill: qa-requirement-review\n\nOwner: kokxi\n\nSummary: 从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibility before test design starts.\n\nTags: latest:1.8.0\n\nVersion history:\n\nv1.8.0 | 2026-09-29T04:27:46.322Z | auto\n\nVersion 1.8.0 introduces metadata restructuring for easier toolchain integration.\n\n- Skill metadata fields (version, display name, when-to-use, structure, etc.) moved to a top-level metadata section in SKILL.md.\n- Added English-language summary and explicit \"触发场景\" (trigger scenarios) to description for clarity.\n- Clarified when to load reference documents (on-demand instead of always).\n- Updated traceability format and minor adjustments in output structure descriptions.\n- Removed redundant skill-card.md file.\n\nv1.7.7 | 2026-09-27T14:37:25.101Z | user\n\n1.7.7\n\nv1.7.6 | 2026-09-01T12:43:38.903Z | user\n\n显示名改中文\n\nv1.7.5 | 2026-08-30T15:17:03.603Z | user\n\n1.7.5: 版本号升级\n\nv1.7.0 | 2026-08-16T14:32:09.780Z | auto\n\nVersion 1.7.0\n\n- Removed the file skill-card.md.\n- Updated SKILL.md with no structural changes detected in the main content.\n- No new features or breaking changes introduced.\n- Documentation and file structure cleanup.\n\nv1.6.3 | 2026-08-12T15:26:17.766Z | auto\n\n- Added missing metadata fields: slug and displayName, improving discoverability.\n- Bumped version to 1.6.3.\n- Removed outdated skill-card.md for simplification.\n- No logic or process changes; content and specification remain the same.\n- Minor formatting harmonization in SKILL.md.\n\nv1.6.0 | 2026-07-06T17:16:42.335Z | auto\n\n- Added \"references\" section to define explicit dependencies on report and review standard templates.\n- Introduced traceability requirements: each report now has a unique ID and linkage to associated requirement IDs.\n- Added \"categories\" metadata for organizational tagging.\n- Included a \"depth_requirement_quantification\" section to guide review depth based on requirement complexity.\n- Removed the sample file skill-card.md.\n\nv1.5.0 | 2026-06-29T12:34:32.390Z | auto\n\nVersion 1.5.0 introduces major structure & standards upgrades.\n\n- Restructured SKILL.md: 明确输入输出格式，增加 version、input_format、output_format、error_recovery_guidance 等字段，全面提升标准化和兼容性。\n- 拆分详细评审标准与模板至 references/report-template.md 和 references/review-standards.md，主文档更简明，便于查阅和维护。\n- 明确五维评分机制，输出格式含评分、问题清单和建议，确保评审结论可量化。\n- 移除 skill-card.md，简化冗余，提升技能管理清晰度。\n- 强化“任何涉及需求文档的任务都应先需求评审”理念，扩展适用场景。\n\nv1.4.1 | 2026-06-25T16:55:56.550Z | auto\n\n- Summary: Simplified documentation for easier understanding and streamlined usage.\n- 简化了 description，去除多余细节，使技能描述更精炼。\n- 删除了 skill-card.md，减少冗余文档。\n- 保留核心评审原则和五维结构，移除冗长操作说明和部分例子。\n- 对激活条件等关键信息无实质变动，技能功能不受影响。\n\nv1.4.0 | 2026-06-24T05:10:27.867Z | auto\n\nVersion 1.4.0\n\n- 丰富描述，支持更多需求评审场景和关键词，触发条件更加详尽（如PRD评审、需求提交测试前预审等）。\n- 新增“评审问题速查”和“严重度矩阵”，帮助快速定位典型问题及处理优先级。\n- 增加真实评审例子，便于理解和应用评审流程。\n- 扩充评审指引，新增“常见评审陷阱”，指导评审实践。\n- 移除冗余 skill-card.md 文件，聚焦核心文档内容。\n- 优化整体结构，使五大评审维度和检查清单更清晰易查。\n\nv1.3.0 | 2026-06-22T16:09:29.290Z | auto\n\n- 完善需求评审流程，系统化梳理五大评审维度（完整性、清晰性、一致性、可测试性、可实现性）。\n- 明确“需求评审不是挑刺”，聚焦需求可理解、可测试、可实现。\n- 丰富详细的检查清单与评审报告模板，覆盖功能、非功能和验收标准。\n- 增加分级问题清单（必须、建议、可选）及改进建议格式，强化结果输出。\n- 明确适用场景与关联上下游技能，支持系统化需求质控。\n\nArchive index:\n\nArchive v1.8.0: 5 files, 7447 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (1610b), SKILL.md (7248b), _meta.json (140b)\n\nFile v1.8.0:SKILL.md\n\n---\nname: qa-requirement-review\ndescription: >-\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibility before test design starts.\nlicense: MIT\nallowed-tools: Read Grep Glob WebFetch\nmetadata:\n  display-name: \"Requirement Review\"\n  version: \"1.8.0\"\n  when-to-use: \"用户说\\\"需求评审\\\"、\\\"评审需求\\\"、\\\"需求质量\\\"、\\\"PRD评审\\\"、\\\"需求检查\\\"、\\\"需求写得好不好\\\"、\\\"评审这份需求\\\"、需要评审需求文档、需求提交测试前预审时\"\n  related-skills: \"{\\\"upstream\\\":[\\\"qa-input-validation\\\",\\\"qa-critical-thinking\\\",\\\"qa-question-framework\\\"],\\\"downstream\\\":[\\\"qa-req-deconstruction\\\",\\\"qa-test-strategy-design\\\"]}\"\n  references: \"[\\\"references/report-template.md\\\",\\\"references/review-standards.md\\\"]\"\n  input-format: \"{\\\"required\\\":[{\\\"name\\\":\\\"需求描述\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"功能需求的详细描述文本\\\"}],\\\"optional\\\":[{\\\"name\\\":\\\"业务背景\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"业务目标和用户角色\\\"},{\\\"name\\\":\\\"历史缺陷\\\",\\\"type\\\":\\\"array\\\",\\\"description\\\":\\\"同类功能的历史缺陷记录\\\"}]}\"\n  output-format: \"{\\\"traceability\\\":[\\\"每份需求评审报告带唯一ID（REV-REQ-XXXX）\\\",\\\"关联需求ID：REQ-{需求模块缩写}-{序号}\\\"],\\\"structure\\\":[\\\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\\\\\"全覆盖/100%\\\\\\\"绝对化表述；缺失模块标注\\\\\\\"未覆盖+原因\\\\\\\"\\\",{\\\"review_report\\\":\\\"需求评审报告\\\"},{\\\"completeness_score\\\":\\\"完整性评分\\\"},{\\\"clarity_score\\\":\\\"清晰性评分\\\"},{\\\"consistency_issues\\\":\\\"一致性问题清单\\\"},{\\\"testability_assessment\\\":\\\"可测试性评估\\\"}]}\"\n  error-recovery-guidance: \"{\\\"on_failure\\\":\\\"识别到需求不完整时返回缺失清单，要求用户补充信息\\\",\\\"retry_behavior\\\":\\\"用户补充信息后重新执行需求评审\\\"}\"\n  categories: \"[\\\"Development\\\",\\\"Requirements\\\"]\"\n  depth-requirement: \"{\\\"reference_value\\\":\\\"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\\\",\\\"minimum\\\":\\\"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\\\"}\"\n---\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n# 需求评审专项\n\n## 核心原则\n\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\n\n## 五维评审速查\n\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\n\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\n\n| 维度 | 评分核心 | 典型问题 |\n|------|---------|---------|\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\n\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\n\n## 评审报告模板\n\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\n\n简要结构：\n```markdown\n# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议\n```\n\n## 加载时机\n\n**需要时才读，不要一上来全读**：\n\n| 什么时候读 | 读哪个 |\n|-----------|--------|\n| 拿评审报告模板填 | [`references/report-template.md`](references/report-template.md)（报告结构与填写要求） |\n| 判断某个需求问题算不算缺陷 | [`references/review-standards.md`](references/review-standards.md)（五维评审标准） |\n\n> 五维评分口径在本文；模板与逐条标准在 references，按需加载。\n\n\n---\n\n## 输出示例\n\n**评审一个PRD：用户登录功能需求**\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\n→ 一致性检查：前后描述一致✅\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\n→ 可实现性检查：技术方案可行✅\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\n\n**五维评审判定示范（pass/fail 对照）**：\n\n| 维度 | PASS 示例 | FAIL 示例 | 判定要点 |\n|------|----------|----------|---------|\n| 完整性 | \"支持用户名+密码登录、验证码、密码找回，含异常场景\" | \"用户能登录系统\"（无边界/异常/非功能） | 主流程+分支+异常+非功能是否齐 |\n| 清晰性 | \"密码错误3次锁定15分钟\" | \"密码错误多次后锁定\"（多次=？锁定多久=？） | 数量/时间/条件是否有具体值 |\n| 一致性 | 全文用\"验证码\"表述，前后一致 | 前文\"短信验证码\"后文\"图形验证码\" | 术语/规则/数据定义前后是否矛盾 |\n| 可测试性 | \"登录响应时间<2秒（P95）\" | \"响应要快\" | 指标是否可量化、可观测 |\n| 可实现性 | \"基于现有统一认证服务实现\" | \"接入自研AI人脸识别（当前无此能力）\" | 技术方案在当前栈是否可行 |\n\n## 检查清单\n\n需求评审完成后检查：\n- [ ] 评审维度是否覆盖？\n- [ ] 检查清单是否执行？\n- [ ] 问题是否识别？\n- [ ] 问题是否分类？\n- [ ] 建议是否可行？\n- [ ] 报告是否规范？\n\n## 常见评审陷阱\n\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.8.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.8.0\",\n  \"publishedAt\": 1790656066322\n}\n\nFile v1.8.0:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.8.0:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.8.0:skill-card.md\n\n## Description:\n\nReviews PRDs and requirements for completeness, clarity, consistency, testability, and feasibility before test design.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA teams, product managers, and developers use this skill to review requirements before test design, identify gaps or ambiguities, and suggest actionable revisions.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The optional companion-skill installation command is not version-pinned.\n\nMitigation: Verify its source and use a pinned or reviewed version before running it.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/kokxi/skills/qa-requirement-review)\n- [Review report template](artifact/references/report-template.md)\n- [Five-dimension review standards](artifact/references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance]\n\n**Output Format:** [Markdown requirement-review report]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Five-dimension scores, an overall decision, prioritized P0–P2 findings, traceable issue IDs, and improvement suggestions.]\n\n## Skill Version(s):\n\n1.8.0 (source: skill metadata and server-resolved release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.7: 5 files, 7321 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (1868b), SKILL.md (6684b), _meta.json (140b)\n\nFile v1.7.7:SKILL.md\n\n---\nname: qa-requirement-review\nslug: qa-requirement-review\ndisplayName: Requirement Review\nversion: 1.7.7\ndescription: >-\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。\n\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\nallowed-tools: Read Grep Glob WebFetch\nrelated_skills:\n  upstream:\n    - qa-input-validation        # 输入：输入验证结果\n    - qa-critical-thinking       # 输入：批判性思维\n    - qa-question-framework      # 输入：提问框架\n  downstream:\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\nreferences:\n  - references/report-template.md\n  - references/review-standards.md\ninput_format:\n  required:\n    - name: 需求描述\n      type: string\n      description: 功能需求的详细描述文本\n  optional:\n    - name: 业务背景\n      type: string\n      description: 业务目标和用户角色\n    - name: 历史缺陷\n      type: array\n      description: 同类功能的历史缺陷记录\noutput_format:\n  traceability:\n    - 每份需求评审报告带唯一ID（REV-REQ-XXXX）\n    - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\n  structure:\n    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\n    - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n    - review_report: 需求评审报告\n    - completeness_score: 完整性评分\n    - clarity_score: 清晰性评分\n    - consistency_issues: 一致性问题清单\n    - testability_assessment: 可测试性评估\nerror_recovery_guidance:\n  on_failure: \"识别到需求不完整时返回缺失清单，要求用户补充信息\"\n  retry_behavior: \"用户补充信息后重新执行需求评审\"\ncategories: ['Development','Requirements']\ndepth_requirement_quantification:\n  reference_value: \"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\"\n---\n# 需求评审专项\n\n## 核心原则\n\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\n\n## 五维评审速查\n\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\n\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\n\n| 维度 | 评分核心 | 典型问题 |\n|------|---------|---------|\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\n\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\n\n## 评审报告模板\n\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\n\n简要结构：\n```markdown\n# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议\n```\n\n## 输出示例\n\n**评审一个PRD：用户登录功能需求**\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\n→ 一致性检查：前后描述一致✅\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\n→ 可实现性检查：技术方案可行✅\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\n\n**五维评审判定示范（pass/fail 对照）**：\n\n| 维度 | PASS 示例 | FAIL 示例 | 判定要点 |\n|------|----------|----------|---------|\n| 完整性 | \"支持用户名+密码登录、验证码、密码找回，含异常场景\" | \"用户能登录系统\"（无边界/异常/非功能） | 主流程+分支+异常+非功能是否齐 |\n| 清晰性 | \"密码错误3次锁定15分钟\" | \"密码错误多次后锁定\"（多次=？锁定多久=？） | 数量/时间/条件是否有具体值 |\n| 一致性 | 全文用\"验证码\"表述，前后一致 | 前文\"短信验证码\"后文\"图形验证码\" | 术语/规则/数据定义前后是否矛盾 |\n| 可测试性 | \"登录响应时间<2秒（P95）\" | \"响应要快\" | 指标是否可量化、可观测 |\n| 可实现性 | \"基于现有统一认证服务实现\" | \"接入自研AI人脸识别（当前无此能力）\" | 技术方案在当前栈是否可行 |\n\n## 检查清单\n\n需求评审完成后检查：\n- [ ] 评审维度是否覆盖？\n- [ ] 检查清单是否执行？\n- [ ] 问题是否识别？\n- [ ] 问题是否分类？\n- [ ] 建议是否可行？\n- [ ] 报告是否规范？\n\n## 常见评审陷阱\n\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.7.7:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.7.7\",\n  \"publishedAt\": 1790519845101\n}\n\nFile v1.7.7:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.7.7:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.7.7:skill-card.md\n\n## Description:\n\nReviews requirement documents across completeness, clarity, consistency, testability, and feasibility, and produces a structured Chinese-language QA assessment.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, testers, and product teams use this skill to review PRDs and other requirements before test design, identify gaps and contradictions, and prioritize improvements.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may be invoked broadly before requirements-related test design, even when a full review is not needed.\n\nMitigation: Confirm the requested review scope before producing an extensive report.\n\nRisk: Chinese-language headings and templates may not suit every audience.\n\nMitigation: Confirm the intended report language and adapt or translate the final report as needed.\n\n## Reference(s):\n\n- [ClawHub skill listing](https://clawhub.ai/kokxi/skills/qa-requirement-review)\n- [Review standards](references/review-standards.md)\n- [Review report template](references/report-template.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance]\n\n**Output Format:** [Chinese-language Markdown review report with scores, prioritized findings, and recommendations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Five review dimensions; P0–P2 issue priorities; unique report identifier]\n\n## Skill Version(s):\n\n1.7.7 (source: ClawHub release metadata and skill frontmatter)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.6: 5 files, 7486 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (1808b), SKILL.md (7102b), _meta.json (140b)\n\nFile v1.7.6:SKILL.md\n\n---\r\nname: qa-requirement-review\r\nslug: qa-requirement-review\r\ndisplayName: 需求评审\r\nversion: 1.7.5\r\ndescription: >-\r\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。\r\n  本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills\r\n\r\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\r\nallowed-tools: Read Grep Glob WebFetch\r\nrelated_skills:\r\n  upstream:\r\n    - qa-input-validation        # 输入：输入验证结果\r\n    - qa-critical-thinking       # 输入：批判性思维\r\n    - qa-question-framework      # 输入：提问框架\r\n  downstream:\r\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\r\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\r\nreferences:\r\n  - references/report-template.md\r\n  - references/review-standards.md\r\ninput_format:\r\n  required:\r\n    - name: 需求描述\r\n      type: string\r\n      description: 功能需求的详细描述文本\r\n  optional:\r\n    - name: 业务背景\r\n      type: string\r\n      description: 业务目标和用户角色\r\n    - name: 历史缺陷\r\n      type: array\r\n      description: 同类功能的历史缺陷记录\r\noutput_format:\r\n  traceability:\r\n    - 每份需求评审报告带唯一ID（REV-REQ-XXXX）\r\n    - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\r\n  structure:\r\n    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\r\n    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\r\n    - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\r\n    - review_report: 需求评审报告\r\n    - completeness_score: 完整性评分\r\n    - clarity_score: 清晰性评分\r\n    - consistency_issues: 一致性问题清单\r\n    - testability_assessment: 可测试性评估\r\nerror_recovery_guidance:\r\n  on_failure: \"识别到需求不完整时返回缺失清单，要求用户补充信息\"\r\n  retry_behavior: \"用户补充信息后重新执行需求评审\"\r\ncategories: ['Development','Requirements']\r\ndepth_requirement_quantification:\r\n  reference_value: \"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\"\r\n  minimum: \"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\"\r\n---\r\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\r\n\r\n# 需求评审专项\r\n\r\n## 核心原则\r\n\r\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\r\n\r\n## 五维评审速查\r\n\r\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\r\n\r\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\r\n\r\n| 维度 | 评分核心 | 典型问题 |\r\n|------|---------|---------|\r\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\r\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\r\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\r\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\r\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\r\n\r\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\r\n\r\n## 评审报告模板\r\n\r\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\r\n\r\n简要结构：\r\n```markdown\r\n# 需求评审报告\r\n## 评审结论：[通过/有条件通过/不通过]\r\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\r\n## 问题清单\r\n### P0（必须修改）\r\n### P1（建议修改）\r\n### P2（可选修改）\r\n## 改进建议\r\n```\r\n\r\n## 输出示例\r\n\r\n**评审一个PRD：用户登录功能需求**\r\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\r\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\r\n→ 一致性检查：前后描述一致✅\r\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\r\n→ 可实现性检查：技术方案可行✅\r\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\r\n\r\n**五维评审判定示范（pass/fail 对照）**：\r\n\r\n| 维度 | PASS 示例 | FAIL 示例 | 判定要点 |\r\n|------|----------|----------|---------|\r\n| 完整性 | \"支持用户名+密码登录、验证码、密码找回，含异常场景\" | \"用户能登录系统\"（无边界/异常/非功能） | 主流程+分支+异常+非功能是否齐 |\r\n| 清晰性 | \"密码错误3次锁定15分钟\" | \"密码错误多次后锁定\"（多次=？锁定多久=？） | 数量/时间/条件是否有具体值 |\r\n| 一致性 | 全文用\"验证码\"表述，前后一致 | 前文\"短信验证码\"后文\"图形验证码\" | 术语/规则/数据定义前后是否矛盾 |\r\n| 可测试性 | \"登录响应时间<2秒（P95）\" | \"响应要快\" | 指标是否可量化、可观测 |\r\n| 可实现性 | \"基于现有统一认证服务实现\" | \"接入自研AI人脸识别（当前无此能力）\" | 技术方案在当前栈是否可行 |\r\n\r\n## 检查清单\r\n\r\n需求评审完成后检查：\r\n- [ ] 评审维度是否覆盖？\r\n- [ ] 检查清单是否执行？\r\n- [ ] 问题是否识别？\r\n- [ ] 问题是否分类？\r\n- [ ] 建议是否可行？\r\n- [ ] 报告是否规范？\r\n\r\n## 常见评审陷阱\r\n\r\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\r\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\r\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\r\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\r\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.7.6:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.7.6\",\n  \"publishedAt\": 1788266618903\n}\n\nFile v1.7.6:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.7.6:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.7.6:skill-card.md\n\n## Description:\n\nReviews requirement documents across completeness, clarity, consistency, testability, and feasibility, and produces a structured Chinese-language QA requirement-review report.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, product teams, and developers use this skill before test design to evaluate whether a PRD or requirement description is understandable, testable, consistent, complete, and feasible.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill promotes an unpinned command that installs a larger third-party QA skill suite.\n\nMitigation: Install only this skill unless the full suite is needed, and inspect or pin the exact third-party version before running the full-suite install command.\n\n## Reference(s):\n\n- [Requirement Review Report Template](references/report-template.md)\n- [Five-Dimension Requirement Review Standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [Text, Markdown, Guidance]\n\n**Output Format:** [Markdown requirement review report with score tables, issue lists, and improvement guidance.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes five-dimension scores and prioritized P0/P1/P2 findings; may request missing information when requirements are incomplete.]\n\n## Skill Version(s):\n\n1.7.6 (source: server release evidence; artifact frontmatter reports 1.7.5)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.5: 5 files, 7333 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (1881b), SKILL.md (6684b), _meta.json (140b)\n\nFile v1.7.5:SKILL.md\n\n---\nname: qa-requirement-review\nslug: qa-requirement-review\ndisplayName: Requirement Review\nversion: 1.7.5\ndescription: >-\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。\n\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\nallowed-tools: Read Grep Glob WebFetch\nrelated_skills:\n  upstream:\n    - qa-input-validation        # 输入：输入验证结果\n    - qa-critical-thinking       # 输入：批判性思维\n    - qa-question-framework      # 输入：提问框架\n  downstream:\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\nreferences:\n  - references/report-template.md\n  - references/review-standards.md\ninput_format:\n  required:\n    - name: 需求描述\n      type: string\n      description: 功能需求的详细描述文本\n  optional:\n    - name: 业务背景\n      type: string\n      description: 业务目标和用户角色\n    - name: 历史缺陷\n      type: array\n      description: 同类功能的历史缺陷记录\noutput_format:\n  traceability:\n    - 每份需求评审报告带唯一ID（REV-REQ-XXXX）\n    - 关联需求ID（TC_{需求模块缩写}_{功能缩写}_{序号}）\n  structure:\n    - 测试用例表格：固定 9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）\n    - 用例级别：P0≤20%（核心流程）/ P1≤40%（主要功能）/ P2≤30%（次要功能）/ P3≤10%（边缘场景）\n    - 覆盖率：标注口径（基于现有需求/输入文档），禁止\"全覆盖/100%\"绝对化表述；缺失模块标注\"未覆盖+原因\"\n    - review_report: 需求评审报告\n    - completeness_score: 完整性评分\n    - clarity_score: 清晰性评分\n    - consistency_issues: 一致性问题清单\n    - testability_assessment: 可测试性评估\nerror_recovery_guidance:\n  on_failure: \"识别到需求不完整时返回缺失清单，要求用户补充信息\"\n  retry_behavior: \"用户补充信息后重新执行需求评审\"\ncategories: ['Development','Requirements']\ndepth_requirement_quantification:\n  reference_value: \"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\"\n---\n# 需求评审专项\n\n## 核心原则\n\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\n\n## 五维评审速查\n\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\n\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\n\n| 维度 | 评分核心 | 典型问题 |\n|------|---------|---------|\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\n\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\n\n## 评审报告模板\n\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\n\n简要结构：\n```markdown\n# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议\n```\n\n## 输出示例\n\n**评审一个PRD：用户登录功能需求**\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\n→ 一致性检查：前后描述一致✅\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\n→ 可实现性检查：技术方案可行✅\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\n\n**五维评审判定示范（pass/fail 对照）**：\n\n| 维度 | PASS 示例 | FAIL 示例 | 判定要点 |\n|------|----------|----------|---------|\n| 完整性 | \"支持用户名+密码登录、验证码、密码找回，含异常场景\" | \"用户能登录系统\"（无边界/异常/非功能） | 主流程+分支+异常+非功能是否齐 |\n| 清晰性 | \"密码错误3次锁定15分钟\" | \"密码错误多次后锁定\"（多次=？锁定多久=？） | 数量/时间/条件是否有具体值 |\n| 一致性 | 全文用\"验证码\"表述，前后一致 | 前文\"短信验证码\"后文\"图形验证码\" | 术语/规则/数据定义前后是否矛盾 |\n| 可测试性 | \"登录响应时间<2秒（P95）\" | \"响应要快\" | 指标是否可量化、可观测 |\n| 可实现性 | \"基于现有统一认证服务实现\" | \"接入自研AI人脸识别（当前无此能力）\" | 技术方案在当前栈是否可行 |\n\n## 检查清单\n\n需求评审完成后检查：\n- [ ] 评审维度是否覆盖？\n- [ ] 检查清单是否执行？\n- [ ] 问题是否识别？\n- [ ] 问题是否分类？\n- [ ] 建议是否可行？\n- [ ] 报告是否规范？\n\n## 常见评审陷阱\n\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.7.5:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.7.5\",\n  \"publishedAt\": 1788103023603\n}\n\nFile v1.7.5:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.7.5:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.7.5:skill-card.md\n\n## Description:\n\nSystematically reviews requirement documents across completeness, clarity, consistency, testability, and feasibility, producing scored findings and improvement recommendations.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, product teams, and developers use this skill to review PRDs or requirement descriptions before test design. It identifies gaps, ambiguity, contradictions, weak acceptance criteria, and feasibility concerns, then reports prioritized fixes.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may prompt requirement-quality review whenever a testing task involves requirement documents, even when the user did not explicitly ask for a requirement review.\n\nMitigation: Install it only when that workflow is desired, or narrow the trigger wording so it activates only for explicit requirement-review requests.\n\n## Reference(s):\n\n- [Review report template](references/report-template.md)\n- [Five-dimension review standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown review report with scoring tables, prioritized issue lists, and improvement recommendations]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes traceable requirement review identifiers, five-dimension scores, P0/P1/P2 issue severity, and coverage caveats.]\n\n## Skill Version(s):\n\n1.7.5 (source: frontmatter and release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.7.0: 5 files, 6724 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (1979b), SKILL.md (5293b), _meta.json (140b)\n\nFile v1.7.0:SKILL.md\n\n---\nname: qa-requirement-review\nslug: qa-requirement-review\ndisplayName: Requirement Review\nversion: 1.7.0\ndescription: >-\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。\n\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\nallowed-tools: Read Grep Glob WebFetch\nrelated_skills:\n  upstream:\n    - qa-input-validation        # 输入：输入验证结果\n    - qa-critical-thinking       # 输入：批判性思维\n    - qa-question-framework      # 输入：提问框架\n  downstream:\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\nreferences:\n  - references/report-template.md\n  - references/review-standards.md\ninput_format:\n  required:\n    - name: 需求描述\n      type: string\n      description: 功能需求的详细描述文本\n  optional:\n    - name: 业务背景\n      type: string\n      description: 业务目标和用户角色\n    - name: 历史缺陷\n      type: array\n      description: 同类功能的历史缺陷记录\noutput_format:\n  traceability:\n    - 每份需求评审报告带唯一ID（REV-REQ-XXXX）\n    - - 关联需求ID（REQ-XXXX）\n  structure:\n    - review_report: 需求评审报告\n    - completeness_score: 完整性评分\n    - clarity_score: 清晰性评分\n    - consistency_issues: 一致性问题清单\n    - testability_assessment: 可测试性评估\nerror_recovery_guidance:\n  on_failure: \"识别到需求不完整时返回缺失清单，要求用户补充信息\"\n  retry_behavior: \"用户补充信息后重新执行需求评审\"\ncategories: ['Development','Requirements']\ndepth_requirement_quantification:\n  reference_value: \"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\"\n---\n# 需求评审专项\n\n## 核心原则\n\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\n\n## 五维评审速查\n\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\n\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\n\n| 维度 | 评分核心 | 典型问题 |\n|------|---------|---------|\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\n\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\n\n## 评审报告模板\n\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\n\n简要结构：\n```markdown\n# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议\n```\n\n## 输出示例\n\n**评审一个PRD：用户登录功能需求**\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\n→ 一致性检查：前后描述一致✅\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\n→ 可实现性检查：技术方案可行✅\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\n\n## 检查清单\n\n需求评审完成后检查：\n- [ ] 评审维度是否覆盖？\n- [ ] 检查清单是否执行？\n- [ ] 问题是否识别？\n- [ ] 问题是否分类？\n- [ ] 建议是否可行？\n- [ ] 报告是否规范？\n\n## 常见评审陷阱\n\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.7.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.7.0\",\n  \"publishedAt\": 1786890729780\n}\n\nFile v1.7.0:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.7.0:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.7.0:skill-card.md\n\n## Description:\n\nReviews requirement documents across completeness, clarity, consistency, testability, and feasibility, producing scored QA feedback before test design.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA engineers, product managers, and developers use this skill to review PRDs and requirement documents before test strategy or test case design. It identifies missing, ambiguous, inconsistent, untestable, or infeasible requirements and returns prioritized improvement guidance.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may be invoked for requirement-related testing work even when the user did not explicitly request a formal requirement review.\n\nMitigation: Use this broad routing for QA workflows that benefit from early requirement checks, or narrow activation to explicit review requests when that behavior is preferred.\n\n## Reference(s):\n\n- [qa-requirement-review Skill Page](https://clawhub.ai/kokxi/skills/qa-requirement-review)\n- [kokxi Publisher Profile](https://clawhub.ai/user/kokxi)\n- [Review Standards](references/review-standards.md)\n- [Report Template](references/report-template.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Markdown review report with five-dimension scoring, prioritized issue tables, and improvement guidance.]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes traceability-oriented report fields and severity levels for requirement issues.]\n\n## Skill Version(s):\n\n1.7.0 (source: frontmatter and server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.6.3: 5 files, 6775 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (2068b), SKILL.md (5293b), _meta.json (140b)\n\nFile v1.6.3:SKILL.md\n\n---\nname: qa-requirement-review\nslug: qa-requirement-review\ndisplayName: Requirement Review\nversion: 1.6.3\ndescription: >-\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。\n\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\nallowed-tools: Read Grep Glob WebFetch\nrelated_skills:\n  upstream:\n    - qa-input-validation        # 输入：输入验证结果\n    - qa-critical-thinking       # 输入：批判性思维\n    - qa-question-framework      # 输入：提问框架\n  downstream:\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\nreferences:\n  - references/report-template.md\n  - references/review-standards.md\ninput_format:\n  required:\n    - name: 需求描述\n      type: string\n      description: 功能需求的详细描述文本\n  optional:\n    - name: 业务背景\n      type: string\n      description: 业务目标和用户角色\n    - name: 历史缺陷\n      type: array\n      description: 同类功能的历史缺陷记录\noutput_format:\n  traceability:\n    - 每份需求评审报告带唯一ID（REV-REQ-XXXX）\n    - - 关联需求ID（REQ-XXXX）\n  structure:\n    - review_report: 需求评审报告\n    - completeness_score: 完整性评分\n    - clarity_score: 清晰性评分\n    - consistency_issues: 一致性问题清单\n    - testability_assessment: 可测试性评估\nerror_recovery_guidance:\n  on_failure: \"识别到需求不完整时返回缺失清单，要求用户补充信息\"\n  retry_behavior: \"用户补充信息后重新执行需求评审\"\ncategories: ['Development','Requirements']\ndepth_requirement_quantification:\n  reference_value: \"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\"\n  minimum: \"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\"\n---\n# 需求评审专项\n\n## 核心原则\n\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\n\n## 五维评审速查\n\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\n\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\n\n| 维度 | 评分核心 | 典型问题 |\n|------|---------|---------|\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\n\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\n\n## 评审报告模板\n\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\n\n简要结构：\n```markdown\n# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议\n```\n\n## 输出示例\n\n**评审一个PRD：用户登录功能需求**\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\n→ 一致性检查：前后描述一致✅\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\n→ 可实现性检查：技术方案可行✅\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\n\n## 检查清单\n\n需求评审完成后检查：\n- [ ] 评审维度是否覆盖？\n- [ ] 检查清单是否执行？\n- [ ] 问题是否识别？\n- [ ] 问题是否分类？\n- [ ] 建议是否可行？\n- [ ] 报告是否规范？\n\n## 常见评审陷阱\n\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.6.3:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.6.3\",\n  \"publishedAt\": 1786548377766\n}\n\nFile v1.6.3:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.6.3:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.6.3:skill-card.md\n\n## Description:\n\nReviews PRDs and requirement documents across completeness, clarity, consistency, testability, and feasibility, then produces a structured quality report with scores, issues, and improvement suggestions.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers, QA engineers, and product teams use this skill to assess requirement quality before test design or implementation. It helps identify ambiguous, conflicting, incomplete, untestable, or infeasible requirements and suggests concrete improvements.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill may be selected for a testing task when the immediate need is test design rather than requirement quality review.\n\nMitigation: Confirm the user's scope before applying the review checklist, especially when the request mentions requirements as context for testing.\n\nRisk: A structured requirement review can produce misleading recommendations if the supplied PRD or business context is incomplete.\n\nMitigation: Ask for missing requirement details, business goals, acceptance criteria, or constraints before finalizing high-priority findings.\n\n## Reference(s):\n\n- [Report template](references/report-template.md)\n- [Five-dimensional review standards](references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, guidance]\n\n**Output Format:** [Structured Markdown requirement review report]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Includes five-dimensional scores, prioritized P0-P2 issue lists, traceability IDs, and improvement suggestions.]\n\n## Skill Version(s):\n\n1.6.3 (source: frontmatter and release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v1.6.0: 5 files, 6818 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (2265b), SKILL.md (5347b), _meta.json (140b)\n\nFile v1.6.0:SKILL.md\n\n---\r\nname: qa-requirement-review\r\nversion: 1.6.0\r\ndescription: >-\r\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。\r\n\r\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\r\nallowed-tools: Read Grep Glob WebFetch\r\nrelated_skills:\r\n  upstream:\r\n    - qa-input-validation        # 输入：输入验证结果\r\n    - qa-critical-thinking       # 输入：批判性思维\r\n    - qa-question-framework      # 输入：提问框架\r\n  downstream:\r\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\r\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\r\nreferences:\r\n  - references/report-template.md\r\n  - references/review-standards.md\r\ninput_format:\r\n  required:\r\n    - name: 需求描述\r\n      type: string\r\n      description: 功能需求的详细描述文本\r\n  optional:\r\n    - name: 业务背景\r\n      type: string\r\n      description: 业务目标和用户角色\r\n    - name: 历史缺陷\r\n      type: array\r\n      description: 同类功能的历史缺陷记录\r\noutput_format:\r\n  traceability:\r\n    - 每份需求评审报告带唯一ID（REV-REQ-XXXX）\r\n    - - 关联需求ID（REQ-XXXX）\r\n  structure:\r\n    - review_report: 需求评审报告\r\n    - completeness_score: 完整性评分\r\n    - clarity_score: 清晰性评分\r\n    - consistency_issues: 一致性问题清单\r\n    - testability_assessment: 可测试性评估\r\nerror_recovery_guidance:\r\n  on_failure: \"识别到需求不完整时返回缺失清单，要求用户补充信息\"\r\n  retry_behavior: \"用户补充信息后重新执行需求评审\"\r\ncategories: ['Development','Requirements']\r\ndepth_requirement_quantification:\r\n  reference_value: \"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\"\r\n  minimum: \"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\"\r\n---\r\n# 需求评审专项\r\n\r\n## 核心原则\r\n\r\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\r\n\r\n## 五维评审速查\r\n\r\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\r\n\r\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\r\n\r\n| 维度 | 评分核心 | 典型问题 |\r\n|------|---------|---------|\r\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\r\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\r\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\r\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\r\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\r\n\r\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\r\n\r\n## 评审报告模板\r\n\r\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\r\n\r\n简要结构：\r\n```markdown\r\n# 需求评审报告\r\n## 评审结论：[通过/有条件通过/不通过]\r\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\r\n## 问题清单\r\n### P0（必须修改）\r\n### P1（建议修改）\r\n### P2（可选修改）\r\n## 改进建议\r\n```\r\n\r\n## 输出示例\r\n\r\n**评审一个PRD：用户登录功能需求**\r\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\r\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\r\n→ 一致性检查：前后描述一致✅\r\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\r\n→ 可实现性检查：技术方案可行✅\r\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\r\n\r\n## 检查清单\r\n\r\n需求评审完成后检查：\r\n- [ ] 评审维度是否覆盖？\r\n- [ ] 检查清单是否执行？\r\n- [ ] 问题是否识别？\r\n- [ ] 问题是否分类？\r\n- [ ] 建议是否可行？\r\n- [ ] 报告是否规范？\r\n\r\n## 常见评审陷阱\r\n\r\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\r\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\r\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\r\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\r\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.6.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.6.0\",\n  \"publishedAt\": 1783358202335\n}\n\nFile v1.6.0:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.6.0:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.6.0:skill-card.md\n\n## Description: <br>\nReviews requirement documents across completeness, clarity, consistency, testability, and feasibility before test design or implementation planning. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, product reviewers, and developers use this skill to review PRDs or requirement descriptions before test case design. It produces a structured review that identifies missing, ambiguous, inconsistent, hard-to-test, or infeasible requirements. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may be invoked broadly before requirement-related test design, including when a user only wants execution support or bug triage. <br>\nMitigation: Invoke it when the task involves PRD or requirement quality review; skip it for execution-only or bug-triage requests. <br>\nRisk: The skill can produce incorrect or incomplete requirement-review guidance if the source requirement description lacks context. <br>\nMitigation: Ask for missing business context, acceptance criteria, constraints, or historical defects before treating the review as final. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-requirement-review) <br>\n- [Requirement review report template](references/report-template.md) <br>\n- [Five-dimension review standards](references/review-standards.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [markdown, guidance] <br>\n**Output Format:** [Markdown requirement review report with scored dimensions, issue lists, and improvement suggestions] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Reports include traceability identifiers and classify issues by P0, P1, and P2 severity.] <br>\n\n## Skill Version(s): <br>\n1.6.0 (source: frontmatter and server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.5.0: 5 files, 6564 bytes\n\nFiles: references/report-template.md (1892b), references/review-standards.md (5241b), skill-card.md (2145b), SKILL.md (4963b), _meta.json (140b)\n\nFile v1.5.0:SKILL.md\n\n---\nname: qa-requirement-review\nversion: 1.5.0\ndescription: >-\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。\n\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\nallowed-tools: Read Grep Glob WebFetch\nrelated_skills:\n  upstream:\n    - qa-input-validation        # 输入：输入验证结果\n    - qa-critical-thinking       # 输入：批判性思维\n    - qa-question-framework      # 输入：提问框架\n  downstream:\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\ninput_format:\n  required:\n    - name: 需求描述\n      type: string\n      description: 功能需求的详细描述文本\n  optional:\n    - name: 业务背景\n      type: string\n      description: 业务目标和用户角色\n    - name: 历史缺陷\n      type: array\n      description: 同类功能的历史缺陷记录\noutput_format:\n  structure:\n    - review_report: 需求评审报告\n    - completeness_score: 完整性评分\n    - clarity_score: 清晰性评分\n    - consistency_issues: 一致性问题清单\n    - testability_assessment: 可测试性评估\nerror_recovery_guidance:\n  on_failure: \"识别到需求不完整时返回缺失清单，要求用户补充信息\"\n  retry_behavior: \"用户补充信息后重新执行需求评审\"\n---\n\n# 需求评审专项\n\n## 核心原则\n\n你是一位需求评审专家，擅长系统化评审需求文档质量。\n**核心原则**：需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\n本技能从完整性、清晰性、一致性、可测试性、可实现性五维评审需求。\n\n## 五维评审速查\n\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\n\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\n\n| 维度 | 评分核心 | 典型问题 |\n|------|---------|---------|\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\n\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\n\n## 评审报告模板\n\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\n\n简要结构：\n```markdown\n# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议\n```\n\n## 输出示例\n\n**评审一个PRD：用户登录功能需求**\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\n→ 一致性检查：前后描述一致✅\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\n→ 可实现性检查：技术方案可行✅\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\n\n## 检查清单\n\n需求评审完成后检查：\n- [ ] 评审维度是否覆盖？\n- [ ] 检查清单是否执行？\n- [ ] 问题是否识别？\n- [ ] 问题是否分类？\n- [ ] 建议是否可行？\n- [ ] 报告是否规范？\n\n## 常见评审陷阱\n\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.5.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.5.0\",\n  \"publishedAt\": 1782736472390\n}\n\nFile v1.5.0:references/report-template.md\n\n# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```\n\nFile v1.5.0:references/review-standards.md\n\n# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |\n\nFile v1.5.0:skill-card.md\n\n## Description: <br>\nReviews requirement documents across completeness, clarity, consistency, testability, and feasibility before QA planning or test design. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, product reviewers, and developers use this skill to assess PRDs or requirement descriptions before creating test plans or test cases. It produces a structured review with five-dimension scoring, issue severity, and improvement recommendations. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may be invoked for broader testing tasks that include requirements even when the user expected a narrower workflow. <br>\nMitigation: Call it explicitly when requirement-quality review is desired, or confirm scope before applying its findings to downstream QA planning. <br>\nRisk: Requirement-review findings can affect test strategy and may overstate or miss issues in ambiguous source requirements. <br>\nMitigation: Have the product owner or QA lead review P0/P1 findings and clarify missing requirement details before test design proceeds. <br>\n\n\n## Reference(s): <br>\n- [Review Standards](references/review-standards.md) <br>\n- [Report Template](references/report-template.md) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Analysis, Markdown, Guidance] <br>\n**Output Format:** [Markdown requirement review report with scoring, issue lists, and recommendations] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Includes completeness, clarity, consistency, testability, and feasibility scoring plus P0-P2 issue classification.] <br>\n\n## Skill Version(s): <br>\n1.5.0 (source: frontmatter and release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.4.1: 3 files, 4786 bytes\n\nFiles: skill-card.md (2005b), SKILL.md (9938b), _meta.json (140b)\n\nFile v1.4.1:SKILL.md\n\n---\r\nname: qa-requirement-review\r\ndescription: >-\r\n  需求评审专项，从完整性/清晰性/一致性/可测试性/可实现性五维评审需求质量。当需要评审需求文档或评估需求质量时激活。\r\n\r\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\r\nallowed-tools: Read Grep Glob WebFetch\r\nrelated_skills:\r\n  upstream:\r\n    - qa-critical-thinking       # 输入：批判性思维\r\n    - qa-question-framework      # 输入：提问框架\r\n  downstream:\r\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\r\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\r\ninput_format: 需求文档/PRD\r\noutput_format: 需求评审报告（评审维度+问题清单+改进建议）\r\n---\r\n\r\n# 需求评审专项\r\n\r\n## Overview\r\n\r\n你是一位需求评审专家，擅长系统化评审需求文档质量。\r\n**核心原则**：需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\r\n本技能从完整性、清晰性、一致性、可测试性、可实现性五维评审需求。\r\n\r\n## 评审维度\r\n\r\n### 维度1：完整性\r\n\r\n```\r\n检查点：\r\n├─ 功能需求\r\n│   ├─ 主流程是否描述完整？\r\n│   ├─ 分支流程是否覆盖？\r\n│   ├─ 异常流程是否考虑？\r\n│   └─ 边界条件是否定义？\r\n│\r\n├─ 非功能需求\r\n│   ├─ 性能要求是否明确？\r\n│   ├─ 安全要求是否定义？\r\n│   ├─ 兼容性要求是否说明？\r\n│   └─ 可用性要求是否描述？\r\n│\r\n├─ 约束条件\r\n│   ├─ 技术约束是否说明？\r\n│   ├─ 业务约束是否定义？\r\n│   ├─ 时间约束是否明确？\r\n│   └─ 资源约束是否描述？\r\n│\r\n└─ 验收标准\r\n    ├─ 验收条件是否明确？\r\n    ├─ 验收方法是否说明？\r\n    ├─ 验收标准是否可测试？\r\n    └─ 验收流程是否定义？\r\n```\r\n\r\n### 维度2：清晰性\r\n\r\n```\r\n检查点：\r\n├─ 术语定义\r\n│   ├─ 专业术语是否有定义？\r\n│   ├─ 业务术语是否有说明？\r\n│   ├─ 术语使用是否一致？\r\n│   └─ 是否有歧义？\r\n│\r\n├─ 描述清晰\r\n│   ├─ 需求描述是否清晰？\r\n│   ├─ 逻辑关系是否明确？\r\n│   ├─ 条件判断是否清晰？\r\n│   └─ 操作步骤是否明确？\r\n│\r\n├─ 示例说明\r\n│   ├─ 复杂需求是否有示例？\r\n│   ├─ 示例是否覆盖典型场景？\r\n│   ├─ 示例是否覆盖边界场景？\r\n│   └─ 示例是否易于理解？\r\n│\r\n└─ 图表辅助\r\n    ├─ 流程图是否清晰？\r\n    ├─ 状态图是否准确？\r\n    ├─ 原型图是否完整？\r\n    └─ 数据模型是否清晰？\r\n```\r\n\r\n### 维度3：一致性\r\n\r\n```\r\n检查点：\r\n├─ 内部一致\r\n│   ├─ 需求间是否矛盾？\r\n│   ├─ 前后描述是否一致？\r\n│   ├─ 术语使用是否一致？\r\n│   └─ 格式规范是否一致？\r\n│\r\n├─ 外部一致\r\n│   ├─ 与历史需求是否兼容？\r\n│   ├─ 与现有系统是否冲突？\r\n│   ├─ 与业务规则是否一致？\r\n│   └─ 与技术架构是否匹配？\r\n│\r\n└─ 版本一致\r\n    ├─ 版本号是否更新？\r\n    ├─ 变更记录是否完整？\r\n    ├─ 历史版本是否保留？\r\n    └─ 变更影响是否说明？\r\n```\r\n\r\n### 维度4：可测试性\r\n\r\n```\r\n检查点：\r\n├─ 可验证\r\n│   ├─ 需求是否可验证？\r\n│   ├─ 验证方法是否明确？\r\n│   ├─ 验证标准是否量化？\r\n│   └─ 验证环境是否说明？\r\n│\r\n├─ 可度量\r\n│   ├─ 性能指标是否量化？\r\n│   ├─ 质量标准是否明确？\r\n│   ├─ 成功标准是否定义？\r\n│   └─ 阈值是否说明？\r\n│\r\n└─ 可自动化\r\n    ├─ 验收条件是否可自动化？\r\n    ├─ 接口是否可测试？\r\n    ├─ 数据是否可构造？\r\n    └─ 环境是否可搭建？\r\n```\r\n\r\n### 维度5：可实现性\r\n\r\n```\r\n检查点：\r\n├─ 技术可行\r\n│   ├─ 技术方案是否可行？\r\n│   ├─ 现有架构是否支持？\r\n│   ├─ 技术风险是否识别？\r\n│   └─ 依赖是否明确？\r\n│\r\n├─ 资源可行\r\n│   ├─ 开发资源是否充足？\r\n│   ├─ 测试资源是否充足？\r\n│   ├─ 时间是否合理？\r\n│   └─ 成本是否可控？\r\n│\r\n└─ 业务可行\r\n    ├─ 业务价值是否明确？\r\n    ├─ 业务规则是否合理？\r\n    ├─ 用户场景是否真实？\r\n    └─ 投入产出比是否合理？\r\n```\r\n\r\n## 评审检查清单\r\n\r\n### 功能需求检查\r\n\r\n```\r\n├─ [ ] 主流程描述完整？\r\n├─ [ ] 分支流程覆盖？\r\n├─ [ ] 异常流程考虑？\r\n├─ [ ] 边界条件定义？\r\n├─ [ ] 业务规则明确？\r\n├─ [ ] 数据流转清晰？\r\n└─ [ ] 状态转换完整？\r\n```\r\n\r\n### 非功能需求检查\r\n\r\n```\r\n├─ [ ] 性能要求量化？\r\n├─ [ ] 安全要求明确？\r\n├─ [ ] 兼容性要求说明？\r\n├─ [ ] 可用性要求描述？\r\n├─ [ ] 可维护性要求？\r\n└─ [ ] 可扩展性要求？\r\n```\r\n\r\n### 验收标准检查\r\n\r\n```\r\n├─ [ ] 验收条件明确？\r\n├─ [ ] 验收方法说明？\r\n├─ [ ] 验收标准可测试？\r\n├─ [ ] 验收流程定义？\r\n├─ [ ] 验收人明确？\r\n└─ [ ] 验收时间约定？\r\n```\r\n\r\n## 评审问题速查\r\n\r\n| 问题类型 | 常见表现 | 对应评审维度 | 严重度倾向 |\r\n|---------|---------|------------|----------|\r\n| 主流程缺失 | 只写了一个功能点，没写完整流转 | 完整性 | P0 |\r\n| 异常未定义 | 只写了正常流程，没写异常处理 | 完整性 | P0-P1 |\r\n| 术语歧义 | \"超时\"没说具体时间，\"大量\"没量化 | 清晰性 | P1 |\r\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\r\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\r\n| 技术不可行 | 现有架构不支持需求描述 | 可实现性 | P0 |\r\n| 性能未量化 | \"响应快\"没给具体指标 | 可测试性 | P1 |\r\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\r\n\r\n## 严重度矩阵\r\n\r\n| 严重度 | 定义 | 处理时限 | 标记 |\r\n|--------|------|---------|------|\r\n| P0-阻塞 | 需求有硬伤，不改无法下一步 | 必须修改 | 🔴 |\r\n| P1-重要 | 需求不完整或有风险，影响测试设计 | 建议修改 | 🟡 |\r\n| P2-建议 | 需求可优化，不影响执行 | 可选 | 🟢 |\r\n\r\n## 评审报告模板\r\n\r\n```markdown\r\n# 需求评审报告\r\n\r\n## 基本信息\r\n- 需求文档：[名称]\r\n- 版本号：[版本]\r\n- 评审日期：[日期]\r\n- 评审人员：[名单]\r\n\r\n## 评审结论\r\n[通过/有条件通过/不通过]\r\n\r\n## 评审结果\r\n\r\n### 完整性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 功能需求完整 | ✅/❌ | [问题] |\r\n| 非功能需求完整 | ✅/❌ | [问题] |\r\n| 验收标准完整 | ✅/❌ | [问题] |\r\n\r\n### 清晰性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 术语定义清晰 | ✅/❌ | [问题] |\r\n| 描述清晰 | ✅/❌ | [问题] |\r\n| 示例说明充分 | ✅/❌ | [问题] |\r\n\r\n### 一致性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 内部一致 | ✅/❌ | [问题] |\r\n| 外部一致 | ✅/❌ | [问题] |\r\n| 版本一致 | ✅/❌ | [问题] |\r\n\r\n### 可测试性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 可验证 | ✅/❌ | [问题] |\r\n| 可度量 | ✅/❌ | [问题] |\r\n| 可自动化 | ✅/❌ | [问题] |\r\n\r\n### 可实现性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 技术可行 | ✅/❌ | [问题] |\r\n| 资源可行 | ✅/❌ | [问题] |\r\n| 业务可行 | ✅/❌ | [问题] |\r\n\r\n## 问题清单\r\n\r\n### 必须修改（P0）\r\n| 问题ID | 问题描述 | 影响范围 | 建议 |\r\n|--------|---------|---------|------|\r\n| REQ-001 | [描述] | [影响] | [建议] |\r\n\r\n### 建议修改（P1）\r\n| 问题ID | 问题描述 | 影响范围 | 建议 |\r\n|--------|---------|---------|------|\r\n| REQ-002 | [描述] | [影响] | [建议] |\r\n\r\n### 可选修改（P2）\r\n| 问题ID | 问题描述 | 影响范围 | 建议 |\r\n|--------|---------|---------|------|\r\n| REQ-003 | [描述] | [影响] | [建议] |\r\n\r\n## 改进建议\r\n1. [建议1]\r\n2. [建议2]\r\n3. [建议3]\r\n```\r\n\r\n## Examples\r\n\r\n**评审一个PRD：用户登录功能需求**\r\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\r\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\r\n→ 一致性检查：前后描述一致✅\r\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\r\n→ 可实现性检查：技术方案可行✅\r\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\r\n\r\n**需求文档中写\"支持多种支付方式\"**\r\n→ 追问：具体有哪几种？每种的技术方案是什么？接入成本？\r\n\r\n## Guidelines\r\n\r\n需求评审完成后检查：\r\n- [ ] 评审维度是否覆盖？\r\n- [ ] 检查清单是否执行？\r\n- [ ] 问题是否识别？\r\n- [ ] 问题是否分类？\r\n- [ ] 建议是否可行？\r\n- [ ] 报告是否规范？\r\n\r\n## 常见评审陷阱\r\n\r\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\r\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\r\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\r\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\r\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.4.1:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.4.1\",\n  \"publishedAt\": 1782406556550\n}\n\nFile v1.4.1:skill-card.md\n\n## Description: <br>\nReviews requirement documents and PRDs for completeness, clarity, consistency, testability, and feasibility. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nQA engineers, product teams, and developers use this skill to review requirement documents before test planning or implementation. It produces a structured assessment with findings and improvement recommendations across five requirement-quality dimensions. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may inspect requirement documents, local paths, or URLs supplied by the user. <br>\nMitigation: Provide only documents, paths, or URLs that the agent is intended to review in the current execution environment. <br>\nRisk: Broad activation phrases may invoke the review workflow during general requirements discussion. <br>\nMitigation: Use explicit invocation wording or narrow activation phrases when automatic activation would be disruptive. <br>\n\n\n## Reference(s): <br>\n- [Qa Requirement Review on ClawHub](https://clawhub.ai/kokxi/skills/qa-requirement-review) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [Text, Markdown, Guidance] <br>\n**Output Format:** [Markdown requirements review report with dimension assessments, issue lists, severity categories, and improvement recommendations.] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Evaluates user-provided requirement documents or PRDs across five quality dimensions.] <br>\n\n## Skill Version(s): <br>\n1.4.1 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.4.0: 3 files, 4942 bytes\n\nFiles: skill-card.md (2209b), SKILL.md (10254b), _meta.json (140b)\n\nFile v1.4.0:SKILL.md\n\n---\r\nname: qa-requirement-review\r\ndescription: >-\r\n  需求评审专项，系统化评审需求文档的完整性、清晰性、一致性、可测试性和可实现性。当用户需要评审需求、评估需求质量或进行需求评审时自动触发。\r\n  也适用于：需求文档提交测试前需要预审，或发现需求问题需要系统性反馈时。\r\n   关键词：需求评审、需求质量、可测试性、文档评审、PRD评审、需求检查、需求完整性、需求清晰性、需求一致性、需求问题清单。\nwhen_to_use: 用户说\"需求评审\"、\"评审需求\"、\"需求质量\"、\"PRD评审\"、\"需求检查\"、\"需求写得好不好\"、\"评审这份需求\"、需要评审需求文档、需求提交测试前预审时\r\nallowed-tools: Read Grep Glob WebFetch\r\nrelated_skills:\r\n  upstream:\r\n    - qa-critical-thinking       # 输入：批判性思维\r\n    - qa-question-framework      # 输入：提问框架\r\n  downstream:\r\n    - qa-req-deconstruction      # 输出：评审结果用于需求解构\r\n    - qa-test-strategy-design    # 输出：评审结果影响测试策略\r\ninput_format: 需求文档/PRD\r\noutput_format: 需求评审报告（评审维度+问题清单+改进建议）\r\n---\r\n\r\n# 需求评审专项\r\n\r\n## Overview\r\n\r\n你是一位需求评审专家，擅长系统化评审需求文档质量。\r\n**核心原则**：需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\r\n本技能从完整性、清晰性、一致性、可测试性、可实现性五维评审需求。\r\n\r\n## 评审维度\r\n\r\n### 维度1：完整性\r\n\r\n```\r\n检查点：\r\n├─ 功能需求\r\n│   ├─ 主流程是否描述完整？\r\n│   ├─ 分支流程是否覆盖？\r\n│   ├─ 异常流程是否考虑？\r\n│   └─ 边界条件是否定义？\r\n│\r\n├─ 非功能需求\r\n│   ├─ 性能要求是否明确？\r\n│   ├─ 安全要求是否定义？\r\n│   ├─ 兼容性要求是否说明？\r\n│   └─ 可用性要求是否描述？\r\n│\r\n├─ 约束条件\r\n│   ├─ 技术约束是否说明？\r\n│   ├─ 业务约束是否定义？\r\n│   ├─ 时间约束是否明确？\r\n│   └─ 资源约束是否描述？\r\n│\r\n└─ 验收标准\r\n    ├─ 验收条件是否明确？\r\n    ├─ 验收方法是否说明？\r\n    ├─ 验收标准是否可测试？\r\n    └─ 验收流程是否定义？\r\n```\r\n\r\n### 维度2：清晰性\r\n\r\n```\r\n检查点：\r\n├─ 术语定义\r\n│   ├─ 专业术语是否有定义？\r\n│   ├─ 业务术语是否有说明？\r\n│   ├─ 术语使用是否一致？\r\n│   └─ 是否有歧义？\r\n│\r\n├─ 描述清晰\r\n│   ├─ 需求描述是否清晰？\r\n│   ├─ 逻辑关系是否明确？\r\n│   ├─ 条件判断是否清晰？\r\n│   └─ 操作步骤是否明确？\r\n│\r\n├─ 示例说明\r\n│   ├─ 复杂需求是否有示例？\r\n│   ├─ 示例是否覆盖典型场景？\r\n│   ├─ 示例是否覆盖边界场景？\r\n│   └─ 示例是否易于理解？\r\n│\r\n└─ 图表辅助\r\n    ├─ 流程图是否清晰？\r\n    ├─ 状态图是否准确？\r\n    ├─ 原型图是否完整？\r\n    └─ 数据模型是否清晰？\r\n```\r\n\r\n### 维度3：一致性\r\n\r\n```\r\n检查点：\r\n├─ 内部一致\r\n│   ├─ 需求间是否矛盾？\r\n│   ├─ 前后描述是否一致？\r\n│   ├─ 术语使用是否一致？\r\n│   └─ 格式规范是否一致？\r\n│\r\n├─ 外部一致\r\n│   ├─ 与历史需求是否兼容？\r\n│   ├─ 与现有系统是否冲突？\r\n│   ├─ 与业务规则是否一致？\r\n│   └─ 与技术架构是否匹配？\r\n│\r\n└─ 版本一致\r\n    ├─ 版本号是否更新？\r\n    ├─ 变更记录是否完整？\r\n    ├─ 历史版本是否保留？\r\n    └─ 变更影响是否说明？\r\n```\r\n\r\n### 维度4：可测试性\r\n\r\n```\r\n检查点：\r\n├─ 可验证\r\n│   ├─ 需求是否可验证？\r\n│   ├─ 验证方法是否明确？\r\n│   ├─ 验证标准是否量化？\r\n│   └─ 验证环境是否说明？\r\n│\r\n├─ 可度量\r\n│   ├─ 性能指标是否量化？\r\n│   ├─ 质量标准是否明确？\r\n│   ├─ 成功标准是否定义？\r\n│   └─ 阈值是否说明？\r\n│\r\n└─ 可自动化\r\n    ├─ 验收条件是否可自动化？\r\n    ├─ 接口是否可测试？\r\n    ├─ 数据是否可构造？\r\n    └─ 环境是否可搭建？\r\n```\r\n\r\n### 维度5：可实现性\r\n\r\n```\r\n检查点：\r\n├─ 技术可行\r\n│   ├─ 技术方案是否可行？\r\n│   ├─ 现有架构是否支持？\r\n│   ├─ 技术风险是否识别？\r\n│   └─ 依赖是否明确？\r\n│\r\n├─ 资源可行\r\n│   ├─ 开发资源是否充足？\r\n│   ├─ 测试资源是否充足？\r\n│   ├─ 时间是否合理？\r\n│   └─ 成本是否可控？\r\n│\r\n└─ 业务可行\r\n    ├─ 业务价值是否明确？\r\n    ├─ 业务规则是否合理？\r\n    ├─ 用户场景是否真实？\r\n    └─ 投入产出比是否合理？\r\n```\r\n\r\n## 评审检查清单\r\n\r\n### 功能需求检查\r\n\r\n```\r\n├─ [ ] 主流程描述完整？\r\n├─ [ ] 分支流程覆盖？\r\n├─ [ ] 异常流程考虑？\r\n├─ [ ] 边界条件定义？\r\n├─ [ ] 业务规则明确？\r\n├─ [ ] 数据流转清晰？\r\n└─ [ ] 状态转换完整？\r\n```\r\n\r\n### 非功能需求检查\r\n\r\n```\r\n├─ [ ] 性能要求量化？\r\n├─ [ ] 安全要求明确？\r\n├─ [ ] 兼容性要求说明？\r\n├─ [ ] 可用性要求描述？\r\n├─ [ ] 可维护性要求？\r\n└─ [ ] 可扩展性要求？\r\n```\r\n\r\n### 验收标准检查\r\n\r\n```\r\n├─ [ ] 验收条件明确？\r\n├─ [ ] 验收方法说明？\r\n├─ [ ] 验收标准可测试？\r\n├─ [ ] 验收流程定义？\r\n├─ [ ] 验收人明确？\r\n└─ [ ] 验收时间约定？\r\n```\r\n\r\n## 评审问题速查\r\n\r\n| 问题类型 | 常见表现 | 对应评审维度 | 严重度倾向 |\r\n|---------|---------|------------|----------|\r\n| 主流程缺失 | 只写了一个功能点，没写完整流转 | 完整性 | P0 |\r\n| 异常未定义 | 只写了正常流程，没写异常处理 | 完整性 | P0-P1 |\r\n| 术语歧义 | \"超时\"没说具体时间，\"大量\"没量化 | 清晰性 | P1 |\r\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\r\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\r\n| 技术不可行 | 现有架构不支持需求描述 | 可实现性 | P0 |\r\n| 性能未量化 | \"响应快\"没给具体指标 | 可测试性 | P1 |\r\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\r\n\r\n## 严重度矩阵\r\n\r\n| 严重度 | 定义 | 处理时限 | 标记 |\r\n|--------|------|---------|------|\r\n| P0-阻塞 | 需求有硬伤，不改无法下一步 | 必须修改 | 🔴 |\r\n| P1-重要 | 需求不完整或有风险，影响测试设计 | 建议修改 | 🟡 |\r\n| P2-建议 | 需求可优化，不影响执行 | 可选 | 🟢 |\r\n\r\n## 评审报告模板\r\n\r\n```markdown\r\n# 需求评审报告\r\n\r\n## 基本信息\r\n- 需求文档：[名称]\r\n- 版本号：[版本]\r\n- 评审日期：[日期]\r\n- 评审人员：[名单]\r\n\r\n## 评审结论\r\n[通过/有条件通过/不通过]\r\n\r\n## 评审结果\r\n\r\n### 完整性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 功能需求完整 | ✅/❌ | [问题] |\r\n| 非功能需求完整 | ✅/❌ | [问题] |\r\n| 验收标准完整 | ✅/❌ | [问题] |\r\n\r\n### 清晰性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 术语定义清晰 | ✅/❌ | [问题] |\r\n| 描述清晰 | ✅/❌ | [问题] |\r\n| 示例说明充分 | ✅/❌ | [问题] |\r\n\r\n### 一致性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 内部一致 | ✅/❌ | [问题] |\r\n| 外部一致 | ✅/❌ | [问题] |\r\n| 版本一致 | ✅/❌ | [问题] |\r\n\r\n### 可测试性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 可验证 | ✅/❌ | [问题] |\r\n| 可度量 | ✅/❌ | [问题] |\r\n| 可自动化 | ✅/❌ | [问题] |\r\n\r\n### 可实现性评审\r\n| 检查项 | 状态 | 问题 |\r\n|--------|------|------|\r\n| 技术可行 | ✅/❌ | [问题] |\r\n| 资源可行 | ✅/❌ | [问题] |\r\n| 业务可行 | ✅/❌ | [问题] |\r\n\r\n## 问题清单\r\n\r\n### 必须修改（P0）\r\n| 问题ID | 问题描述 | 影响范围 | 建议 |\r\n|--------|---------|---------|------|\r\n| REQ-001 | [描述] | [影响] | [建议] |\r\n\r\n### 建议修改（P1）\r\n| 问题ID | 问题描述 | 影响范围 | 建议 |\r\n|--------|---------|---------|------|\r\n| REQ-002 | [描述] | [影响] | [建议] |\r\n\r\n### 可选修改（P2）\r\n| 问题ID | 问题描述 | 影响范围 | 建议 |\r\n|--------|---------|---------|------|\r\n| REQ-003 | [描述] | [影响] | [建议] |\r\n\r\n## 改进建议\r\n1. [建议1]\r\n2. [建议2]\r\n3. [建议3]\r\n```\r\n\r\n## Examples\r\n\r\n**评审一个PRD：用户登录功能需求**\r\n→ 完整性检查：功能描述完整✅，但缺少非功能需求❌\r\n→ 清晰性检查：\"登录超时\"未定义具体时间❌\r\n→ 一致性检查：前后描述一致✅\r\n→ 可测试性检查：\"响应要快\"不可量化❌，应改为\"登录响应<2秒\"\r\n→ 可实现性检查：技术方案可行✅\r\n→ 评审报告：P0问题（缺少非功能需求）+ P1问题（模糊表述）\r\n\r\n**需求文档中写\"支持多种支付方式\"**\r\n→ 追问：具体有哪几种？每种的技术方案是什么？接入成本？\r\n\r\n## Guidelines\r\n\r\n需求评审完成后检查：\r\n- [ ] 评审维度是否覆盖？\r\n- [ ] 检查清单是否执行？\r\n- [ ] 问题是否识别？\r\n- [ ] 问题是否分类？\r\n- [ ] 建议是否可行？\r\n- [ ] 报告是否规范？\r\n\r\n## 常见评审陷阱\r\n\r\n1. **只挑刺不建树**：发现100个问题但没给1个改进建议 → 每个P0/P1问题必须附带建议\r\n2. **凭感觉不打分**：说\"这块不够好\"但不指哪个维度 → 评审结论必须基于五维评分\r\n3. **过度纠错细节**：纠结错别字忽略结构性缺失 → 区分\"格式问题\"和\"内容问题\"，优先评审内容\r\n4. **遗漏非功能**：只看功能完整不看性能/安全 → 五维评审缺一不可\r\n5. **评审完不追踪**：报告给了就完了 → 必须标注每条问题的处理状态（已修/待修/已确认）\n\nFile v1.4.0:_meta.json\n\n{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.4.0\",\n  \"publishedAt\": 1782277827867\n}\n\nFile v1.4.0:skill-card.md\n\n## Description: <br>\nChinese-language skill for systematically reviewing requirements documents and PRDs for completeness, clarity, consistency, testability, and feasibility. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[kokxi](https://clawhub.ai/user/kokxi) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nProduct, QA, engineering, and delivery teams use this skill to review requirement documents before implementation or testing. It produces structured findings and improvement suggestions across completeness, clarity, consistency, testability, and feasibility. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill may review sensitive or unintended requirements content if the user supplies documents or URLs outside the intended scope. <br>\nMitigation: Provide only the documents or URLs intended for review and clarify scope when the conversation is only about general requirements quality. <br>\nRisk: Review findings may be incomplete or misleading when the source requirements are incomplete, ambiguous, or missing business context. <br>\nMitigation: Treat the report as review guidance and have the responsible product, QA, or engineering owner confirm priority and corrective action before implementation. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/kokxi/skills/qa-requirement-review) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, guidance] <br>\n**Output Format:** [Markdown requirements review report with review dimensions, issue list, severity labels, and improvement suggestions] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [No executable code; output quality depends on the completeness and accuracy of the supplied requirements material.] <br>\n\n## Skill Version(s): <br>\n1.4.0 (source: server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>","readmeExcerpt":"Skill: qa-requirement-review Owner: kokxi Summary: 从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibilit","codeSnippets":[],"executableExamples":[{"language":"markdown","snippet":"# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议"},{"language":"markdown","snippet":"# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]"},{"language":"text","snippet":"├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？"},{"language":"text","snippet":"├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？"},{"language":"text","snippet":"├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？"},{"language":"text","snippet":"├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？"}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: qa-requirement-review\ndescription: >-\n  从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibility before test design starts.\nlicense: MIT\nallowed-tools: Read Grep Glob WebFetch\nmetadata:\n  display-name: \"Requirement Review\"\n  version: \"1.8.0\"\n  when-to-use: \"用户说\\\"需求评审\\\"、\\\"评审需求\\\"、\\\"需求质量\\\"、\\\"PRD评审\\\"、\\\"需求检查\\\"、\\\"需求写得好不好\\\"、\\\"评审这份需求\\\"、需要评审需求文档、需求提交测试前预审时\"\n  related-skills: \"{\\\"upstream\\\":[\\\"qa-input-validation\\\",\\\"qa-critical-thinking\\\",\\\"qa-question-framework\\\"],\\\"downstream\\\":[\\\"qa-req-deconstruction\\\",\\\"qa-test-strategy-design\\\"]}\"\n  references: \"[\\\"references/report-template.md\\\",\\\"references/review-standards.md\\\"]\"\n  input-format: \"{\\\"required\\\":[{\\\"name\\\":\\\"需求描述\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"功能需求的详细描述文本\\\"}],\\\"optional\\\":[{\\\"name\\\":\\\"业务背景\\\",\\\"type\\\":\\\"string\\\",\\\"description\\\":\\\"业务目标和用户角色\\\"},{\\\"name\\\":\\\"历史缺陷\\\",\\\"type\\\":\\\"array\\\",\\\"description\\\":\\\"同类功能的历史缺陷记录\\\"}]}\"\n  output-format: \"{\\\"traceability\\\":[\\\"每份需求评审报告带唯一ID（REV-REQ-XXXX）\\\",\\\"关联需求ID：REQ-{需求模块缩写}-{序号}\\\"],\\\"structure\\\":[\\\"覆盖率：标注口径（基于现有需求/输入文档），禁止\\\\\\\"全覆盖/100%\\\\\\\"绝对化表述；缺失模块标注\\\\\\\"未覆盖+原因\\\\\\\"\\\",{\\\"review_report\\\":\\\"需求评审报告\\\"},{\\\"completeness_score\\\":\\\"完整性评分\\\"},{\\\"clarity_score\\\":\\\"清晰性评分\\\"},{\\\"consistency_issues\\\":\\\"一致性问题清单\\\"},{\\\"testability_assessment\\\":\\\"可测试性评估\\\"}]}\"\n  error-recovery-guidance: \"{\\\"on_failure\\\":\\\"识别到需求不完整时返回缺失清单，要求用户补充信息\\\",\\\"retry_behavior\\\":\\\"用户补充信息后重新执行需求评审\\\"}\"\n  categories: \"[\\\"Development\\\",\\\"Requirements\\\"]\"\n  depth-requirement: \"{\\\"reference_value\\\":\\\"根据需求复杂度调整评审深度：简单×1/中等×2/复杂×3\\\",\\\"minimum\\\":\\\"至少评审完整性、清晰性、一致性、可测试性、可实现性5个维度\\\"}\"\n---\n> ⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills\n\n# 需求评审专项\n\n## 核心原则\n\n需求评审不是挑刺，而是确保需求可理解、可测试、可实现。\n\n## 五维评审速查\n\n> 各维度的**详细检查清单、评审问题速查和严重度矩阵**参见 [`references/review-standards.md`](references/review-standards.md)。\n\n**评分规则**：每个维度10分，总分≥40分为\"有条件通过\"，≥45分为\"通过\"。\n\n| 维度 | 评分核心 | 典型问题 |\n|------|---------|---------|\n| 完整性 | 功能/非功能/约束/验收是否完整 | 主流程缺失、异常未定义、验收标准缺失 |\n| 清晰性 | 术语/描述/示例是否清晰无歧义 | 术语歧义、描述模糊、缺少示例 |\n| 一致性 | 内部/外部/版本是否一致 | 前后矛盾、与现有系统冲突 |\n| 可测试性 | 验证/度量/自动化是否可行 | \"体验好\"不可验证、性能未量化 |\n| 可实现性 | 技术/资源/业务是否可行 | 架构不支持、时间不合理 |\n\n> 每维度的完整检查清单和评分标准详见 [`references/review-standards.md`](references/review-standards.md)。\n\n## 评审报告模板\n\n> 完整模板（含五维评分表格、P0-P2问题清单）参见 [`references/report-template.md`](references/report-template.md)。\n\n简要结构：\n```markdown\n# 需求评审报告\n## 评审结论：[通过/有条件通过/不通过]\n## 五维评分：完整性X/10 清晰性X/10 一致性X/10 可测试性X/10 可实现性X/10\n## 问题清单\n### P0（必须修改）\n### P1（建议修改）\n### P2（可选修改）\n## 改进建议\n```\n\n## 加载时机\n\n**需要时才读，不要一上来全读**：\n\n| 什么时候读 | 读哪个 |\n|-----------|--------|\n| 拿评审报告模板填 | [`references/report-template.md`](references/report-template.md)（报告结构与填写要求） |\n| 判断某个需求问题算不算缺陷 | [`references/review-standards.md`](references/review-standards."},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn71y9b23csfx0ykgm55d5m9x5891zt8\",\n  \"slug\": \"qa-requirement-review\",\n  \"version\": \"1.8.0\",\n  \"publishedAt\": 1790656066322\n}"},{"path":"references/report-template.md","content":"# 评审报告模板\n\n> 本文档是 `qa-requirement-review` 的参考文件。按此模板输出评审报告。\n\n---\n\n```markdown\n# 需求评审报告\n\n## 基本信息\n- 需求文档：[名称]\n- 版本号：[版本]\n- 评审日期：[日期]\n- 评审人员：[名单]\n\n## 评审结论\n[通过/有条件通过/不通过]\n\n## 评审结果\n\n### 完整性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 功能需求完整 | ✅/❌ | [问题] |\n| 非功能需求完整 | ✅/❌ | [问题] |\n| 验收标准完整 | ✅/❌ | [问题] |\n\n### 清晰性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 术语定义清晰 | ✅/❌ | [问题] |\n| 描述清晰 | ✅/❌ | [问题] |\n| 示例说明充分 | ✅/❌ | [问题] |\n\n### 一致性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 内部一致 | ✅/❌ | [问题] |\n| 外部一致 | ✅/❌ | [问题] |\n| 版本一致 | ✅/❌ | [问题] |\n\n### 可测试性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 可验证 | ✅/❌ | [问题] |\n| 可度量 | ✅/❌ | [问题] |\n| 可自动化 | ✅/❌ | [问题] |\n\n### 可实现性评审\n| 检查项 | 状态 | 问题 |\n|--------|------|------|\n| 技术可行 | ✅/❌ | [问题] |\n| 资源可行 | ✅/❌ | [问题] |\n| 业务可行 | ✅/❌ | [问题] |\n\n## 问题清单\n\n### 必须修改（P0）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-001 | [描述] | [影响] | [建议] |\n\n### 建议修改（P1）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-002 | [描述] | [影响] | [建议] |\n\n### 可选修改（P2）\n| 问题ID | 问题描述 | 影响范围 | 建议 |\n|--------|---------|---------|------|\n| REQ-003 | [描述] | [影响] | [建议] |\n\n## 改进建议\n1. [建议1]\n2. [建议2]\n3. [建议3]\n```"},{"path":"references/review-standards.md","content":"# 五维评审标准\n\n> 本文档是 `qa-requirement-review` 的参考文件。按以下五维标准逐项评审需求文档质量。\n\n---\n\n## 维度1：完整性\n\n**检查点**：\n\n```text\n├─ 功能需求\n│   ├─ 主流程是否描述完整？\n│   ├─ 分支流程是否覆盖？\n│   ├─ 异常流程是否考虑？\n│   └─ 边界条件是否定义？\n\n├─ 非功能需求\n│   ├─ 性能要求是否明确？\n│   ├─ 安全要求是否定义？\n│   ├─ 兼容性要求是否说明？\n│   └─ 可用性要求是否描述？\n\n├─ 约束条件\n│   ├─ 技术约束是否说明？\n│   ├─ 业务约束是否定义？\n│   ├─ 时间约束是否明确？\n│   └─ 资源约束是否描述？\n\n└─ 验收标准\n    ├─ 验收条件是否明确？\n    ├─ 验收方法是否说明？\n    ├─ 验收标准是否可测试？\n    └─ 验收流程是否定义？\n```\n\n---\n\n## 维度2：清晰性\n\n**检查点**：\n\n```text\n├─ 术语定义\n│   ├─ 专业术语是否有定义？\n│   ├─ 业务术语是否有说明？\n│   ├─ 术语使用是否一致？\n│   └─ 是否有歧义？\n\n├─ 描述清晰\n│   ├─ 需求描述是否清晰？\n│   ├─ 逻辑关系是否明确？\n│   ├─ 条件判断是否清晰？\n│   └─ 操作步骤是否明确？\n\n├─ 示例说明\n│   ├─ 复杂需求是否有示例？\n│   ├─ 示例是否覆盖典型场景？\n│   ├─ 示例是否覆盖边界场景？\n│   └─ 示例是否易于理解？\n\n└─ 图表辅助\n    ├─ 流程图是否清晰？\n    ├─ 状态图是否准确？\n    ├─ 原型图是否完整？\n    └─ 数据模型是否清晰？\n```\n\n---\n\n## 维度3：一致性\n\n**检查点**：\n\n```text\n├─ 内部一致\n│   ├─ 需求间是否矛盾？\n│   ├─ 前后描述是否一致？\n│   ├─ 术语使用是否一致？\n│   └─ 格式规范是否一致？\n\n├─ 外部一致\n│   ├─ 与历史需求是否兼容？\n│   ├─ 与现有系统是否冲突？\n│   ├─ 与业务规则是否一致？\n│   └─ 与技术架构是否匹配？\n\n└─ 版本一致\n    ├─ 版本号是否更新？\n    ├─ 变更记录是否完整？\n    ├─ 历史版本是否保留？\n    └─ 变更影响是否说明？\n```\n\n---\n\n## 维度4：可测试性\n\n**检查点**：\n\n```text\n├─ 可验证\n│   ├─ 需求是否可验证？\n│   ├─ 验证方法是否明确？\n│   ├─ 验证标准是否量化？\n│   └─ 验证环境是否说明？\n\n├─ 可度量\n│   ├─ 性能指标是否量化？\n│   ├─ 质量标准是否明确？\n│   ├─ 成功标准是否定义？\n│   └─ 阈值是否说明？\n\n└─ 可自动化\n    ├─ 验收条件是否可自动化？\n    ├─ 接口是否可测试？\n    ├─ 数据是否可构造？\n    └─ 环境是否可搭建？\n```\n\n---\n\n## 维度5：可实现性\n\n**检查点**：\n\n```text\n├─ 技术可行\n│   ├─ 技术方案是否可行？\n│   ├─ 现有架构是否支持？\n│   ├─ 技术风险是否识别？\n│   └─ 依赖是否明确？\n\n├─ 资源可行\n│   ├─ 开发资源是否充足？\n│   ├─ 测试资源是否充足？\n│   ├─ 时间是否合理？\n│   └─ 成本是否可控？\n\n└─ 业务可行\n    ├─ 业务价值是否明确？\n    ├─ 业务规则是否合理？\n    ├─ 用户场景是否真实？\n    └─ 投入产出比是否合理？\n```\n\n---\n\n## 评审检查清单\n\n### 功能需求检查\n```text\n├─ [ ] 主流程描述完整？\n├─ [ ] 分支流程覆盖？\n├─ [ ] 异常流程考虑？\n├─ [ ] 边界条件定义？\n├─ [ ] 业务规则明确？\n├─ [ ] 数据流转清晰？\n└─ [ ] 状态转换完整？\n```\n\n### 非功能需求检查\n```text\n├─ [ ] 性能要求量化？\n├─ [ ] 安全要求明确？\n├─ [ ] 兼容性要求说明？\n├─ [ ] 可用性要求描述？\n├─ [ ] 可维护性要求？\n└─ [ ] 可扩展性要求？\n```\n\n### 验收标准检查\n```text\n├─ [ ] 验收条件明确？\n├─ [ ] 验收方法说明？\n├─ [ ] 验收标准可测试？\n├─ [ ] 验收流程定义？\n├─ [ ] 验收人明确？\n└─ [ ] 验收时间约定？\n```\n\n---\n\n## 评审问题速查\n\n| 问题类型 | 常见表现 | 对应维度 | 严重度 |\n|---------|---------|---------|--------|\n| 主流程缺失 | 只写功能点没写完整流转 | 完整性 | P0 |\n| 异常未定义 | 只写正常流程没写异常 | 完整性 | P0-P1 |\n| 术语歧义 | \"超时\"没具体时间 | 清晰性 | P1 |\n| 前后矛盾 | 前文说A，后文说非A | 一致性 | P0 |\n| 不可测试 | \"体验好\"无法验证 | 可测试性 | P1 |\n| 技术不可行 | 架构不支持 | 可实现性 | P0 |\n| 性能未量化 | \"响应快\"无指标 | 可测试性 | P1 |\n| 验收标准缺失 | 没写怎么算完成 | 完整性 | P1 |\n\n## 严重度矩阵\n\n| 严重度 | 定义 | 处理时限 | 标记 |\n|--------|------|---------|------|\n| P0-阻塞 | 有硬伤不改无法下一步 | 必须修改 | 🔴 |\n| P1-重要 | 不完整或有风险 | 建议修改 | 🟡 |\n| P2-建议 | 可优化不影响执行 | 可选 | 🟢 |"},{"path":"skill-card.md","content":"## Description:\n\nReviews PRDs and requirements for completeness, clarity, consistency, testability, and feasibility before test design.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[kokxi](https://clawhub.ai/user/kokxi)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nQA teams, product managers, and developers use this skill to review requirements before test design, identify gaps or ambiguities, and suggest actionable revisions.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The optional companion-skill installation command is not version-pinned.\n\nMitigation: Verify its source and use a pinned or reviewed version before running it.\n\n## Reference(s):\n\n- [ClawHub skill release](https://clawhub.ai/kokxi/skills/qa-requirement-review)\n- [Review report template](artifact/references/report-template.md)\n- [Five-dimension review standards](artifact/references/review-standards.md)\n\n## Skill Output:\n\n**Output Type(s):** [Markdown, Guidance]\n\n**Output Format:** [Markdown requirement-review report]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Five-dimension scores, an overall decision, prioritized P0–P2 findings, traceable issue IDs, and improvement suggestions.]\n\n## Skill Version(s):\n\n1.8.0 (source: skill metadata and server-resolved release)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibility before test design starts. Skill: qa-requirement-review Owner: kokxi Summary: 从完整性、清晰性、一致性、可测试性、可实现性五个维度系统化评审需求文档质量。当用户要求\"评审这份需求\"、\"看看这个PRD写得怎么样\"、或者测试用例设计前需要先评估需求质量时，应当使用此技能。如果需求本身有问题（模糊/矛盾/不可测试），后续的测试设计都是徒劳。不要只在用户明确说\"需求评审\"时才用——任何涉及需求文档的测试任务都应先过一遍需求评审。 触发场景：需求评审、评审需求、需求质量、PRD评审、需求检查、需求写得好不好、评审这份需求、需求提交测试前预审时。 Use when the user asks about: reviewing a PRD or requirement document for completeness, clarity, consistency, testability, and feasibilit","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":904,"uniquenessScore":53,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T03:32:26.984Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T03:32:26.984Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T05:34:32.801Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}