Stanislav Stankovic

---
name: game-dev-first-steps
description: Help a beginner or early-stage indie team turn a game idea into a practical starting plan. Use when someone asks how to start making a game, what to build first, how to approach development order, how to scope a concept for a solo dev, duo, or small team, or how to turn a rough game idea into a sensible first prototype or pitchable vertical slice. Ask a few core questions about the concept, team size, skill mix, platform, scope, release intent, and constraints, then recommend a simple development strategy with build order, risks, what to postpone, and concrete next steps.
---

# Game Dev First Steps

Turn an idea into a sensible early development strategy.

Use this skill when the user does not need a deep production plan yet. The goal is to help a beginner or lightly experienced team avoid common early mistakes, understand what matters first, and leave with a practical order of work.

Read `references/team-size-guidance.md` when team composition strongly affects the answer.
Read `references/development-order.md` when you need a default build order or beginner-safe sequencing.

## Core behavior

- Keep the language simple and non-jargony.
- Do not overwhelm the user with giant checklists.
- Ask only the minimum questions needed to give useful advice.
- Give strategy, not fake precision.
- Prefer scope reduction over feature ambition.
- Prefer testing and prototyping before content production.
- Treat solo, duo, and small-team realities differently.
- Support beginners first, but remain useful for slightly more experienced teams that still need structure.
- Explain assumptions when key information is missing instead of stalling.

## What to ask first

Ask a small set of questions before giving the plan. Adapt to what the user already told you.

Prioritize these:
1. What is the game idea in plain language?
2. Who is making it: solo, duo, or small team?
3. What skills does the team actually have right now?
4. What platform is the first version for?
5. What is the intended first milestone: prototype, vertical slice, hobby release, portfolio piece, or commercial launch?
6. How big is the intended first version?
7. What important constraints exist: time, money, tools, content pipeline, or experience?

If the user gives partial answers, do not stall. Infer carefully, state assumptions, and continue.

## What to diagnose

Quickly identify:
- the probable core loop
- the likely hardest part
- the main scope risk
- whether the concept is prototype-first or content-heavy
- whether the team ambition does not match the team size or skill mix
- whether the user is mixing up prototype, vertical slice, and full production

## Beginner traps to watch for

Flag these when relevant:
- starting with lore, worldbuilding, or story instead of the playable core
- planning too many features before proving the main loop
- choosing multiplayer too early
- making custom tech before proving the design
- making lots of art before the prototype is fun
- unclear ownership in a duo or small team
- no distinction between prototype, vertical slice, and full production
- trying to make the dream version first instead of the smallest convincing version
- treating monetization and platform features as proof of fun

## Response structure

Always organize the answer using this structure.

### Idea Snapshot
- one short summary of what they are trying to make
- one sentence on what matters most right now

### Team Reality
- team size
- skill mix
- likely strengths
- likely blind spots
- assumptions if information is missing

### Recommended Development Order
1. define the core player action and core loop
2. choose the smallest playable version that tests the main promise
3. build a rough prototype fast
4. test whether the main interaction is actually fun or interesting
5. revise scope and cut weak ideas
6. build a tiny vertical slice or first presentable version if the user needs to pitch
7. only then expand content, progression, interface, economy, and polish
8. prepare for release, handoff, or pitch usage

### What to Postpone
- list features or workstreams that should wait
- especially warn about multiplayer, advanced tech, large content production, social features, monetization scaffolding, and polish-heavy work if they are premature

### Biggest Risks
- give the top 2 to 4 risks
- explain them in plain language

### Best Next Steps
- give 3 to 5 concrete next actions
- at least one should be something they can do today

## Milestone adaptation

### If the user needs a prototype
- optimize for speed of learning
- use placeholder assets
- reduce to the smallest loop that tests the idea
- focus on whether the idea works at all

### If the user needs a vertical slice
- first prove the loop in rough form
- then polish one narrow band of the experience
- include only enough progression, economy, or UI to communicate the final direction
- do not mistake vertical slice work for full production work

### If the user wants a full release plan
- still start from the smallest convincing version
- recommend milestone-based expansion instead of broad upfront production
- keep advice directional rather than pretending to estimate precisely from thin input

## Team-size adaptation

### Solo
- push hard toward simplicity
- recommend one core mechanic, one platform, and one short path to playable
- suggest using existing engines, assets, and tools instead of building everything from scratch
- strongly discourage early multiplayer unless the user explicitly accepts the cost and risk
- emphasize momentum and finishability over ambition

### Duo
- identify who owns what
- recommend a simple division such as gameplay plus content, or code plus art
- highlight communication, handoff friction, and dependency risks
- keep the design small enough that both people can understand the whole project

### Small team
- define roles and dependencies early
- recommend a milestone sequence rather than everyone building everything at once
- identify who should own prototype validation, pipeline setup, and production planning
- remind them that a larger team can burn more time on coordination and wasted work, not just produce more content

## Style guidance

- Be encouraging without being fluffy.
- If the user is over-scoped, say so clearly.
- If the idea is viable only in a reduced form, recommend the reduced form.
- If information is missing, ask 2 to 4 focused questions, not 12.
- If the user seems overwhelmed, simplify the plan further.
- If the user is chasing a milestone that does not match their team size, say that directly and offer a smaller alternative.

## Fast mode

Use this compressed flow when the user wants a quick answer:
- what are you making
- who is making it
- what is the first milestone
- what is the smallest playable version
- what should be built first
- what should wait until later

## Working principle

A beginner does not need a perfect plan. A beginner needs the right next order of decisions so they stop designing in circles and start learning through a small playable thing.

FILE:references/development-order.md
# Development Order

Use this reference when the user asks what order to do things in or what should be built first.

## Default beginner-safe sequence

1. Define the core fantasy
   - What is the player basically doing?
   - What is the appeal in one sentence?

2. Define the core loop
   - What does the player do repeatedly?
   - What input, feedback, reward, and repeat structure exists?

3. Define the smallest playable version
   - Remove non-essential systems
   - Keep only what is needed to test the core loop

4. Build a rough prototype
   - Use placeholder art
   - Ignore polish
   - Optimize for speed of learning

5. Test and learn
   - Is it understandable?
   - Is it interesting for even a few minutes?
   - What fails first: controls, clarity, pacing, challenge, reward?

6. Cut and refocus
   - Remove weak or unnecessary features
   - Keep only what strengthens the core

7. Build a tiny vertical slice
   - Make one small section look and feel closer to the target quality
   - Use this to test production reality, not just design appeal

8. Plan production
   - estimate content needs
   - identify bottlenecks
   - choose what can be reused and what must be made fresh

9. Expand carefully
   - add content and supporting systems only after the foundation works

10. Polish and prepare release
   - usability
   - readability
   - progression tuning
   - bug fixing
   - packaging and release needs

## What usually comes too early

These are often started before they deserve it:
- lore and deep narrative backstory
- advanced progression systems
- large level counts
- detailed UI polish
- save systems more complex than needed
- optimization before the game exists
- custom tech stacks
- online multiplayer
- marketing beats before a convincing playable exists

## Useful simplification rule

When unsure what to do next, choose the step that most increases learning about whether the game is worth continuing.

## Distinguish these clearly

### Prototype
Build to learn whether the idea works.

### Vertical slice
Build to learn whether the intended quality and pipeline are achievable.

### Production
Build the actual broader game once the direction is proven.

### Polish
Improve the experience after the main structure already works.

FILE:references/team-size-guidance.md
# Team Size Guidance

Use this reference when the answer should noticeably change based on who is making the game.

## Solo

Typical strengths:
- speed of decision making
- unified vision
- low communication overhead

Typical risks:
- overscoping
- skill gaps
- burnout
- polishing too many disciplines at once

Good advice patterns:
- reduce the number of systems
- prefer one strong interaction over many average ones
- keep content needs low
- use off-the-shelf tools and assets where acceptable
- finish a tiny version before expanding

## Duo

Typical strengths:
- complementary skills
- more output than solo without full team overhead
- easier prototyping if roles are clear

Typical risks:
- fuzzy ownership
- one partner blocking the other
- hidden mismatch in ambition or available time

Good advice patterns:
- define ownership early
- choose a prototype one person can keep moving even if the other is busy
- cut features that require constant cross-discipline synchronization
- align on scope and release goal early

## Small Team

Typical strengths:
- broader skill coverage
- better chance of parallel work
- more production capacity if pipeline is clear

Typical risks:
- coordination cost
- waiting on dependencies
- people making content for systems that are not validated yet
- uneven understanding of the core vision

Good advice patterns:
- lock the core loop before broad production
- assign milestone owners
- validate gameplay before mass asset production
- use simple milestones: prototype, vertical slice, production, polish

## Warning signs across all team sizes

- the pitch depends on many systems working together before anything is fun
- the team wants advanced online multiplayer as a first project
- the plan assumes custom engine or custom tools too early
- the first milestone is content-heavy instead of learning-heavy
- nobody can explain the smallest playable version in one paragraph

---
name: game-design-prototype-intent-audit
description: Audit a game feature, system concept, prototype plan, or preproduction proposal to determine whether the prototype is meant to sell the idea or reveal unknowns, and whether the prototype scope matches that intent. Use when teams are unclear about why they are prototyping, when a prototype risks becoming a demo in disguise, or when precious prototype time may be spent proving known strengths instead of testing real uncertainties.
---

# Game Design Prototype Intent Audit

Decide what the prototype is for before deciding what the prototype should contain.

Use this skill to audit whether a prototype is being built to convince stakeholders that an idea works, or to reveal the least-understood parts of the design. These two goals require different prototype choices. Confusing them is one of the most common ways to waste prototype time.

Read `references/prototype-modes.md` when classifying the prototype intent.
Read `references/unknowns-checklist.md` when identifying what a learning prototype should target.
Read `references/failure-patterns.md` when diagnosing common prototype mistakes.

## What to produce

Produce:
1. **Prototype read** - what is being prototyped and why
2. **Intent diagnosis** - whether this is a selling demo, a learning prototype, or a confused hybrid
3. **Scope fit** - whether the prototype contents match the stated intent
4. **Unknowns coverage** - what the prototype is or is not actually testing
5. **Risk diagnosis** - what time or learning may be wasted under the current plan
6. **Recommendation** - what to prototype instead, emphasize, cut, or sequence differently

## Process

### 1. Clarify the prototype ask
Ask:
- what idea, feature, or concept is being prototyped?
- who is the prototype for?
- what decision is the prototype supposed to unlock?
- what would count as success for the prototype itself?

### 2. Diagnose intent
The prototype usually serves one dominant purpose:
- **Selling demo** - prove the concept is exciting, legible, or worth greenlighting
- **Learning prototype** - reveal unknowns and answer risky design questions
- **Confused hybrid** - trying to sell the idea while also pretending to test unknowns, without doing either well

### 3. Check scope fit
Ask whether the implementation focus matches the intent.
For example:
- selling demos usually emphasize strengths, clarity, and presentability
- learning prototypes should target unclear, risky, or least-understood aspects

### 4. Audit unknowns
If the team claims the prototype is for learning, identify:
- what specific unknowns are being tested
- whether the prototype can actually answer them
- what it is avoiding or glossing over

### 5. Diagnose failure mode
Common failures include:
- demo dressed up as learning
- prototype solving the easiest part, not the riskiest part
- too much polish hiding too little insight
- trying to answer too many questions at once
- building broad slices when one narrow uncertainty should be isolated

### 6. Recommend a better prototype move
Possible recommendations:
- turn it honestly into a selling demo
- strip it down into a learning prototype
- split one prototype into two sequential prototypes
- narrow the question set
- focus on the riskiest unknown first

## Response structure

### Prototype Read
- ...

### Intent Diagnosis
- ...

### Scope Fit
- ...

### Unknowns Coverage
- ...

### Risk Diagnosis
- ...

### Recommendation
- ...

## Fast mode
- Who is this prototype for?
- Is it trying to sell the idea or learn something?
- What unknowns are actually being tested?
- What is being polished that does not answer the real question?
- What is the better prototype plan?

## Style rules
- Be explicit about the dominant intent.
- Do not flatter vague prototype plans.
- Prefer one answered question over many implied ones.
- If the prototype is really a demo, say so cleanly.
- If the prototype is not testing the true risk, point that out directly.

## Working principle

A prototype is not automatically useful because it exists.
Its value comes from whether it is built for the right purpose and judged by the right standard.
FILE:references/failure-patterns.md
# Failure Patterns

## 1. The demo in disguise
The team says it wants learning, but the prototype mainly showcases strengths and avoids risk.

## 2. The wrong unknown
The prototype tests something easy to build, not the thing most likely to kill the concept.

## 3. The polish trap
Too much effort goes into presentation quality and too little into informative structure.

## 4. The everything prototype
The team tries to answer too many questions at once and learns almost nothing clearly.

## 5. The premature slice
A broad implementation slice is built before the team has isolated the key design uncertainty.

## 6. The audience mismatch
A rough learning prototype is judged like a market-facing demo, or a selling demo is mistaken for evidence that core unknowns are resolved.

## Practical recommendation

When in doubt, ask:
- what decision does this prototype unlock?
- what unknown disappears if this prototype works?
If neither answer is clear, the prototype plan is weak.
FILE:references/prototype-modes.md
# Prototype Modes

## 1. Selling demo
A prototype built to convince stakeholders, publishers, leadership, or a broader team that the idea is exciting and worth backing.

### Typical traits
- emphasizes strengths
- presents the fantasy clearly
- hides or skips awkward unknowns
- polished enough to create confidence

### Good use
- new concept pitch
- external greenlight support
- internal excitement building

### Risk
- can create false confidence if mistaken for a learning tool

## 2. Learning prototype
A prototype built to reveal unknowns and answer risky design questions.

### Typical traits
- focuses on the least-understood part
- may look rough
- isolates one or a few critical variables
- values clarity of learning over presentability

### Good use
- feature viability questions
- interaction unknowns
- economy or pacing risk checks
- production feasibility risk checks

### Risk
- may look unimpressive if judged like a pitch demo

## 3. Confused hybrid
A prototype trying to do both jobs without clear prioritization.

### Typical traits
- partially polished
- partially exploratory
- unclear success criteria
- neither convincingly sellable nor sharply diagnostic

### Risk
- wastes time
- produces ambiguous conclusions
- gives stakeholders the wrong confidence

## Decision rule

Choose the dominant intent first.
If both intents matter, sequence them instead of blending them badly.
FILE:references/unknowns-checklist.md
# Unknowns Checklist

Use this when the prototype is supposed to teach something.

## Common unknown types
- Is the core interaction actually fun?
- Does the loop hold up after repetition?
- Is the risk/reward structure readable?
- Does the feature fit the host game's pacing?
- Is the value proposition understandable?
- Can players learn the feature without overload?
- Does the system create the intended emotion or fantasy?
- Are production costs or dependencies worse than expected?
- Does the simplified form still preserve the essential value?

## Good learning-prototype questions
- narrow
- falsifiable enough to answer
- tied to a real risk
- testable in limited scope

## Weak learning-prototype questions
- too broad
- too vague
- impossible to answer from the chosen scope
- already answered by the concept itself

## Rule

A learning prototype should reveal something important that the team does not already know.

---
name: game-design-player-segment-perception-audit
description: Audit a game feature, live update, roadmap item, event, or content drop by how different player segments are likely to perceive it. Use when a feature is aimed at one cohort but visible to others, when update messaging may create excitement for players who cannot meaningfully access the feature, or when you need to understand how new, mid, and elder players will read the same feature differently.
---

# Game Design Player Segment Perception Audit

Check not only who the feature is for, but who will see it, misunderstand it, resent it, or feel left out by it.

Use this skill to audit a feature through the eyes of different player segments. The goal is not to please every segment equally. The goal is to understand who the feature is actually serving, what other groups will perceive, and where update visibility, access, and expectation can create disappointment or wasted communication.

Read `references/segment-layers.md` when mapping the main audience groups.
Read `references/perception-failures.md` when diagnosing common update-perception mistakes.
Read `references/recommendation-patterns.md` when deciding how to adjust targeting, access, or messaging.

## What to produce

Produce:
1. **Feature read** - what the feature is and who it seems intended for
2. **Target segment read** - which cohort is supposed to care most and why
3. **Cross-segment perception** - how other player groups are likely to interpret it
4. **Access and visibility mismatch** - who will hear about it versus who can actually use it
5. **Risk diagnosis** - what disappointment, alienation, or wasted hype may result
6. **Recommendation** - how to retarget, reframe, gate, soften, or broaden the feature rollout

## Process

### 1. Clarify the feature and its intended audience
Ask:
- what is being added or changed?
- which player segment is the real target?
- why would that segment care?
- what specific value does the feature create for them?

### 2. Map the main player segments
At minimum consider:
- new players
- midgame players
- elder/endgame players

Also consider when relevant:
- free players
- spenders
- competitive players
- collectors
- social players
- lapsed returners

### 3. Audit visibility versus access
Check:
- who will see this feature in patch notes, ads, art, store pages, or UI surfaces?
- who can actually access it soon?
- who must wait, grind, pay, or reach a threshold first?
- is the feature headline content for players who cannot meaningfully touch it?

### 4. Audit perception by segment
For each important segment ask:
- will they care?
- will they understand why it matters?
- will they feel invited, excluded, indifferent, or misled?
- does the update strengthen their sense of future aspiration or create disappointment?

### 5. Diagnose mismatch risk
Look for patterns such as:
- excitement generated for the wrong audience
- feature aimed at elder players but marketed broadly to everyone
- midgame players ignored even though they are the pipeline to elder status
- access friction turning aspiration into resentment
- feature value obvious only to one cohort while others see noise

### 6. Recommend a better segment strategy
Possible moves:
- target communications more narrowly
- create smaller companion value for non-target segments
- adjust unlock timing or access path
- reduce visible hype for inaccessible content
- provide aspiration framing without overpromising immediate relevance

## Response structure

### Feature Read
- ...

### Target Segment Read
- ...

### Cross-Segment Perception
- ...

### Access and Visibility Mismatch
- ...

### Risk Diagnosis
- ...

### Recommendation
- ...

## Fast mode
- Who is this really for?
- Who else will see it?
- Who will care, who will not, and who will feel disappointed?
- Is the visibility broader than the access?
- What is the best fix: targeting, framing, or access?

## Style rules
- Do not assume one feature must serve all players equally.
- Distinguish target audience from visible audience.
- Pay special attention to middle cohorts, not just new and elder players.
- Be concrete about disappointment mechanics, not just vague sentiment.
- Treat aspiration carefully; it can motivate or alienate depending on access.

## Working principle

A feature is not experienced only by the players who use it.
It is also experienced by the players who see it, anticipate it, misunderstand it, or discover they are excluded from it.
FILE:references/perception-failures.md
# Perception Failures

## 1. Headline for the wrong audience
The feature is marketed broadly, but only a narrow advanced cohort can really use it.

## 2. Aspiration turns into resentment
The feature looks exciting, but the path to access is too long, too unclear, or time-limited.

## 3. Midgame invisibility
New and elder players are considered, but the broad middle of the audience is ignored.

## 4. Segment value mismatch
The intended audience sees strong value, but everyone else sees clutter, unfairness, or irrelevance.

## 5. Visibility without comprehension
Players see the feature but do not understand why they should care.

## 6. Patch-note theater
An update appears large in communications but creates little meaningful value for most visible players.

## 7. Incentive mismatch
The feature is supposed to motivate one segment but instead discourages another critical cohort.

FILE:references/recommendation-patterns.md
# Recommendation Patterns

## 1. Target communications more honestly
Show the feature mainly to the players who can meaningfully care about it now.

## 2. Add companion value
If a feature targets elders, consider a lighter adjacent benefit for mid or newer players.

## 3. Improve access framing
If content is aspirational, make the path feel achievable and emotionally fair.

## 4. Reduce overhype for inaccessible content
Do not make the whole update fantasy about something most players cannot touch.

## 5. Use staged rollout messaging
Explain which cohorts get what now, and what later cohorts can look forward to.

## 6. Protect the middle
Make sure midgame players see themselves in the update story when they are the future of the game.

FILE:references/segment-layers.md
# Segment Layers

Use these as the default player groups.

## 1. New players
Players near the start of the game.

Typical concerns:
- basic comprehension
- early motivation
- feeling invited into the future of the game
- not being teased by inaccessible content too aggressively

## 2. Midgame players
Players past onboarding but not yet at the deep end.

Typical concerns:
- whether the game still feels like it is opening up
- whether they are on a credible path toward later content
- whether updates acknowledge their stage rather than skipping over them

Important note:
Midgame players are often overlooked even though they are the pipeline into elder cohorts.

## 3. Elder / endgame players
Highly progressed players near the end of current content vectors.

Typical concerns:
- boredom prevention
- meaningful new goals
- status and mastery maintenance
- reasons to stay and spend

## 4. Spender layers
Use when relevant:
- free players
- light spenders
- heavy spenders

Ask:
- is the feature's value path fair, aspirational, or paywalled in a way that changes perception?

## 5. Motivational clusters
Use when relevant:
- competitive players
- collectors
- social players
- decorators / expressive players
- routine habit players

## Rule

Start with lifecycle stage (new / mid / elder), then add spending or motivational slices only if they materially change the perception read.

---
name: game-design-kpi-coverage-audit
description: Audit a game feature, roadmap candidate, UX improvement, support system, connective-tissue feature, or quality-of-life change for KPI coverage bias and measurement blind spots. Use when a team is overvaluing only directly attributable metrics, neglecting foundational work that is hard to measure, or struggling to justify features whose value is real but not cleanly tied to one headline KPI.
---

# Game Design KPI Coverage Audit

Check whether the evaluation framework is seeing the whole value of the feature, or only the parts that are easy to measure.

Use this skill when a feature is being judged mainly through directly attributable KPIs and you suspect that measurement logic is biasing the team toward flashy, self-contained systems while undervaluing connective tissue, UX, quality-of-life, enabling systems, or long-term structural work.

Read `references/value-types.md` when identifying what kind of value the feature creates.
Read `references/blind-spot-patterns.md` when diagnosing common KPI-coverage failures.
Read `references/recommendation-patterns.md` when deciding how to justify or evaluate hard-to-measure work.

## What to produce

Produce:
1. **Feature read** - what the proposal is and what role it plays
2. **Current KPI framing** - what the team is measuring or expecting to measure
3. **Coverage diagnosis** - what value is covered versus ignored by those KPIs
4. **Blind spots** - what may be neglected because it is hard to measure directly
5. **Risk of mis-prioritization** - what bad decisions may result from the current framing
6. **Evaluation recommendation** - how the feature should be justified, monitored, or compared more fairly

## Process

### 1. Identify the role of the feature
Clarify whether the proposal is mainly:
- a standalone engagement feature
- a monetization feature
- a progression layer
- a UX improvement
- connective tissue between systems
- quality-of-life work
- support infrastructure for future features
- a clarity, pacing, or usability improvement

### 2. Identify the current KPI story
Ask:
- what metric is the team using to justify this feature?
- is it tied to revenue, retention, engagement, conversion, economy balance, sentiment, or something else?
- is the KPI direct, indirect, speculative, or absent?

### 3. Audit KPI coverage
Check whether the metric framing captures the actual value of the work.
Look for value types such as:
- direct monetization
- direct engagement lift
- retention support
- reduced friction
- improved comprehension
- stronger connective tissue between systems
- future feature enablement
- long-term sustainability
- reduced support burden or balancing burden

### 4. Identify blind spots
Common signs:
- the feature is dismissed because it cannot move one headline KPI on its own
- direct-revenue features are always favored over structural health
- UX work is treated as optional because it lacks clean attribution
- foundational work is postponed until crisis
- enabling systems are undervalued because they mostly improve the performance of other features

### 5. Judge prioritization risk
Ask:
- what happens if this feature is judged only by direct KPI lift?
- is the team likely to underinvest in maintenance, UX, clarity, infrastructure, or connective tissue?
- could the current framework systematically reward short-term visible wins over long-term health?

### 6. Recommend better evaluation
Possible moves:
- use a mixed scorecard instead of one KPI
- classify the feature as enabling or connective work rather than forcing a fake direct KPI
- evaluate via downstream support of other systems
- allocate protected capacity for high-value, hard-to-measure work
- compare opportunity cost honestly rather than pretending everything must tie to one direct metric

## Response structure

### Feature Read
- ...

### Current KPI Framing
- ...

### Coverage Diagnosis
- ...

### Blind Spots
- ...

### Risk of Mis-Prioritization
- ...

### Recommendation
- ...

## Fast mode
- What is this feature actually for?
- What KPI is being used to justify it?
- What important value is not being captured by that KPI?
- What bad prioritization decision could this cause?
- How should the team evaluate it more fairly?

## Style rules
- Do not dismiss KPIs; diagnose their limits.
- Do not invent fake measurable certainty for support work.
- Distinguish direct value from enabling value.
- Prefer fairer framing over anti-metrics rhetoric.
- Be specific about how blind spots distort roadmap decisions.

## Working principle

Teams often prioritize what they can measure cleanly, not what matters most.
Use this skill to expose where KPI logic is too narrow for the actual design value on the table.
FILE:references/blind-spot-patterns.md
# Blind Spot Patterns

Common KPI-coverage failures in feature evaluation.

## 1. Flashy feature bias
Standalone systems with easy KPI stories get prioritized over support work.

Typical result:
- roadmap tilts toward visible surface features
- UX, maintenance, and connective tissue are starved

## 2. Fake metric justification
A hard-to-measure feature is given a weak or performative KPI story just to fit the process.

Typical result:
- false confidence
- poor post-launch reading
- shallow discussion of real value

## 3. Connective tissue neglect
Features that improve relationships between systems are undervalued because they do not own a metric spike.

Typical result:
- systems feel fragmented
- players experience friction between loops
- no team owns the glue

## 4. QoL starvation
Usability improvements are postponed because their benefits are broad, indirect, and hard to isolate.

Typical result:
- everyday friction accumulates
- player fatigue rises
- support burden rises

## 5. Enabler invisibility
Foundational work is delayed because the immediate metric return is weak.

Typical result:
- teams repeatedly build expensive one-offs
- future features are slower, worse, or more fragile

## 6. Short-termism
The evaluation framework rewards immediate measurable lift over long-term structural health.

Typical result:
- metrics improve briefly while system health worsens
- design debt accumulates

## 7. Cannibalization blindness
A feature appears KPI-positive in isolation but harms adjacent systems.

Typical result:
- direct metric looks good
- broader ecosystem suffers
- net value is misread

FILE:references/recommendation-patterns.md
# Recommendation Patterns

Use these moves when KPI framing is too narrow.

## 1. Mixed scorecard
Use more than one kind of success criterion.

Example mix:
- one headline KPI
- one usability or sentiment indicator
- one strategic or enabling justification

## 2. Category correction
Explicitly classify the feature as direct, connective, enabling, QoL, or sustainability work.

Why:
- prevents forcing every feature into the same evaluation logic

## 3. Protected capacity
Reserve some roadmap capacity for high-value work that is structurally important but hard to attribute.

Why:
- prevents total starvation of support work under pressure

## 4. Downstream-value framing
Judge the feature by how it improves the performance of adjacent systems.

Why:
- better fit for connective and enabling features

## 5. Opportunity-cost framing
Compare the risk of not doing the feature, not just the direct upside of doing it.

Why:
- many support features matter because their absence creates drag or fragility

## 6. Honest uncertainty
If impact is real but hard to isolate, say so.

Why:
- fake precision is worse than explicit ambiguity

FILE:references/value-types.md
# Value Types

Use these categories to identify what kind of value a feature creates.

## 1. Direct feature value
The feature can plausibly influence a headline KPI on its own.

Examples:
- monetization bundles
- event participation loops
- collectible systems tied to spending or retention
- direct progression accelerators

Typical measurement:
- revenue lift
- engagement lift
- retention lift
- participation rate

## 2. Connective-tissue value
The feature improves how existing systems work together.

Examples:
- bridges between progression layers
- better event surfacing
- improved transitions between loops
- cross-system clarity improvements

Typical challenge:
- impact is diffuse and spread across several features rather than one metric spike

## 3. UX and quality-of-life value
The feature reduces friction, confusion, or maintenance pain.

Examples:
- inventory usability improvements
- better filtering or sorting
- clearer feedback and navigation
- fewer taps for routine tasks

Typical challenge:
- value is obvious in player experience but difficult to attribute cleanly to one KPI

## 4. Enabling value
The feature creates foundation for future systems or makes later work cheaper and stronger.

Examples:
- tool support
- reusable event scaffolding
- modular progression support
- backend or logic frameworks that future features depend on

Typical challenge:
- value arrives later and through other features

## 5. Sustainability value
The feature reduces long-term operational cost or future fragility.

Examples:
- reduced balancing burden
- cleaner economy structure
- lower support overhead
- fewer live-ops maintenance traps

Typical challenge:
- benefits are preventive rather than dramatic

## Practical rule

A feature may create more than one value type.
Do not force every feature into direct KPI logic if its real value is connective, enabling, or sustainability-oriented.

---
name: game-design-systematizing-empathizing-audit
description: "Evaluate a game, feature, system, UX flow, progression loop, live-ops mechanic, monetization surface, or design concept on two axes: systematizing and empathizing. Use when you want to understand whether a design is structurally logic-driven or emotionally player-attuned, what kind of player personas it is likely to attract or repel, and what practical consequences follow from that positioning without assuming one quadrant is universally best."
---

# Game Design Systematizing Empathizing Audit

Position the design by how strongly it rewards system-thinking and how strongly it reflects emotional understanding of the player.

Use this skill to understand what kind of design a concept is becoming, what kind of people it is likely to appeal to, and what tradeoffs come with that positioning. The goal is not to force every concept toward an imagined ideal balance. The goal is to diagnose where the design sits, who that tends to work for, who may reject it, and whether that positioning feels intentional or accidental.

Read `references/axis-definitions.md` when judging the two axes.
Read `references/quadrant-reads.md` when describing what the position tends to feel like in practice.
Read `references/persona-tendencies.md` when mapping likely audience appeal and rejection.

## What to produce

Produce:
1. **Design read** - what the concept is trying to do
2. **Systematizing position** - how strongly it emphasizes logic, structure, mastery, and model-building
3. **Empathizing position** - how strongly it emphasizes emotional fit, player sensitivity, warmth, expression, and humane friction handling
4. **Positioning read** - what this combination tends to feel like in practice
5. **Likely persona appeal** - who is likely to enjoy or value this design
6. **Likely rejection pattern** - who may bounce and why
7. **Practical consequences** - what follows for onboarding, retention, monetization, community, or communication
8. **Recommendation** - how to lean into, counterweight, clarify, or intentionally preserve the position

## Process

### 1. Read the design at the player-experience level
Clarify:
- what the concept wants the player to do
- what kind of player experience it seems to prioritize
- whether the design is asking for mastery, comfort, expression, optimization, social belonging, emotional immersion, or some combination

### 2. Judge the systematizing axis
Ask how strongly the design rewards:
- understanding rules
- building internal models
- predicting outcomes
- optimizing behavior
- mastering systems
- engaging with strategic structure

Look for evidence such as:
- clear rule consistency
- explicit feedback and cause-effect legibility
- optimization depth
- mastery curves
- strategic planning pressure
- meaningful structural complexity

### 3. Judge the empathizing axis
Ask how strongly the design reflects understanding of:
- player emotional reality
- frustration tolerance
- comfort and dignity
- expressive identity
- emotional readability
- social sensitivity
- humane handling of failure, pressure, and confusion

Look for evidence such as:
- emotionally considerate onboarding
- softened or well-framed failure
- expressive play support
- social meaning beyond pure function
- sensitivity to frustration and player mood
- systems that feel humane rather than merely correct

### 4. Describe the resulting position
Do not rank the quadrant morally.
Describe what this position tends to mean.
For example:
- precise but emotionally austere
- warm and intuitive but structurally soft
- deep and humane but demanding to execute well
- underdefined and low-intent on both axes

### 5. Map likely persona appeal
Infer which player tendencies are likely to find this attractive.
Possible personas include:
- optimizer
- systems thinker
- mastery-seeker
- competitive achiever
- tinkerer
- cozy comfort-seeker
- expressive identity player
- social harmony player
- narrative-relational player
- low-friction casual
- routine habit player

Use these as practical shorthand, not rigid psychological categories.

### 6. Map likely rejection
Ask which players are likely to bounce and why.
Common causes include:
- too much cold optimization pressure
- too little structural depth
- not enough emotional cushioning
- too much emotional softness for mastery-seekers
- social sterility
- unclear or weak challenge identity

### 7. Extract practical implications
Describe what this position tends to imply for:
- onboarding
- retention
- monetization tolerance
- community behavior
- feature communication
- audience targeting
- risk of mismatch between fantasy and system

### 8. Recommend intentionality
End with a practical recommendation such as:
- lean further into this audience fit
- add a small counterweight on the weaker axis
- stop pretending the design is for everyone
- communicate the positioning more honestly
- preserve the current direction because it matches the concept well
- simplify a mismatch between emotional promise and structural reality

## Response structure

### Design Read
- ...

### Systematizing Position
- ...

### Empathizing Position
- ...

### Positioning Read
- ...

### Likely Persona Appeal
- ...

### Likely Rejection Pattern
- ...

### Practical Consequences
- ...

### Recommendation
- ...

## Fast mode
- How logic-driven and mastery-oriented is this design?
- How emotionally considerate and player-attuned is it?
- What kind of player is most likely to love this?
- What kind of player is most likely to bounce?
- What is the most important consequence of that positioning?
- Should the team lean in, counterbalance, or clarify?

## Style rules
- Do not assume one quadrant is best.
- Do not confuse warmth with weakness.
- Do not confuse rigor with quality.
- Tie judgments to observable design consequences.
- Use personas as tendencies, not as deterministic labels.
- If the design is mismatched, say whether the mismatch feels intentional or accidental.

## Working principle

A design does not appeal to everyone in the same way.
This skill exists to clarify what kind of player the design is really speaking to, and what structural-emotional tradeoffs come with that choice.
FILE:references/axis-definitions.md
# Axis Definitions

Use these definitions to judge the two axes precisely and avoid vague psych language.

## Systematizing

### Definition
How strongly the design rewards understanding rules, building internal models, predicting outcomes, optimizing behavior, and mastering explicit structure.

### High-systematizing signs
- strong rule consistency
- clear cause and effect
- explicit feedback loops
- meaningful optimization space
- visible mastery curve
- planning and prediction matter
- better understanding reliably improves performance

### Low-systematizing signs
- weak optimization pressure
- soft or fuzzy structural logic
- low emphasis on mastery
- outcomes driven more by mood, expression, or flow than by deep rule understanding
- little reward for building a precise internal model

### Important note
Low systematizing does not automatically mean shallow.
A design can intentionally prioritize ambiance, expression, social ease, or emotional clarity over strategic depth.

## Empathizing

### Definition
How strongly the design reflects understanding of player emotional reality, frustration tolerance, comfort, dignity, expression, social sensitivity, and humane handling of pressure or confusion.

### High-empathizing signs
- emotionally considerate onboarding
- failure that is framed, cushioned, or meaningfully teachable
- support for expression or identity
- sensitivity to frustration, overwhelm, and emotional pacing
- social systems that feel human rather than purely transactional
- design choices that respect how players actually feel, not only how systems behave

### Low-empathizing signs
- emotionally austere design
- low concern for cushioning frustration
- systems assume players will adapt if logic is sound
- little emotional recovery or expressiveness
- social surfaces are functional but emotionally sterile
- player discomfort is treated as acceptable collateral for rigor

### Important note
Low empathizing is not automatically bad.
It may be entirely appropriate for a design aimed at mastery-first players who value precision and challenge over comfort.

## Practical scoring guidance

Use qualitative positioning rather than fake precision.
Helpful language:
- low
- medium-low
- medium
- medium-high
- high

Only use exact numbers if the user explicitly asks.

## Decision rule

Judge each axis by what the design consistently rewards and communicates, not by isolated details.
A single friendly UI flourish does not make a game high-empathizing.
A single upgrade tree does not make a game high-systematizing.
Look for the dominant pattern of the experience.
FILE:references/persona-tendencies.md
# Persona Tendencies

Use these persona labels as tendencies, not fixed psychological boxes.

## System-heavy appeal tendencies

### Optimizer
Likes:
- efficiency
- best-path discovery
- high information value
- resource conversion clarity

May reject:
- soft emotional framing without structural payoff
- fuzzy or low-stakes decision spaces

### Systems thinker
Likes:
- elegant interactions
- predictable outcomes
- coherent design logic
- deep internal models

May reject:
- inconsistency
- sentiment-first design that weakens structure

### Mastery-seeker
Likes:
- skill growth
- precision
- meaningful difficulty
- visible improvement through understanding and practice

May reject:
- over-cushioned failure
- flat challenge

### Competitive achiever
Likes:
- ladders
- rankings
- comparative performance
- optimization under pressure

May reject:
- emotionally soft structures that reduce edge or status value

## Empathy-heavy appeal tendencies

### Cozy comfort-seeker
Likes:
- warmth
- low intimidation
- emotional safety
- pleasing routines
- light friction

May reject:
- cold punishment
- relentless optimization pressure

### Expressive identity player
Likes:
- self-expression
- personalization
- style and emotional identity
- systems that support personal taste over strict efficiency

May reject:
- rigid dominant strategies
- low-expression structures

### Social harmony player
Likes:
- belonging
- helping
- soft cooperation
- emotionally meaningful social interactions

May reject:
- sterile or combative social systems

### Narrative-relational player
Likes:
- emotional context
- character meaning
- humane pacing
- systems that support feeling, relationship, or reflection

May reject:
- heavily abstract structures with no emotional grounding

### Low-friction casual
Likes:
- quick understanding
- low pressure
- immediate readability
- easy re-entry

May reject:
- steep mastery demands
- complex interdependent systems

## Mixed-profile audiences

Some concepts appeal to blended tendencies, such as:
- optimizer + mastery-seeker
- cozy comfort-seeker + expressive identity player
- systems thinker + narrative-relational player
- competitive achiever + social harmony player in guild or team settings

## Use rule

Do not claim a design appeals to everyone.
Identify the strongest likely audience fit, the secondary fit, and the most likely rejection cluster.
That is usually enough for a practical positioning read.
FILE:references/quadrant-reads.md
# Quadrant Reads

Use these as descriptive tendencies, not universal rankings.

## High systematizing / low empathizing

### Typical feel
- precise
- demanding
- rigorous
- mastery-first
- emotionally austere
- respected for depth more than loved for warmth

### Typical strengths
- strong skill expression
- clear optimization appeal
- high reward for learning and mastery
- good fit for competitive or systems-heavy audiences

### Typical risks
- harsh onboarding
- emotional coldness
- frustration without cushioning
- alienation of players seeking warmth, comfort, or expression

## Low systematizing / high empathizing

### Typical feel
- warm
- intuitive
- low-friction
- emotionally legible
- expressive
- often cozy, soothing, or socially inviting

### Typical strengths
- strong emotional accessibility
- easy approachability
- broad comfort appeal
- lower intimidation for new or tired players

### Typical risks
- softer mastery ceiling
- weaker strategic grip
- vagueness or mushiness if too little structure supports the fantasy
- rejection from optimizer-heavy audiences

## High systematizing / high empathizing

### Typical feel
- rich
- thoughtful
- structurally intelligent and emotionally aware
- capable of serving both mastery and humane player treatment

### Typical strengths
- strong long-term loyalty potential
- depth with lower unnecessary cruelty
- broader appeal among players who want rigor without emotional hostility

### Typical risks
- harder to execute cleanly
- can become muddy if both goals are pursued without prioritization
- may still feel demanding to softer audiences and soft to harder audiences if messaging is unclear

## Low systematizing / low empathizing

### Typical feel
- underdefined
- low-intent
- flat
- neither strategically compelling nor emotionally inviting

### Typical strengths
- can occasionally support extremely lightweight or novelty-driven experiences
- low commitment experiences may survive briefly here if simplicity is the real point

### Typical risks
- weak identity
- weak retention
- weak advocacy
- hard to explain why the experience matters

## Important reminder

These quadrants describe likely experience shape, not moral status.
A cold, system-heavy game may be excellent for its intended audience.
A warm, low-friction design may be exactly right for its goals.
The key question is whether the position is intentional, coherent, and matched to the target player.

---
name: game-design-novelty-spectrum-audit
description: Evaluate a game design, feature proposal, system concept, pitch, or prototype on the novelty spectrum between too familiar and too novel. Use when assessing whether a concept has enough differentiation, whether it violates player expectations too strongly, how it balances familiarity and innovation, or whether its innovation pattern is best understood as incremental innovation, recombination, simplification, or a more radical break from established mental models.
---

# Game Design Novelty Spectrum Audit

Evaluate whether a design is innovating in the right way, at the right intensity, for the right audience.

Use this skill to assess how a proposal sits on the spectrum between overly familiar and overly novel. The goal is not to praise originality for its own sake. The goal is to judge whether the design balances novelty against player expectations strongly enough to feel fresh, but not so aggressively that it creates avoidable cognitive dissonance or adoption risk.

Read `references/mental-model-layers.md` when identifying which player expectations matter most.
Read `references/innovation-patterns.md` when classifying what kind of novelty the design is attempting.
Read `references/verdict-scale.md` when selecting a final novelty-spectrum judgment.

## What to produce

Produce:
1. **Concept read** - what the design is trying to be
2. **Familiarity anchors** - what players will immediately recognize
3. **Novel elements** - what is genuinely different
4. **Innovation pattern** - what kind of innovation is happening
5. **Novelty spectrum verdict** - where the design sits between too familiar and too novel
6. **Expectation clashes** - where player mental models may resist the design
7. **Adjustment recommendation** - what to increase, reduce, simplify, or communicate differently

## Process

### 1. Read the concept through the lens of player expectations
Clarify:
- what the proposal is trying to offer players
- what audience it seems to target
- what genre, fantasy, or product context frames player expectations
- whether the pitch is leaning on familiarity, novelty, or both

### 2. Identify the familiarity anchors
Look for the parts of the concept that already fit player mental models.
These may include:
- recognizable fantasy or setting
- familiar control patterns
- established genre loops
- common progression structures
- known PvP, PvE, crafting, deckbuilding, roguelite, or battle-pass conventions
- franchise or brand expectations

### 3. Identify the novelty sources
Ask what is actually new here.
Distinguish between:
- cosmetic novelty
- thematic novelty
- interaction novelty
- systemic novelty
- social/meta novelty
- packaging or framing novelty

Do not mistake polish, setting swap, or tone shift for deep innovation unless it really changes player experience.

### 4. Classify the innovation pattern
Use one or more of these patterns:
- **Incremental innovation** - improving an existing design lineage
- **Recombination** - combining established elements from different sources
- **Simplification** - removing complexity to create a more accessible or elegant version
- **Radical break** - departing sharply from established expectations

Prefer the dominant pattern rather than force every category at once.

### 5. Judge the novelty balance
Decide whether the design is:
- too derivative to stand out
- familiar but differentiated enough
- balanced well between old and new
- exciting but risky
- likely too novel for the target audience or context

### 6. Surface expectation collisions
Identify where mental models may reject the concept.
Common clashes include:
- genre expectations violated without support
- controls or interactions that feel wrong before they feel interesting
- fantasy promise undermined by unfamiliar systems
- too many unfamiliar layers stacked at once
- innovations that demand learning before the player cares enough to learn

### 7. Recommend adjustment
Suggest the strongest next move, such as:
- add one stronger novelty hook
- reduce novelty load in one layer
- anchor the idea harder in familiar structures
- simplify the innovation
- communicate the novelty better in onboarding or marketing
- prototype the riskiest novelty first

## Response structure

### Concept Read
- ...

### Familiarity Anchors
- ...

### Novel Elements
- ...

### Innovation Pattern
- ...

### Novelty Spectrum Verdict
- ...

### Where Player Expectations May Clash
- ...

### Recommended Adjustment
- ...

## Fast mode
- What will players instantly recognize?
- What is actually new here?
- Is the novelty mostly incremental, recombinational, simplifying, or radical?
- Is the design too safe, well balanced, or too dissonant?
- What one adjustment would improve its novelty balance most?

## Style rules
- Do not worship novelty.
- Do not assume familiarity is automatically safe.
- Distinguish clearly between deep innovation and surface differentiation.
- Tie judgments to player expectations, not abstract design taste.
- If the concept is strong but risky, say where the risk sits.
- If the concept is too derivative, say why players may not care enough.

## Working principle

Good innovation in games is rarely pure invention.
It usually succeeds by balancing what players already understand with what feels meaningfully fresh.
FILE:references/innovation-patterns.md
# Innovation Patterns

Use these patterns to classify what kind of novelty the design is actually attempting.

## 1. Incremental innovation
The design evolves an existing pattern rather than replacing it.

Typical signs:
- keeps the core genre structure
- improves readability, pacing, controls, or progression
- adds one meaningful twist to an established formula
- feels familiar quickly, but better in one or two clear ways

Use this label when the concept is mostly part of an existing lineage.

Strength:
- easier adoption
- lower cognitive load
- lower market risk

Risk:
- may not stand out enough
- can feel like a polished copy without a strong hook

## 2. Recombination
The design combines established ideas from different places into a new arrangement.

Typical signs:
- genre mashups
- imported mechanics from another subgenre
- familiar loops merged into a new fantasy or pacing model
- social, economy, or progression systems transplanted across categories

Use this label when the novelty comes more from arrangement than invention.

Strength:
- often produces strong freshness with manageable risk
- players can understand each piece even if the combination is new

Risk:
- combinations can feel stitched together rather than coherent
- one borrowed system can overpower the rest

## 3. Simplification
The design removes layers, complexity, or friction from an existing pattern to create a more accessible or elegant form.

Typical signs:
- fewer mechanics than the parent genre
- shorter sessions
- clearer roles or choices
- reduction of edge-case complexity
- sharper readability and broader audience reach

Use this label when the “newness” comes from subtractive clarity rather than additional systems.

Strength:
- can open a genre to a much larger audience
- can create cleaner identity and stronger accessibility

Risk:
- may lose depth or expert appeal
- may appear shallow if the simplification cuts too much

## 4. Radical break
The design breaks strongly from established expectations in form, interaction, pacing, or structure.

Typical signs:
- unfamiliar controls or interaction logic
- severe genre inversion
- intentionally strange or experimental player behavior expectations
- requires new mental models rather than extending old ones

Use this label when the design is not mainly evolving or recombining known models but asking players to meet it on new terms.

Strength:
- high differentiation
- strong artistic or experiential uniqueness

Risk:
- high adoption difficulty
- high onboarding burden
- easier rejection if the payoff is not immediately compelling

## Distinguish deep novelty from surface novelty
Not all “newness” is equal.

### Surface novelty
- new art style
- unusual theme wrap
- cosmetic framing
- different setting on the same system

### Deep novelty
- changed interaction grammar
- changed decision structure
- changed pacing logic
- changed social or progression dynamics

A concept may look fresh while functioning almost entirely as a known game. That is not automatically bad, but it should not be misclassified as deep innovation.

## Practical recommendation

When auditing a concept:
- choose the dominant innovation pattern
- name any secondary pattern if useful
- explain what kind of risk that pattern creates
- do not reward radicality by default

The strongest commercial designs are often not the most radical ones.
They are often the ones that balance recognizability with meaningful freshness.
FILE:references/mental-model-layers.md
# Mental Model Layers

Use these layers to identify which expectations the design is leaning on and which ones it may be violating.

## 1. Life and nature expectations
These are broad expectations people carry from the physical and social world.

Examples:
- gravity should pull downward
- cars should accelerate, turn, and stop in somewhat readable ways
- islands, forests, houses, and weapons should broadly behave as people expect
- creatures should read as animals, monsters, machines, or people according to recognizable cues

Use this layer when the design depends on intuitive understanding from real life or common physical logic.

Ask:
- what will players assume is true before the game teaches anything?
- is the design breaking these assumptions in a helpful way or just creating friction?

## 2. Pop culture and fiction expectations
Players also arrive with schemas shaped by stories, films, comics, mythology, and genre fiction.

Examples:
- a superhero fantasy carries expectations of powers, spectacle, and moral framing
- a western implies duels, dust, frontier imagery, and outlaw archetypes
- medieval fantasy suggests swords, classes, monsters, magic, and quests

Use this layer when the design borrows heavily from recognizable fiction patterns.

Ask:
- what fantasy promise is the theme making?
- does the system design support or undermine that promise?

## 3. Video game medium expectations
Players expect some things simply because this is a video game.

Examples:
- interactivity
- responsive feedback
- readable goals
- enough audiovisual clarity to understand state and consequence
- a basic relationship between input and outcome

Use this layer when the proposal risks violating broad game literacy.

Ask:
- is the concept making the player relearn things that most games already teach implicitly?
- is that relearning interesting enough to justify itself?

## 4. Genre expectations
Players bring specific expectations from the genre or neighboring genres.

Examples:
- FPS players expect certain controls, weapon logic, and combat readability
- deckbuilder players expect card synergies, run logic, and decision pacing
- city-builder players expect growth, planning, and economy legibility
- hybrid-casual players expect approachable controls plus a longer-term meta layer

Use this layer heavily in concept evaluation.

Ask:
- what genre promises does the concept trigger?
- what genre rules is it following, mutating, simplifying, or rejecting?

## 5. Product-specific expectations
Players may also approach with expectations about this exact game, brand, or franchise.

Examples:
- sequel expectations
- live-ops brand expectations
- ad or trailer promises
- app-store icon and screenshot implications
- prior community discourse

Use this layer when a concept is attached to an existing product or specific market positioning.

Ask:
- what does the player think this game is before playing it?
- will the actual experience resolve or violate that expectation?

## Practical use

When evaluating novelty:
- identify which layers are carrying the design safely
- identify which layers are being stretched or broken
- judge whether the breaks feel fresh, confusing, or commercially risky

The more layers a concept violates at once, the more likely it is to feel alien or hard to adopt unless one of those violations becomes the compelling point of the whole game.

FILE:references/verdict-scale.md
# Novelty Spectrum Verdict Scale

Use this scale when making the final judgment.

## 1. Too familiar
The concept is too derivative, too expected, or too weakly differentiated.

Use when:
- the player can already map it almost completely onto an existing game
- novelty is mostly superficial
- there is too little reason to choose it over better-known alternatives

Likely recommendation:
- increase differentiation
- add a stronger twist
- sharpen the fantasy or structural hook

## 2. Familiar with light differentiation
The concept is recognizable and low-risk, with some freshness, but may still struggle to feel compelling.

Use when:
- the design has one or two small hooks
- the player will understand it quickly
- the risk is low, but so is excitement

Likely recommendation:
- strengthen one novelty axis without destabilizing accessibility

## 3. Healthy novelty balance
The concept feels grounded enough to understand quickly and fresh enough to feel worth attention.

Use when:
- familiarity anchors are clear
- novelty is concentrated in the right places
- the design feels adoptable and differentiated

Likely recommendation:
- preserve the balance
- prototype key novelty points to validate real player response

## 4. Bold but risky
The concept has strong freshness, but there is real danger in adoption, onboarding, communication, or audience fit.

Use when:
- the novelty is interesting and potentially valuable
- one or more mental model layers are being stretched hard
- misunderstanding or rejection risk is material

Likely recommendation:
- reduce novelty load in one area
- improve onboarding or marketing framing
- prototype the risky novelty first

## 5. Likely too novel for target expectations
The concept asks players to cross too many unfamiliar gaps at once or breaks expectations without enough support.

Use when:
- several mental-model layers are violated simultaneously
- the design creates disorientation before curiosity
- the audience is unlikely to meet it where it stands

Likely recommendation:
- add stronger anchors
- simplify the innovation
- narrow the audience intentionally
- rethink whether the novelty belongs at the core or at the edge

## Important note

This scale is not a score of artistic merit.
A concept can be highly original and still be mispositioned for the intended audience or commercial goal.
A concept can be quite familiar and still be strategically strong.

Judge novelty relative to:
- target audience
- product context
- onboarding burden
- market positioning
- design ambition

---
name: game-design-one-thing-to-remove
description: Identify the single highest-leverage thing to remove from a game design, feature, system, UX flow, pitch, roadmap item, or prototype in order to improve it significantly. Use when a design feels bloated, muddy, overengineered, overly tutorialized, friction-heavy, or diluted by low-value mechanics, and you want a subtractive critique with rationale, tradeoffs, and a cleaner alternative.
---

# Game Design One Thing To Remove

Improve the design by cutting one thing, not by adding three more.

Use this skill when a design would likely become better through subtraction. The goal is not to nitpick random dislikes. The goal is to identify the one removal with the highest leverage: the thing whose absence would most improve clarity, pacing, focus, emotional impact, usability, production efficiency, or strategic coherence.

Read `references/removal-lenses.md` when deciding what kind of thing is most worth cutting.
Read `references/evaluation-patterns.md` when you need the exact output pattern.

## What to produce

Produce:
1. **Design read** - what the design is trying to do
2. **Removal candidate** - the one thing to remove
3. **Why this removal has highest leverage** - why this cut matters more than others
4. **What improves if removed** - concrete downstream effects
5. **Tradeoff** - what value is lost too
6. **Value-preserving alternative** - how to keep the good part without the bad part, if needed
7. **Verdict** - remove now, prototype without it, or cut later if evidence confirms

## Process

### 1. Understand what the design is trying to achieve
Clarify:
- the intended player experience
- the core loop or promise
- which parts feel central versus decorative
- what business, retention, content, or production realities matter

### 2. Look for subtractive opportunities
Check whether the design contains:
- redundant mechanics
- duplicate progression layers
- false choices
- low-value friction
- weak reward currencies
- tutorial clutter
- content burdens that add little value
- fantasy dilution
- complexity that does not create meaningful depth

### 3. Identify the highest-leverage removal
Pick one thing only.
Do not list five cuts unless the user explicitly asks.
Choose the removal whose absence would improve the design most significantly.

Good candidates include:
- one mechanic
- one progression layer
- one UI step
- one rule or constraint
- one reward type
- one content dependency
- one feature that muddies the fantasy

### 4. Explain the mechanism of improvement
Do not say only that the design becomes “cleaner.”
Explain exactly what improves, such as:
- comprehension
- pacing
- motivation
- readability
- strategic clarity
- production sustainability
- onboarding burden
- player trust
- emotional focus

### 5. Acknowledge the loss honestly
A good cut may still remove something useful.
State what is lost and whether that loss matters.
If appropriate, suggest a lighter substitute that preserves the upside without keeping the full problematic element.

### 6. Make a practical recommendation
End with a decision such as:
- remove now
- prototype without it
- keep for now, but cut if testing confirms the issue

## Response structure

### Design Read
- ...

### One Thing I Would Remove
- ...

### Why This Is the Highest-Leverage Cut
- ...

### What Improves If Removed
- ...

### What You Lose
- ...

### How To Preserve the Good Part Without the Bad Part
- ...

### Verdict
- ...

## Fast mode
- What is the design trying to do?
- What single element is hurting it most?
- Why is that element more worth cutting than anything else?
- What gets better if it disappears?
- What should replace it, if anything?

## Style rules
- Be decisive.
- Pick one thing.
- Prefer mechanism over taste.
- Do not recommend removal just because something is complex; complexity is acceptable if it creates real value.
- Distinguish between elegant subtraction and destructive oversimplification.
- If nothing should be removed, say that clearly and explain why.

## Working principle

Many designs get worse because every problem is answered with addition.
Sometimes the best improvement is subtraction with intent.
FILE:references/evaluation-patterns.md
# Evaluation Patterns

Use this pattern to keep the subtractive critique sharp and practical.

## Core output pattern

### Design Read
Summarize:
- what the design seems to want to achieve
- what the core player promise is
- where the design currently feels spread too thin

### One Thing I Would Remove
Name one thing only.
Examples:
- remove crafting
- remove stamina decay
- remove the second currency
- remove forced daily tasks
- remove dialogue choices in onboarding
- remove rarity tiers on equipment

### Why This Is the Highest-Leverage Cut
Explain why this cut matters more than other possible cuts.
Tie it to mechanisms such as:
- duplicated function
- friction without payoff
- unclear value
- fantasy dilution
- content burden
- pacing drag

### What Improves If Removed
Be concrete.
Good categories:
- onboarding clarity
- decision readability
- pacing
- emotional focus
- production scope
- tuning burden
- content sustainability
- player trust

### What You Lose
State the honest downside.
Examples:
- less customization
- fewer long-term goals
- less monetization surface
- lower perceived complexity

### How To Preserve the Good Part Without the Bad Part
If appropriate, propose a lighter replacement.
Examples:
- fold crafting into upgrade drops
- replace second currency with milestone unlocks
- turn a maintenance loop into passive background progression
- keep the fantasy through cosmetics instead of a whole subsystem

### Verdict
Choose one:
- remove now
- prototype without it
- keep temporarily, but test a stripped-down version
- do not remove; the apparent clutter is actually carrying important value

## What a strong answer sounds like

Strong:
- remove the second upgrade currency because it duplicates the same advancement function already carried by account level, adds explanation burden, and makes rewards harder to parse. The game loses some perceived granularity, but that can be preserved by making milestone unlocks more expressive instead of tracking another spendable resource.

Weak:
- remove the currency because it feels unnecessary.

## Important rule

Do not confuse “I personally dislike this” with “this is the highest-leverage removal.”
The skill should make a design judgment, not just express taste.

FILE:references/removal-lenses.md
# Removal Lenses

Use these lenses to decide what kind of cut is most valuable.

## 1. Redundancy
Remove when two systems serve nearly the same purpose but one is weaker, noisier, or more expensive.

Look for:
- overlapping progression layers
- two currencies that both mean advancement
- multiple upgrade surfaces that create the same feeling
- duplicated reward logic

Ask:
- what does this element do that another element does not already do better?

## 2. Friction without payoff
Remove when effort, clicks, waiting, or chores do not create anticipation, mastery, or meaningful commitment.

Look for:
- extra confirmation steps
- repetitive maintenance loops
- forced backtracking
- low-information management tasks
- tutorial chores that feel like paperwork

Ask:
- what player value is created by this friction?
- if the answer is thin, cut it

## 3. Fake depth
Remove when something looks strategic but mainly adds opacity, spreadsheet work, or cargo-cult complexity.

Look for:
- choices with one obviously correct answer
- stats that are hard to parse and weakly felt
- systems that ask for understanding before they earn motivation
- layers that create optimization pressure without interesting tradeoffs

Ask:
- does this create real decision-making or only the appearance of sophistication?

## 4. Fantasy dilution
Remove when an element weakens the core fantasy or emotional identity.

Look for:
- tonal mismatch
- systems that pull attention away from the main fantasy
- side loops that feel imported from another game
- reward surfaces that turn fantasy into admin

Ask:
- does this make the game more itself, or less itself?

## 5. Content burden
Remove when the idea requires too much content, tuning, balancing, writing, or live support relative to the value it adds.

Look for:
- highly variant content with weak player impact
- feature branches that each need bespoke support
- systems that scale poorly with real production realities

Ask:
- is this worth the content and maintenance tax?

## 6. Onboarding overload
Remove when a mechanic, rule, or layer makes early understanding significantly harder.

Look for:
- too many explained systems in the first session
- mechanics that matter late but confuse early
- tutorial steps that protect a feature the player does not yet care about

Ask:
- would the first-time experience improve if this simply did not exist yet?

## 7. Identity drift
Remove when the feature pushes the game toward a different genre promise or audience expectation than the rest of the design supports.

Look for:
- one live-ops system that makes a cozy game feel extractive
- one PvP layer inside a game not built for rivalry
- one crafting or economy layer that hijacks a game about momentum

Ask:
- what kind of game does this element want us to become?

## 8. Production-risk camouflage
Remove when a feature sounds small but actually drags hidden dependencies behind it.

Look for:
- cross-discipline coordination traps
- backend or tooling needs hidden inside a “simple” feature
- balance/support demands that arrive after launch

Ask:
- is this secretly a much bigger commitment than it appears?

## Decision rule

Choose the cut that improves the design most, not the cut that is easiest to argue.
A high-leverage removal usually improves several things at once:
- clarity
- pacing
- focus
- scope
- usability
- emotional identity

---
name: game-design-brainstorm-methods
description: Apply established brainstorming and ideation methodologies to game design problems, features, systems, UX flows, live-ops ideas, content concepts, and stuck team discussions. Use when the user wants a specific brainstorming method rather than generic ideation, or when you should choose and run a method such as SCAMPER, How Might We, Crazy 8s, Six Thinking Hats, Brainwriting 6-3-5, Worst Possible Idea, forced connections, Lotus Blossom, or a morphological matrix.
---

# Game Design Brainstorm Methods

Use named brainstorming methods, not generic idea spray.

This skill helps choose and run a well-known ideation methodology that fits the design problem. The goal is not to mention frameworks for show. The goal is to use the right method to unlock better game design options, surface hidden assumptions, and produce a practical shortlist worth exploring next.

Read `references/method-selection.md` when choosing a method.
Read `references/method-patterns.md` when you need the exact structure for a method output.

## What to produce

Produce:
1. **Problem frame** - what the team is trying to solve
2. **Method choice** - which brainstorming method is best and why
3. **Method run** - the actual brainstorm output in that method's format
4. **Idea clusters** - themes, repeated patterns, or promising directions
5. **Shortlist** - strongest candidates to pursue next
6. **Next move** - recommendation, prototype, or follow-up question

## Process

### 1. Frame the ideation problem
Clarify:
- what design problem, feature, or system is under discussion
- whether the need is divergence, reframing, critique, or narrowing
- what constraints matter most
- whether the user wants novelty, structure, speed, or alignment

### 2. Choose the right method
Pick one primary method. Use a second method only when it adds clear value.

Typical fits:
- **SCAMPER** - improve or mutate an existing feature
- **How Might We** - turn fuzzy problems into opportunity prompts
- **Crazy 8s** - force fast variation and volume
- **Six Thinking Hats** - structure discussion across multiple lenses
- **Brainwriting 6-3-5** - generate many ideas without one dominant voice
- **Worst Possible Idea** - break fixation by inverting bad ideas into useful principles
- **Forced connections** - inject novelty through random or adjacent stimuli
- **Lotus Blossom** - expand one central idea into adjacent branches
- **Morphological matrix** - combine dimensions systematically into new concepts

### 3. Run the method properly
Do not collapse the method into generic bullets.
Preserve the logic of the method.
For example:
- SCAMPER should actually walk through substitute, combine, adapt, modify, put to other use, eliminate, reverse/rearrange
- Six Thinking Hats should clearly separate hat modes
- Brainwriting should show rounds, seeds, or parallel idea contributions
- Morphological matrix should define dimensions before combining them

### 4. Extract the design value
After the method run, identify:
- repeated themes
- strongest directions
- strange but interesting outliers
- weak ideas worth discarding
- what should be prototyped, discussed, or parked

### 5. Convert brainstorm into action
End with one of these:
- best 3 candidates
- one recommended direction and why
- next prototype question
- follow-up method if the first method created useful ambiguity but not enough convergence

## Response structure

### Problem Frame
- ...

### Chosen Method
- Method: ...
- Why this method fits: ...

### Method Run
- ...

### Idea Clusters
- ...

### Strongest Candidates
1. ...
2. ...
3. ...

### Recommended Next Move
- ...

## Fast mode
- What kind of ideation problem is this?
- Which method fits best?
- Run that method clearly.
- Pull out the 3 strongest design directions.
- Recommend what to do next.

## Working principle

Different brainstorming problems need different tools.
Do not default to freeform ideation when a specific method would produce better thinking.
FILE:references/method-patterns.md
# Method Output Patterns

Use these patterns when running the chosen method.

## SCAMPER

### Prompt structure
- Substitute
- Combine
- Adapt
- Modify / Magnify / Minify
- Put to other use
- Eliminate
- Reverse / Rearrange

### Output pattern
- **Substitute**: ...
- **Combine**: ...
- **Adapt**: ...
- **Modify**: ...
- **Put to other use**: ...
- **Eliminate**: ...
- **Reverse / Rearrange**: ...

Then extract:
- strongest 3 mutations
- what each changes for the player
- what seems easiest to prototype

## How Might We

### Output pattern
- **Problem statement**: ...
- **HMW prompts**:
  1. ...
  2. ...
  3. ...
- **Best prompt to ideate from**: ...
- **Why**: ...

If needed, follow with a short ideation burst from the strongest prompt.

## Crazy 8s

### Output pattern
Generate 8 fast variants.
Keep them short.

1. ...
2. ...
3. ...
4. ...
5. ...
6. ...
7. ...
8. ...

Then identify:
- safest useful idea
- boldest interesting idea
- best next prototype candidate

## Six Thinking Hats

### Output pattern
- **White hat (facts / knowns)**: ...
- **Red hat (feelings / instincts)**: ...
- **Black hat (risks / failure modes)**: ...
- **Yellow hat (upsides / benefits)**: ...
- **Green hat (new ideas / alternatives)**: ...
- **Blue hat (process / next step)**: ...

Then summarize:
- what perspective changed the discussion most
- what action follows from the full view

## Brainwriting 6-3-5

Adapt the method for a single-agent environment by simulating rounds.

### Output pattern
- **Round 1 seeds**: 3 starter ideas
- **Round 2 expansions**: 3 mutations or extensions of those ideas
- **Round 3 combinations**: 3 merged or remixed ideas
- **Round 4 strongest outcomes**: shortlist

State clearly that this is a simulated brainwriting pass rather than a literal multi-person workshop.

## Worst Possible Idea

### Output pattern
- **Worst ideas**:
  1. ...
  2. ...
  3. ...
  4. ...
  5. ...
- **What these bad ideas reveal**: ...
- **Useful inversions**: ...
- **Real design candidates extracted**: ...

## Forced Connections

### Output pattern
- **Base design problem**: ...
- **Random or adjacent stimulus**: ...
- **Connections generated**:
  1. ...
  2. ...
  3. ...
  4. ...
- **Which connection is actually promising**: ...

## Lotus Blossom

### Output pattern
- **Central idea**: ...
- **Eight surrounding branches**:
  1. ...
  2. ...
  3. ...
  4. ...
  5. ...
  6. ...
  7. ...
  8. ...
- **Most promising branch to expand next**: ...

## Morphological Matrix

### Output pattern
- **Dimension 1**: ...
- **Dimension 2**: ...
- **Dimension 3**: ...
- **Dimension 4**: ...
- **Interesting combinations**:
  1. ...
  2. ...
  3. ...
  4. ...
- **Most promising combinations**: ...

## Closing rule

Always end with one of these:
- shortlist
- recommendation
- next prototype question
- suggested follow-up method

Do not leave the brainstorm as raw output without synthesis.

FILE:references/method-selection.md
# Method Selection Guide

Choose the narrowest method that matches the real ideation need.

## Quick chooser

### Use SCAMPER when
- an existing feature or system already exists
- the team needs variations rather than blank-page invention
- the problem is how to improve, mutate, or extend something already known

Avoid when:
- the team does not yet understand the core problem
- the design space is still too vague to mutate usefully

### Use How Might We when
- the problem is fuzzy, overloaded, or too negative
- the team is stuck in complaints or constraints
- you need opportunity prompts before ideation

Avoid when:
- the team already has strong idea prompts and now needs volume or evaluation

### Use Crazy 8s when
- speed matters
- the team needs many fast variations
- a concept is becoming too precious too early
- a UI, feature pitch, or mechanic needs breadth quickly

Avoid when:
- the topic needs careful decomposition first
- the user wants deep evaluation rather than rapid ideation

### Use Six Thinking Hats when
- discussion is messy or circular
- the team keeps mixing facts, feelings, risks, and ideas chaotically
- alignment and structured perspective-taking matter more than raw novelty

Avoid when:
- the main need is simply more options fast

### Use Brainwriting 6-3-5 when
- you want many ideas without one loud perspective dominating
- parallel idea generation would help
- the user wants a workshop-like format with rounds

Avoid when:
- the user wants a single-agent fast answer rather than simulated rounds

### Use Worst Possible Idea when
- the team is blocked, polite, or overattached to safe thinking
- assumptions need to be exposed through inversion
- the current discussion feels stiff or obvious

Avoid when:
- the user needs tight, formal output and low playfulness

### Use Forced Connections when
- the problem feels stale
- novelty matters more than immediate plausibility
- the team needs provocative combinations or fresh angles

Avoid when:
- the user mainly wants structured convergence

### Use Lotus Blossom when
- one core idea is promising but under-expanded
- you want adjacent branches around a central theme
- the team needs breadth around one focal concept

Avoid when:
- the design problem has not been centered yet

### Use Morphological Matrix when
- the design can be broken into dimensions or components
- systematic combination is likely to reveal strong options
- the feature is modular enough to recombine cleanly

Avoid when:
- the user needs emotional reframing more than combinatorial search

## Common mappings

### Existing feature needs fresh versions
Use:
- SCAMPER
- Crazy 8s
- Morphological matrix

### Vague problem needs reframing first
Use:
- How Might We
- Worst Possible Idea

### Team conversation is chaotic
Use:
- Six Thinking Hats
- How Might We

### Need many options quickly
Use:
- Crazy 8s
- Brainwriting 6-3-5

### Need weird but useful novelty
Use:
- Forced connections
- Worst Possible Idea
- SCAMPER

### One promising idea needs expansion
Use:
- Lotus Blossom
- Morphological matrix

## Recommendation rule

Prefer one method done well over many methods used shallowly.
Use a second method only when there is a clear handoff such as:
- How Might We -> Crazy 8s
- Worst Possible Idea -> SCAMPER
- Six Thinking Hats -> shortlist or prototype recommendation

---
name: game-design-prototyping-companion
description: Track game design prototype ideas, branching outcomes, dead ends, baselines, and next experiments, and optionally generate a simple SVG visualization of prototype evolution. Use when a prototype leads to several possible follow-up paths, when the team needs to backtrack without losing learned branches, when exploring unknowns through multiple iterations, or when you want both a written prototype log and a branch map of how the concept evolved over time.
---

# Game Design Prototyping Companion

Track prototype evolution, not just prototype results.

Use this skill when prototyping produces branching decisions, dead ends, alternative paths, and backtracking. The aim is to preserve learning structure: what was tested, what was learned, what branch it created, which path was followed, and which paths remain available to revisit.

This skill can also generate a simple SVG branch map from a lightweight text or JSON structure.

## What to produce

Generate one or more of these outputs:
1. **Prototype log** - what was tested and why
2. **Branch record** - what paths emerged from the result
3. **Decision state** - which branch is current, parked, dead, baseline, or promising
4. **Backtrack notes** - what can be revisited later and under what condition
5. **SVG branch map** - a visual map of prototype evolution

## Core principle

A prototype is not just a yes/no answer.
It often creates a tree:
- one branch becomes the current path
- another becomes a dead end
- another becomes a parked idea worth revisiting later
- another reveals a stronger question than the original one

The skill should preserve that tree.

## Workflow

### 1. Define the prototype node
For each prototype node, record:
- **Node ID**
- **Prototype name**
- **Question being tested**
- **What was built or simulated**
- **What was learned**
- **Result state**

Use result states such as:
- **baseline**
- **promising**
- **branch trigger**
- **dead end**
- **parked**
- **production candidate**

### 2. Record branch options
When a prototype produces several next moves, capture each branch explicitly.

For each branch, record:
- **Branch ID**
- **Parent node**
- **New idea or variation**
- **Reason it exists**
- **Current status**

### 3. Mark the chosen path without deleting the others
Do not treat the selected branch as the only meaningful output.
Preserve:
- abandoned paths
- deferred paths
- weird side paths
- stronger substitute ideas revealed by the test

### 4. Add backtrack logic
If a branch is not chosen now, record:
- what would justify revisiting it
- what blocker currently prevents it
- what later discovery might make it relevant again

### 5. Generate a visual map when useful
Use `scripts/branch_map_svg.py` to render a simple SVG from a branch-map JSON file.

Read:
- `references/branch-map-format.md` for the input structure
- `references/example-branch-map.json` for an example

## Response structure

Use this structure unless the user asks for something else:

### Prototype Node
- Node ID: ...
- Question: ...
- Built / simulated: ...
- Learned: ...
- State: ...

### Branches Created
1. ...
2. ...
3. ...

### Current Chosen Path
- ...

### Parked / Revisit Later
- ...

### Suggested Next Prototype
- ...

## Visualization workflow

When the user wants a visual branch map:
1. write the branch data to JSON using the format in `references/branch-map-format.md`
2. run `scripts/branch_map_svg.py <input.json> <output.svg>`
3. return the SVG path and summarize what the map shows

## Style rules
- Preserve branching history.
- Prefer explicit node IDs over vague prose.
- Distinguish clearly between what was learned and what was merely assumed.
- Do not erase dead ends; label them.
- Do not confuse the current path with the best possible path forever.

## References

- `references/branch-map-format.md` for the JSON structure
- `references/example-branch-map.json` for a starter example
- `references/state-labels.md` for recommended branch/node labels

## Working principle

Prototype trees are design memory.
If you only remember the path you chose, you lose the intelligence of the paths you rejected.

FILE:references/branch-map-format.md
# Branch Map Format

Use a simple JSON object with `nodes` and `edges`.

## Structure

```json
{
  "title": "Prototype branch map",
  "nodes": [
    {
      "id": "P0",
      "label": "Grouped request board",
      "state": "baseline",
      "note": "Initial prototype to test readability"
    },
    {
      "id": "P1",
      "label": "Conflict-based board",
      "state": "promising",
      "note": "Players noticed tradeoffs faster"
    }
  ],
  "edges": [
    {
      "from": "P0",
      "to": "P1",
      "label": "What if requests compete?"
    }
  ]
}
```

## Node fields
- `id`: short unique ID
- `label`: visible node title
- `state`: baseline | promising | branch-trigger | dead-end | parked | production-candidate
- `note`: optional short explanation

## Edge fields
- `from`: source node ID
- `to`: target node ID
- `label`: short branch reason or question

## Layout note
The bundled script uses a simple top-to-bottom tree-like layout.
It is not a full graph engine. Keep maps small to medium for readability.

FILE:references/example-branch-map.json
{
  "title": "Request Board Prototype Evolution",
  "nodes": [
    {
      "id": "P0",
      "label": "Basic request board",
      "state": "baseline",
      "note": "Clear but emotionally flat"
    },
    {
      "id": "P1",
      "label": "Grouped by urgency",
      "state": "parked",
      "note": "Improved scannability but still low tension"
    },
    {
      "id": "P2",
      "label": "Conflicting requests",
      "state": "promising",
      "note": "Created meaningful tradeoffs"
    },
    {
      "id": "P3",
      "label": "Fully diegetic world requests",
      "state": "branch-trigger",
      "note": "Revealed a stronger direction outside the board itself"
    },
    {
      "id": "P4",
      "label": "Timer-heavy scarcity version",
      "state": "dead-end",
      "note": "Created pressure without meaningful choice"
    }
  ],
  "edges": [
    {
      "from": "P0",
      "to": "P1",
      "label": "Increase readability"
    },
    {
      "from": "P0",
      "to": "P2",
      "label": "Add tradeoffs"
    },
    {
      "from": "P0",
      "to": "P3",
      "label": "What if the board disappears?"
    },
    {
      "from": "P2",
      "to": "P4",
      "label": "Push urgency harder"
    }
  ]
}

FILE:references/state-labels.md
# State Labels

Recommended node and branch states:

- `baseline` - current stable point of reference
- `promising` - worth pursuing soon
- `branch-trigger` - reveals a new path or question
- `dead-end` - failed or not worth continuing
- `parked` - not chosen now, but worth remembering
- `production-candidate` - sufficiently understood to move toward implementation

## Usage guidance

### baseline
Use for the current comparison anchor.

### promising
Use for a path that deserves serious follow-up.

### branch-trigger
Use when a prototype mainly matters because it opened another direction.

### dead-end
Use when the path taught something useful but should not continue.

### parked
Use for good ideas that are deferred, blocked, or out of scope right now.

### production-candidate
Use when a path is understood well enough to stop exploratory prototyping and move into a more concrete implementation phase.

FILE:scripts/branch_map_svg.py
from __future__ import annotations
import json
import sys
from pathlib import Path
from collections import defaultdict, deque

STATE_COLORS = {
    'baseline': '#5B8DEF',
    'promising': '#2BAE66',
    'branch-trigger': '#F2A93B',
    'dead-end': '#D64545',
    'parked': '#8B7CF6',
    'production-candidate': '#1F8EFA',
}

BOX_W = 220
BOX_H = 64
X_GAP = 70
Y_GAP = 90
MARGIN = 40


def esc(text: str) -> str:
    return (text.replace('&', '&amp;')
                .replace('<', '&lt;')
                .replace('>', '&gt;'))


def wrap(text: str, width: int = 26):
    words = text.split()
    lines = []
    cur = []
    cur_len = 0
    for w in words:
        if cur_len + len(w) + (1 if cur else 0) <= width:
            cur.append(w)
            cur_len += len(w) + (1 if cur_len else 0)
        else:
            lines.append(' '.join(cur))
            cur = [w]
            cur_len = len(w)
    if cur:
        lines.append(' '.join(cur))
    return lines[:3]


def main(inp: str, out: str):
    data = json.loads(Path(inp).read_text(encoding='utf-8'))
    nodes = {n['id']: n for n in data.get('nodes', [])}
    edges = data.get('edges', [])
    children = defaultdict(list)
    indeg = defaultdict(int)
    for e in edges:
        children[e['from']].append(e)
        indeg[e['to']] += 1
        indeg[e['from']] += 0

    roots = [nid for nid in nodes if indeg[nid] == 0] or list(nodes.keys())[:1]

    level = {}
    q = deque((r, 0) for r in roots)
    seen = set()
    while q:
        nid, d = q.popleft()
        if nid in seen:
            continue
        seen.add(nid)
        level[nid] = d
        for e in children.get(nid, []):
            q.append((e['to'], d + 1))

    cols = defaultdict(list)
    for nid, d in level.items():
        cols[d].append(nid)
    for d in cols:
        cols[d].sort()

    positions = {}
    max_col = max(cols) if cols else 0
    max_rows = max((len(v) for v in cols.values()), default=1)
    width = MARGIN * 2 + (max_col + 1) * BOX_W + max_col * X_GAP
    height = MARGIN * 2 + max_rows * BOX_H + (max_rows - 1) * Y_GAP + 80

    for d in sorted(cols):
        for r, nid in enumerate(cols[d]):
            x = MARGIN + d * (BOX_W + X_GAP)
            y = MARGIN + r * (BOX_H + Y_GAP) + 40
            positions[nid] = (x, y)

    parts = []
    parts.append(f'<svg xmlns="http://www.w3.org/2000/svg" width="{width}" height="{height}" viewBox="0 0 {width} {height}">')
    parts.append('<style>text{font-family:Segoe UI,Arial,sans-serif}.title{font-size:20px;font-weight:700}.label{font-size:14px;font-weight:600}.note{font-size:11px;fill:#333}.edge{font-size:11px;fill:#555}</style>')
    title = esc(data.get('title', 'Prototype Branch Map'))
    parts.append(f'<text x="{MARGIN}" y="28" class="title">{title}</text>')

    for e in edges:
        if e['from'] not in positions or e['to'] not in positions:
            continue
        x1, y1 = positions[e['from']]
        x2, y2 = positions[e['to']]
        sx = x1 + BOX_W
        sy = y1 + BOX_H / 2
        tx = x2
        ty = y2 + BOX_H / 2
        mx = (sx + tx) / 2
        parts.append(f'<path d="M {sx} {sy} C {mx} {sy}, {mx} {ty}, {tx} {ty}" fill="none" stroke="#999" stroke-width="2"/>')
        label = esc(e.get('label', ''))
        if label:
            parts.append(f'<text x="{mx}" y="{(sy + ty) / 2 - 6}" class="edge" text-anchor="middle">{label}</text>')

    for nid, node in nodes.items():
        if nid not in positions:
            continue
        x, y = positions[nid]
        color = STATE_COLORS.get(node.get('state', ''), '#888')
        parts.append(f'<rect x="{x}" y="{y}" width="{BOX_W}" height="{BOX_H}" rx="10" ry="10" fill="#fff" stroke="{color}" stroke-width="3"/>')
        parts.append(f'<text x="{x + 10}" y="{y + 18}" class="note">{esc(nid)} • {esc(node.get("state", ""))}</text>')
        for i, line in enumerate(wrap(node.get('label', ''), 24)):
            parts.append(f'<text x="{x + 10}" y="{y + 38 + i * 16}" class="label">{esc(line)}</text>')

    parts.append('</svg>')
    Path(out).write_text('\n'.join(parts), encoding='utf-8')


if __name__ == '__main__':
    if len(sys.argv) != 3:
        print('Usage: python branch_map_svg.py <input.json> <output.svg>')
        sys.exit(1)
    main(sys.argv[1], sys.argv[2])

---
name: game-design-goal-density-and-immediacy-audit
description: Audit a game, feature, progression loop, return-player experience, metagame layer, or session structure for density of goals, immediacy of goals, safe stopping points, and return triggers. Use when evaluating whether players can quickly find something meaningful to do, whether the game offers enough short-term, mid-term, and long-term goals, whether session lengths are flexible enough for real player schedules, or why a game feels aimless, overwhelming, or unable to fit into fragmented playtime.
---

# Game Design Goal Density and Immediacy Audit

Audit a design by asking whether players can quickly find a meaningful goal, pursue it within the time they have, and leave the session feeling both satisfied and pulled to return.

Use this skill to evaluate how a game structures player time. Focus on the density of available goals, how immediate those goals feel, how they ladder across time horizons, whether players can end a session safely, and what return triggers bring them back.

## Core principle

A strong session structure does not depend on one perfect goal.
It gives the player enough meaningful goals of different sizes and time horizons that they can pick one that fits the time, energy, and attention they currently have.

## What to produce

Generate:
1. **Audit target** - what is being reviewed and what kind of session pattern it supports
2. **Goal density audit** - how many meaningful goals are available at once and how varied they are
3. **Goal immediacy audit** - how quickly the player can identify something worth doing now
4. **Time-horizon breakdown** - short-term, mid-term, and long-term goals
5. **Session closure audit** - whether the player can leave at a safe, satisfying moment
6. **Return-trigger audit** - what unfinished business pulls the player back
7. **Recommendations** - what to add, remove, clarify, pace, or restructure

## Process

### 1. Define the audit target
Clarify:
- what system, feature, or game is being audited
- what kind of session pattern it expects: short bursts, long sessions, mixed sessions
- whether the design is FTUE, return-player experience, core loop, metagame, or elder game
- what player context matters most

### 2. Audit goal immediacy
Ask:
- When the player opens the game, how quickly can they identify a meaningful thing to do?
- Does the game help the returning player select a new goal?
- Is the most important current opportunity visible enough?
- Does the game over-rely on the player remembering what they were doing last session?
- Is the player choosing a goal, or wandering through UI trying to figure out what matters?

Look for:
- visible session entry points
- clear next-step candidates
- strong current priorities
- low friction between logging in and acting
- support for self-directed goal choice

### 3. Audit goal density
Ask:
- How many meaningful goals are available at a given moment?
- Do goals vary in size, difficulty, and time requirement?
- Can different players find different goals that fit different amounts of available time?
- Is the game sparse and aimless, or overcrowded and noisy?
- Does the metagame provide enough context to make multiple goals feel meaningful?

Look for:
- multiple simultaneous goal candidates
- different effort bands
- different reward horizons
- overlap between core goals and meta goals
- enough choice without drowning the player

### 4. Break down goals by time horizon
Evaluate whether the design offers a healthy spread of goals across these horizons:

#### Short-term goals
Goals that can usually be started and often completed in one brief session.
Examples:
- one level
- one race
- one mission
- claim and spend loop
- craft one needed item
- collect one reward tier

Ask:
- Are there enough goals that fit tiny pockets of time?
- Can a player feel accomplished in a short session?
- Are short-term goals meaningful, or merely mechanical chores?

#### Mid-term goals
Goals that take several sessions or a moderate amount of focused play.
Examples:
- finish a chapter
- upgrade a subsystem
- unlock a feature tier
- complete an event milestone band
- build a new district or unit composition

Ask:
- Does the game provide medium-range projects worth caring about?
- Do these goals create continuity between sessions?
- Are they paced well, or do they feel either trivial or exhausting?

#### Long-term goals
Goals that define sustained engagement over days, weeks, or longer.
Examples:
- finish a season pass
- complete a major collection
- reach elder-game mastery
- build out a city fantasy
- reach endgame social or competitive status

Ask:
- What gives long-term meaning to repeated sessions?
- Are long-term goals visible enough to inspire commitment?
- Are they aspirational, or just distant grind walls?

Use this format:

| Horizon | Examples Present | Strength | Main Issue |
|---|---|---|---|
| Short-term | ... | ... | ... |
| Mid-term | ... | ... | ... |
| Long-term | ... | ... | ... |

### 5. Audit session flexibility
Ask:
- Can the game support different session lengths?
- Can a player with 2 minutes, 10 minutes, or 45 minutes still do something meaningful?
- Does the structure adapt to fragmented real-life schedules?
- Does the design force one ideal session length too rigidly?

Look for:
- flexible stopping points
- scalable goal selection
- both burst-friendly and longer-form activity options where appropriate

### 6. Audit session closure and safe stopping points
Ask:
- Can the player end the session at a satisfying moment?
- Does the game provide a sense of completion before exit?
- Does the player feel safe leaving, or feel like the game is still on fire without them?
- Are there explicit or implicit signs that nothing urgent remains?

Look for:
- clear stopping moments
- closure after achieving a goal
- no lingering obligation spikes
- reduced anxiety around leaving the game

### 7. Audit return triggers
Ask:
- What unfinished business motivates return?
- Does the player leave with a reason to come back?
- Are return triggers restrictive and imposed, or self-owned and player-shaped?
- Does the game model time away from play intelligently?

Look for:
- production loops
- chest timers
- growth cycles
- event cadence
- self-set goals
- appointment mechanics

Also ask:
- Does the return trigger create anticipation, or only obligation?
- Does it support agency, or mostly remove it?

### 8. Diagnose common failure patterns
Common patterns:
- **Goal drought** - too few meaningful goals, player feels aimless
- **Goal smog** - too many competing goals with no clear priority
- **No immediate hook** - player returns but does not see what to do now
- **Chore density** - many goals exist, but they feel trivial, repetitive, or low-meaning
- **Mid-term gap** - good micro-goals and big aspirations, but weak medium-range projects
- **Long-term fog** - sessions exist, but no larger arc gives them meaning
- **Bad fit for fragmented time** - game only works in one session length
- **Unsafe exit** - player feels punished or anxious for stopping
- **Obligation loop** - return triggers rely on pressure more than anticipation

### 9. Convert findings into design actions
For each major issue, specify:
- **Issue**
- **Why it hurts the experience**
- **Affected horizon** - short, mid, long, or session closure/return
- **Suggested change**
- **Expected effect**

## Response structure

### Audit Target
- ...

### Goal Immediacy
- Strengths: ...
- Weaknesses: ...

### Goal Density
- Strengths: ...
- Weaknesses: ...

### Time-Horizon Breakdown
- Short-term: ...
- Mid-term: ...
- Long-term: ...

### Session Closure
- ...

### Return Triggers
- ...

### Failure Patterns
- ...

### Recommendations
1. ...
2. ...
3. ...

## Fast mode
- When the player returns, do they instantly see something meaningful to do?
- Are there enough goals of different sizes to fit different session lengths?
- What are the short-term, mid-term, and long-term goals?
- Can the player stop safely and feel satisfied?
- What specifically pulls them back next time?

## References

Read these when useful:
- `references/goal-density-notes.md` for the source-derived framing around player time, session anatomy, density of goals, and return triggers
- `references/failure-patterns.md` for common goal-density and immediacy failure shapes

## Working principle

Designing sessions means modeling the player's time both with the game and away from it.
A strong game helps the player find a meaningful goal now, achieve enough to feel satisfied, and leave with a reason to come back.

FILE:references/failure-patterns.md
# Goal Density and Immediacy Failure Patterns

## Goal drought
Too few meaningful goals are visible, so the player feels aimless.

## Goal smog
Too many goals are presented without hierarchy, so nothing feels urgent or meaningful.

## No immediate hook
The player returns but cannot quickly identify what to do next.

## Chore density
The game has many goals, but they are low-meaning, repetitive, or merely maintenance tasks.

## Mid-term gap
Short tasks exist and distant aspirations exist, but the game lacks satisfying medium-range projects.

## Long-term fog
Sessions function mechanically, but there is no larger arc worth caring about.

## Unsafe exit
The player cannot leave comfortably because the system implies ongoing unattended damage or obligation.

## Obligation loop
Return triggers rely more on pressure and restriction than on anticipation and agency.

## Session mismatch
The game only works well at one session length, making it brittle in real player schedules.

## Audit question

For each failure pattern, ask:
- what kind of player time is being modeled poorly?
- which goal horizon is missing or overloaded?
- is the problem visibility, meaning, pacing, or closure?
- what one structural change would improve the session shape most?
FILE:references/goal-density-notes.md
# Goal Density and Immediacy Notes

Derived from the document "Modeling Player's Time".

## Core ideas

- Designing a retention-oriented game is largely about structuring player time.
- A player's total journey is made up of many individual sessions.
- Return-player experience is not mainly about reminding players what they were doing last time.
- It is mainly about helping them choose a new meaningful goal now.

## Meaningful goals

A meaningful goal should be:
- attainable within the session the player currently has time for
- consequential in the larger context of the game

## Density of goals

Strong session structures provide many goals at once.
These goals should vary in:
- difficulty
- time requirement
- payoff horizon

This allows the player to choose something that fits both their schedule and current energy.

## Session flexibility

Good games support more than one useful session length.
Players may have:
- under a minute
- a few minutes
- 10-15 minutes
- much longer evening sessions

The design should offer meaningful activities across these different time windows when appropriate for the platform and genre.

## Safe stopping points

Players need a moment where they feel free to leave.
This often means:
- enough has been accomplished
- nothing urgent still demands action
- the game is not left in a state of unattended disaster

## Return triggers

A session should end with a reason to return.
This can be:
- explicit and system-imposed, like energy regeneration
- implicit and player-owned, like production finishing soon or a self-set objective waiting to be resumed

The source text favors systems that preserve player agency over purely restrictive appointment mechanics.

## Audit implication

When reviewing a design, ask not only whether goals exist, but:
- how quickly they are visible
- how varied they are
- how they ladder across short, mid, and long time horizons
- whether the player can end cleanly
- whether the return trigger creates anticipation rather than mere obligation

---
name: game-design-bartle-archetype-audit
description: Audit a game, feature, event, progression system, social system, live-ops loop, or onboarding flow through the lens of Bartle player archetypes: Achievers, Explorers, Socializers, and Killers. Use when evaluating who a design motivates, who it neglects, whether a feature over-serves one archetype at the expense of others, how a system will be perceived by different motivational player types, or why engagement is uneven across different player motivations.
---

# Game Design Bartle Archetype Audit

Audit a design by asking which Bartle-type players it serves, frustrates, excludes, or accidentally overfeeds.

Use this skill to evaluate how a game or feature lands with four classic player archetype lenses:
- **Achievers** - driven by progress, status, optimization, completion, and measurable advancement
- **Explorers** - driven by discovery, experimentation, hidden depth, and systemic curiosity
- **Socializers** - driven by connection, expression, cooperation, recognition, and shared play
- **Killers** - driven by domination, disruption, competition, advantage, and impact over others

Treat these as motivational lenses, not rigid personality boxes.

## Core principle

A feature rarely serves all player archetypes equally.

That is not automatically a problem. The real question is whether the imbalance is intentional, healthy, and compatible with the broader game. A design can succeed by strongly serving one archetype, but it can also fail by unintentionally alienating others or by overfeeding one motivational pattern until it distorts the whole experience.

## What to produce

Generate:
1. **Audit target** - what is being reviewed and what it is supposed to do
2. **Archetype-by-archetype reading** - how each Bartle lens experiences the design
3. **Motivational profile** - which archetypes are strongly served, weakly served, or actively harmed
4. **Imbalance diagnosis** - where the design overcommits, neglects, or creates unhealthy tension
5. **Recommendations** - what to strengthen, soften, separate, or clarify

## Process

### 1. Define the audit target
Clarify:
- what is being audited
- what the feature or system is supposed to achieve
- what player segment it seems primarily aimed at
- whether it is core, optional, early-game, mid-game, endgame, or event-based

### 2. Audit for Achievers
Ask:
- Does this provide clear goals, progress, ranks, milestones, or measurable completion?
- Is advancement legible and satisfying?
- Are there optimization hooks or mastery ladders?
- Does the system reward effort and planning in a visible way?
- Does it create grind without meaningful payoff?

Look for:
- progression clarity
- completion pressure
- reward cadence
- rank/status markers
- optimization opportunities
- scoreboard or collection incentives

### 3. Audit for Explorers
Ask:
- Does this create opportunities for discovery, experimentation, hidden depth, or surprising interactions?
- Is there anything to uncover, test, or learn beyond the obvious path?
- Does the feature reward curiosity, or punish deviation from the intended route?
- Is the system too solved, too explicit, or too shallow to explore?

Look for:
- secrets or hidden layers
- systemic depth
- expressive experimentation
- optional discovery
- mystery and possibility
- non-obvious interactions

### 4. Audit for Socializers
Ask:
- Does this support cooperation, expression, social recognition, gifting, helping, belonging, or conversation?
- Are there reasons to share, show, support, or coordinate?
- Does it create social presence or only social metrics?
- Does the system feel socially alive or socially sterile?

Look for:
- communication value
- collaboration loops
- group identity
- mutual dependency
- recognition and expression
- emotionally meaningful social rituals

### 5. Audit for Killers
Ask:
- Does this allow players to dominate, disrupt, outplay, pressure, or visibly outperform others?
- Is there direct or indirect competition?
- Does the system create status through relative power?
- Is competitive energy healthy here, or does it poison the experience?
- Could killer-facing incentives distort the feature for everyone else?

Look for:
- PvP or rivalry energy
- visible advantage
- denial or disruption power
- dominance loops
- competitive prestige
- asymmetric leverage over others

### 6. Build the archetype profile
For each archetype, rate the design as:
- **Strongly served**
- **Moderately served**
- **Weakly served**
- **Actively frustrated**

Use this format:

| Archetype | Rating | Why | Likely Response |
|---|---|---|---|
| Achievers | ... | ... | ... |
| Explorers | ... | ... | ... |
| Socializers | ... | ... | ... |
| Killers | ... | ... | ... |

### 7. Diagnose imbalance and cross-archetype friction
Ask:
- Is the feature clearly built for one archetype while pretending to serve all?
- Does one archetype's reward structure damage another's experience?
- Is the design too narrow for the place it occupies in the game?
- Does the game need this system to be broad, or is specialization acceptable here?

Common imbalance patterns:
- **Achiever trap** - everything becomes checklist, grind, ranking, and completion pressure
- **Explorer starvation** - system is legible but dead, with nothing to discover or test
- **Social shell** - other people are visible, but there is no real social meaning
- **Killer contamination** - competitive pressure warps a space that should feel safe, expressive, or cooperative
- **False inclusivity** - feature signals broad appeal but meaningfully serves only one player type

### 8. Convert findings into design actions
For each major issue, specify:
- **Archetype affected**
- **Current issue**
- **Design cause**
- **Suggested change**
- **Expected effect**

## Response structure

### Audit Target
- ...

### Achievers
- Strengths: ...
- Weaknesses: ...

### Explorers
- Strengths: ...
- Weaknesses: ...

### Socializers
- Strengths: ...
- Weaknesses: ...

### Killers
- Strengths: ...
- Weaknesses: ...

### Archetype Profile
- ...

### Imbalance Diagnosis
- ...

### Recommendations
1. ...
2. ...
3. ...

## Fast mode
- Which archetype is this mainly serving?
- Which archetype is getting the least value?
- Which archetype could be actively harmed by this design?
- Is that imbalance intentional and acceptable?
- What one change would improve the weakest archetype fit without breaking the strongest one?

## References

Read these when useful:
- `references/bartle-notes.md` for a concise interpretation of the four archetypes in game-design terms
- `references/failure-patterns.md` for common archetype imbalance shapes

## Working principle

A feature does not need to satisfy every Bartle archetype equally.
But if it strongly privileges one motivational type, that should be by design, not by accident.

FILE:references/bartle-notes.md
# Bartle Archetype Notes

Use these as motivational lenses rather than fixed personality categories.

## Achievers
Driven by:
- progress
- completion
- efficiency
- rank
- optimization
- measurable success

They tend to care about:
- clear goals
- mastery ladders
- visible milestones
- rewards for effort
- status signals

Typical design hooks:
- achievement systems
- progression ladders
- leaderboards
- collection completion
- upgrade paths

## Explorers
Driven by:
- discovery
- hidden depth
- experimentation
- system curiosity
- possibility space

They tend to care about:
- secrets
- unexpected interactions
- world detail
- mechanical depth
- non-obvious strategies

Typical design hooks:
- hidden content
- branching systems
- emergent interactions
- lore fragments
- optional puzzle-like depth

## Socializers
Driven by:
- belonging
- connection
- cooperation
- expression
- shared ritual
- recognition by others

They tend to care about:
- social spaces
- gifting/helping
- clubs or guilds
- identity expression
- communication value

Typical design hooks:
- cooperative systems
- social presence
- customization and sharing
- group contribution
- mutual support loops

## Killers
Driven by:
- competition
- domination
- disruption
- leverage over others
- visible superiority

They tend to care about:
- PvP
- rivalry
- denial power
- rank through comparison
- asymmetrical advantage

Typical design hooks:
- direct competition
- zero-sum pressure
- attack/defense loops
- sabotage or denial systems
- prestige via superiority

## Important note

Many features combine several of these motivations.
The point of the audit is not to force every system into one bucket.
The point is to understand which player lenses are actually being served and which ones are left hungry or pushed away.
FILE:references/failure-patterns.md
# Bartle Archetype Failure Patterns

Use these when diagnosing imbalance or unintended audience fit.

## Achiever trap
The system is full of goals, ranks, meters, and rewards, but feels like obligation rather than play.

## Explorer starvation
The feature is mechanically obvious and fully solved on first contact, leaving no room for curiosity.

## Social shell
Social visibility exists, but there is little real cooperation, connection, or meaning.

## Killer contamination
Competitive leverage enters a space that should support comfort, creativity, or collaboration, making it feel hostile.

## False inclusivity
The feature is marketed as broad and exciting for everyone, but meaningfully satisfies only one archetype.

## Reward mismatch
The feature asks one archetype to engage with a motivation structure built for another.
Example: explorers are funneled into repetitive achiever chores with no discovery payoff.

## Segment drift
The system begins by serving one archetype well, then later tuning or monetization shifts it toward a different player type and breaks its original appeal.

## Audit question

For each failure pattern, ask:
- which archetype is overfed?
- which archetype is starved or pushed away?
- is the imbalance intentional?
- if intentional, is it appropriate for this feature's role in the game?

---
name: design-red-team-audit
description: Adversarial design audit that stress-tests a game feature, system, pitch, roadmap item, or product idea by assuming failure and identifying the most credible reasons it would fail. Use when pressure-testing a concept before production, performing a pre-mortem, challenging a feature that sounds good on paper, exposing blind spots in design thinking, or getting a hostile-but-constructive critique with concrete failure mechanisms and de-risking moves.
---

# Design Red Team Audit

Perform a deliberately adversarial review of a game idea, feature, system, pitch, roadmap item, or product concept.

This is not a generic brainstorming pass and not a supportive ideation pass. Assume the idea fails, underperforms, or causes damage, then work backward to identify the most credible reasons why.

## Purpose

Expose:
- hidden assumptions
- likely failure modes
- player-facing weaknesses
- production and rollout risks
- strategic misfires
- fake confidence created by vague goals or weak metrics

## Working stance

Adopt the stance of a sharp, skeptical reviewer.

Be hard on the idea, not sloppy.
Avoid vague negativity.
Every criticism should point to a mechanism of failure.

Bad:
- "Players may not like this."
- "This seems risky."
- "This could be confusing."

Good:
- "The feature adds a second layer of optimization, but the player is never given enough feedback to understand whether they are making good decisions. That creates opacity rather than mastery."
- "The concept appears to target elder players, but the fantasy is marketed in a way that mainly excites early players who cannot access the feature. That mismatch is likely to produce tease without payoff."
- "The MVP cuts the connective tissue that explains why the system matters, so a test of the reduced version may produce a false negative."

## Inputs

The user may provide:
- a feature description
- a concept pitch
- a problem statement
- a design document
- a roadmap item
- a prototype summary
- a postmortem candidate
- a deck or presentation
- a system description
- target KPIs or business goals
- intended player segment

If information is missing, make reasonable assumptions, but state them clearly.

## Audit lenses

Examine the idea through these lenses where relevant:

### 1. Goal failure
- Is the problem worth solving?
- Is the stated goal vague, inflated, or contradictory?
- Are there multiple hidden goals fighting each other?

### 2. Player value failure
- Why would players not care?
- Why would they misunderstand the promise?
- Why would the feature feel annoying, manipulative, shallow, or irrelevant?
- Which audience is supposed to care, and why might they not?

### 3. UX and comprehension failure
- What will be confusing?
- What is too hidden, too abstract, too fiddly, or too effortful?
- Does the system demand understanding before it provides motivation?

### 4. Systemic design failure
- Does it conflict with the core loop?
- Does it create complexity without depth?
- Does it cannibalize existing motivations, rewards, or behaviors?
- Does it introduce incentives that break other systems?

### 5. Content and scalability failure
- Is this too content-hungry?
- Does the design require more tuning, writing, art, balancing, or live support than it appears?
- Will the idea collapse into repetition?

### 6. Production failure
- Is the concept harder to implement than it sounds?
- Are dependencies hidden?
- Is cross-discipline alignment likely to break?
- Is the team pretending the scope is smaller than it is?

### 7. Prototype and validation failure
- Is the prototype plan incapable of answering the actual unknowns?
- Is the team building a demo instead of testing the risk?
- Could a prototype produce misleading confidence?

### 8. MVP failure
- What essential element is likely to be cut?
- Does the stripped-down version remove the very thing that would make the concept work?
- Could the MVP create a false negative or false positive?

### 9. KPI and measurement failure
- Are success metrics weak, gameable, or indirect?
- Is the team measuring activity instead of value?
- Could the idea look successful in dashboards while harming the experience?

### 10. Rollout failure
- What happens when this meets real players?
- Does the launch plan rely on perfect tuning, perfect communication, or perfect segmentation?
- Is the team prepared only for success?

### 11. Strategic failure
- Even if it works, is it worth doing?
- Is this a distraction from higher-value work?
- Does it fit the game’s identity and long-term direction?

## Output format

Structure the response with the following sections:

### Verdict
Choose one:
- Worth exploring
- Promising but fragile
- Viable with major risks
- Structurally weak
- Not worth pursuing in current form

Then explain why in 2–5 sentences.

### Most Credible Failure Modes
List the top 3–7 failure modes.
For each one include:
- **Failure mode**
- **Why it happens**
- **Likely consequence**
- **Early warning signs**
- **Possible mitigation**

### Weak Assumptions
Identify the assumptions the idea depends on.
Call out which ones are most likely to be false.

### What Would Need To Be True
State the conditions under which the idea could succeed.

### Fastest De-Risking Moves
Suggest the quickest ways to test the biggest uncertainties.
Prefer:
- targeted prototype questions
- focused playtests
- segmentation checks
- UX clarity checks
- economy simulations
- rollout safeguards

## References

Read these when useful:
- `references/workflow.md` for the step-by-step audit flow
- `references/examples.md` for example prompts and expected usage shape

## Style rules
- Be blunt, but precise.
- Do not flatter the user.
- Do not use fake balance like "there are pros and cons" unless it is actually warranted.
- Do not pad with generic risks.
- Prioritize specific mechanisms of failure over abstract criticism.
- Focus on reality, not theoretical purity.
- Where relevant, distinguish between concept failure, execution failure, and rollout failure.
- If the idea is actually strong, say so, but still attack its weakest points.

## Working principle

Always think in pre-mortem form:

**Assume this failed. What most likely killed it?**

Do not default to "it depends."
Make a judgment.

FILE:references/examples.md
# Examples

## Example prompt 1
Audit this idea in a hostile but constructive way:

We want to add a district specialization system to a city builder. Players can assign districts into roles like industrial, cultural, residential, or logistics. Each role modifies output chains and unlocks unique bonuses. The goal is to improve mid-game depth and give players more meaningful city planning decisions.

## Example prompt 2
Red-team this feature:

We want a social gifting feature where players can request items from friends. The intent is to increase daily engagement and social retention, but the game currently has weak cooperative play and low friend density.

## Example prompt 3
Assume this concept failed six months after launch. Why?

We are adding an AI-driven NPC dialogue layer to a management sim to make residents feel more alive. The NPCs will react dynamically to player actions and remember recent events. We believe this will increase attachment and retention.

## Example prompt 4
Perform a pre-mortem on this pitch:

A late-game crafting feature where players combine rare drops into prestige-tier items. The feature is meant to create long-term goals for advanced players and improve monetization through acceleration offers.

FILE:references/workflow.md
# Workflow: Design Red Team Audit

## Objective
Perform an adversarial design audit on a game idea, feature, system, or pitch by assuming failure and identifying the most credible reasons for it.

## Step 1: Restate the idea
First, briefly restate the concept in your own words.
This forces clarity and reveals whether the idea is actually coherent.

Include:
- what the thing is
- who it is for
- what it is supposed to achieve
- where it sits in the product

If crucial information is missing, note assumptions explicitly.

## Step 2: Identify the claimed source of value
State what the idea appears to promise.

Examples:
- stronger retention
- more player mastery
- better elder-game engagement
- fresher social dynamics
- more monetizable progression
- better onboarding clarity
- more meaningful mid-game goals

Then ask:
- is this value real?
- is it visible to players?
- is it worth the cost and complexity?

## Step 3: Attack the idea through failure lenses
Systematically inspect the idea from these angles:

1. Goal failure
2. Player value failure
3. UX/comprehension failure
4. Systemic design failure
5. Content/scalability failure
6. Production failure
7. Prototype/validation failure
8. MVP failure
9. KPI/measurement failure
10. Rollout failure
11. Strategic failure

Do not force every category if some are irrelevant.
Focus on the most dangerous ones.

## Step 4: Rank failure modes
From all possible critiques, select the top few that are:
- most likely
- most damaging
- hardest to detect early
- hardest to recover from post-launch

Prefer a short list of credible failures over a long list of weak ones.

## Step 5: Produce a hard verdict
Choose one:
- Worth exploring
- Promising but fragile
- Viable with major risks
- Structurally weak
- Not worth pursuing in current form

No hedging.
Back the judgment with reasoning.

## Step 6: Suggest de-risking actions
Recommend the fastest and cheapest ways to test the dangerous assumptions.

Good examples:
- a paper prototype for decision clarity
- a fake-door test for player interest
- a limited economy simulation
- a usability session focused on teachability
- a segmented playtest for target audience fit
- a rollout guardrail plan
- clearer success metrics before implementation begins

Avoid generic advice like “do more testing.”

## Response template

### Verdict
[One-line judgment]

[2–5 sentence explanation]

### Most Credible Failure Modes

#### 1. [Failure mode name]
- **Why it happens:** ...
- **Likely consequence:** ...
- **Early warning signs:** ...
- **Possible mitigation:** ...

#### 2. [Failure mode name]
- **Why it happens:** ...
- **Likely consequence:** ...
- **Early warning signs:** ...
- **Possible mitigation:** ...

#### 3. [Failure mode name]
- **Why it happens:** ...
- **Likely consequence:** ...
- **Early warning signs:** ...
- **Possible mitigation:** ...

### Weak Assumptions
- ...
- ...
- ...

### What Would Need To Be True
- ...
- ...
- ...

### Fastest De-Risking Moves
- ...
- ...
- ...

## Quality bar
A strong audit:
- names concrete failure mechanisms
- distinguishes between player, production, and business risk
- avoids boilerplate negativity
- makes a judgment
- helps the team decide what to test next

A weak audit:
- just sounds cynical
- repeats stock phrases
- lists every imaginable risk
- refuses to prioritize
- gives no real decision support

---
name: game-design-pitch-deck-audit
description: Audit a video game pitch deck, publisher deck, funding deck, or investor-facing game presentation for clarity, structure, persuasiveness, visual readability, business-case completeness, and publisher-fit. Use when reviewing a pitch deck before sending to publishers, polishing a deck for meetings, checking whether the deck answers the essential questions about who, what, why, when, budget, and opportunity, or evaluating whether a deck sells both the game and the collaboration case rather than just dumping information.
---

# Game Design Pitch Deck Audit

Audit a game pitch deck as both a persuasion tool and a business-case artifact.

Use this skill to evaluate whether a game pitch deck is clear, compelling, visually readable, and properly structured for publisher or funding conversations. Focus on whether the deck makes a strong case for the team, the game, the opportunity, the ask, and the path to completion.

## Core principle

A good pitch deck does not merely describe a game.
It builds confidence in the team, sells the dream of the project, proves the work, frames the opportunity, and makes a realistic ask.

## What to produce

Generate:
1. **Deck overview** - what the deck is trying to do and for whom
2. **Structure audit** - whether the core sections are present and in a persuasive order
3. **Content audit** - strengths, gaps, and weak claims
4. **Visual/readability audit** - whether the deck is easy to follow without live narration
5. **Publisher-fit audit** - whether the deck answers the practical questions a publisher or funder will ask
6. **Recommendations** - what to cut, strengthen, reorder, or add

## Audit lenses

Audit the deck through these lenses:
- **Who** - who is making the game and why they are credible
- **Why / opportunity** - why this project exists and why now
- **What** - what the game is, what makes it stand out, and what the final vision is
- **Proof** - what already exists that proves the team can deliver
- **Business case** - comparables, target audience, monetization, market logic, and opportunity
- **Ask** - budget, timeline, platforms, scope, and what support is being requested
- **Readability** - whether the deck works when sent ahead of a meeting without narration

## Process

### 1. Define the deck context
Clarify:
- who the audience is: publisher, investor, platform, partner, grant body
- whether this deck is meant to be sent async, presented live, or both
- what stage the project is in: concept, prototype, vertical slice, production
- whether the deck is accompanied by a build, trailer, GDD, or other materials

### 2. Audit the high-level structure
Check whether the deck answers the essential questions:
- What are you making?
- Why are you making it?
- Who is making it?
- Where do you want to go?
- What do you need to get there?
- When will you get there?

Also check whether the deck roughly covers:
- team / studio credibility
- artistic why
- business why / opportunity
- dream of the game
- proof of the game
- work / systems / core loop
- market or comparables
- timeline and budget
- summary and contact info

### 3. Audit the team and credibility section
Ask:
- does the deck establish why this team should be trusted?
- does it show relevant shipped work, experience, or platform familiarity?
- is it concise, or does it waste time on irrelevant biography?
- does it explain who will actually make the game if funded?

### 4. Audit the game pitch itself
Check for three distinct functions:
- **Dream** - does the deck sell the final vision of the game?
- **Proof** - does it show prototype, vertical slice, or other non-speculative evidence?
- **Work** - does it explain how the game operates, what the core loop is, and why the game is compelling?

Ask:
- is the hook clear quickly?
- are the unique selling points obvious?
- does the deck lean into strengths strongly enough?
- does it show what is familiar and then what is unique?
- does it explain why the game matters, not just what it contains?

### 5. Audit the business case
Ask:
- does the deck explain the opportunity and target audience?
- are comparables believable and useful rather than vanity references?
- is monetization or business model clearly stated if relevant?
- is the market framing grounded, or just wishful genre enthusiasm?
- does the deck sell the collaboration case, not just the product fantasy?

### 6. Audit the ask
Check whether the deck makes a realistic ask around:
- budget
- timeline
- platforms
- release window
- build status
- support needed

Ask:
- is the budget plausible and safely scoped?
- are the timeline ratios believable?
- is the ask too low in a way that signals inexperience?
- does the deck separate development needs from broader publishing or marketing assumptions when relevant?

### 7. Audit deck usability and readability
Ask:
- does the deck work without live commentary?
- is the text readable and concise?
- are the slides overcrowded?
- does imagery carry the message effectively?
- are GIFs, videos, mockups, or key art used meaningfully?
- is the style aligned with the tone of the game?
- does the deck avoid pointless bullet sludge?

### 8. Audit submission readiness
If the deck is intended for publishers, check whether the package likely includes or references:
- a playable build
- control notes if needed
- skippable cutscenes or checkpoints if relevant to the build
- budget in practical terms
- timeline to release
- supplementary materials that help a stranger understand the project quickly

### 9. Diagnose common failure patterns
Common pitch-deck failure patterns:
- **Identity fog** - unclear what the game actually is
- **Dream without proof** - strong fantasy, weak evidence
- **Proof without dream** - lots of prototype facts, no compelling vision
- **Bio bloat** - too much team info with too little relevance
- **Market handwaving** - vague business claims with weak comparables
- **Budget naivety** - undercooked ask or unrealistic timeline
- **Narration dependency** - deck only works if someone explains everything live
- **Template autopilot** - all the right sections exist, but the deck says nothing memorable
- **Visual sludge** - unreadable, cramped, or aesthetically disconnected from the game

### 10. Convert findings into recommendations
For each issue, specify:
- **Problem**
- **Why it hurts the pitch**
- **Fix direction**
- **Priority** - critical / important / polish

## Response structure

### Deck Overview
- ...

### Structure Audit
- Present: ...
- Missing or weak: ...

### Content Audit
- Team credibility: ...
- Game hook: ...
- Proof: ...
- Business case: ...
- Ask: ...

### Visual / Readability Audit
- ...

### Publisher-Fit Audit
- ...

### Failure Patterns
- ...

### Recommendations
1. ...
2. ...
3. ...

## Fast mode
- What is the game?
- Why this team?
- Why this opportunity?
- What proof already exists?
- What is the ask?
- Would this deck still make sense if read without you in the room?

## References

Read these when useful:
- `references/pitch-deck-notes.md` for distilled deck structure and slide expectations from the templates
- `references/raw-fury-notes.md` for the Raw Fury-specific pitch expectations

## Working principle

A good pitch deck should make a stranger understand the game, trust the team, believe the opportunity, and feel the ask is grounded.
FILE:references/pitch-deck-notes.md
# Pitch Deck Notes

This reference distills the two PowerPoint templates found in Downloads.

## Core structural patterns

### Rami Ismail / Levelling the Playing Field template
Strongest recurring structure:
- Who
- Saw which opportunity
- To make what
- How can you benefit
- What do we need

Additional framing from the deck:
- establish team trust and relevant experience early
- explain the artistic why and business why separately
- sell the dream of the game, then prove it, then explain the work
- include believable comparables rather than giant vanity comps
- end with the ask: timeline, budget, and contact details
- deck should work even when sent ahead of a live meeting

Notable guidance from the template:
- keep to roughly 10-14 slides if possible, around 15 minutes spoken
- pretty matters; style the deck to match the game
- use mockups or target visuals to sell the final dream, not weak prototype scraps
- focus on what and why; explain how only when transformational
- numbers are boring unless remarkable
- publisher is buying into the business case and collaboration, not just the game fantasy

### GYLD template
Strongest recurring structure:
- Cover / title / logo
- Elevator pitch
- USP overview
- Gameplay overview / core loop
- Monetization / business model
- Art style or moodboard
- Roadmap and budget
- Team / studio
- Additional materials / build / links
- Thank you / contact

Notable guidance from the template:
- show core pillars and USPs clearly
- gameplay overview should visualize the loop
- use moving images where useful
- keep text readable and not cramped
- limit colour palette and preserve contrast
- include build links and extra material if available
- explain development status, target release, similar titles, modes, engine, platforms, and budget

## Shared takeaways

The two templates agree on the essentials:
- make the hook clear quickly
- show what makes the game stand out
- establish team credibility
- explain the path to completion
- make the budget and timeline legible
- keep the deck readable without narration
- use visuals that do real persuasive work, not decorative clutter

## Slide-level checks worth auditing

- cover/title slide clarity
- team slide relevance
- elevator pitch sharpness
- USP slide memorability
- core loop explanation
- prototype / vertical slice evidence
- market / comparable logic
- roadmap realism
- budget plausibility
- summary / contact readiness
FILE:references/raw-fury-notes.md
# Raw Fury Pitch Notes

This reference distills the document "How to Pitch to Raw Fury".

## Raw Fury wants these basics

### 1. A playable PC build
The build should communicate the essence of the game in a way outsiders can understand.

Helpful build features:
- skippable intro or cutscenes
- checkpoints if the build is longer than around 10 minutes
- English subtitles if spoken language is not English
- control scheme notes if needed

The main principle:
- send the build you are most proud of
- assume they may only play it once

### 2. A development budget
Raw Fury wants development cost for one PC build in USD.

Important framing:
- focus on development costs only
- no need to estimate marketing, PR, ports, events, etc.
- simplest framing: monthly burn rate multiplied by months left in development
- more detail is fine if it clarifies the process

### 3. A deck
Raw Fury's six essential questions:
- What are you doing?
- Why are you doing it?
- Who are you?
- Where do you want to go?
- What do you need to get there?
- When will you be there?

If those six are answered, the high-level deck is already useful.

### 4. Extra supporting material
Helpful additions:
- GIFs
- video playthroughs
- GDD
- concept art
- story documents
- anything that helps an outsider understand where the project is headed

## Audit implications

When auditing a publisher-facing deck, especially for Raw Fury-style expectations, check whether:
- the deck answers the six essential questions clearly
- the build is referenced or included
- the budget focuses on development costs in a practical way
- the materials help a stranger understand the project fast
- the deck avoids overcomplicating the pitch before the basics are covered

## Practical reading of publisher-fit

A good deck is not merely beautiful.
It should make a scouting person quickly understand:
- what the game is
- what makes it exciting
- why this team can make it
- what stage it is at
- what money and time are needed
- whether there is enough substance to keep the conversation going

---
name: game-design-ftue-hero-journey-audit
description: Audit a game's FTUE (First Time User Experience) through the lens of the Hero's Journey / monomyth. Use when reviewing onboarding, tutorial flow, first-session retention, first 30 seconds, early-session emotional hooks, mentor/tutorial character usage, first meaningful action, or whether an FTUE makes the player feel like the hero of the experience rather than a passive victim of UX chores.
---

# Game Design FTUE Hero's Journey Audit

Audit the FTUE as if the player is the hero of a story.

Use this skill to evaluate whether a game's onboarding creates emotional connection, delivers a compelling call to adventure, introduces guidance in a motivating way, and gives the player an early moment of meaningful control. This is not just a tutorial audit. It is an audit of the player's first heroic arc.

## Core principle

The purpose of FTUE is not merely to explain controls.
The deeper purpose is to create an emotional connection and make the player feel like the hero of their own story.

## Audit lens

Focus on these stages:
1. **Part 0 / Framing** - Is the FTUE treated broadly as the first meaningful arc, not just a tutorial?
2. **Call to Adventure** - Does the game quickly establish why this world, fantasy, or challenge is worth entering?
3. **Meeting the Mentor** - Does the game provide emotional guidance, framing, and useful gifts without drowning the player?
4. **Crossing the Threshold** - Does the player get to take meaningful action with enough autonomy and competence to feel good?

## What to produce

Generate:
1. **FTUE scope** - what span of the experience is being audited
2. **Hero's Journey stage review** - strengths and weaknesses by stage
3. **Psychological need check** - autonomy, competence, relatedness where relevant
4. **Drop-risk diagnosis** - where the FTUE is likely to lose players
5. **Recommendations** - what to cut, pace, reframe, or strengthen

## Process

### 1. Define the FTUE scope
Clarify:
- what counts as the FTUE in this game
- whether the audit covers first 30 seconds, first session, or several early sessions
- where the player is most likely to bounce

### 2. Audit the broad framing
Ask:
- is FTUE treated only as a control tutorial, or as the player's first arc with the game?
- does the experience aim to build emotional investment?
- does the flow respect the player's time and attention?
- are early retention risks acknowledged in the design?

### 3. Audit the Call to Adventure
Ask:
- does the game establish an inviting fantasy, promise, or problem quickly?
- does the player understand why they should care?
- is there a strong emotional hook before explanation overload begins?
- how much friction appears before meaningful interaction?
- are there blockers such as large downloads, mandatory account creation, intrusive popups, or heavy exposition?

Look for:
- fast entry into meaningful interaction
- minimal pre-play friction
- emotional hooks over yellow-arrow obedience
- intrigue, mood, and promise without infodump

### 4. Audit Meeting the Mentor
Ask:
- is there a mentor figure, guide, or equivalent framing device?
- does it create emotional connection or just dump instructions?
- does the guide explain only what matters now?
- does the player receive meaningful starter gifts, tools, or framing?
- is the mentor reused effectively for later mini-FTUE moments?

Look for:
- empathic or authoritative guidance
- gift-giving that feels magical, useful, and motivating
- character or framing that helps the world feel inhabited
- concise explanation rather than lore drowning

### 5. Audit Crossing the Threshold
Ask:
- when does the player first gain meaningful control?
- is the first self-directed action actually meaningful?
- does it satisfy autonomy as well as competence?
- is the task achievable by a novice while still feeling like real play?
- is the FTUE overloaded with too many mechanics or abilities too fast?
- are rules softened, randomness reduced, and feedback sped up during this phase?

Look for:
- early self-directed action
- clear and satisfying feedback
- low chance of early failure or humiliation
- only the minimum needed to start having fun
- gradual pacing of advanced systems

### 6. Check psychological needs
Use these lenses where relevant:
- **Autonomy** - how quickly the player gets meaningful agency
- **Competence** - whether the player can understand and succeed at the first tasks
- **Relatedness** - whether characters, framing, or social cues create emotional connection

### 7. Diagnose likely failure shapes
Common FTUE failure patterns:
- **Yellow-arrow servitude** - the player obeys prompts without caring
- **Pre-play bureaucracy** - too much friction before play begins
- **Lore drowning** - backstory arrives before emotional investment exists
- **Mentor as textbox** - guide character explains but does not emotionally connect
- **Threshold humiliation** - first real action is confusing or failure-prone
- **Overloaded onboarding** - too many mechanics too quickly
- **Competence trap** - player sleepwalks through tutorial and then crashes in real play

### 8. Convert findings into recommendations
For each issue, specify:
- what stage it damages
- what player need it frustrates
- what should be removed, delayed, simplified, reframed, or strengthened
- what emotional effect the change should produce

## Response structure

### FTUE Scope
- ...

### Part 0 / Framing
- Strengths: ...
- Weaknesses: ...

### Call to Adventure
- Strengths: ...
- Weaknesses: ...

### Meeting the Mentor
- Strengths: ...
- Weaknesses: ...

### Crossing the Threshold
- Strengths: ...
- Weaknesses: ...

### Psychological Need Check
- Autonomy: ...
- Competence: ...
- Relatedness: ...

### Drop-Risk Diagnosis
- ...

### Recommendations
1. ...
2. ...
3. ...

## Fast mode
- What is the player's first emotional hook?
- What friction appears before meaningful play?
- Who or what acts as the mentor?
- What is the first real self-directed action?
- Where is the FTUE most likely to lose the player?

## References

Read these when useful:
- `references/hero-journey-ftue-notes.md` for the article-derived stage mapping
- `references/failure-patterns.md` for common FTUE breakdowns through this lens

## Working principle

Do not design the player like a confused clerk filling forms.
Design them like the hero crossing into a world worth caring about.
FILE:references/failure-patterns.md
# Failure Patterns

Use these patterns when diagnosing why an FTUE feels weak through the Hero's Journey lens.

## Yellow-arrow servitude
The player is technically progressing but feels no ownership, curiosity, or emotional involvement.

## Pre-play bureaucracy
Downloads, logins, agreements, and popups eat the player's patience before meaningful play begins.

## Lore drowning
The game explains worldbuilding before the player has a reason to care.

## Mentor as textbox
A guide character exists, but functions only as instruction delivery without emotional resonance or useful framing.

## Threshold humiliation
The player's first real action is confusing, failure-prone, or too demanding for their early skill level.

## Overloaded onboarding
Too many mechanics, powers, currencies, or systems are taught too quickly.

## Competence trap
The tutorial is so rigid that the player sleepwalks through it, then collapses once real play begins.

## Gift without meaning
Starter rewards are handed out, but they do not feel magical, useful, or tied to a motivating fantasy.

## Emotional vacuum
The FTUE is functional but gives the player no feeling of adventure, purpose, or heroic role.

## Fix direction
For each pattern, ask:
- what stage is failing
- what need is being frustrated
- what can be removed, delayed, or reframed
- what first success or emotional hook should replace the weakness
FILE:references/hero-journey-ftue-notes.md
# FTUE as Hero's Journey - Notes

This reference distills the four source documents:
- Part 0
- Part I
- Part II
- Part III

## Part 0 - Purpose of FTUE

Key ideas:
- FTUE should be understood broadly, not just as a tutorial
- it can extend across the first session and sometimes several early sessions
- the biggest retention drop often happens during the first play session
- the true purpose of FTUE is to create emotional connection
- the player wants to be the hero of the game's story

Important implications:
- do not overfocus on explaining generic controls or UI conventions
- do not reduce FTUE to yellow-arrow obedience
- build engagement and emotional investment early

## Part I - Call to Adventure

Key ideas:
- the player can reject the call just as a hero can reject the adventure
- acquisition is expensive; early loss is painful
- the game itself must be inviting, not just the ad or store listing
- FTUE should support basic psychological needs, especially autonomy
- reduce the time before meaningful interaction

Things to minimize:
- large initial downloads
- slow loading
- mandatory logins
- intrusive popups
- excessive exposition

Narrative implication:
- provide just enough backstory to create intrigue
- use breadcrumbs, not infodumps
- emotional hooks matter more than factual explanation

## Part II - Meeting the Mentor

Key ideas:
- the mentor is a guide into the unknown
- the mentor explains only the basic nature of the quest and world
- the mentor often functions as a gift giver
- humanoid or emotionally legible characters help create empathy and connection
- gift-giving in FTUE often appears as starter items, tools, boosts, or starter systems
- the mentor pattern can repeat later in mini-FTUE moments when new features unlock

Important implication:
- a tutorial character should emotionally frame and support the player, not merely dump instructions

## Part III - Crossing the Threshold

Key ideas:
- this is the moment the player first takes meaningful control
- it must satisfy both autonomy and competence
- the first action should feel meaningful, achievable, and understandable
- overload and early failure create abandonment risk
- one-size-fits-all FTUE is difficult because players vary widely in experience

Mitigation principles:
- teach only the bare minimum needed for fun
- delay advanced systems
- reduce randomness during FTUE where possible
- provide immediate feedback
- pace learning over several moments rather than one giant dump

## Summary lens

A strong FTUE:
- gets to meaningful play quickly
- creates emotional investment early
- gives the player a reason to care
- offers guidance without smothering
- gives the player a first success that feels self-owned
- makes the player feel like a hero, not an intern clicking through forms

---
name: game-design-creative-unblocker
description: Break game design creative block with oblique prompts, sideways reframing, and deliberately non-linear workflow moves. Use when a feature, mechanic, live-ops idea, UX flow, FTUE, economy layer, or prototype feels stale, overthought, equally uninspired in every direction, or trapped in circular discussion. Best when the team needs jolts, detours, provocations, and weird-but-useful next directions rather than another sensible framework.
---

# Game Design Creative Unblocker

Go sideways on purpose.

Use this skill when normal rational design thinking has turned into sludge. The aim is not to produce the cleanest answer immediately. The aim is to disrupt stale thinking, challenge bias, and generate weird but salvageable directions.

This skill is inspired by oblique strategies: prompts that do not solve the problem directly, but knock it loose.

## Working stance

Be playful, mischievous, and slightly disruptive, but stay useful.

Treat prompts as nudges, not commandments.
Not every prompt will fit. That is part of the point.
A non sequitur can still expose a better path.

## What to produce

Generate:
1. **Stuck point** - what feels blocked, muddy, stale, or overworked
2. **Oblique prompts** - 1 to 3 chosen prompts
3. **Prompt interpretations** - what each prompt suggests in this context
4. **Sideways directions** - surprising design directions, edits, cuts, or experiments
5. **Salvageable next step** - the most useful thing to test, discuss, or prototype next

## Process

### 1. Name the stuck point
Clarify:
- what the team is stuck on
- what has already been tried
- what feels dead, circular, or overcomplicated
- whether the problem is lack of ideas, too many half-formed ideas, or inability to choose

### 2. Draw 1 to 3 oblique prompts
Choose prompts that create contrast, discomfort, or a new angle.

Use the prompt list in `references/oblique-prompts.md`.
If one prompt feels flat, draw another.
If a prompt feels absurd but energizing, keep it.

### 3. Force interpretation
For each prompt, ask:
- if this were annoyingly true, what would it imply?
- what would we do differently if we took it seriously for ten minutes?
- what hidden assumption does it challenge?
- what part of the feature becomes suspect, stronger, or newly interesting?

Do not dismiss a prompt too fast just because it sounds stupid.

### 4. Generate sideways directions
Turn the prompt into possible actions such as:
- cut something
- exaggerate something
- invert something
- randomize one decision
- simplify aggressively
- reuse an older idea
- make the emotional truth more obvious
- make the player reaction sharper, stranger, or clearer

### 5. Extract the salvageable move
End with something practical:
- one experiment to run
- one option to expand
- one darling to kill
- one question to ask players
- one awkward or embarrassing detail worth leaning into

## Response structure

### Stuck Point
- ...

### Oblique Prompts
1. ...
2. ...
3. ...

### Interpretations
- Prompt 1 means: ...
- Prompt 2 means: ...
- Prompt 3 means: ...

### Sideways Directions
- ...

### Salvageable Next Step
- ...

## Fast mode
- What feels stale or blocked?
- Draw 1-2 prompts.
- What do they force us to notice?
- What weird direction is actually worth testing?

## References

Read these when useful:
- `references/oblique-prompts.md` for the prompt deck derived from the PDF text and adjacent oblique-style moves
- `references/usage-notes.md` for tone, facilitation guidance, and anti-patterns

## Working principle

When a design problem refuses to move forward, stop pushing harder in the same direction.
Draw a strange card. Disturb the pattern. Then steal the useful part.
FILE:references/oblique-prompts.md
# Oblique Prompts for Game Design

Use these prompts to disrupt stale thinking. They are not commandments. They are creative detours.

## Full prompt list

- REMEMBER THE PRINCESS IS IN ANOTHER CASTLE
- IT IS A HERO'S JOURNEY
- KILL YOUR DARLINGS
- MAKE A DECISION, EVEN A BAD ONE
- CHANGE ONE RULE
- SIMPLIFY
- CUT SOMETHING OUT
- GO BIG OR GO HOME
- SCOPE DOWN
- MAKE YOUR PLAYERS ANGRY
- IS IT VISCERAL?
- WHAT IS YOUR IMMEDIATE GOAL?
- MULTIPLY EVERYTHING BY TWO; DIVIDE EVERYTHING BY TWO
- GO CRAZY
- USE AN OLD IDEA
- STEAL SOMETHING FROM THE COMPETITION
- REMEMBER YOUR FAVOURITE GAME
- THINK ABOUT GARDENING
- ASK THE QUESTION YOU DON'T WANT TO ANSWER
- DO, DON'T THINK
- DO NOT USE YOUR FIRST IDEA
- ORDER YOUR OPTIONS ALPHABETICALLY
- PICK ONE OPTION AT RANDOM AND DEVELOP IT FURTHER
- USE A CLICHE
- CHALLENGE YOUR ASSUMPTIONS
- RECONSIDER THE IDEA YOU REJECTED
- TEAR IT ALL DOWN AND START ALL OVER
- WHAT DID YOU LEARN FROM THE PREVIOUS ATTEMPT?
- WHY ARE YOU DOING THIS IN THE FIRST PLACE?
- CAN THE GAME WORK WITHOUT IT?
- WHAT DO PLAYERS SAY?
- WHAT IS THE VALUE OF THE THING YOU ARE SELLING?
- WHERE DO YOU WANT TO BE IN SEVEN DAYS?
- HOW DO YOU KNOW YOU ARE GOOD AT THIS GAME?
- BRAINSTORM
- ASK A RANDOM TEAMMATE
- DO IT BACKWARDS
- REJECT THE OBVIOUS CHOICE
- GO AROUND THE OBSTACLE
- MAKE IT HARDER
- DO A SANITY CHECK
- ARE YOU MISSING SOMETHING OBVIOUS?
- MAKE IT MULTIPLAYER
- MAKE IT SINGLE PLAYER
- MAKE IT TURN-BASED
- WOULD IT WORK AS A CARD GAME?
- CONTEXT IS THE KING
- DEVIL IS IN THE DETAILS
- HOW CAN YOU MITIGATE THE RISKS
- DO NOT FEAR LARGE NUMBERS
- DO NOT FEAR COMPLEXITY
- ADD ANOTHER CURRENCY
- CAN YOU EXPLOIT THIS
- EMBRACE YOUR ERROR AS A HIDDEN INTENT
- ROLL WITH THE THING THAT WORRIES YOU THE MOST
- ITERATE
- CHANGE ONE THING AT A TIME
- SAY IT IN THREE SENTENCES
- SAY IT IN TWENTY FIVE WORDS OR LESS
- FIND THE MOST EMBARRASSING DETAIL AND AMPLIFY IT

## How to use the prompts

- Pick 1 to 3 prompts at a time.
- Prefer contrast over perfect relevance.
- If a prompt feels useless, ask what assumption makes it feel useless.
- Translate each prompt into a design move, not just a slogan.
- End by extracting one testable or discussable next step.

## Facilitation note

Some prompts are contradictory on purpose.
That is part of the method.
The point is not to obey the deck consistently.
The point is to disturb stale thinking until something alive appears.
FILE:references/usage-notes.md
# Usage Notes

## When to use this skill

Use it when:
- every option feels equally dead
- the team is circling the same arguments
- the prototype is technically functional but creatively flat
- the feature has become spreadsheet sludge
- the design is overthought, overexplained, or overprotected
- you need energy and movement more than neatness

## When not to use it

Do not use it when:
- the problem is simple and already well understood
- precise production planning is needed right now
- a clear audit or prioritization workflow would solve the issue better
- the team is too fragile to tolerate playful provocation

## Facilitation stance

- Stay playful, but do not become random for its own sake.
- Treat absurd prompts seriously for a few minutes before rejecting them.
- Use the prompt to expose assumptions, not to win arguments.
- If a prompt generates energy, follow it.
- If a prompt generates only fog, drop it and draw another.

## Common anti-patterns

- Turning the prompts into fake wisdom quotes
- Using weirdness to avoid making a decision
- Mistaking chaos for creativity
- Pulling too many prompts at once
- Keeping only the joke and not the usable insight

## Best ending move

Always end with one salvageable next step:
- a prototype
- a rewrite
- a cut
- a player question
- a stronger variant to explore
- a worse variant worth testing because it reveals the truth faster

---
name: game-design-feature-prioritization
description: Prioritize game design feature options by comparing expected impact, implementation cost, strategic fit, and roadmap context. Use when choosing between competing feature ideas, deciding what to do now versus later, ranking solution paths after ideation, or identifying which option is best immediately and which is better long-term.
---

# Game Design Feature Prioritization

Choose the strongest next move, not just the loudest idea.

Use this skill to compare candidate features or solution paths and decide what should happen now, later, or not at all. Keep the process practical. Rough structured judgment is better than fake precision, but explicit comparison is still useful.

Read `references/family-conventions.md` when you need the shared conventions for this GROW-derived skill family.

## What to produce

Generate:
1. **Candidate list** - what is being prioritized
2. **Evaluation matrix** - impact, cost, fit, risk, timing
3. **Priority ranking** - now, later, discard, or monitor
4. **Recommendation** - what should happen next and why

## Process

### 1. List the candidates
Make sure the compared items are clear and meaningfully distinct.

### 2. Score the options
Use rough structured scoring such as 1-5 for:
- **Impact** - expected player or business value
- **Implementation cost** - time, resources, complexity
- **Strategic fit** - alignment with game direction and roadmap
- **Risk** - uncertainty, dependency burden, fragility
- **Timing** - whether this is right now or later

### 3. Interpret in context
Do not choose purely by raw score.
Also consider:
- roadmap sequencing
- enabling value for future features
- opportunity cost
- whether a slightly weaker option is smarter in the long run

### 4. Recommend action
For each option, classify it as:
- **Do now**
- **Test first**
- **Do later**
- **Discard for now**

## Response structure

### Candidates
- ...

### Evaluation Matrix
| Option | Impact | Cost | Strategic Fit | Risk | Timing | Notes |
|---|---:|---:|---:|---:|---|---|

### Priority Ranking
- ...

### Recommendation
- ...

## Fast mode
- What are we choosing between?
- Which option has the best impact-to-cost profile?
- Which option best fits the roadmap right now?
- What should we do now, later, or not at all?

## Working principle

The locally optimal choice is not always the strategically best one.
FILE:references/family-conventions.md
# GROW-Derived Family Conventions

Use this family of skills as workflow tools for game design thinking and decision-making.

## Shared stance
- Prefer practical design movement over abstract theory.
- Keep outputs decision-oriented.
- Avoid pretending rough judgments are precise truths.
- When possible, distinguish player value, business value, implementation cost, risk, and strategic fit.
- Prefer several credible paths before commitment.
- Treat these skills as complements, not strict silos.

## How this skill family fits together
- **game-design-goal-framing**: clarify what the feature is for
- **game-design-option-generation**: expand the solution space
- **game-design-five-options**: force explicit comparison across several candidate paths
- **game-design-roadblock-reframing**: get unstuck when one blocker dominates thinking
- **game-design-ideal-outcome-backcasting**: work backward from the best believable future
- **game-design-transformative-reuse**: adapt or recombine what already exists
- **game-design-feature-prioritization**: choose what to do now, later, or not at all

## Recommendation
Start with the narrowest skill that matches the user's real need. If several apply, use them in sequence rather than collapsing everything into one bloated answer.

---
name: game-design-five-options
description: Generate and compare at least five game design solution options for a feature, system, UX issue, live-ops problem, or design challenge. Use when several ideas already exist, when a team needs broader comparison before choosing, or when one favorite answer is dominating too early and better alternatives may be getting ignored.
---

# Game Design Five Options

Force the design space open before it closes too early.

Use this skill when a team already has ideas and needs a structured way to compare them. The aim is to avoid premature convergence by putting several options side by side, then assessing their differences in value, cost, and risk.

Read `references/family-conventions.md` when you need the shared conventions for this GROW-derived skill family.

## What to produce

Generate:
1. **Problem statement** - what needs solving
2. **Five options** - distinct solution directions
3. **Pros and cons** - the upside and downside of each
4. **Rough comparison** - impact, cost, and fit
5. **Recommendation** - the best option or best test candidate

## Process

### 1. Define the problem
State clearly what outcome the options are trying to achieve.

### 2. Generate five distinct options
Push for real differences, not five tiny variations of the same idea.

### 3. Evaluate each option
For each one, describe:
- summary
- strengths
- weaknesses
- expected player impact
- implementation difficulty
- strategic fit

Optional: include SWOT-style notes if useful.

### 4. Prioritize
Recommend:
- the best immediate choice
- the fastest testable version
- any options that should be discarded or held for later

## Response structure

### Problem
- ...

### Five Options
1. ...
2. ...
3. ...
4. ...
5. ...

### Comparison
- ...

### Recommendation
- ...

## Fast mode
- What are five credible ways to solve this?
- Which one is strongest now?
- Which one is cheapest to test?

## Working principle

There is almost always more than one viable answer. Make the alternatives visible.
FILE:references/family-conventions.md
# GROW-Derived Family Conventions

Use this family of skills as workflow tools for game design thinking and decision-making.

## Shared stance
- Prefer practical design movement over abstract theory.
- Keep outputs decision-oriented.
- Avoid pretending rough judgments are precise truths.
- When possible, distinguish player value, business value, implementation cost, risk, and strategic fit.
- Prefer several credible paths before commitment.
- Treat these skills as complements, not strict silos.

## How this skill family fits together
- **game-design-goal-framing**: clarify what the feature is for
- **game-design-option-generation**: expand the solution space
- **game-design-five-options**: force explicit comparison across several candidate paths
- **game-design-roadblock-reframing**: get unstuck when one blocker dominates thinking
- **game-design-ideal-outcome-backcasting**: work backward from the best believable future
- **game-design-transformative-reuse**: adapt or recombine what already exists
- **game-design-feature-prioritization**: choose what to do now, later, or not at all

## Recommendation
Start with the narrowest skill that matches the user's real need. If several apply, use them in sequence rather than collapsing everything into one bloated answer.

---
name: game-design-goal-framing
description: Turn a vague feature idea or design direction into a clear game design goal with purpose, scope, fit, success criteria, and constraints. Use when a feature sounds promising but fuzzy, when a team cannot explain why something should exist, when success is unclear, or when a concept needs a stronger goal before ideation, evaluation, or prototyping.
---

# Game Design Goal Framing

Define what the feature is actually for.

Use this skill to sharpen a game design idea into a clear goal statement. The aim is to prevent fuzzy concepts, circular design discussion, and features that exist without a real reason. Keep the framing practical and explicit.

Read `references/family-conventions.md` when you need the shared conventions for this GROW-derived skill family.

## What to produce

Generate:
1. **Goal statement** - what the feature is meant to achieve
2. **Purpose** - why it should exist
3. **Fit** - how it connects to the rest of the game
4. **Success criteria** - player-facing and KPI-facing signals
5. **Constraints** - quality, scope, time, and resource limits

## Process

### 1. Clarify purpose
Ask:
- what problem does this solve
- what player behavior should change
- what player need or business need it serves

### 2. Check game fit
Ask:
- how it connects to existing loops and systems
- what player expectations it should meet
- what it must not break or dilute

### 3. Define success
Use a SMART-style lens:
- **Specific** - clear feature vision
- **Measurable** - success signals or KPIs
- **Attainable** - feasible with current constraints
- **Relevant** - connected to strategy and player value
- **Time-boxed** - aligned to a release or milestone

### 4. Write the framed goal
Use a compact format such as:

**Goal statement**  
We want to [player or business outcome] by introducing or changing [feature or system], measured by [signals], within [timeframe].

## Response structure

### Goal Statement
- ...

### Purpose
- ...

### Fit with the Game
- ...

### Success Criteria
- ...

### Constraints
- ...

## Fast mode
- What is this feature for?
- How should it help the player or the game?
- What would success look like?
- What constraints matter most?

## Working principle

A feature without a clear goal is just a vague wish wearing design clothes.
FILE:references/family-conventions.md
# GROW-Derived Family Conventions

Use this family of skills as workflow tools for game design thinking and decision-making.

## Shared stance
- Prefer practical design movement over abstract theory.
- Keep outputs decision-oriented.
- Avoid pretending rough judgments are precise truths.
- When possible, distinguish player value, business value, implementation cost, risk, and strategic fit.
- Prefer several credible paths before commitment.
- Treat these skills as complements, not strict silos.

## How this skill family fits together
- **game-design-goal-framing**: clarify what the feature is for
- **game-design-option-generation**: expand the solution space
- **game-design-five-options**: force explicit comparison across several candidate paths
- **game-design-roadblock-reframing**: get unstuck when one blocker dominates thinking
- **game-design-ideal-outcome-backcasting**: work backward from the best believable future
- **game-design-transformative-reuse**: adapt or recombine what already exists
- **game-design-feature-prioritization**: choose what to do now, later, or not at all

## Recommendation
Start with the narrowest skill that matches the user's real need. If several apply, use them in sequence rather than collapsing everything into one bloated answer.

---
name: game-design-roadblock-reframing
description: Reframe a game design problem by isolating the main blocker, imagining it removed, and using that perspective to discover workaround paths. Use when a team is stuck on one obstacle, when discussion keeps collapsing into 'we can't because', or when a feature, system, or plan feels trapped by a single technical, UX, content, or production roadblock.
---

# Game Design Roadblock Reframing

Get unstuck by changing the angle of the problem.

Use this skill when one blocker has become mentally larger than the design space around it. The aim is not to deny the blocker. The aim is to remove it temporarily, inspect what becomes possible, and then derive realistic paths around, under, or over it.

Read `references/family-conventions.md` when you need the shared conventions for this GROW-derived skill family.

## What to produce

Generate:
1. **Roadblock definition** - what is blocking progress
2. **Unblocked reality** - what the design would look like if that blocker vanished
3. **Workaround paths** - how to approach that unblocked state without magic
4. **Recommendation** - which path is most credible now

## Process

### 1. Name the blocker clearly
Define:
- what the roadblock is
- why it matters
- how it is constraining design thinking

### 2. Imagine it removed
Ask:
- if this disappeared overnight, what would we want to do?
- what would the feature or system look like then?
- what value are we actually trying to protect or create?

### 3. Derive workaround paths
From the unblocked version, ask:
- what partial version is achievable now
- what adjacent solution gets us close enough
- what substitute mechanism could create similar value
- what sequencing change could bypass the blocker for now

### 4. Choose the strongest path
Select the workaround that best preserves value with acceptable cost and risk.

## Response structure

### Roadblock
- ...

### Unblocked Reality
- ...

### Workaround Paths
1. ...
2. ...
3. ...

### Recommendation
- ...

## Fast mode
- What is the blocker?
- If it disappeared, what would we do?
- What is the nearest realistic version of that outcome?

## Working principle

Do not let one obstacle define the entire design space.
FILE:references/family-conventions.md
# GROW-Derived Family Conventions

Use this family of skills as workflow tools for game design thinking and decision-making.

## Shared stance
- Prefer practical design movement over abstract theory.
- Keep outputs decision-oriented.
- Avoid pretending rough judgments are precise truths.
- When possible, distinguish player value, business value, implementation cost, risk, and strategic fit.
- Prefer several credible paths before commitment.
- Treat these skills as complements, not strict silos.

## How this skill family fits together
- **game-design-goal-framing**: clarify what the feature is for
- **game-design-option-generation**: expand the solution space
- **game-design-five-options**: force explicit comparison across several candidate paths
- **game-design-roadblock-reframing**: get unstuck when one blocker dominates thinking
- **game-design-ideal-outcome-backcasting**: work backward from the best believable future
- **game-design-transformative-reuse**: adapt or recombine what already exists
- **game-design-feature-prioritization**: choose what to do now, later, or not at all

## Recommendation
Start with the narrowest skill that matches the user's real need. If several apply, use them in sequence rather than collapsing everything into one bloated answer.

---
name: game-design-transformative-reuse
description: Solve game design problems by adapting, extending, recombining, or retuning what already exists instead of inventing from scratch. Use when building on live systems, reusing content pipelines, stretching feature value, reducing production cost, or finding a lower-risk way to achieve a new purpose with existing mechanics, UX, progression structures, or content.
---

# Game Design Transformative Reuse

Look for leverage before novelty.

Use this skill when the smartest move may be to transform existing systems rather than create entirely new ones. The aim is not lazy recycling. The aim is to discover whether a new purpose can be served by adaptation, recombination, extension, or tuning.

Read `references/family-conventions.md` when you need the shared conventions for this GROW-derived skill family.

## What to produce

Generate:
1. **Target problem or goal** - what needs to be achieved
2. **Reuse candidates** - which existing systems or assets could be transformed
3. **Transformation paths** - how each candidate could be adapted
4. **Recommendation** - which reuse path has the best leverage

## Process

### 1. Define the new purpose
Clarify:
- what the team wants to achieve
- what new value is needed
- what constraints matter most

### 2. Inventory reusable materials
Look for:
- existing features
- UI patterns
- content pipelines
- currencies or reward structures
- progression hooks
- social surfaces
- underused systems with adjacent value

### 3. Explore transformation paths
Ask:
- what can be adapted to fit the new purpose
- what can be added to existing features
- what can be recombined in a new way
- what can be solved by tuning rather than invention

### 4. Compare leverage
For each path, assess:
- player-facing freshness
- implementation effort
- systemic fit
- risk of feeling derivative or forced
- long-term flexibility

## Response structure

### Goal
- ...

### Reuse Candidates
- ...

### Transformation Paths
1. ...
2. ...
3. ...

### Recommendation
- ...

## Fast mode
- What are we trying to achieve?
- What existing thing is closest to that purpose?
- Can we adapt, extend, or recombine it instead of rebuilding?

## Working principle

Sometimes the strongest new design move is a smart transformation of something the game already knows how to do.
FILE:references/family-conventions.md
# GROW-Derived Family Conventions

Use this family of skills as workflow tools for game design thinking and decision-making.

## Shared stance
- Prefer practical design movement over abstract theory.
- Keep outputs decision-oriented.
- Avoid pretending rough judgments are precise truths.
- When possible, distinguish player value, business value, implementation cost, risk, and strategic fit.
- Prefer several credible paths before commitment.
- Treat these skills as complements, not strict silos.

## How this skill family fits together
- **game-design-goal-framing**: clarify what the feature is for
- **game-design-option-generation**: expand the solution space
- **game-design-five-options**: force explicit comparison across several candidate paths
- **game-design-roadblock-reframing**: get unstuck when one blocker dominates thinking
- **game-design-ideal-outcome-backcasting**: work backward from the best believable future
- **game-design-transformative-reuse**: adapt or recombine what already exists
- **game-design-feature-prioritization**: choose what to do now, later, or not at all

## Recommendation
Start with the narrowest skill that matches the user's real need. If several apply, use them in sequence rather than collapsing everything into one bloated answer.

---
name: game-design-ideal-outcome-backcasting
description: Start from the ideal player-facing result and work backward to the design steps, systems, and decisions required to reach it. Use when a team knows the kind of experience it wants but not how to structure the path there, when redesigning a feature around a stronger destination, or when clarifying what must be true for a concept to feel successful.
---

# Game Design Ideal Outcome Backcasting

Start from the ideal future and work backward.

Use this skill when the end-state is easier to imagine than the path to reach it. Treat the ideal outcome as a design tool, not a fantasy wish list. The aim is to define the best believable player-facing result, then retrace the steps needed to make it real.

Read `references/family-conventions.md` when you need the shared conventions for this GROW-derived skill family.

## What to produce

Generate:
1. **Ideal outcome** - the best believable player-facing result
2. **Required conditions** - what must be true for that result to exist
3. **Backward path** - the enabling steps, systems, and decisions
4. **Near-term priorities** - what must happen first

## Process

### 1. Describe the ideal future
Clarify:
- what the player experience looks and feels like
- what success looks like in the feature or system
- what makes this version meaningfully better than the current one

### 2. Identify enabling conditions
Ask:
- what must exist for this outcome to work
- what systems, UX, content, or support layers are required
- what assumptions must hold true

### 3. Work backward
Retrace the path from the ideal state to the current state.
List:
- key milestones
- prerequisite systems
- sequencing dependencies
- learnings or tests needed before commitment

### 4. Distill immediate priorities
Separate:
- what must happen now
- what can wait
- what should be prototyped or validated first

## Response structure

### Ideal Outcome
- ...

### Required Conditions
- ...

### Backward Path
1. ...
2. ...
3. ...

### Immediate Priorities
- ...

## Fast mode
- What does the best believable version look like?
- What would need to be true for that version to work?
- What are the first steps backward from that destination?

## Working principle

A clearer destination makes the path easier to design.
FILE:references/family-conventions.md
# GROW-Derived Family Conventions

Use this family of skills as workflow tools for game design thinking and decision-making.

## Shared stance
- Prefer practical design movement over abstract theory.
- Keep outputs decision-oriented.
- Avoid pretending rough judgments are precise truths.
- When possible, distinguish player value, business value, implementation cost, risk, and strategic fit.
- Prefer several credible paths before commitment.
- Treat these skills as complements, not strict silos.

## How this skill family fits together
- **game-design-goal-framing**: clarify what the feature is for
- **game-design-option-generation**: expand the solution space
- **game-design-five-options**: force explicit comparison across several candidate paths
- **game-design-roadblock-reframing**: get unstuck when one blocker dominates thinking
- **game-design-ideal-outcome-backcasting**: work backward from the best believable future
- **game-design-transformative-reuse**: adapt or recombine what already exists
- **game-design-feature-prioritization**: choose what to do now, later, or not at all

## Recommendation
Start with the narrowest skill that matches the user's real need. If several apply, use them in sequence rather than collapsing everything into one bloated answer.

---
name: game-design-option-generation
description: Generate multiple game design solution paths before committing to one direction. Use when a feature, live-ops idea, UX problem, economy issue, or design challenge feels too quickly narrowed, when a team is looping around one favorite answer, or when you need several credible options with tradeoffs instead of a single premature recommendation.
---

# Game Design Option Generation

Generate multiple credible ways forward before choosing one.

Use this skill to expand the solution space around a game design problem, feature pitch, or design goal. Keep the work practical. The aim is not random brainstorming. The aim is to produce several plausible options, clarify what makes them different, and expose tradeoffs early.

Read `references/family-conventions.md` when you need the shared conventions for this GROW-derived skill family.

## What to produce

Generate:
1. **Problem framing** - what needs solving
2. **Option set** - at least 3 credible solution paths
3. **Tradeoff summary** - player value, business value, cost, risk, strategic fit
4. **Recommendation** - which path is strongest and why

## Process

### 1. Frame the problem
Clarify:
- what outcome is desired
- what constraint or tension matters most
- what existing system context cannot be ignored

### 2. Generate multiple options
Always produce several options before deciding.

Use one or more of these lenses:
- **Five-options** - compare several existing ideas
- **Obstacle** - imagine the main blocker removed, then derive paths around it
- **Ideal outcome** - work backward from the best player-facing result
- **Transformative reuse** - adapt or extend what already exists
- **Outside-the-box** - deliberately include non-obvious options

### 3. Compare options
For each option, describe:
- summary
- strengths
- weaknesses
- likely player effect
- implementation burden
- strategic fit

### 4. Recommend a path
Choose the strongest option, or recommend a sequence such as test one now, hold one in reserve, discard the rest.

## Response structure

### Problem Framing
- ...

### Options
1. ...
2. ...
3. ...

### Tradeoffs
- Option A: ...
- Option B: ...
- Option C: ...

### Recommendation
- ...

## Fast mode
- What problem are we actually solving?
- What are 3-5 plausible ways to solve it?
- Which one is best now, and why?

## Working principle

Do not confuse the first decent answer with the best available direction.
FILE:references/family-conventions.md
# GROW-Derived Family Conventions

Use this family of skills as workflow tools for game design thinking and decision-making.

## Shared stance
- Prefer practical design movement over abstract theory.
- Keep outputs decision-oriented.
- Avoid pretending rough judgments are precise truths.
- When possible, distinguish player value, business value, implementation cost, risk, and strategic fit.
- Prefer several credible paths before commitment.
- Treat these skills as complements, not strict silos.

## How this skill family fits together
- **game-design-goal-framing**: clarify what the feature is for
- **game-design-option-generation**: expand the solution space
- **game-design-five-options**: force explicit comparison across several candidate paths
- **game-design-roadblock-reframing**: get unstuck when one blocker dominates thinking
- **game-design-ideal-outcome-backcasting**: work backward from the best believable future
- **game-design-transformative-reuse**: adapt or recombine what already exists
- **game-design-feature-prioritization**: choose what to do now, later, or not at all

## Recommendation
Start with the narrowest skill that matches the user's real need. If several apply, use them in sequence rather than collapsing everything into one bloated answer.

---
name: game-design-unknown-unknowns-prototyping
description: Detect unknown unknowns in game design and decide what to prototype before committing to production. Use when a feature concept feels promising but underdefined, when the team disagrees about the real design problem, when a mechanic seems interesting but the source of interest is unclear, when a concept risks premature production commitment, or when the team needs to determine what should be prototyped, in what order, and why.
---

# Game Design Unknown Unknowns Prototyping

Use prototyping to discover what actually needs to be learned.

This skill helps map uncertainty, identify likely blind spots, frame prototype questions, choose the cheapest useful prototype type, sequence tests, and define stop criteria. Keep the work practical and decision-oriented. Do not prototype to mimic production. Prototype to expose uncertainty.

## Core principle

**Preproduction handles known unknowns. Prototyping explores unknown unknowns.**

That distinction matters.
- **Known unknowns** are questions the team already knows to ask.
- **Unknown unknowns** are hidden design problems, emergent opportunities, and unexpected interactions that only become visible through testing.

Therefore:
- do not prototype to mimic production
- prototype to expose uncertainty
- prototype to discover what the game might actually be

## Knowledge quadrants

Use these four buckets to classify the state of understanding around a concept.

### 1. Known knowns
Things the team is already confident about.

### 2. Known unknowns
Things the team already knows it needs to answer.

### 3. Unknown knowns
Things the team implicitly knows but has not surfaced.

### 4. Unknown unknowns suspects
Things the team cannot yet name directly, but can infer are likely hiding in the concept.

Read `references/quadrants-and-hiding-places.md` when you need examples of each quadrant or a list of common hiding places for unknown unknowns.

## What to produce

Generate a prototyping plan with these outputs:

1. **Concept framing** - what the team thinks the idea is, and where it is still foggy
2. **Uncertainty map** - what is known, suspected, and unexplored
3. **Prototype questions** - what must be learned through making and testing
4. **Prototype sequence** - what order to test things in, and how each test informs the next
5. **Stop criteria** - when to stop exploring and move toward preproduction or production framing
6. **Decision record** - what was learned, what died, and what stronger direction emerged

## Process

### 1. Frame the design space

Clarify the current idea and its uncertainty surface.

Ask:
- What is the idea as currently understood?
- What part is conceptually exciting?
- What part is still vague?
- Which part is likely illusion rather than substance?
- Which assumptions are carrying the concept?
- What are we calling the feature today, and is that label prematurely narrowing thinking?

Write:
- **Current concept**
- **Why it seems promising**
- **Why it is still unclear**
- **Assumptions carrying the concept**

### 2. Build an uncertainty map

Map the concept using the four quadrants.

Use this format:

| Quadrant | Items |
|---|---|
| Known knowns | ... |
| Known unknowns | ... |
| Unknown knowns | ... |
| Unknown unknowns suspects | ... |

Important note: the last row is deliberately phrased as **unknown unknowns suspects**. True unknown unknowns cannot be listed directly. They can only be inferred from where hidden uncertainty is likely to live.

### 3. Convert fog into prototype questions

Turn uncertainty into learning objectives.

Rule: a prototype question should describe what must be learned, not what must be built.

Good prototype questions often sound like:
- Can players understand X without explanation?
- Does X create a stronger feeling of Y?
- What breaks first when X is layered with Z?
- Does X reduce friction or merely relocate it?
- Is the fun in A, or in the choice around A?
- What emergent behavior appears when players optimize X?
- What new problem appears after the obvious problem is removed?

Read `references/prototype-question-patterns.md` when you want more examples of strong versus weak prototype questions.

Write:
- **Prototype questions**

### 4. Identify the right prototype type

Choose the cheapest artifact that can expose the uncertainty.

Do not default to a playable digital prototype. Choose the medium based on the unknown.

Prototype types:
- **Experience prototype** - for feel, rhythm, pacing, emotional response
- **Interaction prototype** - for UI comprehension, decision speed, readability, input behavior
- **Systems prototype** - for simulation, economy, balance, loop interaction
- **Content pipeline prototype** - for production feasibility
- **Wizard-of-Oz or fake-backend prototype** - for testing behavior before full implementation

Use this format:

| Prototype Question | Best Prototype Type | Fidelity Needed | Why |
|---|---|---|---|

Read `references/prototype-types.md` when you need examples of what each type is best at exposing.

### 5. Sequence prototypes as a branching map

Order prototypes so each one clarifies the next one.

A prototype should do at least one of the following:
- kill an idea
- stabilize a baseline
- reveal a stronger direction
- expose a deeper question

Track prototype nodes using these state labels:
- **Dead end** - discard, but capture the lesson
- **Baseline** - stable enough to build on
- **Branch trigger** - revealed a new avenue worth testing
- **Production candidate** - sufficiently understood to move forward

Use this format:

| Prototype Node | Intended Learning | Result | Next Branch | State |
|---|---|---|---|---|

### 6. Detect hidden prototype needs

Ask what is not being prototyped because the team is overfocused on the visible feature.

Diagnostic prompts:
- Are we prototyping the visible feature instead of the invisible feeling?
- Are we testing implementation shape before testing player value?
- Are we arguing over solutions before defining the discovery question?
- Are we trying to answer multiple uncertainties with one bloated prototype?
- Are we protecting the original concept instead of letting the prototype challenge it?
- What would we test if we assumed the current pitch is wrong?
- Which part of the concept is most likely to transform into something else during prototyping?

Read `references/anti-patterns.md` for common prototyping failure modes and how to spot them.

### 7. Specify stop criteria

Define when to stop exploring and move into preproduction or production framing.

Stop when there is enough clarity on:
- core player interaction
- source of fun or value
- major design risks
- baseline UX understanding
- technical feasibility envelope
- a production-worthy direction

Do not wait for:
- complete certainty
- every edge case
- every tuning question answered
- every alternate branch explored

Write:
- **Stop criteria met when**
- **Still not clear enough if**

### 8. Produce a prototype brief

For each prototype, write a compact brief that ties the work to a decision.

Use this format:

**Prototype name**:  
**What this is trying to learn**:  
**Why this matters now**:  
**What is deliberately out of scope**:  
**Prototype type**:  
**Minimum fidelity needed**:  
**Success signal**:  
**Failure signal**:  
**Possible branches after test**:  

This keeps prototypes from becoming vague experiments with no decision consequence.

## Response structure

Use this structure unless the user asks for something else:

### Concept Framing
- ...

### Uncertainty Map
- Known knowns: ...
- Known unknowns: ...
- Unknown knowns: ...
- Unknown unknowns suspects: ...

### What Needs to Be Prototyped
1. ...
2. ...
3. ...

### Prototype Plan
- Prototype A: ...
- Prototype B: ...
- Prototype C: ...

### Stop Criteria
- ...

### Recommendation
- ...

## Fast mode

Use this quick pass when speed matters:
- What part of this idea is actually unclear?
- What might we be wrong about?
- What is the cheapest prototype that would expose that?
- What would we learn that changes the decision?
- What would tell us to stop prototyping and move on?

## Usage notes

This skill is especially useful for:
- new feature concepts with unclear player value
- UI layers that aggregate multiple demands or systems
- event structures that may shift player behavior in unexpected ways
- economy and production features where readability and pressure interact
- hybrid features that may become a different feature category once tested
- retention features where real value may emerge from cadence rather than content

When useful, combine this skill with a more explicit decision framework such as GROW:
- **Goal** defines the intended outcome
- **Reality** identifies current constraints
- **Unknown-unknowns prototyping** identifies what still must be discovered
- **Options / Will** can then be grounded in actual learning instead of speculation

## Working principle

**Prototyping is not the path to a product. It is the path to understanding what you are actually making.**

Do not ask only, "How do we build this?"
Ask first, "What do we not yet understand well enough to build responsibly?"
FILE:references/anti-patterns.md
# Prototyping Anti-Patterns

Use this file when a concept feels deceptively clear or when prototyping is drifting into waste.

## Common anti-patterns

### Polishing too early
The team invests in fidelity before learning the core thing that matters.

### Turning the prototype into a mini-product
The work starts mimicking production instead of exposing uncertainty.

### Bundling too many variables into one test
A bloated prototype makes it hard to tell what caused the result.

### Confusing feasibility with desirability
The team proves something can be built without learning whether it creates value.

### Mistaking familiarity for clarity
A concept feels obvious because it resembles something known, not because it is understood.

### Ignoring dead-end lessons
The team discards failed branches without capturing why they failed.

### Extending prototyping after meaningful clarity
The team keeps exploring because commitment feels riskier than learning.

## Diagnostic prompts

- Are we prototyping the visible feature instead of the invisible feeling?
- Are we testing implementation shape before testing player value?
- Are we arguing over solutions before defining the discovery question?
- Are we trying to answer multiple uncertainties with one bloated prototype?
- Are we protecting the original concept instead of letting the prototype challenge it?
- What would we test if we assumed the current pitch is wrong?
- Which part of the concept is most likely to transform into something else during prototyping?
FILE:references/prototype-question-patterns.md
# Prototype Question Patterns

Use prototype questions to describe what must be learned, not what must be built.

## Weak prototype targets

These describe deliverables instead of learning goals:
- build the new request board
- implement the event hub
- make a prototype of the crafting flow
- add a new urgency system

## Strong prototype questions

These name the uncertainty directly:
- determine whether aggregating requests creates strategic clarity or visual overload
- determine whether players interpret grouped demand as motivating or oppressive
- determine whether surfacing future demand changes crafting behavior in a useful way
- determine whether urgency and priority can be read in under 2 seconds

## Useful question patterns

- Can players understand X without explanation?
- Does X create a stronger feeling of Y?
- What breaks first when X is layered with Z?
- Does X reduce friction or merely relocate it?
- Is the fun in A, or in the choice around A?
- What emergent behavior appears when players optimize X?
- What new problem appears after the obvious problem is removed?

## Facilitation note

If the team keeps naming things to build instead of things to learn, rephrase every prototype target as:

"We are prototyping to learn whether..."
FILE:references/prototype-types.md
# Prototype Types

Choose the prototype medium based on the uncertainty, not habit.

## Experience prototype
Use when the unknown is about feel, rhythm, pacing, or emotional response.

Examples:
- input timing
- motion feel
- moment-to-moment tension
- flow state

## Interaction prototype
Use when the unknown is about UI comprehension, decision speed, readability, or input behavior.

Examples:
- menus
- overlays
- prioritization views
- request boards
- notification structures

## Systems prototype
Use when the unknown is about simulation, economy, balance, or loop interaction.

Examples:
- sinks and sources
- progression tension
- assignment cadence
- resource pressure

## Content pipeline prototype
Use when the unknown is about production feasibility.

Examples:
- asset turnaround speed
- level creation throughput
- localization complexity
- event content scalability

## Wizard-of-Oz or fake-backend prototype
Use when player behavior can be tested before full implementation.

Examples:
- manually curated offers
- scripted event prompts
- simulated opponent reactions
- hand-authored content standing in for automated systems
FILE:references/quadrants-and-hiding-places.md
# Quadrants and Hiding Places

## Knowledge quadrants

### Known knowns
Things the team is already confident about.

Examples:
- existing feature constraints
- established technical capability
- known player expectations
- current KPI baselines
- proven UI patterns

### Known unknowns
Things the team already knows it needs to answer.

Examples:
- implementation cost
- content production speed
- onboarding complexity
- economy balance ranges
- retention or monetization effect size

### Unknown knowns
Things the team implicitly knows but has not surfaced.

Examples:
- prior lessons from old features
- intuition from earlier prototypes
- tacit craft knowledge held by specialists
- assumptions hidden in language like "obviously" or "players will just get it"

### Unknown unknowns suspects
Things the team cannot directly name yet, but can infer are likely hiding in the concept.

Examples:
- an unexpected source of fun
- a control interaction that changes the whole concept
- a hidden frustration point
- a discovered fantasy that is stronger than the original pitch
- a mechanic interaction that redefines the feature category

## Common hiding places for unknown unknowns

Look especially at:
- control feel
- pacing and rhythm
- compound system interactions
- reward anticipation
- emotional fantasy
- readability under stress
- cognitive overload
- emergent optimization behavior
- social interpretation of the mechanic
- unintended dominant strategies

---
name: game-design-player-need-satisfaction-audit
description: Audit a game, feature, live-ops system, onboarding flow, progression loop, social feature, monetization flow, or return loop for player need satisfaction using Self-Determination Theory and the PENS lens. Use when evaluating whether a design is actually fun beyond surface KPIs, diagnosing weak retention or shallow engagement, comparing variants, identifying where a system denies autonomy, competence, or relatedness, or understanding whether a game feels emotionally nourishing or quietly depleting.
---

# Game Design Player Need Satisfaction Audit

Audit a design by asking whether it satisfies core psychological needs rather than merely driving activity.

Use this skill to examine whether a game, feature, or live-ops system supports autonomy, competence, and relatedness, and where it may be denying those needs instead. Keep the analysis practical and design-facing. Treat fun as need satisfaction rather than as a vague entertainment label.

## Core principle

People do not play games only because they are interactive or rewarding. They play because games satisfy core psychological needs. A feature can have solid metrics, clean progression, and monetization hooks, yet still feel emotionally weak if it fails to satisfy these needs.

## Need lenses

### 1. Autonomy
The need to feel like a causal agent of one's own actions.

In game terms: meaningful choice, ownership, self-directed action, strategic freedom, and perceived control.

### 2. Competence
The need to feel effective, capable, and progressively more skillful.

In game terms: clear goals, understandable feedback, mastery, successful execution, improvement, and meaningful progress.

### 3. Relatedness
The need to feel socially connected, embedded, recognized, compared, valued, or bonded with others.

In game terms: cooperation, rivalry, status visibility, shared progress, belonging, social ritual, and social meaning.

### 4. Benevolence (optional)
Use this supplementary lens when the design includes helping, gifting, nurturing, stewardship, caretaking, or contribution to others.

## What to produce

Generate an audit with these outputs:

1. **Need satisfaction profile** - how strongly the design satisfies autonomy, competence, and relatedness
2. **Need denial profile** - where the design frustrates or blocks those needs
3. **Mechanism map** - which systems create or reduce satisfaction
4. **Risk diagnosis** - where the design is emotionally hollow, coercive, or overly one-dimensional
5. **Improvement recommendations** - targeted design changes to improve need satisfaction

## Process

### 1. Define the audit target

Clarify exactly what is being audited.

Possible targets:
- full game
- core loop
- new feature
- onboarding
- event structure
- social system
- monetization flow
- return loop
- session opener

Write:
- **Audit target**
- **Player context**
- **Why this audit matters**

### 2. Map intended player experience

Describe what the design is supposed to make the player feel and do.

This step prevents theory from floating free of the actual experience.

Ask:
- What is the intended player fantasy?
- What actions define the loop?
- What are players choosing?
- What are they trying to master?
- Where are they encountering other people, directly or indirectly?
- What does success look like from the player's perspective?

Write:
- **Intended player experience**
- **Core actions**
- **Sources of progress**
- **Sources of social meaning**

### 3. Audit autonomy

Ask whether the design helps the player feel like an active agent rather than a passenger.

Signs of autonomy satisfaction:
- meaningful choices, not fake choices
- multiple valid paths or priorities
- flexible pacing or self-directed goals
- player expression of preference or playstyle
- guidance that supports choice rather than replacing it
- actions that feel intentional and consequential
- constraints that are understandable rather than arbitrary

Signs of autonomy denial:
- overly forced funnels
- constant interruption or coercion
- fake choice with one obviously correct option
- rigid pacing with little ownership
- recommendation systems that feel bossy
- decisions that do not materially matter
- excessive timers or blockers with no agency-preserving response

Ask:
- What meaningful choices does the player make?
- Can the player set their own short-term priorities?
- Does guidance preserve agency or replace it?
- Are there multiple viable ways to progress?
- Does the player feel ownership over success?
- Where does the system make the player feel trapped, railroaded, or manipulated?

Use this format:

| Autonomy Dimension | Evidence of Satisfaction | Evidence of Denial | Severity |
|---|---|---|---|

### 4. Audit competence

Ask whether the design helps the player feel effective, improving, and capable.

Signs of competence satisfaction:
- clear goals and immediate feedback
- understandable cause and effect
- actions produce visible results
- progression is legible
- player skill or understanding improves outcomes
- challenge is meaningful but not chaotic
- the system teaches without humiliating

Signs of competence denial:
- noisy or ambiguous feedback
- success feels random or disconnected from decisions
- actions fail for opaque reasons
- no sense of improvement or mastery
- friction overwhelms learning
- players cannot tell what good play looks like
- systems produce repeated confusion, blocked states, or dead-end effort

Ask:
- Does the player understand what they are trying to achieve?
- Is the result of action legible and satisfying?
- Can the player improve through practice, strategy, or understanding?
- Is there a clear bridge between effort and result?
- Are failure states fair and interpretable?
- Where does the design create frustration without learning?

Use this format:

| Competence Dimension | Evidence of Satisfaction | Evidence of Denial | Severity |
|---|---|---|---|

### 5. Audit relatedness

Ask whether the design makes the player feel socially connected, situated, or recognized.

Signs of relatedness satisfaction:
- meaningful club, guild, or social systems
- visible social comparison that feels motivating
- cooperation, gifting, helping, or mutual dependency
- rituals of return and shared participation
- recognition, identity, or status within a group
- ambient social presence, even if asynchronous
- emotional connection to characters, community, or shared world

Signs of relatedness denial:
- social systems are present but emotionally empty
- comparison is punishing rather than connective
- other players feel like abstract obstacles only
- no sense of belonging or shared culture
- social actions are transactional with no felt relationship
- players feel isolated even inside a nominally social feature

Ask:
- How does this design help the player feel part of a larger social matrix?
- What forms of recognition or comparison exist?
- Is there cooperation, competition, shared identity, or belonging?
- Are social features emotionally meaningful or just functional?
- Does the design create connection or merely visibility?
- Where does the feature feel socially sterile?

Use this format:

| Relatedness Dimension | Evidence of Satisfaction | Evidence of Denial | Severity |
|---|---|---|---|

### 6. Audit benevolence or contribution when relevant

Use this supplementary lens when the design lets players feel good by helping, nurturing, protecting, or contributing.

Relevant cases include:
- city care
- co-op support
- gifting
- club contribution
- stewardship systems
- pet or resident care
- restoration or rebuilding fantasies

Ask:
- Can the player improve something beyond themselves?
- Can they care for, help, or contribute to others?
- Does contribution feel meaningful or cosmetic?
- Is there emotional payoff in generosity or stewardship?

### 7. Build the need satisfaction profile

Summarize the overall shape of the experience.

Score each need from 1 to 5:
- **1** = strongly denied
- **2** = weak or inconsistent
- **3** = moderate
- **4** = strong
- **5** = central strength

Use this format:

| Need | Score | Why |
|---|---:|---|
| Autonomy | 1-5 | ... |
| Competence | 1-5 | ... |
| Relatedness | 1-5 | ... |
| Benevolence (optional) | 1-5 | ... |

Interpretation patterns:
- high autonomy, low competence -> expressive but confusing
- high competence, low autonomy -> polished but controlling
- high relatedness, low autonomy -> socially sticky but personally shallow
- high competence, low relatedness -> satisfying alone, weak community pull
- balanced strength across all three -> strongest candidate for durable engagement

### 8. Diagnose need denial and imbalance

Identify what is missing, what is overrepresented, and what failure shape is emerging.

Common failure shapes:

#### A. Spreadsheet fun
- competence signals are present
- autonomy is weak
- relatedness is weak
- the system is efficient but emotionally dry

#### B. Coercive retention
- progression exists
- constant nudging and timers deny autonomy
- competence is undermined by blockers
- players return from obligation rather than desire

#### C. Social shell
- clubs or leaderboards exist
- relatedness cues are visible but shallow
- there is little real belonging or identity

#### D. Pleasant but empty
- autonomy is present
- low challenge or poor feedback reduces competence
- interaction lacks a meaningful arc

#### E. High-pressure optimization trap
- competence exists for experts only
- autonomy narrows into one dominant strategy
- social comparison becomes discouraging

### 9. Convert findings into design actions

For each issue, specify:
- **Need affected**
- **Current problem**
- **Design cause**
- **Suggested change**
- **Expected emotional effect**

Examples:
- add more player-selectable priorities -> increases autonomy
- clarify action-result feedback -> increases competence
- add visible club contribution loops -> increases relatedness
- reduce forced interruptions -> reduces autonomy denial
- add progression bridges between systems -> strengthens competence and autonomy together

Use this format:

| Need | Problem | Suggested Change | Expected Effect |
|---|---|---|---|

### 10. Reuse the audit over time

Run this audit:
- during concepting
- after prototype reviews
- before greenlight
- after live launch
- when retention or sentiment drops
- when comparing AB variants

Do not treat this as a one-off theory exercise. It is most useful when repeatedly applied to major game systems.

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Intended Player Experience
- ...

### Autonomy
- Strengths: ...
- Weaknesses: ...

### Competence
- Strengths: ...
- Weaknesses: ...

### Relatedness
- Strengths: ...
- Weaknesses: ...

### Need Satisfaction Profile
- Autonomy: ...
- Competence: ...
- Relatedness: ...

### Risk Diagnosis
- ...

### Recommendations
1. ...
2. ...
3. ...

## Fast mode

Use this quick pass when speed matters:
- Where does the player experience meaningful choice?
- Where do they feel effective and improving?
- Where do they feel connected to others?
- Where does the design deny one of those needs?
- Which need is strongest, and which is weakest?
- What one change would most improve the weakest need?

## Usage notes

This audit is especially useful for:
- session opener flows
- city request systems
- season passes and event track progression
- club systems and wars
- trains and deliveries
- city-building fantasy versus optimization friction
- monetization touchpoints that may erode autonomy
- guidance systems that may help competence while harming autonomy

Common patterns to watch for:
- too much instruction can improve competence but reduce autonomy
- timers and blockers can motivate return but also create autonomy denial
- social systems can create relatedness cues without true belonging
- event layers can create progress but overload competence if feedback is fragmented

## Working principle

A successful game does not merely retain players. It repeatedly satisfies core psychological needs.

Use this skill when a design is performing mechanically but you need to understand whether it is emotionally nourishing or quietly depleting.