Freakling/Godot-Director

**Make the game you designed, with AI doing the building and you staying the director.**
A workflow for Godot projects, new or already in development. You decide the design, the balance and the priorities. The AI builds, tests and keeps the records. Designed to work with any AI coding assistant that reads AGENTS.md. Built and tested on Claude Code; other assistants are untested. Everything lives in your game's own git repository.
Part of Director-Driven Development
This is one of three frameworks built on Director-Driven Development, a way of working with AI coding agents: you direct the design, agents build in small, fresh contexts, and the build verifies every change. The same loop runs all three; only the rules the check enforces change.
- Godot-Director: games in Godot 4 (this one)
- App-Director: small web, mobile and desktop apps
- SaaSAllTheThings: B2B SaaS on Azure
Why
AI writes game code fast. Without structure, that speed goes wrong in familiar ways:
- **The design drifts.** The AI quietly decides a mechanic or a number you never agreed to. With Godot Director, design calls come to you as 2-4 options with a recommendation. Only your choice is written down, and anything undecided goes on an open-questions list instead of being guessed.
- **"Done" means "it compiled".** One check defines "works": the whole project loads and the tests pass. It runs before every commit that touches code, and in Claude Code also before the AI ends its turn.
- **Rules end up inside UI screens.** Game rules live in testable classes and screens only display them. The check fails when a screen rolls dice or writes game state.
- **Context gets lost between sessions.** A few plain files hold everything: the design document, a decision log, the task queue, and an architecture table. Each fact has one home, so any session picks up where the last one stopped.
How to use it
> You've read this far, so Godot Director may be what you're looking for. It's free and open source, and if it helps you make your game, a tip on Ko-fi or GitHub Sponsors helps me keep building it. I greatly appreciate your support.
>
>
Install
Your game needs git (git init if it has none) and no uncommitted changes. You also need Godot 4.3 or newer, and bash (on Windows it comes with Git for Windows).
**Option 1: the skill.** In your game's folder, run:
That installs the skill for the assistant you choose in the prompt. In Claude Code it becomes a /godot-director command. The skill fetches the latest Godot Director release outside your game and runs onboarding.
**Option 2: the Claude Code plugin.** In Claude Code:
The plugin installs the latest release. Then open a new Claude Code session in your game's folder (or run /reload-plugins), and run /godot-director:godot-director.
**Option 3: manual install.** Put the latest release in your game's root folder, next to project.godot, as a folder named Godot-Director. The release's tag is v followed by its version number, and the Releases page shows the latest one. Either run git clone --branch --depth 1 https://github.com/Freakling/Godot-Director.git Godot-Director there, replacing with it, or download that release's source zip from the Releases page and rename the extracted folder. Then ask your assistant:
> Read Godot-Director/ONBOARDING.md and follow it to install Godot Director into this project.
Either way, onboarding works out whether this is a new game, an existing game, a Godot Director 1.x project to migrate, or an upgrade. It then:
1. installs the files and finds your Godot;
2. interviews you (new game) or reads the existing game;
3. agrees with you who owns what;
4. ends with one commit for you to approve.
Afterwards, restart Claude Code so the new commands load. Each new clone of the game later needs one command: bash tools/setup-clone.sh.
**With another AI assistant:** tell onboarding, and it installs the tool-neutral core only (--tools none); you can also keep the Claude adapter alongside. Your assistant reads AGENTS.md, which points it to .godot-director/rules.md and the procedures. The core is tool-neutral: rules, procedures, the check and the git pre-commit hook work the same everywhere. Fresh-context builds, the reviewer, model sizing and the hooks that block risky commands depend on your assistant supporting subagents and hooks.