SuperAPI AI Directory
Partner中文AI newsFavorites
Skillshmos-multidevice-scenario-entry

hmos-multidevice-scenario-entry

General & other

View repository

Updated 10-16 03:11

About this skill

HarmonyOS multi-device adaptation general scenario entry

Skill definition

Field Content
skill_id harmonyos-multi-device-scenario-entry
skill_name 鸿蒙多设备适配总场景入口
one_line_purpose First determine which type of multi-device adaptation scenario the current problem belongs to, then route the request to the corresponding scenario file.
device_scope phone / tablet / foldable / tri-fold / pc / wearables / external input or device
problem_scope 多设备布局、折展状态、避让区、交互方式、自然方向、硬件能力差异
not_in_scope 分布式流转、账号体系、网络通信、纯业务功能设计、与多设备无关的常规 UI 微调
primary_outputs active_phases、primary_phase、primary_scene、secondary_scenes、route_reason、next_scene_refs

General entry constraints

  • This skill is only responsible for entry triage and does not directly expand scenario implementation details.
  • Determine the phase first, then determine the scenario type; do not skip phase identification and directly select a scenario.
  • When a request hits multiple scenarios at the same time, the primary scenario and secondary scenario must be output, rather than forcibly keeping only one.
  • Only when the root cause of the current problem clearly falls within a certain scenario is single-scenario handling allowed; otherwise, handle it as a composite scenario.
  • screen-window-size is a layout-type fallback scenario and should not swallow folding/expansion, avoidance, orientation, interaction, and hardware issues.
  • After entering a scenario file, the boundary definitions and constraints of that scenario file should be followed first; do not let the general entry override the scenario's proprietary rules.

Phase labels

Label Phase General entry focus
REQ Requirements analysis and design Problem boundary, device scope, main adaptation dimensions
DEV Development Which scenario the main code lands in, and whether multiple scenarios need to be combined
FIX Bug fixing Which adaptation domain the root cause belongs to, and whether there is an associated regression domain
VAL Function verification Which scenario the verification matrix should cover, and whether cross-verification is needed

Unified output fields

  • Entry fields:active_phases、primary_phase、primary_scene、secondary_scenes、route_reason、next_scene_refs
  • REQ：problem_frame、device_scope_summary、routing_focus
  • DEV：primary_code_domain、secondary_code_domains、integration_edges
  • FIX：suspected_root_domain、linked_regression_domains、handoff_priority
  • VAL：validation_domains、cross_checks、evidence_scope

Field definitions

  • primary_scene: The scenario that the current request should enter first.
  • secondary_scenes: The list of secondary scenarios linked with the primary scenario; only SCENE-xx format scenario ids are allowed, and skill paths are not filled in.
  • route_reason: Explains why the current primary scenario is hit instead of other scenarios.
  • next_scene_refs: The list of scenario file paths that should actually be opened in the next step.
  • primary_scene_ref: The primary scenario path directly pointed to by the current scenario card, used only inside the scenario card.
  • secondary_scene_refs: The common secondary scenario paths of the current scenario card, used only inside the scenario card.
  • scene_strategy: Whether the current scenario is single or composite。
  • candidate_scenes: When scene_strategy: composite , it can serve as the candidate SCENE-xx list for primary and secondary scenarios.
  • candidate_scene_refs: When scene_strategy: composite , the list of candidate scenario file paths that can be further expanded.
  • This general scenario entry does not output device_constraints；device_constraints belongs to the scenario file's REQ field, which is produced by the corresponding scenario when expanding the analysis.

AI retrieval requirements

  • First determine from the user's expression active_phases：
    • requirements, design, solution, selection, boundary, classified as REQ
    • development, implementation, how to write, code wiring, classified as DEV
    • fix, bug, exception, misalignment, crash, classified as FIX
    • verification, testing, acceptance, screenshot evidence, regression, classified as VAL
  • Then hit the primary scenario based on problem keywords; do not read all scenario files at once.
  • When a single scenario is hit, only open the corresponding scenario file.
  • When a composite scenario is hit, first determine primary_scene, then from secondary_scenes supplement 1-2 secondary scenarios, and summarize them into the final next_scene_refs。
  • If the problem only manifests as "inconsistent layout across multiple devices" without stronger characteristic terms appearing, default to first going through SCENE-01。
  • When it involves "layout not updated after rotation, window changes not synchronized" but does not involve natural orientation semantics,setPreferredOrientation or rotation value interpretation, still prioritize going through SCENE-01。
  • If the request contains explicit words about system region occlusion, creases, orientation semantics, input devices, or hardware capabilities, prioritize using the corresponding specialized scenario, and do not let layout keywords take over.

Scenario cluster index

SCENE-01 Layout and window size scenarios

scene_id: SCENE-01
scene_name: 布局与窗口尺寸场景
phase_tags: [REQ, DEV, FIX, VAL]
priority: P2
intent_signals:
  - 响应式
  - breakpoint
  - GridRow
  - GridCol
  - 多栏
  - windowSizeChange
  - media query
  - 窗口变化
  - 旋转后布局不同步
applies_when:
  - 主要问题是断点、结构切换或窗口尺寸变化
  - 问题可以不依赖折叠态、系统避让区、方向语义、输入设备或硬件能力来解释
not_applies_when:
  - 存在折痕、悬停态、Pura X、键盘遮挡、状态栏遮挡、自然方向语义、`setPreferredOrientation`、`rotation` 值解释、mouse、canIUse 等更强信号
scene_strategy: single
primary_scene_ref: ./references/hmos-multidevice-screen-window-size/SKILL.md
secondary_scenes:
  - SCENE-02
  - SCENE-03
secondary_scene_refs:
  - ./references/hmos-multidevice-fold-state/SKILL.md
  - ./references/hmos-multidevice-avoid-areas/SKILL.md

SCENE-02 Fold state and crease scenarios

scene_id: SCENE-02
scene_name: 折展状态与折痕场景
phase_tags: [REQ, DEV, FIX, VAL]
priority: P0
intent_signals:
  - foldStatus
  - 折叠
  - 展开
  - 悬停态
  - 折痕
  - tri-fold
  - G态
  - Pura X
applies_when:
  - 主要问题依赖设备折叠状态、折痕几何或宽折叠形态
  - 页面在手机和平板正常，但在折叠设备上出现结构或行为异常
not_applies_when:
  - 问题只与普通横竖屏变化或普通窗口断点有关
scene_strategy: single
primary_scene_ref: ./references/hmos-multidevice-fold-state/SKILL.md
secondary_scenes:
  - SCENE-01
  - SCENE-05
secondary_scene_refs:
  - ./references/hmos-multidevice-screen-window-size/SKILL.md
  - ./references/hmos-multidevice-natural-orientation/SKILL.md

SCENE-03 System region and keyboard avoidance scenarios

scene_id: SCENE-03
scene_name: 系统区域与键盘避让场景
phase_tags: [REQ, DEV, FIX, VAL]
priority: P0
intent_signals:
  - safe area
  - 状态栏
  - 导航栏
  - 挖孔
  - 刘海
  - 沉浸式
  - 键盘遮挡
  - 输入法
applies_when:
  - 主要问题是内容被系统区域、挖孔区或软键盘遮挡
  - 需要处理背景延伸和内容避让边界
not_applies_when:
  - 问题只是普通 margin 或栅格调整
scene_strategy: single
primary_scene_ref: ./references/hmos-multidevice-avoid-areas/SKILL.md
secondary_scenes:
  - SCENE-01
  - SCENE-02
secondary_scene_refs:
  - ./references/hmos-multidevice-screen-window-size/SKILL.md
  - ./references/hmos-multidevice-fold-state/SKILL.md

SCENE-04 Multi-input and focus interaction scenarios

scene_id: SCENE-04
scene_name: 多输入与焦点交互场景
phase_tags: [REQ, DEV, FIX, VAL]
priority: P1
intent_signals:
  - 鼠标
  - hover
  - 右键
  - 键盘焦点
  - shortcut
  - 手写笔
  - 拖拽
  - 外接键鼠
applies_when:
  - 主要问题是交互模型会随输入方式变化
  - 需要同时兼容触摸、鼠标、键盘或手写笔
not_applies_when:
  - 问题只表现为布局变化，没有交互行为变化
scene_strategy: single
primary_scene_ref: ./references/hmos-multidevice-interaction-methods/SKILL.md
secondary_scenes:
  - SCENE-01
secondary_scene_refs:
  - ./references/hmos-multidevice-screen-window-size/SKILL.md

SCENE-05 Natural orientation and rotation semantics scenarios

scene_id: SCENE-05
scene_name: 自然方向与旋转语义场景
phase_tags: [REQ, DEV, FIX, VAL]
priority: P1
intent_signals:
  - rotation 值
  - orientation
  - 自然竖屏
  - 自然横屏
  - setPreferredOrientation
  - 传感器方向
  - 横竖屏误判
applies_when:
  - 主要问题是方向语义、rotation 值或自然方向类型
  - 需要区分屏幕旋转、窗口方向和自然方向
not_applies_when:
  - 只是宽度断点变化或窗口尺寸同步导致的布局切换
scene_strategy: single
primary_scene_ref: ./references/hmos-multidevice-natural-orientation/SKILL.md
secondary_scenes:
  - SCENE-02
  - SCENE-01
secondary_scene_refs:
  - ./references/hmos-multidevice-fold-state/SKILL.md
  - ./references/hmos-multidevice-screen-window-size/SKILL.md

SCENE-06 Hardware capability and peripheral scenarios

scene_id: SCENE-06
scene_name: 硬件能力与外设场景
phase_tags: [REQ, DEV, FIX, VAL]
priority: P0
intent_signals:
  - canIUse
  - SysCap
  - 相机
  - camera
  - 传感器
  - GPS
  - NFC
  - 蓝牙
  - 外接设备
  - 热插拔
applies_when:
  - 主要问题是硬件能力存在设备差异，或调用前必须先检测能力
  - 行为异常与设备枚举、权限声明、连接切换或降级策略直接相关
not_applies_when:
  - 问题是纯 UI 布局、方向或避让，不涉及硬件能力差异
scene_strategy: single
primary_scene_ref: ./references/hmos-multidevice-hardware-access/SKILL.md
secondary_scenes:
  - SCENE-04
secondary_scene_refs:
  - ./references/hmos-multidevice-interaction-methods/SKILL.md

SCENE-07 Composite problem joint scenarios

scene_id: SCENE-07
scene_name: 复合问题联合场景
phase_tags: [REQ, DEV, FIX, VAL]
priority: P1
intent_signals:
  - 同时出现折叠、键盘、窗口、方向、输入或硬件中的多个信号
  - 需要解释主问题和连带问题
  - 单一场景不足以完整覆盖
applies_when:
  - 问题必须同时依赖两个以上场景才能解释
  - 需要先选主场景，再合并次场景
not_applies_when:
  - 单一场景已经足够解释问题
scene_strategy: composite
candidate_scenes:
  - SCENE-01
  - SCENE-02
  - SCENE-03
  - SCENE-04
  - SCENE-05
  - SCENE-06
candidate_scene_refs:
  - ./references/hmos-multidevice-screen-window-size/SKILL.md
  - ./references/hmos-multidevice-fold-state/SKILL.md
  - ./references/hmos-multidevice-avoid-areas/SKILL.md
  - ./references/hmos-multidevice-interaction-methods/SKILL.md
  - ./references/hmos-multidevice-natural-orientation/SKILL.md
  - ./references/hmos-multidevice-hardware-access/SKILL.md

Output conventions

  • First output the structured scenario determination, then enter the corresponding scenario file.
  • If multiple scenarios must be combined, prioritize outputting the combination strategy of SCENE-07 .
  • Do not mix scenarios and implementation together; the entry point is responsible for locating, and the scenario file is responsible for expanding.
  • The final output should keep fields as stable as possible; do not change field names due to expression habits.