skills/openharmony-build/SKILL.md
Use for OpenHarmony build execution and diagnosis, including 编译OpenHarmony/完整代码/测试/SDK/host/最小模拟器/全量模拟器/部件独立编译/测试列表, plus full product builds, targeted component/test builds, fast rebuilds, hb independent builds, and build.log failure analysis.
npx skillsauth add openharmonyinsight/openharmony-skills openharmony-buildInstall 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.
Use this skill for OpenHarmony build execution, targeted build verification, and build-log diagnosis. Keep context small: start here, then load only the reference that matches the task.
<skill-dir> means the directory containing this SKILL.md.
.gn and build.sh.repo sync, source download, prebuilt download, or environment bootstrap unless the user explicitly asks for setup; these are slow and can mutate the workspace.build.log exists; the primary log is the source of truth.hb build component name without checking; independent builds require OpenHarmony component names.out/, generated artifacts, or test binaries. Ask first unless the user requested cleanup; for test-list disk pressure, only use the path in references/test-list-builds.md.Use this root test:
find_oh_root() {
local dir="${1:-$PWD}"
while [[ "$dir" != "/" ]]; do
if [[ -f "$dir/.gn" && -f "$dir/build.sh" ]]; then
echo "$dir"
return 0
fi
dir="$(dirname "$dir")"
done
return 1
}
Default full build:
./build.sh --export-para PYCACHE_ENABLE:true --product-name rk3568 --ccache
Targeted build:
./build.sh --export-para PYCACHE_ENABLE:true --product-name <product> --build-target <target> --ccache
Special products:
./build.sh --export-para PYCACHE_ENABLE:true --product-name ohos-sdk --ccache./build.sh --product-name host_product --ccache --no-prebuilt-sdk./build.sh --product-name qemu-arm-linux-min --ccache --no-prebuilt-sdk --deps-guard=false --load-test-config false --gn-args linux_kernel_version=\"linux-5.10\"./build.sh --product-name arm64_virt --ccache --deps-guard=falseRead references/build-commands.md for the full command matrix, products, targets, SDK/host/emulator notes, and fast-rebuild examples.
Reference routing:
references/build-commands.md when choosing command syntax, products, targets, SDK/host/emulator commands, or fast-rebuild examples.references/log-locations.md only when locating or explaining build outputs and logs.references/common-errors.md only after a concrete error class is known.Use --fast-rebuild only when build configuration did not change. Do not use it after edits to BUILD.gn, *.gni, product config, dependency metadata, or first-time output generation.
Helper:
bash <skill-dir>/scripts/check_fast_rebuild.sh 30 "$OH_ROOT"
Use for "部件独立编译", "独立编译部件", or explicit hb build requests.
command -v hb
hb build <component-name> -i
hb build <component-name> -t
Rules:
-i or -t after the component name.-i before -t when both are requested.out/standard/.Reference routing: for hb independent builds, always read references/independent-build.md; do not load references/test-list-builds.md unless the task is specifically about target-list builds.
For ACE Engine development, prefer:
./build.sh --export-para PYCACHE_ENABLE:true --product-name rk3568 --build-target ace_engine_test --ccache
Build all unit tests only when requested or required:
./build.sh --export-para PYCACHE_ENABLE:true --product-name rk3568 --build-target unittest --ccache
For target-list builds:
bash <skill-dir>/scripts/build_test_list.sh rk3568 "$OH_ROOT"
Reference routing: for target-list builds, read references/test-list-builds.md; do not load references/independent-build.md unless the target-list run uses hb build.
A successful build usually has:
0=====build successful===== or equivalent success outputout/Use exit code as the first signal. Check artifacts only when the user needs artifact confirmation.
Always start from the primary log:
out/<product>/build.logout/sdk/build.logout/host/host_product/build.logout/standard/build.log or the relevant out/standard/ sublogUse scripts before broad manual searching:
bash <skill-dir>/scripts/resolve_build_log.sh <product> "$OH_ROOT"
bash <skill-dir>/scripts/find_recent_errors.sh <product> "$OH_ROOT"
bash <skill-dir>/scripts/analyze_build_error.sh <product> "$OH_ROOT"
For hb build failures, pass standard as the product:
bash <skill-dir>/scripts/find_recent_errors.sh standard "$OH_ROOT"
bash <skill-dir>/scripts/analyze_build_error.sh standard "$OH_ROOT"
Reference routing:
references/failure-analysis.md for non-zero build exits, first-failure extraction, and fix/rebuild workflow.references/log-locations.md when the log path is unclear.references/common-errors.md only after identifying the error class.Scripts:
scripts/resolve_build_log.sh: print the primary build log for a product/root.scripts/analyze_build_error.sh: summarize failures from the primary log.scripts/find_recent_errors.sh: quick recent error scan.scripts/check_fast_rebuild.sh: decide whether --fast-rebuild is appropriate.scripts/build_test_list.sh: build targets listed in unittest_targets.txt.References:
references/build-commands.md: complete command reference.references/log-locations.md: output and log path mapping.references/common-errors.md: common failure classes and fixes.references/failure-analysis.md: structured diagnosis workflow.references/independent-build.md: hb build rules and diagnosis patterns.references/test-list-builds.md: target-list builds and disk-space recovery.Do not load README.md or examples/example-workflow.md during normal skill execution; they are repository-facing summaries, not runtime instructions.
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