Files
Claude-Code-Game-Studios/CLAUDE.md
T
DonchitosandClaude Opus 5.5 be8993bbc5 Release 1.1.3 — long skills keep their later steps
Fix release for 1.1.2: the 14 longest skills keep their later phases
after a compaction, a question nobody answered is never taken as an
answer, settings read the same from a subfolder, the commit check works
for a project in a subfolder of a larger repository, every skill opens
with a title, and the shipped allow rules no longer approve deleting a
branch or writing files without asking. Details in CHANGELOG.md; upgrade
steps in UPGRADING.md (v1.1.2 → v1.1.3).

Refs #83
Refs #133

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
2026-10-08 17:52:48 +11:00

3.5 KiB

Claude Code Game Studios -- Game Studio Agent Architecture

Indie game development managed through 49 coordinated Claude Code subagents. Each agent owns a specific domain, enforcing separation of concerns and quality.

Technology Stack

  • Engine: [CHOOSE: Godot 4 / Unity / Unreal Engine 5]
  • Language: [CHOOSE: GDScript / C# / C++ / Blueprint]
  • Version Control: Git with trunk-based development
  • Build System: [SPECIFY after choosing engine]
  • Asset Pipeline: [SPECIFY after choosing engine]

Note

: Engine-specialist agents exist for Godot, Unity, and Unreal with dedicated sub-specialists. Use the set matching your engine.

Project Structure

@.claude/docs/directory-structure.md

Engine Version Reference

@docs/engine-reference/godot/VERSION.md

Technical Preferences

project.yaml at the repo root is the primary config store — engine, specialists, naming, platform, performance, modes. Skills resolve it via resolve_config (see .claude/docs/config-resolution.md).

.claude/docs/technical-preferences.md is the legacy fallback, read on demand when a key is absent from project.yaml. It is no longer imported here: before /setup-engine runs it is almost entirely [TO BE CONFIGURED] placeholders, and after it runs project.yaml holds the real values.

Coordination Rules

@.claude/docs/coordination-rules.md

Collaboration Protocol

User-driven collaboration, not autonomous execution. Every task follows: Question -> Options -> Decision -> Draft -> Approval

  • Agents MUST ask "May I write this to [filepath]?" before using Write/Edit tools (exempt: active.md appends, agent memory, a subagent's new file at the path its orchestrating skill named; see .claude/rules/agent-memory.md)
  • Agents MUST show drafts or summaries before requesting approval
  • Multi-file changes require explicit approval for the full changeset
  • No commits without user instruction
  • A skipped or dismissed question is not an answer: act on nothing, re-ask in plain text and wait
  • Started outside this file's folder? Warn first: hooks, deny rules and the ask-first mode load only when Claude Code starts here

See docs/COLLABORATIVE-DESIGN-PRINCIPLE.md for full protocol and examples.

First session? If the project has no engine configured and no game concept, run /start to begin the guided onboarding flow.

Coding Standards

@.claude/docs/coding-standards.md

Context Management

Read .claude/docs/context-management.md on demand — it is a reference, not session context. Two of its conventions are load-bearing and cited by name elsewhere in the repo, so they are restated here rather than lost:

  • production/session-state/active.md is the session checkpoint. The file is the memory, not the conversation. Read it first after any compaction, crash, or /clear.
  • Helpers in .claude/scripts/ emit observations, never verdicts. A script that scores or judges will eventually contradict a mode or override it cannot see. (Cited by artifact-check.sh and adr-dep-graph.sh.)