Skip to content
Development
Skill

/gat-brainstorm

Brainstorm a game idea through one-question-at-a-time designer interviews. Produces game.md, systems-index.md, and art-direction.md, or runs as discussion-only.

From plugin
game-dev-skills
7817 skills4 agents
Install
$ npx -y skills add Yuki001/game-dev-skills --skill gat-brainstorm --agent claude-code

How it fires

How this skill gets triggered: by you, by Claude, or both.

  • Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
  • You can call itInvoke it directly when you want it.
  • Slash command/gat-brainstorm

Context preview

The summary Claude sees to decide when to auto-load this skill.

Brainstorm a game idea through one-question-at-a-time designer interviews. Produces game.md, systems-index.md, and art-direction.md, or runs as discussion-only.

SKILL.md

gat-brainstorm.SKILL.md
name: gat-brainstorm
description: "Brainstorm a game idea through one-question-at-a-time designer interviews. Produces game.md, systems-index.md, and art-direction.md, or runs as discussion-only."
argument-hint: "[<hint> | discuss]"
user-invocable: true
allowed-tools: Read, Glob, Grep, Write, Edit, Agent, AskUserQuestion

Brainstorm

This skill explores a game concept through open-ended designer interview. Spawn `gat-designer` for design reasoning and `gat-artist` for visual direction. Pick questions from the angle table below — follow the conversation, not a script.

Phase 1: Resolve Mode

  • If argument is `discuss` → Mode: `discuss` (no files written, exploration only)
  • If argument is a hint or empty → Mode: `design` (produces foundational design docs and global art direction)

Check whether `gat/overview/game.md`, `gat/overview/systems-index.md`, or `gat/overview/art-direction.md` already exist. If so, note them — the interview may refine or replace existing decisions instead of starting from scratch.

Phase 2: The Interview

Core Rules

  • **One question at a time.** Never batch. Wait for the answer before the next question.
  • **Provide a recommended answer** with each question. Explain the design reasoning.
  • **Prefer open-ended questions.** Let the user type free-form responses. Reserve

`AskUserQuestion` (multiple-choice) for when you are presenting concrete solution options and need the user to pick one. Most of the interview should be dialogue, not forms.

  • **Pick angles, don't follow steps.** Use the angle table as a menu. Jump to

whatever dimension is most useful next — chase what's interesting or ambiguous.

  • **If a question can be answered by reading existing design files, read them

instead of asking.**

  • **Spawn `gat-designer`** when you need a design reasoning pass: drafting a core

loop, proposing systems, evaluating a trade-off, or checking consistency.

  • **Spawn `gat-artist`** when visual identity needs synthesis: art references,

palette, readability, asset groups, production standards, or conflicts between style and gameplay clarity.

Drilling into Vague Ideas

When the user has a fuzzy idea — about the whole game or a single system — your job is to make it concrete through relentless, curious questioning. This is the core of the interview.

**How to drill:**

  • When the user says something vague ("combat should feel impactful"), ask what

specifically makes it impactful — is it animation, sound, damage numbers, controller rumble, enemy reaction, time-to-kill? Keep asking until the abstraction bottoms out in concrete mechanics.

  • When the user proposes a system, ask about its boundaries. What does it NOT

do? What system owns the adjacent responsibility? A system without edges is still fuzzy.

  • When the user describes a player experience ("I want the player to feel

lost"), ask what the game does to create that feeling. What does the player see, hear, and do? What information is withheld? What mechanics produce the emotion?

  • When the user references another game ("like Dark Souls but..."), isolate what

exactly they want to keep and what they want to change. The reference is a shortcut — unpack it.

  • Ask about edge cases and failure states. What happens when the player ignores

the system? What happens when they optimize it to the extreme? The answers reveal whether the system is understood or still hazy.

  • Ask about the player's moment-to-moment decisions. If the user can't describe

what choices the player makes inside the system, the system isn't clear yet.

  • If an answer opens three new questions, pick the most foundational one first.

Resolve dependencies before details.

**Signals that something is still vague and needs more drilling:**

  • The user uses abstract adjectives without mechanics behind them ("fun",

"smooth", "deep", "cool")

  • A system is named but its inputs, outputs, and rules are undefined
  • Two systems have overlapping or unclear boundaries
  • The user can describe what the system IS but not what the player DOES in it
  • Numbers are absent where they matter (how many? how long? how much?)

Seed Extraction

If a concept hint was provided, first spawn `gat-designer` to extract what the hint already answers. Briefly summarize what's established so the user can confirm or correct before diving in. Skip if no hint.

Interview Angles

Pick questions from any angle below. There is no fixed order — follow the thread that matters most at each moment. The table is a palette, not a checklist.

| # | Angle | Purpose | Example prompts | |---|-------|---------|-----------------| | 1 | **Genre & Style** | Establish the game's design identity and reference points | What genre(s) does this live in? What games should it feel like mechanically? Real-time or turn-based? 2D or 3D? Single-player, co-op, or competitive? | | 2 | **Visual Direction** | Establish the global art identity that will become `art-direction.md` | What should the game look like at a glance? Which art references fit or should be avoided? What palette, shape language, camera, readability, and production constraints matter? | | 3 | **Core Player Verb** | Pin down the primary action the player repeats | What does the player actually DO moment-to-moment — shoot, build, explore, talk, craft, steer, command? What makes that action satisfying? | | 4 | **Target Feeling** | Define the emotional experience | What should the player feel during play — tension, mastery, wonder, power, relaxation, social connection, fear, curiosity? When do they feel it most? | | 5 | **Fantasy & Role** | Clarify who the player is in the world | What fantasy does the game fulfill? Who is the player — hero, commander, survivor, creator, investigator, merchant? | | 6 | **Scope & Constraints** | Set boundaries early | Rough scope (jam, indie, commercial)? Platform? Timeline? Team size? Content rating? Hard constraints? Any visual production constraints like pixel ar

Read more
Ships withgame-dev-skills

This is my personal agent skill repository, primarily focused on game development.

Get the whole plugin

Other skills on game-dev-skills.