Donchitos

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!

今日のGitHubトレンド Donchitos/Claude-Code-Game-Studios Claude Codeのセッションを擬似的なゲーム開発スタジオとして運用するためのツールです。 単一のAI対話では欠けがちな構造や品質管理を補うため、役割分担された49のエージェントや74のスキル、各種テンプレートなどを提供します。 設計からQAまで体系的なワークフローを導入し、プロジェクトの整理と開発品質の向上を実現することを目的としています。

2. Donchitos/Claude-Code-Game-Studios 把一个 Claude Code 会话变成完整的游戏工作室。 49 个专职 Agent、74 个技能，按真实工作室层级分工，从策划到 QA 都有人把关，决策仍由你拍板。 🔗 Donchitos/Claude-Code-Game-Studios 3 万星，一天涨 1347 星 🟢🟢

Claude Code Game Studios took 19 minutes and $5 to build my little Godot game. Plain Claude Code did it in 38 seconds Wanted to know if the whole “49 agent game studio” setup is worth it for a small game, so I made the same one twice. Meteor Dodge: move a ship left and right, dodge meteors that keep speeding up, score is seconds survived, R to restart. Godot 4.7.2, Claude Code v2.1.312, Game Studios v1.2.0, Sonnet 5.5. Game Studios is a template by Donchitos (MIT, not made by Anthropic). You don’t install it, you clone it and the clone becomes your game folder: git clone Donchitos/Claude-Code-Game-Studios my-game cd my-game claude Then /start, /brainstorm, /setup-engine godot 4.7, /create-stories, /dev-story, /story-done. The numbers: - plain: 38 sec, 7 turns, about $0.15, one prompt from me, 1 script with 94 lines - Game Studios: about 19 min, 266 turns, about $5, 14 messages from me, 9 scripts with 387 lines plus a brief, 7 stories and 8 screenshots as proof 13 of those messages happened before it wrote a single line of code. It asks a lot. Both games worked. I wrote a small script that pressed the arrow keys, waited for a hit and pressed R, and both passed. Honestly the plain version looked nicer, it had stars and cratered meteors. The Game Studios one was simpler shapes on a wider screen. The funny part: none of the 49 agents actually ran. At minimal rigor Claude just wrote the code itself and said so, skipped the programmer agent and the Godot specialist to keep files consistent. Agent log stayed empty. What I did like: - it flagged a bug I never asked about, one slow frame could let a meteor skip past the ship - it said the speed numbers were its own guesses - it refused to sign off on how the game looks and left that story for a human - it warned Godot 4.7 is newer than what the model knows well Small things: the trust prompt shows it pre-approves 3 commands (dir and two pytest). Two writes inside .claude got blocked as sensitive, nothing broke. Removing it is just deleting the folder plus a tiny cache in ~/.cache/claude-code-game-studios. The project’s own README kind of admits the same trade-off. Its standard mode wrote 30 documents before the first line of code and reviewers didn’t rank that build higher. So for a one screen arcade game it’s mostly overhead. I can see it making sense for a game you’ll work on for weeks, where you’d forget what you decided last Tuesday. If anyone’s used it at standard or full rigor on something bigger, curious if the agents actually earn their keep there. Full write up with screenshots of both games: aiparabellum.com