// 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 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.
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.
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 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 Babylon.js browser games |
| default_prompt | Use ${GODOGEN_COMMAND} to build or update this Babylon.js browser game from a natural-language design brief. |
| description | 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. |
Generate and update Babylon.js browser 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 | Vite/Babylon project shell | After decomposition |
architecture.md | Babylon gameplay architecture stance | Before designing game code |
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 | Babylon/browser gotchas | Before writing code |
scene-generation.md | Scene/world implementation patterns | When creating or replacing the playable scene |
capture.md | Browser screenshot/video capture | Before screenshots or video |
| (babylon-help skill) | Babylon/Vite/browser API lookup | For Babylon-specific questions |
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
+- Scaffold/refresh Vite project -> package.json + src/ + STRUCTURE.md
|
+- If budget provided (and no asset tables in ASSETS.md):
| +- Plan and generate assets -> ASSETS.md + updated PLAN.md with asset assignments
|
+- Start/keep Vite dev server running at http://127.0.0.1:5173
+- Execute risk slices first, then main build
+- Use browser screenshots frequently while iterating
+- If final presentation media is required:
+- Record browser video to screenshots/result/{N}/video.mp4
If a budget is provided, generating proper assets is part of the task. Use asset-planner.md / asset-gen.md before falling back to procedural stand-ins.
Runtime-loaded assets belong under src/assets/** when imported by TypeScript, or public/** only when a stable direct URL is needed. Keep reference images, prompts, source sidecars, and debug captures outside runtime asset paths.
Read task-execution.md before starting. Keep npm run dev alive when possible. Vite hot reload should be the normal inner loop:
src/game/** or src/assets/**.npm run check before larger edits and npm run build before final media.Chrome/Chromium and WebGL2 are required. If either is missing, stop and report the missing dependency rather than working around it. Hardware GPU acceleration is preferred — the capture script logs a prominent warning when WebGL2 falls back to a software renderer (SwiftShader, llvmpipe, lavapipe, etc) but still completes the capture. On a host with a GPU, treat that warning as a misconfiguration to fix; on a GPU-less host the warning is informational and the run still proves the task at reduced quality.
Use babylon-help for Babylon API questions, examples, loader behavior, Vite integration, browser capture issues, or exact import paths. Prefer the installed npm package sources/types for the current project version, then official docs.
Keep important state in files:
PLAN.md — task statuses and verification criteriaSTRUCTURE.md — architecture referenceMEMORY.md — discoveries, quirks, workarounds, what worked or failedASSETS.md — asset manifest with paths and generation detailsAfter completing each task, update the relevant state files. Commit after verified task slices when the repo policy or user asks for commits.
Do not trust code alone. Verify visible work in the browser with screenshots or recorded video. When code and media disagree, trust the media. If a requirement is not visible in browser capture, treat it as unfinished.