GodotMaker

Generate a new Godot game project with standardized ECS structure and tooling. Use when starting a new game: "create a project", "set up a new game", "scaffold", "initialize", "new project", "start building", "let's make it". Triggers after game-planner produces a confirmed plan, or when the user provides a game name + genre directly. Even for simple requests like "make me a new Godot project", use this skill to ensure proper ECS structure. Creates directory structure, project.godot, CLAUDE.md, gecs World setup, addon stubs, and template source files based on the game plan or user input.

Evaluate the current tag's quality: enforce the playable-closed-loop gate, maintain a single cross-tag e2e/ suite that always reflects the current game (add tests for new mechanics, prune tests for mechanics this tag deliberately removed), and reason about gameplay quality. Independent from the build process — fresh perspective on the final product. Explicit invocation only — use /gm-evaluate.

Reviews Godot Animation implementation for known pitfalls. Triggers AFTER implementation, when code involves AnimationPlayer, AnimationTree, AnimatedSprite2D, SpriteFrames, AnimationNodeStateMachine, BlendSpace, OneShot, callback_mode_process, or animation playback control (play/travel/start). Do NOT use this skill for planning or teaching — only for post-implementation review.

Run gdUnit4 unit tests and parse results into structured output. Use this skill after writing or modifying code to verify correctness via unit tests, when diagnosing test failures, or when writing new test files. Triggers: "run tests", "test fails", "write a test", any gdUnit4/unit test mention. Supports both GDScript (.gd) and C# (.cs) test files.

Asset stage manager. Reads current-tag ASSETS.md gaps, accepts user-provided assets, plans visual production units, dispatches asset-producer subagents, collects reports, updates ASSETS.md and the asset-generation manifest. Explicit invocation only - use /gm-asset.

Scaffold a new Godot project: project.godot + addons + base directories + e2e/conftest.py + initial git commit. Lifetime-once role — runs only on fresh projects. Explicit invocation only — use /gm-scaffold.

Mechanical verification of the built game: headless build, unit tests, lint, static checks. Explicit invocation only — use /gm-verify.

Compile-check a Godot project using headless mode. Use after writing or modifying any GDScript or C# code to verify it compiles. Triggers: after code changes, before running tests, when build errors need diagnosis. Also use this when the user says "check if it compiles", "build check", "does this parse", or after any file creation/modification that could break compilation.

Clarifies game design requirements and produces a Game Design Document (GDD). Use this skill BEFORE writing any game code. Triggers when the user describes a game idea, says "make a game", "build a {genre}", "I want a platformer", "create a tower defense", or provides any game concept — even vague ones like "make something fun" or "I have a game idea". Also triggers on "plan a game", "design a game", "game design document", "GDD". ALWAYS run game-planner before starting implementation. If the user jumps straight to "make me a platformer", do NOT start coding — interview first. The only exception is if a confirmed GDD already exists in the conversation.

Implement game mechanic functions via worker dispatch. Covers risk-first then main implementation. Dispatches workers until PLAN is clean, then runs one verify+review pass; loops until convergence. Explicit invocation only — use /gm-build.

Fix gaps identified by the Evaluator. Generates GAP.md from evaluation.json, dispatches workers to address critical/major issues, then runs one final verify+review pass. Unlike gm-build (PLAN.md-driven), gm-fixgap is GAP.md-driven. Explicit invocation only — use /gm-fixgap.

Game Design Document phase for one tag. On the first ever run, runs the full Socratic interview, produces GDD.md, and derives ROADMAP.md (split into SemVer-tagged release tags). On every subsequent run, focuses the conversation on the current tag (the earliest entry in ROADMAP.md without a git tag), optionally updates GDD.md / ROADMAP.md, then generates the current tag's PLAN/STRUCTURE/SCENES/STYLE/ASSETS at the project root. Explicit invocation only — use /gm-gdd.

Self-diagnostic skill for godotmaker itself. Invoked when the main pipeline can't make progress (e.g. several fixgap rounds in a row failed to converge). NOT a "smarter fixgap" — does not modify game code, does not write files, only reports diagnosis to chat. If a godotmaker-side defect is the root cause, drafts an issue the user can post upstream. Explicit invocation only — use /gm-rescue.

Visual quality assurance: analyze game screenshots for defects, compare against reference, check motion in frame sequences. Supports runtime-native inspection plus Gemini or OpenAI API-backed VQA.

gecs ECS framework API reference — the Entity-Component-System addon for Godot 4.x used by this project. Covers Entity, Component, System, World, QueryBuilder, Relationship, Observer, CommandBuffer, SystemTimer. Use when the task involves ECS architecture: creating entities with components, defining component data classes (C_ prefix), writing game logic systems, querying entities by component composition, entity relationships or links, reactive observers for component changes, safe structural changes during iteration, system tick rates, ECS world setup, debugging ECS queries or cache, or deferred entity destruction. Also trigger on gecs API calls: q.with_all(), ECS.world, ECS.process(), define_components(), cmd.add_component(). gecs has zero LLM training data — without this skill all ECS API calls will be fabricated. NOT relevant for standard Godot subsystems (physics, animation, UI, tilemap, shader, particles, navigation, signals, audio) unless explicitly connected to ECS.

Look up Godot engine class APIs — methods, properties, signals, enums. Use when you need to find which class to use or look up specific API details. Supports version-specific docs — reads the correct API for the project's Godot version.

Capture gameplay screenshots using godot-e2e for visual verification. Use when you need to: take a screenshot of the running game, capture multiple screenshots during an E2E scenario, generate reference.png, visually verify game state, or provide screenshots for VQA analysis. Triggers: "screenshot", "capture screenshot", "take screenshot", "reference.png", "visual capture", "screenshot the game".

Seal the current tag: snapshot the per-tag working docs into docs/tags/<Tag>/, write a CHANGELOG entry, run `git tag`, and reset per-tag runtime state for the next /gm-gdd round. Does NOT package a release — that lives in a separate skill. Explicit invocation only — use /gm-finalize.

Write and run E2E (end-to-end) game tests using the godot-e2e framework. Python controls a live Godot game over TCP — Locator-based semantic queries, expect() auto-retry assertions, and engine log capture make failures self-diagnosing. Use this skill whenever you need to: - Test actual gameplay: player movement, collisions, scoring, scene transitions - Verify UI interactions: button clicks, label text, menu navigation - Write integration tests that run the real game (not mocked unit tests) - Debug E2E test failures or set up E2E test infrastructure Triggers: "E2E test", "end-to-end test", "gameplay test", "test the game running", "simulate input", "test player movement", "test UI clicks", "godot-e2e", "integration test for game", "test scene transitions".

Reviews Godot UI/Control implementation for known pitfalls. Triggers AFTER implementation, when code involves Control, Container, HBoxContainer, VBoxContainer, GridContainer, MarginContainer, ScrollContainer, PanelContainer, Button, Label, LineEdit, TextEdit, OptionButton, TabContainer, CanvasLayer, Theme, StyleBox, focus_mode, mouse_filter, grab_focus, or gui_input. Do NOT use this skill for planning or teaching — only for post-implementation review.

Present final results to the user for acceptance. Shows evaluation results, evaluator screenshots, and asks for confirmation. Explicit invocation only — use /gm-accept.

Lint and format GDScript files using gdtoolkit (gdlint + gdformat). Use after writing or modifying .gd files, when asked to check code style, fix lint errors, format code, or set up linting configuration. Also use when gdlint/gdformat errors appear in output and need diagnosis. Does NOT require Godot — runs as a standalone Python tool.

Runtime debugging and live project inspection via godot-mcp. Use when headless tools cannot diagnose the problem: code compiles but runtime behavior is wrong, tests pass but the game does not work as expected, or you need to inspect live state (node tree, console output, rendering). Escalation trigger: a task has failed 2+ times through the headless path (headless-build, gdunit-driver), or the issue is inherently runtime-only (visual glitches, input not responding, physics behaving unexpectedly at runtime). DO NOT use for: syntax/compile errors (use headless-build), unit test failures (use gdunit-driver), API lookups (use godot-api). Requires: godot-mcp MCP server registered as "godot" (@coding-solo/godot-mcp).

Manage Godot input action mappings in project.godot. Use when adding input actions, changing key bindings, setting up controls for a new genre, or validating that all referenced actions exist. Called by project-scaffold (initial setup), workers (new mechanics), and the dispatching role (GDD changes requiring new inputs).

Reviews Godot Audio implementation for known pitfalls. Triggers AFTER implementation, when code involves AudioStreamPlayer, AudioStreamPlayer2D, AudioStreamPlayer3D, AudioServer, AudioBus, AudioEffect, AudioStream, or .finished signal on audio players. Do NOT use this skill for planning or teaching — only for post-implementation review.

Reviews Godot navigation implementation for known pitfalls. Triggers AFTER implementation, when code involves NavigationAgent2D, NavigationAgent3D, NavigationRegion2D, NavigationRegion3D, NavigationLink2D, NavigationLink3D, NavigationObstacle2D, NavigationObstacle3D, target_position, TargetPosition, avoidance_enabled, bake_navigation_polygon, navigation_layers, velocity_computed, safe_velocity, is_navigation_finished. Do NOT use this skill for planning or teaching — only for post-implementation review.

Reviews Godot Particles implementation for known pitfalls. Triggers AFTER implementation, when code involves GPUParticles2D, GPUParticles3D, CPUParticles2D, CPUParticles3D, ParticleProcessMaterial, trail_enabled, sub-emitters, GPUParticlesCollision, or particle amount/emission control. Do NOT use this skill for planning or teaching — only for post-implementation review.

Reviews Godot physics implementation for known pitfalls. Triggers AFTER implementation, when code involves CollisionObject2D, RigidBody2D, CharacterBody2D, Area2D, collision layers, or physics callbacks. Do NOT use this skill for planning or teaching — only for post-implementation review.

Reviews Godot Shader/Material implementation for known pitfalls. Triggers AFTER implementation, when code involves ShaderMaterial, set_shader_parameter, .gdshader, VisualShader, hint_screen_texture, BackBufferCopy, instance uniform, or uniform declarations. Do NOT use this skill for planning or teaching — only for post-implementation review.

Reviews Godot TileMap implementation for known pitfalls. Triggers AFTER implementation, when code involves TileMapLayer, TileSet, TileSetAtlasSource, TileSetScenesCollectionSource, terrain painting, set_cell, erase_cell, get_cell_tile_data, collision polygons on tiles, or NavigationRegion2D with tile-based navigation. Do NOT use this skill for planning or teaching — only for post-implementation review.