fix: address PR #21 review feedback (round 2)

Six findings verified; four required fixes, two were correct as-shipped:

VERIFIED + FIXED:

- gds-create-prd/steps-c/step-12-complete.md: body referenced an undefined
  variable {checkImplementationReadinessWorkflow}. Frontmatter had the
  wrong variable (validationWorkflow, leftover from Phase 2a split, never
  consumed). Replaced with checkImplementationReadinessWorkflow pointing
  to skill:gds-check-implementation-readiness, matching upstream's
  Option-1 readiness-check semantics.

- gds-edit-gdd and gds-validate-gdd: previously delegated to the PRD
  variants, which doesn't work — neither gds-edit-prd nor gds-validate-prd
  accepts a target-document parameter. Replaced both placeholder stubs
  with full GDD-specific implementations modeled on the PRD variants
  but rewritten for game-design content (mechanics, gameplay loop,
  pillars, genre conventions, engine constraints). 23 new files,
  ~5,000 lines:
    * gds-edit-gdd: 5-step edit flow + gdd-purpose data
    * gds-validate-gdd: 13-step validation flow + gdd-purpose +
      genre-complexity.csv (24 genres mapped to complexity tiers,
      signals, key concerns)
  Validate-gdd reuses gds-create-gdd/game-types.csv via {module_root}
  rather than duplicating it.
  TODO.md: removed the GDD-specific step bodies entry now that they
  exist.

- gds-code-review/steps/step-04-present.md: bucket name inconsistent
  with step-03-triage.md. Triage uses decision_needed (underscore);
  step-04 mixed underscore and hyphen forms. Normalized all 8
  occurrences in step-04 to underscore form.

- gds-sprint-status/workflow.md: next_agent was hardcoded to "DEV"
  for all five recommendation paths and never exported as a
  template-output. Now sets per-path role labels (DEVELOPER, REVIEWER,
  STORY_AUTHOR, FACILITATOR) and adds {{next_agent}} to the
  template-output exports. Note clarifies that in the consolidated
  Phase 4 model all role labels resolve to the same agent
  (gds-agent-game-dev), kept distinct for downstream semantic use.

VERIFIED + NO FIX NEEDED:

- spec-template.md context-prefix guidance: matches upstream exactly.
  The reviewer's "implement validateContextPaths()" suggestion doesn't
  fit upstream's LLM-driven workflow architecture (no JS validators,
  prefix contract is the inline frontmatter comment). Diverging from
  upstream to add prose validators would conflict with the upstream-
  mirror directive.

- gds-quick-dev/step-05-present.md spec-vs-sprint status: upstream
  intent is two distinct lifecycles. {spec_file} status=done means the
  artifact is finished from quick-dev's perspective; sprint-status
  story status=review means the story still needs human/code review
  before being marked done. sync-sprint-status.md line 15 explicitly
  codifies this ordering (review > in-progress, done > review).

- gds-create-gdd "create-gdd" -> "gds-create-gdd" rename: grep
  returns zero bare references; rename was fully propagated in Phase 2b.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

Author: sjennings

TODO.md

@@ -2,5 +2,4 @@
 
 * Adapt document-project workflow to BMGD
 * Add and adapt research agents to pre-production (either to designer agent or new analyst agent)
-* Author GDD-specific step bodies for `gds-edit-gdd/steps-e/*` and `gds-validate-gdd/steps-v/*`. Both skills currently delegate to their PRD counterparts as a structural placeholder. Model after `gds-edit-prd` and `gds-validate-prd`, but replace PRD-specific validation checks (project-type, brief coverage) with GDD equivalents (game-type, gameplay-loop coverage, mechanics completeness).
 * Review whether `src/workflows/gds-quick-flow/` parent directory still earns its keep now that it contains only `gds-quick-dev/`. Candidate: promote `gds-quick-dev` up to `src/workflows/4-production/` or similar and retire the `gds-quick-flow/` wrapper.

src/workflows/2-design/gds-create-prd/steps-c/step-12-complete.md

@@ -4,7 +4,7 @@ description: 'Complete the PRD workflow, update status files, and suggest next s
 
 # File References
 outputFile: '{planning_artifacts}/prd.md'
-validationWorkflow: 'skill:gds-validate-prd'
+checkImplementationReadinessWorkflow: 'skill:gds-check-implementation-readiness'
 ---
 
 # Step 12: Workflow Completion

src/workflows/2-design/gds-edit-gdd/data/gdd-purpose.md

@@ -0,0 +1,224 @@
+# BMAD GDD Purpose
+
+**The GDD is the primary planning artifact in the Game Dev Studio (GDS) module. It feeds every downstream phase: architecture, epics, production, and playtesting.**
+
+In GDS, the PRD is optional and exists only for external-tool compatibility. The GDD is the canonical source of truth for game design intent.
+
+---
+
+## What is a BMAD GDD?
+
+A dual-audience document serving:
+
+1. **Human game designers, producers, and developers** - Vision, pillars, team alignment, playtest briefs
+2. **LLM downstream consumption** - Architecture → Epics → Dev stories → Playtest plans → Game Dev AI Agents
+
+Each successive artifact becomes more granular and more AI-tailored. The GDD is where the design intent is captured in its purest form, before engine and implementation concerns enter the picture.
+
+---
+
+## Core Philosophy: Information Density
+
+**High Signal-to-Noise Ratio on Game Mechanics**
+
+Every sentence must carry design information. LLMs consume precise, dense content efficiently - and game design already suffers from pitch-deck-style fluff.
+
+**Anti-Patterns (Eliminate These):**
+
+- ❌ "The player will be able to..." → ✅ "The player can..."
+- ❌ "It is our intention to create a game that..." → ✅ State the design directly
+- ❌ "Players will experience fun and engaging gameplay" → ✅ Describe the specific mechanic that produces engagement
+- ❌ Marketing copy and pitch language → ✅ Concrete mechanics, systems, and numbers
+
+**Goal:** Maximum design information per word. Zero fluff, zero marketing.
+
+---
+
+## The Traceability Chain
+
+**GDD starts the chain:**
+
+```
+Core Fantasy / Vision → Game Pillars → Core Gameplay Loop → Mechanics & Systems → Epics → Stories
+```
+
+**In the GDD, establish:**
+
+- Vision → Pillars alignment
+- Pillars → Gameplay Loop reinforcement (the loop should embody the pillars)
+- Gameplay Loop → Mechanics mapping (each mechanic serves the loop)
+- Mechanics → Epics (each epic delivers mechanics)
+- All content traceable to the core fantasy
+
+**Why:** Every downstream artifact (architecture, epics, stories, playtest plans) must trace back to documented design intent. This chain is what prevents scope creep, feature bloat, and mechanics that exist for their own sake.
+
+---
+
+## What Makes Great Mechanics and Systems?
+
+### Mechanics are Player-Facing Capabilities, Not Implementation
+
+**Good:** "The player can dash in any of 8 directions, consuming 1 stamina pip. Stamina regenerates at 1 pip/second while grounded."
+**Bad:** "We use a Rigidbody2D with AddForce and a cooldown coroutine" (engine leakage - belongs in architecture)
+
+**Good:** "Frame-perfect parries reward a 1.5x damage multiplier for 3 seconds."
+**Bad:** "Combat feels responsive and satisfying" (subjective, unmeasurable)
+
+### SMART Quality Criteria (Adapted for Game Design)
+
+**Specific:** Clear, precisely defined mechanic or system
+**Measurable:** Quantifiable values (timings, damages, costs, ranges)
+**Attainable:** Realistic within target platform, team, and timeline
+**Relevant:** Reinforces a game pillar or the core loop
+**Traceable:** Links to the vision, a pillar, or a specific player fantasy
+
+### Mechanics Anti-Patterns
+
+**Subjective Adjectives:**
+
+- ❌ "fun", "satisfying", "immersive", "responsive", "deep"
+- ✅ Use concrete values: "chain combos extend the hit window by 6 frames per successful hit"
+
+**Engine / Implementation Leakage:**
+
+- ❌ Engine APIs, node names, specific shaders, class hierarchies
+- ✅ Focus on player experience and system behavior - the engine is architecture's problem
+
+**Vague Quantifiers:**
+
+- ❌ "many enemies", "several weapons", "various environments"
+- ✅ "12 enemy archetypes", "6 primary weapons + 18 unlockable variants", "3 biomes × 4 sub-zones"
+
+**Missing Feel Criteria:**
+
+- ❌ "The jump feels good"
+- ✅ "Jump height: 3 tiles. Air time: 0.55s. Coyote time: 6 frames. Buffer window: 8 frames."
+
+---
+
+## What Makes Great Technical Constraints?
+
+### Target Specs Must Be Measurable
+
+**Template:**
+
+```
+"The game shall [metric] [platform/condition] [measurement method]"
+```
+
+**Examples:**
+
+- ✅ "Maintain 60 FPS sustained on Steam Deck at 720p Medium settings, as measured by in-engine profiler over a 10-minute combat loop"
+- ✅ "First-playable load time under 15s on PS5 from cold boot"
+- ✅ "Memory budget: 4GB on PS4, 6GB on PS5, as measured by PIX capture"
+
+### Constraint Anti-Patterns
+
+**Unmeasurable Claims:**
+
+- ❌ "Runs well on all platforms" → ✅ "60 FPS on PS5/XSX, 30 FPS on PS4/XB1"
+- ❌ "Fast load times" → ✅ "Sub-5-second level transitions on target hardware"
+
+**Missing Context:**
+
+- ❌ "60 FPS target" → ✅ "60 FPS during combat encounters with up to 6 enemies on-screen, measured on Steam Deck"
+
+---
+
+## Genre-Specific Requirements
+
+**Auto-Detect and Enforce Based on Game Type**
+
+Certain genres carry conventions that must be documented:
+
+- **Action/Platformer:** Precise movement values (jump arc, coyote time, input buffer), hit/hurt box conventions, damage formulae
+- **RPG:** Stat system, leveling curve, inventory rules, quest state machine, save/load boundaries
+- **Roguelike:** Run structure, meta-progression rules, seed determinism, balance bands
+- **Multiplayer (MOBA/Shooter):** Netcode model (lockstep/rollback/client-predict), tick rate, lag tolerance, matchmaking
+- **Puzzle:** Solution space guarantees, hint systems, difficulty ramp
+- **Narrative/Visual Novel:** Branching structure, variable/flag system, rewind/save model
+
+**Why:** Missing genre conventions in the GDD means they surface as emergencies during production. Validation should catch these up front. Steps use a `genre-complexity.csv` data file to drive genre-specific expectations.
+
+---
+
+## Document Structure (Markdown, Human-Readable)
+
+### Required Sections (canonical gds-create-gdd schema)
+
+1. **Executive Summary** - Core concept, target audience, USPs
+2. **Goals and Context** - Project goals, background, rationale
+3. **Core Gameplay** - Pillars, core gameplay loop, win/loss conditions
+4. **Game Mechanics** - Primary mechanics, controls and input
+5. **Game-Type Specific Sections** - Genre-driven sections (e.g., RPG stats, roguelike run structure)
+6. **Progression and Balance** - Player progression, difficulty curve, economy
+7. **Level Design Framework** - Level types, progression
+8. **Art and Audio Direction** - Visual style, audio approach
+9. **Technical Specifications** - Performance targets, platform specs, asset budget
+10. **Development Epics** - High-level delivery breakdown
+11. **Success Metrics** - Technical and gameplay success criteria
+12. **Out of Scope** - Explicit scope boundaries
+13. **Assumptions and Dependencies** - External risks
+
+### Formatting for Dual Consumption
+
+**For Humans:**
+
+- Clear, direct language - no pitch-deck bloat
+- Logical flow from vision to execution
+- Easy for producers, leads, and external collaborators to review
+
+**For LLMs:**
+
+- `##` Level 2 headers for all main sections (enables extraction)
+- Consistent structure and patterns
+- Concrete numbers wherever possible
+- High information density
+
+---
+
+## Downstream Impact
+
+**How the GDD Feeds Next Artifacts:**
+
+**Architecture:**
+
+- Mechanics → system design (physics, AI, state machines)
+- Technical specs → engine choice, rendering pipeline, memory layout
+- Genre conventions → framework decisions (netcode model, save system)
+
+**Epics & Stories:**
+
+- Mechanics → epics (1 mechanic often = 1 epic)
+- Level framework → content stories
+- Progression → systems stories
+- Traceability → stories map back to pillars
+
+**Playtesting / Gametest:**
+
+- Pillars → playtest focus areas
+- Success metrics → playtest success criteria
+- Core loop → the thing we're actually testing
+
+**Development AI Agents:**
+
+- Precise mechanics → implementation clarity
+- Measurable specs → automated performance gates
+- Genre conventions → framework selection
+- Success metrics → telemetry targets
+
+---
+
+## Summary: What Makes a Great BMAD GDD?
+
+✅ **High Information Density** - Every sentence carries design weight, zero pitch-deck fluff
+✅ **Measurable Mechanics** - Concrete numbers for timings, damages, costs, ranges
+✅ **Clear Traceability** - Each mechanic links to a pillar or core loop, each pillar to the vision
+✅ **Genre Awareness** - Genre-specific sections auto-detected and included
+✅ **Zero Anti-Patterns** - No subjective adjectives, no engine leakage, no vague quantifiers
+✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
+✅ **Markdown Format** - Professional, clean, accessible to designers and AI tools alike
+
+---
+
+**Remember:** The GDD is the foundation of GDS. Quality here ripples through architecture, epics, stories, and playtesting. A dense, precise, well-traced GDD makes every downstream phase dramatically more effective - and prevents the "we never actually decided what this game is" spiral that kills projects.