Agent Skills: ArkUI API 竞品分析

>

UncategorizedID: openharmonyinsight/openharmony-skills/ohos-design-arkui-api-competitive-analysis

Install this agent skill to your local

pnpm dlx add-skill https://github.com/openharmonyinsight/openharmony-skills/tree/HEAD/skills/ohos-design-arkui-api-competitive-analysis

Skill Files

Browse the full folder contents for ohos-design-arkui-api-competitive-analysis.

Download Skill

Loading file tree…

skills/ohos-design-arkui-api-competitive-analysis/SKILL.md

Skill Metadata

Name
ohos-design-arkui-api-competitive-analysis
Description
>

ArkUI API 竞品分析

对指定 ArkUI 公共 UI API 产出结构一致、证据可追溯的 Android/iOS 对标报告。只分析公开能力和迁移影响;允许给出最小用法示例,但不要修改产品代码或 ace_engine 实现。

任务边界

输入:ArkUI API、组件或能力主题;分析目的;默认 Android+iOS 对标平台;可选作用域层级、平台版本和报告深度。

输出:Analysis Brief、Capability Checklist、Comparator Map、三平台事实、能力矩阵、影响评估、分级建议、待核事项和来源审计。

不适用:性能实测、产品代码实现、Flutter/Web 对标、ace_engine 修改,或仅凭内部实现和非官方资料判断公共能力。

不可违反的规则

规则职责以引用文件为准:workflow.md 是阶段顺序与门禁的唯一来源,analysis-dimensions.md 是子类型闭环的唯一来源,platform-source-routing.md 是 Android/iOS 路径与官方入口的唯一来源,report-template.md 是输出顺序与条件区块的唯一来源。本节只保留跨阶段硬约束;摘要措辞与引用文件不一致时,以对应职责文件为准。

  1. 以 interface_sdk-js 作为 ArkUI 公共接口定义的权威源;ace_engine 内部定义只能用于实现对照。
  2. Android 和 iOS 取证优先使用各平台官方文档,顺序为官方 API Reference、Guide、Sample;平台源码只作实现佐证,社区资料只用于定位官方入口。
  3. 研究前锁定作用域层级和平台版本,不得降低用户指定层级或混用不同版本。
  4. 先分别提取三平台事实,再进行比较;取证阶段不预写“更好、缺失、独有”等结论。
  5. 对标关系只能标记为直接等价、功能等价、组合实现、替代方案或未找到等价能力。
  6. 官方事实与分析推论分开记录;每项实质性断言必须回溯到 Fact ID 和 Source ID。
  7. 对“缺失、独有、优于”完成双向检索;证据不足时标记 待核,不得进入确定性结论。
  8. 领域事实必须按锁定版本从官方源动态取证;不要依赖内置字段速查表,也不要把某一领域的字段、状态或检查项套用到其它领域。
  9. Analysis Brief 必须是首个用户可见阶段产物;在它之前不要输出结论摘要、平台优劣或 API 推荐。
  10. 用户要求“只给名称”“一页结论”或其它压缩输出时,使用 report-template.md 的快速扫描单表;至少保留作用域、Comparator Map、一条已定义 Fact/Claim、来源和待核状态,名称相似不能替代映射判断。
  11. 命中 analysis-dimensions.md 定义的具体子类型时,例如原始触摸/指针、键盘快捷键、连续手势、虚拟化集合、Flex 类布局或显式动画,必须完成对应闭环清单;每项填写 Coverage status(confirmed、pending 或 not-applicable),不得用宽泛的“事件”触发其它输入子类型规则。
  12. 输出中引用的每个 Capability、Fact、Claim 和 Source ID 都必须在同一交付内容中定义;不得引用只存在于内部过程的编号。
  13. 用户要求跳过官方文档时,明确说明不能跳过 Android Developers 和 Apple Developer,并按 platform-source-routing.md 解释官方文档、平台源码和社区资料的证据角色。
  14. 子类型的必查字段、状态和闭环范围只以 analysis-dimensions.md 为准;本文件不复制其清单。
  15. 键盘快捷键的 Path Check、候选 API、排除项和官方取证入口只以 platform-source-routing.md 为准;完成规定路径事实后才能确认 Comparator Map。其它交互按自身分发、命中、仲裁或 responder 事实取证,不套用键盘 Path Check 表。
  16. 条件矩阵、Path Check 顺序和快速/完整报告结构只以 report-template.md 为准;命中条件区块时不得删除。
  17. 官方来源冲突且输入不完整时,必须请求精确符号、公共定义路径、文档链接、双方版本基线和文档时间信息;不得用预设基线代替缺失输入。
  18. 公共签名引用命名常量、枚举或子属性页时,继续追踪官方定义,直到具体值、默认值、单位和语义闭环;可用的官方精确来源不得无故保留为 pending。
  19. 完整报告和快速扫描的每条 Comparator Map 都必须使用 evidence-ledger.md 的 canonical schema:Android/iOS 分别填写 target、mapping type 和 rationale/exclusions,并关联支撑各平台映射的 Fact ID、Source ID、Claim ID 与 Claim status;不得用 ArkUI 单方证据支撑竞品映射,也不得省略或合并平台 mapping type。

渐进式加载

| 阶段或条件 | 读取内容 | 此前不要加载 | |---|---|---| | 开始分析 | 完整读取 references/workflow.md | 无 | | 起草 Analysis Brief、选择具体子类型和拆解能力 | 完整读取 references/analysis-dimensions.md | Target 与 Scope tier 尚未识别时不要加载 | | 建立事实和断言台账 | 完整读取 references/evidence-ledger.md | 尚未形成 Capability Checklist 时不要加载 | | 提取 ArkUI 公共定义 | 完整读取 references/authoritative-sources.md | 尚未进入 ArkUI 取证阶段时不要加载 | | 映射 Android/iOS 对标对象 | 完整读取 references/platform-source-routing.md | ArkUI 原子能力尚未拆解时不要加载 | | 生成正式报告 | 完整读取 assets/report-template.md | 事实、映射和断言尚未审计完成时不要加载 |

不要在开始时一次性加载所有资源;到达表中阶段时必须完整读取对应文件,不要只读取开头或目录。

执行顺序

详细阶段产物、门禁和回退规则以 references/workflow.md 为准:

分析契约
  -> 能力拆解
  -> 对标对象映射
  -> 各平台独立取证
  -> 规格归一化
  -> 断言审计
  -> 差异与影响
  -> 分级建议
  -> 报告与质量门禁

报告模式

| 模式 | 适用场景 | 必需内容 | |---|---|---| | 快速扫描 | 方向判断 | Analysis Brief、Comparator Map、核心矩阵、关键风险、待核项、来源 | | 完整报告 | 设计评审、迁移方案、正式材料 | 全部阶段产物、最小用法、逐项断言、影响评估和 P0/P1/P2 建议 |

两种模式都不得省略版本基线、权威来源、作用域、事实/推论区分和待核标记。

即使用户要求极短答案,也使用快速扫描单表定义必要的 Analysis Brief、Comparator Map、Fact/Claim 和来源;不要直接返回 API 名称列表。

完成标准

  • Analysis Brief、Comparator Map、Fact Ledger 和 Claim Ledger 已完成。
  • 所有确定性结论都有官方来源,所有推论均明确标记。
  • “缺失、独有、优于”已完成双向检索。
  • 建议与差异证据一一关联。
  • 版本、作用域、来源、Fact/Claim 关联和待核事项已按本 Skill 的完成标准检查。