openharmonyinsight/oh-pdd-prd-analysis
skills/oh-pdd-prd-analysis/SKILL.md
分析 HM Desktop PRD 文档，提取需求信息、验证完整性、检查章节顺序（需求来源→需求背景→需求价值分析→竞品分析→需求描述）、检查 KEP 定义、检测需求冲突并生成结构化分析报告。适用于用户请求：(1) 分析或审查 PRD 文档, (2) 从需求中提取 KEP 列表, (3) 检查 PRD 完整性或一致性, (4) 将需求映射到模块架构, (5) 验证 PRD 格式合规性, (6) 验证竞品分析章节完整性。关键词：PRD分析, requirement extraction, KEP验证, completeness check, chapter order validation, 竞品分析检查, analyze PRD, 需求提取, 完整性检查, 章节顺序验证
$ install --global
skillsauthnpx skillsauth add openharmonyinsight/openharmony-skills oh-pdd-prd-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: May 29, 2026, 6:33 AM121.0s7 files scanned
SKILL.md
- name:
- oh-pdd-prd-analysis
- description:
- 分析 HM Desktop PRD 文档，提取需求信息、验证完整性、检查章节顺序（需求来源→需求背景→需求价值分析→竞品分析→需求描述）、检查 KEP 定义、检测需求冲突并生成结构化分析报告。适用于用户请求：(1) 分析或审查 PRD 文档, (2) 从需求中提取 KEP 列表, (3) 检查 PRD 完整性或一致性, (4) 将需求映射到模块架构, (5) 验证 PRD 格式合规性, (6) 验证竞品分析章节完整性。关键词：PRD分析, requirement extraction, KEP验证, completeness check, chapter order validation, 竞品分析检查, analyze PRD, 需求提取, 完整性检查, 章节顺序验证
PRD 需求分析
分析 HM Desktop PRD 文档并生成结构化的需求分析报告。
快速开始
提供 PRD 文件路径：
分析 PRD: {PRD文件路径}
或指定具体选项：
分析 PRD: {PRD文件路径}
- 输出格式：JSON
- 检查完整性：是
- 提取 KEP：是
- 检测冲突：是
分析流程
1. 文档元数据解析
提取以下信息：
- 文档版本（VX.X 格式）
- 创建日期（YYYY-MM-DD）
- 文档作者/团队
- 产品名称
- 目标版本
2. KEP（关键体验路径）提取
对每个找到的 KEP，提取：
- KEP ID：格式应为 KEP1-01、KEP1-02 等
- KEP 名称：简洁、包含动词的名称
- 优先级：P0（关键）、P1（重要）、P2（可选）
- 用户故事：用户场景描述
- 验收标准：明确的验证条件
3. 需求统计
- 需求总数
- P0 需求数量（发布必需）
- P1 需求数量（重要但不阻塞）
- P2 需求数量（未来增强）
4. 完整性验证
使用 references/completeness_rules.md 中的检查清单验证所有必需章节。
标准章节顺序：需求来源 → 需求背景 → 需求价值分析 → 竞品分析 → 需求描述
章节顺序验证：
- [ ] 第1章：需求来源
- [ ] 第2章：需求背景
- [ ] 第3章：需求价值分析
- [ ] 第4章：竞品分析（必需）
- [ ] 第5章：需求描述
- [ ] 后续章节是否符合规范
竞品分析章节检查：
- [ ] 是否存在独立的竞品分析章节（第4章）
- [ ] 竞品数量是否≥2个
- [ ] 是否包含竞品功能对比表格
- [ ] 是否包含竞品技术方案分析
5. 章节顺序验证
验证 PRD 文档章节是否符合标准顺序：
标准顺序：需求来源 → 需求背景 → 需求价值分析 → 竞品分析 → 需求描述
检测逻辑：
- 提取文档中所有一级标题（# 开头）
- 验证前5章的标题是否符合要求
- 如顺序错误，列出问题并建议调整
- 如缺失竞品分析章节，明确提示补充
输出格式：
章节顺序检查结果：
✅ 第1章：需求来源
✅ 第2章：需求背景
✅ 第3章：需求价值分析
❌ 第4章：竞品分析（缺失，需补充）
✅ 第5章：需求描述
6. 冲突检测
检查：
- 同一功能在不同章节描述不一致
- 优先级冲突（P0 项目过多）
- 技术可行性风险
- 矛盾的用户场景
7. 竞品分析章节检查
检查内容：
| 检查项 | 说明 | |--------|------| | 章节位置 | 竞品分析必须在第4章 | | 竞品数量 | 至少分析2个竞品 | | 对比维度 | 功能、技术、体验、成本等 | | 差异化 | 是否明确说明差异化优势 | | 证据支撑 | 是否有数据或案例支撑 |
输出：如竞品分析缺失或不足，生成补充建议模板
8. 模块划分建议
按照 references/module_mapping.md 的指导将需求映射到服务模块。
输出格式
Markdown 报告（默认）
生成 prd_analysis_report.md，包含：
- 文档信息
- 需求概述
- KEP 列表
- 完整性检查结果
- 冲突检测结果
- 模块划分建议
JSON 格式
{
"prd_info": {
"file": "{PRD文件名}",
"version": "VX.X",
"date": "2026-01-31"
},
"requirements": {
"total": 25,
"p0": 8,
"p1": 12,
"p2": 5
},
"kep_list": [...],
"completeness": {...},
"conflicts": [...],
"module_suggestions": [...]
}
参考文档
- PRD 格式要求: references/prd_format.md
- 完整性规则: references/completeness_rules.md
- KEP 验证: references/kep_validation.md
- 模块映射: references/module_mapping.md
报告模板
自定义报告格式，参见 assets/report_template.md。
错误处理
| 错误类型 | 处理方式 | |----------|----------| | PRD 文件未找到 | 提示用户检查文件路径 | | 格式不符合规范 | 列出缺失的必需章节 | | 需求冲突 | 列出冲突和建议的解决方案 | | 读取失败 | 检查文件编码（应为 UTF-8） |
使用示例
基本分析：
分析 {PRD文件路径} 这个 PRD
输出 JSON 格式：
分析 {PRD文件名}，以 JSON 格式输出结果
仅检查完整性：
检查 {PRD文件名} 是否包含所有必需的 PRD 章节
提取 KEP：
从 {PRD文件名} 中提取所有 KEP 定义
检测冲突：
检查 {PRD文件名} 中是否存在需求冲突
模块划分建议：
根据 {PRD文件名} 的需求，建议如何划分服务模块
Related Skills
openharmonyinsight/skills/ohos-req-value-decision
testing
VerifiedTrustedCommunity
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
30SKILL.mdUpdated Jul 22, 2026
openharmonyinsight/ohos-req-review-ppt-gen
development
VerifiedTrustedCommunity
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
30SKILL.mdUpdated Jul 22, 2026
openharmonyinsight/ohos-req-review-gate
testing
VerifiedTrustedCommunity
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
30SKILL.mdUpdated Jul 22, 2026
openharmonyinsight/skills/ohos-req-requirement-intake
testing
VerifiedTrustedCommunity
--- name: ohos-req-requirement-intake description: Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline). metadata: author: openharmony scope: common
30SKILL.mdUpdated Jul 22, 2026