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
6.1 KiB
Agent Test Spec: art-director
Agent Summary
Domain owned: Visual identity, art bible authorship and enforcement, asset quality standards, UI/UX visual design, visual phase gate, concept art evaluation. Does NOT own: UX interaction flows and information architecture (ux-designer's domain), audio direction (audio-director), code implementation. Model tier: Sonnet (note: despite the "director" title, art-director is assigned Sonnet per coordination-rules.md — it handles individual system analysis, not multi-document phase gate synthesis at the Opus level). Gate IDs handled: AD-CONCEPT-VISUAL, AD-ART-BIBLE, AD-PHASE-GATE.
Static Assertions (Structural)
Verified by reading the agent's .claude/agents/art-director.md frontmatter:
description:field is present and domain-specific (references visual identity, art bible, asset standards — not generic)allowed-tools:list is read-focused; image review capability if supported; no Bash unless asset pipeline checks are justified- Model tier is
claude-sonnet-5(NOT Opus — coordination-rules.md assigns Sonnet to art-director) - Agent definition does not claim authority over UX interaction flows or audio direction
Test Cases
Case 1: In-domain request — appropriate output format
Scenario: The art bible's color palette section is submitted for review. The section defines a desaturated earth-tone primary palette with high-contrast accent colors tied to the game pillar "beauty in decay." The palette is internally consistent and references the pillar vocabulary. Request is tagged AD-ART-BIBLE.
Expected: Returns AD-ART-BIBLE: APPROVE with rationale confirming the palette's internal consistency and its alignment with the stated pillar.
Assertions:
- Verdict is exactly one of APPROVE / CONCERNS / REJECT
- Verdict token is formatted as
AD-ART-BIBLE: APPROVE - Rationale references the specific palette characteristics and pillar alignment — not generic art advice
- Output stays within visual domain — does not comment on UX interaction patterns or audio mood
Case 2: Out-of-domain request — redirects or escalates
Scenario: Sound designer asks art-director to specify how ambient audio should layer and duck when the player enters a combat zone. Expected: Agent declines to define audio behavior and redirects to audio-director. Assertions:
- Does not make any binding decision about audio layering or ducking behavior
- Explicitly names
audio-directoras the correct handler - May note if the audio has visual mood implications (e.g., "the audio should match the visual tension of the zone"), but defers all audio specification to audio-director
Case 3: Gate verdict — correct vocabulary
Scenario: Concept art for the protagonist is submitted. The art uses a vivid, saturated color palette (primary: #FF4500, #00BFFF) that directly contradicts the established art bible's "desaturated earth-tones" palette specification. Request is tagged AD-CONCEPT-VISUAL.
Expected: Returns AD-CONCEPT-VISUAL: CONCERNS with specific citation of the palette discrepancy, referencing the art bible's stated palette values versus the submitted concept's palette.
Assertions:
- Verdict is exactly one of APPROVE / CONCERNS / REJECT — not freeform text
- Verdict token is formatted as
AD-CONCEPT-VISUAL: CONCERNS - Rationale specifically identifies the palette conflict — not a generic "doesn't match style" comment
- References the art bible as the authoritative source for the correct palette
Case 4: Conflict escalation — correct parent
Scenario: ux-designer proposes using high-contrast, brightly colored icons for the HUD to improve readability. art-director believes this violates the art bible's muted visual language and would undermine the visual identity. Expected: art-director states the visual identity concern and references the art bible, acknowledges ux-designer's readability goal as legitimate, and escalates to creative-director to arbitrate the trade-off between visual coherence and usability. Assertions:
- Escalates to
creative-director(shared parent for creative domain conflicts) - Does not unilaterally override ux-designer's readability recommendation
- Clearly frames the conflict as a trade-off between two legitimate goals
- References the specific art bible rule being violated
Case 5: Context pass — uses provided context
Scenario: Agent receives a gate context block that includes the existing art bible with specific palette values (primary: #8B7355, #6B6B47; accent: #C8A96E) and style rules ("no pure white, no pure black; all shadows have warm undertones"). A new asset is submitted for review. Expected: Assessment references the specific hex values and style rules from the provided art bible, not generic color theory advice. Any concerns are tied to specific violations of the provided rules. Assertions:
- References specific palette values from the provided art bible context
- Applies the specific style rules (no pure white/black, warm shadow undertones) from the provided document
- Does not generate generic art direction feedback disconnected from the supplied art bible
- Verdict rationale is traceable to specific lines or rules in the provided context
Protocol Compliance
- Returns verdicts using APPROVE / CONCERNS / REJECT vocabulary only
- Stays within declared visual domain
- Escalates UX-vs-visual conflicts to creative-director
- Uses gate IDs in output (e.g.,
AD-ART-BIBLE: APPROVE) not inline prose verdicts - Does not make binding UX interaction, audio, or code implementation decisions
Coverage Notes
- AD-PHASE-GATE (full visual phase advancement) is not covered — deferred to integration with /gate-check skill.
- Asset pipeline standards (file format, resolution, naming conventions) compliance checks are not covered here.
- Shader visual output review is not covered — that interaction with the engine specialist is deferred.
- UI component visual review (as distinct from UX flow review) could benefit from additional cases.