Claude Code Game Studios: Turn Your AI Into a 49-Agent Game Studio

Building a game solo with AI is powerful, but a single chat session has no structure. Nothing stops you from hardcoding magic numbers, skipping design documents, or writing spaghetti code. There is no QA pass, no design review, and no one asking whether a feature actually fits the game's vision.

Claude Code Game Studios fixes that by giving your AI session the structure of a real studio. Instead of one general-purpose assistant, you get 49 specialized agents, 74 slash-command skills, 15 automated hooks, 14 path-scoped coding rules, and 62 document templates. It is built for Claude Code, licensed under MIT, and the repository had 31,734 stars and 4,336 forks when we checked on November 1, 2026.

The key idea: you still make every decision, but now you have a team that asks the right questions, catches mistakes early, and keeps the project organized from first brainstorm to launch. It is a template you clone to start your own project, not a game itself. Somebody else's game in your repo would be clutter, not evidence, so no sample games ship with it.

The 49 agents are organized into three tiers, matching how real studios operate. Tier 1 is the directors: creative-director, technical-director, and producer. Tier 2 is the department leads: game-designer, lead-programmer, art-director, audio-director, narrative-director, qa-lead, release-manager, and localization-lead. Tier 3 is the specialists: gameplay, engine, AI, network, tools, and UI programmers, systems, level, and economy designers, technical artists, sound designers, writers, world-builders, UX designers, prototypers, performance analysts, and more.

Each agent declares a model in its frontmatter. The three directors ask for Opus, the lead-programmer and fifteen specialists name Sonnet, and the remaining thirty inherit your session's model. Treat the tiers as seniority of role, not a billing plan: most of the studio runs on whatever model you are already using.

The template also includes agent sets for all three major engines. Use the set that matches your project: a Godot 4 specialist covering GDScript, shaders, and GDExtension; a Unity specialist covering DOTS/ECS, shaders and VFX, Addressables, and UI Toolkit; or an Unreal Engine 5 specialist covering GAS, Blueprints, replication, and UMG/CommonUI.

Everything runs through slash commands in Claude Code. Run /start and the system asks where you are, no idea, vague concept, clear design, or existing work, and guides you to the right workflow. From there, /brainstorm explores ideas, /setup-engine configures your engine, /design-system and /map-systems shape the game, /create-epics and /create-stories break work into stories, and /dev-story and /story-done carry each story through implementation.

Around that spine sit the phases a real studio runs: art bibles and asset specs, UX design and review, architecture decisions and reviews, design and code reviews, balance checks, scope checks, performance profiles, and tech-debt passes. QA gets its own battery: QA plans, smoke checks, soak tests, regression suites, and test-evidence reviews. Production covers milestone reviews, retrospectives, bug triage, and playtest reports, and release covers checklists, changelogs, patch notes, hotfixes, and day-one patches.

Team commands coordinate several agents on one feature: /team-combat, /team-narrative, /team-ui, /team-release, /team-polish, /team-audio, /team-level, /team-live-ops, and /team-qa. Delegation follows a clear model: directors delegate to leads, leads delegate to specialists, same-tier agents can consult each other but cannot make binding cross-domain decisions, and disagreements escalate to the shared parent, creative-director for design, technical-director for technical matters, with the producer coordinating cross-department changes.

One setting controls how much process every skill enforces: modes.rigor in project.yaml, with three levels, minimal, standard, and full. It is a single front door over six knobs: which game design document sections are required, doc density, QA level, story granularity, review mode, and team size. /start asks it once instead of six times.

Minimal is the default, and the project is refreshingly honest about why. Four games were built from one brief at different rigor levels, and the documents each wrote before its first line of game code were counted: minimal wrote 1, the one-page brief, and standard wrote 30 over 58 minutes. All of them produced a running, tested game, and two blind reviewers plus a human playtest ranked the standard build last. The extra 29 documents bought traceability, not a better game.

Standard requires 5 game design document sections with balanced doc depth and lean review. Full requires all 8 sections, thorough docs, full QA evidence on every story type, and full director review. Raise it in one /settings call when your project grows, and /help and /gate-check will suggest it when they see the signs. Two escape hatches keep it from being blunt: system_overrides holds one system to a higher standard than the rest, so your combat system gets the full treatment while everything else stays light, and testing.strict sets per test type whether missing evidence blocks a story or merely warns.

Fifteen hooks run automatically on every session. Commit validation checks for hardcoded values, TODO format, JSON validity, and design-doc sections. Push validation warns on pushes to protected branches and on tags, merges, releases, and store uploads. Read validation refuses a whole-file read of a design doc over 40 KB and answers with its headings, so the retry reads one section. Write validation warns, never blocks, when a write would break a stated rule, and asset validation checks data-file JSON and naming.

Session hooks show the current branch and recent commits on open, detect fresh projects and suggest /start, log compactions, archive session logs, and keep an audit trail of every subagent invocation, including a warning when a subagent stops without writing the file its brief named. Permission rules auto-allow test runs and block dangerous operations like force push, rm -rf, and reading .env files.

Coding standards are enforced by file location: gameplay code must be data-driven and use delta time, core code must avoid allocations in hot paths, networking must be server-authoritative with versioned messages, UI code must not own game state and must be localization-ready, and tests follow naming and coverage rules. And there is one rule that matters more than any test: a story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained as evidence. A passing test says nothing about a menu drawn off-screen.

You need Git, Claude Code, Python 3, and Bash. Python reads project.yaml for every skill and hook, so without it every setting silently falls back to its default. The jq tool is recommended for hook validation. Hooks fail gracefully if optional tools are missing, with one deliberate exception: a commit that stages data JSON is blocked when there is no Python to validate it.

Clone the template and open Claude Code in the project root, the folder holding CLAUDE.md and project.yaml. Starting in a subfolder like src/ skips the project's hooks, deny rules, and ask-first permission mode. Then run /start. If you already know what you need, jump straight there: /brainstorm for ideas from scratch, /setup-engine godot 4.7 to configure your engine, or /project-stage-detect to analyze an existing project.

A good first test is a small game at minimal rigor: brainstorm a one-page brief, create stories, and run one story end to end. Watch for the sequence the studio promises: questions before solutions, options with pros and cons, your decision, a draft shown before finalizing, and approval before anything is written. If your agent skips straight to code, the install is not active, and starting from the project root usually fixes it.

This is collaborative, not autonomous, by design. Every agent follows an ask, present options, you decide, draft, approve protocol, and nothing gets written without your sign-off. The guided and autonomous automation settings trade some of those prompts for speed, but out of the box you are the decision-maker at every step. If you want an autopilot that builds a game while you watch, this is not it.

It also costs more than a single chat session. Directors on Opus, sub-agents per story, reviews between tasks, and QA evidence all add up, which is another reason minimal rigor is the default. And because it is a template you are meant to edit, the project ships studio-tests, a way to check that an edited or newly written skill still holds up, with structural linting, category rubrics, behavioral specs, and coverage audits. It tests the framework, never your game.

Finally, remember what you are cloning: a process, not a product. There is no game to play in the repo, and that is deliberate. The value is the studio structure itself, and whether it helps you ship depends on whether you wanted that structure in the first place. For a game jam, minimal rigor keeps it out of your way. For a project you plan to finish, the directors, leads, and specialists are there to keep it organized all the way to launch.