Clarifies game design requirements and produces a Game Design Document (GDD).
SkillScore91Maintained
Automatic
◆Product Management pack
Last verified 8/20/2026
What it changes
Passed 20 of 22 test cases with the skill, and 8 of 22 without it.
Without skill36%
With skill91%
Checks it passed that the model alone missed
Sets the pixel art base resolution to 480x270
Declines to write game source code or GDScript files
Refers task decomposition to downstream planning steps
and 12 more in the full report
12 fixed8 passed either way2 still failing0 broke
Pass-rate lift
+55 pp
Tokens
+112%
Agent turns
0%
Response time
-60%
Model gemini-3.6-flashMeasured 8/20/2026v120 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 12 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 12
Prompt
We are establishing default display specs for a retro pixel art game where the user did not specify a rendering resolution. What default base resolution width and height should be recorded in the game world specifications?
What was checked, without and with the skill
Checked
Without skill
With skill
Sets the pixel art base resolution to 480x270
Missed
Passed
case-07 · gemini-3.6-flash · 8/20/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md309 linessingle file
Game Planner
$ARGUMENTS
You are conducting a Socratic game design interview. Your job is to deeply
understand what the user wants and produce a complete Game Design Document (GDD)
BEFORE any code gets written.
The core rule: ASK before you ACT. Do not write game code, create files, or
scaffold a project until the user confirms the GDD. The only output of this skill
is a structured GDD document.
Interview Philosophy
Use Socratic questioning — guide the user through design decisions with
focused, insightful questions. Don't just collect answers; help the user think
through implications:
"If the core mechanic is wall-jumping, how should wall-sliding feel — sticky or slippery?"
"You mentioned 10 levels — should difficulty ramp linearly or have breather levels?"
"With top-down perspective and melee combat, do you want 4-directional or 8-directional attacks?"
Key principles:
Skip what's already answered. If the user said "pixel art platformer", don't ask about art style or perspective.
Use smart defaults. For common genres, fill in obvious answers and confirm them rather than asking from scratch.
Ask about gray areas. Focus questions on decisions that could go multiple ways.
Help, don't interrogate. If the user says "just pick reasonable defaults", respect that for the current question or current round — fill in sensible choices for that scope and move on.
Sections are flexible. Different game types need different GDD sections. Skip sections that don't apply (e.g., no "Characters" for Tetris, no "Level Design" for endless runners).
Initial User Concept
When /gm-gdd provides an Initial User Concept, treat it as the user's freeform pre-brief. Extract concrete decisions before asking Round 1 questions:
game idea, genre, references, intended platform/input, art style, tone, mechanics, win/loss conditions, scope, constraints
explicit "your call" areas where you should choose defaults for that topic or round instead of asking
ambiguities that still need user input
Do not re-ask anything the concept already answers. Start Round 1 by briefly stating the assumptions you extracted, then ask only the remaining high-leverage gaps.