Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

ue5-commonui-menu-systems

Étoiles0

Forks0

Mis à jour13 avril 2026 à 20:48

Use when changing a major UE5 front-end menu, options flow, modal stack, routed input surface, or layered smartphone-first menu architecture. Applies to CommonUI adoption decisions, activatable-widget stacks, menu settings flows, and player-facing mobile front-end structure.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

strmt7

strmt7/project_air_defense

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	ue5-commonui-menu-systems
description	Use when changing a major UE5 front-end menu, options flow, modal stack, routed input surface, or layered smartphone-first menu architecture. Applies to CommonUI adoption decisions, activatable-widget stacks, menu settings flows, and player-facing mobile front-end structure.

UE5 CommonUI Menu Systems

Load first

AGENTS.md
docs/reference/ue5-mobile-agent-skill-sources.md
.agents/skills/ue5-mobile-ui/SKILL.md
docs/planning/ue5-gameplay-migration-matrix.md

Rules

Use CommonUI for large multi-screen menu stacks, routed modal flows, and settings navigation when plain UMG would otherwise create manual state spaghetti.
Keep plain UMG for compact in-battle HUD elements and project-specific overlays when CommonUI would add unnecessary runtime weight.
Treat the menu shell as a product surface, not a debug overlay. Title, actions, settings, and source/status information must be readable in landscape without burying the city view.
Keep menu copy short and action-first. Prefer one primary action, one secondary action, and compact status chips over multiple explanation paragraphs.
Keep buttons large, non-focusable by default for touch, and safe-zone aware.
If a settings surface exists, every visible option must map to real runtime behavior or persistence. No placeholder settings.
When adding a new menu layer, define the owning state transition first. Do not let widgets invent their own routing logic.
Screenshot-proof every front-end state that a player can actually reach.

Preferred stack

CommonUI activatable widgets for front-end stacks and routed settings menus.
Plain UMG for the in-battle HUD, radar, and compact drawers.
Enhanced Input or controller-owned state only for debug bindings and verification hooks, never as player-facing instructions.

Done means

the front-end menu is touch-first and landscape-first
action hierarchy is clear from one screenshot
settings flow is real, not decorative
menu routing does not fight gameplay state

Plus depuis ce dépôt

même dépôt

ue5-mobile-rendering

strmt7/project_air_defense

Use when changing UE5 smartphone rendering, graphics settings, anti-aliasing, ambient occlusion, reflections, post-process, device profiles, or mobile performance tiers. Applies when exposing graphics options to players or claiming that a visual feature works on-device.

2026-04-170

ue5-mobile-gameplay

strmt7/project_air_defense

Use when changing UE5 mobile gameplay flow, menu-to-battle state, touch input routing, hidden debug bindings, deterministic simulation ownership, or verification for a smartphone-first game. Applies to controller state, battle bootstrap, Enhanced Input, and automation-backed gameplay checks.

2026-04-130

ue5-mobile-ui

strmt7/project_air_defense

Use when changing any UE5 player-facing menu, HUD, pause surface, settings surface, touch control, or smartphone layout. Applies to UMG/CommonUI choice, safe zones, touch hit targets, information density, keyboard-hint suppression, and keeping the playfield visible on phones.

2026-04-130

verification-loop

strmt7/project_air_defense

State the narrowest correct verification lane and report exactly what passed.

2026-04-120

android-visual-qa

strmt7/project_air_defense

Use when validating Project Air Defense with screenshots, OCR, template matching, or live emulator navigation, especially when libGDX SurfaceView content is not visible in the Android accessibility tree.

2026-04-120

android-3d-air-defense

strmt7/project_air_defense

Use this skill when building, debugging, balancing, profiling, or visually upgrading the Project Air Defense Android 3D missile-defense prototype, especially for libGDX battle flow, mobile rendering quality, interception logic, HUD ergonomics, and emulator-verified Android fixes.

2026-04-110

name	ue5-commonui-menu-systems
description	Use when changing a major UE5 front-end menu, options flow, modal stack, routed input surface, or layered smartphone-first menu architecture. Applies to CommonUI adoption decisions, activatable-widget stacks, menu settings flows, and player-facing mobile front-end structure.

UE5 CommonUI Menu Systems

Load first

AGENTS.md
docs/reference/ue5-mobile-agent-skill-sources.md
.agents/skills/ue5-mobile-ui/SKILL.md
docs/planning/ue5-gameplay-migration-matrix.md

Rules

Use CommonUI for large multi-screen menu stacks, routed modal flows, and settings navigation when plain UMG would otherwise create manual state spaghetti.
Keep plain UMG for compact in-battle HUD elements and project-specific overlays when CommonUI would add unnecessary runtime weight.
Treat the menu shell as a product surface, not a debug overlay. Title, actions, settings, and source/status information must be readable in landscape without burying the city view.
Keep menu copy short and action-first. Prefer one primary action, one secondary action, and compact status chips over multiple explanation paragraphs.
Keep buttons large, non-focusable by default for touch, and safe-zone aware.
If a settings surface exists, every visible option must map to real runtime behavior or persistence. No placeholder settings.
When adding a new menu layer, define the owning state transition first. Do not let widgets invent their own routing logic.
Screenshot-proof every front-end state that a player can actually reach.

Preferred stack

CommonUI activatable widgets for front-end stacks and routed settings menus.
Plain UMG for the in-battle HUD, radar, and compact drawers.
Enhanced Input or controller-owned state only for debug bindings and verification hooks, never as player-facing instructions.

Done means

the front-end menu is touch-first and landscape-first
action hierarchy is clear from one screenshot
settings flow is real, not decorative
menu routing does not fight gameplay state