`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
1.4 KiB
Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.
AD-PHASE-GATE — Visual Readiness at Phase Transition
Agent: art-director | Model tier: Sonnet | Domain: Visual identity, art bible, visual production readiness
Trigger: Always at /gate-check — spawn in parallel with CD-PHASE-GATE, TD-PHASE-GATE, and PR-PHASE-GATE
Context to pass:
- Target phase name
- List of all art/visual artifacts present (file paths)
- Visual identity anchor from
design/gdd/game-concept.md(if present) - Art bible path if it exists (
design/art/art-bible.md)
Prompt:
"Review the current project state for [target phase] gate readiness from a visual direction perspective. Is the visual identity established and documented at the level this phase requires? Are the right visual artifacts in place? Would visual teams be able to begin their work without visual direction gaps that cause costly rework later? Are there visual decisions that are being deferred past their latest responsible moment? Return READY, CONCERNS [specific visual direction gaps that could cause production rework], or NOT READY [visual blockers that must exist before this phase can succeed — specify what artifact is missing and why it matters at this stage]."
Verdicts: READY / CONCERNS / NOT READY