hmos-multidevice-scenario-entry

Routes HarmonyOS multi-device adaptation requests to the correct scenario skill by phase and problem type.

2|Updated Jun 21, 2026
One-click install
npx skills add https://github.com/IsKenKenYa/skills --skill hmos-multidevice-scenario-entry-iskenkenya
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hmos-multidevice-scenario-entry
Source: https://github.com/IsKenKenYa/skills/tree/main/skills/harmonyos/solutions/HMOS-technologies/multi-device/hmos-multidevice-scenario-entry
Command: npx skills add https://github.com/IsKenKenYa/skills --skill hmos-multidevice-scenario-entry-iskenkenya

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) and references (resource) components.

What problem does it solve? HarmonyOS multi-device adaptation spans many distinct problem domains—responsive layouts, fold states, safe-area avoidance, input methods, orientation semantics, and hardware capabilities—and developers often don't know which specialized guidance applies to their issue. This Skill acts as the entry router: it classifies a request by development phase (REQ/DEV/FIX/VAL) and scenario type, then directs the agent to the correct scenario skill files instead of guessing at implementation details. ## Core Features & Use Cases - Phase and scenario classification: Maps user requests to active phases (requirement analysis, development, bug fixing, validation) and to one primary plus up to two secondary scenarios (SCENE-01 through SCENE-07). - Structured routing output: Produces stable fields such as primary_scene, secondary_scenes, route_reason, and next_scene_refs so downstream scenario skills can take over with clear handoff context. - On-demand remote skill loading: Uses scripts/remote_load.sh to download and cache whitelisted scenario skills from the Matrix registry when the target scenario file is missing locally. - Use Case: A developer reports that a foldable video detail page breaks in hover mode, the keyboard hides the comment input, and rotation desynchronizes the layout. The Skill routes this composite problem to the fold-state, avoid-areas, and screen-window-size scenario skills with a defined handoff order. ## Quick Start Ask the agent to classify your HarmonyOS multi-device adaptation problem, for example: "My foldable app's layout breaks in hover mode and the keyboard covers my input field—which adaptation scenarios should handle this?"

Frequently Asked Questions about hmos-multidevice-scenario-entry

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I route a HarmonyOS multi-device adaptation problem to the right scenario?

Describe your problem to the entry skill, which first classifies the phase (REQ, DEV, FIX, or VAL) and then matches intent signals to one primary scenario and up to two secondary scenarios. It outputs next_scene_refs pointing to the scenario SKILL.md files to read before any implementation.

What scenarios does HarmonyOS multi-device adaptation cover?

Seven scenarios are defined: screen/window size (SCENE-01), fold state and crease (SCENE-02), system areas and keyboard avoidance (SCENE-03), multi-input interaction (SCENE-04), natural orientation (SCENE-05), hardware capabilities (SCENE-06), and foldable multi-form validation (SCENE-07).

Does foldable device adaptation always route to the fold-state scenario?

No. Requests about extending layouts to foldable device types (dual-fold, tri-fold, tablet) route to SCENE-01 screen/window size. Only problems involving FoldStatus changes, hover mode, crease avoidance, or open-close continuity route to SCENE-02.

What happens if the routed scenario skill is not installed locally?

The entry skill invokes scripts/remote_load.sh, which downloads the whitelisted scenario skill from the Matrix registry, caches it under ~/.cache/ai-skill-cache, and exposes it via symlink or copy. Only six whitelisted scenario skills can be fetched.

Can the entry skill write ArkTS implementation code directly?

No. The entry skill only performs routing and is explicitly forbidden from skipping the reading of scenario files and reference documents before implementation. It outputs the routing decision and the list of documents read, then hands off to the scenario skills.