Drive Godogen (htdt/godogen), the MIT-licensed publish-time generator that turns a game description into an autonomous Claude Code or Codex build for Godot 4 C#, Bevy Rust, or Babylon.js TypeScript. Route one request to one mode: preflight the toolchain and API keys; publish a fresh game repository or safely refresh a matching existing runtime with `./publish.sh --engine ...`; run the build and prove it from the live game or a 15-20s recording; budget paid Gemini, Grok, and Tripo3D asset generation; apply engine-specific build and capture rules; troubleshoot rendering and capture failures; or contribute through the issue-first upstream process. Use when the user wants an agent to build a playable game end to end with Godogen. Triggers on: godogen, htdt/godogen, publish.sh --engine, autonomous game development, Godot C# agent build, Bevy agent build, Babylon.js agent game, asset-gen, Tripo3D rig, proof video.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
La commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Explorateur de fichiers
9 fichiers
Affichage de SKILL.md
SKILL.md
Instructions source · Aperçu en lecture seule
name
godogen
description
Drive Godogen (htdt/godogen), the MIT-licensed publish-time generator that turns a game description into an autonomous Claude Code or Codex build for Godot 4 C#, Bevy Rust, or Babylon.js TypeScript. Route one request to one mode: preflight the toolchain and API keys; publish a fresh game repository or safely refresh a matching existing runtime with `./publish.sh --engine ...`; run the build and prove it from the live game or a 15-20s recording; budget paid Gemini, Grok, and Tripo3D asset generation; apply engine-specific build and capture rules; troubleshoot rendering and capture failures; or contribute through the issue-first upstream process. Use when the user wants an agent to build a playable game end to end with Godogen. Triggers on: godogen, htdt/godogen, publish.sh --engine, autonomous game development, Godot C# agent build, Bevy agent build, Babylon.js agent game, asset-gen, Tripo3D rig, proof video.
allowed-tools
Bash Read Write Edit Glob Grep
compatibility
Godogen publishes for Claude Code or Codex on Ubuntu, Debian, or macOS. Shared tooling needs Bash, rsync, and Python 3.10+; Git is recommended for the initialized game repo. Engine lanes need Godot 4 .NET plus .NET 9, current Rust and Cargo, or Node 22.12+ plus Chrome with WebGL2. Asset generation optionally needs paid provider keys. The bundled helper is read-only and the cost estimator is offline.
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:
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.
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.
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.
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.
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.
Never print secrets. Report GOOGLE_API_KEY, XAI_API_KEY, and
TRIPO3D_API_KEY as SET or MISSING only.
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
Mode
Choose it when
First action
preflight
Engine or host readiness is uncertain
Run godogen.sh doctor <engine>
publish
A new repo or recognized same-lane runtime must be rendered
Run the read-only plan helper
run-delivery
The published repo exists and the game must be built
Read its manifest and engine guide
asset-spend
Images, video, GLB, rigging, or retargeting are needed
Build and approve a cost plan
engine-capture
Engine-specific implementation or proof is failing
Read references/engine-guides.md
troubleshoot
A concrete failure or stalled task exists
Identify the failing layer before retrying
contribute
The user wants to change upstream Godogen
Open or confirm an approved issue first
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
Inspect or clone the upstream source. Pin a commit for reproducibility when a
durable build matters.
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.
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.
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:
Read CLAUDE.md or AGENTS.md, then the rendered engine guide.
Keep durable status in the game's README.md: built, remaining, and an asset table
with in-game size, path, and cost.
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.
Run the engine's compile/import gates, then inspect the running game.
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:
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:
publish: target safety, Bash, Python, rsync, or template rendering
runtime: missing assets, side-effect imports, scene serialization, physics
capture: camera timing, offscreen target, WebGL renderer, load readiness
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.
