Claude-Code-Game-Studios — AI Agent 工作流中文教程

Prerequisites

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

Getting Started

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