gamedev-skills/awesome-gamedev-agent-skills

# Master Router — Game-Development Skill Dispatcher

The entry point for game-development work. It fingerprints the project to pick **one** engine,
classifies the task from the request, names the **minimal** set of specialized skills, and tells
you to read them before acting. It **dispatches and composes** — it does not re-teach engine APIs.

## When to use

- Use at the **start of any game-development request** — building or debugging a game, level,
  player, enemy, shader, UI, save system, multiplayer, input, audio, AI, dialogue, procedural
  content, or visual asset set — to decide which skill(s) to load.
- Use when the user names an engine or genre, says "make a game", or asks "which skill should I
  use?".

# Behavior Trees & Utility AI

Two complementary ways to structure NPC decision-making, plus how to combine them. A
**behavior tree (BT)** expresses *structured, prioritized, reactive* logic as a tree that is
"ticked" each step. **Utility AI** answers *"how much do I want each option right now?"* by
scoring actions with normalized curves and picking the best. Ship believable agents by using a
BT for structure and Utility AI where graded trade-offs matter.

This skill is the **implementation** companion to `game-ai` (which helps you *choose* between
FSM / BT / steering / pathfinding). Read `game-ai` to pick a model; read this to build the
runtime.

## When to use

# Audio design

Game audio is a **mixing graph plus a music system**. Route every sound through a
small set of buses so you can balance and process groups; make music *react* to
play through layering and re-sequencing rather than looping one track. This skill
teaches the portable practice; bind it to `godot-audio`, Unity's AudioMixer, or
middleware (FMOD/Wwise) for concrete APIs.

## When to use

- Use to design a bus/mixer layout, set group volumes, and apply effects (reverb,
  compression, EQ) to groups of sounds.
- Use to duck music/ambience under dialogue or impacts (sidechain).
- Use to build adaptive music that responds to combat/exploration intensity.

# Camera systems

The camera is the player's window; bad camera work makes a good game feel awful. This skill
covers the engine-neutral camera techniques — smooth follow, deadzones, look-ahead, bounds
clamping, third-person orbit with collision, first-person look, and multi-target framing — and
maps them onto each engine's camera node or rig.

## When to use

- Use when a 2D camera should follow the player smoothly, stay inside the level, lead the
  player's motion, or ignore small movements (deadzone).
- Use when building a 3D third-person orbit camera (mouse/stick look, collision push-in) or a
  first-person look controller, or framing multiple targets at once.
- Use to fix camera jitter, snapping, motion sickness, or a camera that shows past the level edge.

# Create Game Assets

Turn a game's visual intent into a consistent, engine-ready asset set. Treat image generation as
one production tool inside a controlled pipeline, never as proof that an asset is shippable.

## Core workflow

1. **Inspect before inventing.** Find existing screenshots, concept art, sprites, models, fonts,
   import settings, camera framing, target resolution, and naming conventions. Preserve a coherent
   existing direction unless the user asks for a redesign.
2. **Lock the technical frame.** Record engine, 2D/3D, camera/view, native display size, asset
   dimensions, world scale, transparency, palette, filtering, animation frames, texture budget,
   and target platforms. Use `assets/art-direction-brief.md` as a copyable brief.
3. **Name the visual system.** Define shape language, silhouette priorities, value structure,

# Dialogue systems

Model conversations as a **graph**: nodes hold lines, choices branch the flow,
conditions gate options, and variables remember what the player did. The first
real decision is *build vs. buy* — adopt a proven authoring tool (**Ink** or
**Yarn Spinner**) or write a small data-driven runner. This skill owns both Ink
and Yarn; the `visual-novel` and `rpg` genres consume it.

## When to use

- Use to design branching conversations, choice menus, or narrative state
  (flags, relationship values) that affect later dialogue.
- Use to decide between Ink, Yarn Spinner, and a custom JSON/resource format.
- Use to wire a dialogue script into your game loop (advance line, present

# Game AI: decisions, steering, and pathfinding

Build believable NPC behavior from three separable layers: **decide** (what to
do), **steer** (how to move there), and **path** (how to route around the map).
Keep them decoupled — a behavior tree picks a target, the pathfinder produces
waypoints, steering follows them. This skill teaches the engine-neutral
algorithms; bind them to your engine via the related skills below.

## When to use

- Use when implementing enemy/NPC logic: patrols, chase/flee, guard states,
  group movement, or "find a path to the player".
- Use to choose between an **FSM** (few clear states), a **behavior tree** (many
  reactive behaviors with priorities), or **steering** (smooth local movement).

# Game feel (juice)

The difference between a mechanic that *works* and one that feels *good* is feedback: the
layered, slightly-exaggerated response an action provokes. This skill covers the engine-
neutral techniques — screen shake, hit-stop, easing, squash & stretch, knockback, and stacked
feedback — and tells you how to apply them without burying the underlying simulation. It
**adds polish on top of** an existing mechanic; it does not implement the mechanic.

## When to use

- Use when an action (hit, jump, dash, pickup, death, button press) is mechanically correct
  but feels weak, weightless, or unsatisfying, and you want it to feel responsive and punchy.
- Use to add screen shake, hit-stop/freeze frames, eased motion, squash & stretch, knockback,
  flashes, or to layer multiple feedback channels onto one event.

# Game UI/UX

Build HUDs and menus that stay correct on a phone, an ultrawide monitor, and a TV across a
gamepad and a mouse. This skill owns the engine-neutral UI architecture — responsive layout,
scaling, focus navigation, screen flow, and how UI talks to game state — and defers the
concrete widget API to the engine UI skill.

## When to use

- Use when building a HUD (health/ammo/score), a menu (main/pause/settings), an inventory or
  shop screen, or any overlay, and you want it to scale and navigate correctly.
- Use to fix UI that breaks at other resolutions/aspect ratios, ignores notches/safe areas,
  can't be used with a controller, or is wired to game state by per-frame polling.
- Use to structure screen flow (title → game → pause → settings) as a stack, not flag soup.

# Input systems

Never wire gameplay to raw keys. Map physical inputs (a key, a button, a touch)
to named **actions** (`jump`, `interact`, `move`), and let gameplay read actions.
That one indirection gives you rebinding, multi-device support, and accessibility
almost for free. This skill is the engine-neutral architecture; bind it to
`unity-input-system`, `unreal-enhanced-input`, or Godot's `InputMap`.

## When to use

- Use to design an input layer: actions, bindings, multiple devices, and a
  rebinding UI with conflict detection and saved bindings.
- Use to add analog handling (deadzones, sensitivity) and game-feel features
  (input buffering, coyote time).

# Level design

A level is a **sequence of intentional experiences** delivered through space.
Good level design is a *process*: define the metrics movement is built on, block
out geometry with primitives, play it, then dress it — never the reverse. This
skill is the engine-neutral practice; use `godot-tilemap`/`unity-tilemap-2d` to
lay out 2D grids and gridmaps for 3D.

## When to use

- Use to plan a level's structure: critical path, pacing, gating, encounters,
  and where the player learns vs is tested.
- Use the **blockout → test → iterate → dress** workflow to build a level that
  plays well before any art exists.

# Performance optimization

Performance work is a measurement discipline, not a bag of tricks. The method is always the
same: **profile → find the one bottleneck → fix that → measure again**. This skill teaches that
loop and the highest-leverage fixes (pooling, batching, allocation control, asset budgets), and
points you at each engine's profiler. It pairs with `physics-tuning` for simulation cost.

## When to use

- Use when the frame rate is low or uneven, the game stutters/hitches, or it must hit a target
  (60 FPS desktop, 30/60 mobile) and currently doesn't.
- Use to decide *what* to optimize: profile, read the frame budget, and identify whether the CPU
  or GPU is the bottleneck before changing any code.
- Use to apply specific fixes: object pooling, draw-call/batch reduction, removing per-frame

# Physics tuning

Most "bad physics" is not a bug in the engine — it's a mismatch between the
**fixed-timestep simulation** and the **variable-rate render loop**, or untuned
mass/drag/CCD/layer settings. This skill covers the engine-neutral knobs that
make physics stable and responsive; pair it with `godot-physics` or
`unity-physics` for the concrete APIs.

## When to use

- Use when motion jitters, objects pass through walls (tunneling), stacks
  explode, or movement feels floaty/sticky/laggy.
- Use to decide what goes in the fixed (physics) step vs the render frame, and
  how to interpolate between them.

# Procedural generation

Generate levels, terrain, and loot from compact rules and a seed. The throughline
of good procgen is **determinism**: a single seed reproduces the same world, so
bugs are repeatable and players can share seeds. This skill owns the core
algorithms — noise, seeded RNG, dungeon layout, weighted tables; genres like
`roguelike` and `survival-crafting` consume it.

## When to use

- Use to generate maps, dungeons, terrain heightmaps, item drops, or any content
  you do not want to author by hand.
- Use when results must be **reproducible from a seed** (debugging, daily
  challenges, shareable worlds).

# Save systems

A save file is a **serialized snapshot of game state** that survives restarts.
The hard parts aren't writing bytes — they're choosing *what* to save, writing it
so a crash mid-save can't corrupt it, and reading *old* saves after you ship a
patch. Get those three right and the rest is plumbing.

## When to use

- Use to persist progress: player stats, inventory, world flags, settings,
  positions — across sessions and game updates.
- Use to design save slots, quicksave/autosave, and crash-safe writes.
- Use when old save files break after a content/code change (versioning &
  migration).

# Shader programming (cross-engine)

Shaders are small programs that run **per vertex** and **per pixel** on the GPU.
The concepts — the pipeline, coordinate spaces, UVs, and how common effects are
built — port across engines; only the language dialect and built-in variable
names change. This skill teaches those portable fundamentals in GLSL with HLSL
equivalents; use `godot-shaders` (or Unity/Unreal material docs) for the exact
engine syntax and built-ins.

## When to use

- Use to understand or write vertex/fragment shaders and to reason about UVs,
  coordinate spaces, and the GPU pipeline.
- Use to build common effects: tint/recolor, scrolling textures, dissolve,

# Ebitengine game

Deliver a game that is understandable, responsive and complete at the requested
scope. One request can include several internal build/play/refine passes. A
scaffold, successful build or attractive screenshot alone is not a finished game.
For a focused fix, preserve the project's design and limit the workflow to the
affected behavior.

The bundled starter targets **Ebitengine v2.10.5 / Go 1.25+**. This is a pinned
baseline, not a claim about the latest release. Keep an existing project's
versions unless an upgrade is needed and authorized. Check the pinned version's
public API before using newer or experimental APIs. References contain patterns
to adapt; only the bundled scripts and starter are executable deliverables.
Their checks do not validate every reference snippet.

# Card Game

A playbook for card games — card data, the deck/hand/discard zones, the turn structure, and
how card effects resolve. This is a **compositional** skill: it models cards as data and wires
them to UI. It does not re-teach data assets or UI nodes; it defines the zone model, the draw
machinery, and the effect-resolution rules that keep a card game correct and bug-free.

## When to use

- Use when building any game where the core objects are **cards** moving between zones
  (deck → hand → play → discard): deckbuilder, TCG/CCG, solitaire, roguelike deckbuilder.
- Use when designing draw/shuffle/reshuffle, turn structure, card costs, or how effects resolve.

**When *not* to use:** board/tile state with matching rules → `puzzle`. RPG with an

# FPS Shooter

A playbook for first-person shooters — the look/move controller, the shooting model, weapon
feel, and combat. This is a **compositional** skill: it wires a 3D controller, input, and AI
into a shooter. It does not re-teach 3D nodes or raycasts; it defines the shooting model and
the feel knobs (TTK, recoil, spread) that decide whether the guns feel good.

## When to use

- Use when building a first-person game whose core verb is **aim and shoot** — arena shooter,
  tactical FPS, PvE shooter, boomer-shooter.
- Use when deciding hitscan vs. projectile, tuning time-to-kill, recoil, spread, or aim feel.

**When *not* to use:** third-person/2D shooting → reuse the shooting model here but build the

# Platformer

A playbook for 2D platformers — the run/jump controller "feel", level structure, hazards,
and goals. This is a **compositional** skill: it wires an engine movement skill, a tilemap
skill, and design skills into a working game. It does **not** re-teach physics or tilemaps;
it tells you what to build and how to make jumping feel good.

## When to use

- Use when building a side-scrolling or single-screen platformer, a "Mario-like" /
  "Celeste-like", or any game whose core verb is **jump between surfaces**.
- Use when a jump feels floaty, unresponsive, or "unfair" and you need feel fixes
  (coyote time, jump buffering, variable height, corner correction).

# Puzzle

A playbook for grid/board puzzle games — the board model, move input, rule resolution
(matching, pushing, logic), scoring, undo, and level progression. This is a **compositional**
skill: it models board state and rules and presents them through a tilemap/UI. It does not
re-teach tilemaps; it defines the resolution loop and the correctness rules (clean state,
deterministic resolution, undo) that keep a puzzle fair and bug-free.

## When to use

- Use when the game is a **discrete board** the player changes with moves, and the board
  **resolves by rules**: match-3/tile-matching, sokoban/block-pusher, sliding puzzle, logic grid.
- Use when designing match/cascade resolution, undo, level progression, or solvability.

# Roguelike

A playbook for roguelikes — the turn engine, procedural dungeons, field-of-view, permadeath,
and run economy. This is a **compositional** skill: it orchestrates procedural generation,
tilemaps, save handling, and AI into a run-based game. It does not re-teach noise/RNG or
tilemap APIs; it defines the loop and the systems that make a *run* compelling.

## When to use

- Use when building a **turn-based, grid-based** dungeon crawler where each death ends the
  run and the world is regenerated — a roguelike or "roguelite" (with meta-progression).
- Use when designing procedural dungeons, FOV/fog-of-war, permadeath stakes, or loot tables.

**When *not* to use:** real-time action with roguelike *dressing* → build the action genre

# RPG

A playbook for role-playing games — stats and progression, inventory/equipment, quests,
dialogue, and combat. This is a **compositional** skill: it ties data-driven content,
dialogue, and saving together. It does not re-teach those primitives; it defines the systems
that make growth and choice feel meaningful, and points to the skills that implement each.

These systems also apply to custom/proprietary engines. Keep the project's engine and bind
the concepts below to its documented data, events, UI, and save interfaces. Inspect local
source/SDK examples before choosing APIs; the router's custom-engine fallback guides that
mapping. Godot/Unity bindings below are examples, not prerequisites.

## When to use

# Survival Crafting

A playbook for survival-crafting games — the gather → craft → build loop, survival needs, the
crafting/tech progression, and base building. This is a **compositional** skill: it orchestrates
inventory data, world content, persistence, and threats. It does not re-teach those primitives;
it defines the loop and the pressure systems (needs, scarcity, escalation) that make survival
tense rather than tedious.

## When to use

- Use when the player **gathers resources, crafts items/structures, manages survival needs, and
  builds a base** against escalating threats: survival sandbox, crafting/base-building game.
- Use when designing needs (hunger/thirst/temperature), a crafting tech tree, gathering loops,
  or base placement/building.

# Tower Defense

A playbook for tower defense — enemy pathing, wave spawning, tower targeting, and the
economy that ties them together. This is a **compositional** skill: it orchestrates pathing,
AI, and UI into a TD loop. It does not re-teach pathfinding; it defines the systems and the
balance levers (DPS vs. HP vs. income) that decide whether a TD is tense or trivial.

## When to use

- Use when building a game where the player **places towers** that automatically attack
  **waves of enemies** following a path, spends earned currency to expand/upgrade, and loses
  if too many enemies leak through.
- Use when designing wave composition/pacing, tower targeting priorities, or the gold economy.

# Visual Novel

A playbook for visual novels — the branching script, the presentation (text box, characters,
backgrounds), choices, and the quality-of-life systems players expect (save anywhere, backlog,
skip, auto). This is a **compositional** skill: it drives a dialogue engine and a UI layer. It
does not re-teach the dialogue engine or UI nodes; it defines the script model and the player
conveniences that make a VN pleasant to read.

## When to use

- Use when the game is **mostly reading branching text** with character art and backgrounds:
  visual novel, dating sim, branching interactive fiction, story-choice game.
- Use when designing a choice/route structure, story flags, or VN conveniences (backlog,
  skip, auto-advance, save-anywhere).

# Godot 2D Movement (4.x)

Build responsive 2D character controllers with `CharacterBody2D` and the argument-less
`move_and_slide()`. Targets **Godot 4.7**.

## When to use

- Use when scripting a 2D player/enemy that moves and collides: platformer (gravity +
  jump) or top-down (free 8-direction), slope walking, or wall/floor detection.
- Use when `move_and_slide()` "does nothing", the character sinks through floors, or
  `is_on_floor()` is always false.

**When *not* to use:** dynamic rigid bodies, areas, raycasts, collision layers →
`godot-physics`; tile-based levels → `godot-tilemap`; full platformer game template →

# Godot 3D Essentials (4.x)

Assemble a working 3D scene: transforms, camera, lights, environment/post, materials, and
`GridMap` blockouts. Targets **Godot 4.7**.

## When to use

- Use when starting or fixing a 3D scene: positioning a `Camera3D`, adding lights, setting
  up a `WorldEnvironment` (sky, ambient, tonemap, glow/SSAO), assigning materials, or
  building levels with `GridMap`.

**When *not* to use:** writing spatial shaders → `godot-shaders`; 3D physics bodies and
raycasts → `godot-physics`; character animation blending → `godot-animation`; full FPS
template → the `fps-shooter` genre skill.

# Godot Animation (4.x)

Choose and drive the right animation tool: `AnimationPlayer` (clips), `AnimationTree`
(blending/state machines), or `Tween` (short procedural moves). Targets **Godot 4.7**.

## When to use

- Use when playing keyframed animations, blending walk/run/idle states, animating a
  sprite sheet, or tweening UI/objects in code.

**When *not* to use:** the movement *logic* that decides which state to play →
`godot-2d-movement`; UI layout (vs. UI tweening) → `godot-ui-control`; shader-driven
effects → `godot-shaders`.

# Godot Audio (4.x)

Play SFX and music, route them through buses, control volume in decibels, and time
gameplay to the beat. Targets **Godot 4.7**.

## When to use

- Use when playing sound effects or music, routing audio to buses (Master/Music/SFX),
  adjusting volume/mute from code, adding bus effects (reverb, compressor), positional 3D
  audio, or syncing events to music.

**When *not* to use:** engine-agnostic audio *design* (adaptive music structure, mixing
philosophy, ducking patterns) → `audio-design`; importing/encoding assets outside Godot.

# Godot C# / .NET (4.x)

Write Godot game code in C#: node subclasses, the engine lifecycle, exports, signals as
events, and GDScript interop. Targets **Godot 4.7 (.NET / C#)** and **.NET 8**.

## When to use

- Use when scripting a Godot game in C# (`.cs` + `.csproj`), translating GDScript idioms
  to C#, exposing `[Export]` fields, or wiring `[Signal]` delegates and GetNode<T>.

**When *not* to use:** GDScript-specific syntax → `godot-gdscript`; engine concepts that
are language-neutral (scenes, physics, animation) → the relevant `godot-*` skill. You need
the **Godot .NET build** + the .NET SDK installed; the standard build can't run C#.

# Godot Export & Builds (4.x)

Turn a project into runnable platform builds via export presets and the command line, and
handle the web/dedicated-server gotchas. Targets **Godot 4.7**.

## When to use

- Use when producing a shippable build: installing export templates, creating/editing
  export presets, exporting from the editor or headless CLI (CI), or troubleshooting web
  (HTML5) and dedicated-server exports.

**When *not* to use:** storefront publishing flows → `steam-publish`/`itch-publish`; the
networking code of a server → `godot-multiplayer` (this skill covers building it headless).

# Godot GDScript (4.x)

Write correct, statically typed GDScript and use the node lifecycle and signal
system the way the engine intends. Targets **Godot 4.7** (GDScript 2.0).

## When to use

- Use when writing or fixing `.gd` files: declaring variables, functions, classes,
  using `@export`/`@onready`, connecting signals, or awaiting coroutines/signals.
- Use when porting Godot 3.x scripts to 4.x and the script no longer parses.

**When *not* to use:** scene/node structure and instancing questions →
`godot-nodes-scenes`; signal *architecture*/decoupling patterns →
`godot-signals-groups`; using C# instead of GDScript → `godot-csharp`.

# Godot GDScript headless testing (4.x)

Run GDScript tests from the command line, without the editor GUI, and get a real
process exit code CI can act on. Targets **Godot 4.7** headless CLI.

## When to use

- Use when a Godot project has no testing addon installed and needs a fast way to
  verify GDScript logic (pure functions, resource loading, autoload state) from a
  terminal or CI pipeline.
- Use when wiring a CI job that must fail the build when a `.gd` test fails.
- Use when debugging why a `godot --headless` invocation hangs, opens a window, or
  exits 0 despite failing assertions.

# Godot Multiplayer (4.x high-level)

Connect peers, call functions remotely with `@rpc`, assign authority, and replicate state
with `MultiplayerSpawner`/`MultiplayerSynchronizer`. Targets **Godot 4.7** (ENet). Treat
all client input as untrusted; keep the server authoritative.

## When to use

- Use when adding networked multiplayer: hosting/joining over ENet, calling RPCs,
  assigning per-node authority, or auto-spawning/syncing nodes across peers.

**When *not* to use:** local split-screen (no networking); raw TCP/UDP/WebSocket protocol
work (low-level `PacketPeer`); HTTP requests. For save/persistence → `save-systems`.

# Godot Nodes & Scenes (4.x)

Compose games from nodes and scenes, instance them at runtime, and access the tree
without crashing on freed or missing nodes. Targets **Godot 4.7**.

## When to use

- Use when structuring `.tscn` scenes, choosing how to break a feature into nodes,
  instancing a `PackedScene` (bullets, enemies, UI), or setting up autoload singletons.
- Use when debugging `get_node()` / `$Path` returning `null`, or "Attempt to call on a
  previously freed instance".

**When _not_ to use:** GDScript language/syntax → `godot-gdscript`; signal-based
decoupling → `godot-signals-groups`; physics bodies/collisions → `godot-physics`.

# Godot Physics (4.x, 2D + 3D)

Pick the right physics body, wire up collision layers/masks, detect overlaps, and cast
rays. Concepts apply to both 2D and 3D (swap the `2D`/`3D` suffix). Targets
**Godot 4.7**. In 3D, projects created with Godot 4.6 or later run **Jolt Physics** by
default; older projects keep **GodotPhysics3D** unless someone switched them. 2D always
uses Godot's own 2D engine.

## When to use

- Use when choosing between body types, setting collision layers/masks so the right
  things collide, detecting overlaps (triggers, hurtboxes) with `Area`, applying
  forces/impulses to a `RigidBody`, or casting rays for line-of-sight/ground checks.

# Godot Resources (4.x)

Model game data as reusable, Inspector-editable `Resource` objects instead of hard-coded
values, and load/save them as `.tres`/`.res`. Targets **Godot 4.7**.

## When to use

- Use when representing items, stats, enemy configs, dialogue lines, or level metadata as
  data; authoring `.tres` files in the Inspector; or loading/saving custom resources.

**When *not* to use:** nodes/scene structure → `godot-nodes-scenes`; saving the player's
*runtime progress* (engine-agnostic save format/slots) → `save-systems`; the C# variant of
this pattern → `godot-csharp`.

# Godot Shaders (4.x)

Write `canvas_item` (2D) and `spatial` (3D) shaders in the Godot Shading Language, animate
with `TIME`/`UV`, expose `uniform`s, and read the screen. Targets **Godot 4.7**.

## When to use

- Use when writing `.gdshader` code or a `ShaderMaterial`: 2D effects (outline, dissolve,
  flash, water), 3D surface shaders (rim light, toon, scrolling UV), or screen-space
  post effects.

**When *not* to use:** the cross-engine *concepts* of shading (UVs, vertex/fragment
theory) → `shader-programming`; particles/VFX nodes → general 3D; non-shader visuals.

# Godot Signals & Groups (4.x)

Decouple nodes with the observer pattern (signals) and act on many nodes at once
(groups), instead of hard-coding references between scenes. Targets **Godot 4.7**.

## When to use

- Use when a node needs to tell others "something happened" (player died, item picked
  up, wave cleared) without holding direct references to them.
- Use when you need to address a whole category of nodes at once ("pause all enemies",
  "save every checkpoint").

**When *not* to use:** raw signal *syntax* basics → `godot-gdscript`; scene structure
and instancing → `godot-nodes-scenes`. For cross-scene global events, emit from an

# Godot TileMap (4.7 TileMapLayer)

Author tile-based levels with `TileMapLayer` + `TileSet`, add per-tile collision and
custom data, autotile with terrains, and manipulate cells at runtime. Targets
**Godot 4.7**, where `TileMapLayer` replaces the now-deprecated `TileMap` node.

## When to use

- Use when designing 2D levels from a tile grid, configuring a `TileSet` (collision,
  navigation, custom data, terrains), or reading/writing tiles from code.
- Use when migrating a `TileMap` node (single node, many layers) to multiple
  `TileMapLayer` nodes (one layer each).

**When *not* to use:** moving the player across the tiles → `godot-2d-movement`; general

# Godot UI / Control nodes (4.x)

Lay out responsive UI with `Control` anchors and `Container` nodes, style it with a
`Theme`, and make it navigable by keyboard and gamepad. Targets **Godot 4.7**.

## When to use

- Use when building HUDs, menus, inventories, dialog boxes, or settings screens with
  `Control`-derived nodes; arranging UI that adapts to window size; theming; or wiring
  focus navigation for controller/keyboard.

**When *not* to use:** in-world 2D nodes (`Node2D`/sprites) → `godot-nodes-scenes`;
animating UI transitions → `godot-animation` (Tween); genre UIs like card hands →
`card-game`/`visual-novel`. For full input rebinding → `input-systems`.

# Bevy ECS

Structure a Bevy game in Rust around the Entity Component System: the `App` and
plugins, components and resources, systems with queries, scheduling, and
frame-rate-independent updates. New examples target **Bevy 0.20**. If the project
already pins another release, keep that release and use its matching migration guide.

## When to use

- Use when wiring a Bevy `App`, defining `Component`/`Resource` types, writing
  systems that query entities, ordering/filtering systems, or fixing
  borrow-conflict panics and frame-dependent movement.
- Use when `Cargo.toml` depends on `bevy` and code calls `App::new()`,
  `add_systems`, `Query`, or `Commands`.

# Defold Core

Structure, wire and verify a Defold game: editor resource files, the Lua script lifecycle,
addressing and messages, runtime spawning and world loading, and a Bob build-and-run check.
Examples target **Defold 1.14.0**; they were built with Bob 1.14.0 and run on the 1.14.0
headless engine. An existing project keeps its Defold version (see [Version](#version)).

## When to use

- Use when adding or fixing game objects, collections, scripts, input, messages, spawning or
  level loading in a Defold project (`game.project` in the root, `.collection`, `.go`,
  `.script`, `.gui_script` files), or when Bob reports a missing resource.

**When *not* to use:** plain Lua or LÖVE projects (`love2d-core`); GUI layout, sprites,

# LÖVE (Love2D) Core

Set up and debug the foundation of a LÖVE game in Lua: the callback loop, frame-rate-
independent movement, input, and screen states. Targets **LÖVE 11.5**.

## When to use

- Use when starting a LÖVE game, wiring up `main.lua`/`conf.lua`, or fixing the core loop,
  movement that runs at the wrong speed, input handling, or screen switching.
- Use when the workspace has `main.lua` calling `love.*`, a `conf.lua`, or a `.love` file.

**When *not* to use:** Lua *language* questions unrelated to LÖVE; physics bodies/joints
(LÖVE uses Box2D via `love.physics` — a separate concern); shader code (`love.graphics`
GLSL is its own topic). For cross-engine save/load patterns, use `save-systems`.

# pygame Core

Build the foundation of a pygame game in Python: the main loop, delta-time
movement, drawing with `Surface`/`Rect`, input, and `Sprite`/`Group` management.
Targets **pygame-ce 2.5.8** (the actively maintained community fork; same
`import pygame`), which supports Python 3.10–3.15.

## When to use

- Use when starting a pygame game, fixing the loop, frame-rate-dependent speed,
  input handling, blitting, or sprite/group collision.
- Use when code does `import pygame` and the project depends on `pygame-ce`
  (or `pygame`).

# Roblox characters

Treat a `Player` as the durable identity and each `Character` as a replaceable session with its own
references, connections, animation tracks, and cleanup. Targets Roblox's rolling platform APIs.

## When to use

- Use for player-character lifecycle, Humanoid state/movement, rigs, animations, tools,
  accessories, custom characters, death, or respawn defects.
- Use whenever code stores a Character/Humanoid/root reference longer than one spawn.

**When not to use:** general physics queries and constraints belong to `roblox-physics`; remote
trust belongs to `roblox-networking`; camera logic belongs to `camera-systems`.

# Roblox DataStores

Persist data across sessions in Roblox with `DataStoreService`: loading on join,
saving on leave and shutdown, safe updates, retries, and ordered stores for
leaderboards. Server-side only.

## When to use

- Use to save/load player progress (coins, inventory, levels), build persistent
  leaderboards, or fix data loss, overwrites, and throttling.
- Use when server code calls `DataStoreService`, `GetDataStore`, `GetAsync`,
  `SetAsync`, `UpdateAsync`, or `GetOrderedDataStore`.

**When *not* to use:** general scripting, services, remotes, the client/server

# Roblox Luau Scripting

Script a Roblox experience in **Luau**: services, `Instance`s, events, the
server/client split, and secure cross-boundary communication. Targets the current
Roblox engine and Studio.

## When to use

- Use when writing Roblox scripts: getting services, creating/parenting instances,
  connecting events, deciding server vs client, or wiring `RemoteEvent`/
  `RemoteFunction` communication.
- Use when the project has `Script`/`LocalScript`/`ModuleScript` objects, `.rbxl(x)`
  places, or a Rojo `*.project.json`, and code calls `game:GetService(...)`.

# Roblox networking

Build explicit request and replication contracts in which the server decides authoritative game
state and clients provide input or intent. Targets Roblox's rolling platform APIs. This skill goes
deeper than the networking primer in `roblox-luau`.

## When to use

- Use to design, implement, debug, or secure cross-boundary Roblox communication.
- Use when a remote trusts client values, an exploiter can target arbitrary Instances, messages
  spam services, streamed objects are missing, or clients disagree with the server.

**When not to use:** basic Luau/services belong to `roblox-luau`; persistent state belongs to
`roblox-datastores`; physical ownership mechanics also compose with `roblox-physics`.

# Roblox physics

Choose deliberately between simulation, character control, hit detection, and visual-only motion;
they are different jobs. Targets Roblox's rolling platform APIs. Pair with `physics-tuning` for
engine-neutral stability and feel.

## When to use

- Use for BasePart assemblies, constraints, collision/query policy, ray/overlap queries, forces,
  impulses, moving physical objects, network ownership, or physics cleanup.
- Use when `Touched` is unreliable/security-sensitive, parts tunnel or jitter, a mechanism breaks
  when anchored, or old BodyMover patterns appear.

**When not to use:** ordinary Humanoid lifecycle/control belongs to `roblox-characters`; remote

# Roblox simulator economy

Choose the economy's numbers with a pacing table before writing gameplay code, then implement them
so the server owns every amount. Code targets Luau on Roblox's rolling platform APIs; the bundled
scripts are pure Luau and were run with **Lune 0.11.0**, outside Studio.

## When to use

- Picking or reviewing `baseCost`, `costGrowth`, rebirth requirement and multiplier, or offline
  cap and efficiency values for a simulator, tycoon, clicker, or idle game.
- Writing upgrade, buy-max, currency, rebirth, or offline-earnings code in Luau.
- Displaying large numbers, or values above about `1e15` that lose precision.
- Adding eggs, crates, or spins bought with Robux, or with currency that can be bought with Robux.

# Roblox Studio workflow

Work as a collaborator inside an existing place, not as if it were a blank text repository. Targets
current Roblox Studio and rolling platform APIs.

## When to use

- Use before invasive edits to a Roblox place, Studio DataModel, or Rojo-backed project.
- Use to plan execution location, find/reuse systems, create editable Instances, and gather honest
  Studio verification evidence.

**When not to use:** this skill owns project operation, not the domain implementation. Compose it
with `roblox-ui`, `roblox-networking`, `roblox-characters`, `roblox-physics`, `roblox-luau`, or
`roblox-datastores` as appropriate.

# Roblox UI

Implement deliberate, editable Roblox UI that preserves the experience's visual language and
works across supported devices. Targets Roblox's rolling platform APIs. Pair with `game-ui-ux`
for engine-neutral information architecture and UX; this skill owns Roblox Instances and APIs.

## When to use

- Use for authored `ScreenGui` interfaces, Roblox layout/constraint APIs, UI lifecycle, input,
  focus, animation, performance, or responsive/device fixes.
- Use to replace brittle pixel layouts, runtime-created Instance tangles, mouse-only menus, or
  generic generated styling with a maintainable hierarchy.

**When not to use:** general UX flow and accessibility principles belong to `game-ui-ux`; raw

# Unity Animation (Animator / Mecanim)

Control animation state with Unity 6.3 LTS's `Animator` and Animator Controllers: parameters,
transitions, blend trees, layers, and humanoid IK. Targets **Unity 6.3 LTS (6000.3)**.

## When to use

- Use when connecting animation clips into a state machine, driving them from script via
  parameters, blending locomotion (idle→walk→run), layering an upper-body action over
  movement, or adding foot/hand IK on a humanoid rig.
- Use when the project has `*.controller` (Animator Controller) and `*.anim` assets, or a
  rigged model with an Avatar.

**When *not* to use:** simple non-skeletal value tweens (UI fades, position lerps) are better

# Unity Build Pipeline

Configure, script, and automate Unity 6.3 LTS player builds: scenes, platform target, scripting
backend, stripping, and headless/CI builds. Targets **Unity 6.3 LTS (6000.3)**.

## When to use

- Use when setting up Build Settings/Profiles, choosing a platform and scripting backend
  (Mono vs IL2CPP), reducing build size with managed stripping, scripting a repeatable build
  with `BuildPipeline.BuildPlayer`, or wiring a CI/headless build.
- Use when the project has `ProjectSettings/EditorBuildSettings.asset` or a CI build script.

**When *not* to use:** authoring a CI service config end-to-end is DevOps; this skill covers
the Unity-side build API and settings. Console/platform certification specifics are

# Unity C# Scripting (MonoBehaviour)

Write correct, idiomatic gameplay scripts in Unity 6. Get the lifecycle, component
access, serialization, and coroutines right so behaviour is deterministic and the
Inspector stays useful. Targets **Unity 6.3 LTS (6000.3)**, C# / .NET Standard 2.1.

## When to use

- Use when authoring or fixing a `MonoBehaviour`: choosing the right lifecycle callback,
  reading/caching components, exposing fields to the Inspector, or running timed logic
  with coroutines.
- Use when the project has `*.cs` files, an `Assembly-CSharp` or `*.asmdef`, and a
  `ProjectSettings/` folder.

# Unity Input System (new)

Read input through Unity's **Input System package** (`com.unity.inputsystem` 1.x; Unity 6.3 LTS
ships 1.20) — action-based, device-agnostic, rebindable. Targets **Unity 6.3 LTS**. This is the modern
replacement for the legacy `Input.GetAxis`/`Input.GetKey` Input Manager.

## When to use

- Use when setting up movement/jump/fire input, defining an `.inputactions` asset with
  action maps and control schemes, wiring a `PlayerInput` component, reading a `Vector2`
  stick/WASD value, or handling gamepad + keyboard + touch from one set of actions.
- Use when `Packages/manifest.json` contains `com.unity.inputsystem` or the project has an
  `*.inputactions` asset.

# Unity NavMesh (AI Navigation)

Give NPCs pathfinding in Unity 6.3 LTS: bake walkable surfaces and move agents around obstacles.
Targets **Unity 6.3 LTS (6000.3)** with the **AI Navigation package 2.0** (2.0.16 at last check).

> **Version trap (Unity 2022+/6):** the old built-in **Navigation window** (Object/Bake tabs,
> "Navigation Static" flag) is gone. The package's **Window → AI → Navigation** only holds the
> Agents and Areas tabs. Baking is now **component-based** via the **AI Navigation package**
> (`com.unity.ai.navigation`): add a **NavMeshSurface** to your level geometry and click
> **Bake**. The *runtime* `NavMeshAgent`/`NavMesh` API stays in built-in `UnityEngine.AI`.

## When to use

- Use when an agent needs to walk/chase/patrol to a target, when baking a navigable surface,

# Unity Physics (Rigidbody / PhysX)

Make objects move, collide, and detect each other with Unity 6.3 LTS's built-in 3D physics
(PhysX). Get the `FixedUpdate` discipline, trigger-vs-collision rules, and collision layers
right. Targets **Unity 6.3 LTS (6000.3)**.

> **Unity 6 renames:** `Rigidbody.velocity` → **`linearVelocity`**, `drag` → **`linearDamping`**,
> `angularDrag` → **`angularDamping`**. The old names still compile in 6.3 LTS but are obsolete
> (warnings; the API Updater offers the rename), so write the new names. `PhysicMaterial` →
> **`PhysicsMaterial`** is a hard compile error in old code.

## When to use

- Use when giving an object physical motion (forces, velocity, gravity), responding to

# Unity ScriptableObject Architecture

Use `ScriptableObject` assets to store shared data and decouple systems in Unity 6.3 LTS —
configuration, event channels, and registries that live as project assets instead of being
hard-wired into scenes or singletons. Targets **Unity 6.3 LTS (6000.3)**.

## When to use

- Use when you need designer-editable config (weapon stats, level data), to share one value
  between unrelated systems, to decouple senders from listeners via event channels, or to
  build a runtime registry of active objects — without a `static`/singleton manager.
- Use when the project has `*.asset` data files backed by `: ScriptableObject` classes.

**When _not_ to use:** per-instance runtime state that differs per GameObject (that belongs on

# Unity 2D Tilemap

Author and script tile-based 2D levels in Unity 6.3 LTS with the `Grid`/`Tilemap` system, the Tile
Palette, colliders, and runtime painting. Targets **Unity 6.3 LTS (6000.3)**.

> **Package note:** the core Tilemap (`Grid`, `Tilemap`, `Tile`, `TilemapCollider2D`) is
> built in, and so is the Tile Palette with its default brush. **Rule Tiles, Animated Tiles,
> and the extra brushes (Random, Line, GameObject, Group) live in the separate "2D Tilemap
> Extras" package (`com.unity.2d.tilemap.extras`, 6.0.x for Unity 6.3)** — install it via
> Package Manager before using `RuleTile`.

## When to use

- Use when laying out a 2D level by painting tiles, setting up a `Grid` + `Tilemap`, adding

# Unreal Behavior Trees

Author NPC decision-making in UE5 with Behavior Trees driven by a Blackboard: structure the
tree with composites, gate branches with decorators, keep state current with services, and run
it from an AIController. Targets **UE 5.8**.

## When to use

- Use when building enemy/NPC AI: creating a `BT_`/`BB_` asset pair, structuring
  Selector/Sequence branches, adding decorators (conditions) and services (periodic updates),
  writing custom `BTTask`/`BTService` nodes, or wiring an AIController to run the tree.
- Use when the project has Behavior Tree (`BT_`) and Blackboard (`BB_`) assets and an
  `AAIController`.

# Unreal Blueprints (Visual Scripting)

Structure gameplay logic in Unreal Engine 5 Blueprints: pick the right graph, expose data
cleanly, and choose a communication method that doesn't create hard-reference spaghetti.
Targets **UE 5.8**. (Blueprints are node graphs; the snippets below describe node flows.)

## When to use

- Use when authoring a Blueprint Class, wiring the Event Graph (BeginPlay/Tick/overlap),
  using the Construction Script, creating variables/functions/macros, or choosing how two
  Blueprints communicate (Cast, Interface, or Event Dispatcher).
- Use when the project has `*.uproject` and Blueprint `*.uasset` files, and the user works
  visually rather than in C++.

# Unreal C++ Gameplay

Write correct UE5 gameplay C++: the reflection macros that connect C++ to the editor and
Blueprints, the Gameplay Framework class roles, and module dependencies. Targets **UE 5.8**.

## When to use

- Use when creating C++ gameplay classes (`AActor`, `APawn`, `ACharacter`, `AGameModeBase`,
  `UActorComponent`), exposing properties/functions with `UPROPERTY`/`UFUNCTION`, setting up a
  GameMode's default classes, or adding a module dependency in `*.Build.cs`.
- Use when the project has a `Source/` tree with `*.h`/`*.cpp` using `UCLASS`, and `*.Build.cs`.

**When *not* to use:** designer-facing visual logic → `unreal-blueprints`. Player input
binding details → `unreal-enhanced-input`. AI logic → `unreal-behavior-trees`. This skill owns

# Unreal Enhanced Input

Wire player input the modern UE5 way with the **Enhanced Input** system: data-driven Input
Actions and Mapping Contexts instead of the legacy Project Settings axis/action mappings.
Targets **UE 5.8** (Enhanced Input is the default; legacy input is deprecated).

## When to use

- Use when adding movement/look/jump/fire input, creating Input Action (`IA_`) and Input
  Mapping Context (`IMC_`) assets, applying modifiers/triggers, adding a mapping context to a
  player, or binding actions in C++ or Blueprints.
- Use when the project has `IA_*`/`IMC_*` assets or references `EnhancedInput`.

**When *not* to use:** engine-agnostic input *architecture* (rebinding strategy, buffering,

# Unreal Niagara VFX

Build and control real-time visual effects in UE5 with Niagara: understand the
System/Emitter/Module hierarchy, expose parameters you can drive from gameplay, and spawn
effects at runtime. Targets **UE 5.8**. (Niagara replaces the legacy Cascade system.)

## When to use

- Use when creating a Niagara System (`NS_`) and Emitters (`NE_`), wiring modules in the
  spawn/update stages, exposing **User** parameters to gameplay, or spawning/driving an effect
  (impact, muzzle flash, fire, magic) from Blueprint or C++.
- Use when the project has Niagara `NS_`/`NE_` assets or references `UNiagaraComponent`.

**When *not* to use:** material/shader authoring (the look of a surface, not particles) is a

# Unreal Packaging & Cooking

Turn a UE5 project into a runnable, distributable build: choose the right build configuration,
cook content, set the launch map, and package — from the editor or the command line. Targets
**UE 5.8**.

## When to use

- Use when producing a build (test or release), choosing Development vs Shipping, cooking
  content, configuring Packaging / Maps & Modes settings, or automating builds with
  `RunUAT BuildCookRun` for CI.
- Use when the project has a `*.uproject` and `Config/Default*.ini`, and the goal is a packaged
  player rather than running in-editor.

# Phaser 4 Arcade Physics

Add movement and collision to a Phaser game with the lightweight **Arcade
Physics** engine (AABB rectangles and circles only). Targets **Phaser 4.2** for
new projects; inspect the installed major before editing an existing project.

## When to use

- Use for top-down or platformer movement, velocity/acceleration/gravity, bouncing,
  world bounds, and collision/overlap resolution between sprites, groups, and tiles.
- Use when the scene enables `physics: { default: 'arcade' }` and code calls
  `this.physics.add.*`, `body.setVelocity`, or `this.physics.add.collider`.

**When *not* to use:** the `Game` config, scene structure, asset loading, or

# Phaser 4 Core

Set up the foundation of a Phaser game: the `Game` config, the `Scene`
lifecycle, asset loading, cameras, and passing data between scenes. Targets
**Phaser 4.2** for new projects; keep an existing Phaser 3.90 project on its
pinned major unless the user explicitly asks for a migration.

## When to use

- Use when starting a Phaser game, wiring the `Phaser.Game` config, structuring
  `Scene`s, loading assets in `preload`, or fixing scene transitions and shared
  state.
- Use when the project has `phaser` in `package.json` or `import Phaser from 'phaser'`,
  and code uses `preload()`/`create()`/`update()`.