Skip to main content
skill CX Codex

review-all-gdds — Claude Code skill: cross-GDD review for game design

Reads every system GDD at once and catches what a single-document pass misses: contradictions, dominant strategies, broken economies.

Install into Claude Code · Skills CLI (Vercel) All methods and platforms ↓
npx skills add Donchitos/Claude-Code-Game-Studios --skill review-all-gdds -a claude-code
Open on GitHub

What review-all-gdds does

The skill loads all system GDDs and runs two passes over them. The first is cross-GDD consistency: contradictions between documents, stale references, ownership conflicts. The second is design holism: dominant strategies, broken economies, cognitive overload, pillar drift, competing progression loops. That is the difference from /design-review, which checks one GDD for internal completeness — here the subject is the relationships between documents.

Seven phases run in sequence. Loading first, then two parallel game-designer sub-agents — one for consistency, one for design theory — followed by a cross-system scenario walkthrough, the report, the write step and a handoff. Each phase gets its own slice of the GDDs: consistency needs dependencies, rules, formulas, tuning knobs and acceptance criteria; design theory needs player fantasy, reward structure and the game pillars. Content is pasted into the sub-agent prompt rather than passed as file paths, because each sub-agent has its own context window.

Run it once every MVP-tier GDD is approved on its own, and before /create-architecture starts — architecture built on inconsistent GDDs inherits the inconsistencies. The minimal workflow does not apply here, since there are no GDDs to read. The argument sets the scope: full, consistency, design-theory or since-last-review for git-based changes.

What it helps with

  • find contradictions between system GDDs
  • catch a dominant strategy before balancing starts
  • spot an economy imbalance across all systems
  • cut cognitive overload from too many mechanics
  • check progression against the game pillars

Example prompts for the agent

  • /review-all-gdds
  • /review-all-gdds consistency
  • /review-all-gdds since-last-review

How to install review-all-gdds

1Skills CLI (Vercel)

npx skills add Donchitos/Claude-Code-Game-Studios --skill review-all-gdds -a claude-code

2Manually: put the files in place

~/.claude/skills/review-all-gdds/SKILL.md

Copy the whole skill folder; for one project use .claude/skills/review-all-gdds/

Step by step, with commands for each platform: How to install skills in Claude Code: five ways

Questions about review-all-gdds

How do I install review-all-gdds in Claude?

Run npx skills add Donchitos/Claude-Code-Game-Studios --skill review-all-gdds -a claude-code. The skill file then sits at ~/.claude/skills/review-all-gdds/SKILL.md.

What does review-all-gdds do?

It reads all system GDDs together and runs two passes: cross-GDD consistency between documents, and design holism — dominant strategies, economy, overload, pillar drift.

How is it different from /design-review?

/design-review reviews one GDD for internal completeness. This skill reviews the relationships between all GDDs, so it runs after the individual documents are approved.

Source text

SKILL.md · MIT
---
name: review-all-gdds
description: "Holistic cross-GDD review — contradictions between systems, dominant strategies, economic imbalance, cognitive overload, pillar drift."
argument-hint: "[focus: full | consistency | design-theory | since-last-review]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, AskUserQuestion, Agent, Bash(bash "*/.claude/skills/review-all-gdds/../../hooks/yaml-helper.sh" resolve_config *), Bash(bash .claude/scripts/review-scope.sh*)
model: opus
---

!`bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow,system_overrides`

# Review All GDDs

This skill reads every system GDD simultaneously and performs two complementary
reviews that cannot be done per-GDD in isolation:

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

**This is distinct from `/design-review`**, which reviews one GDD for internal
completeness. This skill reviews the *relationships* between all GDDs.

**When to run:**
- 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)

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).

**Argument modes:**

**Focus:** `$ARGUMENTS` (blank = `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)

---

**`workflow`** per GDD (per `.claude/docs/workflow-modes.md`): each GDD validates
against its effective tier — the project value, overridden per system by the
`system_overrides` row for that system when the block lists one. At `full`, validate all 8
sections across all GDDs. At `standard`, validate the 5 required sections;
optional sections (Player Fantasy, Tuning Knobs, conditional Formulas) are
surfaced as advisory only. At `minimal`, this skill is not applicable (no GDDs).

## Phase 1: Load Everything

**Read `references/1-load.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

### Parallel Execution

Phase 2 (Consistency) and Phase 3 (Design Theory) are independent — they read
the same GDD inputs but produce separate reports. Spawn both as parallel `Agent`
agents simultaneously rather than waiting for Phase 2 to complete before
starting Phase 3. Collect both results before writing the combined report.

Spawn both as `game-designer` sub-agents (`subagent_type: game-designer`) — GDD
consistency and design-theory review is its domain.

**When spawning the Phase 2 and Phase 3 agents, always pass:**
- The loaded GDD **content** each phase needs — **not file paths**. Paste the
  sections; the sub-agent has its own context and cannot re-read Phase 1's
  results, so a path forces a full re-read (and contradicts the "do not re-read"
  rule below). Pass only the phase's slice: Phase 2 (consistency) needs each GDD's
  Dependencies, Detailed Design/Rules, Formulas, Tuning Knobs and Acceptance
  Criteria; Phase 3 (design theory) needs Player Fantasy, progression/reward
  structure and the game pillars.
- The full entity registry contents (`design/registry/entities.yaml`) if loaded in Phase 1b (paste the registry text, not just a file path)
- The specific checklist items assigned to that agent's phase (Phase 2 gets 2a–2f; Phase 3 gets 3a–3g)
- The engine name and version — `engine.name` and `engine.version` from `project.yaml`, resolving each field independently (if its key is absent or empty, use `.claude/docs/technical-preferences.md`) — plus `docs/engine-reference/[engine]/VERSION.md`

Do not rely on the subagent to re-read these files — it has its own context window and cannot access Phase 1 results unless they are explicitly passed in the `Agent` prompt.

---

## Phase 2: Cross-GDD Consistency

**Read `references/2-consistency.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

## Phase 3: Game Design Holism

**Read `references/3-design-holism.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

## Phase 4: Cross-System Scenario Walkthrough

**Read `references/4-scenarios.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

## Phase 5: Output the Review Report

**Read `references/5-report.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

## Phase 6: Write Report and Flag GDDs

**Read `references/6-write.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

## Phase 7: Handoff

**Read `references/7-handoff.md` now and follow it** — this phase's steps are in that file, not here. Read it again if the conversation was compacted or resumed during this phase.

## Error Recovery Protocol

**First, verify the artifact.** If the return contract named a path, check the
path exists before treating the phase as done — **a named artifact that is not
on disk is a failed phase, however fluent the response reads.** An agent can
burn a full phase and return a plausible preamble having written nothing, which
is neither BLOCKED nor an error nor "fails to complete", so the trigger below
never fires. Resume it naming the unmet contract; the context is
usually still there.

If any spawned agent returns BLOCKED, errors, or fails to complete: **surface it
immediately, don't proceed past a dependency it blocks, and always produce a
partial report** (retry scope here = fewer GDDs / single-system). Full procedure:
`.claude/docs/error-recovery-protocol.md`.

---

## Collaborative Protocol

**In `collaborative` mode (the default).** For `guided` and `autonomous` modes,
see `.claude/docs/automation-modes.md`. In `autonomous` mode the
PASS/CONCERNS/FAIL verdict is still printed and logged — only the closing
handoff widget is skipped.

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

© Donchitos · MIT · Donchitos/Claude-Code-Game-Studios

Similar skills

Everything for Game dev and 3D: Unity, Unreal, Godot, Blender →

From the same set72

Project sponsors

Companies that keep this analytics open
Gold sponsor

Impressions, clicks and code copies — open statistics. We keep the numbers public for the same reason NeBlask itself is public. Become a sponsor