skills/afwk-hb-build/SKILL.md
智能编译 ability_runtime 组件,通过检测修改的文件自动确定编译目标。支持多目标一起编译、自动重试判断、智能错误分析。触发关键词:"编译"、"构建"、"compile"、"build"、"make"、"make file"。
npx skillsauth add openharmonyinsight/openharmony-skills hb-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.
自动检测修改的文件并智能编译 ability_runtime 组件,支持多目标编译和自动重试。
python3 scripts/helper.py
# SO 名称(推荐)
python3 scripts/helper.py --target libupms # UriPermissionManager
python3 scripts/helper.py --target abilityms # AbilityManagerService
python3 scripts/helper.py --target appms # AppManagerService
# 完整路径
python3 scripts/helper.py --target \
//foundation/ability/ability_runtime/services/uripermmgr:libupms
python3 scripts/helper.py --target libupms abilityms appms
python3 scripts/helper.py --target full
1. 切换到项目根目录(包含 build.py)
2. 检测修改文件 → git status --short
3. 过滤无关文件 → 排除 .claude/, build/, out/, *.md 等
4. 推断编译目标 → 统计每个服务的修改文件数
5. 智能决策 →
• 目标数量 > 5 → 使用整仓编译
• 目标数量 > 1 → 一起编译多个目标
• 目标数量 = 1 → 编译单个目标
6. 执行编译 → hb build ability_runtime -i --build-target <TARGET>
7. 处理结果 → 成功或失败(支持智能重试)
| 参数 | 说明 | 默认值 |
|------|------|--------|
| --target | 编译目标(支持多个) | auto |
| --type | 编译类型(-i 功能代码 / -t 测试套) | -i |
| --fast | 启用快速编译(--fast-rebuild) | false |
| --max-retries | 最大重试次数 | 3 |
| --auto-retry | 启用自动重试模式 | false |
abilityms - AbilityManagerService (services/abilitymgr)appms - AppManagerService (services/appmgr)libupms - UriPermissionManager (services/uripermmgr)dataobsms - DataObserverManager (services/dataobsmgr)quickfixmgr - QuickFix Manager (services/quickfixmgr)auto - 自动检测修改文件并推断编译目标full - 编译整个 ability_runtime 组件以下文件和目录不会被检测为需要编译的修改:
.claude/, .hvigor/, build/, out/, .git/services/dialog_ui/ams_system_dialog/.hvigor/local.properties*.md 文档文件必须满足的条件:
已知的限制:
--target full)耗时较长(10-30 分钟)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