openharmonyinsight
100 verified skills2,292 total stars
skills/harmonyos-autotest
--- name: harmonyos-autotest description: Complete HarmonyOS automated testing workflow orchestrator. Converts natural language test requirements to executable Hypium test cases through step parsing, environment checking, project creation, control parsing, operation execution, debugging, and test case writing. Use when user wants to run complete automated test workflow, create HarmonyOS test projects, or mentions HarmonyOS测试, 自动化测试, run test, execute test. Trigger keywords: harmonyos test, 自动化测试
development25
log-coverage-analyzer
Analyze code repository logging coverage to ensure all function branches have LOGE/LOGI logs and identify high-frequency log risks. Supports multiple programming languages (C++, Java, Python, JavaScript, etc.)
development25
hmos-multidevice-screen-window-size
Handle HarmonyOS screen and window size adaptation, including breakpoint systems, responsive layouts, GridRow/GridCol usage, window size observation, and multi-device layout changes.
development25
oh-pdd-prd-analysis
分析 HM Desktop PRD 文档，提取需求信息、验证完整性、检查章节顺序（需求来源→需求背景→需求价值分析→竞品分析→需求描述）、检查 KEP 定义、检测需求冲突并生成结构化分析报告。适用于用户请求：(1) 分析或审查 PRD 文档, (2) 从需求中提取 KEP 列表, (3) 检查 PRD 完整性或一致性, (4) 将需求映射到模块架构, (5) 验证 PRD 格式合规性, (6) 验证竞品分析章节完整性。关键词：PRD分析, requirement extraction, KEP验证, completeness check, chapter order validation, 竞品分析检查, analyze PRD, 需求提取, 完整性检查, 章节顺序验证
testing25
oh-precommit-codecheck
Run local code quality checks covering a subset of OpenHarmony gate CI (copyright, CodeArts C/C++) plus additional local checks (pylint/flake8, shellcheck/bashate, gn format). Use before committing to reduce gate failures. Triggers on: /oh-precommit-codecheck, "门禁检查", "门禁预检", "检查代码", "run codecheck", "check code quality", "lint my code", "代码检查", or after completing code implementation. WHEN to use: before git commit, before creating PR, after modifying C/C++/Python/Shell/GN files, when gate CI fails with codecheck defects, or when you want to preview what gate will flag.
development25
interop-promise
ETS-JavaScript interop Promise bridging system in ArkCompiler. Use this skill when working on cross-language Promise conversion between ETS (ArkTS) and JavaScript, including JSConvertPromise Wrap/Unwrap, EtsPromise proxy creation, EtsPromiseRef bridging, CreatePromiseLink, OnJsPromiseCompleted callbacks, connectPromise, SettleJsPromise, PromiseInteropResolve/Reject, EtsAwaitPromise/AwaitProxyPromise, callback queue management, or any code under js_convert.h (Promise section), js_job_queue, ets_promise, ets_promise_ref, std_core_Promise.cpp, or PromiseInterop.ets. Also use when debugging cross-VM Promise state synchronization, coroutine suspension/resumption during await, or napi_deferred lifecycle issues.
development25
oh-distributed-security-design-review
OpenHarmony分布式系统安全代码检视专用技能。当用户要求"检视代码安全实现"、"代码安全审查"、"安全代码review"或类似的分布式系统代码安全检视请求时触发。此技能提供18条OpenHarmony分布式业务安全设计规则的详细检视指导，涵盖授权控制、状态机、数据传输、权限管理、可信关系等安全领域。使用此技能可在通用网络安全规则基础上，针对OpenHarmony分布式系统进行专项安全检视。
testing25
taskpool-dependency-analysis
Analyze, diagnose, and fix taskpool task dependency problems in static ArkTS — including circular dependency (10200026), missing dependency (10200027), dependent tasks not waking after dependency completion, cancel propagation through dependency chains, and illegal addDependency/removeDependency on periodic/group/seqRunner/asyncRunner/executed tasks. Use this skill whenever the user mentions taskpool dependencies, addDependency, removeDependency, circular dependency, dependency graph, task not executing after dependencies complete, cancel propagation, or any taskpool error codes 10200026, 10200027, 10200070, 10200071, 10200073, 10200074, 10200079, 10200097, 10200101, 10200113 — even if they don't explicitly say 'dependency' or 'taskpool'.
development25
oh-arkruntime-thread-safety-audit
Use this skill when auditing, reviewing, or fixing thread-safety issues in ArkCompiler Runtime Core, especially ArkTS-Sta ETS stdlib and plugin code under static_core/plugins/ets. It covers static mutable state, singleton initialization, shared maps/caches/counters/timers, taskpool/EAWorker concurrency, TSAN follow-up, and concurrent test design.
tools25
oh-pdd-code-generator
基于设计文档自动生成鸿蒙系统代码框架，包括 IDL 接口定义、目录结构、头文件、源文件模板、构建配置等。生成前会分析 OpenHarmony 存量代码，学习现有代码风格和架构规范。适用于用户请求：(1) 生成代码框架, (2) 创建 IDL 接口, (3) 生成 BUILD.gn 配置, (4) 创建服务代码, (5) 初始化项目结构, (6) 参考现有代码风格。关键词：code generation, IDL, BUILD.gn, bundle.json, SA profile, OpenHarmony code style, 代码生成, 接口定义, 构建配置, OH代码风格
development25
skills/oh-memory-leak-detection
--- name: memory-leak-detection description: Detect and fix NAPI memory leaks in OpenHarmony Ability Runtime. Use when reviewing NAPI code for memory leaks, especially functions that: (1) Return napi_value, (2) Have napi_value& parameters, (3) Call napi_create_* functions, (4) Set properties with temporary napi_value variables, (5) Work in async callbacks. See references/background.md for detailed memory management principles. --- # NAPI Memory Leak Detection ## Quick Start Functions working
development25
add-memory-trace-tags
Use when adding new resource tracking types to memory profiling in developtools_profiler and third_party_musl repositories. Triggered by requests to add trace tags, resource labels, or memory tracking types.
tools25
oh-interfaces-ipc-to-service
在Openharmony项目的graphic_2d仓新增透传通路。当用户希望在graphic_2d仓新增RSInterface接口，且指明该接口为ToSerivce时，调用该能力
tools25
oh-pr-workflow
OpenHarmony PR full lifecycle workflow. Five modes: - Commit: standardized commit with DCO sign-off and Issue linking - Create PR: commit + push to fork + create Issue + create PR on upstream - Fix Codecheck: fetch gate CI codecheck defects from a PR and auto-fix them - Review PR: fetch a PR's changes to local for code review - Fix Review: fetch unresolved review comments from a PR and auto-fix them Triggers on: /oh-pr-workflow, "提交代码", "创建PR", "提个PR", "commit", "修复告警", "修复门禁", "修复codecheck", "fix codecheck", "review pr", "review这个pr", "看下这个pr", "检视pr", "修复review", "修复检视意见", "fix review", or a GitCode PR URL with fix/review intent.
development25
oh-graphic-gitcode-pr-creator
Automate Gitcode Pull Request creation workflow for OpenHarmony graphic subsystem including code commit, issue creation, and PR submission with proper template formatting. Use when user needs to create a PR for the Gitcode platform, especially for OpenHarmony graphic projects that require specific PR templates with CodeCheck tables and Signed-off-by tags.
development25
oh-pdd-design-doc-generator
基于 PRD 文档自动生成鸿蒙系统设计文档，包括架构设计文档和功能设计文档。生成前会分析 OpenHarmony 存量代码结构，确保与现有架构兼容。架构设计文档第2章必须为竞品方案分析，位于需求背景之后。适用于用户请求：(1) 生成架构设计文档, (2) 生成功能设计文档, (3) 从 PRD 生成设计文档, (4) 创建系统架构设计, (5) 编写功能规格说明, (6) 分析 OH 代码结构。关键词：architecture design, functional design, design doc, 竞品方案分析, OpenHarmony code analysis, 架构设计, 功能设计, 设计文档生成, OH代码分析, analyze codebase, competitor analysis
development25
docs-check-zh-cn
Check whether OpenHarmony API documentation follows the required templates and whether public API docs, system API docs, error code docs, and interface declarations/comments/implementations are consistent. Use when the user asks to review API doc quality, compare docs against code, audit error code docs, fill missing interface documentation, or generate a doc issue report.
development25
oh-capi-xts-gen
OpenHarmony CAPI N-API 封装测试用例生成器（方式2）。自动解析 .h 头文件，生成 C++ N-API 封装和 ETS/ArkTS 测试代码。 **触发此技能的场景**： - 用户提到 CAPI、C 测试、Native 测试、原生测试、.h 文件解析 - 用户需要生成 N-API 封装测试（不是 gtest） - 用户提到覆盖率报告、补充测试、缺失测试 - 用户需要编译或验证 CAPI 测试套 - 用户提到异步编译、后台编译、编译验证 - 用户提到 XTS 测试、OpenHarmony 测试、子系统测试 **核心功能**： 1. 头文件解析 → 提取 API 信息 2. 测试用例生成 → C++ N-API 封装 + ETS 测试代码 3. 编译验证 → 异步编译 + 错误修复 4. 代码验证 → N-API 三重校验 + 格式检查 **支持子系统**：multimedia、bundlemanager、ability、arkui、hilog 等 **当用户提供覆盖率报告时**：自动切换到覆盖率报告驱动模式（高效精准）
development25
header-optimization
This skill should be used when the user asks to "optimize header files", "reduce header dependencies", "优化头文件", "减少头文件依赖", "analyze compilation efficiency", "分析编译效率", or mentions test_header.cpp analysis. This skill optimizes C++ header file compilation efficiency through systematic refactoring.
development25
openharmony-cpp
Expert coding guide for OpenHarmony C++ development. Use this skill when writing, refactoring, or reviewing C++ code for OpenHarmony projects. It enforces strict project-specific conventions (naming, formatting, headers) and critical security requirements (input validation, memory safety).
development24
openharmony-download
Interactive OpenHarmony source code download with mirror selection (GitCode/Gitee/GitHub), environment checking, branch selection, and real-time progress. Use when user requests:"下载 OpenHarmony", "download OpenHarmony", "下载源码", "获取源码", "拉取代码", "clone openharmony", or "repo init".
development24
skills/openharmony-arkts-layer
# ark-layer name: ark-layer description: | 基于 ArkTS 的鸿蒙应用开发框架助手。提供架构规范检查、Service 代码生成、多阶段加载配置、分层验证等功能，帮助开发者快速构建符合规范的鸿蒙应用。 instructions: | 你是 ark-layer 框架的架构助手，专门帮助开发者遵守项目架构规范并高效开发。 ## 项目概述 **ark-layer** 是一个基于 ArkTS 的轻量级鸿蒙应用开发框架，核心特性： - 清晰的三层架构分离 - 基于 ServiceManager 的依赖注入和生命周期管理 - 多阶段加载机制（GLOBAL/BUSINESS/FEATURE/LAZY） - Agent 辅助开发 ## 核心架构原则 ### 分层架构 项目采用严格的三层分离： - **infra/** - 基础设施层：框架核心 + 无状态、通用工具类 - **domain/** - 业务领域层：按功能划分的业务逻辑（user、focus、achievement） - **pages/** - 视图层：仅 ArkUI 组件，通过
devops24
hmos-multidevice-fold-state
Validate and route HarmonyOS foldable-device adaptation tasks (including bi-fold, multi-fold, and special-ratio form factors) through a declarative scene and resource index. Use when the task involves FoldStatus, hover layouts, crease avoidance, fold continuity, multi-fold state mapping (for example F/M/G), special-ratio inner/outer screen adaptation, or remediation of existing foldable-page issues.
development24
hmos-multidevice-interaction-methods
HarmonyOS应用多设备交互适配开发方案skill，提供触摸、鼠标、键盘、手写笔等多输入方式的交互方案和统一策略。当涉及触摸、鼠标、键盘、手写笔等设备的交互以及实现交互归一化、悬停效果、右键菜单、焦点导航、手写板输入和压感等功能时调用。
development24
hmos-multidevice-natural-orientation
Handle HarmonyOS device natural orientation, screen rotation, and window orientation adaptation across multiple device form factors. Use when the task involves setPreferredOrientation, rotation, orientation, natural orientation, tri-fold G-state, follow_desktop, video landscape/portrait switching, short video adaptive rotation, or multi-device orientation strategy.
development24
ohos-test-graphics3d-static-api-unit-test
Use when generating unit tests for ETS/ArkTS static API classes in OpenHarmony graphic_3d module, when adding new test cases for MaterialETS, CameraETS, SceneETS or similar wrapper classes, or when setting up test environment for GTest-based ETS unit tests
development24
comprehensive-code-review
Code review for ACE Engine (OpenHarmony ArkUI) covering C++/JS/TS/ArkTS. Analyzes 19+ dimensions: stability, performance, threading, security, memory, Modern C++ practices, SOLID principles, design patterns, robustness, testability, maintainability, observability, API design, technical debt, backward compatibility. Reports severity levels, refactoring suggestions, and ACE Engine checks (Pattern/Model/Property, component lifecycle, RefPtr/WeakPtr, four-layer architecture). Use when: reviewing PRs, analyzing code quality, enforcing standards, identifying technical debt, validating architecture, generating quality reports.
development24
openharmony-build
Use for OpenHarmony build execution and diagnosis, including 编译OpenHarmony/完整代码/测试/SDK/host/最小模拟器/全量模拟器/部件独立编译/测试列表, plus full product builds, targeted component/test builds, fast rebuilds, hb independent builds, and build.log failure analysis.
development24
openharmony-ci
Use when investigating OpenHarmony PR CI status from `openharmony_ci` comments, DCP event IDs, build labels, artifact links, or CI log URLs.
development24
skills/oh-stability/memoryLeak/dynamic-memory-analyzer
--- name: dynamic-memory-analyzer description: Comprehensive dynamic memory management analysis for ace_engine codebase. Covers 17 critical scenarios: basic pairing, smart pointers (RefPtr/WeakPtr), exception safety, ownership transfer, container pointers, singletons, callbacks, multi-threading, cross-layer interaction, third-party libraries, special patterns, common leaks, nullptr handling, Register/Unregister, lifecycle binding, assignment updates, and function returns. Use when checking memor
development24
ohos-app-build-debug
Build, install, launch, and debug HarmonyOS/OpenHarmony applications using DevEco Studio toolchain. Use when Claude needs to: (1) Build OHOS apps with hvigorw, (2) Install HAP files to devices via hdc, (3) Launch or debug OHOS applications, (4) Parse crash stacks with hstack, (5) Take device screenshots, or (6) Detect DevEco Studio environment and SDK tools. Automatically detects DevEco Studio installation and configures JAVA_HOME, PATH, and toolchain.
tools24
arkweb-thread-safety-review
Must use when scanning or reviewing OpenHarmony ArkWeb/Chromium C++ single files for thread-safety violations involving PostTask, BindOnce, base::Unretained(this), WeakPtr, scoped_refptr, mojo::Connector, GPU/Audio/DrDC threads, NDK/UI callbacks, NWeb, WebContents, Profile, BrowserContext, NavigationController. Enforces false-positive control and outputs strict JSON schema violations for standard_rule1-standard_rule10 only.
development24
oh-xts-generator-template
OpenHarmony XTS 测试用例通用生成模板。支持各子系统测试用例生成，API 定义解析，测试覆盖率分析，代码规范检查。触发关键词：XTS、测试生成、用例生成、测试用例。
development24
ohos-dev-graphics-stability-code-review
C/C++ 稳定性代码审查框架，包含可扩展规则体系，覆盖 5 个稳定性分类： 异常处理、并发稳定性、资源管理、边界条件、图形稳定性。 触发场景：稳定性专项全仓扫描、代码上库前本地检视、稳定性审计、故障预防检视、代码审查、OpenHarmony 稳定性扫描、 以及用户要求检查 C/C++ 代码稳定性风险时均应使用此技能。
development24
ohos-dev-graphics3d-combined-postprocess
Implement Combined post-processing effects (tone mapping, color grading, vignette) in Graphics3D. MUST use when: (1) Adding effect to Combined post-process, (2) User mentions 'Combined post-process' or 'post-processing'. DOES NOT apply to multi-pass effects (bloom, depth-of-field).
development24
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.
research24
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 图片，就必须使用。
development24
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.
research24
oh-xts-build-run
OpenHarmony XTS 编译和运行组合命令。一站式完成 XTS 测试项目的编译和运行。当用户需要执行完整的 XTS 测试流程时使用此 Skill： (1) 编译 XTS 测试项目生成 HAP 文件，(2) 运行 XTS 测试并展示结果。支持 --package 和 --api 参数传递给运行阶段。
development24
oh-ut-generator
Generate OpenHarmony C++ unit tests following HWTEST_F framework conventions. Supports Mock strategies, BUILD.gn configuration, NDK/NAPI interfaces, and maintains 75%+ coverage requirements with strict code style consistency. Use when generating unit tests for OpenHarmony C++ source files.
development24
hmos-multidevice-avoid-areas
Handle HarmonyOS avoid-area adaptation through a declarative scene and resource index. Use when the task involves safe area expansion, status bar or navigation bar avoidance, notch or cutout handling, immersive full-screen layouts, or soft keyboard overlap handling.
development24
hmos-multidevice-hardware-access
Handle HarmonyOS hardware-capability adaptation through a declarative scene and resource index. Use when the task involves camera selection, camera rotation/stride/foldable adaptation, sensor availability, canIUse or SysCap checks, hardware fallback strategy, external device access, or multi-device hardware behavior differences.
development24
hmos-multidevice-scenario-entry
Entry skill for HarmonyOS multi-device adaptation. Use when the task broadly concerns HarmonyOS multi-device adaptation, or when the correct scenario is still unclear. This skill classifies the request by phase and scenario type, then routes to one or more scenario files for screen and window size, fold state, avoid areas, interaction methods, natural orientation, or hardware access.
development24
ohos-test-ut-generation
为OpenHarmony C/C++代码生成单元测试用例。Use when: (1) 用户请求为子系统/模块/文件/函数生成单元测试；(2) 编写HWTEST/HWTEST_F测试用例；(3) 创建ohos_unittest；(4) 用户提到'生成测试用例'、'写单元测试'、HWTEST、ohos_unittest。Keywords: HWTEST, ohos_unittest, unit test, C++ testing, 单元测试生成
testing24
ohos-test-fuzz-generation
为 C/C++ 项目自动生成 FUZZ 测试用例、执行安全规范审查、生成语义化种子数据（corpus）。支持 LLVM libFuzzer 框架，兼容 OpenHarmony、Linux、Android 等构建系统。 **必须激活场景**： - 用户提及 "fuzz 测试"、"生成 fuzzer"、"创建 fuzz 用例"、"fuzz 规范检查"、"fuzz_test"、"LLVMFuzzerTestOneInput" - 需要为类/API 编写 FUZZ 测试 - 需要生成或验证 FUZZ 种子数据 - 需要检查 FUZZ 代码是否符合安全编码规范 **能力**：代码分析 → 用例生成 → 种子构造 → 26条规则合规审查 → 自动修复 → 报告生成。
development24
skills/check-test-code-quality/rules/R002
# R002: 错误码断言必须是number类型 ## 规则元信息 | 字段 | 值 | |------|------| | 规则编号 | R002 | | 规则名称 | 错误码断言必须是number类型 | | 严重级别 | Critical | | 规则分类 | simple rule（简单规则，可用grep/正则直接检测） | | 扫描范围 | 所有源代码文件（`.ets`, `.ts`, `.js`） | ## 问题描述 `error.code` 的类型为 `number`，但测试代码中经常使用 **string字面量** 对其进行断言或比较。这属于类型不匹配的低级错误。 **核心原因**: 错误码是数字类型（如 `401`、`14000011`），使用字符串（如 `"401"`、`'14000011'`）进行断言/比较是类型错误。 ## 修复方法 将所有 `error.code` 相关的 string 断言/比较改为 number 类型。 ## 检测模式 ### Pattern 1: `assertEqual` 中的 string 字面量（最常见） ```
development22
skills/check-test-code-quality/rules/R003
# R003: 禁止恒真断言 ## 规则概述 | 属性 | 值 | |------|-----| | 规则编号 | R003 | | 问题类型 | 禁止恒真断言 | | 严重级别 | Critical | | 规则分类 | 简单规则（正则匹配） | | 扫描范围 | 所有源代码文件（`.ets`, `.ts`, `.js`） | ## 问题描述 测试用例中使用 `expect(true).assertTrue()` 等恒真断言，断言只会产生成功结果，用例恒通过。此类断言未对接口实际返回值进行断言校验，相当于没有任何有效断言。 ## 检测模式（完整覆盖） R003规则必须检测以下**全部3种**恒真断言模式： ```python r003_patterns = [ # 模式1: expect(true).assertTrue() # 最常见的恒真断言形式，true断言为true，恒成立 re.compile(r'expect\s*\(\s*true\s*\)\s*\.\s*assertTrue\s*\('), # 模式2: expect(t
development22
skills/check-test-code-quality/rules/R004
--- rule: R004 type: 测试用例缺少断言 severity: Critical complexity: 最复杂规则（L5） scan_scope: .ets, .ts, .js --- # R004: 测试用例缺少断言 ## 文档导航 本文档较长（L5最复杂规则），按需阅读： - **快速执行**: 直接使用 [R004专用扫描脚本](#r004专用扫描脚本) `scan_r004_v3_generic.py` - **理解检测流程**: [检测逻辑总览](#检测逻辑总览)（8步流程图） - **核心实现**: [步骤1-5](#核心检测步骤详解)（it块提取、断言检查、递归间接断言） - **关键陷阱**: [陷阱#1](#步骤2提取函数体内容字符串感知的大括号匹配)（字符串大括号）、[陷阱#1b](#陷阱-1bcrucial反引号模板字符串中的撇号引号干扰)（反引号撇号） - **try-catch处理**: [步骤6-7](#步骤7try-catch-断言检测) - **修复建议格式**: [修复建议格式规范](#修复建议格式规范) --- ## 规则
development22
skills/check-test-code-quality/rules/R019
# R019: .key重复 > R019是工程级属性重复检测的基类规则。R020（.id重复）与此规则共享完全相同的扫描逻辑，仅检测目标不同。共享函数定义见 [references/project_level_scan.md](../../references/project_level_scan.md)。 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R019 | | 问题类型 | .key重复 | | 严重级别 | Critical | | 规则复杂度 | complex | | 扫描范围 | 同一独立XTS工程内的所有源代码文件（`.ets`, `.ts`, `.js`） | | testcase字段 | `-`（.key()不在it()块内） | ## 问题描述 一个独立XTS工程下的页面设计中，`.key()` 的字符串参数值不允许重复。即同一个独立XTS工程中，所有源代码文件里 `.key('xxx')` 的字符串参数值不能重复。 ## 检测模式 ```python import re KEY_PATTERN = re
development22
compile-analysis
This skill should be used when the user asks to "分析编译效率", "分析编译时间", "查看头文件依赖", "保存编译命令", "提取编译命令", "生成编译脚本", "保存这个文件的编译命令", "单独编译这个文件", "编译单个文件", "单编文件", "独立编译文件", "分析这个文件的头文件依赖", "头文件依赖关系", "这个文件依赖了多少头文件", "analyze compilation", "check header dependencies", "分析文件编译开销", "save compile command", "extract compile command", "generate compile script", "compile single file", "compile individual file", "standalone compile", "analyze header dependencies", "header dependency tree", "how many header files", or mentions analyzing compilation performance, build times, include dependencies, extracting/saving compilation commands, generating standalone compilation scripts, compiling individual files in isolation, or analyzing header file dependency relationships for specific source files in the ace_engine project. Provides comprehensive compilation efficiency analysis including timing, resource usage, dependency tree visualization with automatic saving, the ability to save reusable compilation scripts with performance monitoring, and standalone compilation capabilities using generated scripts.
development22
glslviewer-shader-debug
Adapt fragment shaders or runtime-shader snippets into standard GLSL, render them with glslViewer in headless mode, and inspect PNG output for shader debugging. Use when Codex needs to validate SDFs, gradients, masks, edge contours, or intermediate shader math by producing reproducible preview images from `.frag` files or translated shader snippets.
development22
graphic-2d-PR
The complete workflow for creating a pull request in the OpenHarmony graphic_graphic_2d repository, including creating an issue, linking them, and pushing to the fork.
tools22
skills/check-test-code-quality/rules/R014
# R014: 测试HAP命名不规范 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R014 | | 问题类型 | 测试HAP命名不规范 | | 严重级别 | Critical | | 规则复杂度 | simple | | 扫描范围 | BUILD.gn文件中的ohos_js_app_suite、ohos_js_app_static_suite、ohos_moduletest_suite模板 | | testcase字段 | `-`（BUILD.gn为非测试文件，无对应it()块） | ## 问题描述 测试HAP命名不符合规范要求。hap包命名采用大驼峰方式。 ## 命名规范 | 模板类型 | 检测目标 | 命名规范 | 正确示例 | |---------|---------|---------|---------| | `ohos_js_app_suite` | `hap_name` | 以`Acts`开头（A大写），以`Test`结尾（T大写） | `ActsAbilityTest` | | `ohos_js_app_static
development22
api-doc-checker
Comprehensive API documentation quality checker supporting 7 quality dimensions, SDK source consistency validation, and multi-format reporting. Use for API review, documentation quality assessment, error detection, and consistency checks.
development22
arkts-sta-playground
Execute ArkTS-Sta code snippets and files via the Playground HTTP API. Use this for testing ArkTS syntax, learning ArkTS features, verifying code logic, or demonstrating code execution results.
development22
audio_pr_create
使用oh-gc CLI管理GitCode仓库时使用 — 包括认证、issues、PRs、评审人、测试人员、标签、发布和仓库配置。当用户想要提交代码，创建ISSUE，创建PR,更新PR等涉及gitcode网页的操作时使用该技能。
tools22
skills/arkuix-module-adapter
--- name: ArkUIX Module Adapter description: Guide OHOS modules cross-platform adaptation with automated architecture analysis, code sync, and configuration generation. Use for adapting OHOS subsystem modules (@ohos.data.preferences, @ohos.intl, @ohos.multimedia.image, etc.) to Android/iOS. Provides 6-phase workflow: info collection → code sync → API analysis → architecture analysis → recommendation → implementation. Includes automated scripts for DTS analysis, architecture analysis, and configu
development22
arkts-static-spec
ArkTS static language specification reference for OpenHarmony. Use this skill when reading or writing ArkTS (.ets), explaining ArkTS type-system and static-semantics rules, validating code against the ArkTS spec, investigating ArkTS compile-time behavior, or comparing ArkTS with TypeScript migration guidance.
development22
arkui-api-design
This skill should be used when the user asks to "design ArkUI API", "add component property", "create Modifier method", "review ArkUI API", "deprecate API", "write JSDOC for ArkUI", or mentions OpenHarmony API design standards. Provides comprehensive guidance for ArkUI component API design following OpenHarmony coding guidelines, including static/dynamic interface synchronization, SDK compilation, and verification.
development22
skills/appmgr-api-generator
--- name: appmgr-api-generator description: Generate complete API implementation chain from AppMgrClient to AppMgrServiceInner. Use when adding new interfaces to the app_manager service that require: (1) Client implementation, (2) IPC proxy/stub code, (3) AppMgrService service implementation, (4) AppMgrServiceInner business logic implementation, (5) Complete call chain: client.cpp → proxy.cpp → stub.cpp → service.cpp → service_inner.cpp --- # AppMgr API Generator Automatically generate complet
tools22
android-to-harmonyos-migration-workflow
多 agent 协作的 Android 到 HarmonyOS 代码迁移工作流（迭代式）。当用户需要将 Android 项目迁移到 HarmonyOS 时触发，提供：1) Analyzer Agent 扫描代码结构 2) Planner Agent 制定迁移计划 3) Translator Agent 执行代码转换 4) **Validator Agent（验证代理）** 使用 **ohos-app-build-debug** skill 进行编译验证、应用打包和上板验证首界面 5) Tester Agent 验证功能（每个模块迁移完成后执行） 6) 所有模块迁移完成后，执行 Feature Comparator Agent 检查遗漏功能 7) UI Comparator Agent 验证界面一致性 8) 将未完成部分反馈给 Planner Agent 继续迭代。包含代码分析脚本、API映射表、组件转换模式和自动化验证工具。触发关键词：迁移Android到鸿蒙、Android迁移、HarmonyOS迁移、Java/Kotlin转ArkTS、Activity转Page、功能比对、UI比对。
development22
arkweb-build
This skill should be used when the user asks to "编译 ArkWeb", "build ArkWeb", "执行 ArkWeb 编译", "验证 ArkWeb 构建", "排查 ArkWeb build.log", "分析 ArkWeb 编译失败", or mentions build_arkweb.sh, src/out/<product>/build.log, ArkWeb native or browser build targets, or incremental ArkWeb build verification. Handles command selection, incremental build execution, success verification, and build.log-first failure diagnosis for ArkWeb projects.
development22
menu-debug
This skill should be used when user asks to "Menu宽度为0", "Menu宽度问题", "Menu显示异常", "Menu子窗口问题", "Menu layout异常", "recreate subwindow", "快速打开Menu问题", "Menu闪退", "Menu位置错误", "子窗口recreate", "Menu崩溃", "Menu打印recreate", "点击无响应", "点击菜单关闭", "菜单位置左上角", "菜单方向不对", "菜单避让坑", "宽度高度为0", or mentions any Menu component issues like Menu width being 0, Menu display problems, Menu subwindow issues, Menu layout exceptions, positioning errors, crashes, click response issues, menu closing immediately, incorrect positioning, direction issues, safe area issues, or zero width/height problems. Provides systematic debugging guidance for Menu component issues including width problems, subwindow recreation, layout exceptions, positioning errors, crash analysis, click issues, menu positioning, and dimension problems with automatic log enhancement patch generation.
tools22
arkweb-app-debug
Debug HarmonyOS ArkWeb applications using Chrome DevTools Protocol. Use when Claude needs to: (1) Start ArkWeb debugging sessions, (2) Connect Chrome DevTools to HarmonyOS apps via hdc, (3) Inspect webview elements, console, and network, (4) Test ArkWeb applications with Chrome DevTools MCP, (5) Troubleshoot webview debugging issues, or (6) Manage port forwarding and debugging sessions. Automatically detects project configuration, device connection, and debugging sockets. Works with ohos-app-build-debug skill for complete workflow.
tools22
ai-feedback-collector
Use this skill when a user wants to report, collect, normalize, classify, or template feedback about problems encountered while using AI tools in any scenario, including coding agents, chatbots, office assistants, search, writing, data analysis, or internal AI systems. The skill converts free-form problem descriptions into a structured feedback report with explicit labels, problem category, severity, scenario, impact, and follow-up questions.
tools22
ai-feedback-collector-zh
当用户想要反馈、收集、整理、归类或模板化 AI 工具使用过程中的问题时使用此 skill，适用于编码 Agent、聊天助手、办公助手、搜索、写作、数据分析、内部 AI 系统等任意场景。该 skill 会把自由描述转换为结构化反馈报告，并输出明确的问题分类、标签、严重程度、场景、影响和补充信息建议。
data-ai22
build-error-analyzer
This skill should be used when the user asks to "分析构建错误", "analyze build errors", "查看编译错误", "检查构建日志", "诊断链接错误", "fix build errors", "resolve compilation errors", "分析 last_error.log", "extract build error", "分析SDK的编译错误", "分析 SDK 编译错误", "analyze SDK build errors", "check SDK errors", "诊断 sdk 编译错误", or mentions analyzing build failures, compilation errors, linker errors, undefined symbols, SDK compilation errors, or needs to fix build issues. Focuses on reading last_error.log from out/<product>/ directory (or out/sdk/ for SDK builds) and providing specific fix recommendations based on error patterns and historical cases.
development22
skills/check-test-code-quality/rules/R001
# R001: 禁止使用getSync系统接口 ## 规则元数据 | 字段 | 值 | |------|-----| | 规则ID | R001 | | 规则名称 | 禁止使用getSync系统接口 | | 严重级别 | Critical | | 规则类别 | simple（简单规则，可用grep直接检测） | | 问题类型 | 源代码规范 | | 修复建议 | 使用`canIUse`接口替代或`差异化API`接口替代 | ## 问题描述 多设备XTS适配禁止使用任何形式的`getSync()`系统接口。`getSync()`是同步阻塞调用，在多设备测试场景中会导致死锁或超时问题。 **注意**: 本规则只针对**系统参数模块**的`getSync()`调用（如`@ohos.systemparameter`），不针对应用API的`getSync()`（如`mPreference.getSync()`）。 ## 扫描范围 ### 文件类型（关键） R001必须扫描**所有源代码文件**，不仅仅是测试文件： | 文件类型 | 扩展名 | 是否扫描 | |---------
development22
skills/check-test-code-quality/rules/R010
# R010: part_name/subsystem_name不匹配 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R010 | | 问题类型 | part_name/subsystem_name不匹配 | | 严重级别 | Critical | | 规则复杂度 | complex | | 扫描范围 | BUILD.gn files only | | testcase字段 | `-`（BUILD.gn为非测试文件，无对应it()块） | ## 问题描述 `part_name`/`subsystem_name`不匹配。BUILD.gn中声明的`part_name`必须在对应`subsystem_name`的components列表中存在。 ## 修复建议 使用完整的子系统-组件映射表，确保`part_name`在对应`subsystem`的components中。 ## 映射表数据源 映射表从以下三个配置文件构建（合并所有 subsystem → component 关系，共54个子系统、332个部件）： | 配置文件 | 主U
development22
skills/check-test-code-quality/rules/R005
# R005: 组件尺寸使用固定值 ## 规则信息 | 属性 | 值 | |------|------| | 规则编号 | R005 | | 问题类型 | 组件尺寸使用固定值 | | 严重级别 | Warning | | 规则复杂度 | complex | ## 问题描述 UI组件的width/height属性使用了固定像素值，导致多设备上页面适用性差，引起XTS适配问题。应使用百分比方式实现自适应布局。 **规范来源**: 用例低级问题.md 第5条 — "页面设计涉及组件尺寸大小，禁止使用固定值，考虑百分比方式" ## 扫描范围 **⚠️ 关键陷阱**: R005必须扫描**所有源代码文件**，不是测试文件！仅扫描`.test.ets`会漏报47226个问题（检出率0%）。 > 详见 [references/TRAPS.md](../../references/TRAPS.md) 陷阱2/7。 ## 检测逻辑 ### 步骤1: 收集文件 ```python def get_r005_scan_files(directory: str) -> list[str]
development22
skills/check-test-code-quality/rules/R007
# R007: Test.json禁止配置项 ## 规则信息 | 属性 | 值 | |------|------| | 规则编号 | R007 | | 问题类型 | Test.json禁止配置项 | | 严重级别 | Critical | | 规则复杂度 | simple | ## 问题描述 Test.json配置文件中存在禁止的配置项： - `setenforce 0` — 会关闭SELinux，引入安全问题 - `rerun: true` — 会导致测试报告出现异常 - `appfreeze.filter_bundle_name` — 会屏蔽appfreeze异常 **规范来源**: - 用例低级问题.md 第9条 — "禁止配置setenforce 0，会关闭selinux引入问题" - 用例低级问题.md 第10条 — "禁止配置rerun:true，会导致报告出现异常" - 用例低级问题.md 第11条 — "禁止配置appfreeze.filter_bundle_name，会屏蔽appfreeze异常" ## 扫描范围 | 应扫描 | 文件名 | |-----
development22
skills/check-test-code-quality/rules/R006
# R006: 禁止基于设备类型差异化 ## 规则信息 | 属性 | 值 | |------|------| | 规则编号 | R006 | | 问题类型 | 禁止基于设备类型差异化 | | 严重级别 | Critical | | 规则复杂度 | simple | ## 问题描述 在条件判断中使用 `deviceInfo.deviceType` 或从其赋值的变量进行设备类型判断，导致XTS测试无法在所有设备上正确执行。应使用 `SystemCapability` 和 `canIUse` 进行能力判断。 **规范来源**: 用例低级问题.md 第8条 — "禁止基于deviceInfo.deviceType差异化" ## 扫描范围 **⚠️ 关键陷阱（陷阱2）**: R006必须扫描**所有源代码文件**，不是测试文件！ | 应扫描 | 文件扩展名 | |--------|-----------| | **所有源代码文件** | `.ets`, `.ts`, `.js` | **错误做法**: 只扫描 `.test.ets` 文件 → 漏报部分问题 **正确做法**:
development22
skills/check-test-code-quality/rules/R011
# R011: testsuite重复 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R011 | | 问题类型 | testsuite重复 | | 严重级别 | Critical | | 规则复杂度 | complex | | 扫描范围 | 同一独立XTS工程内的所有测试文件 | | testcase字段 | `-`（describe不在it()块内） | ## 问题描述 一个独立XTS工程下不允许describe命名重复。即同一个独立XTS工程中，所有测试文件里的`describe()`函数的第一个参数不能重复。 ## 修复建议 确保testsuite命名唯一。重复的testsuite名称后追加`Adapt`+三位数字编号。 ## 自动修复规则 - **命名格式**: `{原testsuite名称}Adapt{三位数字}` - **保留首个**: 保留第一个出现的testsuite名称不变 - **递增编号**: 后续重复的依次编号为Adapt001, Adapt002, Adapt003... ## 修复建议格式 ```
development22
skills/check-test-code-quality/rules/R008
# R008: 用例声明格式不规范 ## 规则信息 | 属性 | 值 | |------|------| | 规则编号 | R008 | | 问题类型 | 用例声明格式不规范 | | 严重级别 | Warning | | 规则复杂度 | complex | ## 问题描述 测试用例的文档注释格式不符合规范要求，包括缺少注释标记、分隔符错误、空行等问题。 **规范来源**: 用例低级问题.md 第15条 — "XTS上库用例声明需符合要求" ### 规范要求 1. 文档注释以 `/**` 开头，以 `*/` 结尾，每行以 `*` 开始 2. 参数名以 `@` 修饰，参数名和参数值以（一或若干个）空格分隔，禁止使用其他分隔符 3. 文档注释结束行的下一行应紧接要修饰的测试用例，禁止出现空行 ## 扫描范围 | 应扫描 | 文件扩展名 | |--------|-----------| | **测试文件** | `.test.ets`, `.test.ts`, `.test.js` | ## 检测逻辑 ### 步骤1: 收集测试文件 ```python def get_
development22
skills/check-test-code-quality/rules/R009
# R009: @tc.number命名不规范 ## 规则信息 | 属性 | 值 | |------|------| | 规则编号 | R009 | | 问题类型 | @tc.number命名不规范 | | 严重级别 | Warning | | 规则复杂度 | simple | ## 问题描述 `@tc.number` 的命名不符合 `SUB_{子系统}_{部件}_XXXX` 格式要求。用例编号命名规则为 `SUB_{子系统}_{部件}_[XX?]_增加4位阿拉伯数字标识`，用例编号的递增要求以100为单位。 **规范来源**: 用例低级问题.md 第16条 — "@tc.number命名不符合要求" ## 扫描范围 | 应扫描 | 文件扩展名 | |--------|-----------| | **测试文件** | `.test.ets`, `.test.ts`, `.test.js` | **⚠️ 默认不扫描**: R009属于Warning级别，默认情况下不会被扫描。需要使用 `--level warning` 或 `--level all` 参数。 ## 命
development22
skills/check-test-code-quality/rules/R017
# R017: syscap.json配置多个能力 - **规则编号**: R017 - **严重级别**: Critical - **规则复杂度**: complex（需要JSON解析） - **问题类型**: 一个XTS工程的syscap.json文件中配置了多个syscap能力 - **修复方式**: 仅配置一个syscap能力 - **预期问题数量**: 3000+ ## 扫描范围 仅扫描`syscap.json`文件。 **文件定位规则**：在每个XTS工程目录下查找`syscap.json`文件（通常位于工程根目录或`src`目录下）。 ## 问题描述 一个XTS工程的`syscap.json`文件中配置了多个syscap能力。根据规范，每个XTS工程应仅配置一个syscap能力，即被测API对应的能力。 ## 检测逻辑 ### 核心算法 ```python import json import os import re def find_syscap_files(directory: str) -> list: """ 在目录下递归查找
development22
skills/check-test-code-quality/rules/R012
# R012: 签名证书APL等级和app-feature配置错误 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R012 | | 问题类型 | 签名证书APL等级和app-feature配置错误 | | 严重级别 | Critical | | 规则复杂度 | simple | | 扫描范围 | 所有.p7b文件（signature/*.p7b 和 根目录*.p7b） | | testcase字段 | `-`（p7b为非测试文件，无对应it()块） | ## 问题描述 签名证书p7b文件中使用了`system_core`等级或`app-feature`字段配置错误。 - **规范要求**： - `apl`字段：控制应用等级，默认普通应用配置为`normal`，禁止使用`system_core` - `app-feature`字段：控制普通应用还是系统应用，开源仓默认为`hos_normal_app` - 极少数情况可以使用`system_basic`（仅限于涉及特定受限权限） - 高于APL等级的权限依据"权限ACL是否
development22
skills/check-test-code-quality/rules/R013
# R013: 注释的废弃代码 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R013 | | 问题类型 | 注释的废弃代码 | | 严重级别 | Warning | | 规则复杂度 | complex | | 扫描范围 | 测试文件（`.test.ets`, `.test.ts`, `.test.js`） | | testcase字段 | 所属的it()名称，不在it()块内时为`-` | ## 问题描述 存在大量注释的废弃代码。测试文件中包含连续多行的注释代码块，这些代码已经不再使用但仍然保留在文件中，影响代码可读性。 ## 修复建议 直接删除注释的废弃代码。使用版本控制系统（如Git）保留历史记录，不需要在代码中注释保留。 ## 扫描逻辑 ### Step 1: 筛选测试文件 ```python import os TEST_EXTENSIONS = ('.test.ets', '.test.ts', '.test.js') def find_test_files(scan_root): test_files
tools22
check-test-code-quality
OpenHarmony XTS测试代码质量检查工具。扫描23条检查规则（Critical+Warning），自动生成Excel报告，检测低级问题和编码规范违规。使用此技能检查XTS测试代码质量、扫描编码规范问题、验证测试用例、发现低级问题、检查getSync接口使用、验证错误码断言格式、检查用例重复、检查HAP命名规范、扫描BUILD.gn配置问题、检查签名证书APL等级等。触发关键词：XTS、测试质量、代码检查、编码规范、测试用例检查、ACTS、DCTS、HATS。
development22
skills/check-test-code-quality/rules/R015
# R015: Level参数缺省 - **规则编号**: R015 - **严重级别**: Warning - **规则复杂度**: complex（需要代码分析） - **问题类型**: it()函数缺少Level参数 - **修复方式**: 添加`Level.LEVEL*`参数 - **预期问题数量**: 1100+ ## 扫描范围 仅扫描测试文件： - `.test.ets` - ArkTS测试文件 - `.test.ts` - TypeScript测试文件 - `.test.js` - JavaScript测试文件 ## 问题描述 `it()`函数声明时缺少`Level.LEVEL*`参数，不符合编码规范要求。每个测试用例必须指定测试级别。 ## 检测逻辑 ### 核心算法 ```python import re def scan_r015(file_path: str, content: str) -> list: """ 扫描文件中缺少Level参数的it()函数调用。 Args: file_path: 文件相对
development22
skills/check-test-code-quality/rules/R021
# R021: hypium版本号>=1.0.26 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R021 | | 问题类型 | hypium版本号不满足要求 | | 严重级别 | Critical | | 规则复杂度 | simple | | 扫描范围 | 独立XTS工程根目录下的 `oh-package.json5` | | testcase字段 | `-`（配置文件，不在it()块内） | ## 问题描述 一个独立XTS工程的 `oh-package.json5` 文件中，`devDependencies` 下的 `"@ohos/hypium"` 字段值必须 >= `1.0.26`。 ## 修复建议 将 `"@ohos/hypium"` 的版本号升级到 `1.0.26` 或以上。 ## 修复建议格式 ``` 路径: {文件路径}, 行号: {行号}, 问题描述: 在独立XTS工程 '{工程名称}' 中，oh-package.json5的devDependencies.@ohos/hypium版本号为 '{当前版本}'，低于最
development22
skills/check-test-code-quality/rules/R018
# R018: testcase重复 - **规则编号**: R018 - **严重级别**: Critical - **规则复杂度**: complex（需要文件级分析） - **问题类型**: 一个describe下不允许testcase（@tc.name）重复 - **修复方式**: 保留首个testcase不变，后续重复的追加`Adapt{三位数字}`后缀，并同步更新`@tc.name` - **预期问题数量**: 500+ ## 修复历史 | 版本 | 日期 | 修复内容 | |------|------|---------| | v1.1.0 | 2026-03-11 | 文件类型修复：添加`.test.js`文件类型扫描（storage目录51%的测试文件为.js格式，此前全部遗漏） | | v3.4.0 | 2026-03-12 | 正则表达式修复：添加`\b`单词边界，消除`split()`、`submit()`、`visit()`等误报（减少730个误报，85.9%） | | v3.4.0 | 2026-03-12 | 合并报告：同一组重复只报告第一个出现位置
development22
skills/check-test-code-quality/rules/R020
# R020: .id重复 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R020 | | 问题类型 | .id重复 | | 严重级别 | Critical | | 规则复杂度 | complex | | 扫描范围 | 同一独立XTS工程内的所有源代码文件（`.ets`, `.ts`, `.js`） | | testcase字段 | `-`（.id()不在it()块内） | ## 问题描述 一个独立XTS工程下的页面设计中，`.id()` 的字符串参数值不允许重复。即同一个独立XTS工程中，所有源代码文件里 `.id('xxx')` 的字符串参数值不能重复。 ## 与R019的关系 R020与R019的扫描逻辑完全一致，唯一差异是检测目标属性。两者共享相同的工程级检测基类（见 [references/project_level_scan.md](../../references/project_level_scan.md)），包括： - `find_independent_projects()` — 工程边界识别 - `get_pr
development22
code-problem-analyzer
深度代码问题分析与根因定位。用于分析代码行为异常、执行流程问题、配置错误等技术问题。当用户需要：1) 分析代码执行流程找到问题根因，2) 理解复杂代码逻辑和调用链，3) 定位异常行为的原因，4) 排查配置或状态问题。使用触发词：问题定位、分析问题、问题分析、代码分析、根因分析。
development22
skills/check-test-code-quality/rules/R023
# R023: 禁止errcode值(.code)类型强转后断言 ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R023 | | 问题类型 | 禁止errcode值类型强转后断言 | | 严重级别 | Critical | | 规则复杂度 | simple | | 扫描范围 | 所有源代码文件（`.ets`, `.ts`, `.js`） | | testcase字段 | 需解析`it()`块范围 | ## 问题描述 errcode值（`.code`）本身一定是number类型，不允许使用`Number()`等类型强转后再进行断言。类型强转是对errcode类型问题的规避行为，正确做法是给开发提单修复API的errcode类型。 ## 修复建议 1. 新增API接口出现的errcode类型问题：给开发提单修复 2. 已转测的API，给开发提单后，测试侧先按错误的（string类型）上库，**不使用`Number()`强转规避** ## 修复建议格式 ``` 路径: {文件路径}, 行号: {行号}, 问题描述: errcode值断言
development22
ets-runtime-dev
Plan, implement, review, and validate general ets_runtime changes with a planner/worker/reviewer workflow. Use when working under arkcompiler/ets_runtime, or when handling ets_runtime feature work, bug fixes, refactors, test additions, and compile-validation tasks.
development22
generate-interface-uml
This skill should be used when user asks to "generate UML", "create sequence diagram", "生成时序图", "生成类图", "generate PlantUML", or discusses generating UML diagrams for new interfaces or API design.
development22
gitcode-cli
Use when managing GitCode repositories from the terminal with oh-gc CLI — auth, issues, PRs, reviewers, testers, labels, releases, and repo config. Triggers on oh-gc commands, GitCode issue/PR management, or when user wants to interact with GitCode without a browser.
tools22
cpp-include-sorter
Automatically sorts C/C++ header files (#include statements) with full support for conditional compilation blocks. Use when Claude needs to organize
tools22
create-pr
Automated PR workflow: analyze code changes, auto-generate Issue/PR descriptions, auto-commit with DCO sign-off, auto-push, auto-create Issue + PR, and link PR to Issue.
development22
cpp-core-guidelines-review
Parallel C++ Core Guidelines code review using multiple specialized sub-agents. Use when reviewing C++ code, modules, or files against C++ Core Guidelines to identify violations. Each sub-agent reviews against a specific guideline section (Functions, Classes, Resource Management, etc.) and outputs findings to separate markdown files in the review/ directory, followed by a consolidated summary.
development22
gitcode-pr
Handle GitCode PR workflow for OpenHarmony - commit changes, push to fork remote, create issue, create PR from fork to upstream using repo's .gitee/PULL_REQUEST_TEMPLATE.zh-CN.md with issue linking via
development22
format
Run clang-format on the current git changes. Only keep the formatting fix on the changed lines.
development22
dsoftbus_safety_guard
OpenHarmony软总线代码安全检视专家 - 全面检查C/C++代码的安全编码规范和日志规范。 涵盖40+条安全规则，包括指针安全、内存管理、锁管理、敏感信息保护等关键领域。 提供跨文件调用分析和控制流分析，生成详细的代码审查报告。 仅在用户输入包含"软总线安全卫士"时触发。 ⚠️ 重要：此技能为只读审查工具，不修改源文件。
tools22
skills/check-test-code-quality/rules/R016
# R016: testcase命名规范 - **规则编号**: R016 - **严重级别**: Warning - **规则复杂度**: complex（需要代码分析） - **问题类型**: testcase名称包含特殊字符（仅允许英文字母、数字、下划线、连字符） - **修复方式**: 移除特殊字符，追加`Adapt`+三位数字后缀，同步修改`@tc.name` - **预期问题数量**: 400+ ## 扫描范围 仅扫描测试文件： - `.test.ets` - ArkTS测试文件 - `.test.ts` - TypeScript测试文件 - `.test.js` - JavaScript测试文件 ## 问题描述 testcase名称（`it()`的第一个参数）中包含特殊字符。仅允许使用英文字母（`a-zA-Z`）、数字（`0-9`）、下划线（`_`）和连字符（`-`）。 **检测对象**: 以`it()`的第一个参数为准，不检测`@tc.name`的值。`@tc.name`仅在修复阶段同步修改。 ## 检测逻辑 ### 核心算法 ```python im
development22
skills/check-test-code-quality/rules/R022
# R022: errcode值(.code)值断言使用"==="非"==" ## 规则信息 | 属性 | 值 | |------|-----| | 规则编号 | R022 | | 问题类型 | errcode值断言使用==而非=== | | 严重级别 | Critical | | 规则复杂度 | simple | | 扫描范围 | 所有源代码文件（`.ets`, `.ts`, `.js`） | | testcase字段 | 需解析`it()`块范围 | ## 问题描述 测试用例中对`.code`（errcode）进行值断言时，必须使用严格相等运算符`===`，不允许使用宽松相等运算符`==`。 ## 修复建议 将`==`替换为`===`。例如：`expect(err.code == 401)` 改为 `expect(err.code === 401)`。 ## 修复建议格式 ``` 路径: {文件路径}, 行号: {行号}, 问题描述: errcode值断言使用了宽松相等运算符'=='，应使用严格相等运算符'==='。 ``` ## 扫描逻辑 ### Step 1
development22
code-checker
Scan C/C++ codebases for code quality issues including extra large files/functions and circular dependencies. Use when the user asks to check file sizes, find oversized functions, detect circular dependencies, analyze code complexity, find code smells, or identify maintainability issues in C/C++ code. Supports scanning individual files or entire directories with configurable thresholds.
development22
ai-generated-ut-code-review
Use when reviewing or scoring AI-generated unit tests/UT code, especially when coverage, assertion effectiveness, or test quality is in question and a numeric score, risk level, or must-fix checklist is needed
development18
ai-generated-business-code-review
Use when reviewing or scoring AI-generated business/application code quality in any language, especially when a numeric score, risk level, or must-fix checklist is requested, or when C++ code must comply with OpenHarmony C++ and security standards
development18
hb-build
智能编译 ability_runtime 组件，通过检测修改的文件自动确定编译目标。支持多目标一起编译、自动重试判断、智能错误分析。触发关键词："编译"、"构建"、"compile"、"build"、"make"、"make file"。
development13