android2harmony 0.1.0 → 0.1.2

package/skills/hmos-convert-pipeline/SKILL.md

@@ -48,15 +48,15 @@ Define shorthand variables for the instructions below:
 
 ## Environment Variables Check (run before Stage 1)
 
-The pipeline's sub-agents resolve each setting along the standard chain — **OS environment variable first, then `~/.hometrans/config.json`, then ask the user**. Verify upfront so the long pipeline fails fast (read env vars with `echo "$VAR"` on macOS/Linux; `$env:VAR` in PowerShell on Windows):
+The pipeline's sub-agents resolve each setting from the **OS environment variable** — then ask the user if unset. Verify upfront so the long pipeline fails fast (read env vars with `echo "$VAR"` on macOS/Linux; `$env:VAR` in PowerShell on Windows):
 
-| Variable | config.json fallback | Needed for | Valid when |
-|---|---|---|---|
-| `DEVECO_HOME` *(or `DEVECO_SDK_HOME`)* | `env.DEVECO_HOME` / `env.DEVECO_SDK_HOME` | Stage 2 build + Stage 3b/4b rebuilds | resolves to a valid DevEco install |
-| `HOMETRANS_MODEL_API_KEY` *(legacy `TEST_API_KEY` still honored as a fallback)* | `autotest.unified_model.api_key` | Stage 4 self-test (only when `SKIP_TEST=false`) | non-empty / not the placeholder |
-| `HOMETRANS_TOOL_PATH` | `env.HOMETRANS_TOOL_PATH` (defaults to `~/.hometrans/tools`) | Stage 4 self-test AutoTest dir | path exists on disk |
+| Variable | Needed for | Valid when |
+|---|---|---|
+| `DEVECO_SDK_HOME` | Stage 2 build + Stage 3b/4b rebuilds | resolves to a valid DevEco install (derive the install root as its parent dir) |
+| `HOMETRANS_MODEL_API_KEY` | Stage 4 self-test (only when `SKIP_TEST=false`) | non-empty / not the placeholder |
+| `HOMETRANS_TOOL_PATH` | Stage 4 self-test AutoTest dir | path exists on disk; if unset, the self-test stage resolves the bundled AutoTest tools dir itself |
 
-For each value, if the env var is unset, fall back to the listed `~/.hometrans/config.json` field. If neither yields a value: for the DevEco path / model api_key, **ask the user** (for the api_key they may instead pass `skip_test=true`). Suggest running `ht init` to persist these as machine environment variables.
+For each value, if the env var is unset, **ask the user**: for the DevEco path / model api_key, **ask the user** (for the api_key they may instead pass `skip_test=true`). Suggest setting the corresponding machine environment variable directly (`DEVECO_SDK_HOME` / `HOMETRANS_MODEL_API_KEY` / `HOMETRANS_TOOL_PATH`).
 
 ---
 
@@ -163,15 +163,15 @@ For the Stage 4 loop, combine test and fix results into one row per round plus o
 Several stages below need the **full signed package set** — the entry HAP plus any in-app HSPs (and any feature HAP the build freshly produced) — so the self-tester installs them in one `hdc install -r` transaction (in-app HSPs cannot install standalone). Those stages call this procedure.
 
 **Inputs:**
-- `BUILD_ROOT` — the project root build-fixer compiled (= `HMOS`).
-- `DEST` — a dedicated `package-set/` directory to populate; **must never be the directory build-fixer copied the entry HAP into** (step 1 clears `DEST`).
-- `BUILD_START` — a marker captured **immediately before** launching build-fixer, e.g. `touch "<DEST>/../.build_start_marker"` (or record a timestamp). Used to tell freshly-rebuilt artifacts from stale ones. A touched marker + `find -newer` avoids clock-skew between the agent and the build host.
-- `AUTHORITATIVE_ENTRY` — the entry HAP build-fixer **copied** to this stage's output dir (the `*-signed.hap` it placed). Authoritative **by construction**, regardless of mtime.
+- `BUILD_ROOT` — the project root rebuilt by `hmos-fix-build-errors` (= `HMOS`).
+- `DEST` — a dedicated `package-set/` directory to populate; **must never be the directory where you mirror the authoritative entry HAP** (step 1 clears `DEST`).
+- `BUILD_START` — a marker captured **immediately before** invoking the build stage, e.g. `touch "<DEST>/../.build_start_marker"` (or record a timestamp). Used to tell freshly-rebuilt artifacts from stale ones. A touched marker + `find -newer` avoids clock-skew between the build stage and the host.
+- `AUTHORITATIVE_ENTRY` — the authoritative signed entry HAP resolved directly from `HMOS/entry/build/default/outputs/default/` after `hmos-fix-build-errors` succeeds. Once resolved for the stage, treat it as authoritative regardless of mtime.
 
 **Procedure:**
-1. **Clear/create `DEST`** (remove prior contents, recreate) so stale packages never leak forward. `DEST` is a dedicated `package-set/` subdir, distinct from where build-fixer copied the entry.
-2. **Place the authoritative entry:** copy `AUTHORITATIVE_ENTRY` into `DEST`. Included **unconditionally — the mtime gate does NOT apply to the entry** (an incremental build may leave the build-tree entry UP-TO-DATE; build-fixer's copy still reflects the round's code).
-3. **Discover non-entry outputs** under depth-1 modules `BUILD_ROOT/*/build/default/outputs/default/`, admitting **only files with mtime ≥ `BUILD_START`** (freshly rebuilt this invocation; cross-platform: `find "<dir>" -newer "<marker>"` or compare `stat` mtimes). build-fixer runs **no clean**, so non-entry dirs still hold *prior*-build packages — the mtime gate is the only reliable way to reject those stale artifacts:
+1. **Clear/create `DEST`** (remove prior contents, recreate) so stale packages never leak forward. `DEST` is a dedicated `package-set/` subdir, distinct from the location where you mirror the authoritative entry for this stage.
+2. **Place the authoritative entry:** copy `AUTHORITATIVE_ENTRY` into `DEST`. Included **unconditionally — the mtime gate does NOT apply to the entry** (an incremental build may leave the build-tree entry UP-TO-DATE, but the resolved entry HAP still reflects the current build result).
+3. **Discover non-entry outputs** under depth-1 modules `BUILD_ROOT/*/build/default/outputs/default/`, admitting **only files with mtime ≥ `BUILD_START`** (freshly rebuilt this invocation; cross-platform: `find "<dir>" -newer "<marker>"` or compare `stat` mtimes). Incremental rebuilds run **no clean**, so non-entry dirs still hold *prior*-build packages — the mtime gate is the only reliable way to reject those stale artifacts:
    - **HSPs:** `*-signed.hsp` (the fresh in-app HSPs).
    - **Feature HAPs:** `*-signed.hap` from non-entry modules the build freshly rebuilt; skip any whose basename equals `AUTHORITATIVE_ENTRY`'s.
 4. **Exclude test artifacts:** skip `*ohosTest*` and `*-test-signed.*`.
@@ -216,12 +216,12 @@ Prompt format (applies to both Stage 1 and Stage 1a): ONLY the key-value lines b
 
 ### Stage 2 — Compilation and Build
 
-1. Launch the **build-fixer** agent with `--signed`.
-2. Input: `harmony_project_dir`: `HMOS`, `output_path`: `OUTPUT`.
-3. The agent runs the build-fix loop (up to 20 iterations), writes `build-fix-report.md` into `OUTPUT`.
-4. If the build succeeds, the signed `.hap` is copied to `OUTPUT`. Note its location in the manifest.
-5. **If the build succeeded**, run **Package-Set Collection** with `BUILD_ROOT = HMOS`, `DEST = OUTPUT/package-set/`, `AUTHORITATIVE_ENTRY =` the `*-signed.hap` build-fixer just copied to `OUTPUT/` (step 4), and `BUILD_START` captured just before launching build-fixer (step 1). Record the inventory in the manifest. (If the build failed there is no fresh entry to collect; collection's ≥1-`.hap` guard fails and Stage 4 Loop Setup's legacy fallback applies. The step-4 entry-HAP copy is retained for the manifest / back-compat.)
-6. After the agent completes, read `OUTPUT/build-fix-commit-info.md` and note the commit ID (may be a real hash or `none`). 
+1. Invoke the `hmos-fix-build-errors` skill for a signed build of `HMOS`.
+2. Capture `BUILD_START` just before invoking the skill.
+3. Treat the build stage as a compile/fix gate only — do **not** expect build-stage report or commit-info artifacts.
+4. After a successful build, resolve `AUTHORITATIVE_ENTRY` directly from `HMOS/entry/build/default/outputs/default/` (prefer `entry-default-signed.hap`, else the first `*-signed.hap`) and note it in the manifest.
+5. **If the build succeeded**, run **Package-Set Collection** with `BUILD_ROOT = HMOS`, `DEST = OUTPUT/package-set/`, the resolved `AUTHORITATIVE_ENTRY`, and the captured `BUILD_START`. Record the inventory in the manifest. (If the build failed there is no fresh entry to collect; collection's ≥1-`.hap` guard fails and Stage 4 Loop Setup's legacy fallback applies.)
+6. Do not read a build-stage commit-info file; `OUTPUT/commit-info.md` from Stage 1a remains the canonical commit handoff for later review stages.
 
 ### Stage 3 — Code Review Loop (Review-and-Fix → Rebuild)
 
@@ -231,7 +231,7 @@ Treat Stage 3 → 3b as a loop that runs up to `MAX_ROUNDS_REVIEW` times. `code-
 
 1. **Resolve the initial commit ID for code review** using the following priority:
    - Read `OUTPUT/commit-info.md` (written by Stage 1a) and use its `commit_id` when available.
-   - IMPORTANT: Use `commit-info.md` from Stage 1a, NOT `build-fix-commit-info.md` from Stage 2.
+   - IMPORTANT: Use `commit-info.md` from Stage 1a. The build stage no longer produces a separate commit-info artifact.
    - Store this as `REVIEW_COMMIT_ID`.
 2. Initialize loop state:
    - `review_round = 1`
@@ -267,14 +267,13 @@ For each `review_round` from `1..MAX_ROUNDS_REVIEW`, set `REVIEW_ROUND_DIR = OUT
 ##### Review Round Step B — Stage 3b Rebuild after Review Fix
 
 1. Mark Stage 3b `in_progress` when the first Stage 3b round begins.
-2. Capture `BUILD_START` (touch a marker), then launch the **build-fixer** agent with `--signed`.
-3. Input: `harmony_project_dir`: `HMOS`, `output_path`: `REVIEW_ROUND_DIR`.
-4. The agent writes `REVIEW_ROUND_DIR/build-fix-report.md`.
-5. If the build succeeds, the signed `.hap` is copied to `REVIEW_ROUND_DIR`. Note its location in the manifest. **Then run Package-Set Collection** with `BUILD_ROOT = HMOS`, `DEST = REVIEW_ROUND_DIR/package-set/`, `AUTHORITATIVE_ENTRY =` the `*-signed.hap` build-fixer copied to `REVIEW_ROUND_DIR/`, and the captured `BUILD_START`; on success set `LAST_GOOD_REVIEW_SET = REVIEW_ROUND_DIR/package-set/`. **If the 3b build failed, do NOT run collection and keep the previous `LAST_GOOD_REVIEW_SET`** (a failed rebuild leaves stale sibling-module outputs on disk; the mtime gate already prevents harvesting them, and skipping collection avoids re-touching `LAST_GOOD_REVIEW_SET` with an entry-less set).
-6. Append one Defect Summary row for this round using the parsed Stage 3 stats, labeled `3 Loop - Round {review_round}`.
-7. Update the Stage 3b task description with a brief round summary (for example: `Round 1: build success`).
-8. Increment `review_rounds_executed`.
-9. **Loop stop decision** (after 3b completes):
+2. Capture `BUILD_START` (touch a marker), then invoke the `hmos-fix-build-errors` skill for a signed rebuild of `HMOS`.
+3. Treat this as a compile/fix gate only — do **not** expect a rebuild report artifact in `REVIEW_ROUND_DIR`.
+4. If the build succeeds, resolve `AUTHORITATIVE_ENTRY` directly from `HMOS/entry/build/default/outputs/default/` (prefer `entry-default-signed.hap`, else the first `*-signed.hap`), note it in the manifest, and **then run Package-Set Collection** with `BUILD_ROOT = HMOS`, `DEST = REVIEW_ROUND_DIR/package-set/`, the resolved `AUTHORITATIVE_ENTRY`, and the captured `BUILD_START`; on success set `LAST_GOOD_REVIEW_SET = REVIEW_ROUND_DIR/package-set/`. **If the 3b build failed, do NOT run collection and keep the previous `LAST_GOOD_REVIEW_SET`** (a failed rebuild leaves stale sibling-module outputs on disk; the mtime gate already prevents harvesting them, and skipping collection avoids re-touching `LAST_GOOD_REVIEW_SET` with an entry-less set).
+5. Append one Defect Summary row for this round using the parsed Stage 3 stats, labeled `3 Loop - Round {review_round}`.
+6. Update the Stage 3b task description with a brief round summary (for example: `Round 1: build success`).
+7. Increment `review_rounds_executed`.
+8. **Loop stop decision** (after 3b completes):
     - If `review_stop_reason` was already set to `no_progress` in Step A, exit the loop.
     - Else if `review_round == MAX_ROUNDS_REVIEW`, set `review_stop_reason = max_rounds_reached` and exit the loop.
     - Else continue to the next round.
@@ -292,7 +291,6 @@ After the review loop exits:
 3. Mirror the final review round outputs back to the root `OUTPUT` directory using the canonical filenames for backward compatibility:
    - `OUTPUT/code-review-report.md`
    - `OUTPUT/code-review-commit-info.md`
-   - `OUTPUT/build-fix-report.md` (overwrites Stage 2 report, if 3b ran in the final round)
    - If the final round's build produced a signed `.hap`, copy it to `OUTPUT` (replaces Stage 2 `.hap` if present).
    - **Mirror the package set:** if `LAST_GOOD_REVIEW_SET != none` (some review round rebuilt successfully), clear-then-copy `LAST_GOOD_REVIEW_SET` → `OUTPUT/package-set/`. **If `LAST_GOOD_REVIEW_SET == none`, leave `OUTPUT/package-set/` (the Stage-2 set) untouched — never clear it.** No self-copy guard is needed: `LAST_GOOD_REVIEW_SET` is always a `review-round-*/package-set/`, never `OUTPUT/package-set/`.
 4. Mark Stage 3 / 3b `completed` only after the full loop finishes.
@@ -346,7 +344,7 @@ For each `round` from `1..MAX_ROUNDS_TEST`, set `ROUND_DIR = OUTPUT/round-{round
    - `output_path`: `OUTPUT` (still the ROOT)
    - `setup`: `false`
 5. The agent verifies device connectivity, invokes `ht autotest selftest run` to install the HAP and run test cases. **Pre-cases are folded into `OUTPUT/testcases.json` by the agent's S4/S5 step during round 1's `setup: true` invocation; they run first in the same batch — no separate pre-case file or parameter is needed downstream.** The agent writes `OUTPUT/self-test-report.md`, `OUTPUT/task/`, and (round 1 only) `OUTPUT/testcases.json` + `OUTPUT/app-metadata.json` + `OUTPUT/_extracted.json`.
-6. After round 1's agent returns, read `OUTPUT/app-metadata.json` and extract `project_root` → `PROJECT_ROOT`. For round 2+, re-read `OUTPUT/app-metadata.json` before invoking the agent; if the previous round's `OUTPUT/round-{round-1}/app-metadata.json` exists (build-fixer may have written one for a relocated project root), the round-dir copy overrides the root copy for this round.
+6. After round 1's agent returns, read `OUTPUT/app-metadata.json` and extract `project_root` → `PROJECT_ROOT`. For round 2+, re-read `OUTPUT/app-metadata.json` before invoking the agent; if the previous round's `OUTPUT/round-{round-1}/app-metadata.json` exists (a previous rebuild step may have written one for a relocated project root), the round-dir copy overrides the root copy for this round.
 7. Snapshot per-round artifacts to `ROUND_DIR` after the agent returns: copy `OUTPUT/self-test-report.md` → `ROUND_DIR/self-test-report.md`, `OUTPUT/task/` → `ROUND_DIR/task/`, and (round 1 only) `OUTPUT/_extracted.json` → `ROUND_DIR/_extracted.json`. Skip any source that is missing.
 8. Read `ROUND_DIR/self-test-report.md` and extract total cases, passed, failed, and pass rate when the report exists.
 9. Compute `round_all_passed` only when the report can be parsed clearly and:
@@ -376,14 +374,13 @@ For each `round` from `1..MAX_ROUNDS_TEST`, set `ROUND_DIR = OUTPUT/round-{round
 ##### Round Step C — Stage 4b Rebuild after Self-Test Fix
 
 1. Mark Stage 4b `in_progress` when the first Stage 4b round begins.
-2. Capture `BUILD_START` (touch a marker), then launch the **build-fixer** agent with `--signed`.
-3. Input: `harmony_project_dir`: `HMOS`, `output_path`: `ROUND_DIR`.
-4. The agent writes `ROUND_DIR/build-fix-report.md`.
-5. ⚠️ **CRITICAL — Update `CURRENT_HAP` for the next round**: If the build succeeds, the signed `.hap` is copied to `ROUND_DIR`. **Run Package-Set Collection** with `BUILD_ROOT = HMOS`, `DEST = ROUND_DIR/package-set/`, `AUTHORITATIVE_ENTRY =` the `*-signed.hap` build-fixer copied to `ROUND_DIR/` (`entry-default-signed.hap`, else first `ROUND_DIR/*-signed.hap`), and the captured `BUILD_START`; then set `CURRENT_HAP = ROUND_DIR/package-set/` so the next round's Stage 4 self-tester uses the freshly built set. If collection **fails** or yields zero HAPs (e.g. build-fixer placed no entry), **keep the previous `CURRENT_HAP`** (the prior round's full set — fresher than any legacy single-file resolution) and record that this round produced no fresh package set.
-6. Append one Defect Summary row for this round by combining the parsed Stage 4 and Stage 4a results into a single row labeled `4 Loop - Round {round}`.
-7. Update the Stage 4b task description with a brief round summary (for example: `Round 1: build success, hap=...`).
-8. Increment `rounds_executed`.
-9. **Loop stop decision** (after 4b completes):
+2. Capture `BUILD_START` (touch a marker), then invoke the `hmos-fix-build-errors` skill for a signed rebuild of `HMOS`.
+3. Treat this as a compile/fix gate only — do **not** expect rebuild-stage report or commit-info artifacts in `ROUND_DIR`.
+4. ⚠️ **CRITICAL — Update `CURRENT_HAP` for the next round**: If the build succeeds, resolve `AUTHORITATIVE_ENTRY` directly from `HMOS/entry/build/default/outputs/default/` (prefer `entry-default-signed.hap`, else the first `*-signed.hap`), **run Package-Set Collection** with `BUILD_ROOT = HMOS`, `DEST = ROUND_DIR/package-set/`, that resolved `AUTHORITATIVE_ENTRY`, and the captured `BUILD_START`, and then set `CURRENT_HAP = ROUND_DIR/package-set/` so the next round's Stage 4 self-tester uses the freshly built set. If collection **fails** or yields zero HAPs, **keep the previous `CURRENT_HAP`** (the prior round's full set — fresher than any legacy single-file resolution) and record that this round produced no fresh package set.
+5. Append one Defect Summary row for this round by combining the parsed Stage 4 and Stage 4a results into a single row labeled `4 Loop - Round {round}`.
+6. Update the Stage 4b task description with a brief round summary (for example: `Round 1: build success, hap=...`).
+7. Increment `rounds_executed`.
+8. **Loop stop decision** (after 4b completes):
     - If `round_all_passed == true`, set `stop_reason = all_passed` and exit the loop.
     - Else if `round_no_confirmed_defects == true`, set `stop_reason = no_confirmed_defects` and exit the loop. Rationale: all failures were judged as false positives (AutoTest limitations / environment issues) by white-box review, no code was changed, so repeating the test would yield identical results.
     - Else if `round == MAX_ROUNDS_TEST`, set `stop_reason = max_rounds_reached` and exit the loop.
@@ -399,11 +396,9 @@ After the loop exits:
    - `Rounds executed: rounds_executed`
    - `Stop reason: stop_reason` — one of: `all_passed` (all tests green), `no_confirmed_defects` (failures exist but all judged as false positives by white-box review), `max_rounds_reached` (hit the round limit with real defects remaining)
    - `Final round: round-{rounds_executed}`
-3. Mirror the final round's `OUTPUT/round-{rounds_executed}/` Fix/Build artifacts back to `OUTPUT/` root using the canonical filenames (the test report and `task/` are already at `OUTPUT/` root as the latest copies — they do NOT need mirroring):
+3. Mirror the final round's `OUTPUT/round-{rounds_executed}/` Fix artifacts back to `OUTPUT/` root using the canonical filenames (the test report and `task/` are already at `OUTPUT/` root as the latest copies — they do NOT need mirroring):
    - `OUTPUT/self-test-fix-report.md` ← `OUTPUT/round-{rounds_executed}/self-test-fix-report.md` (if present)
-   - `OUTPUT/build-fix-report.md` ← `OUTPUT/round-{rounds_executed}/build-fix-report.md` (if present)
    - `OUTPUT/self-test-fix-commit-info.md` ← `OUTPUT/round-{rounds_executed}/self-test-fix-commit-info.md` (if present)
-   - `OUTPUT/build-fix-commit-info.md` ← `OUTPUT/round-{rounds_executed}/build-fix-commit-info.md` (if present)
    - **Final package set** — branch on the type of `CURRENT_HAP`:
      - **If `CURRENT_HAP` is a directory** (a `package-set/`): mirror `CURRENT_HAP/` → `OUTPUT/package-set/` (clear-then-copy), **but skip entirely when `CURRENT_HAP` already resolves to `OUTPUT/package-set/`** (source == dest — happens when every 4b build failed and `CURRENT_HAP` still holds the Loop-Setup value; a clear-then-copy onto itself would destroy the set). Then, best-effort, copy the single `entry-*.hap` out of the set to `OUTPUT/entry-default-signed.hap` for back-compat (skip if absent).
      - **If `CURRENT_HAP` is a single file** (legacy fallback — no package set was ever produced): copy it to `OUTPUT/entry-default-signed.hap`, skipping when `CURRENT_HAP` is already that path. Do not attempt a directory mirror.

package/skills/hmos-fix-build-errors/SKILL.md

@@ -29,11 +29,10 @@ Note: `--signed` is a positional-order-independent flag — when `deveco_studio_
 
 1. **Verify project exists** — Check that `harmony_project_dir` contains a valid HarmonyOS project (look for `build-profile.json5`, `entry/src` directory, `oh-package.json5`).
 
-2. **Resolve `<deveco-path>`** — follow the standard config chain, stopping at the first source that yields a valid path:
+2. **Resolve `<deveco-path>`** — follow the resolution chain, stopping at the first source that yields a valid path (environment variable only, else ask):
    1. `deveco_studio_path` if provided (and not `--signed`).
-   2. **OS environment variables** (`echo "$VAR"` on macOS/Linux; `$env:VAR` in PowerShell on Windows): `DEVECO_HOME` → parent of `DEVECO_SDK_HOME` → strip the trailing `/sdk/default/openharmony/ets` from `OHOS_SDK_PATH` (legacy).
-   3. **`~/.hometrans/config.json`** — read `env.DEVECO_HOME`, else parent of `env.DEVECO_SDK_HOME` (written by `ht init`).
-   4. **Ask the user** for the DevEco Studio install path (suggest running `ht init` to persist it as an environment variable).
+   2. **OS environment variable** `DEVECO_SDK_HOME` (`echo "$DEVECO_SDK_HOME"` on macOS/Linux; `$env:DEVECO_SDK_HOME` in PowerShell on Windows) — the DevEco SDK root (e.g. `D:/DevEco Studio/sdk`); derive `<deveco-path>` as its parent directory (the DevEco Studio install root).
+   3. **Ask the user** for the DevEco Studio install path (suggest setting `DEVECO_SDK_HOME` as a machine environment variable).
 
    **Verify the resolved `<deveco-path>`** contains:
    - `tools/node/node.exe`
@@ -49,16 +48,11 @@ Note: `--signed` is a positional-order-independent flag — when `deveco_studio_
    ```
    Create it if missing. Use forward slashes in the path.
 
-4. **Run `ohpm install`** — Install dependencies before first build:
-   ```bash
-   cd "<project-dir>"
-   export PATH="<deveco-path>/tools/ohpm/bin:$PATH"
-   "<deveco-path>/tools/ohpm/bin/ohpm" install
-   ```
+4. **Use `npx --yes devecocli build` as the build entrypoint** — The build-fix loop should call `npx --yes devecocli build` rather than invoking `ohpm` or `hvigorw.js` directly. `npx --yes devecocli build` wraps dependency install (`ohpm install`) and the underlying hvigor build.
 
 5. **Determine Build Mode** — Check if any argument equals `--signed` (it may be `$ARGUMENTS[1]` when the DevEco path is omitted, or `$ARGUMENTS[2]` when it is provided):
    - **If NOT `--signed`** → **Unsigned build mode**. Ensure `build-profile.json5` does NOT have `signingConfigs` or `signingConfig` references in products (remove them if present). Go to Step 1.
-   - **If `--signed`** → **Signed build mode**. Proceed to Step 0.5 to validate signing config.
+   - **If `--signed`** → **Signed build mode**. Proceed to Step 0.5 to validate signing config before the Step 1 build loop invokes `npx --yes devecocli build`.
 
 ---
 
@@ -93,39 +87,30 @@ Execute the following loop. **Maximum 20 iterations** to prevent infinite loops.
 
 ### 1.1 Run CLI Build
 
-**IMPORTANT (Windows)**: On Windows, bash `export PATH` does NOT propagate to Windows native child processes. You **must** use a temporary `.bat` file to set `PATH` and `JAVA_HOME`.
+Use `npx --yes devecocli build` as the build command inside the fix loop. It is the supported wrapper for dependency install and hvigor execution, so the skill should not instruct raw `hvigorw.js` calls.
 
-1. **Write a temporary batch file** (e.g. `<project-dir>/build_temp.bat`):
+1. **Invoke `npx --yes devecocli build` from the project root**:
 
    **For unsigned builds** (no `--signed`):
-   ```bat
-   @echo off
-   set "DEVECO_SDK_HOME=<deveco-path>\sdk"
-   cd /d "<project-dir>"
-   "<deveco-path>\tools\node\node.exe" "<deveco-path>\tools\hvigor\bin\hvigorw.js" assembleHap --mode module -p module=entry --no-daemon
+   ```bash
+   cd "<project-dir>"
+   npx --yes devecocli build
    ```
-
-   **For signed builds** (`--signed`):
-   ```bat
-   @echo off
-   set "PATH=<deveco-path>\jbr\bin;%PATH%"
-   set "JAVA_HOME=<deveco-path>\jbr"
-   set "DEVECO_SDK_HOME=<deveco-path>\sdk"
-   cd /d "<project-dir>"
-   "<deveco-path>\tools\node\node.exe" "<deveco-path>\tools\hvigor\bin\hvigorw.js" assembleHap --mode module -p module=entry --no-daemon
+   If the project needs an explicit module target, prefer:
+   ```bash
+   cd "<project-dir>"
+   npx --yes devecocli build --modules entry
    ```
-   Note: Signed builds need `JAVA_HOME` and `jbr\bin` in PATH because the `SignHap` step spawns `java` as a child process.
 
-   Use backslashes (`\`) in paths inside the `.bat` file (Windows convention).
-
-2. **Run the batch file** via `cmd.exe`:
+   **For signed builds** (`--signed`):
    ```bash
-   cmd.exe //c "<project-dir>/build_temp.bat" 2>&1
+   cd "<project-dir>"
+   npx --yes devecocli build
    ```
+   Run this only after Step 0.5 verifies the signing config in `build-profile.json5`. Preserve any required signed-build environment setup (for example `JAVA_HOME` on Windows) before invoking `npx --yes devecocli build`, but do not bypass the CLI wrapper.
 
-3. **Delete the batch file** after the build completes (success or failure).
+2. **Capture the full output** into a variable.
 
-- Capture the **full output** into a variable.
 - The build command may take 1-3 minutes. Use a timeout of 300000ms (5 minutes).
 
 ### 1.2 Check Build Result
@@ -270,7 +255,7 @@ All code must comply with ArkTS strict mode:
 - **Don't over-fix**: Only fix errors reported by the compiler. Don't proactively refactor unrelated code.
 - **Read before edit**: Always read a file before modifying it. Understand the surrounding context.
 - **One error can cause many**: A single root-cause fix (like adding a missing interface) may resolve multiple reported errors. After fixing root causes, rebuild to see remaining issues.
-- **ohpm errors**: If the build fails because of missing packages, run `ohpm install` again.
+- **ohpm errors**: If the build fails because of missing packages, rerun `npx --yes devecocli build` so it can retry dependency install before you investigate deeper.
 
 ---
 

package/skills/hmos-resources-convert/SKILL.md

@@ -73,7 +73,7 @@ a2h-resource <apk_path> -o <decoded_output_path>
 Alternatively, if you prefer not to install globally, run it on-demand with `npx` (which fetches the package automatically):
 
 ```bash
-npx a2h-resource <apk_path> -o <decoded_output_path>
+npx --yes a2h-resource <apk_path> -o <decoded_output_path>
 ```
 
 `a2h-resource` is a pure-Node.js resource decoder distributed as an npm package and requires only Node.js `>= 20`. It reads the APK's `resources.arsc` — the fully-merged resource table produced at build time — so its output at `<decoded_output_path>/res/` is the **complete merged resource set** (source + all library/AAR resources merged in at build time). It produces:
@@ -646,7 +646,7 @@ Read `references/resource-mapping-rules.md` and write the mapping markdown with
 - **Build is best-effort**: The APK build + decoding is attempted first because the decoded APK is the most complete resource source (it includes library dependencies). But if the build fails, conversion proceeds from source `res/` — a partial conversion with clear reporting is far more useful than no conversion at all.
 - **XML drawable conversion is critical**: Android XML drawables (`<vector>`, `<shape>`, `<layer-list>`, `<selector>`) must be converted to SVG format, not skipped. HarmonyOS supports SVG in `media/`. Read `references/xml-drawable-to-svg-rules.md` for the detailed conversion rules for each drawable type.
 - **Dependency analysis always runs**: Read `references/dependency-analysis-rules.md` for the complete dependency extraction patterns and reference formats. Even when converting from source `res/` with missing library resources, dependency analysis is essential — it tells the developer exactly which references are broken and why, so they can address them manually or fix the build.
-- **APK decoding**: The decoder is `a2h-resource`, a pure-Node.js resource decoder published to npm (requires Node.js `>= 20`; no other runtime). Install it with `npm install -g a2h-resource` and run `a2h-resource <apk> -o <out>`, or run it on-demand with `npx a2h-resource <apk> -o <out>`. It covers resource extraction only — it does not disassemble `classes.dex` or repackage APKs, neither of which this skill needs. It decodes a single resource package (the app's); if it errors out or the APK is a rare multi-package/split APK, fall back to converting from the project's source `res/` directory (as in Step 3).
+- **APK decoding**: The decoder is `a2h-resource`, a pure-Node.js resource decoder published to npm (requires Node.js `>= 20`; no other runtime). Install it with `npm install -g a2h-resource` and run `a2h-resource <apk> -o <out>`, or run it on-demand with `npx --yes a2h-resource <apk> -o <out>`. It covers resource extraction only — it does not disassemble `classes.dex` or repackage APKs, neither of which this skill needs. It decodes a single resource package (the app's); if it errors out or the APK is a rare multi-package/split APK, fall back to converting from the project's source `res/` directory (as in Step 3).
 - When parsing Android XML resource files, handle XML namespaces, comments, and attributes correctly.
 - For `values/` XML files, each `<resources>` element can contain multiple resource entries — extract ALL of them.
 - When multiple Android value files contribute to the same HarmonyOS JSON file (e.g., both `strings.xml` and custom `app_strings.xml` both contain `<string>` entries), merge them into a single JSON file.

package/skills/hmos-spec-generate/SKILL.md

@@ -13,13 +13,6 @@ allowed-tools:
   - TaskCreate
   - TaskList
   - TaskUpdate
-  - mcp__homegraph__search
-  - mcp__homegraph__explore
-  - mcp__homegraph__node
-  - mcp__homegraph__impact
-  - mcp__homegraph__callers
-  - mcp__homegraph__callees
-  - mcp__homegraph__files
 ---
 
 # Spec Generator Skill
@@ -32,8 +25,7 @@ You are a **Spec Generator** that produces high-quality requirement specificatio
 |------|-------|
 | **Input** | `requirement-description-dir` + `android-project-path` + `spec-output-dir` |
 | **Output** | One `<source_filename_without_ext>.md` per input `.txt` under `spec-output-dir` |
-| **homegraph (Index CLI)** | `homegraph` CLI via `Bash` (`status` / `init` / `sync` / `index`) |
-| **homegraph (Code queries)** | `mcp__homegraph__*` tools (`search` / `explore` / `node` / `impact` / `callers` / `callees` / `files`) |
+| **homegraph** | `npx --yes homegraph <command>` CLI via `Bash` (index management + code queries) |
 | **Processing Mode** | Per-file end-to-end loop (no batch pre-read) |
 
 ## Expected Input
@@ -378,33 +370,30 @@ These are the authoring rules the final spec MUST follow:
 
 ### Step 1 — Ensure homegraph has a fresh index for the project
 
-homegraph exposes two surfaces:
+homegraph is invoked exclusively through its CLI via `Bash`. Always prefix commands with `npx` (e.g. `npx --yes homegraph status <android-project-path>`); `npx` resolves the binary without requiring a global install. All index management and code query commands share the same CLI — there is no MCP surface in this skill.
 
-- **Index management** (`status`, `init`, `sync`, `index`) → run the `homegraph` CLI via `Bash`.
-- **Code queries** (`search`, `explore`, `node`, `impact`, `callers`, `callees`, `files`) → call `mcp__homegraph__*` tools directly.
-
-homegraph indexes per-project into a local `.homegraph/` directory; there is no central repo registry. Scope every code query to the Android project with `projectPath: "<android-project-path>"` (this skill's working directory is the spec project, NOT the Android project, so the parameter is mandatory — omitting it queries the wrong project).
+homegraph indexes per-project into a local `.homegraph/` directory; there is no central repo registry. Always pass the Android project path as the positional `[path]` argument to scope the command to the Android project (this skill's working directory is the spec project, NOT the Android project, so omitting the path queries the wrong project).
 
 Procedure:
 
-1. Run `homegraph status <android-project-path>` to inspect the index state.
+1. Run `npx --yes homegraph status <android-project-path>` to inspect the index state.
 2. Decide based on the output:
-   - **Not indexed** (no `.homegraph/`) → run `homegraph init -i <android-project-path>`, wait for completion.
-   - **Stale** (`homegraph status` output does NOT contain `[OK] Index is up to date`) → run `homegraph sync <android-project-path>` (incremental; use `homegraph index <android-project-path> --force` for a full rebuild), wait for completion.
+   - **Not indexed** (no `.homegraph/`) → run `npx --yes homegraph init -i <android-project-path>`, wait for completion.
+   - **Stale** (`npx --yes homegraph status` output does NOT contain `[OK] Index is up to date`) → run `npx --yes homegraph sync <android-project-path>` (incremental; use `npx --yes homegraph index <android-project-path> --force` for a full rebuild), wait for completion.
    - **Fresh** → proceed to Step 2.
 
 **Hard fail policy** — any of the following stops the skill and surfaces the error to the user; do NOT degrade to `Read` + `Grep`:
 
-- `homegraph` CLI is not found on PATH → ask the user to install it (`npm install -g homegraph`).
-- `homegraph status`, `init`, `sync`, or `index` returns an error → surface the error verbatim and stop. Do not attempt spec generation without an index — the resulting spec would miss code-grounded scenarios.
-- Any `mcp__homegraph__*` call reports the project is not indexed → verify `init -i` ran against `android-project-path`.
+- `homegraph` CLI is not reachable via `npx` → ask the user to install it (`npm install -g homegraph` or `npx --yes homegraph install`).
+- `npx --yes homegraph status`, `init`, `sync`, or `index` returns an error → surface the error verbatim and stop. Do not attempt spec generation without an index — the resulting spec would miss code-grounded scenarios.
+- Any `npx --yes homegraph` query reports the project is not indexed → verify `init -i` ran against `android-project-path`.
 
 ### Step 2 — Process each requirement file independently, one at a time
 
 For each `.txt` filename collected in Step 0, in order, run 2.1 → 2.4 end-to-end before moving to the next file. Do NOT pre-read all `.txt` files.
 
 - **2.1 Read**: Read this file's content verbatim. If empty, warn and skip to the next file.
-- **2.2 Analyze**: Explore the Android codebase for this requirement using the `mcp__homegraph__*` tools to retrieve the complete code implementation (entry points, end-to-end call chains, state writes / persistence keys, manifest declarations). Use `search` → `explore` / `node` to locate and read symbols; `callers` / `callees` / `impact` to walk call chains up and down; `files` to enumerate; and `Grep` for exact literals (settings keys, DAO columns, `android:key`) that live outside the code graph. Scope EVERY `mcp__homegraph__*` call with `projectPath: "<android-project-path>"` (a missing or wrong `projectPath` queries the wrong project). Use these tools directly — do NOT invoke any nested exploration skill. If any `mcp__homegraph__*` call fails unexpectedly, surface the error and stop.
+- **2.2 Analyze**: Explore the Android codebase for this requirement using the `npx --yes homegraph` CLI (via `Bash`) to retrieve the complete code implementation (entry points, end-to-end call chains, state writes / persistence keys, manifest declarations). Query commands (`query` / `explore` / `node` / `callers` / `callees` / `impact` / `files`) resolve their target project from the current working directory's nearest `.homegraph/` index, so run them from within the Android project root using a subshell — e.g. `cd <android-project-path> && npx --yes homegraph explore "<query>"` (the index commands `status` / `init` / `sync` / `index` accept an explicit path argument, see Step 1). Use `npx --yes homegraph query "<keyword>"` / `npx --yes homegraph explore "<query>"` to locate symbols and read their line-numbered source; `npx --yes homegraph node "<symbol|file>"` to read a single symbol or whole file; `npx --yes homegraph callers "<symbol>"` / `npx --yes homegraph callees "<symbol>"` to walk call chains up and down; `npx --yes homegraph impact "<symbol>"` for change blast radius; `npx --yes homegraph files` to enumerate indexed files; and `Grep` for exact literals (settings keys, DAO columns, `android:key`) that live outside the code graph. Always run query commands from `<android-project-path>` — this skill's working directory is the spec project, NOT the Android project, so running them from elsewhere queries the wrong project (or none). Use the CLI directly — do NOT invoke any MCP tool or nested exploration skill. If any `npx --yes homegraph` call fails unexpectedly, surface the error and stop.
 - **2.3 Decompose**: Using the raw requirement + code from 2.2, generate the spec per `## Principles` and `## Spec Few-shot Samples`.
 - **2.4 Write**: Write the spec to `<spec-output-dir>/<source_filename_without_ext>.md` (overwrite if exists), then move on to the next file.