// Generate or update a complete Godot game from a natural-language description. Use when the user wants ${AGENT_NAME} to make, rebuild, or substantially extend a Godot project end to end.
Look up Babylon.js APIs, import paths, examples, loaders, Vite integration, and browser runtime behavior. Use for Babylon-specific API lookup, feature design, rendering setup, asset loading, and capture issues.
Generate or update a complete Babylon.js browser game from a natural-language description. Use when the user wants ${AGENT_NAME} to make, rebuild, or substantially extend a Babylon.js project end to end.
Look up current Bevy engine APIs, crates, examples, and patterns. Use for any Bevy-related question, including API lookup, feature design, architecture, and implementation patterns.
Generate or update a complete Bevy game from a natural-language description. Use when the user wants ${AGENT_NAME} to make, rebuild, or substantially extend a Bevy project end to end.
Look up Godot engine class APIs, methods, properties, signals, enums, or C# Godot syntax. Use when you need a targeted Godot API answer or a specific engine-class recommendation.
| name | godogen |
| display_name | Godogen |
| short_description | Generate or update complete Godot games |
| default_prompt | Use ${GODOGEN_COMMAND} to build or update this Godot game from a natural-language design brief. |
| description | Generate or update a complete Godot game from a natural-language description. Use when the user wants ${AGENT_NAME} to make, rebuild, or substantially extend a Godot project end to end. |
Generate and update Godot games from natural language.
Read each stage file from ${GODOGEN_SKILL_DIR}/ only when you reach that stage.
| File | Purpose | When to read |
|---|---|---|
visual-target.md | Generate reference image | Pipeline start |
decomposer.md | Decompose into task plan | After visual target |
scaffold.md | Architecture + skeleton | After decomposition |
asset-planner.md | Budget and plan assets | If budget provided |
asset-gen.md | Asset generation CLI ref | When generating assets |
rembg.md | Background removal | Only when an asset needs transparency removed |
task-execution.md | Task workflow + commands | Before first task |
quirks.md | Godot gotchas | Before writing code |
scene-generation.md | Scene builders | Targets include .tscn |
test-harness.md | SceneTree verification scripts | Before writing capture/test scripts |
capture.md | Screenshot/video capture + final result bundle | Before automated screenshots or video |
android-build.md | APK export | User requests Android |
| (godot-api skill) | C# Godot syntax ref | When unsure about Godot API details |
User request
|
+- Check if PLAN.md exists (resume check)
| +- If yes: read PLAN.md, STRUCTURE.md, MEMORY.md, ASSETS.md if present -> skip to task execution
| +- If no: continue with fresh pipeline below
|
+- Generate visual target -> reference.png + ASSETS.md (art direction only)
+- Analyze risks + define verification criteria -> PLAN.md
+- Design architecture -> STRUCTURE.md + project.godot + stubs
|
+- If budget provided (and no asset tables in ASSETS.md):
| +- Plan and generate assets -> ASSETS.md + updated PLAN.md with asset assignments
|
+- Show user a concise plan summary (risk tasks if any, main build scope)
|
+- Execute (see Execution below)
|
+- If final presentation media is required:
| +- Read test-harness.md and capture.md, produce a fresh screenshots/result/{N}/ bundle with raw frames and video.mp4
|
+- If user requested Android app:
| +- Read android-build.md, add ETC2/ASTC to project.godot, create export_presets.cfg, export APK
|
+- Summary of completed game
If a budget is provided, generating proper assets is part of the task, not optional. Do not fall back to procedural primitives (boxes stacked into a human, spheres for heads, coloured quads for props) when the budget allows a real asset — plan and generate the asset through asset-planner.md / asset-gen.md. Procedural stand-ins are acceptable only for genuinely abstract shapes (platforms, blocks, particles) or when the asset-planner has explicitly ruled an asset out on budget grounds.
Placeholder primitives in gameplay code are a signal that the asset step was skipped — go back and generate the asset before continuing.
Read task-execution.md before starting. Two phases:
If PLAN.md calls for presentation media, finish through the Godot test harness and capture flow in test-harness.md / capture.md and leave a fresh screenshots/result/{N}/ proof bundle behind.
When you need to look up a Godot class API or C# Godot pattern, use the godot-api skill with a targeted query. It keeps large API docs out of the main pipeline.
Use the skill inline when you already know what class or symbol to inspect and can answer by searching _common.md / _other.md plus reading a small number of specific docs. Use a dedicated helper agent when you need to discover candidate classes, compare several classes, or read multiple or large docs and reduce them to a compact answer.
Be specific about what you need:
"CharacterBody3D: what method applies velocity and slides along collisions?""full API for AnimationPlayer"Keep important state in files so the pipeline can resume cleanly after long threads or compaction:
After completing each task: update PLAN.md, write discoveries to MEMORY.md, and commit. If the thread becomes noisy, summarize the important state into those files and continue from the artifacts instead of relying on conversational memory.
Do not trust code alone — verify on screenshots, captured frames, and video. Code that looks correct often still ships broken placement, wrong scale, clipped geometry, missing elements, or bad motion timing.
When code and media disagree, trust the media. Be skeptical: the job is to find what is still broken, not to argue that it is probably fine. If a requirement is not clearly visible, treat it as not done.
Inspect captures directly while you work, then finish with a fresh screenshots/result/{N}/ proof bundle containing video.mp4 and the raw frameXXX.png sequence used to encode it.