Claude Code Game Studios：用 49 个 AI Agent 与 74 项技能打造完整游戏开发工作室体系

将单个 Claude Code 会话转变为一家完整的游戏开发工作室。
49 个 Agent。74 项技能。一支协调一致的 AI 团队。

---

利用 AI 进行单人游戏开发非常强大——但单一的聊天对话往往缺乏组织架构。没有人会阻止你硬编码魔法数字、跳过设计文档或写出意大利面条式代码；没有 QA 测试环节，没有设计评审，也没有人追问“这真的契合游戏的整体构想吗？”

Claude Code Game Studios 通过为你的 AI 对话赋予真实工作室的组织架构来解决这个问题。你不再只面对一个通用型助手，而是拥有 49 个专门的 Agent，按工作室层级组织起来——把控全局愿景的总监、掌管各自领域的部门主管，以及负责具体执行的专业人员。每个 Agent 都具备明确定义的职责、问题上报路径和质量关卡（quality gates）。

其最终效果是：你依然掌握所有决策权，但此刻你拥有了一支会提出正确问题、及早发现失误，并在从最初头脑风暴到正式发布的整个生命周期中让项目井井有条的团队。

---

---

类别	数量	说明
Agents	49	涵盖设计、程序、美术、音频、叙事、QA 和制作的专业子 Agent
Skills	74	贯穿各工作流阶段的斜杠命令（/start、/design-system、/create-epics、/create-stories、/dev-story、/story-done 等）
Hooks	15	针对 commit、push、资产变更、设计文档读写与登记、会话生命周期、Agent 审计追踪及断层检测的自动化校验
Rules	14	针对游戏玩法、引擎、AI、UI、网络代码、场景及资产文件等编辑操作强制执行的作用域代码规范
Templates	62	涵盖 GDD、UX 规范、ADR、Sprint 计划、HUD 设计、无障碍功能等方面的文档模板

Agent 按三个层级进行划分，与真实工作室的运作方式完全一致：

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

每个 Agent 都在其 Frontmatter 中声明了所使用的模型：三位总监指定使用 Opus；lead-programmer 与另外 15 位专员指定使用 Sonnet；其余 30 位则继承你当前会话的模型。请将这些层级视为角色的资历级别，而非账单套餐——工作室的大多数职能都会直接沿用你当前正在运行的模型。

该模板包含针对三大主流游戏引擎的 Agent 预设套件，请根据你的项目选择对应的一套：

引擎	领衔 Agent	细分专业人员
Godot 4	godot-specialist	GDScript、Shaders、GDExtension
Unity	unity-specialist	DOTS/ECS、Shaders/VFX、Addressables、UI Toolkit
Unreal Engine 5	unreal-specialist	GAS、Blueprints、Replication、UMG/CommonUI

在 Claude Code 中输入 / 即可调取全部 74 项技能：

新手引导与导航（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

用户故事与 Sprint（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，用于协调多个 Agent 完成单项功能）：/team-combat /team-narrative /team-ui /team-release /team-polish /team-audio /team-level /team-live-ops /team-qa

它产出的是游戏，还是文档？

这是一个非常中肯的问题，而其答案来自于一次实际量化测试，而非简单的样例工程。我们根据同一份任务简报（Brief），在不同的 modes.rigor（严谨度级别）下构建了四款游戏，并统计了各自在写下第一行游戏代码之前所生成的文档数量：

modes.rigor	第一行代码前的文档数	耗时
minimal	1（单页简报）	0 分钟
standard	30	58 分钟

所有模式最终都产出了可运行且经过测试的游戏。然而，在两名盲审评测员与人类玩家的试玩评估中，standard 构建版本的综合排名却位列末位——额外撰写的 29 份文档换来的只是可追溯性，而不是更好玩的游戏。

实际运行并观察游戏画面

上述评估关乎研发成本，而另一半核心在于项目是否真正可用。对于一款游戏而言，这意味着必须有人去看它——单元测试通过并不代表菜单不会渲染到屏幕之外。因此，任何改动玩家可见内容的 Story，在游戏被实际启动、观察并将截图归档至 production/qa/evidence/ 之前，都不得标记为关闭。代码解析检查不等于实际运行。这一规则适用于所有严谨度级别，即便是免除自动化测试的 minimal 模式，视觉观察验收也绝不可省去。

这里特意没有附带示例游戏成品：这是一个用于克隆并开启你自己项目的工程模板，仓库中留有别人的游戏只会成为杂物干扰，算不上佐证。

• Git
• Claude Code — 推荐使用官方原生安装器（在 Node.js 22+ 环境下运行 npm install -g @anthropic-ai/claude-code 亦可）
• Python 3 — 各项 Skill 和 Hook 均依赖其读取 project.yaml；缺少该环境所有配置项将静默回退至默认值
• Bash — 运行所有 Hook 的必要环境；macOS 与 Linux 已内置，Windows 环境可随 Git for Windows 一同获取
• 推荐安装：jq（用于 Hook 校验）

当可选工具缺失时，各类 Hook 会优雅降级——你只是失去了部分校验功能——但存在一个特意设计的例外：若暂存区包含数据 JSON 文件但系统中缺少 Python 进行校验，则提交（commit）将被强制拦截。

1. 克隆或将其作为模板使用：

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

2. 在项目根目录下打开 Claude Code（即包含 CLAUDE.md 与 project.yaml 的目录）并开启会话：

若在 src/ 等子目录中启动，将导致项目的 Hook、拒绝规则（deny rules）和先问后动权限模式失效。

3. 运行 /start — 系统会询问你当前的研发进度（毫无头绪、模糊概念、明确设计、已有成果），并引导你进入对应的工作流，不做主观臆断。

如果你已明确知晓需求，亦可直接跳转至对应技能：

 * `/brainstorm` — 从零探索游戏创意构想
 * `/setup-engine godot 4.7` — 直接配置你已选定的游戏引擎
 * `/project-stage-detect` — 剖析与诊断现有项目阶段

仓库根目录下的 project.yaml 是决定工作室在当前项目中所有行为准则的唯一真实数据源（Single Source of Truth）——包含引擎、命名规范，以及控制每个技能流程介入程度的 modes 配置块。/start 会为你自动写入该文件，极少需要手动编辑。

其中最核心的一项配置是 modes.rigor，可选值包含 minimal、standard 或 full。它是统领六个独立控制项的总开关（包括：workflow 决定必须撰写哪些 GDD 章节、docs.density、qa.level、story_granularity、review_mode 决定介入评审的总监级 Agent 数量，以及 team.size），因此 /start 只需向你确认一次，无需重复询问六项细节：

• minimal（默认选项）— 具备 Game Jam 式的高速开发节奏。无需强制编写 GDD，文档简明扼要，保留最低限度的 QA 凭证，单人评审模式。流程为：/start → /setup-engine → /brainstorm（一页纸简报）→ /create-stories → /dev-story ↔ /story-done。
• standard — 必须包含 5 个核心 GDD 章节，文档深度适中，保留标准 QA 凭证，精简评审模式。
• full — 完整覆盖全部 8 项 GDD 章节，详尽文档，对所有 Story 类型保留完备 QA 凭证，总监级团队全量评审。

之所以将 minimal 设为默认值，是因为更重的流程层级在未能产出更优结果的前提下，大幅增加了通往可运行代码的开发成本，且在新成员接手项目时无法带来任何收益。当项目规模扩大时，只需执行一次 /settings 即可完成升级——/help 与 /gate-check 在识别到相应特征时也会主动给出升级建议。

系统提供了两个“逃生舱（escape hatches）”，避免单一全局配置显得过于粗暴：system_overrides 允许对特定系统启用高于全项目的执行标准——例如让战斗系统接受全流程严密管控，其余部分依旧保持轻量；testing.strict 允许按测试类型（逻辑、集成、视觉、UI、配置）单独设置当缺少验证凭据时是直接阻塞 Story 交付还是仅输出警告。

如果你需要混合搭配，底层对应的六个控制参数依然支持单独自定义（例如配置 workflow: full 搭配 docs.density: terse，兼顾全面性与精简度）。其中两项参数——review_mode（full / lean / solo）与 team.size——还支持个人级配置：严谨度模式规定了团队级的默认设定，但开发者可在被 git 忽略的 project.local.yaml 中进行单人本地重写，无需触动团队共享配置。位于严谨度体系之外的 modes.automation（即 AI 在执行动作前暂停求助的频次）同样支持个人单独覆盖。

使用 /settings 技能可随时查看或调整各项配置：

/settings                              # 查看当前生效配置
/settings modes.review_mode            # 查看单项设定
/settings modes.rigor=full             # 写入 project.yaml（团队全局生效）
/settings --local modes.review_mode=solo   # 写入 project.local.yaml（仅对个人生效）

完整 Schema 与每项配置的详细行为说明见：.claude/docs/effects-map.md。

若你已经在使用本模板的旧版本，请参阅 UPGRADING.md 获取逐步迁移说明、版本变更解析，以及了解哪些文件可以安全覆盖、哪些文件需要手动合并。

CLAUDE.md                           # 主配置文件
.claude/
  settings.json                     # 钩子、权限、安全规则配置
  agents/                           # 49 个 Agent 定义（Markdown + YAML Frontmatter）
  skills/                           # 74 个斜杠命令（每个技能对应独立子目录）
  hooks/                            # 18 个脚本（Bash）— 包含 15 个事件钩子、两个由钩子调用的辅助脚本
                                    #   （yaml-helper.sh、update-check.sh）以及一个需自行配置的手动诊断脚本
  rules/                            # 14 项按路径生效的编码规范
  statusline.sh     

Turn a single Claude Code session into a full game development studio.
49 agents. 74 skills. One coordinated AI team.

---

Building a game solo with AI is powerful — but a single chat session has no structure. No one stops you from hardcoding magic numbers, skipping design docs, or writing spaghetti code. There's no QA pass, no design review, no one asking "does this actually fit the game's vision?"

Claude Code Game Studios solves this by giving your AI session the structure of a real studio. Instead of one general-purpose assistant, you get 49 specialized agents organized into a studio hierarchy — directors who guard the vision, department leads who own their domains, and specialists who do the hands-on work. Each agent has defined responsibilities, escalation paths, and quality gates.

The result: you still make every decision, but now you have a team that asks the right questions, catches mistakes early, and keeps your project organized from first brainstorm to launch.

---

---

Category	Count	Description
Agents	49	Specialized subagents across design, programming, art, audio, narrative, QA, and production
Skills	74	Slash commands for every workflow phase (/start, /design-system, /create-epics, /create-stories, /dev-story, /story-done, etc.)
Hooks	15	Automated validation on commits, pushes, asset changes, design-doc reads, writes and registries, session lifecycle, agent audit trail, and gap detection
Rules	14	Path-scoped coding standards enforced when editing gameplay, engine, AI, UI, network code, scene and asset files, and more
Templates	62	Document templates for GDDs, UX specs, ADRs, sprint plans, HUD design, accessibility, and more

Agents are organized into three tiers, matching how real studios operate:

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, lead-programmer 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.

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

Engine	Lead Agent	Sub-Specialists
Godot 4	godot-specialist	GDScript, Shaders, GDExtension
Unity	unity-specialist	DOTS/ECS, Shaders/VFX, Addressables, UI Toolkit
Unreal Engine 5	unreal-specialist	GAS, Blueprints, Replication, UMG/CommonUI

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 modes.rigor levels and the documents each wrote before its first line of game code were counted:

modes.rigor	Docs before first line of game code	Time
minimal	1 (the one-page brief)	0 min
standard	30	58 min

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

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 production/qa/evidence/. A parse check is not a run. This holds at every rigor level, including minimal, where automated tests are waived but the look is not.

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.

• Git
• Claude Code — the native installer is recommended (npm install -g @anthropic-ai/claude-code also works, on Node.js 22+)
• Python 3 — reads project.yaml for every skill and hook; without it every setting silently falls back to its default
• 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.

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 in the project's root folder (the one holding CLAUDE.md and project.yaml) and start a session:

Starting it in a subfolder such as src/ skips the project's hooks, deny rules and ask-first permission mode.

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.7` — configure your engine if you already know
 * `/project-stage-detect` — analyze an existing project

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 modes block that controls how much process every skill enforces. /start writes it for you; you rarely need to hand-edit it.

The one question that matters most is modes.rigor — minimal, standard, or full. It's a single front door over six separate knobs (workflow — which GDD sections are required, docs.density, qa.level, story_granularity, review_mode — how many director agents review your work, and team.size), so /start asks it once instead of six times:

• minimal (default) — jam-game speed. No GDDs required, terse docs, minimal QA evidence, solo review. /start → /setup-engine → /brainstorm (a one-page brief) → /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 the heavier tier costs more to reach working code without producing a better result, and gives nothing back when someone new picks the project up. Raise it in one /settings call when your project grows — /help and /gate-check will suggest it when they see the signs.

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. workflow: full with docs.density: terse — comprehensive but compact). Two of them — review_mode (full / lean / solo) and team.size — are also personal : rigor sets the team-wide default, but you can override them per-developer in a gitignored project.local.yaml without touching the shared config. modes.automation (how often the AI pauses to ask before it acts) sits outside rigor and is likewise personally overridable.

View or change any setting with the /settings skill:

/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.

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.

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/                            # 18 scripts (bash) — 15 event hooks, two helpers they
                                    #   source (yaml-helper.sh, update-check.sh), and one
                                    #   opt-in diagnostic you wire yourself
  rules/                            # 14 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/                      # 62 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
studio-tests/                       # QA for the skills and agents themselves — see below

Testing your customizations

CCGS is a template you are meant to edit. studio-tests/ 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.

/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/.

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 (creative-director for design, technical-director for technical)
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.

That is how a terminal session started at the project root behaves out of the box. The guided and autonomous automation settings, and Claude Code's own auto mode, trade some of these prompts for speed; see setup-requirements.md for the routes into auto mode.

Hooks run automatically on every session:

Hook	Trigger	What It Does
validate-commit.sh	PreToolUse (Bash, PowerShell)	Checks for hardcoded values, TODO format, JSON validity, design doc sections — exits early if the command is not git commit
validate-push.sh	PreToolUse (Bash, PowerShell)	Warns on pushes to protected branches, and on git tag, git merge, gh release, butler push and steamcmd +run_app_build — exits early for any other command
validate-read.sh	PreToolUse (Read)	Refuses a whole-file read of a design doc over 40 KB and answers with its headings, so the retry reads one section (features.read_guard)
validate-write.sh	PreToolUse (Write/Edit)	Warns, never blocks, when a write would break a rule the skills state: a file they never overwrite, the config guard, the prototype boundary, a localization freeze
validate-registry.sh	PreToolUse (Write/Edit)	Warns when a write to the entity or TR-ID registry would delete or renumber an entry, or set a status its header does not list
validate-assets.sh	PostToolUse (Write/Edit)	Checks data-file JSON under assets/, Assets/ or Content/, and asset naming in Godot's assets/ only — exits early if the file is under none of them
session-start.sh	Session open	Shows current branch and recent commits for orientation
detect-gaps.sh	Session open	Detects fresh projects (suggests /start) and missing design docs when code or prototypes exist
pre-compact.sh	Before compaction	Logs the compaction (its output does not reach Claude — session-start.sh restores context afterwards)
notify.sh	Permission prompt, or idle about a minute	Shows Windows toast notification via PowerShell
session-stop.sh	Every response end, in the background	Archives active.md to session log and records git activity
log-agent.sh	Agent spawned	Audit trail start — logs subagent invocation
log-agent-stop.sh	Agent stops	Audit trail stop — completes subagent record
validate-agent-artifact.sh	Agent stops	Warns when a subagent stops without writing the file its brief named
validate-skill-change.sh	PostToolUse (Write/Edit)	Advises running /skill-test after any .claude/skills/ change

Note : validate-commit.sh, validate-push.sh, validate-read.sh, validate-write.sh, validate-registry.sh, validate-assets.sh and validate-skill-change.sh fire on every Bash, PowerShell, Read, Write or Edit 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.

Permission rules in settings.json auto-allow test runs and block dangerous operations (force push, rm -rf, reading .env files) in both the Bash and PowerShell tools. Read-only commands such as git status, git log and ls need no rule: Claude Code runs them without asking. The git rules match anywhere after git, so a git command whose text only mentions push followed later by + or -f, clean followed by -f, or reset followed by --hard — a commit message such as git commit -m "push + pull" included — is denied too: reword the message.

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 Assets/**/Gameplay/ and C++ under Source/**/Gameplay/ (and Core, AI, Networking, UI), data matches JSON under Assets/**/Data/ and Content/**/Data/, shaders match by file type, and tests match C# under Assets/Tests/ and C++ under Source/**/Tests/.

Path	Enforces
src/gameplay/**	Data-driven values, delta time usage, no UI references
src/core/**	Zero allocations in hot paths, thread safety, API stability
src/ai/**	Performance budgets, debuggability, data-driven parameters
src/networking/**	Server-authoritative, versioned messages, security
src/ui/**	No game state ownership, localization-ready, accessibility
design/gdd/**	Required sections per modes.workflow, formula format, edge cases
design/narrative/**	Lore consistency, character voice, canon levels
assets/data/**/*.json	JSON validity, naming conventions, schema rules
assets/shaders/**	Naming conventions, performance targets, cross-platform rules
**/*.tscn, **/*.tres	Scene and resource files changed in the editor where possible; safe hand-edit rules
tests/**	Test naming, coverage requirements, fixture patterns
prototypes/**	Relaxed standards, README required, hypothesis documented

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

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

• Add/remove agents — delete agent files you don't need, add new ones for your domains
• Edit agent prompts — tune agent behavior, add project-specific knowledge
• Modify skills — adjust workflows to match your team's process
• Add rules — create new path-scoped rules for your project's directory structure
• Tune hooks — adjust validation strictness, add new checks
• Pick your engine — use the Godot, Unity, or Unreal agent set (or none)
• Tune process weight — modes.rigor and its underlying knobs in project.yaml (see Configuration). Override per-run with --review solo on any skill.

Primary development on Windows 10 with Git Bash. The hooks and scripts are also tested on macOS — its stock bash 3.2 and BSD tools, with and without jq — and on Linux. All hooks use POSIX-compatible patterns (grep -E, not grep -P) and include fallbacks for missing tools. The notify.sh hook uses PowerShell for Windows toast notifications and is a no-op elsewhere — desktop notifications on macOS/Linux are not yet wired. Please file issues for any platform-specific breakage.

Community

---

Claude Code Game Studios is free and open source. If it saves you time or helps you ship your game, consider supporting continued development:

Sponsorships help fund time spent maintaining skills, adding new agents, keeping up with Claude Code and engine API changes, and responding to community issues.

---

Built for Claude Code. Maintained and extended — contributions welcome viaGitHub Discussions.

MIT License. See LICENSE for details.