openharmonyinsight/openharmony-skills

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.

First seen Mar 13, 2026

Installation

$ npx skills add openharmonyinsight/openharmony-skills --skill ets-runtime-dev

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from openharmonyinsight/openharmony-skills · top by installs.

npx skills add openharmonyinsight/openharmony-skills

Browse all from openharmonyinsight/openharmony-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 33
Default branch main
Open issues 2
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 8,818 B
  • docs SUMMARY.md 288 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 41 installs

SKILL.md

ets-runtime-dev — ets_runtime Development Orchestrator

你是 Planner,负责编排 ets-runtime-dev-workerets-runtime-dev-reviewer agent 来完成 ets_runtime 开发任务。

SKILL_ROOT 定位

启动时必须先确定 SKILL_ROOT(ets-runtime-dev 技能资源目录,包含 review.mdformat.sh 等文件):

  1. 在项目根目录下搜索 **/ets-runtime-dev/review.md
  2. 找到后,取 review.md 所在目录作为 SKILL_ROOT
  3. 如果找不到,向用户询问路径

后续所有 SKILL_ROOT/ 引用均指此路径。

共享资源路径

以下文件位于 SKILL_ROOT/,Worker/Reviewer 通过 Planner 注入的路径读取:

文件 用途
review.md 5 项评分标准(三方共享)
mistakes.md 常见错误(可追加,三方共享)
.clang-format 代码格式化配置
format.sh 格式化 git 工作区中已修改的 C/C++ 文件(仅修改行)
ets_runtime.md ets_runtime 编译、测试、运行参考(按需读取)
states.md Task 状态定义(三方共享)
plan-template.md Plan 输出模板
tasks-template.md tasks.md 模板

Task 状态定义详见 SKILL_ROOT/states.md


执行流程

恢复检查

在开始需求确认之前,先检查当前分支是否有已存在的 plan/tasks:

  1. 获取当前分支名:git branch --show-current
  2. 检查 .agents/ets-runtime-dev/<branch-name>/plan.md 是否存在
  3. 如果存在:读取 plan.mdtasks.md,然后询问用户:

- 继续未完成的任务:根据各 Task 的 Status 和 Reason 决定恢复动作(参照下方"Task 状态定义"表),从对应步骤继续执行 - 开始新任务:进入正常的需求确认流程(覆盖旧的 plan.md 和 tasks.md)

  1. 如果不存在:进入正常的需求确认流程

如果用户已经明确说了“继续未完成任务 / 恢复当前任务”或“开始新任务 / 覆盖旧 plan”,不要重复追问,直接按用户指定路径执行。

0. 创建分支

询问用户:

  • 新建分支:询问分支名和基于哪个分支创建(默认当前分支),执行 git checkout -b <branch-name> <base-branch>
  • 在当前分支工作:不做任何操作

如果用户已经明确说了“不要新建分支 / 在当前分支工作”,或已经给出新分支名和 base branch,直接遵从,不要重复询问

1. 需求确认

在写任何代码之前,必须先完成需求确认:

  1. 质疑需求合理性:是否真的需要?有没有更简单的方案?
  2. 明确实现范围:哪些功能需要实现、哪些可以简化或跳过
  3. 识别风险:架构差异、依赖关系等可能导致的问题
  4. 确认参考资料:如有参考代码或设计文档,确认具体路径

默认先给出一段精简的“需求确认结论”,覆盖上述 4 点,再让用户确认。

如果用户已经明确要求“直接出 Plan / 先不要来回追问 / 等我确认 Plan 再继续”,则不要反复追问;把未确认的信息写成显式假设,放进回复和 plan.md,等用户在 Plan 评审阶段修正。不要把推断项写成已确认事实。

2. 输出 Plan

需求确认后,参照 SKILL_ROOT/plan-template.md 输出实现计划,并立即持久化:

  1. 获取当前分支名:git branch --show-current
  2. 创建目录:.agents/ets-runtime-dev/<branch-name>/
  3. 创建目录:.agents/ets-runtime-dev/<branch-name>/docs/
  4. 保存 .agents/ets-runtime-dev/<branch-name>/plan.md

- Plan 保持精简,只写任务拆分、目标文件、测试策略、验收标准和风险 - 不要在 plan.md 中粘贴完整测试代码或完整实现代码 - 严格沿用 plan-template.md 的标题和字段名;不要改写成自由发挥的小标题 - 如果某个实现落点是根据分支名、历史提交、相邻代码推断出来的,要写在 Assumptions / Open questions 中,标明“待用户确认”

  1. 参照 SKILL_ROOT/tasks-template.md 生成 .agents/ets-runtime-dev/<branch-name>/tasks.md

- tasks.md 只使用模板里的 Status / Reason / Progress - 不要自创 Compile Validation StatusBuild Result 之类额外字段

  1. 向用户汇报时,明确列出刚刚持久化的精确路径:

- .agents/ets-runtime-dev/<branch-name>/plan.md - .agents/ets-runtime-dev/<branch-name>/tasks.md

  1. 如果当前阶段只落了 plan/tasks,没有改源码或测试,明确说清楚“当前只修改了 .agents/ets-runtime-dev/<branch-name>/...,没有修改 ecmascript/test/ 等实现路径”
  2. 如果需要用 git 状态证明改动范围,优先使用 git status --short --untracked-files=all,避免只显示 ?? .agents/ 这种过粗粒度结果

⚠️ 持久化后,让用户确认 Plan 没有问题。用户可提修改意见,迭代直到确认后才能进入下一步。

3. 派发 Worker

后台派发 ets-runtime-dev-worker,并在任务描述中注入以下信息:

  • 任务描述:[Task 描述]
  • 技能根路径(SKILLROOT):SKILLROOT
  • 项目根路径:[project_root]
  • 文档目录:[docs_dir]
  • 任务追踪文件:.agents/ets-runtime-dev/<branch-name>/tasks.md
  • 当前任务编号:Task N
  • 参考资料:[如有参考代码或文档,注明路径]
  • 约束:禁止编译
  • 完成后要求:更新 tasks.md,标记完成步骤为 [x],并将 Status 改为 in_review

如果当前 Task 的 Status 是 rework,派发内容中要额外明确:

  • 这是继续已有 Task,不是开始新任务
  • 逐条附上 Reviewer 的修复意见,转成 Worker 可执行的 checklist
  • 如果上一轮 plan 中仍有占位项或推断项,要求 Worker 先在既有上下文中收敛真实落点,再动手修改

Worker 完成后会执行 SKILL_ROOT/format.sh 格式化代码。

Worker 返回 BLOCKED 时,Planner 读取 tasks.md 中对应 Task 的 Reason,按原因处理:

  • clang-format not found:提示用户安装 clang-format(如 apt install clang-formatbrew install clang-format),安装后重新派发该 Task
  • 其他原因:根据具体情况决定(提示用户 / 调整任务 / 升级决策)

4. 派发 Reviewer

后台派发 ets-runtime-dev-reviewer,并在任务描述中注入以下信息:

  • 技能根路径(SKILLROOT):SKILLROOT
  • 任务描述:[Task 描述]
  • 文档目录:.agents/ets-runtime-dev/<branch-name>/docs/
  • 任务追踪文件:.agents/ets-runtime-dev/<branch-name>/tasks.md
  • 当前任务编号:Task N
  • 参考资料:[如有参考代码或文档,注明路径]
  • Review 完成后要求:

- 通过(≥95):Status 改为 completed,更新 Progress - 未通过(<95):追加本轮扣分摘要

Review 结果处理

结果 动作
≥95 分 通过,进入下一步
<95 分(第 1-3 轮) 将 Reviewer 的修复建议附给 Worker,重新派发
<95 分(第 3 轮后) 升级给用户决策

5. 编译验证

按需读取 SKILLROOT/etsruntime.md 的“Planner 编译验证流程”章节,简要:

  1. ets_runtime 项目:自动组装命令并直接执行,Status 改为 building
  2. 非 etsruntime 项目:Status 改为 blocked,Reason 写 not an etsruntime repo, build command unknown,再向用户询问编译命令
  3. 编译通过:Status 改为 done
  4. 编译失败:Status 改为 build_failed,Reason 写编译错误摘要,附错误信息重新派发 Worker

编译验证阶段只允许复用 Task 的 StatusReason 字段表达状态;不要额外新增 Compile Validation Status / Compile Validation Reason 一类字段。 编译验证不是新任务,不要追加 Task 2: Compile Validation 之类的结构;仍然更新当前正在进入验证阶段的那个 Task。

6. DONE

所有 Task 状态为 done 后,汇总报告结果。

plan.md 和 tasks.md 不删除,作为历史记录保留。


错误追加

工作过程中如果发现新的错误模式(Worker 或 Reviewer 反复犯的错),应追加到 SKILL_ROOT/mistakes.md


重要约束

  • Worker 禁止编译,编译由 Planner 在步骤 5 统一执行
  • Reviewer 禁止编译,只做代码审查
  • 路径等由 Planner 在派发时注入,不要硬编码