メニュー
HarmonyOS应用多设备交互适配开发方案skill，提供触摸、鼠标、键盘、手写笔等多输入方式的交互方案和统一策略。当涉及触摸、鼠标、键盘、手写笔等设备的交互以及实现交互归一化、悬停效果、右键菜单、焦点导航、手写板输入和压感等功能时调用。
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/openharmonyinsight/openharmony-skills --skill hmos-multidevice-interaction-methodsコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
SOC 職業分類に基づく
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.
对 ArkUI 公共 UI API 与 Android（Compose/View）和 iOS（SwiftUI/UIKit）进行可审计的能力与规格竞品分析。 适用于接口设计评审、能力补齐、Android/iOS 与 ArkUI 迁移评估、API 对标和 capability gap analysis， 覆盖触摸/指针输入、键盘快捷键、手势、组件、布局、状态和动画。要求锁定作用域与版本，以 interface_sdk-js 为 ArkUI 公共接口权威源，优先引用 Android/iOS 官方文档，区分等价关系，并输出带逐项证据、影响和优先级建议的报告。
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.
SKILL.md を表示中
| name | hmos-multidevice-interaction-methods |
| description | HarmonyOS应用多设备交互适配开发方案skill，提供触摸、鼠标、键盘、手写笔等多输入方式的交互方案和统一策略。当涉及触摸、鼠标、键盘、手写笔等设备的交互以及实现交互归一化、悬停效果、右键菜单、焦点导航、手写板输入和压感等功能时调用。 |
HarmonyOS应用交互方式适配skill，为触摸、鼠标、键盘、手写笔等多输入方式提供交互方案和统一交互策略 适用设备(device types)： phone / tablet / 2in1 / tv 适用范围：交互归一化、鼠标悬浮、右键菜单、焦点导航、键盘快捷键、手写笔输入 不适用范围： 纯视觉动画微调、与输入方式无关的业务流程改造
| 标签 | 阶段 | 当前模块关注点 |
|---|---|---|
REQ | 需求分析设计 | 主输入方式、兼容输入方式、交互边界 |
DEV | 开发 | 事件接线、焦点链路、悬浮和快捷键实现 |
FIX | 问题修复 | 焦点断裂、鼠标无反馈、快捷键冲突、手写笔异常 |
VAL | 功能验证 | 输入矩阵、焦点路径、悬浮效果验证、快捷键验证 |
active_phases、primary_phase、primary_scene、secondary_scenes、resources_usedREQ：device_constraints、capability_boundary、acceptance_focusDEV：code_touchpoints、reuse_resources、implementation_notes、integration_risksFIX：problem_profile、root_cause_hypothesis、fix_plan、regression_watchlistVAL：verification_matrix、evidence_requirements、pass_criteria、residual_risksdevice_constraints：指由触摸、鼠标、键盘、手写笔或外接输入设备差异带来的交互硬约束。在 interaction-methods 中，通常是哪些输入方式必须支持、是否必须有 hover 或 focus、快捷键是否是必选能力。capability_boundary：指当前交互方案覆盖哪些输入方式，哪些输入路径可以降级，哪些行为只在特定设备上生效。acceptance_focus：指需求阶段验收时必须确认的焦点链路、悬浮反馈、快捷键行为和多输入回退策略。deliverables.REQ 出现 device_constraints，表示“该交互场景命中后，需求阶段必须先明确输入适配边界”，不是对字段重新命名。开始
│
├─→ 步骤1: 分析是否涉及鼠标交互(右键菜单，鼠标悬浮)
│ └─→ 涉及 → 命中 `INPUT-01` -> 步骤2
│ └─→ 不涉及 → 步骤3
│
├─→ 步骤2: 分析是否涉及交互归一化，即一套组件同时支持触摸和鼠标
│ └─→ 涉及 → 命中 `INPUT-02` -> 步骤3
│ └─→ 不涉及 → 步骤3
│
├─→ 步骤3: 分析是否涉及键盘交互（焦点导航、样式或键盘快捷键）
│ └─→ 涉及 → 命中 `INPUT-03` -> 步骤4
│ └─→ 不涉及 → 步骤4
│
└─→ 步骤4: 分析是否涉及手写笔交互（手写笔交互，压感）
└─→ 涉及 → 命中 `INPUT-04` -> 结束
└─→ 不涉及 → 结束
INPUT-01 鼠标设备交互（点击，悬浮，右键菜单）阶段： REQ, DEV, FIX
REQ阶段
DEV阶段
FIX阶段
INPUT-02 交互归一化阶段： REQ, DEV, FIX
REQ阶段
DEV阶段
FIX阶段
INPUT-03 键盘焦点导航与快捷键阶段： REQ, DEV, FIX
REQ阶段
DEV阶段
FIX阶段
INPUT-04 手写笔输入与笔态交互阶段： REQ, DEV, FIX
REQ阶段
DEV阶段
FIX阶段
REQactive_phases、primary_phase、primary_scene、secondary_scenesdevice_constraints、capability_boundary、acceptance_focusDEVcode_touchpoints、reuse_resources、implementation_notes、integration_risksFIXproblem_profile、root_cause_hypothesis、fix_plan、regression_watchlistVALverification_matrix、evidence_requirements、pass_criteria、residual_risksINPUT-04，还要进行手写笔验证