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
85 lines
6.6 KiB
Markdown
85 lines
6.6 KiB
Markdown
# Agent Test Spec: game-designer
|
|
|
|
## Agent Summary
|
|
**Domain owned:** Core loop design, progression systems, combat mechanics rules, economy design, player-facing rules and interactions.
|
|
**Does NOT own:** Code implementation (lead-programmer / gameplay-programmer), visual art (art-director), narrative lore and story (narrative-director — coordinates with), balance formula math (systems-designer — collaborates with).
|
|
**Model tier:** Sonnet (individual system design authoring and review).
|
|
**Gate IDs handled:** Design review verdicts on mechanic specs (no named gate ID prefix — uses APPROVED / NEEDS REVISION vocabulary).
|
|
|
|
---
|
|
|
|
## Static Assertions (Structural)
|
|
|
|
Verified by reading the agent's `.claude/agents/game-designer.md` frontmatter:
|
|
|
|
- [ ] `description:` field is present and domain-specific (references core loop, progression, combat rules, economy, player-facing design — not generic)
|
|
- [ ] `allowed-tools:` list is read-focused; includes Read for GDDs and design docs; no Bash unless design tooling requires it
|
|
- [ ] Model tier is `claude-sonnet-5` per coordination-rules.md
|
|
- [ ] Agent definition does not claim authority over code implementation, visual art style, or standalone narrative lore decisions
|
|
|
|
---
|
|
|
|
## Test Cases
|
|
|
|
### Case 1: In-domain request — appropriate output format
|
|
**Scenario:** A mechanic spec for a "Stamina-Based Dodge" system is submitted for review. The spec defines: the player has a stamina pool (100 units), each dodge costs 25 stamina, stamina regenerates at 20 units/second when not dodging, and the dodge grants 0.3 seconds of invincibility. The core loop interaction is clearly described, rules are unambiguous, and edge cases (stamina at 0, dodge during regen) are addressed.
|
|
**Expected:** Returns `APPROVED` with rationale confirming the core loop clarity, unambiguous rules, and edge case coverage.
|
|
**Assertions:**
|
|
- [ ] Verdict is exactly one of APPROVED / NEEDS REVISION
|
|
- [ ] Rationale references specific design quality criteria (clear rules, edge case coverage, core loop coherence)
|
|
- [ ] Output stays within design scope — does not comment on how to implement it in code or what art assets it requires
|
|
- [ ] Verdict is clearly labeled with context (e.g., "Mechanic Spec Review: APPROVED")
|
|
|
|
### Case 2: Out-of-domain request — redirects or escalates
|
|
**Scenario:** A team member asks game-designer to write the in-world lore explanation for why the stamina system exists (e.g., the narrative reason characters have stamina limits in the game world).
|
|
**Expected:** Agent declines to write narrative/lore content and redirects to writer or narrative-director.
|
|
**Assertions:**
|
|
- [ ] Does not write narrative or lore content
|
|
- [ ] Explicitly names `writer` or `narrative-director` as the correct handler
|
|
- [ ] May note the design intent that the lore should support (e.g., "the stamina system should reinforce the physical realism theme"), but defers the writing to the narrative team
|
|
|
|
### Case 3: Gate verdict — correct vocabulary
|
|
**Scenario:** A mechanic spec for "Environmental Hazard Damage" is submitted. The spec defines three hazard types (fire, acid, electricity) but does not specify what happens when a player is simultaneously affected by multiple hazard types, what happens when a hazard is applied during the invincibility window from a dodge, or what the damage frequency is (per-second, per-tick, on-enter).
|
|
**Expected:** Returns `NEEDS REVISION` with specific identification of the undefined edge cases: multi-hazard interaction, hazard-during-invincibility, and damage frequency specification.
|
|
**Assertions:**
|
|
- [ ] Verdict is exactly one of APPROVED / NEEDS REVISION — not freeform text
|
|
- [ ] Rationale identifies the specific missing edge cases by name
|
|
- [ ] Does not reject the entire mechanic — identifies the specific gaps to fill
|
|
- [ ] Provides actionable guidance on what to define (not how to implement it)
|
|
|
|
### Case 4: Conflict escalation — correct parent
|
|
**Scenario:** systems-designer proposes a damage formula with 6 variables and complex scaling interactions, arguing it produces the best tuning granularity. game-designer believes the formula is too complex for players to intuit and want a simpler 2-variable version.
|
|
**Expected:** game-designer owns the conceptual rule and player experience intention ("the damage should feel understandable to players"), but defers the formula granularity question to systems-designer. If the disagreement cannot be resolved between them (one wants complex, one wants simple), escalate to creative-director for a player experience ruling.
|
|
**Assertions:**
|
|
- [ ] Clearly states the player experience intention (intuitive damage, player agency)
|
|
- [ ] Defers formula granularity decisions to `systems-designer`
|
|
- [ ] Escalates unresolved disagreement to `creative-director` for player experience arbiter ruling
|
|
- [ ] Does not unilaterally impose a formula structure on systems-designer
|
|
|
|
### Case 5: Context pass — uses provided context
|
|
**Scenario:** Agent receives a gate context block that includes the game's three pillars: "player authorship," "consequence permanence," and "world responsiveness." A new mechanic spec for "permadeath with legacy bonuses" is submitted for review.
|
|
**Expected:** Assessment evaluates the mechanic against all three provided pillars — how does permadeath support player authorship, how do legacy bonuses express consequence permanence, and how does the world respond to a player's death? Uses the pillar vocabulary directly in the rationale.
|
|
**Assertions:**
|
|
- [ ] References all three provided pillars by name in the assessment
|
|
- [ ] Evaluates the mechanic's contribution to each pillar explicitly
|
|
- [ ] Does not generate generic game design advice — all feedback is tied to the provided pillar vocabulary
|
|
- [ ] Identifies if any pillar creates a tension with the mechanic and flags it with a specific concern
|
|
|
|
---
|
|
|
|
## Protocol Compliance
|
|
|
|
- [ ] Returns verdicts using APPROVED / NEEDS REVISION vocabulary only
|
|
- [ ] Stays within declared game design domain
|
|
- [ ] Escalates design-vs-formula conflicts to creative-director when unresolved
|
|
- [ ] Does not make binding code implementation, visual art, or standalone lore decisions
|
|
- [ ] Provides actionable design feedback, not implementation prescriptions
|
|
|
|
---
|
|
|
|
## Coverage Notes
|
|
- Economy design review (resource sinks, faucets, inflation prevention) is not covered — a dedicated case should be added.
|
|
- Progression system review (XP curves, unlock gates, player power trajectory) is not covered.
|
|
- Core loop validation across multiple interconnected systems (not just a single mechanic) is not covered — deferred to /review-all-gdds integration.
|
|
- Coordination protocol with systems-designer on formula ownership boundary could benefit from additional cases.
|