Godogen

Godogen autonomous game generation

Godogen is a source repository that publishes a thin agent runtime into a fresh game repository. It is not the generated game and it is not a globally installed CLI:

godogen source -> published game repo -> game built by Claude Code or Codex

This skill tracks the docs-only runtime at upstream commit 05cebffc8b10c5817e8a3db495b82e7b6004ab84 (2026-07-02). That version publishes one runtime manifest, one engine guide, and one asset-gen skill. Older posts that describe planner, decomposer, scaffold, lookup, capture, or Telegram-hook skills are stale.

When to use this skill

• Decide whether Godogen fits a game brief and choose Godot, Bevy, or Babylon.js
• Check the host toolchain, rendering path, browser, and provider-key presence
• Publish Godogen into a new game repository or refresh a recognized same-lane runtime
• Run or steer an autonomous build under Godogen's live-game and proof-video contract
• Plan or troubleshoot paid image, video, GLB, rigging, retargeting, or sprite work
• Apply the engine-specific rules that compile successfully but fail visibly at runtime
• Diagnose a stalled Tripo3D task, black capture, missing Godot assembly, Bevy API drift, or Babylon software-renderer fallback
• Contribute to htdt/godogen after an upstream issue has been approved

Do not use this skill for:

• Unity or Unreal builds: use unity-cli, unity-gamedev-skill-pack, or game-build-log-triage
• Generic Three.js browser games: use web-game-development and the threejs-* family
• Standalone sprite generation: use perfectpixel
• Standalone auto-rigging: use unirig
• SFX, VFX, playtesting, or store launch: use rfxgen, game-vfx, wai-play, or steam-store-launch-ops
• A multi-role studio process independent of Godogen: use game-studio-harness

Instructions

Step 0: Enforce the safety contract

These rules apply before choosing a mode:

1. Use a fresh, empty target by default. A nonempty target is eligible only when the bundled plan helper recognizes the selected agent manifest, selected engine guide, and an agent skills directory containing only asset-gen:

   bash .agent-skills/godogen/scripts/godogen.sh plan \
     --engine godot --agent claude --out /path/to/game
   

   A recognized refresh must use normal publish after the game repo is committed or backed up. Never add --force to a refresh.

2. Treat --force as destructive. Upstream runs rm -rf on the resolved target. Never use it on a path with valuable contents. Show the exact target and obtain the user's explicit approval before any forced publish.

3. A normal publish can still delete sibling skills. Upstream uses rsync --delete on the entire .claude/skills/ or .agents/skills/ directory, not just asset-gen/. An existing repo with unrelated skills is not a safe target.

4. Confirm spend before the first paid call. Estimate the full plan, show provider, operation counts, and maximum cost, then get explicit approval. Do not treat a general request to build a game as approval for an unknown API bill.

5. Resume timed-out Tripo jobs. Never resubmit them. The task id is in <output>.tripo.json; asset_gen.py resume -o <output> polls the existing task for no extra cost. A second glb, rig, or retarget submission can double-charge.

6. Never print secrets. Report GOOGLE_API_KEY, XAI_API_KEY, and TRIPO3D_API_KEY as SET or MISSING only.

7. Prove the running game. A clean compile is a gate, not completion.

Read references/upstream-and-publish.md before a publish and references/asset-generation.md before any provider call.

Step 1: Pick exactly one operating mode

Do not blend setup, publication, paid generation, and engine execution into one unreviewable shell block.

Step 2: Preflight the selected lane

Run the read-only helper:

bash .agent-skills/godogen/scripts/godogen.sh doctor all
bash .agent-skills/godogen/scripts/godogen.sh doctor godot
bash .agent-skills/godogen/scripts/godogen.sh doctor bevy
bash .agent-skills/godogen/scripts/godogen.sh doctor babylon

The helper checks command presence and versions without installing anything or printing key values. Interpret missing tools by lane; for example, Rust is not a Godot blocker and Godot is not a Babylon blocker. Use references/setup-and-delivery.md for the exact prerequisites and manual verify commands.

Step 3: Publish or refresh a game repository

1. Inspect or clone the upstream source. Pin a commit for reproducibility when a durable build matters.

2. Run the plan helper against the intended target. If it blocks, choose a new empty directory and do not weaken the check. If it recognizes a same-lane runtime, commit or back up the game repo and use normal publish without --force.

3. Choose one engine and one host agent:

   ./publish.sh --engine godot   --agent claude --out /path/to/new-game
   ./publish.sh --engine bevy    --agent codex  --out /path/to/new-game
   ./publish.sh --engine babylon --agent claude --out /path/to/new-game
   

4. Inspect the rendered manifest, engine guide, asset-gen folder, .gitignore, and Git status. On refresh, review the diff and verify gameplay files were preserved. Upstream runs git init when Git is available and writes .gitignore only when one does not already exist.

5. Do not add --force merely because publication failed. Diagnose the target first.

The exact Claude/Codex layouts and template values are in references/upstream-and-publish.md.

Step 4: Run under the delivery contract

Inside the published game repository:

1. Read CLAUDE.md or AGENTS.md, then the rendered engine guide.
2. Keep durable status in the game's README.md: built, remaining, and an asset table with in-game size, path, and cost.
3. Match the execution style to the brief:
   • open-ended or collaborative direction: expose the live game early and checkpoint taste, scope, and cost decisions;
   • finished brief: make reasonable calls, run steadily, and avoid unnecessary blocking questions.
4. Run the engine's compile/import gates, then inspect the running game.
5. If the user has not seen it live, finish with a 15-20 second proof video and watch it back before reporting completion.

A full run may take hours. On a remote GPU host, keep it inside tmux or screen and use the official Claude Code or Codex remote-control surface rather than an ad hoc background process.

Step 5: Budget and run asset generation

Before any paid call, estimate the frozen upstream rates offline:

python3 .agent-skills/godogen/scripts/cost-estimate.py \
  --grok-images 4 --gemini-1k 2 --video-seconds 6 \
  --glb 2 --rig 1 --retarget 3

Show the estimate, state that provider prices can change, and obtain approval for the specific plan. Then use the published repo's asset-gen tools. Claude publishes them under .claude/skills/asset-gen/; Codex uses .agents/skills/asset-gen/.

For sprite, GLB, rigging, retargeting, background-removal, logging, and retry recipes, read references/asset-generation.md. Review each reference image before paying for a downstream GLB or rig.

Step 6: Apply the engine guide, then verify visibly

• Godot: .NET/Mono only; C# classes are partial; generated scenes need correct owner chains and pack validation; use primitive colliders for imported GLBs.
• Bevy: resolve and pin the current stable version; keep all bevy_* crates on one minor; verify APIs against installed source; capture from a dedicated offscreen binary, not the windowed app.
• Babylon.js: use Vite + TypeScript; bind the dev server to a shareable fixed port; register required side-effect imports; reject SwiftShader/llvmpipe/lavapipe as proof of a correctly configured GPU path.

Read references/engine-guides.md for the silent-failure checks and capture commands. Do not copy an old engine recipe without matching it to the installed version.

Step 7: Troubleshoot before retrying

Classify the first failed layer:

1. publish: target safety, Bash, Python, rsync, or template rendering
2. toolchain: Godot/.NET, Rust/Bevy, Node/npm, browser, Vulkan, Xvfb, ffmpeg
3. build: compile/import/package errors
4. runtime: missing assets, side-effect imports, scene serialization, physics
5. capture: camera timing, offscreen target, WebGL renderer, load readiness
6. provider: key, quota, generation error, or pending Tripo sidecar

Do not repeat a paid call or long build until the layer is known. For a pending Tripo sidecar, resume. For contribution work, upstream requires an approved issue before a PR and favors narrow, evidence-backed changes.

Examples

Example 1: Check whether a Godot build host is ready

bash .agent-skills/godogen/scripts/godogen.sh doctor godot

Resolve only Godot blockers, then verify dotnet --version, a .mono Godot build, and godot --headless --quit.

Example 2: Preview a Codex Babylon publication

bash .agent-skills/godogen/scripts/godogen.sh plan \
  --engine babylon --agent codex --out "$HOME/new-babylon-game"

Proceed only if the helper reports a new/empty target or a recognized same-lane refresh. Expect AGENTS.md, babylon.md, .agents/skills/asset-gen/, an engine .gitignore, and a Git repository.

Example 3: Recover a timed-out Tripo3D model

python3 .agents/skills/asset-gen/tools/asset_gen.py resume -o assets/model.glb

Do not submit glb again while assets/model.glb.tripo.json records the task.

Example 4: Price a rigged character with three clips

python3 .agent-skills/godogen/scripts/cost-estimate.py \
  --gemini-1k 1 --rig 1 --retarget 3 --json

At the pinned rates this is 92 cents: 7 + 55 + 30.

Best practices

1. Prefer a new target; refresh only a helper-recognized same-lane runtime and never use --force.
2. Pin the upstream commit for reproducible publication; re-read current upstream before claiming a latest-version behavior.
3. Keep the published runtime thin; do not resurrect the pre-2026-07-02 skill pipeline.
4. Separate compile gates from running-game proof.
5. Show a cost ceiling and asset count before spending.
6. Resume Tripo sidecars instead of resubmitting.
7. Keep generation references and captures outside runtime asset directories.
8. Record each generated asset's in-game size and cost in the game README.
9. Trust installed engine/package sources over model memory when APIs differ.
10. Watch every final proof video; file existence alone is not visual verification.

References

• references/upstream-and-publish.md - pinned architecture, payload, flags, deletion hazards
• references/setup-and-delivery.md - prerequisites, key handling, and delivery modes
• references/asset-generation.md - paid models, costs, commands, sprite and Tripo recovery
• references/engine-guides.md - Godot, Bevy, Babylon build and capture rules
• scripts/godogen.sh - read-only host doctor, publication plan, and pinned URLs
• scripts/cost-estimate.py - offline cost estimate at pinned upstream rates
• Godogen repository
• Pinned upstream source