/gm-gdd

name: gm-gdd
description: |
  Game Design Document phase for one tag. On the first ever run, runs the
  full Socratic interview, produces GDD.md, and derives ROADMAP.md (split
  into SemVer-tagged release tags). On every subsequent run, focuses the
  conversation on the current tag (the earliest entry in ROADMAP.md
  without a git tag), optionally updates GDD.md / ROADMAP.md, then
  generates the current tag's PLAN/STRUCTURE/SCENES/DESIGN/ASSETS at the project
  root. Explicit invocation only — use /gm-gdd.
disable-model-invocation: true

GodotMaker GDD

$ARGUMENTS

You are running the design phase **for one tag at a time**. The pipeline is tag-iterative: each `/gm-gdd` invocation either bootstraps the whole project plus its first tag (initial mode), or focuses the next tag in `ROADMAP.md` (subsequent mode).

Session Setup

**FIRST ACTION — before anything else:** Write `gdd` to `.godotmaker/current_role`.

Resume Check

Read `.godotmaker/stage.jsonl` (treat as empty if missing) — each line is `{"role": X, "ts": Y}`.

• If `project.godot` does not exist → STOP. Tell user to run `/gm-scaffold` first.
• If the **last event** has `role == "gdd"` → STOP. Tell the user:

> "GDD already completed for the current tag at {timestamp}. Recommended next: /gm-asset. > If you need to redo this step or have other plans, just tell me."

• Otherwise → proceed (fresh project, OR new tag after the previous tag's `/gm-finalize`).

Mode Detection

Detect the mode by inspecting on-disk state — there is no flag:

• **Initial mode**: `ROADMAP.md` does NOT exist. (`GDD.md` may also be missing — if it is, this is a brand-new project.)
• **Subsequent mode**: `ROADMAP.md` EXISTS. Determine the **current tag** as follows:

1. Read `ROADMAP.md`, list tag entries in declared order. 2. Run `git tag --list 'v*'` (capture stdout). 3. The current tag is the **earliest tag in ROADMAP that is not in `git tag --list`**. 4. If every ROADMAP entry already has a git tag, STOP and inform the user the roadmap is exhausted — they must edit `ROADMAP.md` to add new entries before re-running `/gm-gdd`.

State the detected mode + (if subsequent) the current tag explicitly to the user as your first conversational message after Resume Check passes. They should never have to guess which tag they're working on.

Freeform Intake

Before invoking `game-planner` in initial mode, collect the user's rough idea in normal conversation, not `AskUserQuestion`.

• If `$ARGUMENTS` already contains a game idea, treat it as the freeform intake and do not ask again.
• If `$ARGUMENTS` is empty, ask the user for one open-ended paragraph: what they want to make, any references, mechanics, visual style, constraints, and anything they already decided. Make clear that rough notes are enough.
• Pass this freeform intake verbatim into the `game-planner` brief as "Initial User Concept".
• `game-planner` must skip questions that the freeform intake already answers and use those details to choose smarter defaults.
• Any "your call" / "you decide" language in the intake is scoped to the named topic or the current intake round unless the user explicitly grants broader delegation.

This intake is NOT a confirmation gate. Keep `AskUserQuestion` for explicit GDD and ROADMAP confirmations only.

Hard Rules

1. **You CANNOT write game code (.gd/.tscn/.tres).** Code lives in workers in `/gm-build`. 2. **You CANNOT write to `assets/`.** Assets are produced in `/gm-asset`. 3. **Use AskUserQuestion for confirmation.** GDD must be explicitly confirmed by the user before generating ROADMAP / per-tag artifacts. ROADMAP must be explicitly confirmed before any artifact is written. 4. **MUST NOT skip the ROADMAP confirmation gate** — see Sub-stages below. Initial mode WITHOUT a confirmed ROADMAP cannot proceed to artifact generation; subsequent mode with a roadmap edit WITHOUT re-confirmation cannot proceed either. 5. **Subsequent mode does NOT append tag-N sections to STRUCTURE/SCENES.** It **overwrites** those root files with end-of-current-tag snapshots. Prior tags' versions live in `docs/tags/<prev_tag>/`. When rewriting STRUCTURE.md, carry forward every still-valid entry under Architecture Ownership, Architecture Dependencies, Ordering Constraints, and Stable Invariants from the previous tag archive, and modify only entries this tag actually changes. The cross-tag accumulating files are `GDD.md`, `ROADMAP.md`, `DESIGN.md`, and `ASSETS.md`. 6. **GDD design changes that contradict shipped tags MUST be reflected as PLAN refactor tasks.** When subsequent-mode interview reveals that a prior tag's behaviour now needs to change, the GDD update marks the old behaviour as `(superseded by ...)` rather than deleting it, AND the new PLAN.md gains an explicit refactor / removal task in the Main Build section.

Sub-stages

1a — Interview & GDD update

Invoke the `game-planner` skill (`.claude/skills/game-planner/SKILL.md`).

Initial-mode brief MUST include the Freeform Intake as `Initial User Concept`; game-planner skips already-answered topics and uses the intake to choose smarter defaults.

• **Initial mode:** game-planner runs the full Socratic interview → produces fresh `GDD.md`.
• **Subsequent mode:** brief game-planner with:
• Current tag id (e.g. `v0.2.0`)
• The current ROADMAP.md entry for that tag (its bullet list)
• The full existing `GDD.md` content
• The previous tag's `docs/tags/<prev>/PLAN.md` Tag Mechanics list (so the conversation knows what already shipped)

Game-planner asks the user: "We're about to plan {Tag}. ROADMAP currently says {bullets}. Do you want to keep that scope, adjust it, or change the underlying GDD design?" — and runs a focused interview. If the user changes design intent, game-planner updates `GDD.md` in place: new sections appended, replaced sections marked `(superseded by ...)`. Old GDD content is **never silently deleted**.

**Gate 1a:**

• [ ] `GDD.md` exists and (if subsequent mode) reflects the u