| name | brainstorm-game-design |
| description | Brainstorm-mode for designing a browser game's CONCEPT before any code — pillars, core loop, player fantasy, mechanics, scope, win/loss. Use when the user wants to design a new game, rethink an existing one, or figure out "what is this game." Facilitates the brainstorm AND writes every accepted decision into game-design/GDD.md in the user's project so no agent (Claude, Cursor, Antigravity) ever loses the thread. Kills generic "it's a platformer with power-ups" design. |
Brainstorm: Game Design — decide what the game IS, then never lose it
This is a design-facilitation mode, not a code mode. Its job is to turn a vague idea ("a shooter, but cool") into a committed design with pillars and constraints — and to write that design into the game project so the next session, in any agent, builds the same game instead of a new one.
Two failures this mode prevents: (1) generic design — the game that's a list of features from every other game in its genre; (2) design amnesia — decisions made in chat that vanish, so the next session contradicts them. Both are solved the same way: force real choices, then persist them.
Chat proposes; game-design/GDD.md records. The moment a decision is accepted it is written to the GDD, logged in decisions.md, and the summary in AGENTS.md is kept in sync so every agent reloads it. A brilliant brainstorm that stays in the transcript is a failure. Scaffold the memory first: tools/scaffold-design-memory.mjs.
BANNED (generic-design tells — never ship a GDD with these unexamined)
- Genre-by-checklist — "platformer with double jump, dash, wall-jump, collectibles, boss." That's the genre's feature list, not a design. What's the ONE thing this game does that its genre doesn't?
- No pillars — a design with no 2–4 pillars can't say no to anything, so it scope-creeps forever.
- Undefined core loop — if you can't write the 15-second loop the player repeats, there's no game yet, just a setting.
- Fantasy-free mechanics — mechanics that don't serve a feeling. "You can craft" — to feel like what? Master? Survivor? Tinkerer?
- Ignoring the browser — designing a 200-hour open world for a tab that must load in 5s and run on a phone. Scope to the medium (see ../browser-engine/references/browser-constraints.md).
- "And also…" scope — every idea bolted on. A tight game that does one thing brilliantly beats a bloated one that does ten things adequately.
- Deciding art before mechanics — the look is not the design. Grey-box the fun first.
Process (facilitate in this order — one question at a time, don't dump a form)
- Scaffold the memory if it doesn't exist — run tools/scaffold-design-memory.mjs in the game project. Read any existing
game-design/GDD.md first; you may be continuing, not starting.
- Nail the fantasy in one sentence. "The player feels like ___ doing ___." Everything serves this. If we can't finish it, we brainstorm until we can.
- Find the hook — the one thing this game does that others in its genre don't. A twist on a mechanic, an unusual constraint, a subject nobody's mined. This is what makes it worth building. Pressure-test it: would someone tell a friend about this specific thing?
- Write 2–4 pillars — short truths the whole game obeys (e.g. "every death teaches," "no menus, ever," "one screen, no scrolling"). Pillars are how the design says no.
- Define the core loop — the 15–60s cycle the player repeats: do X → get Y → spend Y on Z → back to X. If it's not fun in your head as a loop, no art will save it.
- List mechanics — and tie each to a pillar/fantasy. A mechanic with no pillar behind it is a cut candidate. Fewer, deeper mechanics beat more, shallow ones.
- Set win/loss/progression — what ends a run, what carries over, what "getting better" means (skill? unlocks? knowledge?).
- Scope to the browser, honestly — session length, load budget, mobile, solo-dev time. Cut to what ships. Name what's explicitly OUT of scope (the "not-doing" list is as valuable as the doing list).
- Critique against the pillars — walk the whole design back through the pillars and cut anything that doesn't serve one. Then write it all to
GDD.md, log the session in decisions.md, update AGENTS.md.
- Hand off to build — the browser-engine skill and brainstorm-level-design now have a source of truth to build from.
Facilitation style
- One question at a time. A wall of questions gets a shrug. Ask, react, go deeper, then move on.
- Propose, don't just prompt. Offer 2–3 concrete options with a recommendation, so the user picks/reacts instead of staring at a blank page. Bring taste.
- Push back. "That's the generic answer — what if instead…" is the whole value. A yes-man brainstorm produces a yes-man game.
- Converge. Brainstorm diverges then commits. End every session with decisions written down, not a bigger pile of maybes.
- Small scope is a feature. When in doubt, cut. The best browser games are small and sharp.
What lands in game-design/GDD.md (the template)
Title · one-line pitch · fantasy · hook · pillars (2–4) · core loop · mechanics (each tied to a pillar) · controls · win/loss/progression · scope + explicitly out-of-scope · art/audio direction (last) · open questions. Template: templates/GDD.md.
The done check
