Skip to main content
arkuix-module-adapter 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 configuration generation.
Jump to install Skills Marketplace Discover and explore AI skills built by the community.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Show prompt details A direct command skips the review prompt. Inspect the source before running it.
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill arkuix-module-adapterThe command stays on one line. Scroll horizontally to inspect it before copying.
Prefer a local copy? Download the files currently available to SkillsMP.
Download Zip Downloading... More from this repository 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.
ohos-design-arkui-api-competitive-analysis 对 ArkUI 公共 UI API 与 Android（Compose/View）和 iOS（SwiftUI/UIKit）进行可审计的能力与规格竞品分析。 适用于接口设计评审、能力补齐、Android/iOS 与 ArkUI 迁移评估、API 对标和 capability gap analysis， 覆盖触摸/指针输入、键盘快捷键、手势、组件、布局、状态和动画。要求锁定作用域与版本，以 interface_sdk-js 为 ArkUI 公共接口权威源，优先引用 Android/iOS 官方文档，区分等价关系，并输出带逐项证据、影响和优先级建议的报告。
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.
Related occupations SOC
Based on SOC occupation classification
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 configuration generation.
ArkUIX Module Adapter Skill
Overview
Guide OHOS modules through cross-platform adaptation with automated analysis and code generation. This skill transforms Claude into a specialized adaptation assistant with domain expertise in OHOS/ArkUI-X architecture.
Quick Start
User: "I need to adapt @ohos.data.preferences module"
The skill automatically guides through all 6 phases of adaptation.
6-Phase Workflow
Phase 1: Information Collection
Collects minimal information upfront (module name), then lazily collects additional details (repository name, storage path) only when needed.
Output : Module identification information
Phase 2: Code Existence Check & Sync
Intelligently checks if OHOS code already exists before syncing. Avoids redundant operations.
Decision Tree :
Check .repo/manifests/openharmony-master.xml
Check plugins/ directory
Only sync if both checks fail (with repository verification on GitCode)
Output : Sync status or repository verification results
Phase 3: API Interface Analysis
Analyzes .d.ts file to determine @crossplatform coverage.
Metrics :
Total interface count (by category)
Adapted vs needs adaptation counts
Coverage percentage
Detailed list of interfaces needing adaptation Output : Comprehensive API statistics with coverage progress bar
Automation : scripts/dts_analyzer.py interface/sdk-js/api/@ohos.{module}.d.ts
Phase 4: Architecture Analysis Analyzes OHOS module code composition and platform dependencies.
Code volume statistics (NAPI, business logic, platform-specific)
Platform dependency ratio
Internal and external dependencies
Platform implementation necessity (C/C++ native vs platform-specific code)Architecture diagrams (module structure, dependencies, call flow)
Key Rule : C/C++ Cross-Platform Native Support
Analyzes whether module actually requires Android/iOS platform code
Many data modules (preferences, RDB, crypto) are pure C/C++ and require zero platform-specific implementation
Only path/configuration differences needed (~50 lines per platform)
Output : Detailed code composition and dependency analysis
Automation : scripts/architecture_analyzer.py foundation/{module_path}
Phase 5: Architecture Recommendation Recommends adaptation mode based on analysis: OHOS Reuse / Independent / Hybrid
Mode Code Reuse New Code Time Best For OHOS Reuse 90-95% 500-800 lines 4-6 weeks Data-focused (preferences, kv_store) Hybrid 60-80% 1,500-2,500 lines 6-10 weeks Mixed (location, sensor) Independent 10-30% 4,000-6,000 lines 10-16 weeks Platform-heavy (BLE, pasteboard)
Output : Recommended mode with rationale and effort estimates
Phase 6: Implementation Guidance Provides actual implementation code with complete examples for:
Pure virtual interface (OHOS repo)
OHOS thin wrapper (100% forwarding)
Android JNI adapter (complete with error handling)
iOS Objective-C++ adapter (complete with @try-@catch)
Build configuration (GN templates)
Unit tests
Output : Production-ready code with comprehensive error handling
Automation : scripts/code_generator.py {module} {repo} --api-version {ver}
Key Features
🤖 Automated Scripts All scripts are in scripts/ directory:
python3 scripts/dts_analyzer.py interface/sdk-js/api/@ohos.data.preferences.d.ts
python3 scripts/architecture_analyzer.py foundation/distributeddatamgr/preferences
python3 scripts/code_generator.py data/preferences distributeddatamgr_preferences --api-version 23 --dry-run
python3 scripts/code_generator.py data/preferences distributeddatamgr_preferences --api-version 23
📚 Progressive Disclosure Core workflow in SKILL.md (this file), detailed content in references:
Phase Details : references/phase{1-6}*.mdArchitecture Modes : references/architecture-modes.mdCode Examples : references/code-examples.mdTemplates : assets/templates/ (code templates for reuse)
🎯 Three Architecture Modes
OHOS Reuse Mode (90-95% reuse) For data-focused modules with minimal platform dependencies.
Platform-independent business logic >90%
Thin platform adapters (JNI/ObjC++)
Zero OHOS runtime overhead
C/C++ Native modules may require zero platform code (up to 100% reuse) Example Modules : preferences, kv_store, http
Independent Implementation Mode (10-30% reuse) For modules with heavy platform API dependencies.
Platform-specific code >70%
Native framework integration
Each platform has own implementation
Example Modules : bluetooth, pasteboard, camera
Hybrid Mode (60-80% reuse) For mixed data/platform logic modules.
Extract common data structures
Service abstraction layer
Shared business logic
Example Modules : geolocation, sensor, request
Implementation Checklist Use this checklist to track adaptation progress:
Phase 1: Information Collection
Phase 2: Code Sync
Phase 3: API Analysis
Phase 4: Architecture Analysis
Phase 5: Architecture Recommendation
Phase 6: Implementation
Mandatory Configuration Files After code generation, ensure all 4 files are updated:
Troubleshooting Repository not found on GitCode?
Check all 4 mandatory files exist
Verify module name format (use forward slashes)
Ensure .d.ts file path is correct
Check GN configuration syntax
Verify dependency declarations
Check for missing includes
Related Skills
arkuix-api-adapter - For adapting individual API methods within a module
Tips
Start Small : Try with a simple module first (e.g., preferences)Use Dry-Run : Always use --dry-run flag before applying changesVerify Repository : Always verify repository exists before syncingRead References : Consult detailed references for complex phasesRun Tests : Always run tests after implementation 