Run any Skill in Manus with one click

ue5-commonui-menu-systems

Stars0

Forks0

UpdatedApril 13, 2026 at 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

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

strmt7

strmt7/project_air_defense

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·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

More from this repository

same repository

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