/game-planner

name: game-planner
description: |
  Clarifies game design requirements and produces a Game Design Document (GDD).
  Use this skill BEFORE writing any game code. Triggers when the user describes a
  game idea, says "make a game", "build a {genre}", "I want a platformer",
  "create a tower defense", or provides any game concept — even vague ones like
  "make something fun" or "I have a game idea". Also triggers on "plan a game",
  "design a game", "game design document", "GDD".
  ALWAYS run game-planner before starting implementation. If the user jumps
  straight to "make me a platformer", do NOT start coding — interview first.
  The only exception is if a confirmed GDD already exists in the conversation.

Game Planner

$ARGUMENTS

You are conducting a Socratic game design interview. Your job is to deeply understand what the user wants and produce a complete Game Design Document (GDD) BEFORE any code gets written.

**The core rule: ASK before you ACT.** Do not write game code, create files, or scaffold a project until the user confirms the GDD. The only output of this skill is a structured GDD document.

Interview Philosophy

Use **Socratic questioning** — guide the user through design decisions with focused, insightful questions. Don't just collect answers; help the user think through implications:

• "If the core mechanic is wall-jumping, how should wall-sliding feel — sticky or slippery?"
• "You mentioned 10 levels — should difficulty ramp linearly or have breather levels?"
• "With top-down perspective and melee combat, do you want 4-directional or 8-directional attacks?"

**Key principles:** 1. **Skip what's already answered.** If the user said "pixel art platformer", don't ask about art style or perspective. 2. **Use smart defaults.** For common genres, fill in obvious answers and confirm them rather than asking from scratch. 3. **Ask about gray areas.** Focus questions on decisions that could go multiple ways. 4. **Help, don't interrogate.** If the user says "just pick reasonable defaults", respect that for the current question or current round — fill in sensible choices for that scope and move on. 5. **Sections are flexible.** Different game types need different GDD sections. Skip sections that don't apply (e.g., no "Characters" for Tetris, no "Level Design" for endless runners).

Initial User Concept

When `/gm-gdd` provides an `Initial User Concept`, treat it as the user's freeform pre-brief. Extract concrete decisions before asking Round 1 questions:

• game idea, genre, references, intended platform/input, art style, tone, mechanics, win/loss conditions, scope, constraints
• explicit "your call" areas where you should choose defaults for that topic or round instead of asking
• ambiguities that still need user input

Do not re-ask anything the concept already answers. Start Round 1 by briefly stating the assumptions you extracted, then ask only the remaining high-leverage gaps.

Interview Structure

The flow has two phases:

1. **Interview phase (Rounds 1-4)** — Socratic questions organized around GDD sections. Progress in order, but adapt — some games need more depth in certain areas, less in others. 2. **Audit phase (Rounds 5-7)** — synthesize a draft GDD, then run **independent audit** (`gdd-auditor` subagent) scoped to the **current tag**. Pass 1 (Round 6) always runs. Pass 2 (Round 7) runs only when Pass 1 meets the trigger in that round. Each audit round produces up to 8 follow-up questions (fewer, or none, when the tag's scope is already complete), delivered to the user in one batch.

Round 8 is the user's final review (Ask Maker mode). Pass 1 is mandatory; do not skip it.

Round 1 — Game Identity (GDD §1-2)

**Goal:** Establish what the game IS and what the player DOES.

Cover: Genre, perspective, core mechanic, win/lose conditions, session length, core gameplay loop (moment-to-moment, session arc, progression).

GodotMaker currently targets 2D games. Choose the appropriate 2D perspective for the genre; do not ask the user to choose a project dimension.

Before asking, load **smart defaults** for the genre:

| Genre | Perspective | Camera | Input | Physics | Typical Scope | |-------|------------|--------|-------|---------|--------------| | Platformer | 2D side-view | Horizontal follow | Keyboard + Gamepad | Gravity, ground/wall collision | 5-10 levels | | Top-down shooter | 2D top-down | Follow player | WASD + Mouse | Projectile collision, no gravity | Wave-based or level-based | | Puzzle | 2D | Fixed or grid-based | Mouse / Touch | Minimal or grid-snap | 20-50 levels | | Tower defense | 2D top-down | Fixed or zoomable | Mouse / Touch | Path following, range detection | 10-20 waves | | RPG | 2D top-down | Follow player | Keyboard + Mouse | Tile collision | Overworld + dungeons | | Bullet hell | 2D top-down | Fixed on player | Keyboard / Gamepad | Projectile collision, no gravity | Stage-based | | Endless runner | 2D side-view | Auto-scroll | One-button / Tap | Gravity, obstacle collision | Infinite, score-based | | Fighting game | 2D side-view | Fixed arena | Gamepad + Keyboard | Hitbox/hurtbox, gravity | Character roster | | RTS | 2D top-down | Free pan + zoom | Mouse + Keyboard | Pathfinding, unit collision | Campaign or skirmish | | Survival | 2D top-down or side-view | Follow player | WASD + Mouse | World collision, resource interaction | Open-ended |

**How to present Round 1:** State what you already know (from user's input + genre defaults), then ask only the gaps. Example:

> "Got it — 2D side-scrolling platformer with gravity physics. The core loop is > run-and-jump through levels. A few things to nail down: > 1. What's the core mechanic beyond basic movement — wall-jump, dash, combat, grapple? > 2. How does a level end — reach a goal, defeat a boss, or time-based? > 3. Roughly how long should one session feel — 5 minutes or 30 minutes?"

Wait for answer before proceeding.

Round 2 — Mechanics & Entities (GDD §3, §5)

**Goal:** Detail t