liangdabiao Game Generator — Orchestrator
Generate and update Godot games from natural language.
Capabilities
Read each sub-file from ${CLAUDE_SKILL_DIR}/ when you reach its pipeline stage.
| File | Purpose | When to read |
|---|---|---|
visual-target.md |
Generate reference image | Pipeline start |
decomposer.md |
Decompose into task DAG | 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 |
sprite-gen.md |
Sprite sheet animation generation | When generating animated characters |
task-execution.md |
Task workflow + commands | Before first task |
quirks.md |
Godot gotchas | Before writing code |
| (godot-api skill) | GDScript syntax ref | When unsure about GDScript syntax |
scene-generation.md |
Scene builders | Targets include .tscn |
test-harness.md |
Verification scripts | Before test harness |
capture.md |
Screenshot/video | Before capture |
visual-qa.md |
Visual QA (forked skill) | After capture |
android-build.md |
APK export | User requests Android |
Pipeline
User request
|
+- Check if PLAN.md exists (resume check)
| +- If yes: read PLAN.md, STRUCTURE.md, MEMORY.md -> 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 user requested Android app:
| +- Read android-build.md, add ETC2/ASTC to project.godot, create export_presets.cfg, export APK
|
+- Summary of completed game
Execution
Read task-execution.md before starting. Three phases:
- Risk tasks (if any) — implement each in isolation, verify, commit
- Main build — implement everything else, verify, present results (video for new games), commit
Godot API Lookup
When you need to look up a Godot class API (methods, properties, signals), use Skill(skill="godot-api") with your query. This runs in a separate context to avoid loading large API docs into the main pipeline.
Be specific about what you need — the docs are comprehensive and full returns are large:
- Targeted query — ask for specific methods/signals to get a concise answer:
"CharacterBody3D: what method applies velocity and slides along collisions?" - Full API — only request when you need to survey the entire class:
"full API for AnimationPlayer"
Examples:
- Skill(skill="godot-api") "TileMapLayer: methods for setting/getting cells and their alternatives"
- Skill(skill="godot-api") "full API for CharacterBody3D"
- Skill(skill="godot-api") "which class handles 2D particle effects?"
- Skill(skill="godot-api") "GDScript: tween parallel syntax and callbacks"
Visual QA
After capturing screenshots, verify with Skill(skill="visual-qa"). Runs in a forked context with Claude's native vision.
- Static:
Skill(skill="visual-qa") "Check reference.png against screenshots/{task}/frame0003.png — Goal: ..., Verify: ..." - Dynamic:
Skill(skill="visual-qa") "Check reference.png against frame1.png frame2.png ... — Goal: ..., Verify: ..." - Question:
Skill(skill="visual-qa") "Are surfaces showing magenta? screenshots/{task}/frame*.png"
Save output to visual-qa/{N}.md. See visual-qa.md for full usage.
Context Hygiene
Keep important state in files so the pipeline can resume even after compaction or clear:
- PLAN.md — task statuses, always up to date before moving on
- STRUCTURE.md — architecture reference, update if scaffolding changes
- MEMORY.md — discoveries, quirks, workarounds, what worked/failed
- ASSETS.md — asset manifest with paths and generation details
After completing each task: update PLAN.md status, write discoveries to MEMORY.md, git commit. This ensures the pipeline can resume from any point by reading these files.
If the context becomes polluted from debugging loops, manually compact with:
/compact "Discard failed debugging attempts."
Visual QA
Don't trust code — verify on screenshots. The most common failure mode: code looks correct, you assume it works, and report "everything's fine." Then screenshots reveal broken placement, wrong scale, missing elements, clipped geometry — dozens of small details that go wrong in unexpected ways, especially with custom assets. Visual QA is your quality partner: use it actively after every task, not as a formality.
Visual QA runs inline with each task. Never ignore a fail verdict — always act on it before marking a task done.
VQA reports are clear signal. If a significant issue is reported, fix it. If you genuinely believe it's a false positive — report it to the user and let them decide. Never silently ignore a fail verdict.
- pass/warning — move on.
- fail — fix the issue. If you've already attempted up to 3 fix cycles, decide:
- Replan — reset architecture, rewrite plan, and/or regenerate assets if the root cause is upstream.
- Escalate — surface the issue to the user if you can't determine the right fix.
The final task in PLAN.md is a presentation video — a script that showcases gameplay in a ~30-second cinematic MP4.