/prototype

name: prototype
description: "Concept prototype — validate the core idea is worth designing before writing GDDs. Run right after /brainstorm and /setup-engine. Routes to HTML, Engine, or Paper path based on game type. Produces a throwaway build and a PROCEED/PIVOT/KILL verdict."
argument-hint: "[concept-description] [--path html|engine|paper] [--review full|lean|solo] [--spike]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Bash, Task, AskUserQuestion
model: sonnet
agent: prototyper
isolation: worktree

Purpose

This is the **concept prototype** — a fast, throwaway build that answers one question: *"Is this core idea actually fun to interact with?"*

**Default use** — run right after `/brainstorm` and `/setup-engine`, before writing GDDs or architecture docs. Its verdict determines whether the concept is worth the investment of full design documentation.

**Mid-production?** You can also run this at any stage to test a specific mechanic, design change, or technical question. Pass `--spike` to activate spike mode: a lightweight ~4-hour build with no GDD prerequisites and no phase gate implications.

**Already have GDDs and architecture complete?** To validate the full game loop before committing to Production, run `/vertical-slice` instead.

---

Phase 1: Define the Question

Resolve the review mode (once, store for all gate spawns this run): 1. If `--review [full|lean|solo]` was passed → use that 2. Else read `production/review-mode.txt` → use that value 3. Else → default to `lean`

**Check for spike mode:** If `--spike` was passed, skip to the **Spike Mode** section at the bottom of this skill.

Otherwise, use `AskUserQuestion` to confirm intent before proceeding:

• **Prompt**: "How would you like to use this prototype session?"
• **Options**:
• `Prototype this concept` — build a throwaway build to validate the core idea is fun before writing GDDs (1–3 days)
• `Skip — concept already proven` — I have enough evidence this works; log it and proceed directly to design
• `Mid-production spike` — I'm already in Production and want to test a specific mechanic or technical question quickly (~4 hours, no phase gate implications)

**If "Skip — concept already proven":** Ask (plain text, not a widget): "What evidence do you have that the concept works?" Record the one-line answer, then stop. Note: "Concept prototype skipped — evidence: [answer]." Suggest next step: `/map-systems` or `/design-system [mechanic]`.

**If "Mid-production spike"**: skip to the **Spike Mode** section below.

**If "Prototype this concept"**: continue with Phase 1 below.

---

**A note on prototype strategy:** The research on successful indie development is consistent — building 2-3 concept variants and letting the best one win is far more likely to succeed than iterating one concept until it works. This is your first prototype, not necessarily your only one. If this prototype produces a PIVOT verdict, consider whether to refine this concept OR start fresh with a different angle on the same game idea and prototype that instead.

**Game jam as a prototype vehicle:** If you're planning a concept prototype anyway, consider timing it to a game jam (Ludum Dare, GMTK Game Jam, Global Game Jam). Jams provide a forced timebox (48-72 hours), instant distribution to thousands of players who rate and review early builds, and a deadline that prevents scope creep by design. Many shipped games (Celeste, VVVVVV) began as jam prototypes. Not required — but worth considering if the timing is right.

Read the concept description from the argument. Before building anything, define the **falsifiable hypothesis** this prototype must answer:

> *"If the player [does X], they will feel [Y] — we will know this is true if [measurable signal Z]."*

Good: "If the player swings on grapple hooks, traversal will feel fluid — we'll know if players chain 3+ swings without stopping within 2 minutes of picking it up."

Bad: "Does this feel fun?" ← not testable, not falsifiable.

**If the concept is too vague to form a hypothesis, stop here.** Ask the user to narrow the question before proceeding. A prototype without a clear question wastes time.

Also ask: **"What is the riskiest assumption in this concept?"** That is the first thing the prototype should test — not the easiest part, the riskiest.

---

Phase 2: Load Concept Context

Read `design/gdd/game-concept.md` if it exists. Extract:

• Core fantasy (what the player is supposed to feel)
• Core loop (the moment-to-moment action being tested)

Read `CLAUDE.md` and `.claude/docs/technical-preferences.md` for the engine and language in use.

---

Phase 3: Choose the Prototype Path

Select the prototype path. If `--path [html|engine|paper]` was passed, use that. Otherwise, use this quick-reference first, then read the full path details below:

| Genre | Recommended path | Key reason | |-------|-----------------|------------| | Platformer / action / fighter | **Engine** | Feel IS the hypothesis; browser latency produces false results | | Racing / sports | **Engine** | Same — timing and physics feedback are the point | | Top-down shooter / twin-stick | **Engine** | Aim feel is timing-sensitive | | Puzzle (logic) | **HTML** or **Paper** | Timing is not the point; logic and clarity are | | Card game | **Paper** first | Fastest iteration by hand before touching code | | Narrative / visual novel | **Paper** (Twine / Ink / Yarn Spinner) | Story is the mechanic — test it without code overhead | | Strategy / 4X / city builder | **Paper** (spreadsheet sim) | Validate economy and progression rules before building | | Roguelike (systems-heavy) | **Paper** → Engine | Validate that the ruleset is interesting before building | | Idle / clicker / incremental | **HTML** | Turn-based logic, no feel sensitivity required | | Rhythm game | **Paper** first (design levels in audio) | Design levels before the engine exists | | RPG / open world | **Paper** → Engine | Systems complexi