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.
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