ohos-design-arkui-api-competitive-analysis
>
ohos-dev-arkruntime-interop-development
>
ohos-dev-arkui-v1-v2-migration
Use when migrating OpenHarmony/HarmonyOS ArkUI state management from V1 (@Component, @State/@Prop/@Link/@Provide/@Consume/@Watch/@Observed) to V2 (@ComponentV2, @Local/@Param/@Event/@Provider/@Consumer/@Monitor/@ObservedV2/@Trace), or assessing migration feasibility. Trigger phrases include "迁移V1到V2", "V1V2迁移", "状态管理迁移", "将@Component改为@ComponentV2", "迁移@State/@Prop/@Link到V2", "migrate V1 to V2". Provides automated analysis (component structure, dependency tracing, API version detection, V1/V2 mixing validation), step-by-step migration guidance, and post-migration validation.
ohos-dev-distributed-cpp-callgraph-analysis
Use when an OpenHarmony C++ change must be checked for call-chain completeness, especially for data propagation, IPC/proxy/stub paths, virtual overrides, callbacks, or dlopen/dlsym boundaries. Produces evidence tables and modification coverage matrices; the helper script only discovers candidate edges.
ohos-dev-distributed-device-image-flashing
Use when the user wants to download OpenHarmony daily build images or flash them to a real device (DAYU200/RK3568 or others). Triggers on daily build, DAYU200, RK3568, flashing, burning, hdc reboot, upgrading firmware.
ohos-dev-distributed-mmi-device-test-harness
Use when building or running multimodal input system tests on a real DAYU200 device. Covers NativeToken permission setup, server-side bypass, test binary compile/deploy/run pipeline, phase-based hidumper capture, device discovery polling, and dump field reference.
ohos-dev-distributed-mmi-ram-rom-measurement
Use when measuring RAM/ROM impact of OpenHarmony multimodal input (MMI) subsystem changes on DAYU200 (RK3568). Covers ROM measurement via readelf section analysis and file size comparison, RAM measurement via /proc/PID/smaps, smaps_rollup, hidumper --mem, and baseline/current .so swap methodology. Includes code-level theoretical analysis for heap-allocated data structures.
ohos-dev-distributed-mmi-uinput-virtual-device
Use when testing OpenHarmony input subsystem features (mouse/keyboard/touchpad event flow, device binding, display group isolation) on a real device without physical peripherals. Covers /dev/uinput device creation, event injection, InputManager device discovery, and hot-plug simulation.
ohos-dev-distributed-mmi-wms-dms-simulation
Use when testing OpenHarmony input features that depend on window/display state without running real WMS/DMS. Builds requested simulation scenarios from display groups, users, main/extended/mirror displays, per-display focus windows, z-order window stacks, hot areas, dynamic focus switching, pointer style, capture mode, scroll wheel, and device binding.
ohos-dev-graphics-pixel-tests-generator
务必在创建、修改、评审或调试 OpenHarmony graphic_2d graphic_test 像素比对测试时使用；只要用户提到 RSGraphicTest、GRAPHIC_TEST、GRAPHIC_TESTS、GRAPHIC_N_TEST、Rosen 渲染测试、RSCanvasNode、RSSurfaceNode、Drawing::Canvas、PixelMap、截图测试、graphic_test 目录或 /data/local/graphic_test 图片，就必须使用。
ohos-dev-graphics-stability-code-review
>
ohos-issue-graphics-cppcrash-analysis
Use when analyzing OpenHarmony cppcrash faultlogs to locate root cause of native process crashes, investigating SIGSEGV/SIGABRT signals, memory corruption patterns, or call stack anomalies.
ohos-issue-graphics-sysfreeze-analysis
Use when analyzing OpenHarmony sysfreeze/appfreeze logs to diagnose process freeze and thread blocking issues. Triggers on SERVICE_BLOCK, THREAD_BLOCK_6S, IPC deadlock, task queue blocking, or when user requests sysfreeze/process stuck analysis.
ohos-req-arch-decision
Use when selecting an OHOS solution direction in Phase 0.3, especially for 03-arch-decision-record.md, candidate options comparison, or when the main session needs structured ADR output with user-provided decision. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), feature baseline (ohos-req-feature-baseline), or review gate (ohos-req-review-gate).
ohos-req-feasibility-analysis
Use when evaluating an OHOS requirement in Phase 0.2, especially for 02-feasibility.md, capability gaps, candidate technical paths, compatibility, security, dependencies, effort, risk, or validation planning. Triggers: 02-feasibility.md, 可行性分析, capability gap, 候选技术路径, 兼容性分析, 工作量估算, 500行人月. Do NOT use for requirement intake (ohos-req-requirement-intake), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline).
ohos-req-feature-baseline
Use when preparing an OHOS Feature for Phase 0.4 review, especially for 04-feature.md, SIG review readiness, proposal splitting, feature scope, acceptance criteria, or delivery impact. Do NOT use for requirement intake (ohos-req-requirement-intake), feasibility analysis (ohos-req-feasibility-analysis), or review gate (ohos-req-review-gate).
ohos-req-feature-to-ir
Use when an OHOS Feature has completed the Phase 0 Review Ready Gate and an Initial Requirement baseline is needed before proposal creation or cross-repository requirement splitting. Activation keywords: "IR.md baseline", "AC reference inheritance", "rr_id", "extension dimension confirmation". Do NOT use for requirement intake (ohos-req-requirement-intake), feasibility analysis (ohos-req-feasibility-analysis), or SR generation (ohos-req-proposal-to-sr).
ohos-req-intake-orchestration
Use when orchestrating OHOS Phase 0 intake workflow, from raw requirement to IR + proposal splitting + handoff contract. Triggers: requirement intake, Phase 0, requirement review, generate IR, 需求导入, 需求评审, 生成IR. Do NOT use for single-feature design work, Phase 1-9 delivery, ad-hoc document generation, or any task outside the Phase 0 requirement intake workflow.
ohos-req-proposal-to-sr
Use when every proposal associated with an OHOS IR has passed GATE A and a System Requirement baseline is needed before spec and design work begins. Triggers: 生成SR, proposal转SR, SR基线, 系统需求基线, GATE A通过, 05-proposal to SR. Do NOT use for IR generation (ohos-req-feature-to-ir), feature baseline (ohos-req-feature-baseline), or feasibility analysis (ohos-req-feasibility-analysis).
ohos-req-requirement-intake
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).
ohos-req-review-gate
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).
ohos-req-review-ppt-gen
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.
ohos-req-value-decision
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).
ohos-test-arkruntime-interop-testing
>
ohos-test-fuzz-generation
>
cts-dev
ArkTS前端编译器(ets2panda)CTS测试修复开发助手。用于CTS测试用例未通过时的缺陷定位、代码修复、测试验证全流程。适用场景：(1)CTS测试用例失败需要定位根因并修复 (2)前端编译器parser/checker/lowering模块的功能开发与缺陷修复 (3)编译构建、测试运行、回归验证 (4)代码评审与重构 (5)代码修改报告生成。涉及仓库为ets_frontend和runtime_core，编译器代码路径为ets_frontend/ets2panda。本技能是spec-test-analyzer的下游技能，接收spec分析报告后执行修复。当处理CTS用例失败时，必须先使用spec-test-analyzer技能生成spec分析报告，再使用本技能进行修复。
spec-test-analyzer
Analyze ArkTS code snippets or CTS test cases against the specification stored in ./docs. Prefer the generated ./.agent index when available, and fall back to raw docs when the index has not been built yet.