RandallLiuXin

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

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.

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 collection + generation. Reads ASSETS.md MISSING entries (rows whose Tag matches the current tag), dispatches an analyst subagent for image inspection, generates AI images through the configured asset_image_model path, updates ASSETS.md status. ASSETS.md is cross-tag — every row carries a Tag column marking the introducing tag. Re-runnable any time during a tag. Explicit invocation only — us

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

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 comp

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 gam

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.

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.

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/STYL

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.

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.

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.

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.

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.

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.

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

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).

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 iss

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

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 plan

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.

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", us

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.

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

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 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 re