Opening Claude Code in the project root is a consequential step with Claude Code Game Studios. The README says starting in a subfolder skips the project's hooks, deny rules and ask-first permission mode. Before choosing a studio workflow, check that the session is actually using the configuration you intend.
This repository supplies roles, skills and shell hooks for organizing game development. It doesn't include a sample game to play. For someone already building with Claude Code, the attraction is a record of design decisions and a defined path from a feature idea to work that can be inspected. Whether that improves the game remains unmeasured here.
What happened when we ran it
Our October 29, 2026 lab record for commit 05ad7c8 is NOT RUN: the runner had no supported ecosystem for this Shell repository and found no Dockerfile. There are no installation, build or test outcomes to turn into a performance or reliability finding.
That result limits this review to a documentation-based evaluation. The recorded sandbox configuration listed 3 CPUs and 8 GB RAM, with image n/a. It establishes no actual runtime version. In particular, the lack of execution cannot establish that the template is broken or that its hooks enforce their documented rules.
The README describes specialist roles for Godot, Unity and Unreal, with directors and department leads coordinating work. Those are agent definitions and instructions. We have no recorded game-development session establishing the quality of their output, the amount of human correction required or the cost of coordinating them.
Minimal rigor keeps the first feature small
The documented default for modes.rigor is minimal. It allows a short brief and a lighter review process, while standard and full require more design material. This is a useful choice to expose before work begins: decide how much written evidence a small feature needs rather than accepting every available document template.
For a first trial, choose a mechanic you can observe directly, such as a player movement rule. State the intended behavior and ask for the corresponding story. Check whether the workflow keeps that decision visible while implementation changes. This is a proposed evaluation exercise, not a feature we built with the template.
The README allows individual systems to receive stricter treatment through system_overrides. That could suit a project where combat rules need more explanation than a menu label. Keep the extra process attached to a reason you can name. The repository's own comparison of rigor levels is an upstream claim, not a productivity result reproduced by MrKeyoor.
Python and Bash determine which controls can operate
The setup requirements say missing Python makes settings fall back to their defaults. Bash runs the hooks. Merely getting Claude Code to open therefore doesn't establish that your selected configuration is being read or that validation is operating.
The README's getting-started route requires Git and Claude Code as well as those tools, then directs you to open the root containing CLAUDE.md and project.yaml. You'll also need the engine appropriate to the game. The template's engine-specific agents don't remove that separate dependency.
Permission behavior needs a separate check. The setup guide describes root-started terminal sessions using an ask-first default, while resumed sessions retain their previous mode and editor integrations have their own settings. Treat the collaboration instructions and the permission system as separate things to inspect. A sentence asking the model to wait cannot establish that a tool action will be blocked.
A write warning is advisory
The README says the write-validation hook warns and never blocks. That is a concrete reason to avoid treating every named rule as an enforced boundary. If a protected file matters to your project, observe what happens when the workflow proposes changing it and check which mechanism is supposed to stop the write.
Other hooks have different jobs, including commit checks and activity logging. Read the configuration with those distinctions in mind rather than inferring enforcement from the number of hooks. We inspected the write hook's source, which also describes its exit behavior as advisory; we didn't execute it.
Issue 147, opened on October 29, reports a partial stage update at the same commit recorded by our lab. The reporter says a failed second write can leave project.yaml and production/stage.txt inconsistent. We haven't reproduced that report. It gives a specific reason to inspect stage state after a failed transition, rather than assuming a workflow label proves both records agree.
Other workflows change what you organize around
BMad Game Dev Studio documents game design, architecture and production planning with coding agents including Claude Code, Cursor and GitHub Copilot. Its README lists Roblox alongside Unity, Unreal and Godot, and describes custom-engine use. Evaluate that route when the coding tool or engine choices are central to your decision. We didn't verify those compatibility claims.
GSD Core documents a phase loop covering discussion, planning, execution, verification and shipping across several coding tools. Consider it when you want general delivery structure without organizing every task around game-studio roles. We have no comparative cost or productivity result for either alternative.
For a first Game Studios evaluation, keep minimal rigor, start at the root and use a disposable project. Take one visible feature through the workflow, inspect the changed files and retain a screenshot of the running game. Stop at any discrepancy between what the workflow records and what you can actually observe.