mirror of https://github.com/Donchitos/Claude-Code-Game-Studios.git synced 2026-10-16 01:37:05 +00:00

Files

T

DonchitosandClaude Opus 5 d05699707f Release 1.1.0 — one config file, and a process weight you choose

`project.yaml` at the repo root is now the single source of truth for a
project's configuration, replacing `production/stage.txt`,
`production/review-mode.txt` and `.claude/docs/technical-preferences.md` (all
three still read as a fallback; nothing is force-deleted).

**`modes.rigor` — one question instead of six.** `minimal`, `standard` or
`full` fronts six knobs: `modes.workflow`, `docs.density`, `qa.level`,
`modes.story_granularity`, `modes.review_mode` and `team.size`. It defaults to
`minimal`, which is a change from 1.0's behaviour: the heavier tier was
measured costing several times more to reach working code without producing a
better result, and returning nothing when a fresh developer inherited the
project. Pin `modes.rigor: standard` to keep 1.0's process level.

Also in this release:

- `/settings` to view or change any setting, and `project.local.yaml` for
  per-developer preferences that should not be committed.
- `system_overrides` to hold one system to a higher standard than the rest of
  the project, and `testing.strict` to set per test type whether missing
  evidence blocks a story or warns.
- 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 code root is engine-specific and enforced as such: Godot `src/`, Unity
  `Assets/`, Unreal `Source/<Module>/`. Two of the three will not build a
  project laid out any other way.
- Migration tooling for existing projects: `.claude/scripts/migrate-v1-config.sh`
  converts a 1.0 layout, non-destructively by default, with a report to review
  before `--finalize` deletes anything.
- Ask-before-write holds regardless of personal automation settings.

Upgrading from 1.0 or earlier: see UPGRADING.md. Full list of changes:
CHANGELOG.md.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016xvzG3i7pWQg4LjyDwWMXd

2026-09-23 12:25:11 +10:00

godot

Release 1.1.0 — one config file, and a process weight you choose

2026-09-23 12:25:11 +10:00

unity

Release 1.1.0 — one config file, and a process weight you choose

2026-09-23 12:25:11 +10:00

unreal

Release 1.1.0 — one config file, and a process weight you choose

2026-09-23 12:25:11 +10:00

README.md

Game Studio Agent Architecture — complete setup (Phases 1-7)

2026-02-13 21:04:24 +11:00

README.md

Engine Reference Documentation

This directory contains curated, version-pinned documentation snapshots for the game engine(s) used in this project. These files exist because LLM knowledge has a cutoff date and game engines update frequently.

Why This Exists

Claude's training data has a knowledge cutoff (currently May 2025). Game engines like Godot, Unity, and Unreal ship updates that introduce breaking API changes, new features, and deprecated patterns. Without these reference files, agents will suggest outdated code.

Structure

Each engine gets its own directory:

<engine>/
├── VERSION.md              # Pinned version, verification date, knowledge gap window
├── breaking-changes.md     # API changes between versions, organized by risk level
├── deprecated-apis.md      # "Don't use X → Use Y" lookup tables
├── current-best-practices.md  # New practices not in model training data
└── modules/                # Per-subsystem quick references (~150 lines max each)
    ├── rendering.md
    ├── physics.md
    └── ...

How Agents Use These Files

Engine-specialist agents are instructed to:

Read VERSION.md to confirm the current engine version
Check deprecated-apis.md before suggesting any engine API
Consult breaking-changes.md for version-specific concerns
Read relevant modules/*.md for subsystem-specific work

Maintenance

When to Update

After upgrading the engine version
When the LLM model is updated (new knowledge cutoff)
After running /refresh-docs (if available)
When you discover an API the model gets wrong

How to Update

Update VERSION.md with the new engine version and date
Add new entries to breaking-changes.md for the version transition
Move newly deprecated APIs into deprecated-apis.md
Update current-best-practices.md with new patterns
Update relevant modules/*.md with API changes
Set "Last verified" dates on all modified files

Quality Rules

Every file must have a "Last verified: YYYY-MM-DD" date
Keep module files under 150 lines (context budget)
Include code examples showing correct/incorrect patterns
Link to official documentation URLs for verification
Only document things that differ from the model's training data