1. Cross-GDD Consistency — contradictions, stale references, and ownership conflicts between documents
2. Game Design Holism — issues that only emerge when you see all systems together: dominant strategies, broken economies, cognitive overload, pillar drift, competing progression loops

/design-review

• After all MVP-tier GDDs are individually approved
• After any GDD is significantly revised mid-production
• Before

  /create-architecture

  begins (architecture built on inconsistent GDDs inherits those inconsistencies)

$ARGUMENTS[0]

full

• No argument /

  full

  : Both consistency and design theory passes

• consistency

  : Cross-GDD consistency checks only (faster)

• design-theory

  : Game design holism checks only

• since-last-review

  : Only GDDs modified since the last review report (git-based)

1. design/gdd/game-concept.md

   — game vision, core loop, MVP definition

2. design/gdd/game-pillars.md

   if it exists — design pillars and anti-pillars

3. design/gdd/systems-index.md

   — authoritative system list, layers, dependencies, status
4. Every in-scope system GDD in

   design/gdd/

   — read completely (skip game-concept.md and systems-index.md — those are read above)

"Cross-GDD review requires at least 2 system GDDs. Write more GDDs first, then re-run

/review-all-gdds

."

• If GDD-A lists "depends on GDD-B", check that GDD-B lists GDD-A as a dependent
• If GDD-A lists "depended on by GDD-C", check that GDD-C lists GDD-A as a dependency
• Flag any one-directional dependency as a consistency issue

⚠️  Dependency Asymmetry
[system-a].md lists: Depends On → [system-b].md
[system-b].md does NOT list [system-a].md as a dependent
→ One of these documents has a stale dependency section

• Floor/ceiling rules: Does any GDD define a minimum value for an output? Does any other say a different system can bypass that floor? These contradict.
• Resource ownership: If two GDDs both define how a shared resource accumulates or depletes, do they agree?
• State transitions: If GDD-A describes what happens when a character dies, does GDD-B's description of the same event agree?
• Timing: If GDD-A says "X happens on the same frame", does GDD-B assume it happens asynchronously?
• Stacking rules: If GDD-A says status effects stack, does GDD-B assume they don't?

🔴 Rule Contradiction
[system-a].md: "Minimum [output] after reduction is [floor_value]"
[system-b].md: "[mechanic] bypasses [system-a]'s rules and can reduce [output] to 0"
→ These rules directly contradict. Which GDD is authoritative?

• If GDD-A says "combo multiplier from the combat system feeds into score", check that the combat GDD actually defines a combo multiplier that outputs to score
• If GDD-A references "the progression curve defined in [system].md", check that [system].md actually has that curve, not a different progression model
• If GDD-A was written before GDD-B and assumed a mechanic that GDD-B later designed differently, flag GDD-A as containing a stale reference

⚠️  Stale Reference
inventory.md (written first): "Item weight uses the encumbrance formula
  from movement.md"
movement.md (written later): Defines no encumbrance formula — uses a flat
  carry limit instead
→ inventory.md references a formula that doesn't exist

• If [system-a].md outputs values between [min]–[max], and [system-b].md is designed to receive values between [min2]–[max2], is the mismatch intentional?
• If an economy GDD expects resource acquisition in range X, and the progression GDD generates it at range Y, the economy will be trivial or inaccessible — is that intended?

⚠️  Formula Range Mismatch
[system-a].md: Max [output] = [value_a] (at max [condition])
[system-b].md: Base [input] = [value_b], max [input] = [value_c]
→ Late-[stage] [scenario] can resolve in a single [event].
  Is this intentional? If not, either [system-a]'s ceiling or [system-b]'s ceiling needs adjustment.

• GDD-A criteria: "Player cannot die from a single hit"
• GDD-B criteria: "Boss attack deals 150% of player max health" These acceptance criteria cannot both pass simultaneously.

• Award the player's primary resource (XP, levels, prestige, unlocks)
• Define themselves as the "core" or "main" loop
• Have comparable depth and time investment to other systems doing the same

⚠️  Competing Progression Loops
combat.md: Awards XP, unlocks abilities, is described as "the core loop"
crafting.md: Awards XP, unlocks recipes, is described as "the primary activity"
exploration.md: Awards XP, unlocks map areas, described as "the main driver"
→ Three systems all claim to be the primary progression loop and all award
  the same primary currency. Players will optimise one and ignore the others.
  Consider: one primary loop with the others as support systems.

• Active = player must make decisions about this system regularly during play
• Passive = system runs automatically, player sees results but doesn't manage it

⚠️  Cognitive Load Risk
Simultaneously active systems during [core loop moment]:
  1. [system-a].md — [decision type] (active)
  2. [system-b].md — [resource management] (active)
  3. [system-c].md — [tracking] (active)
  4. [system-d].md — [item/action use] (active)
  5. [system-e].md — [cooldown/timer management] (active)
  6. [system-f].md — [coordination decisions] (active)
→ 6 simultaneously active systems during the core loop.
  Research suggests 3-4 is the comfortable limit for most players.
  Consider: which of these can be made passive or simplified?

• Resource monopolies: One strategy generates a resource significantly faster than all others
• Risk-free power: A strategy that is both high-reward and low-risk (if high-risk strategies exist, they need proportionally higher reward)
• No trade-offs: An option that is superior in all dimensions to all others
• Obvious optimal path: If any progression choice is "clearly correct", the others aren't real choices

⚠️  Potential Dominant Strategy
combat.md: Ranged attacks deal 80% of melee damage with no risk
combat.md: Melee attacks deal 100% damage but require close range
→ Unless melee has a significant compensating advantage (AOE, stagger,
  resource regeneration), ranged is dominant — higher safety, only 20% less
  damage. Consider what melee offers that ranged cannot.

• What scales (enemy health, player damage, resource cost, area size)
• How it scales (linear, exponential, stepped)
• When it scales (level, time, area)

⚠️  Difficulty Curve Mismatch
combat.md: Enemy health scales exponentially with area (×2 per area)
progression.md: Player damage scales linearly with level (+10% per level)
→ By area 5, enemies have 32× base health; player deals ~1.5× base damage.
  The gap widens indefinitely. Late areas will become inaccessibly difficult
  unless the curves are reconciled.

• Combat + Economy overlap: killing enemies that drop resources, spending resources during combat, death/respawn interacting with economy state
• Progression + Difficulty overlap: level-up triggering mid-fight, ability unlocks changing combat viability, difficulty scaling at progression milestones
• Narrative + Gameplay overlap: dialogue choices locking/unlocking mechanics, story beats interrupting resource loops, quest completion triggering system state changes
• 3+ system chains: any player action that triggers System A, which feeds into System B, which triggers System C (these are highest-risk interaction paths)

1. Trigger — what player action or game event starts this?
2. Activation order — which systems activate, in what sequence?
3. Data flow — what does each system output, and is that output a valid input for the next system in the chain?
4. Player experience — what does the player see, hear, or feel at each step?
5. Failure modes — are there any of the following?
   • Race conditions: two systems trying to modify the same state simultaneously
   • Feedback loops: System A amplifies System B which re-amplifies System A with no cap or dampener
   • Broken state transitions: a system assumes a state that a previous system may have changed (e.g., "player is alive" assumption after a combat step that could have caused death)
   • Contradictory messaging: player receives conflicting feedback from two systems reacting to the same event (e.g., "success" sound + "failure" UI)
   • Compounding difficulty spikes: two systems both scaling up at the same progression point, multiplying the intended difficulty increase
   • Reward conflicts: two systems both reacting to the same trigger with rewards that together exceed the intended value (double-dipping)
   • Undefined behavior: the GDDs don't specify what happens in this combined state (neither system's rules cover it)

Example walkthrough:
Scenario: Player kills elite enemy at level-up threshold during active quest

Trigger: Player lands killing blow on elite enemy
→ combat.md: awards kill XP (100 pts)
→ progression.md: XP total crosses level threshold → triggers level-up
  Output: new level, stat increases, ability unlock popup
→ quest.md: kill-count criterion met → triggers quest completion event
  Output: quest reward XP (500 pts), completion fanfare
→ progression.md (again): quest XP added → triggers SECOND level-up in same frame
  ⚠️  Data flow issue: quest.md awards XP without checking if a level-up
  is already in progress. progression.md has no guard against concurrent
  level-up events. Undefined behavior: does the player level up once or twice?
  Does the ability popup fire twice? Does the second level use the updated or
  pre-update stat baseline?

• BLOCKER: undefined behavior, broken state transition, or contradictory player messaging — the experience is broken or incoherent in this scenario
• WARNING: compounding spikes, feedback loops without caps, reward conflicts — the experience works but produces unintended outcomes
• INFO: minor ordering ambiguity or messaging overlap — worth noting but unlikely to cause player-visible problems

AskUserQuestion

• Prompt: "May I write this review to

  design/gdd/gdd-cross-review-[date].md

  ?"
• Options:

  [A] Yes — write the report

  /

  [B] No — skip

AskUserQuestion

• Prompt: "Should I update the systems index to mark these GDDs as needing revision? ([list of flagged GDDs])"
• Options:

  [A] Yes — update systems index

  /

  [B] No — leave as-is

• If yes: update each flagged GDD's Status field in systems-index.md to "Needs Revision". (Do NOT append parentheticals to the status value — other skills match "Needs Revision" as an exact string and parentheticals break that match.)

AskUserQuestion

• Are there any Warning-level items that are simple edits (flagged with "30-second edit", "brief addition", or similar)? → offer inline quick-fix option
• Are any GDDs in the "Flagged for Revision" table? → offer /design-review option for each
• Read systems-index.md for the next system with Status: Not Started → offer /design-system option
• Is the verdict PASS or CONCERNS? → offer /gate-check or /create-architecture

• [_] Apply quick fix: [W-XX description] in [gdd-name].md — [effort estimate]

  (one option per simple-edit warning; only for Warning-level, not Blocking)

• [_] Run /design-review [flagged-gdd-path] — address flagged warnings

  (one per flagged GDD, if any)

• [_] Run /design-system [next-system] — next in design order

  (always include, name the actual system)

• [_] Run /create-architecture — begin architecture (verdict is PASS/CONCERNS)

  (include if verdict is not FAIL)

• [_] Run /gate-check — validate Systems Design phase gate

  (include if verdict is PASS)

• [_] Stop here

(recommended)

1. Surface immediately: Report "[AgentName]: BLOCKED — [reason]" before continuing
2. Assess dependencies: If the blocked agent's output is required by a later phase, do not proceed past that phase without user input
3. Offer options via AskUserQuestion with three choices:
   • Skip this agent and note the gap in the final report
   • Retry with narrower scope (fewer GDDs, single-system focus)
   • Stop here and resolve the blocker first
4. Always produce a partial report — output whatever was completed so work is not lost

1. Read silently — load all GDDs before presenting anything
2. Show everything — present the full consistency and design theory analysis before asking for any action
3. Distinguish blocking from advisory — not every issue needs to block architecture; be clear about which do
4. Don't make design decisions — flag contradictions and options, but never unilaterally decide which GDD is "right"
5. Ask before writing — confirm before writing the report or updating the systems index
6. Be specific — every issue must cite the exact GDD, section, and text involved; no vague warnings