克劳德代码游戏工作室

把一次Claude Code的会话变成一个完整的游戏开发工作室。
49名特工。74项技能。一个协调一致的AI团队。

为什么会这样

用AI单独构建游戏很强大——但单次聊天没有结构。没人能阻止你硬编码魔术数字、跳过设计文档或写杂乱无章的代码。没有质量保证，没有设计审查，也没有人问“这真的符合游戏的愿景吗？”

Claude Code Game Studios 通过赋予你的 AI 会话真实工作室的结构来解决这个问题。不再是一个通用助理，而是49名专业经纪人组成了一个工作室层级体系——负责守护愿景的导演，拥有自己领域的部门负责人，以及亲力亲为的专家。每个代理都有明确的职责、升级路径和质量门槛。

结果是：你仍然做每一个决定，但现在你拥有了一个提出正确问题、及早发现错误，并从头脑风暴到启动都保持项目井然有序的团队。

目录

• 包含内容

• 制片厂层级

• 斩击指令

• 它会制作游戏或文档吗？

• 入门指南

• 配置

• 升级

• 项目结构

• 工作原理

• 设计理念

• 定制化

• 平台支持

• 社区

• 支持本项目

• 许可

包含内容

制片厂层级

经纪人分为三级，与真实工作室的运作方式相符：

Tier 1 — Directors
  creative-director    technical-director    producer

Tier 2 — Department Leads
  game-designer        lead-programmer       art-director
  audio-director       narrative-director    qa-lead
  release-manager      localization-lead

Tier 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       analytics-engineer
  security-engineer    qa-tester             accessibility-specialist
  live-ops-designer    community-manager

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

Engine Specialists

The template includes agent sets for all three major engines. Use the set that matches your project:

Slash Commands

Type in Claude Code to access all 74 skills:/

Onboarding & Navigation /start /help /project-stage-detect /setup-engine /adopt /settings

Game Design /brainstorm /map-systems /design-system /quick-design /review-all-gdds /propagate-design-change

Art & Assets /art-bible /asset-spec /asset-audit

UX & Interface Design /ux-design /ux-review

Architecture /create-architecture /architecture-decision /architecture-review /create-control-manifest

Stories & Sprints /create-epics /create-stories /dev-story /sprint-plan /sprint-status /story-readiness /story-done /estimate

Reviews & Analysis /design-review /code-review /balance-check /content-audit /scope-check /perf-profile /tech-debt /gate-check /consistency-check /security-audit

QA & Testing /qa-plan /smoke-check /soak-test /regression-suite /test-setup /test-helpers /test-evidence-review /test-flakiness /skill-test /skill-improve

Production /milestone-review /retrospective /bug-report /bug-triage /reverse-document /playtest-report

Release /release-checklist /launch-checklist /changelog /patch-notes /hotfix /day-one-patch

Creative & Content /prototype /vertical-slice /onboard /localize

Team Orchestration (coordinate multiple agents on a single feature) /team-combat /team-narrative /team-ui /team-release /team-polish /team-audio /team-level /team-live-ops /team-qa

Does it produce games, or documents?

A fair question, and the answer is a measurement rather than a sample project. Four games were built from one brief at different levels and the documents each wrote before its first line of game code were counted:modes.rigor

All of them produced a running, tested game. Two blind reviewers and a human playtest then ranked the build last — the extra 29 documents bought traceability, not a better game.standard

It runs the game and looks at it

The measurement above is about cost. The other half is whether the thing works, and for a game that means someone has to look at it — a passing test says nothing about a menu drawn off-screen. So a story that changes anything the player sees is not closed until the game has been launched, observed, and a screenshot retained in . A parse check is not a run. This holds at every rigor level, including , where automated tests are waived but the look is not.production/qa/evidence/minimal

The games themselves are deliberately not shipped here: this is a template you clone to start your own project, and somebody else's game in your repo is clutter, not evidence.

Getting Started

Prerequisites

• Git

• Claude Code — the native installer is recommended ( also works, on Node.js 22+)npm install -g @anthropic-ai/claude-code

• Python 3 — reads for every skill and hook; without it every setting silently falls back to its defaultproject.yaml

• Bash — runs every hook; built into macOS and Linux, and on Windows it comes with Git for Windows

• Recommended: jq (for hook validation)

Hooks fail gracefully if optional tools are missing — you just lose validation — with one deliberate exception: a commit that stages data JSON is blocked when there is no Python to validate it.

Setup

1. Clone or use as template:

   git clone https://github.com/Donchitos/Claude-Code-Game-Studios.git my-game
   cd my-game

2. Open Claude Code and start a session:

   claude

3. Run /start — the system asks where you are (no idea, vague concept, clear design, existing work) and guides you to the right workflow. No assumptions.

   Or jump directly to a specific skill if you already know what you need:

   • /brainstorm — explore game ideas from scratch

   • /setup-engine godot 4.6 — configure your engine if you already know

   • /project-stage-detect — analyze an existing project

Configuration

project.yaml at the repo root is the single source of truth for how the studio behaves on your project — engine, naming conventions, and a block that controls how much process every skill enforces. writes it for you; you rarely need to hand-edit it.modes/start

The one question that matters most is modes.rigor — , , or . It's a single front door over six separate knobs ( — which GDD sections are required, , , , — how many director agents review your work, and ), so asks it once instead of six times:minimalstandardfullworkflowdocs.densityqa.levelstory_granularityreview_modeteam.size/start

• minimal (default) — jam-game speed. No GDDs required, terse docs, minimal QA evidence, solo review. → → (a one-page brief) → → ↔ ./start/setup-engine/brainstorm/create-stories/dev-story/story-done

• standard — 5 required GDD sections, balanced doc depth, standard QA evidence, lean review.

• full — all 8 GDD sections, thorough docs, full QA evidence on every story type, full director review.

minimal is the default because it was measured against the alternatives: the heavier tier cost several times more to reach working code, was ranked last on play quality, and returned nothing measurable when a fresh developer inherited the project. Raise it in one call when your project grows — and will suggest it when they see the signs./settings/help/gate-check

Two escape hatches keep one setting from being a blunt instrument. system_overrides holds a single system to a higher standard than the rest of the project — your combat system gets the full treatment while everything else stays light. testing.strict sets, per test type (logic, integration, visual, UI, config), whether missing evidence blocks a story or merely warns.

Any of the six underlying knobs can still be set individually if you want a mix (e.g. with — comprehensive but compact). Two of them — ( / / ) and — are also personal: rigor sets the team-wide default, but you can override them per-developer in a gitignored without touching the shared config. (how often the AI pauses to ask before it acts) sits outside rigor and is likewise personally overridable.workflow: fulldocs.density: tersereview_modefullleansoloteam.sizeproject.local.yamlmodes.automation

View or change any setting with the skill:/settings

/settings                              # view effective config
/settings modes.review_mode            # view one setting
/settings modes.rigor=full             # write to project.yaml (team-wide)
/settings --local modes.review_mode=solo   # write to project.local.yaml (just you)

Full schema and per-setting behavior: ..claude/docs/effects-map.md

Upgrading

Already using an older version of this template? See UPGRADING.md for step-by-step migration instructions, a breakdown of what changed between versions, and which files are safe to overwrite vs. which need a manual merge.

Project Structure

CLAUDE.md                           # Master configuration
.claude/
  settings.json                     # Hooks, permissions, safety rules
  agents/                           # 49 agent definitions (markdown + YAML frontmatter)
  skills/                           # 74 slash commands (subdirectory per skill)
  hooks/                            # 14 scripts (bash) — 12 event hooks, yaml-helper.sh,
                                    #   and one opt-in diagnostic you wire yourself
  rules/                            # 13 path-scoped coding standards
  statusline.sh                     # Status line script (context%, model, stage, epic breadcrumb)
  docs/
    workflow-catalog.yaml           # 7-phase pipeline definition (read by /help)
    templates/                      # 39 document templates (+ per-section guidance)
src/                                # Game source code (Godot). The code root is
                                    #   ENGINE-SPECIFIC: Unity compiles only
                                    #   Assets/, Unreal builds from Source/<Module>/
assets/                             # Art, audio, VFX, shaders, data files
design/                             # GDDs, narrative docs, level designs
docs/                               # Technical documentation and ADRs
tests/                              # Test suites (unit, integration, performance, playtest)
tools/                              # Build and pipeline tools
prototypes/                         # Throwaway prototypes (isolated from src/)
production/                         # Sprint plans, milestones, release tracking
CCGS Skill Testing Framework/       # QA for the skills and agents themselves — see below

Testing your customizations

CCGS is a template you are meant to edit. is how you check that an edited or newly written skill still holds up — a catalog of all 74 skills and 49 agents, per-category quality rubrics, behavioral specs, and templates for writing specs of your own.CCGS Skill Testing Framework/

/skill-test static [name]     # structural linter — 7 compliance checks
/skill-test category [name]   # category-specific quality rubric
/skill-test spec [name]       # behavioral spec assertions
/skill-test audit             # coverage report across skills and agents
/skill-improve [name]         # test-fix-retest loop; keeps or reverts on score change

It tests the framework, never your game — game tests live in .tests/

How It Works

Agent Coordination

Agents follow a structured delegation model:

1. Vertical delegation — directors delegate to leads, leads delegate to specialists

2. Horizontal consultation — same-tier agents can consult each other but can't make binding cross-domain decisions

3. Conflict resolution — disagreements escalate up to the shared parent ( for design, for technical)creative-directortechnical-director

4. Change propagation — cross-department changes are coordinated by producer

5. Domain boundaries — agents don't modify files outside their domain without explicit delegation

Collaborative, Not Autonomous

This is not an auto-pilot system. Every agent follows a strict collaboration protocol:

1. Ask — agents ask questions before proposing solutions

2. Present options — agents show 2-4 options with pros/cons

3. You decide — the user always makes the call

4. Draft — agents show work before finalizing

5. Approve — nothing gets written without your sign-off

You stay in control. The agents provide structure and expertise, not autonomy.

Automated Safety

Hooks run automatically on every session:

Note: , , and fire on every Bash, PowerShell or Write tool call and exit immediately (exit 0) when the command or file path is not relevant. This is normal hook behavior — not a performance concern.validate-commit.shvalidate-assets.shvalidate-skill-change.sh

Permission rules in auto-allow safe operations (git status, test runs) and block dangerous ones (force push, , reading files) in both the Bash and PowerShell tools. The rules match anywhere after , so a git command whose text only mentions followed later by or , followed by , or followed by — a commit message such as included — is denied too: reword the message.settings.jsonrm -rf.envgitgitpush + -fclean -freset--hardgit commit -m "push + pull"

Path-Scoped Rules

Coding standards are automatically enforced based on file location. The paths below are Godot's. Each rule also matches the Unity and Unreal layouts: the code rules match C# under and C++ under (and , , , ), data matches JSON under and , shaders match by file type, and tests match C# under and C++ under .Assets/**/Gameplay/Source/**/Gameplay/CoreAINetworkingUIAssets/**/Data/Content/**/Data/Assets/Tests/Source/**/Tests/

Design Philosophy

This template is grounded in professional game development practices:

• MDA Framework — Mechanics, Dynamics, Aesthetics analysis for game design

• Self-Determination Theory — Autonomy, Competence, Relatedness for player motivation

• Flow State Design — Challenge-skill balance for player engagement

• Bartle Player Types — Audience targeting and validation

• Verification-Driven Development — Tests first, then implementation

Customization

This is a template, not a locked framework. Everything is meant to be customized:

• 添加/移除代理——删除不需要的代理文件，为你的域名添加新的代理文件

• 编辑代理提示——调整代理行为，添加项目特定知识

• 调整技能——调整工作流程以配合团队流程

• 添加规则——为项目目录结构创建新的路径范围规则

• 调整钩子——调整验证严格性，添加新的检查

• 选择你的引擎——使用Godot、Unity或Unreal代理集（或者不使用）

• 调优工艺权重及其底层旋钮（见配置）。每次游戏都可以覆盖任何技能。modes.rigorproject.yaml--review solo

平台支持

Windows 10 上的主要开发，使用 Git Bash。这些钩子和脚本也在macOS上测试——其自带bash 3.2和BSD工具，有无——以及Linux上。所有钩子都使用兼容POSIX的模式（非），并包含缺失工具的备份。该钩子使用 PowerShell 来发送 Windows 的 Toast 通知，其他地方不适用——macOS/Linux 桌面通知尚未有线连接。请为任何平台特定的故障提交问题。jqgrep -Egrep -Pnotify.sh

社区

• 讨论区 — GitHub 讨论区，提问、分享想法和展示你所构建的内容

• 问题 — 错误报告和功能请求

支持本项目

Claude Code Game Studios 是免费且开源的。如果这能帮你节省时间或帮助你发布游戏，考虑支持持续开发：

• 请我喝咖啡——一次性支持

• GitHub 赞助商——通过 GitHub 提供定期支持

赞助有助于资助维护技能、添加新代理、跟进Claude代码和引擎API变化以及应对社区问题的时间。

为Claude代码打造。维护和扩展——欢迎通过GitHub讨论区进行贡献。

许可

麻省理工学院执照。详情请参见许可。