Show HN: Claude Code skills that build complete Godot games

Why “Claude Code skills” are interesting for Godot developers

The compelling idea behind “Claude Code skills that build complete Godot games” is not simply “ask an LLM to make a game.” Developers have been trying that since code models became usable. The more interesting technique is packaging domain-specific workflows into repeatable agent skills: structured instructions, project conventions, validation steps, and engine-specific knowledge that guide an AI coding assistant through an entire Godot project.

For Godot, this matters because game projects are not just code. A working game usually involves:

• Scene trees and .tscn files
• GDScript or C# logic
• Input maps
• Resources, sprites, audio, shaders, and fonts
• Node naming conventions
• Editor settings
• Export configuration
• Iteration through playtesting and bug fixing

A generic coding assistant may write a plausible Player.gd, but fail to connect it to the correct scene, forget to configure input actions, or generate assets in the wrong folder. A Godot-specific skill narrows the problem: it tells the model how a Godot project should be structured, how to reason about scenes, and how to verify that the game is actually runnable.

That is the pattern worth stealing.

The core pattern: turn “make a game” into a build pipeline

A good game-generation skill should not be one giant prompt. It should behave more like a development pipeline.

Instead of:

Build me a complete top-down shooter in Godot.

Use a staged workflow:

1. Define the game loop.
2. Create the Godot project structure.
3. Generate scenes and scripts.
4. Wire inputs and resources.
5. Run static checks.
6. Launch or simulate tests.
7. Iterate from concrete errors.

This works because game projects have many cross-file dependencies. The model needs to plan before it writes, and it needs feedback after it writes.

A practical Claude Code skill might include instructions like:

When creating a Godot game:

1. First inspect the existing project files.
2. Do not overwrite user-created assets unless asked.
3. Prefer Godot 4.x GDScript syntax.
4. Create a minimal playable loop before adding polish.
5. Keep scene names and script names consistent.
6. After editing, run Godot headless checks if available.
7. Fix parser errors before adding features.

The key is that these instructions are persistent and reusable. You are not relying on the user to remember every Godot-specific constraint in each prompt.

A practical Godot project layout for AI-generated games

AI assistants work better when the project has a boring, predictable layout. For Godot, that is a feature, not a limitation.

A simple structure might look like this:

res://
  project.godot
  scenes/
    Main.tscn
    Player.tscn
    Enemy.tscn
    Bullet.tscn
    UI.tscn
  scripts/
    main.gd
    player.gd
    enemy.gd
    bullet.gd
    game_state.gd
  assets/
    sprites/
    audio/
    fonts/
  resources/
    enemy_stats.tres

For small generated games, resist the urge to over-engineer. The first target should be a playable vertical slice:

• A controllable player
• One enemy or obstacle
• A win/loss condition
• UI feedback
• Restart behavior

Once that loop exists, the model can safely add levels, upgrades, effects, and menus.

Example: a minimal Godot player controller

One useful thing to put in a skill is canonical code examples. The model can adapt them, but the examples anchor syntax and style.

For Godot 4.x, a simple 2D movement script might be:

extends CharacterBody2D

@export var speed: float = 220.0

func _physics_process(_delta: float) -> void:
    var direction := Vector2.ZERO

    direction.x = Input.get_action_strength("move_right") - Input.get_action_strength("move_left")
    direction.y = Input.get_action_strength("move_down") - Input.get_action_strength("move_up")

    if direction.length() > 1.0:
        direction = direction.normalized()

    velocity = direction * speed
    move_and_slide()

The important part is not just the script. The assistant also needs to ensure that the input actions exist. In Godot’s project.godot, that means configuring actions such as move_up, move_down, move_left, and move_right.

An AI coding skill should explicitly say:

If a script uses Input actions, verify those actions exist in project.godot.
Do not invent action names without adding them to the input map.

That single instruction prevents a surprisingly common failure mode.

Scene generation: where LLMs need guardrails

Godot scene files are text-based, which makes them AI-editable. But they are also easy to corrupt.

For example, a basic scene file has resource IDs, node paths, and references that must line up:

[gd_scene load_steps=2 format=3]

[ext_resource type="Script" path="res://scripts/player.gd" id="1_player"]

[node name="Player" type="CharacterBody2D"]
script = ExtResource("1_player")

[node name="CollisionShape2D" type="CollisionShape2D" parent="."]

An assistant can generate this, but a robust workflow should prefer one of three strategies:

For a Claude Code-style workflow, direct .tscn generation is acceptable for small games, but validation is mandatory. If you can run Godot headlessly, do it.

Example commands:

godot --headless --path . --check-only

Depending on your Godot version and environment, you may need alternative commands, but the principle is the same: make the model prove the project parses.

Add a validation loop to the skill

The difference between a demo prompt and a useful development tool is the feedback loop.

A good Godot skill should tell the coding agent:

After creating or modifying the game:

1. Run a syntax or import check if Godot is available.
2. If errors appear, fix only the errors first.
3. Do not add new features while parser errors exist.
4. Summarize what was changed and how to run the game.

This keeps the agent from spiraling. Without that constraint, models often respond to an error by rewriting large parts of the project, which can introduce new problems.

For scripts, you can also add lightweight checks:

find scripts -name "*.gd" -print

Then inspect the files for common Godot 3 vs Godot 4 mistakes:

• KinematicBody2D instead of CharacterBody2D
• move_and_slide(velocity) instead of Godot 4’s move_and_slide()
• Old signal connection syntax
• Missing @export
• Invalid typed variable inference

Building with Claude, GPT, and Gemini APIs

The same technique applies whether you are using Claude Code interactively or building your own game-generation backend with APIs.

A production system might use multiple models for different stages:

This is where multi-model gateways can be useful. If you are experimenting heavily, API cost adds up quickly because agentic coding involves many turns: planning, file reads, edits, checks, and fixes. AI Prime Tech can be a practical option for cheaper Claude API access alongside GPT and Gemini models, especially when you want to route different parts of the workflow to different models without integrating every provider separately.

The important architectural idea is model routing. You do not need the most expensive model for every step.

For example:

• Use Haiku 4.5 to classify errors.
• Use Sonnet 4.6 to patch GDScript.
• Use Fable 5 when you need to ingest an entire existing Godot project.
• Use Opus 4.8 to resolve ambiguous architecture or gameplay design issues.
• Use Gemini 3 or GPT-5.5 as a second reviewer for generated code.

A simple API-oriented workflow

If you were implementing your own “generate a Godot game” service, the loop could look like this:

User prompt
  ↓
Design model creates game spec
  ↓
Code model creates file plan
  ↓
Tool layer writes project files
  ↓
Godot headless validation runs
  ↓
Error logs go back to code model
  ↓
Repeat until runnable or budget exhausted

The most important rule: never let the model pretend it wrote or tested files. Your tool layer should own file I/O and command execution.

A simplified pseudo-implementation:

def build_game(prompt: str):
    spec = call_model(
        model="claude-opus-4.8",
        system="Create a concise Godot 4 game specification.",
        user=prompt,
    )

    plan = call_model(
        model="claude-sonnet-4.6",
        system="Convert the spec into a file-by-file Godot implementation plan.",
        user=spec,
    )

    apply_file_plan(plan)

    for attempt in range(5):
        result = run_command("godot --headless --path . --check-only")

        if result.ok:
            return "Game generated successfully"

        patch = call_model(
            model="claude-sonnet-4.6",
            system="Fix the Godot project errors. Return only file edits.",
            user=f"Errors:\n{result.stderr}\n\nProject summary:\n{summarize_files()}",
        )

        apply_file_plan(patch)

    return "Stopped after validation budget was exhausted"

In a real system, you would want structured outputs rather than free-form patches. For example, ask the model to return JSON operations:

[
  {
    "path": "scripts/player.gd",
    "operation": "replace",
    "content": "extends CharacterBody2D\n..."
  }
]

Then validate paths, reject writes outside the project directory, and run checks before accepting the result.

Best practices for AI-generated Godot games

Keep the first version tiny

Ask for “complete but small,” not “massive and impressive.” A polished Breakout clone is a better target than an unfinished open-world RPG.

Good first-game prompts:

• “Make a one-screen asteroid dodging game.”
• “Create a top-down arena shooter with one enemy type.”
• “Build a Sokoban-style puzzle with three levels.”
• “Make a clicker game with upgrades and save/load.”

Bad first-game prompts:

• “Make a full Stardew Valley clone.”
• “Build a multiplayer MMO.”
• “Create a realistic 3D survival game.”

Separate mechanics from content

Have the model implement systems first, then add content. For example:

1. Movement
2. Collision
3. Scoring
4. Enemy spawning
5. UI
6. Levels
7. Juice and polish

This makes validation easier and reduces cross-file churn.

Prefer deterministic assets early

Generated art and audio can come later. For the first pass, use:

• ColorRect
• Polygon2D
• Basic shapes
• Placeholder fonts
• Simple procedural sounds if needed

The game should be fun before it is pretty.

Make bugs observable

Tell the agent to add debug-friendly structure:

func die() -> void:
    print("Player died")
    get_tree().reload_current_scene()

Temporary logging is valuable during generation. You can remove it later.

Trade-offs and limitations

This technique is powerful, but it is not magic.

The main trade-offs:

• Generated games can be generic. You still need taste and direction.
• Scene files are fragile. Automated validation is essential.
• Large rewrites are risky. Prefer small patches.
• Model context matters. Bigger projects require stronger retrieval or long-context models.
• Engine version drift hurts. Always specify Godot 4.x or your exact version.
• Playability is hard to judge automatically. A project can compile and still be boring.

The best results come from treating the model as a tireless junior developer with excellent recall, not as a complete replacement for design judgment.

The bigger lesson

The Godot game-generation idea is a great example of where AI coding is heading. The winning pattern is not a single super-prompt. It is a domain-specific agent workflow with:

• Persistent skills
• Clear project conventions
• Tool-driven file edits
• Automated validation
• Iterative repair
• Sensible model routing

For developers, that means the opportunity is broader than Godot. You can build similar skills for Unity, Unreal, browser games, data apps, internal tools, or API services.

Godot just makes the pattern especially visible because the output is tangible: you can press Play and immediately know whether the agent built something real.