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() 获取服务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