mirror of
https://github.com/Donchitos/Claude-Code-Game-Studios.git
synced 2026-10-16 01:37:05 +00:00
DonchitosandClaude Opus 5.5
be8993bbc5
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
56 lines
2.7 KiB
Markdown
56 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.
|
|
|
|
**Key point:** whether a skill's `model:` is used
|
|
depends on how the skill starts. Typed as `/skill-name`: yes, except a `haiku`
|
|
pin in auto mode. Started by Claude through the Skill tool: no. Never tell a
|
|
user a `haiku` skill saves money; an `opus` skill typed in a Sonnet session
|
|
costs more. The agent-side `model:` is a different mechanism, and is applied.
|
|
|
|
## 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 only — 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
|