Reviews a game design document for completeness, internal consistency, implementability, and adherence to project design standards. Run this before handing a design document to programmers.

! bash "${CLAUDE SKILL DIR}/../../hooks/yaml helper.sh" resolve config keys review mode,automation,workflow,system overrides Resolved above — use as is; review overrides review mode . depth is the pre 1.1 name for the same flag: treat depth <mode exactly as review <mode , and say once that it was renamed. Given both, review wins and depth is ignored — say so. No block → defaults in .claude/docs/config resolution.md . Design Review Phase 0: Parse Arguments See .claude/docs/director gates.md for the full check pattern. Individual gate definitions live in .claude/docs/director gates/[gate id].md — the spawned agent reads its own gate file; do not read it in the parent session. Every AskUserQuestion call follows .claude/docs/automation modes.md (collaborative asks always · guided major only · autonomous logs and proceeds; automation always ask categories always prompt). workflow for the GDD under review — use the system overrides row for <system if the block lists one, else the project value. Validation scope follows the tier: full — all 8 sections validated; any missing section blocks approval. standard — the 5 required sections (Overview, Detailed Rules, Edge Cases, Dependencies, Acceptance Criteria) block if missing; Formulas blocks only when the system defines numeric rules (rates, curves, thresholds, costs — the category is a hint, not the test); Player Fantasy and Tuning Knobs are advisory (warn, never block) unless workflow overrides require them. minimal — no GDD is expected; if one exists, validate the 5 standard sections advisorily. Resolved mode controls how thorough this review is: full : Complete review — all phases + specialist agent delegation (Phase 3b) lean : All phases, no specialist agents — faster, single session analysis solo : Phases 1 4 only, no delegation, no Phase 5 next step prompt — use when called from within another skill Phase 1: Load Documents Freshness check first — a re review of an unchanged document costs full price and reproduces the same verdict. Run: The registry is in the check because this review consults it for cross document facts — an unchanged GDD reviewed against a changed registry can reach different conclusions, so the skip is only safe when every line reads UNCHANGED (a registry that never existed doesn't appear in the output and doesn't block the skip). This skill's file is in it because a changed skill reviews differently. The check also compares every other file the log stamps — the related GDDs, concept or brief and narrative files earlier reviews read — and prints GONE: for one that no longer exists. Then read the latest entry's Review mode: line. That review covers this run only when its mode is the same as or deeper than the mode resolved now ( full lean solo ) and its workflow is the same or deeper ( full standard minimal ). An entry without the line was written before it existed and covers nothing. All UNCHANGED and the log's latest entry carries a verdict — surface it: "This document is byte identical to its last review on [date] ([mode] review, verdict: [verdict])." If that verdict was APPROVED and that review covers this run, offer via AskUserQuestion : [A] Use the prior verdict (Recommended) / [B] Re review anyway — guided proceeds with [A] and notes it; autonomous logs via log decision and uses the prior verdict. If it was APPROVED but the review asked for now is deeper than the logged one, say so — "That was a [mode] review at workflow [tier]; this run asks for [mode] at [tier]." — and offer [A] Re review at [mode] (Recommended) / [B] Use the prior [mode] verdict ; guided and autonomous re review ( autonomous logs it via log decision ). If it was NEEDS REVISION or MAJOR REVISION NEEDED, say so plainly: the document has not changed since it failed review — the prior findings stand; revising the document is the next step, not re reviewing it. Offer to display the prior findings from the log. The target doc and this skill's file UNCHANGED , and only the registry or another stamped cross document file CHANGED , NEW or GONE — the prior verdict stands except for cross document facts: re verify the doc's values against the changed files and re issue the verdict; escalate to a full re review if a conflict appears or that review does not cover this run. Target doc or this skill's file CHANGED or NEW , or RECEIPT: NONE — proceed with the full review below. Do not offer a partial/delta re review that skips reading or re analyzing unchanged sections. A section scoped re review misses defects a full review finds, and saves little or nothing. "Unchanged since last review" only means byte identical to what was reviewed then — it says nothing about whether that prior pass was itself complete, and attention narrows to the flagged change even under an instruction to scan everything anyway. Read the target design document in full. This step needs the whole GDD: read it in ranges by its headings (found with the Grep tool: pattern ^ , content mode), since a whole file Read over 40 KB is refused. Read CLAUDE.md to understand project context and standards. For cross document facts, prefer the registry over sibling GDDs. If design/registry/entities.yaml exists and lists entries for this system , grep it — these are the established facts this GDD must not contradict, and they replace reading sibling GDDs to rediscover them: The first finds entries this system owns — the A 6 context includes their referenced by: block. The second finds entries that reference this system — referenced by: is a block sequence (the key and its paths are on separate lines), so match the path with B 8 context to see the owning entry, not a referenced by. name one liner (which never matches the block form). If design/registry/entities.yaml does not exist, or lists no entry for this system — the file ships as an empty stub, so this is the default until /design system has populated it — fall back to reading the related GDDs the target doc names in its Dependencies section. Bound the read to those, not to everything "implied". Do not glob read all of design/gdd/ . Dependency graph validation: For every system listed in the Dependencies section, use Glob to check whether its GDD file exists in design/gdd/ . Flag any that don't exist yet — these are broken references that downstream authors will hit. Lore/narrative alignment: If design/gdd/game concept.md (or, at rigor: minimal , the one page brief design/game brief.md ) or any file in design/narrative/ exists, read it. Note any mechanical choices in this GDD that contradict established world rules, tone, or design pillars. Pass this context to game designer in Phase 3b. Prior review check: Check whether design/gdd/reviews/[doc name] review log.md exists. If it does, read the most recent entry — note what verdict was given and what blocking items were listed. This session is a re review; track whether prior items were addressed. Phase 2: Completeness Check Step 2a — gather section presence deterministically (no document read): It prints a PRESENT: list and, when applicable, an ABSENT: list and a PLACEHOLDER: list (present sections holding only [To be designed] : not yet written, so treat them as missing for the checklist). It reports presence only and makes no REQUIRED/ADVISORY judgment — that is Step 2b's job. It already accepts Detailed Design as satisfying the Detailed Rules requirement, so do not flag that as missing. Step 2b — apply the tier. Using the Step 2a lists, evaluate against the Design Document Standard checklist below. Mark each section REQUIRED or ADVISORY per the resolved workflow tier (Phase 0). A missing REQUIRED section blocks approval; a missing ADVISORY section is surfaced as a recommendation but does not block. A section reported PRESENT can still fail review if it is an empty heading — spot read any section the verdict actually turns on. [ ] Has Overview section (one paragraph summary) — REQUIRED at all tiers [ ] Has Player Fantasy section (intended feeling) — REQUIRED at full ; ADVISORY at standard [ ] Has Detailed Rules section (unambiguous mechanics) — REQUIRED at full / standard . The GDD template titles this section Detailed Design (it carries Core Rules / States / Interactions sub headings); accept either heading as satisfying this requirement — do not flag "Detailed Rules" as missing when a Detailed Design section is present. [ ] Has Formulas section (all math defined with variables) — REQUIRED at full ; at standard REQUIRED whenever the system defines numeric rules (rates, curves, thresholds, costs, damage, drop weights), else ADVISORY. The system's Category is a hint, not the test — do not clear this on a category token alone [ ] Has Edge Cases section (unusual situations handled) — REQUIRED at full / standard [ ] Has Dependencies section (other systems listed) — REQUIRED at full / standard [ ] Has Tuning Knobs section (configurable values identified) — REQUIRED at full ; ADVISORY at standard unless workflow overrides.tuning knobs [ ] Has Acceptance Criteria section (testable success conditions) — REQUIRED at full / standard Phase 3: Consistency and Implementability Internal consistency: Do the formulas produce values that match the described behavior? Do edge cases contradict the main rules? Are dependencies bidirectional (does the other system know about this one)? Implementability: Are the rules precise enough for a programmer to implement without guessing? Are there any "hand wave" sections where details are missing? Are performance implications considered? Is every acceptance criterion independently testable? Flag each one that is not, quoting it — "feels balanced", "works correctly", "performs well" are not criteria — with a measurable rewrite. In full mode qa lead also checks them (Phase 3b); in lean and solo no specialist runs, so this main review check is the only one. Cross system consistency: Does this conflict with any existing mechanic? Does this create unintended interactions with other systems? Is this consistent with the game's established tone and pillars? Registry values, wherever the GDD states them. A value restated in a table, a catalogue entry or a variant note contradicts the registry as surely as one in Detailed Rules, and reading by section makes those bodies easy to skim. List the registry's entry names ( grep E '^ name:' design/registry/entities.yaml ), then search the whole target document once for all of them plus the numeric keys they carry, case insensitive, writing each as [ ] so goblin scout also matches "Goblin scouts": Check every line it prints against the registry, whatever section it sits in. A line that gives an entry a different value, even for one room, variant, level or exception, contradicts the owning GDD: list it under Required Before Implementation with its line number, this document's value and the registry's. With no registry entries, run the same search for the entities and values the related GDDs define. Phase 3b: Adversarial Specialist Review (full mode only) Skip this phase in lean or solo mode. This phase is MANDATORY in full mode. Do not skip it. Before spawning any agents , print this notice: "Full review: spawning specialist agents in parallel. This typically takes 8–15 minutes. Use review lean for faster single session analysis." Step 1 — Identify all domains the GDD touches Using the GDD already loaded in Phase 1 — do not re read it — identify every domain present. A GDD can touch multiple domains simultaneously — be thorough. Common signals: If the GDD contains... Spawn these a

design-review