Donchitos

Claude Code Game Studios: Turn Your AI Into a 49-Agent Game Studio --- title: "Claude Code Game Studios: Turn Your AI Into a 49-Agent Game Studio" published: true tags: opensource, aicoding, gamedevelopment, claudecode canonical_url: devpik.com --- Claude Code Game Studios turns a single Claude Code session into a full game development studio. It gives you 49 specialized AI agents organized like a real studio, directors who guard the vision, department leads who own their domains, and specialists who do the hands-on work, plus 74 workflow skills and automated checks. It has 31,734 stars and works with Godot, Unity, and Unreal Engine. What Is Claude Code Game Studios? 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. A Studio Hierarchy, Not a Single Chatbot 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. The Workflow: From /start to Launch 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. How Much Process? The Rigor Setting 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. Guardrails That Run Themselves 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. How to Try It 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. What to Watch Out For 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. FAQs What is Claude Code Game Studios? A template that turns one Claude Code session into a full game development studio: 49 specialized AI agents in a director, lead, and specialist hierarchy, 74 slash-command skills, 15 automated hooks, 14 coding rules, and 62 document templates. It is open source under MIT and had 31,734 stars in November 2026. Which game engines does it support? Godot 4, Unity, and Unreal Engine 5, each with its own specialist agent set: GDScript, shaders, and GDExtension for Godot; DOTS/ECS, shaders and VFX, Addressables, and UI Toolkit for Unity; and GAS, Blueprints, replication, and UMG/CommonUI for Unreal. How do I start a game with it? Clone the repo, open Claude Code in the project root (the folder holding CLAUDE.md and project.yaml), and run /start. It asks where you are, no idea, vague concept, clear design, or existing work, and guides you to the right workflow. What is modes.rigor? One setting in project.yaml that controls how much process every skill enforces: minimal (jam-game speed, no design docs required), standard (5 required design-doc sections), or full (all 8 sections, full QA evidence, full director review). Minimal is the default, because the project's own measurement found heavier process bought traceability, not a better game. Does it build the game by itself? No. It is collaborative, not autonomous. Agents ask questions before proposing solutions, present 2 to 4 options with pros and cons, and nothing gets written without your approval. You make every decision; the agents provide structure and expertise. Does the repo include a playable game? No, deliberately. It is a template you clone to start your own project, and somebody else's game in your repo would be clutter, not evidence. The value is the studio structure: agents, skills, hooks, rules, and templates. What do I need installed? Git, Claude Code, Python 3, and Bash. Python reads project.yaml for every skill and hook, so without it settings silently fall back to defaults. The jq tool is recommended for hook validation. Is Claude Code Game Studios free? Yes. It is open source under the MIT license. The maintainer accepts voluntary support through Buy Me a Coffee and GitHub Sponsors. --- Originally published at devpik.com. Repo: Donchitos/Claude-Code-Game-Studios.

@oleg_thrasher Ну так там обвязок куча, про разные движки и задачи. Как пример Donchitos/Claude-Code-Game-Studios

Turn one Claude Code session into a game studio with 49 agents A solo game project in a single Claude Code chat tends to drift. Nothing stops you from hardcoding magic numbers, skipping the design doc, or shipping spaghetti, because no one plays QA or asks whether a feature fits the game's vision. Donchitos/Claude-Code-Game-Studios gives one Claude Code session the structure of a studio. The README lists 49 agents, 74 skills (slash commands), 15 hooks, 14 path-scoped rules and 62 document templates. You still make every decision, but a team of specialist agents asks questions and flags mistakes along the way. How the studio is organized Agents sit in three tiers, like a real studio: - Directors: creative-director, technical-director, producer. - Department leads: game-designer, lead-programmer, art-director, audio-director, narrative-director, qa-lead, release-manager, localization-lead. - Specialists: gameplay-programmer, engine-programmer, ui-programmer, level-designer, sound-designer, qa-tester and more. Each agent declares its model in its frontmatter. The directors ask for Opus, so expect heavier usage on the big decisions. Prerequisites From the README: Git, Claude Code, Python 3 and Bash. The README recommends jq as well. Python matters more than it looks, because it reads project.yaml for every skill and hook. Without it every setting silently falls back to its default. On macOS and Linux Bash is built in, and on Windows it comes with Git for Windows. Claude Code itself can be installed with the native installer, or with this command on Node.js 22 or newer: npm install -g @anthropic-ai/claude-code Setup Clone the repo as your new game folder: git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game cd my-game Then start Claude Code from the project root, the folder that holds CLAUDE.md and project.yaml: claude Do not start it in a subfolder such as src/. The README warns that this skips the project's hooks. Your first session The skill list names the workflow phases: /start, /design-system, /create-epics, /create-stories, /dev-story and /story-done. A sensible first pass: 1. Run /start and answer the questions about the game you want to make. 2. Use /design-system to write a design document for one mechanic before any code exists. 3. Break the work down with /create-epics and /create-stories. 4. Implement one story with /dev-story, then close it with /story-done. The path-scoped rules apply while you edit gameplay, engine, AI, UI and network code, so standards are enforced where they matter. Hooks validate commits, pushes and asset changes. Does it produce games, or documents? The README has a section with this exact question, and it is worth reading before you commit a weekend to it. The templates cover GDDs, ADRs, sprint plans and HUD design, so a large part of what you get is structure and documentation around the code you and Claude write together. Where it fits - You are building a game alone and want review gates without hiring anyone. - You already use Claude Code and want conventions it follows every session. - You want a tested hierarchy to copy for non-game projects, by editing the agents and rules. Our full write-up with more detail is on the Claude Code Game Studios use case page. If you are choosing among agent kits, the use cases for Claude Code itself are a good baseline. Caveats - Fifteen hooks run bash on your machine. Read them in .claude/ before you trust them. - The hierarchy can burn tokens quickly, since many agents may be invoked per task. - This walkthrough follows the README and has not been run end to end by us. Source repo: Donchitos/Claude-Code-Game-Studios. Want the setup commands for 50 AI repos people actually ship with? Get the free AI Repos That Actually Ship pack: dedupedai.com --- Get one email every Monday with the week's hottest AI repos and exactly how to use them: subscribe free at dedupedai.com

Claude Codeを49エージェントのゲームスタジオにするテンプレートで、実際に1本作ってみた 本記事は「海外で話題のAI関連ニュース/OSSを毎日検証する」100日チャレンジのDay 035。この連載自体もClaude Code Routines(クラウド上の自動実行)で運用しているが、今回検証したClaude Code Game Studios(以下CCGS、MIT License)は、Claude Codeの1セッションを49体のサブエージェント・74個のスラッシュコマンド形式スキルからなる「ゲーム開発スタジオ」として動かすテンプレートで、本日GitHub Trendingで見かけて気になった。筆者がこの連載をClaude Codeで回しているのと似た発想のツールを、実際に動かして確かめてみる。 まず数字を数えて検証した READMEは「49 agents・74 skills・15 hooks・14 rules・62 templates」という構成を謳っている。話を進める前に、実物のファイル数をそのまま数えて照合した。 $ ls .claude/agents | wc -l 49 $ ls .claude/skills | wc -l 74 $ ls .claude/rules | wc -l 14 agentsとrulesは完全一致。skillsもディレクトリ数(=スラッシュコマンド数)で一致した。hooksは.claude/hooks/*.shが18個あったが、実際に.claude/settings.jsonのhooksブロックに登録されているのは15個で、残り3つは登録済みフックから呼び出される共有ヘルパーだった。templatesは63個あり、READMEの62件表記とは1件ずれていたが、実害のない軽微な食い違いだった。総じてREADMEの主張はほぼ正確だった。 クラウド実行環境では動かせなかった 朝のRoutine(クラウド上の自動実行)で、クローンしたテンプレート自身のコード(.claude/hooks/*.shの直接実行や、ネストしたClaude Codeセッションの起動)を実行しようとしたところ、実行環境側の安全策である自動モード分類器に一貫してブロックされた。 Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Code from External]. ... これはCCGS自体の不具合ではなく、自動実行されるクラウドセッションに対する安全策というRoutine環境固有の制約だったため、/startから/dev-storyまでの実際のワークフロー検証は、手元のPCでのローカル検証にエスカレーションした。本記事の本題はこのローカル検証の結果になる。 代わりに見つけた、Claude Code自体のおもしろい挙動 テンプレート自身を動かすのは断念したが、その調査の途中で意図せず別の発見があった。 テンプレートをクローンして、作業ディレクトリをそのクローン先に移した直後、こちらから何も読み込み操作をしていないにもかかわらず、このセッション自身に「クローンしたテンプレートのCLAUDE.mdの内容」がそのまま指示として差し込まれた。しかもそれだけでなく、そのCLAUDE.mdの中で@記法によって参照されている4つのファイル(ディレクトリ構成の説明、エンジンのバージョン表、エージェント間の協調ルール、コーディング規約)の内容まで、連鎖的に読み込まれていた。 これが幻覚ではなく実在の機能であることは、claude --helpで確認できた。--bareフラグの説明に、次のように明記されている。 --bare Minimal mode: skip hooks ..., LSP, plugin sync, attribution, auto-memory, background prefetches, keychain reads, and CLAUDE.md auto-discovery. "CLAUDE.md auto-discovery"というのが、まさに今回観測した挙動の名前だった。作業ディレクトリがCLAUDE.mdを持つフォルダに入ると、セッションはその内容(と@で参照された先)を自動的に自分の指示として取り込む。 ここで引っかかったのは、クローンしてきたテンプレートのCLAUDE.md自身が、次のような「協調プロトコル」を定めていたことだ。 Agents MUST ask "May I write this to [filepath]?" before using Write/Edit tools No commits without user instruction つまり、人間がこのテンプレートを直接自分のプロジェクトとして使うことを前提にしたルールだ。今回のように「検証のために一時的にクローンして内部を調べる」だけの作業でも、cdして中に入った瞬間、このルールがそのままセッションの指示として読み込まれる。このリポジトリ自身のCLAUDE.mdが定める運用ルール(ブランチ+PR、公開判断は人間が行う等)と、クローン先テンプレートのCLAUDE.mdが定める協調プロトコルが、同一セッションの中で並行して「指示」として扱われている状態になっていた。 今回は読み取り専用の調査だったので実害はなかったが、他人のテンプレート(特にClaude Code向けの設定ファイルを含むもの)を調べるときに、気づかないうちに2つ目の指示セットを抱え込むことがある、というのは実務上おぼえておく価値のある挙動だと感じた。長く中に居座らず調査を終えたら早めにディレクトリを抜けるのが安全そうだ。 /startから/dev-storyまで実際に動かす 手元のPCで対話的なclaudeセッションを開き、クローンしたテンプレートのルートで/startを実行した。「どこから始めるか」(アイデアなし/漠然としたアイデア/明確な構想/既存の資産あり)を聞かれ、「アイデアなし」を選ぶと/brainstorm openに誘導された。/brainstormは3つの一行コンセプト案を自動提示してきて、その中から「墜落寸前の衛星リレー局をデブリ場から部品を回収して修理し、軌道減衰タイマーが0になる前に全システムを復旧させる」というゲーム「Signal Lost」を選び、対話形式で一枚物のdesign/game-brief.mdを生成した。 続く/setup-engineでは、Unity経験がある旨を答えるとUnityが即決された。最新版をWebSearchで調べたうえで、手元に実際にインストールされているUnityエディタのバージョンをPowerShellで直接プローブしてきた。 $ Get-ChildItem "C:\Program Files\Unity\Hub\Editor" -Directory Name ---- 6000.2.11f1 最新LTS(6000.3)と実機の既存バージョン(6000.2.11f1)の差分を検出し、どちらを使うか3択で確認された。既存バージョンを選んだところ、テンプレート同梱のエンジンリファレンス文書がすでに6.3 LTSを前提に書かれていることも検知し、参照文書を書き換えるのではなく「実際のバージョンを記録し、差分をproject.yamlに明記して両立させる」という対応を提案してきた。整合性検証スクリプトもこの差分を[DIFFERS]として実際に検出し、マージ判断はこちら側に委ねられた。 design/game-brief.mdのMVPリスト6件から、/create-storiesが各項目を1ストーリーずつ構造化した6本のストーリーファイルを自動生成した。/dev-storyは各ストーリーの実装をengine-programmerなどのサブエージェントへ委譲し、実装前に毎回「この設計でこのファイルに書いていいですか」と確認を挟んでくる。実装後には別のunity-specialistサブエージェントへ「Unity APIの使い方が現行バージョンに対して正しいか」というレビューだけを依頼する2段階構成になっており、実際にこのレビューでUIDocument.rootVisualElementの取得タイミングのバグと、生成UXMLの不正な属性の2件を発見し、実装担当エージェントへ差し戻して修正させていた。 Unityの実機プロジェクトがまだ存在しない段階だったため(次節で詳述)、「実際に起動してスクリーンショットを撮る」工程は毎回正直にNOT VERIFIEDとして記録され、UIストーリー(勝敗画面)は/story-doneの時点で一度正直にBLOCKED判定になった。「パースが通ることと実際に動くことは別物」というテンプレートの設計思想が、スローガンではなく実際に機能しているのを確認できた。 一番詰まった点: WSL上のリポジトリでUnityが起動を拒否した ここでCCGS自体とは別の、環境固有の壁にぶつかった。筆者の作業リポジトリはWSL(WindowsのLinux環境)側にあり、そこにUnityプロジェクトを作ろうとした。 Aborting batchmode due to fatal error: The project is on case sensitive file system. Case sensitive file systems are not supported at the moment. Please move the project folder to a case insensitive file system. WSLのファイルシステム(ext4)は大文字小文字を区別するが、Windows版Unityエディタはこれを明示的にサポートしていなかった。対応として、Unityプロジェクト本体はWindowsネイティブのパスに別途作成し、コード(Assets/)はリポジトリ側を正として変更のたびに手動でコピーして同期する、という二重管理の運用に切り替えた。プロジェクト作成後、-batchmode -quitでコンパイルを確認したところ、6ストーリー分のコードがエラーなくビルドされた。 --- DLLs built --- Name ---- Assembly-CSharp.dll Assembly-CSharp-Editor.dll WSLで開発していてUnity(のWindows版エディタ)を併用する読者が、同じ条件でそのまま再現しうる制約だと思うので、ここは失敗ログも含めてそのまま記録しておく。 ストーリーの範囲外だった「実際に遊べるようにする」統合作業 6本のストーリーはそれぞれ個別のロジッククラス(タイマー・デブリ・運搬・ステーション・修理・UI)を作るだけで、プレイヤーを動かしてシーン上で実際に遊べるようにする統合作業(プレイヤー操作・カメラ・シーン配置)はどのストーリーの範囲にも含まれていなかった。これはテンプレートの設計通りで、この統合レイヤーは「どのストーリーの正式スコープでもない追加作業」として明示的に確認したうえで直接実装した。 ここでUnity初心者でなくても踏みやすい実務的なバグに3つ遭遇した。1つ目は片付け忘れによる二重初期化で、勝敗画面のテスト用オブジェクトをシーンに残したまま本番用オブジェクトを追加し、同じインスタンスに対して初期化処理が2回呼ばれて例外になった。2つ目はカメラの設定漏れで、デフォルトのMain Cameraがパースペクティブのままだったため、プレイヤー以外のオブジェクトがほぼ画面外に出てしまっていた。3つ目が一番厄介で、エディタスクリプト(編集時に実行するメニュー項目)の中で生成した一時的なスプライトオブジェクトへの参照が、Playモード突入時のドメインリロードで失われ、該当オブジェクトが画面上で透明になっていた。一方、MonoBehaviour.Awake()(実行時)で同じように生成したプレイヤーのスプライトは問題なく表示されており、「編集時に生成した一時アセット」と「実行時に生成した一時アセット」とでドメインリロードをまたいだ生存期間が異なるという非対称な挙動だった。最終的にスプライトの割り当てをすべてAwake()内のランタイム生成に統一して解決した。 これらをすべて解決したのち、実際にプレイヤーを動かしてデブリをスキャンし、部品を回収し、ステーションで修理する一連の操作が成立し、全システムを修理すれば勝利画面、修理しきる前にタイマーが0になれば敗北画面が表示されることを、スクリーンショットで確認した。 <!-- TODO(公開前): Zenn CLIまたはWeb UIで下記2枚をアップロードし、Zennの画像URLに差し替える。 元ファイルは experiments/day-035/signal-lost-game/evidence/ 参照。 - win-screen.png (SIGNAL RESTORED — all systems repaired.) - loss-screen.png (SIGNAL LOST — the station has gone dark.) --> まとめ CCGSが主張する「パースが通ることと実際に動くことは別物」「画面の変化を伴う修正は実際に起動してスクリーンショットを残すまで完了にしない」という検証哲学は、実際に/story-doneのBLOCKED判定として機能していた。一方で6本のストーリー単体では「実際に遊べるゲーム」にはならず、その統合作業はテンプレートのスコープ外であり、結局は従来どおり一行ずつデバッグログを足しながら原因を切り分ける必要があった。49体のエージェント・74個のスキルは「設計からコードへの変換と検証」を高い精度で担ってくれる一方、「実際に動かして遊んでみて、何かおかしいときに原因を探る」という最後の工程は、今回確認した範囲では人間の目と反復作業に最後まで依存していた。 もう一つ収穫だったのは、CCGS自体ではなくClaude Code自体の挙動として見つけた"CLAUDE.md auto-discovery"だった。他人のテンプレートをクローンしてcdしただけで、そのディレクトリのCLAUDE.md(と@参照先)がこちらの指示として自動的に読み込まれる。検証のための一時的な調査でも、気づかないうちに相手の協調プロトコルを指示として抱え込むことがある、というのは実務上おぼえておく価値のある挙動だった。 出典・ライセンス Donchitos/Claude-Code-Game-Studios(MIT License)

Agent Swarms Still Can't Coordinate Agent Swarms Still Can't Coordinate > 📖 Read the full version with charts and embedded sources on AgentConn → GitHub's trending page this week features a repo called Claude Code Game Studios — 49 AI agents organized into a full game development hierarchy, complete with designers, programmers, QA testers, and a production coordinator. It picked up 970 stars in a single day and has crossed 32,000 total. The pitch is irresistible: clone the repo, point Claude at it, and watch a studio of agents build your game. The same week, two independent benchmarks dropped results that should give every multi-agent enthusiast pause. YC Labs and Olam Labs put 50 GPT-6.1 Sol agents in Minecraft with a single instruction — "build a thriving civilization" — and watched them descend into paralyzing bureaucracy. Separately, Silo-Bench, an ACL 2026 paper, measured what happens when you split a reasoning task across multiple agents: even at just two agents, performance drops 15-49%. At fifty agents, the loss hits 80-100%. The pattern is stark. The industry is shipping orchestration frameworks. The benchmarks say coordination is unsolved. {% youtube l1L9sezAcxc %} The Civ50 Experiment: 50 Agents, 3 Hours, One Disastrous First Night The YC Labs report, published October 29, is the most detailed public experiment on large-scale agent swarm behavior we have seen. Olam Labs (co-founded by Om Buddhdev) partnered with Y Combinator's Labs group to run what they call "Civ50": fifty GPT-6.1 Sol agents dropped into a fresh Minecraft survival world with three hours and one goal. What happened next reads like a management consulting case study gone wrong.  View the full article on RuntimeWire → Within 90 seconds, the agents had cleared nearly every tree near spawn. The first agent in the fixed agent directory — an agent named Ada — became the de facto leader simply because she was listed first. She received 616 direct messages. The colony generated roughly 5,900 messages total across three hours. Then night fell. Twenty-two of the fifty agents died. The surviving colony became intensely risk-averse. A food-rationing system emerged around one agent's ledger, with fishing as the primary calorie source. Eleven different agents independently wrote fishing scripts. > ⚠️ The Bone Meal Incident: At one point, four agents spent 11 minutes appointing a "sole fertilizer operator" for a single piece of bone meal on a single wheat block. This is not a parody. This is what emergent multi-agent governance looks like at scale. The colony's social dynamics were equally revealing. After one agent picked up and ate a cooked chicken that was intended for another, the entire colony instituted a rule that rations must go into named chests and never be tossed. The word "toss" appeared 7 times before the incident and 125 times after — the agents had effectively legislated around a single misdelivered food item. By hour three, the colony had 34 total deaths, a functioning bureaucracy, and something that looked more like a risk-averse government than a thriving civilization. The Bed Wars and Mindustry Results: Democracy vs. Hive Mind The same research team ran two competitive benchmarks — nine Bed Wars games (10 vs. 10 agents) and seven Mindustry battles — pitting GPT-6.1 Sol agents against Claude Opus 5.5 agents. The results reveal how differently these models approach coordination under pressure. Mindustry (7 games, ~9.5 hours): GPT won 6-1. YC Labs summarized the split cleanly: "Claudes generally established democracies, GPTs formed hives." The Claude team used a "+1" voting system where proposals needed multiple endorsements and no objections. They kept this system unchanged for all 9.5 hours — including through five consecutive losses. The GPT team split factory ownership early, shared resources readily, and developed compressed shorthand language over time. Bed Wars (9 games, 45 minutes each): GPT won the series 6-3. Claude's strategy was defensive — aim to win on kill count. It worked on paper: Claude led kills in three key games by margins of 63-16, 57-19, and 59-24. But GPT broke Claude's bed with minutes remaining each time. When a block-breaking bug hit both teams, GPT diagnosed it and shared a workaround. Several Claude agents concluded breaking was impossible. The most damning finding: Claude agents wrote lessons into memory files after each game. They then repeated the same mistakes. GPT agents left their memory files empty but warned teammates directly in real time. > ℹ️ The Source Code Incident: Both teams had internet access. When games got tight, only the GPT agents searched for Mindustry's open-source code online and read it for tactical advantage — unprompted. The Claude agents never did. The "aligned, deliberative" agent lost to the one that improvised and bent rules. There are caveats worth stating clearly. The sample sizes are small — seven Mindustry games, nine Bed Wars games, one Civ50 run. Each model ran in a different harness (Codex vs. Claude Code), so harness and model effects are tangled. No statistical tests were reported. But the qualitative patterns — bureaucratic paralysis, ignored memory, defensive conservatism — match what we see in every production multi-agent deployment. The Academic Evidence: Coordination Overhead Is Measurable The Minecraft experiments are vivid, but the academic benchmarks are more damning because they are controlled. Silo-Bench (ACL 2026) designed 30 algorithmic tasks where information is deliberately split across agents. The key finding: the failure is not in information acquisition — agents successfully gather the data they need — but in integration. They cannot combine distributed knowledge into a coherent solution. At k=2 agents, performance drops 15-49% compared to a single agent with the same information. At k=50, the drop reaches 80-100%. The coordination tax does not just reduce gains — it eliminates them entirely. "When 20 Agents Fail to Sort" (ACL Findings 2026) set an even simpler challenge: distributed sorting. Success drops sharply as agent count grows, with failures concentrated in shared state management, convention alignment, and consistent termination. The paper proposes CAMOC (Coordination-Aware Multi-agent Orchestration with Communication), a drop-in fix that substantially improves results — suggesting the problem is architectural, not capability-limited.  View the full post on Google Research → Google Research's scaling study (January 2026, 180 agent configurations) adds the quantitative framework. On parallelizable tasks (Finance-Agent), centralized coordination raised performance 81% above single-agent baselines. On sequential tasks (PlanCraft), every multi-agent variant tested lost 39-70%. Independent multi-agent systems amplified errors up to 17.2x. Centralized systems limited amplification to 4.4x. The takeaway from the research is unambiguous: coordination overhead scales superlinearly with agent count. Adding agents to a sequential task does not just fail to help — it actively degrades performance. Why Model IQ Is Not the Bottleneck  View the discussion on Hacker News → The Memdoor project landed on Hacker News this week with 385 points and 188 comments: five Qwen3.8-27B models, running collaboratively through a custom harness, matched Fable 5 on LiveCodeBench Hard. A team of open-source models punching above their weight against the frontier. The top comment was prophetic: "It's remarkably easy to build a harness that improves a single eval, and remarkably difficult to build one that generalizes." This captures the coordination paradox precisely. The harness — the orchestration layer — matters enormously. But the returns from adding agents are inconsistent and task-dependent. Richmond Alake from Oracle made the same point at AI Engineer this week: "Everyone has the same models. Memory is the moat — the intelligence plane governs what agents know." {% youtube 1_lX0m64-aI %} The DoorDash evidence drives the point home from the product side. Ars Technica reported that outside AI agents have led to only "hundreds" of DoorDash orders total. Not hundreds per day — hundreds, period. The agents exist. They can place orders. But the coordination required to go from "can do the task" to "reliably does the task at scale" is the gap that nobody has closed.  View the discussion on Reddit → The Community Reaction  View the discussion on Reddit → The Reddit thread racked up 4,759 upvotes and 315 comments — one of the biggest AI agent stories on r/technology this quarter. On Hacker News, the Memdoor discussion (a separate but thematically linked thread) drew 385 points and 188 comments with practitioners debating whether multi-agent harnesses can generalize beyond single benchmarks. The discourse splits into two camps. The first sees this as evidence that multi-agent systems are fundamentally limited by coordination overhead — that the ceiling is lower than the hype suggests. The second camp, smaller but vocal, argues that coordination is an engineering problem with known solutions from distributed systems theory, and that these experiments are testing first-generation coordination protocols against tasks that took human societies centuries to solve. Both camps are right, and the tension between them is precisely the point. Coordination is both a hard problem and a solvable one. The question is whether the current rush to ship 49-agent studios is running ahead of the coordination science that would make them work. {% youtube 7WUzHIF32vA %} The 49-Agent Studio Problem The broader developer community is also grappling with these overhead costs. A parallel Hacker News thread on "The AI Cost of JavaScript Frameworks" (223 points, 154 comments) debates how framework complexity compounds when AI agents are the ones writing and maintaining the code — a coordination cost that scales with every additional tool and abstraction layer agents must navigate.  View the discussion on Hacker News → Back to Claude Code Game Studios. The repo is impressive — 49 specialized agents, 72 workflow skills, 12 validation hooks, 41 document templates. It mirrors a real studio hierarchy. It earned 970 stars in a day. But here is the question the benchmarks force us to ask: what happens when those 49 agents need to coordinate? The Civ50 experiment used 50 agents — a comparable number — and the result was a bone-meal bureaucracy. Google's research found that coordination overhead rises disproportionately as tool count grows, with severe degradation when agents manage 16+ tools. Silo-Bench showed that even two agents lose up to half their solo performance on integration tasks. The pattern repeating across GitHub Trending is frameworks that add agents. The pattern repeating across benchmarks is that agents, once added, spend most of their time coordinating rather than producing. The industry is building the organizational chart. The research says the meetings are eating the work. > ⚠️ Contrarian Corner: Maybe the bureaucracy IS the coordination solution. Human organizations have the same overhead — committees, voting, named responsibilities for single resources. The Civ50 colony's food-rationing system and fertilizer operator are structurally identical to how early human settlements organized. Perhaps agent coordination will improve through the same slow cultural evolution, not through architectural silver bullets. The uncomfortable implication: if you want agents to coordinate well, you may need to let them develop their own institutions over many iterations — which means the "throw 50 agents at it for 3 hours" benchmark is measuring startup culture, not steady-state governance. What This Means for Builders The benchmarks converge on a clear set of principles for anyone designing multi-agent systems in production: 1. Default to single-agent. Google's study found that a predictive model could pick the best architecture for 87% of unseen tasks using just task properties (tool count, decomposability). For sequential reasoning tasks, every multi-agent variant lost. Start with one strong agent. Add agents only when you can prove the task is parallelizable and the coordination protocol is defined. 2. Measure coordination overhead before scaling. Silo-Bench's 15-49% penalty at k=2 means coordination is expensive even at the smallest multi-agent scale. Before adding a second agent, benchmark the integration cost. If two agents lose 30% on your task, five agents will not gain it back. 3. Centralize orchestration. Google's error-amplification numbers are definitive: 17.2x for independent agents vs. 4.4x for centralized coordination. If you must use multiple agents, give one agent clear authority. The Mindustry results reinforce this — GPT's hive-mind coordination outperformed Claude's democratic voting in 6 of 7 games. 4. Do not trust written memory. The Bed Wars finding — agents writing lessons they then ignored — should alarm anyone building memory-augmented multi-agent systems. Direct, real-time communication between agents outperformed asynchronous written records. If your agents share state through files or databases rather than direct messaging, test whether they actually use what they read. 5. Watch for bureaucratic emergence. The bone-meal incident and the toss-legislation are not edge cases — they are the natural equilibrium of agents that can communicate freely. If your agents can create rules, they will create rules, and the rules will multiply faster than the productive output. Constrain the communication channel deliberately. For a deeper dive into orchestration architecture, see our coverage of dynamic workflows in Claude's agent swarm and the graph-structured approach to multi-agent coordination. For fleet management patterns, the agent-of-agents architecture piece covers the observe-route-kill primitives. The Bottom Line The agent coordination problem is not a model problem. GPT-6.1 Sol and Claude Opus 5.5 are both frontier models. They both failed to coordinate efficiently at scale — one through bureaucratic conservatism, the other through chaotic improvisation that happened to win more games. The Minecraft benchmarks do not crown a winner in the model race. They expose a shared failure in the coordination layer. Fifty agents in Minecraft built a government. They did not build a civilization. The gap between those two outcomes is the coordination tax, and right now, nobody is close to solving it. The frameworks shipping on GitHub this week are adding more agents. The benchmarks shipping from research labs this week are proving that more agents, absent a coordination breakthrough, means more overhead, more errors, and more bone-meal committees. Build one agent that works. Then ask yourself very carefully whether you need a second one. Originally published at AgentConn

t3code Tops GitHub Trending with 3,100 Stars Today What it is !pingdotgg/t3code t3code is the top repository on GitHub trending today, picking up 3,100 stars in a single day. That is more than double the next closest project on the list, and it happened with a repository description that is currently empty. The only signals available are the name, the organization behind it, and the star velocity. The pingdotgg organization is the same one behind the T3 stack ecosystem, which includes create-t3-app and the T3 Turbo monorepo. That context matters because it tells you what kind of codebase to expect: TypeScript-first, opinionated about tooling, and aimed at developers who already work in the React and Next.js world. But the repository itself does not yet ship a description, so anything beyond that is inference. Why it is getting attention The star count is the story. 3,100 stars in a day puts t3code well ahead of every other project on today's trending list. For comparison, claude-mem pulled 1,527, hex pulled 1,329, and Claude-Code-Game-Studios pulled 970. t3code more than doubled the runner-up. That kind of velocity usually means one of a few things. Either a well-known maintainer announced something publicly, a launch post linked here, or the repository is a placeholder that got shared before the actual code landed. The empty description supports the third possibility, though it is not proof. What is clear is that a large number of developers decided this repository was worth starring today, and the star count is the only concrete data point available. It is also worth noting what t3code is competing against on the same day. The rest of the trending list is dominated by AI tooling: persistent memory for coding agents, a headless browser built for automation, an offline speech-to-text app, a local voice dictation tool for three platforms, and an open-source security operations center that ships an MCP server. In that company, a repository with no description still leading the chart is unusual and suggests the T3 name carries real weight with its audience. Who should care Developers already using the T3 stack should watch this repository. If it turns out to be a new scaffolding tool, a runtime, or a component library, it will likely slot into the same workflow as create-t3-app and T3 Turbo. The organization has a track record of shipping tooling that people actually adopt, which is why the star count spiked before any documentation existed. Anyone evaluating TypeScript web tooling more broadly should also keep an eye on it, but with a caveat. Without a description, a README, or a release, there is not enough information to recommend adoption. Starring a repository is cheap. The useful next step is to wait for the maintainers to publish what the project actually does, then decide whether it fits your stack. If you are looking for something you can use today, the other entries on the trending list are more concrete. claude-mem has a clear description of persistent context across agent sessions. hex and Handy both ship offline voice input. AiSOC documents alert fusion and a replayable decision ledger. t3code, by contrast, is a signal without a payload, at least for now. The 3,100 stars are real. The project's purpose is not yet public. That gap is exactly why it is worth following rather than adopting. View the repository on GitHub

Claude-Code-Game-Studios: A Chinese Translation for Claude Code's 49-Agent Game Studio The original repo has 31,393 stars. The Chinese translation launched today with zero. That gap is the whole point of this article: the project is worth reading, and for a Chinese-speaking developer the barrier to reading it just dropped. What the project actually is Claude-Code-Game-Studios (original: Donchitos/Claude-Code-Game-Studios, Shell, MIT) is a configuration template for Claude Code. It does not generate games. It restructures a single chat session into something that behaves like a studio hierarchy. The numbers from the README: | Category | Count | What it covers | |---|---|---| | Agents | 49 | Sub-agents across design, programming, art, audio, narrative, QA, production | | Skills | 74 | Slash commands for each workflow stage | | Hooks | 15 | Automatic validation on commit, push, asset changes, design doc reads/writes, registry writes, session lifecycle, agent audit trail, gap detection | | Rules | 14 | Path-scoped coding standards | | Templates | 62 | GDD, UX spec, ADR, sprint plan, HUD design, accessibility, and more | The problem it targets is stated plainly in the README: a solo developer using AI has no structure. Nobody stops you from hardcoding magic numbers. Nobody asks whether a feature matches the game's vision. There is no QA pass and no design review. The three-layer hierarchy Agents are organized the way a real studio is: Layer 1 — Directors creative-director technical-director producer Layer 2 — Department Leads game-designer lead-programmer art-director audio-director narrative-director qa-lead release-manager localization-lead Layer 3 — Specialists gameplay-programmer engine-programmer ai-programmer network-programmer tools-programmer ui-programmer systems-designer level-designer economy-designer technical-artist sound-designer writer world-builder ux-designer prototyper performance-analyst devops-engineer Each agent has a defined scope, an escalation path, and quality gates. You still make every decision. The difference is that the session now pushes back — asks the questions a lead would ask, catches errors earlier. One practical detail worth flagging before you start: model requirements differ per agent. The three director agents require Opus. lead-programmer and 15 specialists specify Sonnet. The remaining 30 inherit whatever model your session is running. If your session model is lower than what a role expects, that role may not behave as intended. Getting a session running The Chinese README adds a "中文快速上手" (quick start) section that is explicitly marked as supplementary, not part of the original translation. It exists so you can get moving without reading the full document first. The shortest path: git clone https://github.com/Donchitos/Claude-Code-Game-Studios Open the project directory in Claude Code, then: 1. /start — begins the guided flow 2. /setup-engine — pick Godot 4, Unity, or Unreal Engine 5 3. Then move through /brainstorm, /design-system, /create-epics, /create-stories, /dev-story, /story-done as needed The engine choice matters. There are three separate agent sets, one per engine, and /setup-engine selects the matching one. Pick wrong and your specialists won't line up with your project. The original README does not provide an explicit install or launch command, and the Chinese version says so rather than inventing one. Platform support and hardware requirements are also marked as not specified in the source material — the "Platform Support" section was truncated in what was available for translation. The only hard dependency stated is Claude Code itself. Why the Chinese version is worth having The translation is faithful to the original — the body of the README is translated text, and the quick-start section is clearly separated as an addition. That separation is the right call. You can tell at a glance which parts are the author's words and which are translator commentary. For a Chinese-speaking developer, the practical gain is not just language comfort. This is a document dense with role names, workflow vocabulary, and process concepts — "department lead," "escalation path," "quality gate," "sprint plan," "ADR." Reading that in a second language while also trying to learn an unfamiliar workflow is slow. Having the terminology in Chinese means you spend your attention on the structure instead of on parsing. The quick-start section also front-loads the things that trip people up: - Model cost. Some agents require Opus or Sonnet. Budget for it or expect degraded behavior from those roles. - Engine selection is exclusive. One of three agent sets, chosen via /setup-engine. This is a one-time decision that shapes everything downstream. - It is a process template, not a game generator. Output is design docs, architecture, stories, reviews. Not a playable build. - Upgrades have their own doc. The repo includes UPGRADING.md. Read it before upgrading so you don't overwrite custom configuration. The specific upgrade steps aren't detailed in the available material. That last point is a good example of how the translation handles uncertainty: it says what the source says and marks what the source doesn't cover, rather than filling gaps with guesses. What it produces The README has a section titled "它产出游戏还是文档？" (Does it produce games or documents?). The available material is truncated at that point, so the original's conclusion isn't stated here. What is clear from the rest of the document is that the output is process artifacts — GDDs, UX specs, ADRs, sprint plans, HUD designs, accessibility docs, drawn from the 62 templates. Treat it as scaffolding for a solo project that would otherwise have none. A note on the numbers 31,393 stars belong to the original project. The Chinese translation is new and has none yet. If you're evaluating whether to adopt this, the star count tells you the original is widely used; it tells you nothing about the translation's quality. The translation's own claim is modest — if something is inaccurate, open an issue or a PR. My read is that the translation is competent and the structure is honest about its own limits. That's a small sample, and it may not hold for you. Repository Chinese version: yangshun2005/Claude-Code-Game-Studios-cn Original: Donchitos/Claude-Code-Game-Studios License: MIT. Language: Shell. --- *Chinese documentation: yangshun2005/Claude-Code-Game-Studios-cn* I'm an independent enterprise AI delivery consultant — private LLM deployment, RAG, agent workflows, AIOps. If your team is stuck somewhere in that stack, my inbox is open.

An entire game dev studio in one Claude session? 🎮 Claude-Code-Game-Studios turns Claude Code into an AI production studio: 49 agents, 72 skills, and real hierarchy. Free & open-source. Donchitos/Claude-Code-Game-Studios #OpenSource #GitHub #DevTools

Claude-Code-Game-Studios — Turn Claude Code into a full game dev studio — 49 AI agents, 72 workflow skills, and a complete coordination system mirroring real studio hierarchy Link: Donchitos/Claude-Code-Game-Studios #OpenSource #GitHub #DevTools

Anyone use Claude-Code-Game-Studios suite? I've ad hoc built some of this (like specialist agents) as I go, but wondering if I should just submit myself to this github Donchitos/Claude-Code-Game-Studios which seems to have thought it through a lot more. I know people in other thread were divided on how much to rely on skills. For someone like me with no technical or industry background in any of this, it's reassuring that other people have thought through the workflows etc and I can let that guide me. Thanks!