Claude Code Game Studios: What 49 Agents and 74 Skills Add to Claude Code, According to the Repo

Claude Code Game Studios is a template repo that sets up Claude Code game studio agents: 49 role-based subagents, 74 skills, and hooks and rules that impose a production process on a single Claude Code session. Under the hood it uses Claude Code's standard subagent and skill features. The new parts are the ready-made roles, the order of the workflow, a configurable rigor setting and a rule that visual changes need screenshot evidence. The maker's own measurement points to the lightest setting as the right default.

This note reads the README alongside the Claude Code documentation. The goal is to separate the parts that add something from the parts that only add labels.

What is Claude Code Game Studios?

It is an MIT-licensed GitHub repository by Donchitos. You clone it as the starting point of a project. It is not a plugin and it is not a game. The README says it will "turn a single Claude Code session into a full game development studio."

The counts depend on which part of the repo page you read:

• The repo description says 72 workflow skills.
• The README headline, badges and slash-command section say 74 skills.

This post uses the README's 74 as the current number. The description has probably not been updated.

Other README figures: 49 agents, 12 hooks (14 scripts once you count a helper and one opt-in diagnostic), 13 path-scoped rules and 39 document templates.

The README's "Why This Exists" section explains the problem it targets. A single chat session has no structure. Nothing gives you a design review or a QA pass, and nothing stops you from hardcoding magic numbers.

How are the 49 agents organized?

The README splits the agents into three tiers:

1. Directors: creative-director, technical-director, producer.
2. Department leads: game-designer, lead-programmer, art-director, audio-director, narrative-director, qa-lead, release-manager, localization-lead.
3. Specialists: gameplay-programmer, systems-designer, qa-tester, security-engineer and others.

Each agent is a markdown file with YAML frontmatter in .claude/agents. That is the standard Claude Code format.

Do all the agents run on Opus?

No. The README says the three directors request Opus, sixteen specialists name Sonnet or Haiku, and the other thirty "inherit your session's model." It also says to treat the tiers "as seniority of role, not as a billing plan." In practice, most of the studio runs on whatever model your session already uses.

Engine coverage

The README lists one agent set per engine:

You use the set that matches your engine. For more engine-specific coverage, see the Godot, Unity and Unreal tag pages.

What does stock Claude Code already give you?

This is the key question for any "studio" template. According to the Claude Code docs on creating custom subagents:

• Each subagent runs in its own context window, with a custom system prompt, its own tool access and separate permissions.
• Claude reads each subagent's description to decide when to hand work to it.
• A subagent uses the main conversation's model unless one is set.

The skills documentation says slash commands are built as skills, stored as SKILL.md files under .claude/skills.

So every agent and command in this repo uses features Claude Code already has. The repo gives Claude Code no new abilities. Its value lies in the written role prompts, the order of the workflow and the configuration. Whether that is worth adopting depends on whether you want someone else's process or would rather write a shorter one yourself.

The tier names are partly role-play. Calling an agent "creative-director" does not give it authority. It gets a system prompt, a description Claude uses for routing, and in three cases a request for a stronger model. If you share the CLAUDE.md approach in our Claude Code setup guide for game development, many of these roles may duplicate instructions you already have.

What do the 74 skills and rigor modes do?

The README groups the skills by workflow stage:

• Onboarding: /start, /setup-engine, /adopt, /settings
• Design: /brainstorm, /map-systems, /design-system, /review-all-gdds
• Architecture: /create-architecture, /architecture-decision
• Stories and sprints: /create-epics, /dev-story, /sprint-plan, /story-done
• Reviews: /code-review, /balance-check, /gate-check, /security-audit
• QA: /qa-plan, /smoke-check, /soak-test, /regression-suite
• Release: /release-checklist, /changelog, /hotfix
• Team orchestration: nine /team-* commands (combat, narrative, UI, release, polish, audio, level, live-ops, QA) that coordinate several agents on one feature

The rigor setting

According to the README's configuration section, project.yaml stores the engine, your conventions and a modes block. The main control is modes.rigor:

modes:
  rigor: minimal   # minimal (default) | standard | full

The README says rigor sets six underlying knobs. Two examples are review_mode (full, lean or solo) and team.size. Other documented controls:

• system_overrides makes one system, such as combat, stricter than the rest.
• testing.strict decides whether missing test evidence blocks a story or only produces a warning.
• /settings reads and writes these values.
• A gitignored project.local.yaml holds personal overrides.

Of everything in the repo, this layer goes furthest beyond a folder of prompts. It lets one setting change how much process the agents apply.

Does it produce games, or just documents?

The README asks this question itself and answers with a measurement instead of a sample project. Four games were built from one brief at different modes.rigor levels. For each build, the maker counted the documents written "before its first line of game code."

The table in the README shows:

The maker reports that every build produced a running, tested game. Two blind reviewers and a human playtest ranked the standard build last. According to the README, the 29 extra documents bought traceability but not a better game. The README also says the heavier tier cost several times more to reach working code. It says it gave no measurable benefit when a new developer took over the project. That result is why minimal is the default.

This is a candid result to put in a README, and it cuts against the template's main feature. Some caveats apply:

• The maker ran and reported the measurement. No independent reproduction could be found.
• The text mentions four builds, but the table shows two rows.
• None of the games is a shipped product, and one brief is a small sample.

Read it as an unverified claim, not a benchmark. Even so, the direction is useful. By the maker's own account, more process meant more paperwork, not a better game.

What do the hooks, rules and evidence gate add?

The guardrails are where the repo goes past role prompts.

Hooks. According to the README, hooks run validation on commits, pushes, asset changes and session start and end. They also keep an audit trail of agent activity and run gap detection. The README recommends jq and Python 3 and says hooks fail gracefully without them. That means a missing dependency switches validation off silently. Check that both are installed before you rely on the hooks.

Path-scoped rules. The 13 rules apply coding standards when you edit gameplay, engine, AI, UI or network code. They only load when you work in the relevant folders.

The evidence gate. This is the most distinctive idea in the repo. The README says a story that changes what the player sees cannot be closed until the game has been launched, the change observed and a screenshot saved to production/qa/evidence/. It says this applies at every rigor level, including minimal.

This matches a broader pattern. The Claude Code skills docs describe recording verification steps for running an app as a skill. Our game legibility guide makes the same point: an agent that cannot see the game cannot say whether a visual change worked. The evidence gate turns that idea into a rule that blocks a story from closing.

Who is it for, and who should skip it?

Likely fits: solo developers on Godot, Unity or Unreal who want a ready-made production structure. That includes GDDs, architecture decision records, sprint tracking and QA evidence folders. It also fits people who want to see how a full multi-agent setup is organized before building their own.

Likely poor fits: game jam builders who care most about speed, and anyone who already keeps a tight CLAUDE.md. The maker's own default is the lightest mode. Our note on Claude Code's /doctor prompt audit covers keeping instructions lean, which pulls the other way from a 49-agent setup.

What the sources don't answer:

• How many tokens, or how much subscription usage, multi-agent runs and /team-* commands consume.
• How well the 30 agents that inherit the session model perform on a cheaper model.
• Whether the director agents catch real design problems or just add review steps.

No independent reviews could be found, and this publication has not verified the README's claims.

Setup per the README

1. Clone the repository as the start of your project.
2. Run claude in the project folder.
3. Run /start.
4. Optionally, set your engine, for example /setup-engine godot 4.6.
5. For existing projects, the README lists /adopt under onboarding.

The README does not cover connecting Claude Code to a running editor. For that, see our guides to Unity MCP setup and the godot-ai MCP server. For a lighter, engine-vendor option, see Unity's official Claude Code plugin.

Verdict

Read against the Claude Code docs, Claude Code Game Studios is a well-organized set of prompts and configuration on top of standard features. The useful parts are the rigor setting, the path-scoped rules and the screenshot evidence gate. The 49-role hierarchy is mostly naming. The maker's own data suggests that heavy process does not improve the game. If you use it, start at minimal and take the evidence gate seriously. If you already keep a tight CLAUDE.md, copying the evidence-gate idea into your own setup may be enough.