/game-design-review

name: game-design-review
description: >
  Reviews an existing GDD or feature spec with a severity-rated rubric: pillar alignment, MDA and
  player-psychology fit, consistency, scope, testability for agent-built games, originality, AI
  disclosure and accessibility hooks, ending in a build-readiness verdict. Use for "review my GDD",
  "design feedback", "critique this spec". Not for writing a GDD (use game-gdd-author).
argument-hint: "[path to design document or section]"
effort: high
allowed-tools: Read, Glob, Grep, Write, Edit, AskUserQuestion

AlterLab GameForge -- Design Document Review

A game design document is a contract between ambition and execution capacity. A bad GDD is not badly formatted; it is one that lets the team build confidently in the wrong direction for weeks before anyone notices. Most fail because they describe a game without constraining it: anything goes, so nothing coheres.

This is not a checklist review. A checklist confirms sections exist. This review confirms they are good: internally consistent, psychologically grounded, scope-honest, and specific enough to drive implementation. In 2026 that last test is literal. When a GDD section goes to Claude Code or a similar agent, every vague sentence becomes a guess in code, so this review also asks: **could an agent build this, and could a test tell whether it built it right?** And because players, stores and regulators now care how a game was made, it checks originality, AI-content disclosure and accessibility while changes are still cheap.

When to Use / When Not To

Use before implementation starts, as a gate before a section is handed to a coding agent, after significant design changes, when a playtest went badly and the cause may be in the design, or when the team disagrees about what the game is.

| Instead of this skill... | Use | |---|---| | Writing or rebuilding GDD sections | `/gameforge:game-gdd-author` | | Generating new ideas | `/gameforge:game-brainstorm` | | Tuning numbers against play data | `/gameforge:game-balance-check` | | Timeline vs capacity in depth | `/gameforge:game-scope-check` | | Reviewing code or architecture | `/gameforge:game-code-review` | | Full accessibility audit | `/gameforge:game-accessibility-specialist` | | Store compliance and disclosure forms at launch | `/gameforge:game-launch` |

Critical Rules

1. **Read the whole document before commenting.** A mechanic that looks orphaned in §5 may be justified in §11. Read everything, including linked pillars and the systems index, then analyze. 2. **Severity is explicit.** Critical, Major, Minor or Suggestion on every finding, with a reason. A missing core loop is Critical; a vague art reference is Minor. 3. **Specific, cited, actionable.** "Combat could be better" is useless. "§5.1 specifies player attacks but no enemy behavior, so difficulty cannot be tuned" is a finding. Name the problem, cite the section, propose a fix. 4. **Propose, do not prescribe.** The designer owns the vision. Offer directions with reasons; do not rewrite their sections. Route rewrites to `/gameforge:game-gdd-author`. 5. **Ground it in theory.** Tie findings to `${CLAUDE_PLUGIN_ROOT}/docs/game-design-theory.md`: "this spike violates Flow because §11 has no skill-building ramp before Stage 3" beats "Stage 3 is too hard." 6. **Contradictions beat omissions.** The costliest GDD failures are sections that disagree, not sections that are missing. 7. **Separate design quality from document quality.** A brilliant design can be badly documented and a polished document can describe a weak game. Say which problem you found. 8. **Compliance findings are flags, not legal advice.** State the rule and its date, say what it implies for the design, and recommend professional review where real exposure exists.

Step 0: Intake

1. Locate the document: the argument, else `Glob` for `design/**/*.md`, `docs/design/**`, `*gdd*`. Also read `design/pillars.md`, `design/systems-index.md` and `.gameforge/project.json` (engine, phase, pillars) when present. 2. Ask **one** AskUserQuestion to set the mode (default in bold):

• **Full review** -- all thirteen dimensions.
• **Build-readiness gate** -- dimensions 1, 2, 5, 10, 11, 12, 13 on the sections about to be built.
• **Focused** -- the user names the concern (scope, pillars, psychology, playtest diagnosis, compliance).

3. Note the phase. A concept-phase GDD is not penalized for missing §13 numbers; a GDD about to go into production is.

The Review Rubric

| # | Dimension | Question it answers | Typical worst severity | |---|---|---|---| | 1 | Section completeness | Is everything needed to build present? | Critical (no core loop) | | 2 | Pillar alignment | Does every mechanic serve a pillar? | Critical (no pillars) | | 3 | MDA consistency | Do mechanics produce the target aesthetics? | Major | | 4 | Player psychology | Are SDT needs and Flow supported? | Major | | 5 | Internal consistency | Do sections agree with each other? | Critical | | 6 | Scope feasibility | Can this team build it by this date? | Critical | | 7 | Edge cases | What happens when players do the unexpected? | Major | | 8 | Onboarding | Can a new player learn it unaided? | Major | | 9 | Differentiation | Is the hook real and communicable? | Major | | 10 | Testability for agent-built games | Could an agent build it and a test verify it? | Critical (for agent-built T1 systems) | | 11 | Originality and IP risk | Is it the team's own game, with clean assets? | Critical | | 12 | AI content and disclosure | What does the AI use in this design oblige? | Critical (runtime AI without guardrails) | | 13 | Accessibility hooks | Is accessibility designed in, not bolted on? | Major (Critical for EAA-scope features) |

1. Section completeness

Compare against `${CLAUDE_PLUGIN_ROOT}/templates/game-design-document.md` (§1-§13) plus the sections `game-gdd-author` appends: Direction, Technical Approach, AI Use & Or