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?".

*When not to use:* once the right skill is loaded and the task is squarely inside it, work
from that skill — don't re-run the router every turn. Re-route only when the task pivots to a
new engine or concern (router step 6).

Routing algorithm

1. Detect engine and version — project fingerprint → at most one engine skill set (or

"unknown"), then read the project's version source. §1.

1. Classify task — phrasing → discipline(s) + at most one genre + workflow(s). §2.
2. Resolve — the minimal set: engine skill(s) + discipline(s) + genre + workflow(s). §3.
3. Read (disclosure) — open only the chosen SKILL.md bodies; references/ only on demand. §4.
4. Compose — order: engine fundamentals → discipline concept → genre glue → workflow. §5.
5. Fallback — engine unknown or no skill fits → ask or default to Godot; state any gap. §6.

---

1. Engine detection (project fingerprint)

Scan for the highest-confidence signal; choose exactly one engine. Stop at the first match.

For secondary signals, the Godot-C#/Unity/Bevy and multi-web disambiguation rules, monorepos,
and plain-text engine mentions, read references/engine-detection.md.

After identifying the engine, read its version from project metadata or dependency locks before
choosing APIs. Existing projects keep their pinned version unless migration is requested; the
catalog baseline is only for new projects. The exact version sources are in the detection reference
and ../docs/VERSION-SUPPORT.md.

2. Task classification (phrasing → category)

After the engine, read the request for task signals (three additive categories):

• disciplines (cross-engine concepts): create-game-assets, game-ai, procedural-gen, dialogue-systems,

save-systems, audio-design, shader-programming, physics-tuning, level-design,
input-systems, game-feel, camera-systems, game-ui-ux, performance-optimization.
Triggered by concept words ("sprite sheet", "art direction", "texture", "pathfinding",
"save slots", "fragment shader", "screen shake", "camera follow", "HUD/menu",
"optimize/low FPS").

• genres (whole-game templates): platformer, roguelike, rpg, fps-shooter,

tower-defense, card-game, visual-novel, survival-crafting, puzzle. Triggered by genre
words ("make a roguelike", "deckbuilder").

• workflows (process/shipping): game-jam, prototype-fast, steam-publish,

itch-publish. Triggered by process words ("publish on Steam", "vertical slice").

File signals sharpen this: *.yarn/*.ink → dialogue-systems/visual-novel; steam_appid.txt
→ steam-publish; *.inputactions → unity-input-system.

3. Routing table (task → category → skill)

3a. Engine skills — read the one matching the detected engine + sub-task

• Godot (skills/godot/): language godot-gdscript / godot-csharp; structure

godot-nodes-scenes, godot-signals-groups; 2D godot-2d-movement, godot-tilemap; 3D
godot-3d-essentials; physics godot-physics; UI godot-ui-control; animation
godot-animation; shaders godot-shaders; data godot-resources; audio godot-audio;
netcode godot-multiplayer; ship godot-export.

• Unity (skills/unity/): scripting unity-csharp-scripting; input unity-input-system;

physics unity-physics; animation unity-animation; data unity-scriptableobjects; 2D
unity-tilemap-2d; AI nav unity-navmesh; ship unity-build-pipeline.

• Unreal (skills/unreal/): visual scripting unreal-blueprints; C++ gameplay

unreal-cpp-gameplay; input unreal-enhanced-input; AI unreal-behavior-trees; VFX
unreal-niagara; ship unreal-packaging.

• Web (skills/web-engines/): phaser-core, phaser-arcade-physics; pixijs-rendering;

threejs-scene-setup, threejs-gltf-loading, threejs-materials-lighting.

• Other (skills/other-engines/): bevy-ecs, pygame-core, love2d-core, roblox-luau,

roblox-datastores.

3b. Disciplines — load with the engine skill (concept ↔ engine API)

3c. Genres — compose engine + disciplines (bind * to the detected engine)

3d. Workflows — engine-independent process & shipping

game-jam (jam, 48-hour, Ludum Dare/GMTK) · prototype-fast (vertical slice, MVP, greybox) ·
steam-publish (Steam, Steamworks, depot; steam_appid.txt) · itch-publish (itch.io, butler;
.itch.toml).

For the exhaustive per-skill trigger list and every engine binding, read
references/routing-table.md.

4. Read protocol (progressive disclosure)

1. Preloaded: only each skill's name + description are in context. Decide from those plus

the fingerprint — do not pre-read bodies.

1. On selection: read the body of each chosen skills/<category>/<name>/SKILL.md — and

only those. Never bulk-load a whole category.

1. On demand: read a skill's bundled references/ files only when the subtask needs that

depth (the skill body says when).

1. Re-route on pivot: if the task changes (movement → saving), select and read the newly

relevant skill instead of keeping everything loaded.

Announce what you load and why, e.g.: *"Detected Godot (project.godot). Loading
godot-2d-movement for the controller and platformer for jump feel; will open the platformer
skill's feel-tuning.md reference if you want coyote-time/buffering."*

5. Composition rules

• One engine set, additive concepts. Exactly one engine skill set; add the disciplines the

task needs and usually at most one genre. Workflows attach independently.

• Order: engine fundamentals → discipline concept → genre orchestration → workflow. For asset

production, approve the visual target before generating a family, then finish with the engine
import settings and an in-context capture.

• Ownership on overlap: the engine skill owns API/syntax; the discipline skill owns

the portable concept/algorithm and defers to the engine skill for code; the genre skill owns
structure/glue and links out instead of re-teaching a primitive.

• Hand-offs: when a genre's composes names a slot like *-2d-movement, bind it to the

detected engine. If that engine lacks the exact skill, see §6 and references/routing-table.md
("Binding gaps").

6. Unknown-engine & no-skill fallback

Engine unknown (no fingerprint, no engine named):

1. Check the request for a plain-text engine name ("in Unity", "using Phaser"). If found, adopt it.
2. If the task is a pure concept/genre/workflow question, route straight to the engine-agnostic

discipline/genre/workflow skill — no engine needed ("what's a good save format?" → save-systems).

1. Only if engine choice actually blocks the answer, ask one targeted question ("Which engine —

Godot, Unity, Unreal, or a web/other engine?"). If the user has no preference and one is needed,
default to Godot (the most fully covered engine here) and say so.

1. Never invent an engine or load an engine skill on a guess.

Engine known but no skill covers the subtask: load the closest engine skill plus the relevant
discipline and state the gap plainly (e.g. "no dedicated Unity 2D-movement skill; using
unity-csharp-scripting + unity-physics"). Never fabricate a skill name.

Conflicting/multiple genres: pick the dominant genre from the phrasing; mention the secondary
and offer to load it if the user confirms.

Worked examples

References

• Full engine fingerprints, secondary signals, and disambiguation: references/engine-detection.md.
• Exhaustive per-skill trigger words, engine bindings, and binding gaps: references/routing-table.md.