agentleFS
DunoDogeDunoDoge/OHOS-Skills/arkts-build/SKILL.md

arkts-build

Skill1 starsChanged 2 months agoMITView on GitHub

Use when building, testing, signing, or deploying HarmonyOS / OpenHarmony apps via command line tools, or when configuring CI pipelines. Triggers include hvigorw, codelinter, hstack, ohpm, assembleHap, assembleApp, assembleHsp, assembleHar, onDeviceTest, buildMode, product, module target, --no-daemon, --mode module, hap-sign-tool, keytool, hdc file send, hdc shell bm install, hdc shell aa start, ohpm install, ohpm publish, ohpm config, code-linter.json5, sourceMap, nameCache, crash stack parsing, CI pipeline, signing, pipeline setup, or any topic under the HarmonyOS Command Line Tools documentation. Loads the offline command-line tools reference set so the agent can give real HarmonyOS commands instead of guessing from npm/gradle knowledge.

The file

We split this skill into the rules it gives an agent

8 rules. About 0 are common, 4 are distinctive, and 4 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Follow this skill's workflow whenever any of the following conditions are met:

    line 21
  2. Distinctive:

    Do not force this skill onto "pure ArkTS syntax/migration", "ArkTS compilation error fixes", or "NDK/C++ interop" scenarios — use the …

    line 34
  3. Very specific:

    Before any build/test/deploy task, you must read references/INDEX.md first.

    line 57
  4. Very specific:

    When reading documents, prefer using Grep/Read with offset/limit to locate specific sections — do not read large files in their entirety at …

    line 73
  5. Distinctive:

    Before writing or modifying build commands, self-check the following high-frequency red lines (detailed rules are subject to the original …

    line 77
  6. Very specific:

    Do not place project paths inside hidden directories: Every level of the project path should not start with ., otherwise the build may …

    line 87
  7. Very specific:

    When uncertain, search the original text in references/04-hvigorw.md or the relevant topic-specific document before writing.

    line 89
  8. Distinctive:

    When answering command/parameter questions, include a citation at the end of the response, e.g.:

    line 93

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

arkts-build

The HarmonyOS command-line toolchain (Command Line Tools, including codelinter, hstack, hvigorw, ohpm, and SDK tools hdc/aa/bm, etc.) is not the same as community npm/gradle/Node tools:

  • hvigorw task names (assembleHap/assembleApp/assembleHsp/assembleHar/onDeviceTest) and parameters (-p product=, -p buildMode=, -p module=, --mode module, --no-daemon) are HarmonyOS-specific — gradle experience does not apply.
  • ohpm is similar to npm but uses different repository URLs (https://ohpm.openharmony.cn/ohpm/), oh-package.json5, strict_ssl, and other configuration options.
  • codelinter's --exit-on exit code calculation (binary bit combinations), code-linter.json5 rule files, and --incremental incremental checks are HarmonyOS-specific.
  • hstack requires sourceMap + nameCache + so archive directories to parse release obfuscated stacks — community sourcemap tools cannot handle HarmonyOS's entry|har|1.0.0|src/... path format.
  • Signing uses hap-sign-tool.jar (ECDSA + .p12/.cer/.p7b), not jarsigner / apksigner.

This skill provides offline reference documents (8 docs + INDEX under references/) which are offline copies of Huawei's official "Command Line Tools" documentation series, serving as the authoritative reference for build/test/deploy tasks.

When to Use This Skill

Follow this skill's workflow whenever any of the following conditions are met:

  • The user requests command-line builds of HarmonyOS projects (hvigorw, assembleHap, assembleApp, assembleHsp, assembleHar, clean, building release/debug packages)
  • The user requests static code analysis (codelinter, CI gates, --exit-on, code-linter.json5, incremental checks)
  • The user requests release crash stack parsing (hstack, sourceMap, nameCache, so archiving, deobfuscation)
  • The user requests third-party dependency management (ohpm install, ohpm publish, ohpm config, oh-package.json5, repository URL configuration)
  • The user requests CI pipeline setup (environment configuration, building, signing, installing & running, offline pipelines)
  • The user requests testing (onDeviceTest, hvigorw test, coverage, ASan)
  • The user requests signing/deployment (hap-sign-tool.jar, keytool, .p12/.cer/.p7b, hdc file send, hdc shell bm install, hdc shell aa start)
  • The user requests emulator command-line usage (Emulator, hdc tconn, gRPC remote service)
  • The user mentions --no-daemon, -p product=, -p buildMode=, -p module=, --mode module, -p coverage=, or other hvigorw parameters
  • The project root contains oh-package.json5 / build-profile.json5 / hvigorw / hvigorfile.ts or other HarmonyOS project markers, and the task is build/test/deploy rather than code authoring

Do not force this skill onto "pure ArkTS syntax/migration", "ArkTS compilation error fixes", or "NDK/C++ interop" scenarios — use the corresponding skills instead (see boundary below).

Boundary with Other Skills

This skill covers "how to invoke command-line tools", not "how to modify code". When build tasks involve the following issues, cross-reference the corresponding skill:

Issue TypeCross-reference SkillBoundary
ArkTS syntax / migration / coding stylearkts-helperThis skill only covers build commands, not ArkTS syntax
ArkTS compilation errors (arkts-no-* rules, etc.)arkts-debugIf a build failure is caused by code errors, use arkts-debug to fix the code first, then return to this skill to rebuild
NDK / C++ / Node-API interoparkts-ndk-devThis skill only covers "how to trigger native builds via hvigorw / syncNative / abiFilters in build-profile.json5" at the command-line level; CMake toolchain variables, .so linking, musl/libc++, and other C++ layer issues belong to arkts-ndk-dev
Tools / options / workflows not covered by offline docsharmony-fetchIf the 8 offline docs in this skill are insufficient to answer a question (e.g., new CLI parameters, new ohpm behavior changes), use harmony-fetch to fetch the latest documentation from the Huawei developer portal
Code compiles but crashes at runtimearkts-crash-diagnosisBuild failures from code errors go to arkts-debug; runtime crashes after a successful build go to arkts-crash-diagnosis
Understanding build config files in an existing projectunderstand-hmos"What does build-profile.json5 / oh-package.json5 mean in this project" belongs to understand-hmos; this skill covers invoking the tools
Creating a new project from scratchcreate-hmos-projectScaffold first with create-hmos-project, then use this skill to build/sign/deploy
Lite Wearable Simulator (仿真器) run/debuglite-simulator-debugThe standard-system Emulator command-line docs live here (08-emulator.md); running/debugging Lite Wearable apps on the DevEco Studio Simulator (仿真器) belongs to lite-simulator-debug
Atomic Service (元服务) packaging / size-limit failuresatomic-service-devhvigorw / hap-sign-tool invocation stays here; atomic-service packaging constraints (分包 2MB per-package / 10MB total caps, atomicService.preloads, feature-module ban) belong to atomic-service-dev
ArkUI-X cross-platform builds (APK/IPA/AAR/Framework, ACE Tools, rom size)arkui-x-devHarmonyOS toolchain invocation (hvigorw / hap-sign-tool / hdc) stays here; building the Android/iOS outputs of an ArkUI-X project (ace build apk/hap/ios, DevEco Build APP(s), rom size analysis) belongs to arkui-x-dev

Workflow (Follow Strictly)

1. Read the Index First, Then Decide Which Doc to Load

Before any build/test/deploy task, you must read references/INDEX.md first. It provides the role of each of the 8 documents, reading paths by task type, and key command quick references — this prevents loading the entire reference directory into context.

2. Load the Corresponding Document by Task Type

Task TypeRequired Reading (under references/)
Tool acquisition / environment variable configuration01-command-line-tools-overview.md
Code static analysis / CI gates02-codelinter.md
Release crash stack parsing03-hstack.md
hvigorw build commands / build parameters04-hvigorw.md
ohpm install / publish / dependency management05-ohpm.md
CI pipeline setup / post-build signing, install & run06-building-app.md (+ 04-hvigorw.md)
Device debugging commands (hdc/aa/bm, etc.)07-debugging-commands.md (+ the "Running Applications" section in 06-building-app.md)
Emulator usage08-emulator.md
Testing (onDeviceTest / Local Test)The "Test Commands" section in 04-hvigorw.md

When reading documents, prefer using Grep/Read with offset/limit to locate specific sections — do not read large files in their entirety at once.

3. Strictly Enforce Red Lines When Issuing Commands

Before writing or modifying build commands, self-check the following high-frequency red lines (detailed rules are subject to the original documentation):

  • CI builds must add --no-daemon: Command-line mode (especially CI) recommends disabling the daemon process to avoid state residue
  • -p module= must be paired with --mode module: The -p module={ModuleName}@{TargetName} parameter requires --mode module to take effect
  • Run ohpm install before building: You need to run ohpm install in both the project root and each module directory to install project-level and module-level third-party dependencies
  • Release stack parsing requires sourceMap + nameCache: hstack's -s (sourceMap) and --so (shared object) require at least one; method name deobfuscation requires both sourceMap and nameCache
  • Signing trio: .p12 / .cer / .p7b: Signing requires a key (.p12), digital certificate (.cer), and Profile (.p7b); HAP pushed to a device must carry signature information
  • Output path patterns: Hap output is at ${PROJECT_PATH}/{moduleName}/build/{productName}/outputs/{targetName}/xxx.hap; App output is at ${PROJECT_PATH}/build/outputs/{productName}/xxx.app
  • Check version first with hvigorw -v: buildInfo (5.18.4+), ohos-debug-asan (5.19.0+), --optimization-strategy (5.19.2+), --analyze=ultrafine (6.0.0+), -p buildVersion= (6.23.3+) and other commands have version requirements
  • Confirm OS for platform differences: Environment variable configuration differs across Windows/macOS/Linux (PATH separators, Node path differences: Windows uses tool/node, Linux/macOS uses tool/node/bin) — confirm the user's OS before providing environment variable commands
  • Do not place project paths inside hidden directories: Every level of the project path should not start with ., otherwise the build may package module code and configuration files as resources into the output

When uncertain, search the original text in references/04-hvigorw.md or the relevant topic-specific document before writing.

4. Cite the Source When Referencing Documents

When answering command/parameter questions, include a citation at the end of the response, e.g.:

Per the "Common Extension Parameters for Build" section in references/04-hvigorw.md and the "Running Hvigor Commands for Build" example in references/06-building-app.md.

This allows users to quickly verify against the original text.

5. Do Not Skip or Replace This Skill's Checks

Even if the user's build request "looks like something gradle/npm can handle", in the HarmonyOS context you must verify commands against this skill before answering — do not assume gradle/npm knowledge can be directly applied.

High-Frequency Command Quick Reference

ScenarioCommand
Clean build outputshvigorw clean --no-daemon
Build Hap (debug)hvigorw assembleHap --mode module -p product=default -p buildMode=debug --no-daemon
Build Hap (release)hvigorw assembleHap --mode module -p product=default -p buildMode=release --no-daemon
Build Apphvigorw assembleApp --mode project -p product=default -p buildMode=release --no-daemon
Build Hsphvigorw assembleHsp --mode module -p module=library@default -p product=default --no-daemon
Build Harhvigorw assembleHar --mode module -p module=library1@default -p product=default --no-daemon
Install dependenciesohpm install / ohpm install --all
Publish harohpm publish pkg.har
Configure ohpm repositoryohpm config set registry https://ohpm.openharmony.cn/ohpm/
Code analysiscodelinter / codelinter -c code-linter.json5 -f json -o report.json --exit-on error
Incremental checkcodelinter -i
Check and fixcodelinter -c filepath --fix
Stack parsinghstack -i D:\crashDir -o D:\outputDir -s D:\sourcemapDir --so D:\soDir -n D:\nameCacheDir
On-device testhvigorw onDeviceTest -p module={moduleName} -p coverage=true -p scope={suiteName}#{methodName}
Local testhvigorw test -p module={moduleName} -p coverage=true -p scope={suiteName}#{methodName}
Push HAPhdc file send "xxx.hap" "data/local/tmp/xxx.hap"
Install HAPhdc shell bm install -p "data/local/tmp/xxx.hap"
Launch apphdc shell aa start -a EntryAbility -b com.example.myapplication -m entry
Sign HAPjava -jar hap-sign-tool.jar sign-app -keyAlias "demo_key" -signAlg "SHA256withECDSA" -mode "localSign" -appCertFile "/path/demo.cer" -profileFile "/path/demo.p7b" -inFile "/path/hap-unsigned.hap" -keystoreFile "/path/demo.p12" -outFile "/path/hap-signed.hap" -keyPwd "123456Abc" -keystorePwd "123456Abc"

Directory Structure

arkts-build/
├── SKILL.md                                          # This file
└── references/
    ├── INDEX.md                                      # Must read first
    ├── 01-command-line-tools-overview.md             # Command Line Tools acquisition & env config
    ├── 02-codelinter.md                              # Code linter (codelinter)
    ├── 03-hstack.md                                  # Crash stack parser (hstack)
    ├── 04-hvigorw.md                                 # Command-line build tool (hvigorw)
    ├── 05-ohpm.md                                    # Third-party dependency manager (ohpm)
    ├── 06-building-app.md                            # CI pipeline setup
    ├── 07-debugging-commands.md                      # SDK CLI tools & debugging command index
    └── 08-emulator.md                                # Emulator tool

Documentation Source & Maintenance

  • Upstream: Huawei Developer official site "Documentation Center › Application Development › Command Line Tools" series, under https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/:
    • ide-commandline-get (acquiring Command Line Tools)
    • ide-command-line-codelinter (codelinter)
    • ide-command-line-hstack (hstack)
    • ide-hvigor-commandline (hvigorw)
    • ide-ohpm-cli / ide-ohpm-common-commands (ohpm)
    • ide-command-line-building-app (CI pipeline setup)
    • debugging-commands (debugging commands)
    • ide-commandline-emulator (Emulator)
  • Documents are offline snapshots taken on 2026-07-20; each document includes the upstream URL and fetch timestamp at the top.
  • To update to the latest version, re-run the fetch (use curl/WebFetch from the upstream URLs to overwrite files in references/); if expanding the file list, also update references/INDEX.md.
  • Command version differences are subject to the official documentation: commands and parameters for hvigorw / codelinter / ohpm may change with HarmonyOS version updates; if uncertain, first check the version with hvigorw -v / codelinter -v / ohpm -v.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.