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

--- name: game-design-player-persona-extractor description: Extract the ideal player persona and anti-persona for a game, feature, loop, or progression structure based on the design itself. Use when a team can describe mechanics but cannot clearly articulate who the design is truly for, which player motivations and tolerances it suits, which players it will alienate, or how audience fit should shape design decisions. Focus on behavioral and motivational personas first, and optionally add demographic or market-fit hypotheses when the user explicitly asks for that layer. --- # Game Design Player Persona Extractor Extract who a design is actually built for. Use this skill when a team can describe systems, loops, and mechanics, but not the kind of player who will love them, tolerate them, or bounce off them. The job is not to invent a fake marketing avatar. The job is to infer the player profile implied by the design. Focus on behavior, motivation, tolerance, learning style, and emotional appetite. Avoid demographic fluff unless the user explicitly asks for it. 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. Read `references/demographic-research-notes.md` when the user explicitly wants demographic support, market validation, or publisher-facing audience framing. ## Core principle A game becomes sharper when it serves a specific kind of player extremely well instead of vaguely trying to work for everyone. A useful persona does three things: - identifies who the design delights - identifies who the design frustrates or excludes - implies concrete design choices If the resulting persona could fit almost any game, it is too weak to matter. ## What to produce Generate: 1. **Ideal player persona** - the player this design best serves 2. **Anti-persona** - the player most likely to reject or churn from it 3. **Behavior profile** - how the player approaches play, learning, and decisions 4. **Emotional profile** - what they want to feel and what breaks the deal 5. **Design implications** - what the design must emphasize, protect, and avoid for this audience 6. **Optional demographic layer** - only when explicitly requested, add likely demographic or market-fit hypotheses that support the behavior-first persona rather than replacing it 7. **Optional market audience summary** - when requested for pitch, publishing, or strategy use, convert the persona into a concise audience-facing summary with demographic overlap, comparable-title signals, and confidence notes ## Process ### 1. Define the extraction target Clarify: - what exact game, feature, or loop is being analyzed - whether the persona is for the whole product or only one experience slice - what known constraints already shape audience fit Write: - **Extraction target** - **Scope** - **Known constraints** ### 2. Read the design for behavioral signals Look at features such as: - difficulty level - randomness level - pacing and session length - agency level - punishment severity - progression structure - strategic depth - repetition tolerance - required patience, experimentation, or precision Ask: - What kind of player will enjoy making these decisions repeatedly? - What kind of frustration is this design asking the player to tolerate? - Does it reward mastery, experimentation, social play, expression, optimization, calm routine, or high tension? ### 3. Infer the core motivation profile Common motivation buckets include: - mastery and skill growth - experimentation and discovery - optimization and efficiency - competition and status - expression and creativity - narrative curiosity - collection and completion - comfort, ritual, and low-pressure progress State which motivations the design strongly serves and which it serves poorly. ### 4. Infer the tolerance profile Judge what the implied player can comfortably tolerate in terms of: - difficulty - repetition - randomness - ambiguity - failure frequency - delayed rewards - long sessions or short bursts - social friction - optimization pressure This often reveals the anti-persona more clearly than the positive persona does. ### 5. Describe the play style and learning style Clarify how the ideal player tends to behave: - cautious or impulsive - planner or improviser - systems learner or fantasy chaser - repetition-based learner or novelty seeker - optimizer or role-player - solo-focused or socially motivated Write this as behavior, not vague adjectives. ### 6. Define emotional expectations Ask: - What does this player want to feel regularly? - What kind of tension is enjoyable to them? - What kind of frustration will they accept? - What kind of frustration will feel like betrayal? ### 7. Define the anti-persona State clearly who this is not for and why. Avoid generic anti-personas like "people who do not like games." Instead name the specific mismatch: - wants predictable progression but design thrives on variance - wants low-pressure comfort but loop demands intense optimization - wants expressive freedom but systems narrow into one dominant path ### 8. Convert the persona into design implications For each important persona trait, specify: - **Trait or expectation** - **What the design must do** - **What the design should avoid** Examples: - experimental learner -> outcomes must be legible enough to support testing - high variance tolerance -> randomness must still feel interpretable - low repetition tolerance -> loop needs novelty density - mastery-driven audience -> failure must teach, not merely punish ### 9. Add the optional demographic layer only when asked Use this step only if the user explicitly wants demographic data, audience hypotheses, or market-facing persona framing. Keep the logic in this order: 1. extract the behavioral persona first 2. infer which demographic clusters are most likely to overlap with that persona 3. if needed, use current market or genre data to test whether those demographic guesses are plausible Demographics should support the behavioral read, not drive it. When asked for this layer: - clearly label it as **hypothesis**, **market signal**, or **supporting demographic fit**, not as certainty - prefer ranges and segments over fake precision - distinguish between **likely demographic overlap** and **required target audience** - if external market validation is useful, search for recent player-demographic data for the genre, platform, region, or adjacent titles - note when the available data is broad market data rather than title-specific evidence Useful demographic dimensions may include: - age bands - platform skew - region - play frequency - spending profile - genre familiarity - solo versus social preference Avoid garbage personas like: - "25-year-old male who likes fun" - fabricated lifestyle backstory with no design relevance - demographic claims that contradict the behavior profile If evidence is weak, say so directly. ### 10. Use web research mode when the user wants validation Use web research mode when the user asks for demographic validation, audience evidence, market support, or current player data. In web research mode: - search for recent data first, preferably within the last 2 to 4 years when possible - prioritize reputable sources such as platform-holder reports, publisher reports, ESA, Newzoo, Statista-style summaries if clearly cited, GDC talks, Steam or console ecosystem reports, and credible market analyses - prefer genre-, platform-, or region-specific data over broad "all gamers" data when the design is niche - separate hard evidence from inference - cite what the evidence actually supports rather than stretching it Useful web-research questions: - what demographics over-index in this genre? - what platform and age skew is reported for comparable play patterns? - what monetization or session-length patterns are common in this audience? - what regional differences matter? When evidence is mixed, show the tension instead of pretending one clean answer exists. ### 11. Use title-comparison mode when comparable games matter Use title-comparison mode when the user asks for comp titles, adjacent audience fit, genre neighbors, or evidence from similar games. In title-comparison mode: - identify 2 to 5 comparable titles, not a giant dump - choose comps based on audience behavior, play pattern, and fantasy, not just surface theme - explain why each title is a useful comparison - infer likely audience overlap from those comps carefully - note where a comp is commercially useful but behaviorally misleading For each comparison, prefer: - **Comparable title** - **Why it overlaps** - **Likely shared audience traits** - **Important difference** ### 12. Use market-audience summary mode for pitch decks and publisher-facing work Use this mode when the user wants a concise audience summary for pitch decks, publishing conversations, strategy docs, or greenlight materials. In market-audience summary mode: - compress the behavior-first persona into a short, decision-useful audience summary - include the strongest likely demographic overlap only if it helps the audience case - mention comparable titles if they strengthen the argument - state confidence level and major uncertainty - avoid pretending the persona itself is validated market truth unless actual evidence was reviewed A good market-audience summary should answer: - who this game is mainly for - why that audience is a fit - what adjacent audiences may also convert - what audience mismatches or commercial risks are most important ## Response structure Use this structure unless the user asks for something else: ### Extraction Target - ... ### Ideal Player Persona - ... ### Core Motivations - ... ### Tolerance Profile - ... ### Play Style and Learning Style - ... ### Emotional Expectations - ... ### Anti-Persona - ... ### Design Implications 1. ... 2. ... 3. ... ### Optional Demographic Layer - Likely demographic overlap: ... - Confidence: ... - Supporting signal or market evidence: ... ### Optional Comparable Titles - ... ### Optional Market Audience Summary - ... ## Fast mode Use this quick pass when speed matters: - Who is this game perfect for? - What frustration are they willing to tolerate? - What kind of player will hate this? - What one design choice matters most for the ideal audience? - If demographic output was requested, what demographic overlap is plausible and how confident are we? - If market framing was requested, which comparable titles and audience signals best support the case? ## Usage notes This extractor is especially useful for: - early concept definition - pillar clarification - feature targeting - tuning difficulty and punishment - checking audience fit after prototypes - aligning design, product, and marketing language - preparing audience sections for pitch decks and publisher conversations - creating behavior-first audience summaries supported by market evidence Common patterns to watch for: - many teams describe mechanics first and audience second, which hides conflicts - a design can accidentally target incompatible personas at once - personas built from demographics are usually too weak to guide design - demographics are useful as a supporting layer, not as the foundation of the persona - the anti-persona is often more useful than the persona for clarifying tradeoffs - if everyone sounds like a fit, the design target is still foggy ## Working principle A design always chooses its player, even when the team refuses to admit it. Use this skill to make that choice visible and actionable.

path: references/demographic-research-notes.md
content: # Demographic Research Notes

Use this reference only when the user explicitly wants demographic support, market validation, or publisher-facing audience framing.

## Core rule

Start from the behavior-first persona. Use demographic data to support or challenge it, not to replace it.

## What to look for

Prefer evidence about:
- genre audience skew
- platform skew
- age-band concentration
- region concentration
- play frequency or session style
- spending propensity where relevant
- adjacent-title audience overlap

## Source priorities

Prefer, in rough order:
1. platform-holder and store ecosystem reports
2. major industry reports with clear methodology
3. reputable publisher or developer presentations
4. conference talks or postmortems with cited audience data
5. broader market summaries when narrower evidence is unavailable

## Reporting rules

- Label inferences as inferences.
- Distinguish title-specific evidence from genre-level evidence.
- Do not fake precision.
- If the evidence is weak, conflicting, or outdated, say so.
- Do not let demographics contradict the behavior-first persona without explaining why.

## Useful output labels

- Likely demographic overlap
- Evidence-backed audience signal
- Confidence level
- Important uncertainty
- Comparable-title support

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)