Files
Claude-Code-Game-Studios/.claude/docs/director-gates/td-manifest.md
T
DonchitosandClaude Opus 5 d05699707f Release 1.1.0 — one config file, and a process weight you choose
`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
2026-09-23 12:25:11 +10:00

1.3 KiB

Gate definition. The spawning skill passes this file's path to the director agent; the AGENT reads it — the parent session should not.

TD-MANIFEST — Control Manifest Review

Agent: technical-director | Model tier: Opus | Domain: Architecture, engine risk, performance

Trigger: After control-manifest rules are extracted and previewed (/create-control-manifest Phase 4), before the manifest file is written

Context to pass:

  • The Control Manifest Preview from Phase 4 (rule counts per layer, full extracted rule list)
  • The list of ADRs covered
  • Engine version
  • Any rules sourced from technical-preferences.md or engine reference docs

Prompt:

"Review this control manifest before it is written. Are all mandatory ADR patterns captured and accurately stated? Are the forbidden approaches complete and correctly attributed to their source ADR? Were any rules added that lack a source ADR or preference document — that is, invented rather than extracted? Are the performance guardrails consistent with the constraints the ADRs actually set? Return APPROVE, CONCERNS [list the specific rules to revise], or REJECT [rules that are wrong or unsourced and must be fixed before the manifest is written]."

Verdicts: APPROVE / CONCERNS / REJECT