A Claude Code game development studio

Claude Code Game Studios is a game project template you can copy. It stores agent roles, skills, configuration resolution, file conventions and hooks in the repository so Claude Code can divide tasks across game design, programming, art, audio, testing and production management.

Start with a game idea, an existing design or an existing project. The workflow produces a game brief, design documents, development work items, code and acceptance records. Users still need to provide the engine environment, choose a design direction and check whether the game meets their expectations.

This template suits individuals or small teams with basic game development skills who want to divide AI work into tasks they can check. It includes roles and workflows for Godot, Unity and Unreal; it does not include a complete game or replace the licenses and usage costs of those engines, Claude Code or external assets.

Check the tools first. jq is recommended; the other version outputs must match the installed tools, and Python must report Python 3:

On Windows, Python 3 may also use python or py; check the actual installation. Without Python, configuration may fall back to defaults and the validation script will block commits containing staged data JSON; without Bash, hooks cannot run.

Clone the template into your working directory and start from the root containing CLAUDE.md, project.yaml and .claude/:

This retrieves the default branch at the time you run it; compare against this manual's pinned commit when checking differences. GitHub's Use this template is another official starting method; preserve the original project and custom settings before adopting the template in an existing game or upgrading later.

After a direct clone, origin still points to the template repository. Before your first push, confirm the destination with git remote -v and switch to your own game repository; /start also warns when a remote still points upstream.

Enter /start in Claude Code and explain whether you have no idea yet, a concept, a design or an existing game. The skill checks the project state and, after approval, saves the stage, rigor and automation preferences. It then identifies the next step without executing it.

Engine setup updates project.yaml, CLAUDE.md and the engine reference documents. Check the code root: Godot normally uses src/, Unity uses Assets/ and Unreal uses Source/<Module>/; do not let the agent put all Unity or Unreal code in src/.

The Godot workflow can propose creating project.godot when project files are missing. For Unity and Unreal, first create the engine project through the official Hub or editor, then return to setup; the skill does not install the engine for the user.

modes.rigor determines how much documentation, review and test evidence the workflow requires; modes.automation determines when the agent asks the user. They are separate settings, so increasing rigor does not authorize more autonomous actions.

GDD means Game Design Document and records gameplay and system specifications; ADR means Architecture Decision Record and records technical decisions and their reasons. Heavier workflows connect requirements, decisions, implementation and tests, while increasing the work needed to produce and maintain documents.

The default always-ask categories are scope_changes, file_deletions and schema_changes. These are the template's collaboration rules; Claude Code's tool permissions, session mode and execution environment still affect actual behavior.

Use /settings to check effective values and their sources, then change the settings you need:

Configuration precedence starts with allowed personal overrides in project.local.yaml, followed by shared project.yaml, corresponding legacy text files, values expanded from modes.rigor, and finally the documented defaults. Invalid enum values are skipped and listed in diagnostics; the source beside each effective value helps identify an incorrect override.

modes.rigor expands into the following six settings. Explicitly writing any one of them pins that value and overrides the rigor-derived value; write only the settings you intend to override:

• modes.workflow and docs.density.

• qa.level and modes.story_granularity.

• modes.review_mode and team.size.

project.local.yaml accepts only personal settings on an allowlist, such as review mode, team size and automation preferences. Put modes.rigor in shared configuration; placing it in the local file produces a diagnostic and cannot change the team's artifact requirements.

Use a system-level override when only one system, such as combat, needs a more complete design; settings such as testing.strict.* affect whether test evidence blocks closure. Check workflow, qa.level and the actual acceptance thresholds separately to confirm current requirements.

Enter slash commands inside Claude Code, not in a regular shell. Start with the main workflow and select other skills when their tasks arise:

Agent definitions cover directors, department leads and specialists. The hierarchy determines responsibility and escalation paths; the current skill, team settings and task needs determine which agents are called.

creative-director, technical-director and producer specify Opus; some leads and specialists specify Sonnet, while the others inherit the current session model. Assess costs from actual calls, context and retries; the three role levels do not form a fixed model-cost hierarchy.

Coordination rules require vertical delegation, consultation at the same level and conflict resolution by a shared superior; producer coordinates changes across departments, and edits across domains require explicit delegation. prototyper uses an isolated worktree by default, but the other collaboration rules do not automatically create file locks, isolation for every role or a release queue.

The prototyper worktree starts from the last commit and may not see uncommitted engine settings or the brief. Before starting it, confirm that required inputs are saved in an available revision; after it returns, inspect the reported worktree path and branch before deciding whether to merge or copy the result into the main project.

A Story is an implementable work item with acceptance criteria, scope and the necessary technical basis. /dev-story checks dependencies, ADR status and workflow requirements before selecting a programming agent; Config/Data work can change data values directly without starting another programming agent.

/story-done checks files, reads evidence and asks about results it cannot determine directly, but does not run tests. "A test file exists" proves only that a file exists; claiming a test passed still requires a record of an actual run.

For player-visible changes, the run-and-observe procedure requires opening the game, reaching the affected screen, capturing a screenshot and inspecting the image. Save images in production/qa/evidence/ and use file hashes to record the code the evidence corresponds to; after code changes, an old image cannot automatically count as evidence for the new version.

Currently, /story-done reports stale or missing hash stamps without changing the acceptance conclusion. Users still need to confirm that affected screens were captured again. Game feel, response time and audio synchronization require actual play; static screenshots cannot establish them.

The README simplifies the requirement that visual evidence is needed for closure; explicit overrides also affect the actual threshold. Read OBSERVED, N/A or NOT VERIFIED in the completion record and check that any N/A has a reason appropriate to the scenario.

Hooks differ in their triggers and exit codes, so check each script before treating it as a mandatory block. This research used isolated cases to test data JSON, full and bounded reads, push warnings and overwrite warnings:

.claude/settings.json also contains tool allow and deny rules and permissions.defaultMode. Template modes, Claude Code session permissions and GitHub branch protection control different layers of operation; a prompt saying "approval required" does not replace actual permission controls.

Notifications on Windows use PowerShell; the same script does not show desktop notifications on macOS or Linux. Some Git deny rules match command text, so even matching text inside a commit message may be intercepted; inspect the command and message first instead of removing the whole rule set to make them pass.

The following request and sequence illustrate a small collection game in Godot; this research did not execute or produce that game. The user's environment and /setup-engine determine the engine version; complete the approvals required by the current collaboration mode at each step before proceeding.

More complete workflows add system design, architecture and Epics; standard/full Stories first go through /story-readiness, then /code-review after implementation as required, before reaching /story-done. Use the effective settings to decide which skills to run.

Save the current version before changing agents, skills, path rules or hooks. Verify a concrete workflow: after changing /dev-story, for example, check that it still recognizes unaccepted ADRs, limits file scope and reports missing evidence.

The four /skill-test modes read skill and specification files without invoking the skill under test. Score changes from /skill-improve only reflect that checking method; verifying execution behavior still requires a controlled task. Framework quality specifications live in studio-tests/, while game tests live in the project's appropriate test root.

This research tested shell syntax, configuration resolution and some hook behaviors in an isolated copy; it did not start a Claude Code agent workflow or build or play Godot, Unity or Unreal games. These checks support the descriptions of script behavior, not a claim that game output quality has been verified.

Before upgrading, create a recoverable Git revision and read UPGRADING.md. When the project shares Git history with the template, the official instructions recommend adding an upstream remote and merging; without shared history, use selective updates or manual merging instead of forcing unrelated histories together.

On first adoption, complete one small game's playable flow and evidence before deciding which systems need more documentation and review. Teams already using another Agent Harness can first borrow Story contracts, configuration-source display and visual game evidence, verifying each before integrating more roles.

Verification date: 2026-10-20. Community entry points are GitHub Discussions and Issues. The source code uses the MIT License; retain the notices required by that license when distributing the corresponding material.