Skill: stanestane/game-design-fantasy-extractor (version 1.0.0)

--- name: game-design-fantasy-extractor description: Extract the core player fantasy from a game, feature, loop, or pitch based on what the design actually lets the player do, feel, and become. Use when a team can describe mechanics but cannot clearly articulate the fantasy those mechanics are supposed to deliver, when a concept feels emotionally vague, when a pitch names features instead of a player promise, or when you need to test whether the claimed fantasy is real, weak, conflicted, or absent. --- # Game Design Fantasy Extractor Extract the fantasy the design is actually trying to deliver, not just the genre wrapper or marketing line sitting on top of it. Use this skill when a team can explain systems, verbs, and content, but cannot cleanly state what the player is meant to feel like, become, or emotionally inhabit. The goal is to infer the core player fantasy from the design itself, test whether the systems support it, and expose where the fantasy is generic, split, or fake. Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family. Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure. ## Core principle Players do not attach to mechanics in the abstract. They attach to what those mechanics let them be. A useful fantasy statement does three things: - names who the player becomes - implies what emotional payoff they are chasing - is supported by repeated gameplay, not just theme dressing If the fantasy could describe fifty unrelated games, it is too weak to guide design. ## What to produce Generate: 1. **Core fantasy** - the strongest player-facing fantasy implied by the design 2. **Supporting fantasy layers** - secondary fantasies or emotional promises present in the design 3. **Fantasy support map** - which systems reinforce the fantasy and which fail to do so 4. **Fantasy conflicts** - where systems, pacing, or progression undermine the claimed fantasy 5. **Design implications** - what must be strengthened, clarified, cut, or re-framed ## Process ### 1. Define the extraction target Clarify: - what exact game, feature, loop, or pitch is being analyzed - whether the fantasy is for the whole product or one experience slice - whether you are extracting the current fantasy or pressure-testing a claimed one Write: - **Extraction target** - **Scope** - **Claimed fantasy if any** ### 2. Identify the player verbs and role Look at: - what the player repeatedly does - what power they exercise - what decisions they make - what social or world position they occupy - what consequences they create Ask: - What role is the player actually inhabiting? - What kind of agency does the design grant? - Is the player expressing mastery, care, domination, discovery, survival, performance, stewardship, rebellion, creation, or something else? ### 3. Infer the emotional promise Ask: - What is the player supposed to feel at their best moments? - What fantasy payoff keeps the loop emotionally coherent? - Does the design promise competence, cleverness, power, danger, intimacy, authorship, belonging, control, chaos, or transformation? State the strongest emotional promise in plain language. ### 4. Separate fantasy from theme skin Check whether the fantasy is genuinely systemic or mostly cosmetic. Examples: - a game dressed as leadership but functionally about spreadsheet optimization - a game themed as outlaw chaos but structurally punishing improvisation - a game marketed as freedom while funneling players into narrow routes Ask: - If the art and fiction layer were stripped away, would the same fantasy still be legible through play? - Is the fantasy delivered by action, or merely narrated at the player? ### 5. Identify supporting and competing fantasies Many designs carry secondary fantasies. That is fine until they collide. Look for: - power fantasy versus vulnerability fantasy - mastery fantasy versus cozy ritual fantasy - freedom fantasy versus authored narrative control - social belonging fantasy versus individual dominance fantasy Name the strongest secondary fantasies and whether they strengthen or muddy the main one. ### 6. Map support and contradiction For each major system, ask: - does it reinforce the fantasy - distract from it - undermine it - replace it with a different fantasy Use this format: | System or loop element | Supports fantasy? | Why | |---|---|---| | ... | Strongly / Partly / Weakly / No | ... | ### 7. Write the extracted fantasy sharply Prefer a compact form such as: - **You are ...** - **You get to feel like ...** - **This is a game about becoming ...** Good examples are concrete and emotionally legible. Bad examples sound like box-copy mush. ### 8. Convert the fantasy into design implications For each important fantasy claim, specify: - **Fantasy promise** - **What the design must deliver repeatedly** - **What the design should avoid because it breaks the fantasy** Examples: - outlaw improvisation -> systems must reward bold opportunism, not only rigid planning - city stewardship -> player actions must visibly improve or shape the world - predator mastery -> encounters must showcase dominance, not constant attrition panic ## Response structure Use this structure unless the user asks for something else: ### Extraction Target - ... ### Core Fantasy - ... ### Supporting Fantasy Layers - ... ### Fantasy Support Map - ... ### Fantasy Conflicts - ... ### Design Implications 1. ... 2. ... 3. ... ### Minimal Reframe or Fix - ... ## Fast mode Use this quick pass when speed matters: - What does the player actually get to be here? - What feeling is the design promising at its best? - Which system most strongly supports that fantasy? - Which system most obviously betrays it? - What one change would make the fantasy clearer? ## Usage notes This extractor is especially useful for: - early concept framing - pitch cleanup - fantasy-first ideation - checking whether mechanics match emotional promise - identifying why a concept feels flat despite competent systems - aligning narrative, art, and design around one player promise Common patterns to watch for: - teams often describe setting instead of fantasy - many designs claim freedom while structurally delivering obedience - multiple fantasies can coexist, but only if they are hierarchized - a fantasy without systemic support is just expensive decoration - if the player role is vague, the fantasy probably is too ## Working principle A design is not just a set of mechanics. It is an answer to the question, "what do I get to become while playing this?" Use this skill to make that answer explicit and test whether the game earns it.

path: references/family-conventions.md
content: # Family Conventions

Use this file to keep this game-design skill family tonally and structurally aligned.

## Core style

- Be direct, concrete, and design-facing.
- Prefer clear diagnosis over academic display.
- Name the exact moment, system, or interaction where the issue appears.
- Avoid generic advice like "improve balance" or "add polish."
- When a tradeoff exists, state the tradeoff plainly.
- Favor actionable language over abstract theory recap.

## Analysis rules

- Audit player experience, not designer intention.
- Separate what is mechanically true from what players are likely to perceive.
- Distinguish local issues from structural issues.
- Call out contradictions instead of smoothing them over.
- Prefer 2 to 5 strong findings over a long bag of weak observations.
- If input is incomplete, infer cautiously and state assumptions.

## Recommendation rules

- Prioritize the highest-leverage fix first.
- State why the issue happens, not just what to change.
- When possible, provide one "minimal fix" and a broader strategic direction.
- If the right answer is removal, simplification, or reduction, say so.
- Separate must-fix issues from optional improvements when useful.

## Response conventions

Default sections should stay close to this order when applicable:
1. Target or framing
2. Diagnosis or profile
3. Key risks or contradictions
4. Recommendations
5. Minimal fix

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.

path: references/output-patterns.md
content: # Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

For each major recommendation, prefer this structure:
- **Issue** - what is going wrong
- **Cause** - why it is happening
- **Change** - what to alter
- **Expected effect** - how player experience should improve

## Minimal fix pattern

End with the smallest realistic change that would materially improve the design without requiring a total redesign.

## Evidence pattern

When the input includes specific moments, systems, complaints, or test observations:
- cite them directly
- tie every conclusion back to them
- avoid floating theory that is not anchored to the case

## Sharpness pattern

When several issues exist, prioritize:
1. trust-breaking problems
2. learning-blocking problems
3. motivation-killing problems
4. optimization or polish problems

Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)