skills/api-doc-checker/SKILL.md
Comprehensive API documentation quality checker supporting 7 quality dimensions, SDK source consistency validation, and multi-format reporting. Use for API review, documentation quality assessment, error detection, and consistency checks.
npx skillsauth add openharmonyinsight/openharmony-skills api-doc-checkerInstall 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.
检查API文档质量的基本步骤:
references/index.json 加载规则模块详细实现见:references/workflow-details.md
js-apis-*.md、js-apis-app-ability-*.md、js-apis-inner-*.md、capi-*.mdjs-apis-geolocation.md、js-apis-app-ability-wantAgent.mdguide、tutorial、overview、getting-started等关键词application-dev-guide.md、getting-started.md通过加载 references/ 目录下的规则文件,按以下维度执行检查:
| 维度 | 规则文件 | 核心关注点 | 细分问题 |
|------|---------|-----------|---------|
| 资源易找性 | findability-rules.json | 信息可发现性 | 描述关键字不准确;官网资料缺失,分散在其他渠道 |
| 资源丰富性/完整性 | completeness-rules.json | 内容完整性 | 示例代码/解决方案缺失;关键说明缺失;规格约束说明缺失;默认效果说明缺失;关联信息说明缺失 |
| 资料正确性 | correctness-rules.json | 内容准确性 | 变更未及时更新;示例代码不完整/不可用;JSDOC描述错误 |
| 资源清晰易懂 | clarity-rules.json | 表达清晰度 | 标题与内容不符;功能描述不准确;关联文档链接缺失;机制原理说明缺失 |
| 能力有效性 | capability-rules.json | API有效性 | 约束条件缺失;系统bug;资料过时未更新 |
| 能力易用性 | capability-rules.json | API易用性 | 命名存在歧义;示例代码不实用 |
| 能力丰富性 | capability-rules.json | API丰富度 | 替代方案缺失;系统能力缺失;稳定性定位手段缺失 |
本 Skill 通过加载 references/index.json 中定义的规则模块执行检查:
| 规则模块 | 规则文件 | 所属维度 | 检查内容 |
|---------|---------|---------|---------|
| spelling | spelling-rules.json | 资料正确性 | 拼写错误、鸿蒙专有名词校验 |
| syntax | syntax-rules.json | 资料正确性 | 代码语法错误(模板字符串空格、括号匹配等) |
| path-consistency | path-consistency-rules.json | 资料正确性 | 文档内部路径一致性、与Sample代码一致性 |
| semantics | semantics-rules.json | 能力易用性 | 示例代码语义清晰度(bundleName占位符等) |
| project-structure | project-structure.json | 资料正确性 | 与官方工程结构规范的符合性 |
| findability | findability-rules.json | 资源易找性 | 关键词准确性、外部引用完整性、文档可发现性 |
| completeness | completeness-rules.json | 资源丰富性/完整性 | 示例完整性、关键说明、约束条件、默认行为、关联信息 |
| correctness | correctness-rules.json | 资料正确性 | 版本同步、代码可执行性、JSDOC准确性、路径一致性 |
| clarity | clarity-rules.json | 资源清晰易懂 | 标题-内容匹配、描述准确性、链接完整性、机制说明 |
| capability | capability-rules.json | 能力有效性/易用性/丰富性 | 约束条件、已知问题、命名规范、实用性、替代方案 |
规则管理说明:本 SKILL 的具体检查规则存储在
references/目录下的 JSON 文件中。新增或修改检查规则时,只需编辑对应的规则文件,无需修改 SKILL.md。
检查结果输出为 Excel 表格文件(.xlsx),包含以下列:
| 列名 | 说明 | |------|------| | 文件名 | 被检查的文件路径(只保留最后一个/后的字符) | | Designer | 被检查的文件的设计人<!--Designer: xxx--> | | 问题类型 | 问题所属的质量维度 | | 问题行号 | 问题所在的具体行号 | | 问题原因 | 问题的详细描述 | | 建议修改方案 | 具体的修复建议 | | 问题严重级别 | 优先级分类(严重/高/中/低) |
Excel 报告支持:
详细格式说明和使用指南见:references/excel-format.md
同时生成简要的 Markdown 汇总报告,包含:
置信度和优先级的定义和处理建议见:references/scoring-guide.md
SDK 源码一致性检查是 correctness 维度的核心功能,用于确保文档与 interface_sdk-js 仓库中的 .d.ts 定义文件保持一致。
文档文件与 SDK 文件的映射遵循以下规则:
| 文档文件模式 | SDK 文件路径 | 示例 |
|-------------|-------------|------|
| js-apis-app-ability-{name}.md | api/@ohos.app.ability.{name}.d.ts | js-apis-app-ability-wantAgent.md → @ohos.app.ability.wantAgent.d.ts |
| js-apis-{name}.md | api/@ohos.{name}.d.ts | js-apis-geolocation.md → @ohos.geolocation.d.ts |
| js-apis-inner-{module}-{name}.md | api/{module}/{name}.d.ts | js-apis-inner-wantAgent-wantAgentInfo.md → wantAgent/wantAgentInfo.d.ts |
| js-apis-inner-{module}-{name}-sys.md | api/{module}/{name}.d.ts | js-apis-inner-wantAgent-wantAgentInfo-sys.md → wantAgent/wantAgentInfo.d.ts |
| capi-{name}.md | api/{name}.h | capi-native-bundle.md → native_bundle.h |
SDK 源码一致性检查包括以下 10 个检查点:
| 检查点 | 说明 | 优先级 |
|--------|------|--------|
| api-since-version-match | API 起始版本(文档<sup>X+</sup> vs SDK @since) | Critical |
| param-count-match | 入参数量一致性 | High |
| param-name-match | 入参名称拼写准确性 | High |
| param-type-match | 入参类型一致性 | High |
| return-type-match | 返回值类型一致性 | High |
| systemapi-mark-match | 系统接口标记一致性(-sys vs @systemapi) | High |
| stagemodelonly-mark-match | Stage模型约束标记一致性 | Medium |
| error-code-match | 错误码完整性 | Medium |
| enum-values-complete | 枚举值列举完整性 | Medium |
| interface-fields-complete | 接口字段列举完整性 | Medium |
检查工具会自动尝试从以下位置加载 SDK 源码:
INTERFACE_SDK_JS_PATH 指定的本地路径git clone 临时克隆的仓库(自动清理)配置环境变量(推荐):
export INTERFACE_SDK_JS_PATH=/path/to/interface_sdk-js
{
"id": "{dimension}-XXX",
"name": "rule-name",
"description": "规则描述",
"type": "{dimension}",
"subType": "{subCategory}",
"priority": "high|medium|low",
"confidence": 90,
"enabled": true,
"checkPoints": [...],
"message": "错误消息模板",
"explanation": "详细说明",
"suggestedFix": "修复建议"
}
详细扩展指南和示例见:references/rule-extensions.md
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.
testing
分析 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, 需求提取, 完整性检查, 章节顺序验证
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