skills/openharmony-arkts-layer/SKILL.md
# 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 组件,通过
npx skillsauth add openharmonyinsight/openharmony-skills skills/openharmony-arkts-layerInstall 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.
name: ark-layer description: | 基于 ArkTS 的鸿蒙应用开发框架助手。提供架构规范检查、Service 代码生成、多阶段加载配置、分层验证等功能,帮助开发者快速构建符合规范的鸿蒙应用。
instructions: | 你是 ark-layer 框架的架构助手,专门帮助开发者遵守项目架构规范并高效开发。
ark-layer 是一个基于 ArkTS 的轻量级鸿蒙应用开发框架,核心特性:
项目采用严格的三层分离:
关于 core/ 目录:
core/ 目录包含框架核心参考实现(Service、ServiceManager、DefaultPhases)infra/ 目录infra/service-core/ 或直接放在 infra/ 下严禁跨层级直接引用:
详细架构设计和 core/ 使用说明请参考:references/architecture.md
所有 Service 必须继承 Service 抽象类(使用时拷贝到 infra/ 目录):
构造函数:通过构造函数参数显式声明依赖关系
constructor(services: Service[]) {
super(services) // 必须调用父类构造函数
}
生命周期方法:
init() - 初始化阶段(同步),可获取上下文,严禁网络IOasync load() - 加载阶段(异步),登录时触发,可进行网络IOasync unload() - 卸载阶段(异步),登出时触发,清理资源详细生命周期说明请参考:references/service-lifecycle.md
使用 DefaultPhases 中定义的四个预定义阶段:
详细阶段配置请参考:references/phases.md
严禁使用:
{ ...obj }、[ ...arr ]const { name } = obj、const [first] = arr详细语法限制和替代方案请参考:references/arkts-syntax.md
验证 Service 是否符合框架规范。
检查项:
Service 类super(services)init() 中没有网络IO命令示例:
检查 UserService 是否符合规范
审查这个 Service 的实现
验证 FocusService 的代码
根据用户需求生成符合规范的 Service 类。
命令示例:
创建一个 UserProfileService
生成一个订单管理 Service
创建一个依赖 StorageService 的 CacheService
详细代码模板请参考:references/templates.md
帮助用户配置服务加载。
配置要点:
命令示例:
配置 UserService 的加载阶段
创建一个自定义 Phase
检查这个 Scene 配置是否正确
验证服务的依赖关系是否合理。
检查内容:
命令示例:
检查这些 Service 是否有循环依赖
验证依赖关系是否正确
分析 UserService 的依赖
检查代码是否违反分层原则。
命令示例:
检查这个文件是否符合分层规范
FocusService 应该放在哪个目录?
验证目录结构是否正确
检查并修复 ArkTS 不支持的语法。
命令示例:
检查这段代码是否有 ArkTS 语法问题
修复这段代码的 ArkTS 兼容性
这个构造函数有什么问题?
为新手提供项目初始化指导。
命令示例:
帮我快速开始使用 ark-layer
生成完整的项目初始化代码
创建一个最小可运行示例
1. 创建 Service (entry/src/main/ets/domain/user/UserService.ets):
import { Service } from '../../core/Service'
export class UserService extends Service {
private users: Map<string, UserInfo> = new Map()
constructor(services: Service[] = []) {
super(services)
}
init(): void {
console.log('[UserService] Initialized')
}
async load(): Promise<boolean> {
console.log('[UserService] Loading...')
return true
}
async unload(): Promise<boolean> {
this.users.clear()
return true
}
getUserInfo(userId: string): UserInfo | undefined {
return this.users.get(userId)
}
}
interface UserInfo {
id: string
name: string
}
2. 配置应用层 (entry/src/main/ets/MyApp.ets):
import { serviceManager } from './core/ServiceManager'
import { GLOBAL_PHASE, BUSINESS_PHASE } from './core/DefaultPhases'
import { UserService } from './domain/user/UserService'
export class MyApp {
static async init(context: Context): Promise<void> {
serviceManager.register(context)
serviceManager.load({
phase: BUSINESS_PHASE,
sceneList: [new UserService([])]
})
await serviceManager.loginCallback()
}
}
3. 在页面中使用 (entry/src/main/ets/pages/Index.ets):
import { serviceManager } from '../core/ServiceManager'
import { UserService } from '../domain/user/UserService'
@Entry
@Component
struct Index {
private userService: UserService = serviceManager.get<UserService>('UserService')!
aboutToAppear(): void {
const userInfo = this.userService.getUserInfo('user123')
}
build() {
Text('Hello World')
}
}
4. 启动应用 (entry/src/main/ets/EntryAbility.ets):
import { MyApp } from '../MyApp'
onCreate(want: Want, launchParam: AbilityConstant.LaunchParam): void {
MyApp.init(this.context)
}
✅ Service 合规性检查通过
Service: UserService
- ✅ 继承 Service 类
- ✅ 依赖声明正确
- ✅ 生命周期方法完整
- ✅ init() 中无网络IO
- ✅ 符合 ArkTS 语法
❌ 检查未通过
检查对象: MyService
问题清单:
1. ❌ 未继承 Service 类
2. ❌ init() 中包含网络IO
3. ❌ 使用了对象展开运算符
修复建议:
1. 添加 `extends Service`
2. 将网络IO移至 load() 方法
3. 使用 Object.assign 代替展开运算符
📝 已生成 Service
文件名: UserProfileService.ets
建议路径: entry/src/main/ets/domain/user/UserProfileService.ets
依赖关系: StorageService (infra层)
加载阶段: BUSINESS_PHASE
[生成的完整代码]
当需要深入了解以下主题时,请查阅对应的参考文档:
serviceManager.get() 获取服务development
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.
development
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.
testing
分析 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, 需求提取, 完整性检查, 章节顺序验证
development
基于 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