ue5-umg
Skill22 starsChanged 7 months agoMITView on GitHub
Use when building HUDs, menus, inventory screens, settings panels, or any widget-based interface in Unreal Engine 5. Also use when connecting C++ logic to UMG Blueprint visuals, handling gamepad or keyboard focus navigation, managing UI state, creating widget animations, or troubleshooting UMG performance issues like frame drops, hitches, or widget memory leaks.
In this repository17 other files it gives its agents.
- code-analysisSkill
- code-generatorSkill
- contributingSkill
- daily-logSkill
- devflowSkill
- git-workflowSkill
- hexo-blog-updateSkill
- kimicode-vision-bridgeSkill
- knowledge-base-cacheSkill
- layered-first-principles-teachingSkill
- msvc-buildSkill
- mvp-designSkill
- paper-first-principlesSkill
- requirement-clarificationSkill
- research-to-practiceSkill
- taskmaster-skillSkill
- unity-mcpSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 1 is distinctive, and 6 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈1
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 80
Always use UCLASS(Abstract) on base classes meant for Blueprint subclassing
- Very specific: line 87
Use Collapsed visibility for hiding.
- Very specific: line 88
Use WidgetSwitcher for mutually exclusive pages, not Visibility toggling
- Distinctive: line 89
Never use Blueprint "Bind" properties — they run every frame
- Very specific: line 92
Use UListView / UTileView for scrollable lists with 10+ items
- Very specific: line 93
Avoid NativeTick for polling.
- Very specific: line 94
Call SetVisibility only when state actually changes
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
UE5 UMG Studio
Orchestrate C++ logic and Blueprint visuals for production UE5 user interfaces. Work in two layers: C++ for architecture and data binding, Blueprints for layout and polish.
Overview
Build production-ready Unreal Engine 5 user interfaces using a hybrid C++/Blueprint approach. C++ handles widget architecture, data binding, lifecycle, and performance; Blueprints handle layout, styling, animation, and visual state management.
When to Use
- Creating HUDs, menus, inventories, settings panels, or any widget-based interface
- Binding C++ properties to Blueprint widget components via
BindWidget - Handling gamepad or keyboard focus navigation and input modes
- Designing responsive UMG layouts, animations, and visual states
- Optimizing UI performance (widget pooling, ListView, Tick abuse, material overhead)
- Troubleshooting memory leaks from widget pools or dangling delegate references
When NOT to Use
- Editor tools, debug overlays, or custom Slate drawing — see
references/slate-fundamentals.md - Deep Common UI Plugin specifics — refer to official Epic documentation
- General gameplay programming unrelated to UI
Core Pattern: Hybrid C++/Blueprint Workflow
Without separation: Blueprint-only logic becomes spaghetti, C++-only UI is slow to iterate. With separation: C++ owns data, state, and lifecycle; Blueprints own layout, style, and animation.
// C++ Logic Layer: data binding and state
UCLASS(Abstract)
class UMyWidget : public UUserWidget
{
GENERATED_BODY()
protected:
UPROPERTY(meta = (BindWidget))
TObjectPtr<UProgressBar> HealthBar;
virtual void NativeConstruct() override;
virtual void NativeDestruct() override;
};void UMyWidget::NativeConstruct()
{
Super::NativeConstruct();
if (HealthBar)
{
HealthBar->SetPercent(1.0f);
}
}The Blueprint subclass of UMyWidget places a ProgressBar named HealthBar
in the Designer and styles it without any logic nodes.
Quick Reference
| Task | Reference File |
| C++ base class, BindWidget, pooling, ListView, input modes | references/umg-cpp-patterns.md |
| Layout containers, anchors, animation, styling, materials | references/blueprint-visuals.md |
| Common mistakes and how to fix them | references/common-pitfalls.md |
| Slate direct usage for editor tools | references/slate-fundamentals.md |
Key Rules
C++ Logic:
- Always use
UCLASS(Abstract)on base classes meant for Blueprint subclassing - BindWidget names must match Blueprint component names exactly (case-sensitive)
- Bind delegates in
NativeConstruct, unbind inNativeDestruct - Override
ReleaseSlateResourceswhen usingFUserWidgetPool
Blueprint Visuals:
- Design at your minimum supported resolution (e.g. 1280x720)
- Use
Collapsedvisibility for hiding;Hiddenonly to preserve layout space - Use
WidgetSwitcherfor mutually exclusive pages, not Visibility toggling - Never use Blueprint "Bind" properties — they run every frame
Performance:
- Use
UListView/UTileViewfor scrollable lists with 10+ items - Avoid
NativeTickfor polling; use delegates and events - Call
SetVisibilityonly when state actually changes
Quality Gates
UCLASS(Abstract)on base classes; BindWidget names match exactly- Delegates bound in
NativeConstruct, unbound inNativeDestruct - Input mode and focus set when showing or hiding UI
ReleaseSlateResourcesimplemented if using widget pools- ListView used for scrollable lists with 10+ items
- No Blueprint "Bind" properties used for dynamic values
- UI designed at minimum target resolution; anchors used for responsiveness
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

