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
testing
--- 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
development
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.
testing
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).
testing
--- 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