wordle/.claude/skills/gds-gdd/assets/gdd-validation-checklist.md

GDD Validation Checklist

Loaded by the GDD validator subagent. For each item, return {id, status: pass|fail|warn|n/a, severity: low|medium|high|critical, location, note}. Skip items not applicable to the agreed scope and game type. Cite specific GDD locations — never abstract criticism.

The genre and game-type checks (G-1, G-2) require the validator to read assets/game-types.csv and assets/genre-complexity.csv from the skill root.

Quality

• Q-1. Information density. Sentences carry design weight. Flag conversational filler ("The player will be able to...", "In order to"), marketing / pitch-deck language ("immersive experience", "revolutionary", "AAA-quality"), and subjective design claims used without concrete backing ("fun", "satisfying", "deep").
• Q-2. Measurability. Mechanics, design goals, and technical specs carry concrete numbers — timings, damages, costs, ranges, cooldowns; feel parameters (jump arc, coyote time, input buffer, hit windows) where the genre demands; per-platform FPS / memory / load-time targets with a measurement method. Flag subjective adjectives and vague quantifiers ("many", "several", "various").
• Q-3. Traceability. The chain Vision → Game Pillars → Core Gameplay Loop → Mechanics → Development Epics is intact. Every pillar embodies the vision; the loop reinforces the pillars; each mechanic serves the loop or a pillar; each epic delivers mechanics. Flag orphan mechanics (no pillar/loop source), unsupported pillars (no reinforcing mechanic), and orphan epics.
• Q-4. Core gameplay concrete. Game Pillars (2–4, each game-defining and distinct) are specific enough to steer decisions. The Core Gameplay Loop documents a complete cycle (player action → outcome → reward → motivation to repeat). Win/loss conditions are defined and testable (or explicitly N/A for sandbox games).
• Q-5. Out of Scope explicit. An Out of Scope section names what is deliberately cut for v1.0 and what is deferred to post-launch, so omissions are not silently assumed downstream.
• Q-6. Dual-audience and self-contained. Each section makes sense pulled out alone; the GDD is readable by designers, producers, and leads, and structured cleanly (## headers, consistent patterns) for downstream source-extraction by architecture and epic/story workflows.

Discipline

• D-1. No engine-implementation leakage. Mechanics and systems specify WHAT the player experiences and WHAT a system must achieve, not HOW it is built. Flag engine internals (GameObject, MonoBehaviour, Rigidbody, Actor, Blueprint, Node2D, _process), scripting/code patterns, shader/rendering internals, netcode library names, and data-format internals. Target engine, platform, and hard certification constraints in Technical Specifications are acceptable — that is on what it runs, not how it is built.
• D-2. Input fidelity. Content from input documents (game brief, brainstorming, research, prior GDD) is still in scope or explicitly handled via Out of Scope or [ASSUMPTION]. Core fantasy, called-out mechanics, target platforms, and design pillars from the brief are honored or the deviation is documented.
• D-3. Technical Specifications stay GDD-level. Performance, platform, and asset-budget requirements only — no architecture-level system or engine design (that is gds-game-architecture's job).
• D-4. No innovation theater. USP and novelty claims are real, not invented pitch language.

Genre and game-type

• G-1. Genre compliance. Determine the genre's complexity from genre-complexity.csv. Low-complexity genres (general, idle-incremental, sandbox, party-game, text-based) carry no special-section requirement — mark n/a. Medium- and high-complexity genres must document their special_sections and key concerns: e.g. RPG stat system + leveling curve + inventory rules + quest state machine + save model; roguelike run structure + meta-progression + seed determinism; fighting frame data + netcode model + input spec; shooter weapon-feel table + netcode + hitreg. Missing genre-critical sections are critical.
• G-2. Game-type cross-reference. The GDD's declared game type is a canonical id in game-types.csv. Scan the GDD for that type's genre_tags; measure match strength (strong / moderate / weak / none). Flag a mismatch if another game type shows stronger signals. Verify the {GameType} Specific Design section is present and contains content appropriate to the matched genre guide — not an unfilled {{GAME_TYPE_SPECIFIC_SECTIONS}} token.

Structural integrity

• S-1. Terminology integrity. Every game-specific noun (mechanic name, resource, system) is used identically throughout. Flag drift (case, plural, synonyms) and contradictions between sections.
• S-2. Epic continuity. Development epics in gdd.md match epics.md; epic titles, scope, and sequence are consistent. Each epic delivers playable value and has high-level stories. ID / numbering is contiguous and unique.
• S-3. Assumptions Index. Every inline [ASSUMPTION: ...] appears in the Assumptions Index and vice versa.
• S-4. Template completeness. No unfilled {{template_variables}} or {{GAME_TYPE_SPECIFIC_SECTIONS}} token remains. Each canonical section has required content.
• S-5. Open-items density. Count Open Questions + [ASSUMPTION] + [NOTE FOR DESIGNER]. Red flag if density is high relative to the agreed scope.

Scope-gated

• STK-1. Required sections. The GDD includes the sections the agreed scope and game type warrant — and, for a game heading into build, enough detail for gds-game-architecture to make engine and system decisions and for gds-create-epics-and-stories to break down work.