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.1 KiB
Markdown
85 lines
6.1 KiB
Markdown
# Agent Test Spec: creative-director
|
|
|
|
## Agent Summary
|
|
**Domain owned:** Creative vision, game pillars, GDD alignment, systems decomposition feedback, narrative direction, playtest feedback interpretation, phase gate (creative aspect).
|
|
**Does NOT own:** Technical architecture or implementation details (delegates to technical-director), production scheduling (producer), visual art style execution (delegates to art-director).
|
|
**Model tier:** Opus (multi-document synthesis, high-stakes phase gate verdicts).
|
|
**Gate IDs handled:** CD-PILLARS, CD-GDD-ALIGN, CD-SYSTEMS, CD-NARRATIVE, CD-PLAYTEST, CD-PHASE-GATE.
|
|
|
|
---
|
|
|
|
## Static Assertions (Structural)
|
|
|
|
Verified by reading the agent's `.claude/agents/creative-director.md` frontmatter:
|
|
|
|
- [ ] `description:` field is present and domain-specific (references creative vision, pillars, GDD alignment — not generic)
|
|
- [ ] `allowed-tools:` list is read-heavy; should not include Bash unless justified by a creative workflow need
|
|
- [ ] Model tier is `claude-opus-4-8` per coordination-rules.md (directors with gate synthesis = Opus)
|
|
- [ ] Agent definition does not claim authority over technical architecture or production scheduling
|
|
|
|
---
|
|
|
|
## Test Cases
|
|
|
|
### Case 1: In-domain request — appropriate output format
|
|
**Scenario:** A game concept document is submitted for pillar review. The concept describes a narrative survival game built around three pillars: "emergent stories," "meaningful sacrifice," and "lived-in world." Request is tagged CD-PILLARS.
|
|
**Expected:** Returns `CD-PILLARS: APPROVE` with rationale citing how each pillar is represented in the concept and any reinforcing or weakening signals found in the document.
|
|
**Assertions:**
|
|
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT
|
|
- [ ] Verdict token is formatted as `CD-PILLARS: APPROVE` (gate ID prefix, colon, verdict keyword)
|
|
- [ ] Rationale references the three specific pillars by name, not generic creative advice
|
|
- [ ] Output stays within creative scope — does not comment on engine feasibility or sprint schedule
|
|
|
|
### Case 2: Out-of-domain request — redirects or escalates
|
|
**Scenario:** Developer asks creative-director to review a proposed PostgreSQL schema for storing player save data.
|
|
**Expected:** Agent declines to evaluate the schema and redirects to technical-director.
|
|
**Assertions:**
|
|
- [ ] Does not make any binding decision about the schema design
|
|
- [ ] Explicitly names `technical-director` as the correct handler
|
|
- [ ] May note whether the data model has creative implications (e.g., what player data is tracked), but defers structural decisions entirely
|
|
|
|
### Case 3: Gate verdict — correct vocabulary
|
|
**Scenario:** A GDD for the "Crafting" system is submitted. Section 4 (Formulas) defines a resource decay formula that punishes exploration — contradicting the Player Fantasy section which calls for "freedom to roam without fear." Request is tagged CD-GDD-ALIGN.
|
|
**Expected:** Returns `CD-GDD-ALIGN: CONCERNS` with specific citation of the contradiction between the formula behavior and the Player Fantasy statement.
|
|
**Assertions:**
|
|
- [ ] Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
|
|
- [ ] Verdict token is formatted as `CD-GDD-ALIGN: CONCERNS`
|
|
- [ ] Rationale quotes or directly references GDD Section 4 (Formulas) and the Player Fantasy section
|
|
- [ ] Does not prescribe a specific formula fix — that belongs to systems-designer
|
|
|
|
### Case 4: Conflict escalation — correct parent
|
|
**Scenario:** technical-director raises a concern that the core loop mechanic (real-time branching conversations) is prohibitively expensive to implement and recommends cutting it. creative-director disagrees on creative grounds.
|
|
**Expected:** creative-director acknowledges the technical constraint, does not override technical-director's feasibility assessment, but retains authority to define what the creative goal is. For the conflict itself, creative-director is the top-level creative escalation point and defers to technical-director on implementation feasibility while advocating for the design intent. The resolution path is for both to jointly present trade-off options to the user.
|
|
**Assertions:**
|
|
- [ ] Does not unilaterally override technical-director's feasibility concern
|
|
- [ ] Clearly separates "what we want creatively" from "how it gets built"
|
|
- [ ] Proposes presenting trade-offs to the user rather than resolving unilaterally
|
|
- [ ] Does not claim to own implementation decisions
|
|
|
|
### Case 5: Context pass — uses provided context
|
|
**Scenario:** Agent receives a gate context block that includes the game pillars document (`design/gdd/pillars.md`) and a new mechanic spec for review. The pillars document defines "player authorship," "consequence permanence," and "world responsiveness" as the three core pillars.
|
|
**Expected:** Assessment uses the exact pillar vocabulary from the provided document, not generic creative heuristics. Any approval or concern is tied back to one or more of the three named pillars.
|
|
**Assertions:**
|
|
- [ ] Uses the exact pillar names from the provided context document
|
|
- [ ] Does not generate generic creative feedback disconnected from the supplied pillars
|
|
- [ ] References the specific pillar(s) most relevant to the mechanic under review
|
|
- [ ] Does not reference pillars not present in the provided document
|
|
|
|
---
|
|
|
|
## Protocol Compliance
|
|
|
|
- [ ] Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
|
|
- [ ] Stays within declared creative domain
|
|
- [ ] Escalates conflicts by presenting trade-offs to user rather than unilateral override
|
|
- [ ] Uses gate IDs in output (e.g., `CD-PILLARS: APPROVE`) not inline prose verdicts
|
|
- [ ] Does not make binding cross-domain decisions (technical, production, art execution)
|
|
|
|
---
|
|
|
|
## Coverage Notes
|
|
- Multi-gate scenario (e.g., single submission triggering both CD-PILLARS and CD-GDD-ALIGN) is not covered here — deferred to integration tests.
|
|
- CD-PHASE-GATE (full phase advancement) involves synthesizing multiple sub-gate results; this complex case is deferred.
|
|
- Playtest report interpretation (CD-PLAYTEST) is not covered — a dedicated case should be added when the playtest-report skill produces structured output.
|
|
- Interaction with art-director on visual-pillar alignment is not covered.
|