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, 需求提取, 完整性检查, 章节顺序验证
npx skillsauth add openharmonyinsight/openharmony-skills oh-pdd-prd-analysisInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
分析 HM Desktop PRD 文档并生成结构化的需求分析报告。
提供 PRD 文件路径:
分析 PRD: {PRD文件路径}
或指定具体选项:
分析 PRD: {PRD文件路径}
- 输出格式:JSON
- 检查完整性:是
- 提取 KEP:是
- 检测冲突:是
提取以下信息:
对每个找到的 KEP,提取:
使用 references/completeness_rules.md 中的检查清单验证所有必需章节。
标准章节顺序:需求来源 → 需求背景 → 需求价值分析 → 竞品分析 → 需求描述
章节顺序验证:
竞品分析章节检查:
验证 PRD 文档章节是否符合标准顺序:
标准顺序:需求来源 → 需求背景 → 需求价值分析 → 竞品分析 → 需求描述
检测逻辑:
输出格式:
章节顺序检查结果:
✅ 第1章:需求来源
✅ 第2章:需求背景
✅ 第3章:需求价值分析
❌ 第4章:竞品分析(缺失,需补充)
✅ 第5章:需求描述
检查:
检查内容:
| 检查项 | 说明 | |--------|------| | 章节位置 | 竞品分析必须在第4章 | | 竞品数量 | 至少分析2个竞品 | | 对比维度 | 功能、技术、体验、成本等 | | 差异化 | 是否明确说明差异化优势 | | 证据支撑 | 是否有数据或案例支撑 |
输出:如竞品分析缺失或不足,生成补充建议模板
按照 references/module_mapping.md 的指导将需求映射到服务模块。
生成 prd_analysis_report.md,包含:
{
"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": [...]
}
自定义报告格式,参见 assets/report_template.md。
| 错误类型 | 处理方式 | |----------|----------| | PRD 文件未找到 | 提示用户检查文件路径 | | 格式不符合规范 | 列出缺失的必需章节 | | 需求冲突 | 列出冲突和建议的解决方案 | | 读取失败 | 检查文件编码(应为 UTF-8) |
基本分析:
分析 {PRD文件路径} 这个 PRD
输出 JSON 格式:
分析 {PRD文件名},以 JSON 格式输出结果
仅检查完整性:
检查 {PRD文件名} 是否包含所有必需的 PRD 章节
提取 KEP:
从 {PRD文件名} 中提取所有 KEP 定义
检测冲突:
检查 {PRD文件名} 中是否存在需求冲突
模块划分建议:
根据 {PRD文件名} 的需求,建议如何划分服务模块
development
Run local code quality checks covering a subset of OpenHarmony gate CI (copyright, CodeArts C/C++) plus additional local checks (pylint/flake8, shellcheck/bashate, gn format). Use before committing to reduce gate failures. Triggers on: /oh-precommit-codecheck, "门禁检查", "门禁预检", "检查代码", "run codecheck", "check code quality", "lint my code", "代码检查", or after completing code implementation. WHEN to use: before git commit, before creating PR, after modifying C/C++/Python/Shell/GN files, when gate CI fails with codecheck defects, or when you want to preview what gate will flag.
development
OpenHarmony PR full lifecycle workflow. Five modes: - Commit: standardized commit with DCO sign-off and Issue linking - Create PR: commit + push to fork + create Issue + create PR on upstream - Fix Codecheck: fetch gate CI codecheck defects from a PR and auto-fix them - Review PR: fetch a PR's changes to local for code review - Fix Review: fetch unresolved review comments from a PR and auto-fix them Triggers on: /oh-pr-workflow, "提交代码", "创建PR", "提个PR", "commit", "修复告警", "修复门禁", "修复codecheck", "fix codecheck", "review pr", "review这个pr", "看下这个pr", "检视pr", "修复review", "修复检视意见", "fix review", or a GitCode PR URL with fix/review intent.
development
基于 PRD 文档自动生成鸿蒙系统设计文档,包括架构设计文档和功能设计文档。生成前会分析 OpenHarmony 存量代码结构,确保与现有架构兼容。架构设计文档第2章必须为竞品方案分析,位于需求背景之后。适用于用户请求:(1) 生成架构设计文档, (2) 生成功能设计文档, (3) 从 PRD 生成设计文档, (4) 创建系统架构设计, (5) 编写功能规格说明, (6) 分析 OH 代码结构。关键词:architecture design, functional design, design doc, 竞品方案分析, OpenHarmony code analysis, 架构设计, 功能设计, 设计文档生成, OH代码分析, analyze codebase, competitor analysis
development
基于设计文档自动生成鸿蒙系统代码框架,包括 IDL 接口定义、目录结构、头文件、源文件模板、构建配置等。生成前会分析 OpenHarmony 存量代码,学习现有代码风格和架构规范。适用于用户请求:(1) 生成代码框架, (2) 创建 IDL 接口, (3) 生成 BUILD.gn 配置, (4) 创建服务代码, (5) 初始化项目结构, (6) 参考现有代码风格。关键词:code generation, IDL, BUILD.gn, bundle.json, SA profile, OpenHarmony code style, 代码生成, 接口定义, 构建配置, OH代码风格