• Use the smallest inner loop that matches the Track. For a local or logic change, stop at lint/build; do not launch a device unless runtime behavior is in scope.
• For a UI Track, take one initial screenshot and one approved interaction pass. Do not repeat build/run/layout/screenshot after an unchanged successful pass.
• Prefer

  devecocli build --modules <module> --build-mode debug

  for module-scoped source changes, then

  devecocli run --skip-build --device <serial> --module <module>

  . Use

  --hotreload-apply

  only when the project has a valid

  .hvigor

  hot-reload file and the user path does not need a fresh install. File-level recompilation remains controlled by Hvigor's dependency graph; never promise that an arbitrary edit compiles in isolation.
• Never print an unfiltered

  devecocli log

  result. Capture it through

  compact_command.py

  or filter immediately with

  rg "TypeError|JS_ERROR|Fatal|ERROR"

  .
• Never pass raw

  devecocli docs search

  output into the conversation. Use

  devecocli_docs_bridge.py

  , which fixes

  --format json --limit 3

  , removes long fields, and marks short non-English snippets for local model translation. Do not discard a relevant Chinese result solely because its source language is Chinese.
• The bridge's

  translation_queue

  is intermediate input to the local model; only translated English

  ready_context

  may be reused as later context.
• Keep full command output in

  artifacts/logs/

  ; show only the marker, exit code, first actionable error, and artifact path in the conversation.
• Use the

  devecocli

  installation and DevEco Studio toolchain resolved by the workflow environment. Do not overwrite the caller's PATH or mix executables from unrelated Node installations.

Prereqs: Node.js and npm,

devecocli

installed by the hackathon setup and on PATH, and an available DevEco Studio toolchain (

hvigor

,

ohpm

,

hdc

, etc.). Check with

devecocli -V

.

1. CLI-first. Use

   devecocli

   for build, install, launch, lint, logs, and UI operations. Use the verified CLI references above instead of repeatedly probing

   --help

   .
2. Lint timing. For non-UI changes or an explicit lint request, run

   devecocli check lint --format json

   after editing and resolve errors; use its automatic-fix option only after reviewing the proposed changes. For UI changes executed under Conductor, the first post-implementation action is the build-to-device checkpoint; run lint after the user approves the current UI and before final verification or commit. Resolve errors; justify warnings. If lint or build fails, update the project's

   conductor/learning.md

   before retrying and display the updated Lessons Learned. If the project is not Conductor-managed, use

   artifacts/logs/learning.md

   as the fallback log; create it with a

   # Learning Log

   heading when needed. A non-zero exit or explicit

   BUILD FAILED

   result ends the current command and the current verification step. Capture the first actionable cause, update and display the learning log, then return a concise failure report. Do not wait after the launcher has exited, continue to device/UI validation, or retry implicitly. A retry requires a separately announced recovery step and must not happen for a missing launcher or command-not-found error. 3. Build completion is a two-part check. A build is successful only when the DevEco build result is successful and

   devecocli

   returns exit code

   0

   . Always print or capture

   DEVECOCLI_BUILD_EXIT_CODE=<code>

   after the command. If the exit code is non-zero, the build is failed and the workflow must return the failure immediately. Do not start device validation while the command is still running after the success marker. A persistent Hvigor daemon alone is normal.
3. Build-to-device gate. After a successful build, always run

   devecocli device list

   before deployment.

   devecocli run

   accepts a device serial or name. If the serial contains

   [IP_ADDRESS]

   or another redaction placeholder, use the displayed device name instead. If no device is listed, do not stop at a generic "blocked" report: this is commonly a first-time-emulator issue (no virtual device created yet, or its system image was never downloaded) rather than a CLI problem — see

   references/troubleshooting.md

   and hand the Device Manager steps to the user as an explicit manual step, then wait. If multiple devices are listed, ask the user to select one and never silently choose one. A

   Connected

   row is only discovery evidence, not an install readiness check. Keep the real serial in a shell variable instead of copying a redacted address from displayed output:

   $serial = (hdc list targets | Where-Object { $_ -match ':\\d+$' } | Select-Object -First 1).Trim()

   . Run

   hdc -t $serial shell echo hdc-ready

   . If that command fails, run

   hdc kill -r

   ,

   hdc tconn $serial

   , and the shell check again. Stop if the shell check still fails; do not attempt install or launch.
4. No destructive device operations without confirmation. Treat uninstalling apps, modifying device data, and deleting emulators as destructive.
5. UI inspection. Use

   devecocli ui layout

   and

   devecocli ui screenshot

   . Use the documented

   devecocli ui click

   ,

   doubleclick

   ,

   longclick

   ,

   swipe

   ,

   fling

   ,

   dircfling

   , and

   drag

   commands for interaction.
6. Implementation handoff. Before verification, read the changed files and any Conductor handoff/API-evidence artifacts. Confirm the target module, SDK/API level, state-management version, expected user paths, and known risks. Do not infer missing acceptance criteria from the source code.
7. ArkUI diagnosis. If lint/build fails on an ArkUI API, import, callback type, state decorator, rendering rule, or API-level issue, classify the first actionable error and use

   hmos-arkts-knowledge-retriever

   or the ArkUI references before proposing a fix. Do not mechanically replace

   @ohos.*

   with

   @kit.*

   ; verify the current SDK and project convention first.
8. State-management migration. If the handoff declares a migration, read the migration inventory and target version before verification. Check for unresolved V1 decorators, invalid V1/V2 mixing, incomplete parent/child event flow, missing V2 initialization, and unsupported APIs. If the handoff does not declare a migration, do not suggest V1-to-V2 conversion as an incidental cleanup.

1. Edit sources after the written work plan is approved.
2. Build —

   devecocli build

   . Treat the build as complete only after the command exit check and successful build output. On failure, stop, capture the failing phase and first actionable error, update the applicable learning log, display the lesson, fix the cause, then rerun the failed build-to-device checkpoint.
3. Device gate — run

   devecocli device list

   after build success. Stop if there is no target; resolve multiple targets explicitly and select the target serial.
4. Install and launch —

   devecocli run --skip-build --module <module> --device <serial>

   . If HDC reports

   connect-key

   or

   Not match target founded

   , run

   hdc kill -r

   , reconnect with

   hdc tconn $serial

   , verify

   hdc list targets

   , then rerun the shell readiness check. Retry deployment only after the shell check passes.
5. Observe and pause — capture the first screenshot, then use the interactive

   question

   tool to ask for UI approval and automated interaction consent. Record interaction consent immediately with

   record_test_consent.py

   , before lint or any tap/type action. If the UI is rejected, return to Edit and repeat steps 2-5. If the question tool cannot render, use a Markdown table only after the tool call fails or is dismissed.
6. Lint after UI approval —

   devecocli check lint --format json <project-root>

   .
7. Regression observe
   • Logs:

     devecocli log

     for HiLog output or crash logs.
   • Screenshot:

     devecocli ui screenshot

     .
   • Layout:

     devecocli ui layout

     .
   • Drive: use the

     devecocli ui

     interaction commands listed above.
   • Record: report each planned user path as pass, fail, or blocked and attach its screenshot/log evidence. A successful launch alone is not UI-path validation.
   • Migration paths: when applicable, report simple state updates, nested-object updates, parent/child communication, list mutations, persistence restore, and animation behavior separately.

1. Stop at the first actionable error.
2. Check the local ArkUI references.
3. Call

   hmos-arkts-knowledge-retriever

   if the signature, import, or version is unclear.
4. Record the evidence and first fix attempt in the applicable learning log.
5. Let the implementation skill apply the source change, then rerun this skill's gates.

• List targets:

  hdc list targets -v

• For operations not exposed by DevEco CLI, ask for confirmation before using the underlying DevEco toolchain command. Do not invent an equivalent

  devecocli

  subcommand.

• Scaffolding or templating a fresh project.
• System/persistent bundle development and OHOS source-tree builds.
• Product discovery, Track planning, and architecture decisions owned by Conductor or the architecture specialist.

• references/arkts-strict.md

  — ArkTS strict-mode rules the compiler /

  devecocli check lint --format json

  enforce.

• references/architecture.md

  — Clean-Architecture layering for ArkTS apps (Domain / Data / Presentation).

• references/troubleshooting.md

  — common

  devecocli

  build / SDK failures and fixes.

• references/arkui-validation.md

  — ArkUI handoff, diagnostic routing, and UI-path verification guidance.

• references/state-migration-validation.md

  — V1/V2 migration preflight and behavioral regression matrix.