prototype

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

--spike

AskUserQuestion

• 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)

/map-systems

/design-system [mechanic]

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

design/gdd/game-concept.md

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

CLAUDE.md

.claude/docs/technical-preferences.md

prototype.html

• itch.io — upload the file, share the link, get play counts and written feedback within hours. Free. The indie community plays rough builds here without expecting polish. This is genuine external validation at zero cost.
• Loom + file share — share via Google Drive/Dropbox, ask someone to record their screen + audio with Loom while playing. You get a video of real first-impression reactions and confusion without synchronous scheduling.
• r/playmygame or r/WebGames (Reddit) — active communities that specifically test early builds and give unsolicited honest feedback.
• Game dev Discord servers (GMTK, Brackeys, GameDev.tv) — members test each other's prototypes routinely; an HTML file is the easiest possible ask.

1. Agent writes the code
2. User runs it in the engine
3. User reports errors or observations
4. Agent fixes and iterates

prototypes/[name]-concept/

1. Brief the rules once. Hand them the rule summary sheet. Then step back.
2. Do NOT explain further. Do NOT help. Do NOT clarify. Confusion is data.
3. Watch silently. Note every moment they slow down, re-read, or ask a question.
4. After the session, ask one question only: "What was confusing?" — not "Did you like it?"
5. Use fresh testers for each iteration. The same person cannot give new first-impression data.
6. If 3+ testers hit the same confusion point, that rule is broken — redesign it before re-testing.

• Twine — zero-code hypertext fiction; ideal for branching structure experiments and choice-impact testing
• Ink (Inkle) — plain-text scripting language used in 80 Days, Heaven's Vault, and Overboard; exports directly to Unity and Godot
• Yarn Spinner — dialogue scripting used in A Short Hike, DREDGE, and Night in the Woods; integrates natively with Unity and Godot

AskUserQuestion

• Prompt: "Which prototype path would you like to use? (Based on your concept, I'd recommend [path] — [one sentence reason].)"
• Options:

  • HTML — browser prototype

    — puzzle, card, turn-based, strategy, idle. Opens by double-clicking, no install. 85–90% reliable. Not suitable for action games — browser latency lies about feel.

  • Engine — native prototype

    — action, platformer, physics, or anything where feel IS the hypothesis. 50–60% one-shot; 2–4 iteration rounds are normal. Requires engine installed.

  • Paper — rules document + play log

    — strategy, economy, logic, board-game-style mechanics. 100% reliable. Cannot validate feel.

• What is the falsifiable hypothesis?
• What is the riskiest assumption — and how does this prototype test it first?
• What is the absolute minimum needed to answer the question?
• What is explicitly cut? (menus, save systems, error handling, polish, architecture — all of it)

production/session-state/active.md

production/session-state/

prototypes/[concept-name]-concept/

// PROTOTYPE - NOT FOR PRODUCTION
// Question: [Core question being tested]
// Date: [Current date]

• Hardcode values freely
• Use placeholder assets (colored rectangles, debug shapes)
• Skip error handling entirely
• Use the simplest approach that works
• Copy code rather than importing from production
• No architecture, no patterns, no abstractions

"The prototype files are written. Run the project in your engine now. If there are errors, paste them here and I'll fix them. If it runs, describe what you see and whether it feels like it's answering the question."

1. User runs → reports errors or observations
2. Agent fixes errors or adjusts the mechanic
3. Repeat until playable or sunk cost rule triggers

"The prototype is ready. Open

prototypes/[name]-concept/prototype.html

in your browser and play it. Take as long as you need. Don't rush through it — try to approach it the way a new player would. Come back here when you're done."

"Now that it's running — play through it a few times as if you're the player, not the developer. Come back when you have a feel for it."

"Read through

prototypes/[name]-concept/rules.md

and walk through the

play-log.md

as if you're playing it for the first time. If you have someone nearby, try running the rules with them. Come back when you've seen at least one full play cycle."

1. Hypothesis check:

   "The hypothesis was: [restate the hypothesis from Phase 1]. Did it hold up — CONFIRMED, PARTIALLY CONFIRMED, or REFUTED? Tell me what you saw."

2. Best moment:

   "What was the moment — if any — where it felt like it was working? Be specific."

3. Worst moment:

   "What was the most frustrating, confusing, or broken moment? Be specific — not 'it felt slow' but 'the jump took about half a second to respond and it felt like I was fighting the controls'."

4. Surprise:

   "Did anything happen that you didn't expect — good or bad?"

5. Verdict:

   "PROCEED, PIVOT, or KILL — and one sentence why."

• solo

  → skip. Note: "CD-PLAYTEST skipped — Solo mode."

• lean

  → skip. Note: "CD-PLAYTEST skipped — Lean mode."

• full

  → spawn

  creative-director

  via Task using gate CD-PLAYTEST if

  design/gdd/game-concept.md

  exists with game pillars defined. If pillars are not yet defined, note: "CD-PLAYTEST skipped — game pillars not yet defined at concept prototype stage."

design/gdd/game-concept.md

prototypes/[concept-name]-concept/REPORT.md

1. /design-review design/gdd/game-concept.md

   — validate the concept doc against what the prototype revealed

2. /gate-check

   — confirm readiness to advance to Systems Design

3. /art-bible

   — define visual identity (optional but worth doing before GDDs)

4. /map-systems

   — decompose the concept into all game systems

5. /design-system [mechanic]

   — GDD for each MVP system; use prototype learnings in the Tuning Knobs and Formulas sections

6. /review-all-gdds

   — cross-system consistency check

1. "What specifically worked in this prototype that we should preserve in the next version?"
2. "What is the single most important thing to change?"

prototypes/[concept-name]-concept/PIVOT-NOTE.md

/prototype

prototypes/

PIVOT-NOTE.md

• Run

  /prototype [revised-concept]

  to test the adjusted direction
• Or

  /brainstorm [hint]

  if the concept needs more fundamental rethinking

• Core mechanic still unclear to testers after 2+ playtests?
• No "fun moment" (smile, laugh, or retry by choice) observed in any session?
• 3+ PIVOT iterations on the same concept with no clear improvement?
• Concept only works when heavily explained or when the dev guides the player?
• Building this feels like obligation, not excitement?

prototypes/GRAVEYARD.md

prototypes/GRAVEYARD.md

undefined

• Kill reason: [specific blocker — not "it was boring" but "players never understood the core action"]
• What worked: [2-3 things worth carrying forward to future concepts]
• What failed: [the specific mechanic, design decision, or scope issue]
• Next time: [one explicit action to try differently on a similar concept]

This file exists so the same mistake doesn't get made twice on the next concept.

- Run `/brainstorm open` or `/brainstorm [new-hint]` to explore a different concept
- The prototype report is the deliverable — no further action needed

---

---

--spike

• You're in Production and want to test whether a new mechanic should be added
• You're unsure if a technical approach will work before building it properly
• A design change is being considered and you want a quick before/after comparison
• A GDD system is proving harder than expected and you want to prototype the hard part
• You need to confirm target hardware can sustain the required framerate before writing gameplay code (performance spike — see below)

1. Define the spike question (plain text, not a widget): "What specific question does this spike answer? Give me one sentence: 'Can we [do X] using [approach Y]?'"
2. Choose path — same AskUserQuestion widget as Phase 3 (HTML / Engine / Paper).
3. Scope — maximum 2-3 bullet points. One mechanic, one technical question, nothing else.
4. Build — same relaxed standards as concept prototype. Hard cap: 4 hours. If not demonstrable in 4 hours, the question is too large. Split it.
5. Observe and decide — no formal playtest debrief. Ask: "Did the spike answer the question? YES or NO, and why in one sentence."
6. Write a spike note (not a full report) to

   prototypes/[concept-name]-spike-[date]/SPIKE-NOTE.md

   :
   • Question tested
   • Result (YES it works / NO it doesn't / PARTIAL — needs more investigation)
   • What to do next (add to current sprint / investigate further / abandon the idea)
7. Update

   production/session-state/active.md

   to clear the spike and return to the current sprint state.

• The question is "can the engine render [scene X] at 60fps on [minimum spec hardware]?" not "does this mechanic feel good?"
• The output is a benchmark number, not a feel verdict
• No gameplay logic is needed — just the maximum intended scene load (terrain, draw calls, physics objects, particles) running at once
• Build time stays within the ~4-hour cap; the spike is setting up the rendering load, not the game
• If the answer is NO at this scope, this is an architecture or scope constraint that affects everything downstream — better to surface it now than during Sprint 8

• Prototype code must NEVER import from production source files
• Production code must NEVER import from prototype directories
• If the recommendation is PROCEED, production implementation is written from scratch — prototype code is never refactored into production
• Total effort is hard-capped at 1 day (concept prototypes test one mechanic)
• Test ONE mechanic — if scope grows, stop and simplify the question
• No polish. No menus, no game over, no music, no UI unless it IS the mechanic
• If stuck after 2 hours of engine iteration, reframe the question or switch paths
• 3 PIVOT iterations → force a KILL decision. If this is the third time the same concept has produced a PIVOT verdict, the concept likely doesn't work. Ask: "Is this the right idea, or am I in the sunk cost trap?" A new concept prototyped fresh will almost always beat a fourth iteration of a struggling one.
• Building 2-3 different concept variants and picking the best one is a healthier strategy than iterating one concept to death. Natural selection between prototypes beats willpower.
• Networked/multiplayer games: A local prototype cannot validate the feel of a networked mechanic. Latency fundamentally changes how combat, movement, and prediction feel — a prototype running at 0ms local will feel entirely different at 80ms network delay. Use a local prototype to validate that the mechanic is interesting. Do not use it as evidence that it feels good under real network conditions. Network feel requires real peers or simulated latency (e.g., throttle tools, network condition simulators).