Claude Code Game Studios

A repository that contains almost no program and a great deal of instruction. It turns one Claude Code session into something shaped like a game studio: forty-nine agent definitions covering creative and technical direction, production, art, audio, narrative, engineering, QA, release, security and live operations, alongside engine specialists for Godot, Unity and Unreal; around seventy skills; fourteen shell hooks that validate commits, pushes, assets and skill changes; thirteen rule files; and roughly forty document templates from a game brief to a post-mortem. It installs by cloning or as a Claude Code plugin.

Who built itThe author of all forty-one commits, every one attached to a linked account, and the only name GitHub credits as a contributor. The pull-request queue carries submissions from several other people and the release notes thank them by handle, so the contributor graph and the traffic understate each other in opposite directions.

1. 01

   Twenty-five thousand stars and forty-one commits

   The ratio is the first thing worth recording. Twenty-five thousand five hundred stars, three thousand six hundred forks, a hundred and eighty-four watchers, and forty-one commits. For an application that would be absurd; here it is accurate, because the artifact is not code. Thirty-nine of those forty-one commits carry a co-author trailer naming a model — ninety-five per cent, the highest proportion this archive has seen, against seventy-one for gate4agent and sixty-six for CodeGraph — and the mixture is led by Claude Sonnet 4.6 on thirty, with Opus 4.6 on six and single appearances by Opus 5 and Opus 5.5. Eight releases in seven months have names that read like a changelog sentence rather than a version: the first public release, then context resilience and systems decomposition, then a design-system and map-systems release, then the plugin-era releases, ending with one that says the default path works end to end.

2. 02

   A studio org chart, written as files

   The repository is a .claude/ directory with a shape. Forty-nine agent definitions, four to eighteen kilobytes each, named for roles rather than functions: creative director, technical director, producer, art director, audio director, narrative director, lead programmer, engine, gameplay, network, tools and UI programmers, QA lead and tester, release manager, security engineer, live-ops designer, localization lead, economy designer, level designer, world builder, writer, sound designer, performance analyst, prototyper, community manager, accessibility specialist, analytics engineer. Engine expertise is split further — five Godot specialists including one each for GDScript, C# and GDExtension, five Unity specialists including DOTS, Addressables and shaders, and four Unreal specialists plus separate agents for Blueprints, GAS, replication and UMG. Around them sit thirteen rule files, fourteen shell hooks, ten scripts, a twenty-two-kilobyte workflow catalogue and roughly forty document templates that run from a game brief and a pitch document through a game design document, an art bible, a sound bible, an economy model, a difficulty curve, a UX specification and a player journey, to a release checklist, a test plan and a post-mortem. The largest single document is a hundred and thirty-eight kilobyte effects map.

3. 03

   The numbers keep drifting, and the pull requests are about that

   A configuration this size has an inventory problem, and the tracker is unusually honest about it. One pull request corrects the README, which advertised forty-one templates while the directory held forty, and in the same breath records that the other counts in the table — agents forty-nine, skills seventy-three, hooks twelve, rules eleven — were checked and were accurate. Another raises the two documents still carrying the count from before the newest agent landed, moving forty-eight subagents to forty-nine and sixty-eight slash commands to seventy-two, with the verification stated as the commands that produced it: list the agent files and count, list the skill directories and count. A third finds that the agent test specifications and the model-tier table had drifted from what the agent files actually declare, and prints a table of the disagreements. The pattern is not that the numbers were wrong; it is that a project made of prose keeps needing to be reconciled with a project made of files, and the pull requests do the reconciling in public. The discrepancy is still there at the top: the repository description says seventy-two workflow skills and the README says seventy-four.

4. 04

   One line in sixty-six files broke the whole thing

   The sharpest incident in the history is a release that had to be repaired two days later. Version 1.1.0 added a configuration line to sixty-six skills — a shell substitution that sources a helper script and resolves a config key at render time. Claude Code permission-checks every injected command in a skill before the skill renders, and outside auto mode that line fails the check as containing an expansion, with no grant able to approve it. The consequences were not subtle: all sixty-six skills aborted silently before doing anything, in one mode the thirty-one without a shell grant failed from the root as well, and two agents — the game designer and the creative director — could not launch at all because they preload those skills. Version 1.1.1 is named for the fix. The lesson is stated in the pull request rather than implied: building on another product’s extension points means that product’s permission model is part of your architecture, and a mechanism that is safe in one mode can be unusable in another.

5. 05

   Hooks that can refuse a commit

   Fourteen shell hooks run around the session rather than inside it — one at session start and one at session stop, one before and one after context compaction, two that log agent activity, one that detects gaps, one that validates assets, one that validates skill changes, and two that gate the git operations: a commit validator and a push validator. Their sizes are the tell. The commit validator is thirty-eight kilobytes of shell; a YAML helper shared by the skills is sixty-eight kilobytes; the asset validator is eight; the push validator is ten. There are also scripts for architecture decision graphs, artefact checking, game-design-document structure, project coherence, review receipts, review scope, session-state rotation and story status, plus a migration script for the configuration format. A pull-request checklist tells contributors what the hooks expect of them: use POSIX grep, fail gracefully when neither jq nor python is present, hardcode no paths, assume no platform.

6. 06

   Two sessions, one on high and one on xhigh

   One contribution describes its own method in two sentences: the upgrade was done with two model sessions, the first on high effort producing the initial work and the second on extra-high effort doing the review and smoothing inconsistencies. Effort level used as a review protocol is a small thing, but it is a deliberate answer to the problem every one of these projects has — the same model both writes and approves unless you change something. A later contribution adding an asset-generation skill states its constraints with similar precision: the helper validates the live model catalogue rather than assuming it, never retries a generation request, bounds how long it polls, keeps every output inside the project directory, and asks before each request that costs money. A repository that automates a studio is unusually careful about what it lets the automation spend.

7. 07

   The packaging changed and the instructions did not

   The plugin-era release is the most architectural change after launch. The plugin manifest points at the existing agent, skill and hook directories rather than moving them, so the clone workflow keeps working, and a marketplace file publishes the whole thing under a short name. The interesting part is the part a plugin cannot ship: a project needs a CLAUDE.md, its own rules, its own document tree and an engine reference. Rather than leaving that as an upgrade conflict, the maintainer added an initialisation skill that scaffolds the project side, and the pull request says outright that this removes the merge-conflict-on-upgrade problem the previous upgrade guide existed to work around. A configuration distributed as a plugin gains a clean upgrade path only by separating what belongs to the tool from what belongs to the project.

8. 08

   One name in the contributor list, several in the queue

   Fifty-six issues are open. The repository page lists two contributors: the maintainer, and Claude — the co-author trailers earned a model a place on the contributor list, while the API’s own contributors endpoint returns only the human. The pull-request queue meanwhile holds submissions from several other people and the release notes thank them by handle, so work is arriving from outside and landing under the maintainer’s name. Some of the most careful writing in the repository is in that queue and not in the code: the release-blocking line of shell, the drift audit, the checklist that codifies what a contribution must prove. That is the honest shape of a document-heavy open-source project — more proposals than merges, more surface than program, and a maintainer who is the only one who can approve anything.