/game-design-review

name: "game-design-review"
description: >
  Invoke when the user wants feedback on a game design document, GDD review, design
  evaluation, or consistency check on an existing design. Triggers on: "review my GDD",
  "design feedback", "evaluate design", "design document review", "GDD critique".
  Do NOT invoke for brainstorming new ideas (use game-brainstorm) or balance tuning
  (use game-balance-check). Part of the AlterLab GameForge collection.
argument-hint: "[path to design document]"
effort: medium
context: fork
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion
version: 1.3.0

AlterLab GameForge -- Design Document Review Workflow

A game design document is a living contract between your ambitions and your execution capacity. A bad GDD is not poorly formatted -- it is one that lets the team build confidently in the wrong direction for weeks before anyone notices. Hollow Knight's design doc worked because Team Cherry kept it tight, falsifiable, and obsessively focused on three pillars. Most GDDs fail because they describe a game without constraining it -- anything goes, so nothing works.

This is not a checklist review. A checklist confirms sections exist. This review confirms sections are good -- internally consistent, psychologically grounded, scope-honest, and specific enough to guide implementation decisions. Disco Elysium's systems-narrative integration did not happen by accident -- it happened because the design document specified exactly how every skill check connected to every dialogue branch. That level of specificity is what this review demands.

Purpose & Triggers

Use this workflow when:

• A designer says "review my GDD" or "give feedback on my design document"
• Before starting implementation, to catch problems while they are cheap to fix
• After significant design changes, to re-validate internal consistency
• When a playtest reveals problems and you suspect the root cause is in the design
• When team members disagree about what the game is supposed to be

Problems this solves:

• Mechanics that do not serve any design pillar (orphan features)
• Target aesthetics that contradict the actual mechanics (MDA misalignment)
• Scope estimates that ignore reality (optimism masquerading as planning)
• Design documents that describe a game but do not constrain it (anything goes = nothing works)
• Systems that interact in unintended ways (emergent conflict)
• Missing sections that will cause confusion during implementation

Critical Rules

1. **Read the whole document before commenting.** Context matters. A mechanic that seems orphaned in Section 3 might be justified by the progression system in Section 7. Read everything first, then analyze.

2. **Severity matters.** Not all findings are equal. A missing core loop definition is Critical. A vague art style reference is Minor. Assign severity explicitly so the designer knows where to spend time.

3. **Be specific, not vague.** "The combat system could be better" is useless feedback. "The combat system describes player attacks but never specifies enemy behavior patterns, making it impossible to tune difficulty" is actionable. Name the problem, cite the section, propose the fix.

4. **Propose, do not prescribe.** Offer alternative approaches with reasoning, not mandates. The designer owns the vision. Your job is to identify problems and suggest directions -- "Disco Elysium solved this by tying skill checks to dialogue, not combat" is a reference that opens thinking. "Just copy Disco Elysium" is lazy.

5. **Reference the theory.** When flagging an issue, connect it to established design principles from `docs/game-design-theory.md`. "This violates Flow Theory because the difficulty spike at Stage 3 has no skill-building ramp" is stronger than "Stage 3 is too hard."

6. **Check alignment across the document.** The biggest GDD failures are not missing sections but contradictions between sections. A pillar that says "player freedom" and a level design section that describes linear corridors is a critical contradiction.

Workflow

**Step 1: Document Intake**

Read the complete design document. Note the structure, length, and overall organization. Identify which of the 8 required GDD sections are present:

REQUIRED GDD SECTIONS
-------------------------------------------------
1. Game Overview (concept, genre, platform, audience)
2. Core Mechanics (player actions, systems, interactions)
3. Game Flow / Core Loop (30-sec to full-game timescales)
4. Level / World Design (spaces, progression through space)
5. Art Direction (visual style, references, asset requirements)
6. Audio Design (music, SFX, adaptive audio approach)
7. UI / UX Design (menus, HUD, accessibility considerations)
8. Technical Requirements (engine, platforms, performance targets)

OPTIONAL BUT VALUABLE
- Narrative Design (story, characters, dialogue systems)
- Monetization Model (if applicable)
- Multiplayer Design (if applicable)
- Accessibility Plan
- Competitive Analysis
-------------------------------------------------

**Step 2: Pillar Alignment Review**

This is the most important dimension. If the game has defined design pillars, every mechanic and system must trace back to at least one pillar. If no pillars are defined, flag this as a Critical finding.

PILLAR ALIGNMENT MATRIX
-------------------------------------------------
Mechanic/System        | Pillar 1 | Pillar 2 | Pillar 3 | Orphan?
-------------------------------------------------
[combat system]        | Yes      | --       | Yes      | No
[crafting system]      | --       | --       | --       | YES - flag
[dialogue choices]     | Yes      | Yes      | --       | No
[inventory management] | --       | --       | --       | YES - flag
-------------------------------------------------

Orphan mechanics are red flags. They either:
a) Should be cut (they serve no pillar, so they dilute focus)
b) Reveal a missing pillar (add a pillar that justifies