mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
DonchitosandClaude Opus 5
d05699707f
`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
57 lines
2.7 KiB
Markdown
57 lines
2.7 KiB
Markdown
# Agent Coordination Rules
|
|
|
|
1. **Vertical Delegation**: Leadership agents delegate to department leads, who
|
|
delegate to specialists. Never skip a tier for complex decisions.
|
|
2. **Horizontal Consultation**: Agents at the same tier may consult each other
|
|
but must not make binding decisions outside their domain.
|
|
3. **Conflict Resolution**: When two agents disagree, escalate to the shared
|
|
parent. If no shared parent, escalate to `creative-director` for design
|
|
conflicts or `technical-director` for technical conflicts.
|
|
4. **Change Propagation**: When a design change affects multiple domains, the
|
|
`producer` agent coordinates the propagation.
|
|
5. **No Unilateral Cross-Domain Changes**: An agent must never modify files
|
|
outside its designated directories without explicit delegation.
|
|
|
|
## Model Tier Assignment
|
|
|
|
Read `.claude/docs/model-tiers.md` on demand. It carries the tier table, the
|
|
per-skill assignments and the authoring rule.
|
|
|
|
**One line of it is load-bearing enough to restate here:** a skill's `model:`
|
|
frontmatter is **declared but not applied** — Claude Code reads it and serves the
|
|
skill from the session model regardless. Never tell a user that a skill's tier
|
|
is saving them money. The agent-side `model:` is a different mechanism and is
|
|
untested, not known-broken.
|
|
|
|
## Subagents vs Agent Teams
|
|
|
|
This project uses two distinct multi-agent patterns:
|
|
|
|
### Subagents (current, always active)
|
|
Spawned via the `Agent` tool within a single Claude Code session (renamed from
|
|
`Task` in Claude Code 2.1.63; `Task` still works as an alias). Used by all
|
|
`team-*` skills and orchestration skills. Subagents share the session's
|
|
permission context, run sequentially or in parallel within the session, and
|
|
return results to the parent.
|
|
|
|
**When to spawn in parallel**: If two subagents' inputs are independent (neither
|
|
needs the other's output to begin), spawn both `Agent` calls simultaneously
|
|
rather than waiting. Example: `/review-all-gdds` **Phase 2** (consistency) and
|
|
**Phase 3** (design theory) are independent — spawn both at the same time.
|
|
Phase 1 loads the GDDs and both depend on it, so it is the one phase here that
|
|
must NOT be parallelised.
|
|
|
|
### Agent Teams (experimental — opt-in)
|
|
Multiple independent Claude Code *sessions* coordinated via a shared task list.
|
|
Opt-in and never yet used here — read `.claude/docs/agent-teams.md` on demand
|
|
before proposing one.
|
|
|
|
## Parallel Task Protocol
|
|
|
|
When an orchestration skill spawns multiple independent agents:
|
|
|
|
1. Issue all independent `Agent` calls before waiting for any result
|
|
2. Collect all results before proceeding to dependent phases
|
|
3. If any agent is BLOCKED, surface it immediately — do not silently skip
|
|
4. Always produce a partial report if some agents complete and others block
|