Stanislav Stankovic

---
name: game-design-player-perspective-reframe
description: Reframe a player's current situation to reveal new meaning, goals, roles, or playstyles without changing the underlying mechanics. Use when diagnosing stagnation, boredom, or mid/late-game disengagement; when designing re-engagement prompts, adaptive guidance, or dynamic missions; or when a player is technically able to continue but no longer sees the current state as interesting, valuable, or purposeful.
---

# Game Design Player Perspective Reframe

Reframe a player's current situation so the same game state can be interpreted through a more motivating lens.

Use this skill when the player is not blocked by a fundamentally broken system, but by a stale interpretation of what their situation means or what kind of play is currently available to them.

## Core principle

Sometimes the problem is not lack of content, but lack of meaning.

A player can have options available and still feel stuck because they are reading the current state through an exhausted frame: "I cannot grow," "I am behind," "nothing is happening," or "this part is just waiting." Reframing changes the interpretation of the state so a new kind of goal, role, or challenge becomes visible.

## What to produce

Generate:
1. **Current state summary** - what the player is doing, wanting, and feeling
2. **Stagnation diagnosis** - why the current frame is no longer working
3. **Reframe options** - alternative ways to interpret the current state
4. **Chosen reframe** - the strongest new lens
5. **Action hook** - immediate next objective or prompt
6. **Expected effect** - why the reframe may restore interest, agency, or momentum
7. **Use-case judgment** - whether reframing is actually the right intervention, or whether the underlying system instead needs fixing

## Process

### 1. Define the stuck state

Clarify:
- what the player is trying to do
- what they believe is the problem
- what the system state actually looks like
- what kind of disengagement is happening: boredom, frustration, aimlessness, repetition, self-comparison fatigue, etc.

Write:
- **Player state**
- **Current goal**
- **Why the current frame is failing**

### 2. Decide whether reframing is appropriate at all

Before generating reframes, check whether the problem is truly interpretive rather than structural.

Reframing is appropriate when:
- the player has meaningful options, but does not currently value or notice them
- the underlying systems are basically sound, but the player's current lens is exhausted
- the game can support alternate self-directed goals without pretending the state is healthier than it is
- the intervention is meant to extend or redirect engagement, not conceal a broken loop

Reframing is not the right primary move when:
- the system is actually opaque, unfair, or under-rewarding
- the player lacks real agency or feasible next steps
- the economy is over-constrained and the reframe would just romanticize waiting
- frustration is caused by balance, UX, matchmaking, or monetization abuse

If the issue is mostly structural, say so clearly and treat any reframe as secondary at best.

### 3. Diagnose the dominant stagnation pattern

Common patterns:
- **growth lock** - player only values expansion and cannot see value in consolidation
- **efficiency fatigue** - player is optimizing mechanically but no longer feels purpose
- **goal vacuum** - no compelling next objective is visible
- **identity exhaustion** - player has overidentified with one role or playstyle
- **failure fixation** - player reads current state only as a deficit or loss
- **content blindness** - systems are present but the player does not recognize them as meaningful play

### 4. Choose a reframe strategy

Use one or combine several:

#### Role reframe
Shift who the player is right now.
Examples:
- builder -> optimizer
- collector -> curator
- attacker -> steward
- grinder -> planner

#### Goal reframe
Shift what success means.
Examples:
- expansion -> refinement
- speed -> elegance
- raw power -> consistency
- completion -> experimentation

#### Constraint reframe
Turn a limitation into a challenge premise.
Examples:
- "What can you achieve with only your current tools?"
- "Can you solve this with one district / one deck / one weapon class?"

#### System reframe
Reveal another layer of meaning already present in the same mechanics.
Examples:
- "This is not just waiting; this is production planning."
- "This is not a content gap; it is a logistics puzzle."

#### Narrative reframe
Wrap the current state in story meaning.
Examples:
- recovery phase
- rebuilding chapter
- proving-ground moment
- specialist mission

#### Social reframe
Redefine the current state through comparison, contribution, or recognition.
Examples:
- show off efficiency
- mentor others
- attempt a community challenge
- compare style rather than speed

### 5. Generate multiple plausible reframes

Produce at least three candidate reframes before choosing one.

Each candidate should include:
- new interpretation
- why it fits the current state
- what kind of player it is most likely to help
- risk of backfiring

### 6. Select the best reframe

Pick the reframe most likely to:
- restore agency
- make the current state feel meaningful
- create an immediate next step
- fit the player's likely values
- avoid lying about a broken system

Important: do not use reframing to excuse an actually broken or abusive loop. If the system is fundamentally busted, say so.

### 7. Attach an action hook

The reframe must point to a concrete next move.

Examples:
- optimize output using only current buildings
- redesign one district around beauty instead of income
- complete a self-imposed low-resource challenge
- treat the next three sessions as a scouting-and-planning phase
- focus on one underused system and master it

Without an action hook, the reframe stays abstract and weak.

### 8. State the expected effect

The expected effect should be modest and believable.

Good targets:
- renewed curiosity
- restored short-term agency
- lower self-defeating frustration
- better recognition of alternate goals already present in the system
- a temporary bridge from stale play to fresher play

Bad targets:
- masking a broken progression wall
- making players accept exploitative friction
- pretending a starved content phase is secretly rich

### 9. State the use-case judgment

Conclude with a blunt judgment:
- **Strong fit for reframing**
- **Partial fit; system fixes matter more**
- **Weak fit; this is mostly a structural problem**

Say why.

Explain what the reframe is trying to change:
- restore curiosity
- reduce frustration by changing success criteria
- open a new playstyle identity
- create a short-term challenge layer
- transform waiting into anticipation or planning

## Response structure

### Current State Summary
- ...

### Stagnation Diagnosis
- ...

### Reframe Options
1. ...
2. ...
3. ...

### Chosen Reframe
- ...

### Action Hook
- ...

### Expected Effect
- ...

### Use-Case Judgment
- ...

## Fast mode

Use this quick pass when speed matters:
- what is the player currently trying to do?
- is the problem interpretive or structural?
- why does the current frame feel dead?
- what other role, goal, or lens could fit the same state?
- what should the player do immediately under that new frame?

## Working principle

A good reframe does not pretend the player's situation is different.
It makes a different and more useful truth visible inside the same situation.

---
name: game-design-player-values-mapper
description: Infer a player's underlying values and motivational priorities from behavior, then translate those into design implications. Use when designing personalization, segmentation, dynamic guidance, live-ops targeting, adaptive missions, re-engagement strategies, or feature prioritization; when behavior suggests that what players actually care about differs from what the design assumes; or when a team needs a behavior-first player profile rather than a demographic or archetype-only model.
---

# Game Design Player Values Mapper

Map observed player behavior to likely underlying value priorities, then use that map to infer what kinds of goals, rewards, content, or framing are most likely to resonate.

Use this skill when the team needs to understand not just what players do, but what those choices imply about what they care about.

## Core principle

Behavior is not random. It is preference made visible.

Players reveal their values through repetition, avoidance, investment, and attention. The goal is not to assign a rigid personality label, but to infer the motivational structure most likely driving current behavior and use that to improve design alignment.

## What to produce

Generate:
1. **Observed behavior summary** - what the player consistently does, ignores, and invests in
2. **Value map** - likely dominant, secondary, and weak values
3. **Confidence notes** - how strong or ambiguous each inference is
4. **Tensions or contradictions** - where behavior suggests mixed motives or blocked values
5. **Design implications** - what systems, content, messaging, goals, or monetization surfaces are likely aligned or misaligned
6. **Segment hypothesis** - what kind of player pattern this most resembles in practical design terms
7. **Recommendations** - what to emphasize, reframe, personalize, or stop pushing

## Value framework

Map behavior to these value dimensions:

- **Efficiency / Optimization**
- **Progression / Growth**
- **Aesthetics / Expression**
- **Collection / Completion**
- **Social Recognition / Status**
- **Experimentation / Discovery**
- **Narrative / Meaning**

You may add a clearly justified extra value if the case demands it, but do not bloat the framework casually.

## Process

### 1. Gather behavior signals

List concrete observed behaviors.

Possible sources:
- build patterns
- resource spending
- session frequency and duration
- event participation
- feature engagement
- purchase behavior
- social behavior
- what the player returns to repeatedly
- what the player ignores despite obvious rewards

Write:
- **Repeated behaviors**
- **Avoided behaviors**
- **Investment patterns**

### 2. Map behaviors to likely value signals

Translate behavior into value hypotheses.

Examples:
- min-maxing production chains -> Efficiency / Optimization
- constant upgrading and rushing unlocks -> Progression / Growth
- decorating, styling, curating loadouts -> Aesthetics / Expression
- chasing every item or badge -> Collection / Completion
- caring about ranks, cosmetics, visibility -> Social Recognition / Status
- trying odd builds or niche tools -> Experimentation / Discovery
- following lore, theme, faction identity, story arcs -> Narrative / Meaning

Important: many behaviors can map to more than one value. Do not overclaim certainty.

### 3. Weight the value profile

Do not force fake precision. The goal is a useful profile, not pseudo-scientific certainty.

Assign rough weight levels such as:
- High
- Medium
- Low

Or if needed:
- Dominant
- Secondary
- Weak
- Absent

Also note confidence:
- high confidence
- medium confidence
- low confidence

Use this format:

| Value | Weight | Confidence | Evidence |
|---|---|---|---|
| ... | ... | ... | ... |

### 4. Detect tensions and blocked values

Look for contradictions.

Examples:
- optimization-driven player engaging with decoration only because progression forces it
- status-seeking player avoiding competition because the failure cost feels humiliating
- progression-oriented player not spending because they distrust the offer structure
- discovery-oriented player repeating safe loops because experimentation is too punished

Ask:
- is this a real mixed-value profile?
- or is one value being blocked by system design?

### 5. Infer likely design alignment

Answer:
- what currently motivates this player most?
- what kinds of content or objectives will likely land well?
- what incentives are probably weak for this player?
- where is the game asking for a value the player does not strongly hold?
- what part of the experience is likely causing silent disengagement?
- what messaging, reward framing, or mission framing is most likely to resonate?

### 6. Form a practical segment hypothesis

Translate the value map into a practical design-facing player pattern.

Examples:
- efficiency-first optimizer
- completionist collector with moderate status drive
- expressive builder with weak progression urgency
- growth-focused grinder with low experimentation tolerance
- discovery-oriented tinkerer blocked by punishment

This is not meant to replace deeper persona work. It is a compact operational summary that helps teams act.

### 7. Recommend design actions

Translate the value map into actions such as:
- personalize mission framing
- surface a different kind of goal
- target events/offers more intelligently
- reduce pressure toward misaligned systems
- give better tools to the dominant value type
- redesign progression framing for the current segment
- change how rewards are explained, not just what rewards are given
- stop over-serving a secondary value while neglecting the dominant one

## Response structure

### Observed Behavior Summary
- ...

### Player Value Map
| Value | Weight | Confidence | Evidence |
|---|---|---|---|
| ... | ... | ... | ... |

### Dominant Values
- ...

### Secondary Values
- ...

### Tensions / Contradictions
- ...

### Segment Hypothesis
- ...

### Design Implications
- ...

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

## Fast mode

Use this quick pass when speed matters:
- what does the player repeatedly choose?
- what do they ignore?
- what does that imply they value?
- what is the strongest mismatch between the player's values and the game's current asks?
- what practical segment hypothesis best describes this player?
- what should the design emphasize or stop emphasizing for this player?

## Working principle

A player rarely says their values directly.
They leak them constantly through what they pursue, what they skip, and what they are willing to suffer for.

---
name: game-design-friction-journey-audit
description: Audit a game, feature flow, economy path, onboarding journey, progression chain, or live-ops loop for friction quality and friction accumulation. Use when diagnosing where players stall, disengage, churn, or feel overloaded; when distinguishing productive challenge from harmful friction; or when evaluating whether constraints, waiting, confusion, resource pressure, or multi-step dependencies are creating strategy, tension, frustration, or deadlock.
---

# Game Design Friction Journey Audit

Audit a design by mapping where friction appears across a player journey, what kind of friction it is, how it accumulates, and where useful challenge mutates into harmful drag.

Use this skill when a feature feels sticky in the wrong way, when progression seems to slow down for reasons players cannot articulate clearly, or when you need to separate meaningful challenge from accidental obstruction.

## Core principle

Not all friction is bad.

Some friction creates commitment, decision-making, anticipation, and mastery. Other friction creates confusion, paralysis, resentment, or churn. The job is not to remove all resistance. The job is to identify which resistance is doing design work and which is merely getting in the player's way.

## What to produce

Generate:
1. **Audit target** - what journey, loop, or feature is being reviewed
2. **Journey breakdown** - the major steps in player progression through the target flow
3. **Friction map** - where friction appears, what kind it is, and what causes it
4. **Accumulation analysis** - where multiple frictions stack into exhaustion or deadlock
5. **Diagnosis** - where the design shifts from meaningful challenge to harmful blockage
6. **Recommendations** - what to preserve, reduce, surface, reorder, or remove

## Process

### 1. Define the journey being audited

Clarify:
- what system or flow is under review
- what kind of player it applies to
- what stage of play it belongs to: FTUE, early game, mid-game, elder game, event loop, monetization path, social loop, etc.
- what desired player behavior the flow is supposed to support

Write:
- **Audit target**
- **Expected player goal**
- **Player context**

### 2. Break the journey into steps

Map the journey as a sequence of player-facing steps.

For each step, identify:
- player action
- player decision
- requirement or dependency
- feedback or reward
- what unlocks the next step

Keep steps coarse enough to be readable but concrete enough to locate friction.

### 3. Identify friction at each step

For each step, ask:
- what slows progress?
- what blocks progress?
- what creates uncertainty?
- what consumes time, attention, or resources?
- what forces tradeoffs or commitment?

Possible friction sources:
- resource scarcity
- dependency chains
- waiting and timers
- unclear affordances or goals
- UI or information opacity
- cognitive overload
- skill challenge
- social coordination burden
- random variance
- harsh penalty or recovery cost
- monetization pressure

### 4. Classify the friction

Classify each friction point as one of these:

#### Productive friction
Supports:
- decision-making
- planning
- anticipation
- mastery
- commitment
- strategic tradeoff
- emotional tension that feels fair and legible

#### Harmful friction
Produces:
- confusion
- dead time without meaning
- arbitrary blocking
- unreadable requirements
- overloaded task chains
- repeated admin work
- punishment without learning
- progress paralysis

#### Mixed friction
Useful in principle, but currently too strong, too opaque, too stacked, or too poorly timed.

Do not treat this as binary if it is not. Many systems are good ideas implemented at the wrong intensity.

### 5. Assess intensity and visibility

For each friction point, rate:
- **Intensity** - low / medium / high
- **Visibility** - obvious / partially hidden / opaque
- **Fairness feel** - fair / borderline / unfair-feeling

A friction can be mild but still dangerous if it is hidden. It can also be intense but acceptable if the player clearly understands it and sees why it exists.

### 6. Analyze friction accumulation

Look for stack effects.

Ask:
- where do several medium frictions compound into a high-friction moment?
- where are players forced to satisfy too many constraints at once?
- where does the flow ask for too much memory, too much waiting, or too many parallel tasks?
- where do repeated harmful frictions appear without enough reward, clarity, or release?

Common accumulation patterns:
- multiple resources plus timer plus low clarity
- complex chain plus weak feedback plus low inventory space
- repeated losses plus long recovery plus weak learning signal
- social obligation plus schedule pressure plus poor coordination tools

### 7. Find the breakpoints

Identify:
- where challenge turns into drag
- where strategy turns into opacity
- where anticipation turns into dead time
- where difficulty turns into helplessness
- where a healthy loop turns into churn risk

These are the key design breakpoints.

### 8. Diagnose the role of friction in the design

Answer:
- which friction points are core to the fantasy or mastery arc?
- which friction points only exist because of weak clarity, weak UX, poor pacing, or over-constrained economy?
- what friction is essential and should be protected?
- what friction is currently doing accidental damage?

### 9. Recommend design changes

For each major friction issue, specify:
- **Issue**
- **Why it hurts**
- **Keep / reduce / remove / surface / reorder / soften**
- **Expected effect**

Typical interventions:
- surface hidden requirements
- reduce simultaneous constraints
- improve feedback and goal clarity
- shorten dead-time without removing commitment
- preserve meaningful tradeoffs while removing admin burden
- stagger dependencies instead of stacking them all at once

## Response structure

### Audit Target
- ...

### Journey Breakdown
1. ...
2. ...
3. ...

### Friction Map
| Step | Friction Point | Type | Cause | Intensity | Visibility | Fairness Feel |
|---|---|---|---|---|---|---|
| ... | ... | ... | ... | ... | ... | ... |

### Accumulation Analysis
- ...

### Breakpoints
- ...

### Diagnosis
- ...

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

## Fast mode

Use this quick pass when speed matters:
- where does the player slow down or stop?
- is the friction creating strategy or confusion?
- is it fair and legible?
- what other frictions are stacking nearby?
- what should be preserved, softened, surfaced, or removed?

## Working principle

Good friction gives the player something meaningful to push against.
Bad friction makes the player wonder why they are pushing at all.

---
name: game-design-multiplayer-feature-audit
description: Audit a game, feature, live-ops layer, social system, or multiplayer concept for the quality and fit of its social design. Use when evaluating collaboration, competition, collaborate-to-compete structures, matchmaking, guilds/clubs, synchronous versus asynchronous play, realtime constraints, depth of social interaction, community formation, vanity/status systems, or how to add social play to a mostly single-player game.
---

# Game Design Multiplayer Feature Audit

Audit a design by asking what kind of social experience it is actually creating, for whom, at what coordination cost, and with what likely community effect.

Use this skill when a design has multiplayer or social ambitions and you need to judge whether those ambitions are coherent, motivating, scalable, and well matched to the core fantasy of the game.

## Core principle

Social design is not a checklist of features.

A leaderboard, guild, chat channel, or PvP mode does not automatically create meaningful social play. Strong multiplayer design aligns player motivation, time structure, coordination demands, visibility, and community purpose.

## What to produce

Generate:
1. **Audit target** - what is being reviewed and what kind of social experience it appears to aim for
2. **Social promise** - the core social fantasy or player promise
3. **Motivation map** - competition, collaboration, collaborate-to-compete, belonging, vanity/status, knowledge exchange
4. **Time and synchronization audit** - realtime, non-realtime, synchronous, asynchronous, or hybrid
5. **Social depth audit** - how deep the interaction really goes
6. **Community and status audit** - whether the system supports durable groups, identity, and readable prestige
7. **Risks / failure modes** - where the design is likely to break, flatten, or create friction
8. **Recommendations** - what to strengthen, stage, simplify, avoid, or postpone

## Process

### 1. Define the social promise

State in one or two sentences what the feature is socially promising.

Examples:
- compete for rank and status against peers
- cooperate with a small squad to solve hard encounters
- contribute to a group goal while still pursuing personal goals
- show off taste, city design, wealth, or mastery
- let solo players feel the presence of others without hard coordination

If the design appears to promise incompatible things at once, say so early.

Common tension examples:
- calm self-expression versus destructive PvP
- casual mobile bursts versus rigid appointment play
- individual authorship versus committee-driven collaboration

### 2. Map the motivation structure

Audit the feature across these motivation buckets:

- **Competition** - rivalry, ranking, domination, comparison
- **Collaboration** - helping, supporting, coordinating, solving together
- **Collaborate-to-compete** - teamwork in service of beating another team, club, faction, or cohort
- **Belonging** - identity, membership, shared rituals, durable group attachment
- **Vanity / status** - visible prestige, taste display, wealth display, proof of mastery
- **Knowledge exchange** - teaching, strategy sharing, build discussion, optimization culture

Do not just list them. Judge which ones are truly doing work and which are merely implied.

### 3. Check motivational fit

Use a Self-Determination-Theory-inspired check:

- **Autonomy** - does the player have choice of role, pace, route, or strategy?
- **Competence** - can the player demonstrate mastery, improvement, contribution, or skill?
- **Relatedness** - can the player meaningfully connect, compare, help, coordinate, or belong?

Flag fake-social systems that mostly create obligation, admin work, or shallow compliance.

Examples:
- a guild donation button may create duty without meaningful relatedness
- a giant anonymous global leaderboard may technically create comparison but fail emotionally
- a cosmetic showcase may create status only if others can actually see and decode it

### 4. Audit time model and synchronization demands

Classify the feature explicitly:

- **Realtime synchronous**
- **Non-realtime synchronous window**
- **Asynchronous competitive**
- **Asynchronous collaborative**
- **Hybrid**

Then ask:
- how long does a typical social interaction last?
- must players overlap in time?
- what happens if one player misses the window?
- does the audience/platform support this coordination burden?
- is the feature mobile-friendly, session-friendly, or appointment-heavy?

Call out time-model mismatch clearly. A socially appealing idea can still be wrong for the audience if it demands too much synchronization.

### 5. Audit depth of social interaction

Rate the design using this depth ladder:

1. **Awareness** - others exist
2. **Comparison** - scores, rankings, visible collections, ghosts, showcases
3. **Indirect exchange** - gifting, trading, donations, borrowing
4. **Communication** - chat, pings, negotiation, requests
5. **Coordination** - timing, role division, tactical cooperation
6. **Collective strategy** - shared plans, doctrine, adaptation, team optimization
7. **Community identity** - durable groups, leadership, rituals, norms, reputation, belonging

State where the feature sits now, where it wants to sit, and whether the gap is credible.

Do not assume deeper is always better. More depth usually means more friction, moderation burden, onboarding cost, and design risk.

### 6. Audit competition design

If the feature includes competition, evaluate:

- leaderboard scale
- intimacy of comparison group
- freshness of score movement
- reward brackets and goal density
- fairness and matchmaking logic
- anti-exploit / anti-smurf / anti-boost concerns
- visibility of rivals and stakes
- whether losing still feels legible and motivating

Prefer emotionally legible comparison over giant anonymous ranking walls.

Small groups, leagues, seasons, and visible rivals are often stronger than one global list.

### 7. Audit collaboration design

If the feature includes cooperation, evaluate:

- clarity of shared goal
- role differentiation
- visibility of contribution
- whether casual or weaker players can still help
- whether personal goals can also feed the group goal
- dependency risk if one player flakes or churns
- communication need versus communication tools provided

Strong collaborative systems often let players pursue personal goals that still contribute to a shared outcome.

### 8. Audit community formation

Ask whether the design supports durable social structure:

- clubs, clans, guilds, alliances, squads
- friend discovery and invitations
- reasons to stay in a group
- recurring cadence and rituals
- visible contribution and group memory
- discoverability of healthy groups
- lightweight leadership roles or responsibilities

Ask the blunt question:
**Why would a player bother joining or maintaining this group?**

If the answer is only chat access, habit, or raw rewards, call that out as thin.

### 9. Audit vanity and status

Evaluate the status layer through four checks:

1. **Visibility** - can other players see the signal?
2. **Legibility** - can they understand what it means?
3. **Desirability** - is it aspirational?
4. **Fairness** - what exactly is being signaled: skill, taste, effort, money, tenure, luck?

Common status surfaces:
- ranks and leagues
- trophies and seasonal records
- rare cosmetics
- city/base/avatar/profile display
- titles and badges
- featured placements and judged showcases

Vanity systems are weak when they are private, unreadable, or disconnected from any real social surface.

### 10. Audit fit for mostly single-player games

When the design adds social play to a mostly solo experience, ask:

- what player behaviors already suggest social demand?
- what social fantasy naturally fits the core loop?
- what part of the fantasy should remain personal and unshared?
- should the first social layer be comparison, exchange, clubs, judged showcases, or direct PvP?
- is the design trying to force deep collaboration onto a fantasy built around individual authorship or control?

Be skeptical of bolted-on realtime multiplayer when the core fantasy is solitary mastery, self-expression, or authorship.

A safer migration path often goes:
1. observe others
2. compare with others
3. exchange with others
4. group with others
5. collaborate to compete
6. only then add tightly synchronized modes if the audience proves it wants them

### 11. Diagnose failure patterns

Common failure shapes:
- **social wallpaper** - many social features, little actual social meaning
- **coordination overkill** - audience asked for more synchronization than it can sustain
- **status fog** - prestige exists but players cannot read or value it
- **guild shell** - groups exist but have no real purpose
- **comparison numbness** - ranks exist but movement feels emotionally meaningless
- **solo fantasy violation** - the social layer damages the core fantasy instead of extending it
- **high-friction collaboration** - teamwork exists but the cost of organizing it is too high
- **shallow relatedness** - players are adjacent, not meaningfully connected

### 12. Convert findings into actions

For each major issue, specify:
- **Issue**
- **Why it hurts**
- **What kind of player it hurts most**
- **Suggested change**
- **Expected effect**

## Response structure

### Audit Target
- ...

### Social Promise
- ...

### Motivation Map
- Competition: ...
- Collaboration: ...
- Collaborate-to-compete: ...
- Belonging: ...
- Vanity / status: ...
- Knowledge exchange: ...

### Time and Synchronization Audit
- ...

### Social Depth Audit
- Current depth: ...
- Intended depth: ...
- Gap: ...

### Community and Status Audit
- ...

### Risks / Failure Modes
1. ...
2. ...
3. ...

### Recommendations
- Do now: ...
- Do later: ...
- Avoid: ...

## Fast mode

Use this quick pass when speed matters:
- what social fantasy is this actually selling?
- is it mostly competition, collaboration, or collaborate-to-compete?
- does the time model fit the audience?
- how deep is the social interaction really?
- why would players stay in a group?
- what visible status or prestige does the system create?
- what is the single biggest mismatch or risk?

## References

Read these when useful:
- `references/social-design-dimensions.md` for the deeper multiplayer audit checklist and sharper prompts

## Working principle

Strong multiplayer design does not merely place players near each other.
It creates meaningful comparison, contribution, coordination, recognition, or belonging at a coordination cost the audience is actually willing to pay.

FILE:references/social-design-dimensions.md
# Social design dimensions

Use this file when the user wants a denser rubric, sharper prompts, or a more systematic multiplayer audit.

## 1. Motivation matrix

For each feature, score low / medium / high and justify briefly.

- **Competition** - compare, beat, rank above, dominate
- **Collaboration** - help, support, solve together
- **Collaborate-to-compete** - coordinate within a group to defeat another group or cohort
- **Belonging** - identity, attachment, membership, shared ritual
- **Status** - prestige others can read
- **Vanity** - taste, wealth, authorship, or style on display
- **Knowledge exchange** - guides, strategy sharing, doctrine, teaching

Ask:
- which motivation is actually carrying the feature?
- which is merely cosmetic?
- which player segment is most likely to care?

## 2. Time and coordination rubric

Check:
- minimum players needed
- overlap in time required or not required
- session length expectation
- latency sensitivity
- whether the feature is burst-friendly or appointment-heavy
- what happens when one participant misses a step
- whether the feature supports 2-minute, 10-minute, and 30-minute participation bands

Warning signs:
- mobile audience asked to coordinate like a raid team
- one absent player collapses the whole structure
- feature marketed as casual but behaves like shift work
- social reward requires too much scheduling overhead

## 3. Social depth prompts

Ask:
- are players merely visible to each other, or meaningfully affecting each other?
- can they exchange value?
- can they express intent?
- can they negotiate or request help?
- can they divide labor?
- can they build trust, reputation, or norms over time?
- can they admire, envy, or learn from each other?

## 4. Competition prompts

Evaluate:
- scale of comparison group
- freshness of movement on the board
- fairness of matchmaking or seeding
- reward ladder and aspiration structure
- whether top-end status is reachable, reset, or permanently locked away
- whether the format creates meaningful rivals
- whether failure teaches or only humiliates

Typical fixes:
- shrink comparison groups
- add leagues or brackets
- shorten round cadence
- increase score feedback frequency
- make immediate rivals more visible

## 5. Collaboration prompts

Evaluate:
- clarity of shared goal
- role differentiation
- contribution visibility
- tolerance for absences or churn
- whether weak/casual players can still help
- whether veterans can mentor newer players
- whether communication tools match the coordination problem

Typical fixes:
- let personal progress also feed group progress
- reduce exact coordination requirements
- show contribution clearly
- remove single points of failure

## 6. Community prompts

Check:
- onboarding into groups
- reasons to remain in a group
- rituals, cadence, recurring events
- group history, memory, or identity
- discoverability of good groups
- leadership roles, social hierarchy, governance
- moderation, abuse handling, conflict risk

Strong signs:
- players return because of the people, not only the reward
- groups produce stories, traditions, doctrine, or shared identity
- contribution is visible and socially acknowledged

## 7. Vanity and status prompts

Check whether the design supports:
- **taste display** - decoration, city/base layout, loadout curation, composition
- **mastery display** - difficult cosmetics, titles, ratings, trophies
- **tenure display** - season history, legacy badges, old-event proof
- **wealth display** - rare items, premium cosmetics, abundance signals
- **social proof** - likes, endorsements, featured placement, group rank

Failure modes:
- players cannot see the signal
- players see it but cannot decode it
- everything is monetized, so nothing means much
- status loops humiliate the majority without offering reachable aspiration

## 8. Single-player-to-social migration prompts

Use when a game is adding social layers after launch or onto a mostly solo concept.

Ask:
- what emergent social behavior already exists outside the game?
- what are players already comparing, sharing, trading, or showing off?
- what part of the fantasy is too personal to turn into committee play?
- is direct PvP actually needed?
- would judged showcases, leagues, exchange, or club goals fit better first?

Safer migration pattern:
1. awareness and visitation
2. comparison and judged display
3. exchange and trade
4. groups and identity
5. collaborate-to-compete
6. tightly synchronized modes only if proven necessary

---
name: game-design-zeigarnik-effect-audit
description: "Audit a game, feature, task system, quest flow, event track, puzzle chain, progression layer, or return loop through the lens of the Zeigarnik effect: the tension created by incomplete, interrupted, or unresolved tasks. Use when evaluating whether a design creates healthy return motivation through open loops, whether it leaves players with productive unfinished business, or whether it turns incompletion into anxiety, clutter, guilt, or manipulative pressure."
---

# Game Design Zeigarnik Effect Audit

Audit a design by asking how it uses unfinished business and whether that unfinishedness creates useful tension or just psychic clutter.

Use this skill when a feature depends on incomplete tasks, suspended goals, unresolved quests, unfinished collections, interrupted runs, dangling mysteries, near-complete progress bars, or other forms of cognitive open-loop tension. The goal is to evaluate whether the design creates healthy return pull, curiosity, and momentum, or whether it produces guilt, overwhelm, clutter, and coercive pressure.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

Unfinished things stick in the mind.

In games, that can be powerful. An incomplete task can create:
- return motivation
- curiosity
- anticipation
- desire for closure
- mental continuity between sessions

But open loops become toxic when they create:
- obligation without excitement
- clutter without priority
- anxiety without clarity
- guilt without meaningful choice
- manipulative pressure to return

The point is not merely to leave things unfinished. The point is to leave the right things unfinished in the right way.

## What to produce

Generate:
1. **Open-loop profile** - what unresolved elements the design leaves active in the player's mind
2. **Return-tension diagnosis** - whether incompletion creates healthy pull or unhealthy pressure
3. **Clarity and prioritization diagnosis** - whether the player knows what is unfinished and why it matters
4. **Clutter and coercion risks** - where open loops become noise, guilt, or manipulative burden
5. **Design actions** - what to sharpen, resolve, stage, reduce, or frame differently

## Process

### 1. Define the audit target
Clarify:
- what exact system, flow, or experience slice is being audited
- what unresolved elements matter most
- whether the concern is retention, curiosity, task load, or psychological pressure

Write:
- **Audit target**
- **Open-loop type**
- **Primary concern**

### 2. Identify the unresolved loops
Look for things like:
- incomplete quests
- partial event tracks
- nearly finished collections
- dangling narrative mysteries
- interrupted crafting or building goals
- unresolved social obligations
- suspended runs or puzzle attempts
- pending claim states
- visible near-misses

Ask:
- what remains unfinished?
- what keeps that unfinishedness mentally active?
- is the loop explicit, implied, or ambient?

### 3. Classify the kind of tension being created
Useful categories include:
- curiosity tension
- completion tension
- competence tension
- social obligation tension
- reward anticipation tension
- scarcity/FOMO tension
- guilt/maintenance tension

Not all tension is equally healthy.

### 4. Audit clarity and closure path
Ask:
- does the player understand what is unresolved?
- do they know how to resume or resolve it?
- is the next step obvious enough to act on?
- is there one clean open loop or a pile of competing ones?
- does the system preserve meaningful stopping points, or does it always leave the player hanging messily?

### 5. Diagnose healthy versus unhealthy open loops
Healthy open loops tend to be:
- legible
- meaningful
- self-directed
- motivating
- finite enough to imagine closure

Unhealthy open loops tend to be:
- noisy
- coercive
- low-value
- ambiguous
- too numerous
- attached to shame or maintenance burden

Ask:
- does the player return because they want closure, or because they feel nagged?
- is the unfinishedness energizing or depleting?
- is the pressure chosen or imposed?

### 6. Check interaction with session structure
Ask:
- does the system give players safe stopping points?
- does it create a clear "one more thing" pull?
- does it overload session endings with too many unresolved hooks?
- does it preserve continuity between sessions without creating dread?

This is especially important for retention design and return loops.

### 7. Diagnose Zeigarnik failure patterns
Look for:
- too many simultaneous unfinished tasks
- near-completion bait with weak actual payoff
- open loops that matter only because the UI keeps nagging about them
- unresolved states with poor re-entry clarity
- social obligations that convert return into guilt
- cliffhangers without enough meaning to justify the tension
- retention loops that feel manipulative rather than naturally compelling

### 8. Check audience sensitivity
Ask whether:
- completionists are energized while casual players are overwhelmed
- new players feel buried under unresolved systems
- lapsed players return to a wall of unfinished business and bounce
- high-engagement players enjoy layered open loops that would suffocate lighter audiences

### 9. Convert findings into design changes
For each issue, specify:
- **Open-loop problem**
- **Why it creates the wrong kind of tension**
- **Suggested change**
- **Expected effect on return motivation or psychological load**

Examples:
- reduce simultaneous unfinished objectives -> lowers clutter and increases focus
- improve resume clarity -> turns vague guilt into actionable momentum
- sharpen payoff framing -> makes incompletion feel worth resolving
- add cleaner stopping points -> preserves return tension without making the session feel messy
- reduce nagging visibility for low-value loops -> lowers manipulative pressure

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Open-Loop Profile
- ...

### Tension Type and Quality
- ...

### Clarity and Resume Path
- ...

### Clutter and Coercion Risks
- ...

### Audience Sensitivity
- ...

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

### Minimal Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- What is being left unfinished?
- Does that create curiosity, momentum, guilt, or clutter?
- Does the player know how to resume it?
- Are there too many open loops at once?
- What one change would make the unfinished tension healthier?

## Usage notes

This audit is especially useful for:
- quest logs
- event tracks
- collection systems
- cliffhanger-driven retention loops
- city-building and crafting goals
- return-player re-entry
- social obligation systems
- progression dashboards
- puzzle chains and interrupted runs

Common patterns to watch for:
- many retention systems misuse open loops and create obligation instead of desire
- incomplete tasks are powerful only when they are legible and meaningful
- too many open loops destroy the benefit of any single one
- a strong unresolved hook can improve return motivation, but a junk drawer of unresolved hooks kills it
- if the player leaves thinking "I should go back," that may be good; if they leave thinking "ugh, I have chores waiting," that is not

## Working principle

Unfinishedness is a tool, not a virtue.

Use this skill to test whether the design leaves players with compelling momentum or just a backpack full of psychological clutter.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-peak-end-audit
description: Audit a game, feature, session, level, event, onboarding flow, reward sequence, or return-player experience through the lens of the peak-end rule. Use when evaluating which moments players are most likely to remember, whether the emotional high points are strong enough, whether endings, exits, and completions leave the right aftertaste, or why an experience with decent average quality is still remembered as flat, frustrating, or unexpectedly great.
---

# Game Design Peak-End Audit

Audit a design by asking which moments dominate memory and whether the experience earns the memory it leaves behind.

Use this skill when the important question is not just how the experience feels moment to moment, but how players will remember it afterward. The goal is to identify the emotional peaks, the ending shape, and the aftertaste that determine whether a session, level, feature, event, or sequence is remembered as exciting, exhausting, disappointing, triumphant, or forgettable.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

Players do not remember an experience as an average of every second they lived through.

They disproportionately remember:
- the strongest emotional peaks
- the ending
- the story those moments imply afterward

That means a design with decent average quality can still be remembered badly if:
- its emotional peaks are weak
- its worst spike dominates memory
- its ending sours the whole experience

And a rougher experience can still land well if:
- its peak is strong and meaningful
- its ending resolves cleanly
- the memory closes with satisfaction, momentum, relief, or anticipation

## What to produce

Generate:
1. **Peak-end profile** - the strongest peaks, the ending shape, and the likely remembered summary
2. **Memory dominance diagnosis** - which moments will overshadow the rest of the experience
3. **Ending-quality diagnosis** - whether the closing moments strengthen or poison the memory
4. **Experience-shape risks** - where the design is setting itself up to be remembered for the wrong thing
5. **Design actions** - what to amplify, soften, reorder, frame, or close differently

## Process

### 1. Define the audit target
Clarify:
- what exact experience slice is being audited
- where it begins and ends from the player's point of view
- what player segment matters most

Write:
- **Audit target**
- **Experience window**
- **Primary player segment**

### 2. Map the emotional shape over time
Break the experience into phases and ask:
- where does emotional intensity rise?
- where does it sag?
- where does frustration spike?
- where does satisfaction spike?
- what is the final emotional note?

Do not settle for generic labels like "good pacing." Name the moments.

### 3. Identify positive and negative peaks
Look for the moments most likely to become the remembered highlight or remembered wound.

Examples:
- first big win
- dramatic comeback
- painful difficulty spike
- surprising reveal
- humiliating loss
- beautiful payoff moment
- reward opening high
- last-minute collapse

For each peak, ask:
- how intense is it?
- how clear is it?
- does it support the intended fantasy?
- is it the thing you actually want remembered?

### 4. Audit the ending
The ending may be:
- session close
- boss resolution
- reward-claim sequence
- level completion
- event wrap-up
- return-to-hub state
- defeat screen and immediate aftermath

Ask:
- what emotion does the player leave with?
- does the ending frame the previous experience positively or negatively?
- does it create closure, momentum, relief, excitement, emptiness, or irritation?
- does it respect the effort that preceded it?

### 5. Determine the likely remembered story
Translate the shape into the sentence the player is likely to remember later.

Examples:
- "That run had one incredible clutch ending"
- "The fight was fine, but the ending reward felt pathetic"
- "That event was mostly chores and then it just sort of stopped"
- "The level was hard, but the payoff made it worth it"

If the remembered sentence is bad, average quality elsewhere may not save the experience.

### 6. Diagnose peak-end failure patterns
Look for:
- strong negative spike dominating weak positives
- flat experience with no memorable high
- rewarding middle but deflating ending
- emotionally strong ending attached to a fantasy mismatch
- punishing final note after meaningful progress
- reward ceremony too weak for the effort invested
- admin or UI sludge contaminating the exit

### 7. Check segment differences
Ask whether:
- new players experience the worst peak where veterans experience the best one
- one audience sees relief while another sees boredom
- the ending hits differently depending on skill, investment, or outcome state

### 8. Convert findings into design changes
For each issue, specify:
- **Peak-end problem**
- **Why it will dominate memory**
- **Suggested change**
- **Expected effect on remembered experience**

Examples:
- strengthen the success payoff -> improves remembered value of the whole sequence
- remove admin friction at the end -> prevents sour aftertaste
- soften one brutal late spike -> stops the whole feature being remembered as hostile
- reorder the reward reveal -> lets the ending carry more emotional weight

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Peak-End Profile
- ...

### Positive Peaks
- ...

### Negative Peaks
- ...

### Ending Quality
- ...

### Likely Remembered Story
- ...

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

### Minimal Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- What is the strongest moment?
- What is the worst moment?
- What is the final emotional note?
- Which of those will dominate memory?
- What one change would most improve the remembered aftertaste?

## Usage notes

This audit is especially useful for:
- onboarding and first-session retention
- boss fights and level endings
- event wrap-ups
- reward ceremonies and chest openings
- return-player flows
- session exits and stop points
- defeat aftermaths
- premium or high-effort experiences where memory quality really matters

Common patterns to watch for:
- many systems are fine in aggregate but remembered badly because the ending is weak
- a single ugly late frustration spike can poison an otherwise decent feature
- reward structure often over-focuses on average yield and under-focuses on emotional ending quality
- if the strongest remembered moment is the wrong one, the design has a memory-shape problem
- closure and anticipation are both valid endings, but aimlessness is not

## Working principle

The experience players remember is often not the one designers think they shipped.

Use this skill to identify which moments actually own the memory and whether that memory helps or hurts the design.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-thinking-fast-and-slow-audit
description: Audit a game, feature, combat system, economy loop, onboarding flow, puzzle, UI, or design proposal through the lens of fast versus slow thinking inspired by Thinking, Fast and Slow. Use when evaluating whether a design relies on rapid intuitive judgment or deliberate analytical reasoning, whether the intended mode matches the actual demand, where cognitive overload or under-stimulation appears, or how badly the design handles shifts between instinctive and reflective play.
---

# Game Design Thinking Fast and Slow Audit

Audit a design by asking what kind of thinking it demands from the player, when, and whether that demand is appropriate.

Use this skill when a proposal sounds good in the abstract but may be mismatched to the kind of cognition it actually requires. The goal is to identify where the design leans on fast, intuitive, low-deliberation processing versus slow, analytical, effortful reasoning, and where the transition between those modes becomes awkward, exhausting, misleading, or strategically dead.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

Players do not think in one uniform way.

Some situations ask for:
- rapid pattern recognition
- instinctive response
- snap prioritization
- fluent repetition

Other situations ask for:
- deliberate comparison
- explicit planning
- rule-based reasoning
- careful tradeoff evaluation

Neither mode is automatically better. The important questions are:
- which mode the design is asking for
- whether that suits the fantasy and pacing
- whether the player is being supported properly
- whether the handoff between modes is clean

## Fast and slow lenses

### Fast-mode thinking
Typical qualities:
- intuitive
- automatic
- rapid
- pattern-based
- low-deliberation
- emotionally immediate

In game terms, this often appears in:
- action combat
- dodging, aiming, timing, rhythm
- snap tactical prioritization
- recognition of familiar board states
- habitual session actions
- high-tempo moment-to-moment play

### Slow-mode thinking
Typical qualities:
- reflective
- effortful
- explicit
- comparative
- planning-heavy
- cognitively expensive

In game terms, this often appears in:
- deckbuilding and loadout decisions
- long-horizon economy planning
- puzzle decomposition
- route planning
- team composition
- optimization and meta decisions

## What to produce

Generate:
1. **Thinking-mode profile** - whether the design primarily demands fast thinking, slow thinking, or a layered mix
2. **Mode-fit diagnosis** - whether the required thinking mode matches the fantasy, pacing, and audience
3. **Transition diagnosis** - where the design shifts between fast and slow modes, and whether those handoffs work
4. **Cognitive risk map** - where the design creates overload, confusion, autopilot deadness, or false depth
5. **Design actions** - what to simplify, deepen, pace differently, surface more clearly, or separate

## Process

### 1. Define the audit target
Clarify:
- what exact game, feature, loop, or proposal is being audited
- whether the audit is for minute-to-minute play, meta systems, onboarding, or the full experience
- what player segment matters most

Write:
- **Audit target**
- **Scope**
- **Primary player segment**

### 2. Identify the dominant thinking demand
Ask:
- what does the player have to notice, decide, remember, and prioritize?
- how much time do they have to do it?
- are they reacting from fluency or stopping to reason explicitly?
- what mistakes come from speed versus what mistakes come from misunderstanding?

Classify the dominant demand as:
- mostly fast-mode
- mostly slow-mode
- mixed, with one dominant
- deeply hybrid

### 3. Map where each mode appears
Break the experience into phases or layers such as:
- onboarding
- moment-to-moment play
- build/loadout decisions
- economy or progression planning
- social/coordination layer
- end-of-run reflection

For each phase, identify:
- **Thinking mode demanded**
- **Why that mode is required**
- **Whether the player has enough support**

Use this format:

| Phase or system | Thinking mode | Demand level | Notes |
|---|---|---|---|
| ... | Fast / Slow / Mixed | Low / Med / High | ... |

### 4. Check fit between mode and fantasy
Ask:
- does the cognitive demand support the intended fantasy?
- is the game claiming flow, mastery, panic, elegance, command, coziness, or brilliance?
- does the required thinking mode reinforce that promise or betray it?

Examples:
- a fantasy of fluid sword mastery should not constantly hard-stop into spreadsheet reasoning
- a fantasy of careful grand strategy should not bury important choices inside twitch pressure
- a cozy planning game can tolerate slow thought, but not exhausting ambiguity

### 5. Diagnose fast-mode failure patterns
Look for:
- reaction demands too fast for the available clarity
- hidden information inside high-speed play
- too many simultaneous priorities
- snap judgments punished by information the player could not reasonably process
- UI that slows recognition instead of supporting it
- panic without readable action value

### 6. Diagnose slow-mode failure patterns
Look for:
- analysis burden too high for the payoff
- false complexity with obvious dominant answers
- too many variables to compare meaningfully
- long planning phases that are cognitively costly but emotionally flat
- systems that imply deep strategy but resolve shallowly
- excessive memory burden or bookkeeping

### 7. Diagnose transition failures between modes
This is often where designs get ugly.

Look for:
- abrupt switches from high-speed execution to deep planning without recovery time
- long slow-mode interruptions that kill fast-mode momentum
- fast-mode punishment for choices made in poorly supported slow-mode spaces
- slow-mode systems whose consequences only appear in frantic real-time moments
- a requirement to do deep reasoning under time pressure when the interface does not support it

Ask:
- where does the player shift modes?
- is the shift clean, intentional, and well-signaled?
- does the game give enough time, framing, and UI support for the new mode?

### 8. Identify audience mismatch and expertise effects
Ask:
- does this design feel intuitive to experts but exhausting to new players?
- does it ask casual players for tournament-level reasoning?
- does it flatten expert depth into autopilot?
- does the intended audience actually want this blend of cognition?

A system can be good for one audience and terrible for another because of thinking-mode mismatch alone.

### 9. Convert findings into design changes
For each major issue, specify:
- **Thinking-mode problem**
- **Why it hurts the experience**
- **Suggested change**
- **Expected effect**

Examples:
- reduce simultaneous fast-mode demands -> improves readability and decision confidence
- move some choices out of real-time pressure -> supports better slow-mode reasoning
- compress false-complexity planning layers -> preserves depth while reducing fatigue
- add clearer state framing before mode shifts -> reduces cognitive whiplash

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Thinking-Mode Profile
- ...

### Fast-Mode Demands
- ...

### Slow-Mode Demands
- ...

### Transition and Handoff Issues
- ...

### Audience and Expertise Fit
- ...

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

### Minimal Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- Is this mainly asking for instinctive play or analytical play?
- Does that fit the fantasy and pacing?
- Where is the worst mismatch?
- Where does the player switch modes?
- What one change would most improve the cognitive fit?

## Usage notes

This audit is especially useful for:
- action/strategy hybrids
- real-time systems with heavy pre-planning
- economy layers attached to fast gameplay
- onboarding for cognitively demanding games
- puzzles embedded inside otherwise reactive experiences
- proposal reviews where the cognitive demand is still fuzzy
- UI-heavy systems that may be hiding slow thought inside supposed fast play

Common patterns to watch for:
- many proposals accidentally ask for more slow thinking than their fantasy can sustain
- some designs confuse time pressure with depth
- some planning layers create the appearance of strategy without meaningful choice
- many frustrating systems are really bad handoffs between fast and slow modes
- expert fluency can hide a beginner-facing cognitive disaster

## Working principle

A strong design does not just ask the player to think. It asks them to think in the right way, at the right time, with the right support.

Use this skill to identify whether the proposal's cognitive demands are elegant, mismatched, exhausting, or fake-deep.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-failure-loop-audit
description: "Audit a game, feature, encounter structure, roguelite run, puzzle sequence, onboarding path, or progression gate through the lens of its failure loop: what happens after the player fails, what they learn, what they lose, and why they would or would not try again. Use when diagnosing whether failure teaches, motivates, stalls, humiliates, exhausts, or ejects the player, or when tuning punishment, retry structure, and post-failure recovery."
---

# Game Design Failure Loop Audit

Audit what the game does after the player fails, and whether that loop produces learning, motivation, and retry energy instead of confusion, resentment, or collapse.

Use this skill when a design includes repeated failure states and the real question is not merely "is failure possible" but "what does failure do to the player over time?" The goal is to evaluate what the player loses, what they understand, what they retain, how fast they re-enter, and whether the failure loop makes them want another attempt.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

A good failure loop does not just punish. It converts defeat into renewed intention.

A strong failure loop usually provides:
- readable cause of failure
- meaningful lesson or hypothesis for next attempt
- tolerable cost relative to clarity
- manageable re-entry friction
- emotional permission to try again

A bad failure loop produces:
- confusion without learning
- punishment without agency
- downtime without anticipation
- repetition without adaptation
- shame, fatigue, or helplessness

## What to produce

Generate:
1. **Failure loop summary** - the current structure from failure to re-entry
2. **Loss-learning-retry analysis** - what the player loses, learns, and does next
3. **Friction diagnosis** - where punishment, delay, opacity, or humiliation break the loop
4. **Motivation diagnosis** - why players will retry, hesitate, or quit
5. **Design implications** - what to tune in cost, clarity, pacing, recovery, or support

## Process

### 1. Define the audit target
Clarify:
- what exact failure state or loop is being audited
- what player segment is most affected
- whether the focus is early churn, midgame frustration, endgame mastery, or broad retention

Write:
- **Audit target**
- **Player segment**
- **Failure context**

### 2. Reconstruct the full failure loop
Map the sequence:
- fail
- receive feedback
- pay consequence
- recover or reset
- prepare again
- retry or abandon

Ask:
- What happens immediately after failure?
- What is the player told or shown?
- What is lost?
- What remains?
- How long until the next meaningful attempt?
- What emotional state is the player likely in by then?

### 3. Audit loss, learning, and retention
Evaluate:
- what resources, progress, time, status, or opportunity are lost
- what information or understanding is gained
- what progression, meta-progress, or unlocked knowledge is retained
- whether the player can form a better next-attempt plan

Use this format:

| Dimension | Current state | Effect on retry motivation |
|---|---|---|
| Loss | ... | ... |
| Learning | ... | ... |
| Retention | ... | ... |
| Re-entry speed | ... | ... |

### 4. Diagnose re-entry friction
Look for:
- long dead time before the next real attempt
- tedious setup or replay of solved content
- unclear recovery path
- punishment that exceeds the educational value of the failure
- restart structures that encourage resignation rather than iteration

Ask:
- Is the retry fast enough?
- Is the player replaying meaningful challenge or just chores?
- Does the recovery path preserve tension or drain it?

### 5. Diagnose emotional effect
Check whether the failure loop tends to create:
- determination
- curiosity
- annoyance
- humiliation
- dread
- learned helplessness
- numb repetition

Name the most likely felt response and why.

### 6. Check fairness and attribution inside failure
Ask:
- does the player understand why they failed?
- does the punishment feel deserved?
- does the loop preserve a sense of control?
- does repeated failure harden into external blame?

If needed, call out connections to attribution, flow, or fairness problems without fully re-running those audits.

### 7. Identify failure-loop archetypes
Useful patterns include:
- **learning loop** - fast retry, high clarity, strong adaptation
- **grindback loop** - too much rebuild between real attempts
- **shame loop** - public or ego-threatening failure with weak learning
- **attrition loop** - death by repeated low-grade exhaustion
- **helpless loop** - repeated failure without better hypotheses
- **mastery loop** - hard punishment justified by high clarity and strong growth

Classify the current loop and say whether that shape suits the game.

### 8. Convert findings into design changes
For each issue, specify:
- **Failure-loop problem**
- **Why it hurts retry willingness**
- **Suggested change**
- **Expected effect on learning and motivation**

Examples:
- unclear death cause -> improve post-failure feedback and telegraphing
- long rebuild before retry -> shorten setup or preserve more state
- punishment too severe for early game -> soften cost during learning phases
- nothing learned from failure -> increase legibility or give comparative feedback

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Failure Loop Summary
- ...

### Loss, Learning, and Retention
- ...

### Re-entry Friction
- ...

### Emotional Effect
- ...

### Failure Loop Type
- ...

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

### Minimal Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- What happens right after failure?
- What does the player lose?
- What do they learn?
- How fast can they make a better next attempt?
- What one change would most improve retry willingness?

## Usage notes

This audit is especially useful for:
- boss retries
- roguelite runs
- puzzle resets
- stealth mission failure
- onboarding deaths
- challenge events
- progression gates
- harsh economy setbacks
- difficult action-combat loops

Common patterns to watch for:
- many games punish more than they teach
- retry friction is often more damaging than raw difficulty
- harsh failure can work if clarity and re-entry speed are strong
- meta-progression can rescue a hard failure loop, but cannot fully compensate for opaque failure
- if the player dreads the retry more than the challenge itself, the loop is probably broken

## Working principle

Failure should create a better next attempt, not just a worse mood.

Use this skill to test whether the design turns defeat into momentum or just burns player trust and energy.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-core-loop-extractor
description: Extract the actual core loop from a game, feature set, or pitch based on repeated player actions, feedback, rewards, and renewed motivation. Use when a team can list mechanics but cannot clearly articulate the repeatable loop that drives engagement, when a pitch sounds like disconnected features, when a design document lacks loop clarity, or when you need to test whether the claimed loop is coherent, rewarding, and structurally complete.
---

# Game Design Core Loop Extractor

Extract the actual repeatable loop that drives the experience, not a decorative feature list pretending to be structure.

Use this skill when a team can describe mechanics, systems, and content, but not the recurring action-feedback-motivation cycle that keeps the game alive. The job is to identify what the player repeatedly does, what the game gives back, why the player wants to do it again, and where the loop is broken, bloated, or fake.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

A core loop is not just a sequence of actions. It is a repeatable motivational circuit.

A useful loop definition identifies:
- what the player does
- what the game returns
- what state changes as a result
- why the player wants to re-enter the loop

If the loop cannot explain why the player comes back for another cycle, it is incomplete.

## What to produce

Generate:
1. **Extracted core loop** - the clearest repeatable loop implied by the design
2. **Loop step breakdown** - the key stages in order
3. **Loop drivers** - what reward, pressure, tension, or fantasy pulls the player back in
4. **Loop breaks and dead steps** - where the loop is weak, bloated, confusing, or non-motivating
5. **Design implications** - what to simplify, strengthen, cut, or separate

## Process

### 1. Define the extraction target
Clarify:
- what exact game, feature set, or slice is being analyzed
- whether you are extracting the top-level game loop or a sub-loop
- whether a claimed loop already exists in the documentation

Write:
- **Extraction target**
- **Loop scope**
- **Claimed loop if any**

### 2. Identify the repeated player cycle
Ask:
- What does the player do over and over?
- What starts the cycle?
- What ends one cycle and begins the next?
- What resource, state, knowledge, or opportunity changes each time?

Look for actual recurrence, not one-time setup or occasional side systems.

### 3. Break the loop into action, feedback, reward, and renewed intent
For each stage, identify:
- **Player action**
- **Game response**
- **Reward or consequence**
- **Reason to continue**

Useful questions:
- What is the player's immediate objective?
- What result does the game return?
- What makes the next cycle attractive or necessary?
- Where does tension accumulate or release?

### 4. Distinguish core loop from support systems
Separate:
- the actual core loop
- progression loops
- economy loops
- meta loops
- social loops
- retention wrappers

A design often has many loops. Do not confuse scaffolding with the main engine.

Ask:
- If optional layers vanished, what loop would still define the game minute to minute?
- Which systems amplify the loop versus merely decorate it?

### 5. Test the loop for motivational completeness
Check whether the loop contains:
- clear initiation
- meaningful action
- readable feedback
- satisfying reward or consequence
- a genuine reason to repeat

Common failure signs:
- one or more steps are vague
- reward does not materially matter
- repetition exists without renewed motivation
- the loop is really several disconnected chains awkwardly stapled together
- the loop is too long to feel cyclical

### 6. Identify dead steps, bloat, and false loops
Look for:
- steps that do not change player state meaningfully
- chores inserted between meaningful beats
- feedback that is too weak to reinforce repetition
- loops that are structurally present but emotionally flat
- claimed loops that are really just content progression, not recurrence

### 7. Write the extracted loop clearly
Prefer a concise format such as:
- **Observe -> choose -> act -> resolve -> gain -> re-enter**
or
- **Explore -> fight -> earn -> upgrade -> explore again**

Then explain why this loop has pull.

### 8. Convert the loop into design implications
For each important part of the loop, specify:
- **Loop step**
- **Current strength or weakness**
- **What to change**
- **Expected effect on repeat engagement**

Examples:
- weak reward read -> improve feedback and clearer state change
- bloated transition step -> shorten or remove the chore layer
- no renewed tension -> add scarcity, discovery, escalation, or strategic consequence

## Response structure

Use this structure unless the user asks for something else:

### Extraction Target
- ...

### Extracted Core Loop
- ...

### Loop Step Breakdown
- ...

### Loop Drivers
- ...

### Loop Breaks and Dead Steps
- ...

### Design Implications
1. ...
2. ...
3. ...

### Minimal Loop Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- What does the player repeat most often?
- What reward or state change closes the loop?
- Why does the player want another cycle?
- Which step is dead weight?
- What one change would make the loop cleaner or more compelling?

## Usage notes

This extractor is especially useful for:
- concept definition
- pitch sharpening
- prototype evaluation
- identifying feature sprawl
- clarifying the minute-to-minute game engine
- separating real engagement structure from progression wallpaper

Common patterns to watch for:
- many teams describe systems, not loops
- progression is often mistaken for the core loop
- a long chain of actions is not automatically a loop
- if the loop depends entirely on external rewards, the core loop may be weak
- if nobody can state the loop in one breath, it is probably muddy

## Working principle

A game stays alive because something in it closes cleanly enough, changes enough, and promises enough to make repetition feel meaningful.

Use this skill to identify that engine and expose where it is sputtering.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-fantasy-extractor
description: Extract the core player fantasy from a game, feature, loop, or pitch based on what the design actually lets the player do, feel, and become. Use when a team can describe mechanics but cannot clearly articulate the fantasy those mechanics are supposed to deliver, when a concept feels emotionally vague, when a pitch names features instead of a player promise, or when you need to test whether the claimed fantasy is real, weak, conflicted, or absent.
---

# Game Design Fantasy Extractor

Extract the fantasy the design is actually trying to deliver, not just the genre wrapper or marketing line sitting on top of it.

Use this skill when a team can explain systems, verbs, and content, but cannot cleanly state what the player is meant to feel like, become, or emotionally inhabit. The goal is to infer the core player fantasy from the design itself, test whether the systems support it, and expose where the fantasy is generic, split, or fake.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

Players do not attach to mechanics in the abstract. They attach to what those mechanics let them be.

A useful fantasy statement does three things:
- names who the player becomes
- implies what emotional payoff they are chasing
- is supported by repeated gameplay, not just theme dressing

If the fantasy could describe fifty unrelated games, it is too weak to guide design.

## What to produce

Generate:
1. **Core fantasy** - the strongest player-facing fantasy implied by the design
2. **Supporting fantasy layers** - secondary fantasies or emotional promises present in the design
3. **Fantasy support map** - which systems reinforce the fantasy and which fail to do so
4. **Fantasy conflicts** - where systems, pacing, or progression undermine the claimed fantasy
5. **Design implications** - what must be strengthened, clarified, cut, or re-framed

## Process

### 1. Define the extraction target
Clarify:
- what exact game, feature, loop, or pitch is being analyzed
- whether the fantasy is for the whole product or one experience slice
- whether you are extracting the current fantasy or pressure-testing a claimed one

Write:
- **Extraction target**
- **Scope**
- **Claimed fantasy if any**

### 2. Identify the player verbs and role
Look at:
- what the player repeatedly does
- what power they exercise
- what decisions they make
- what social or world position they occupy
- what consequences they create

Ask:
- What role is the player actually inhabiting?
- What kind of agency does the design grant?
- Is the player expressing mastery, care, domination, discovery, survival, performance, stewardship, rebellion, creation, or something else?

### 3. Infer the emotional promise
Ask:
- What is the player supposed to feel at their best moments?
- What fantasy payoff keeps the loop emotionally coherent?
- Does the design promise competence, cleverness, power, danger, intimacy, authorship, belonging, control, chaos, or transformation?

State the strongest emotional promise in plain language.

### 4. Separate fantasy from theme skin
Check whether the fantasy is genuinely systemic or mostly cosmetic.

Examples:
- a game dressed as leadership but functionally about spreadsheet optimization
- a game themed as outlaw chaos but structurally punishing improvisation
- a game marketed as freedom while funneling players into narrow routes

Ask:
- If the art and fiction layer were stripped away, would the same fantasy still be legible through play?
- Is the fantasy delivered by action, or merely narrated at the player?

### 5. Identify supporting and competing fantasies
Many designs carry secondary fantasies. That is fine until they collide.

Look for:
- power fantasy versus vulnerability fantasy
- mastery fantasy versus cozy ritual fantasy
- freedom fantasy versus authored narrative control
- social belonging fantasy versus individual dominance fantasy

Name the strongest secondary fantasies and whether they strengthen or muddy the main one.

### 6. Map support and contradiction
For each major system, ask:
- does it reinforce the fantasy
- distract from it
- undermine it
- replace it with a different fantasy

Use this format:

| System or loop element | Supports fantasy? | Why |
|---|---|---|
| ... | Strongly / Partly / Weakly / No | ... |

### 7. Write the extracted fantasy sharply
Prefer a compact form such as:
- **You are ...**
- **You get to feel like ...**
- **This is a game about becoming ...**

Good examples are concrete and emotionally legible.
Bad examples sound like box-copy mush.

### 8. Convert the fantasy into design implications
For each important fantasy claim, specify:
- **Fantasy promise**
- **What the design must deliver repeatedly**
- **What the design should avoid because it breaks the fantasy**

Examples:
- outlaw improvisation -> systems must reward bold opportunism, not only rigid planning
- city stewardship -> player actions must visibly improve or shape the world
- predator mastery -> encounters must showcase dominance, not constant attrition panic

## Response structure

Use this structure unless the user asks for something else:

### Extraction Target
- ...

### Core Fantasy
- ...

### Supporting Fantasy Layers
- ...

### Fantasy Support Map
- ...

### Fantasy Conflicts
- ...

### Design Implications
1. ...
2. ...
3. ...

### Minimal Reframe or Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- What does the player actually get to be here?
- What feeling is the design promising at its best?
- Which system most strongly supports that fantasy?
- Which system most obviously betrays it?
- What one change would make the fantasy clearer?

## Usage notes

This extractor is especially useful for:
- early concept framing
- pitch cleanup
- fantasy-first ideation
- checking whether mechanics match emotional promise
- identifying why a concept feels flat despite competent systems
- aligning narrative, art, and design around one player promise

Common patterns to watch for:
- teams often describe setting instead of fantasy
- many designs claim freedom while structurally delivering obedience
- multiple fantasies can coexist, but only if they are hierarchized
- a fantasy without systemic support is just expensive decoration
- if the player role is vague, the fantasy probably is too

## Working principle

A design is not just a set of mechanics. It is an answer to the question, "what do I get to become while playing this?"

Use this skill to make that answer explicit and test whether the game earns it.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-design-pillars-extractor
description: Extract 3 to 5 actionable design pillars from a game, feature, loop, or system based on what the design actually rewards and prioritizes. Use when a team can describe mechanics but cannot clearly articulate the principles those mechanics serve, when pillars are vague, generic, or contradictory, or when you need a sharper set of tradeoff-driven pillars that can guide decisions and cut features.
---

# Game Design Design Pillars Extractor

Extract the real pillars a design is built around, not the polite slogans attached to it.

Use this skill when a team has a pile of mechanics, references, and ambitions but no sharp articulation of what the design actually prioritizes. The goal is to reverse-engineer 3 to 5 actionable pillars from the game's systems, loops, and tradeoffs.

Good pillars are directional. They help decide what to keep, what to cut, and what kinds of changes are off-brand. Bad pillars are just nice words wearing capital letters.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

A meaningful design pillar does two things:
- names what the design is trying hard to deliver
- implies what the design is willing to sacrifice to deliver it

If a pillar does not create a constraint, it is not a pillar yet.

## What to produce

Generate:
1. **Extracted pillars** - 3 to 5 clear, testable pillars
2. **Support map** - which systems actually reinforce each pillar
3. **Conflict map** - where systems or candidate pillars push against each other
4. **Missing or weak dimensions** - important priorities that are undefined, accidental, or under-supported
5. **Decision guidance** - which pillars should dominate future choices

## Process

### 1. Define the extraction target
Clarify:
- what exact game, feature set, or loop is being analyzed
- whether the pillars are for the whole product or a subset
- whether you are extracting current pillars or intended pillars

Write:
- **Extraction target**
- **Scope**
- **Current versus intended state**

### 2. Map the dominant design behaviors
Look at:
- core loop
- repeat decisions
- reward structure
- punishment structure
- progression model
- randomness profile
- pacing
- agency level
- social or solo emphasis

Ask:
- What does the design repeatedly encourage the player to do?
- What kinds of decisions matter most?
- What behaviors are rewarded, tolerated, or ignored?

### 3. Infer the implicit priorities
Ask:
- What is this design optimizing for in practice?
- What is it willing to make harder, slower, riskier, narrower, or less accessible in order to preserve that?
- Which experiences seem central rather than incidental?

This is where you move from feature description to design intention.

### 4. Detect tradeoffs and contradictions
Look for places where:
- one system rewards patience while another rewards speed
- one feature pushes mastery while another floods the loop with noise
- one layer promises freedom while another funnels players into one dominant path
- a supposed pillar is not actually reinforced by gameplay

Do not hide contradictions. Surface them.

### 5. Synthesize 3 to 5 pillars
For each pillar, provide:
- **Name**
- **What it means**
- **What it prioritizes**
- **What it sacrifices**
- **Which systems support it**

Prefer short, sharp names that imply a stance, such as:
- Controlled Chaos
- Readable Mastery
- High-Risk Commitment
- Expressive Preparation
- Ruthless Momentum

Avoid vague filler such as:
- Fun
- Immersion
- Engagement
- Quality
- Innovation

### 6. Identify missing or weak pillars
Ask:
- Which important experience dimensions are currently accidental or under-defined?
- Which design goals are talked about but not structurally supported?
- Which player promises are present in language but absent in systems?

### 7. Turn the pillars into decision guidance
State:
- which pillar should win when tradeoffs appear
- which features do not support any pillar and should be challenged
- which future ideas fit or violate the extracted set

## Response structure

Use this structure unless the user asks for something else:

### Extraction Target
- ...

### Extracted Design Pillars
1. ...
2. ...
3. ...

For each pillar:
- Meaning: ...
- Prioritizes: ...
- Sacrifices: ...
- Supporting systems: ...

### Conflicts and Contradictions
- ...

### Missing or Weak Pillars
- ...

### Decision Guidance
1. ...
2. ...
3. ...

## Fast mode

Use this quick pass when speed matters:
- What does the design reward most consistently?
- What is it clearly willing to sacrifice?
- What three priorities best describe the actual game?
- Which feature does not belong?

## Usage notes

This extractor is especially useful for:
- early concept framing
- preproduction alignment
- pitch cleanup
- feature triage
- post-prototype coherence checks
- making design docs less hand-wavy

Common patterns to watch for:
- teams often confuse feature lists with pillars
- a pillar that cannot say "no" is not doing any work
- contradictory pillars usually reflect unresolved design conflict, not healthy nuance
- the strongest pillar should be obvious in repeated gameplay, not just in slide decks
- if every pillar sounds universally positive, they are probably too generic to guide decisions

## Working principle

Mechanics reveal priorities even when the team does not.

Use this skill to extract the principles the design is actually living by, then decide whether those principles are worth keeping.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-player-persona-extractor
description: Extract the ideal player persona and anti-persona for a game, feature, loop, or progression structure based on the design itself. Use when a team can describe mechanics but cannot clearly articulate who the design is truly for, which player motivations and tolerances it suits, which players it will alienate, or how audience fit should shape design decisions. Focus on behavioral and motivational personas first, and optionally add demographic or market-fit hypotheses when the user explicitly asks for that layer.
---

# Game Design Player Persona Extractor

Extract who a design is actually built for.

Use this skill when a team can describe systems, loops, and mechanics, but not the kind of player who will love them, tolerate them, or bounce off them. The job is not to invent a fake marketing avatar. The job is to infer the player profile implied by the design.

Focus on behavior, motivation, tolerance, learning style, and emotional appetite. Avoid demographic fluff unless the user explicitly asks for it.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.
Read `references/demographic-research-notes.md` when the user explicitly wants demographic support, market validation, or publisher-facing audience framing.

## Core principle

A game becomes sharper when it serves a specific kind of player extremely well instead of vaguely trying to work for everyone.

A useful persona does three things:
- identifies who the design delights
- identifies who the design frustrates or excludes
- implies concrete design choices

If the resulting persona could fit almost any game, it is too weak to matter.

## What to produce

Generate:
1. **Ideal player persona** - the player this design best serves
2. **Anti-persona** - the player most likely to reject or churn from it
3. **Behavior profile** - how the player approaches play, learning, and decisions
4. **Emotional profile** - what they want to feel and what breaks the deal
5. **Design implications** - what the design must emphasize, protect, and avoid for this audience
6. **Optional demographic layer** - only when explicitly requested, add likely demographic or market-fit hypotheses that support the behavior-first persona rather than replacing it
7. **Optional market audience summary** - when requested for pitch, publishing, or strategy use, convert the persona into a concise audience-facing summary with demographic overlap, comparable-title signals, and confidence notes

## Process

### 1. Define the extraction target
Clarify:
- what exact game, feature, or loop is being analyzed
- whether the persona is for the whole product or only one experience slice
- what known constraints already shape audience fit

Write:
- **Extraction target**
- **Scope**
- **Known constraints**

### 2. Read the design for behavioral signals
Look at features such as:
- difficulty level
- randomness level
- pacing and session length
- agency level
- punishment severity
- progression structure
- strategic depth
- repetition tolerance
- required patience, experimentation, or precision

Ask:
- What kind of player will enjoy making these decisions repeatedly?
- What kind of frustration is this design asking the player to tolerate?
- Does it reward mastery, experimentation, social play, expression, optimization, calm routine, or high tension?

### 3. Infer the core motivation profile
Common motivation buckets include:
- mastery and skill growth
- experimentation and discovery
- optimization and efficiency
- competition and status
- expression and creativity
- narrative curiosity
- collection and completion
- comfort, ritual, and low-pressure progress

State which motivations the design strongly serves and which it serves poorly.

### 4. Infer the tolerance profile
Judge what the implied player can comfortably tolerate in terms of:
- difficulty
- repetition
- randomness
- ambiguity
- failure frequency
- delayed rewards
- long sessions or short bursts
- social friction
- optimization pressure

This often reveals the anti-persona more clearly than the positive persona does.

### 5. Describe the play style and learning style
Clarify how the ideal player tends to behave:
- cautious or impulsive
- planner or improviser
- systems learner or fantasy chaser
- repetition-based learner or novelty seeker
- optimizer or role-player
- solo-focused or socially motivated

Write this as behavior, not vague adjectives.

### 6. Define emotional expectations
Ask:
- What does this player want to feel regularly?
- What kind of tension is enjoyable to them?
- What kind of frustration will they accept?
- What kind of frustration will feel like betrayal?

### 7. Define the anti-persona
State clearly who this is not for and why.

Avoid generic anti-personas like "people who do not like games." Instead name the specific mismatch:
- wants predictable progression but design thrives on variance
- wants low-pressure comfort but loop demands intense optimization
- wants expressive freedom but systems narrow into one dominant path

### 8. Convert the persona into design implications
For each important persona trait, specify:
- **Trait or expectation**
- **What the design must do**
- **What the design should avoid**

Examples:
- experimental learner -> outcomes must be legible enough to support testing
- high variance tolerance -> randomness must still feel interpretable
- low repetition tolerance -> loop needs novelty density
- mastery-driven audience -> failure must teach, not merely punish

### 9. Add the optional demographic layer only when asked
Use this step only if the user explicitly wants demographic data, audience hypotheses, or market-facing persona framing.

Keep the logic in this order:
1. extract the behavioral persona first
2. infer which demographic clusters are most likely to overlap with that persona
3. if needed, use current market or genre data to test whether those demographic guesses are plausible

Demographics should support the behavioral read, not drive it.

When asked for this layer:
- clearly label it as **hypothesis**, **market signal**, or **supporting demographic fit**, not as certainty
- prefer ranges and segments over fake precision
- distinguish between **likely demographic overlap** and **required target audience**
- if external market validation is useful, search for recent player-demographic data for the genre, platform, region, or adjacent titles
- note when the available data is broad market data rather than title-specific evidence

Useful demographic dimensions may include:
- age bands
- platform skew
- region
- play frequency
- spending profile
- genre familiarity
- solo versus social preference

Avoid garbage personas like:
- "25-year-old male who likes fun"
- fabricated lifestyle backstory with no design relevance
- demographic claims that contradict the behavior profile

If evidence is weak, say so directly.

### 10. Use web research mode when the user wants validation
Use web research mode when the user asks for demographic validation, audience evidence, market support, or current player data.

In web research mode:
- search for recent data first, preferably within the last 2 to 4 years when possible
- prioritize reputable sources such as platform-holder reports, publisher reports, ESA, Newzoo, Statista-style summaries if clearly cited, GDC talks, Steam or console ecosystem reports, and credible market analyses
- prefer genre-, platform-, or region-specific data over broad "all gamers" data when the design is niche
- separate hard evidence from inference
- cite what the evidence actually supports rather than stretching it

Useful web-research questions:
- what demographics over-index in this genre?
- what platform and age skew is reported for comparable play patterns?
- what monetization or session-length patterns are common in this audience?
- what regional differences matter?

When evidence is mixed, show the tension instead of pretending one clean answer exists.

### 11. Use title-comparison mode when comparable games matter
Use title-comparison mode when the user asks for comp titles, adjacent audience fit, genre neighbors, or evidence from similar games.

In title-comparison mode:
- identify 2 to 5 comparable titles, not a giant dump
- choose comps based on audience behavior, play pattern, and fantasy, not just surface theme
- explain why each title is a useful comparison
- infer likely audience overlap from those comps carefully
- note where a comp is commercially useful but behaviorally misleading

For each comparison, prefer:
- **Comparable title**
- **Why it overlaps**
- **Likely shared audience traits**
- **Important difference**

### 12. Use market-audience summary mode for pitch decks and publisher-facing work
Use this mode when the user wants a concise audience summary for pitch decks, publishing conversations, strategy docs, or greenlight materials.

In market-audience summary mode:
- compress the behavior-first persona into a short, decision-useful audience summary
- include the strongest likely demographic overlap only if it helps the audience case
- mention comparable titles if they strengthen the argument
- state confidence level and major uncertainty
- avoid pretending the persona itself is validated market truth unless actual evidence was reviewed

A good market-audience summary should answer:
- who this game is mainly for
- why that audience is a fit
- what adjacent audiences may also convert
- what audience mismatches or commercial risks are most important

## Response structure

Use this structure unless the user asks for something else:

### Extraction Target
- ...

### Ideal Player Persona
- ...

### Core Motivations
- ...

### Tolerance Profile
- ...

### Play Style and Learning Style
- ...

### Emotional Expectations
- ...

### Anti-Persona
- ...

### Design Implications
1. ...
2. ...
3. ...

### Optional Demographic Layer
- Likely demographic overlap: ...
- Confidence: ...
- Supporting signal or market evidence: ...

### Optional Comparable Titles
- ...

### Optional Market Audience Summary
- ...

## Fast mode

Use this quick pass when speed matters:
- Who is this game perfect for?
- What frustration are they willing to tolerate?
- What kind of player will hate this?
- What one design choice matters most for the ideal audience?
- If demographic output was requested, what demographic overlap is plausible and how confident are we?
- If market framing was requested, which comparable titles and audience signals best support the case?

## Usage notes

This extractor is especially useful for:
- early concept definition
- pillar clarification
- feature targeting
- tuning difficulty and punishment
- checking audience fit after prototypes
- aligning design, product, and marketing language
- preparing audience sections for pitch decks and publisher conversations
- creating behavior-first audience summaries supported by market evidence

Common patterns to watch for:
- many teams describe mechanics first and audience second, which hides conflicts
- a design can accidentally target incompatible personas at once
- personas built from demographics are usually too weak to guide design
- demographics are useful as a supporting layer, not as the foundation of the persona
- the anti-persona is often more useful than the persona for clarifying tradeoffs
- if everyone sounds like a fit, the design target is still foggy

## Working principle

A design always chooses its player, even when the team refuses to admit it.

Use this skill to make that choice visible and actionable.
FILE:references/demographic-research-notes.md
# Demographic Research Notes

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

## Core rule

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

## What to look for

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

## Source priorities

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

## Reporting rules

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

## Useful output labels

- Likely demographic overlap
- Evidence-backed audience signal
- Confidence level
- Important uncertainty
- Comparable-title support
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-molyneux-lens
description: Stress-test a game concept, feature, system, or pitch through a deliberately provocative, ambition-seeking design lens inspired by Peter Molyneux-style overstatement. Use when a concept feels too safe, too polite, under-fantasized, mechanically competent but emotionally weak, or in need of sharp provocations that push fantasy, reactivity, and memorable moments before being grounded back into reality.
---

# Game Design Molyneux Lens

Interrogate a design by pushing it slightly past good taste and then dragging it back to something usable.

Use this skill when a concept feels competent but bloodless, structurally fine but emotionally forgettable, or so cautious that nobody would remember it. This is not a neutral audit. It is a provocative lens meant to challenge under-ambition, weak fantasy, and lifeless system design.

Be bold, but not useless. Push hard, then ground hard.

Read `references/family-conventions.md` when you want the shared style rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-viable-magic structure.

## Core principle

Safe ideas are often coherent and also invisible.

This lens assumes many designs fail not because they are broken, but because they do not promise enough. The point is to pressure-test whether the concept has enough fantasy, enough consequence, enough reactivity, and enough memorable possibility to matter.

Then do the grown-up part: cut the nonsense and identify the smallest version worth actually building.

## Tone rules

- Be direct.
- Be slightly over the top, not parody-level ridiculous.
- Call out mediocrity when you see it.
- Offer only a few strong provocations, not a bucket of feature sludge.
- Tie every provocation back to player fantasy.
- Follow every bold idea with a reality check.

## What to produce

Generate:
1. **Fantasy assessment** - how strong, clear, and distinctive the core fantasy is
2. **Safety callout** - where the idea is timid, generic, or over-sanitized
3. **Provocations** - a small set of bold, high-upside pushes
4. **Magic moments** - concrete moments the stronger version could create
5. **Reality check** - what is vague, over-scoped, or technically dangerous
6. **Minimal viable magic** - the smallest grounded version that still carries the spark

## Process

### 1. Define the design target
Clarify:
- what exact concept, feature, or system is being challenged
- what fantasy it claims to serve
- what constraints matter

Write:
- **Design target**
- **Claimed fantasy**
- **Practical constraints**

### 2. Judge the core fantasy
Ask:
- Is the fantasy clear in one sentence?
- Would a player care emotionally, not just mechanically?
- Is this fantasy actually being delivered by the current systems?
- Is it distinctive, or does it smell like a genre placeholder?

Call out weak fantasy plainly.

### 3. Identify where the design is playing safe
Look for:
- predictable structure
- low consequence decisions
- reactive shallowness
- passive player role
- feature polish without experiential identity
- systems that function but do not produce stories

State exactly where the design feels timid, sanitized, or forgettable.

### 4. Generate a few strong provocations
Produce 2 to 3 maximum.

Each provocation must state:
- **Bold idea**
- **Why it matters**
- **How it changes the fantasy**
- **What player behavior or emotion it unlocks**

Good provocations tend to:
- increase player agency
- deepen system reactivity
- raise consequence
- sharpen fantasy identity
- create story-worthy moments

### 5. Describe the magic moments
For each strong direction, describe one or more concrete moments a player could later retell.

Do not stay abstract. Write the scene.

Examples of useful framing:
- "the moment the village remembers what you did"
- "the moment the market crashes because you manipulated trust"
- "the moment your pet disobeys because you trained it badly"

### 6. Run the reality check
For each provocation, ask:
- what is hand-wavy here?
- what is likely over-scoped?
- what is technologically or production-wise risky?
- what would collapse into smoke and hype if built lazily?

Be honest. The point is not to protect the provocation from criticism.

### 7. Extract the minimal viable magic
Reduce each promising direction to the smallest buildable version that still preserves the emotional point.

Examples:
- not a fully simulated society, but a small number of reactive factions
- not infinite emergent morality, but 3 persistent consequence tracks
- not godlike systemic freedom, but one deeply reactive toy with surprising range

## Response structure

Use this structure unless the user asks for something else:

### Design Target
- ...

### Fantasy Assessment
- ...

### Safety Callout
- ...

### Provocations
1. ...
2. ...
3. ...

### Magic Moments
- ...

### Reality Check
- ...

### Minimal Viable Magic
- ...

### Recommendation
- Push / Refine / Cut
- Why: ...

## Fast mode

Use this quick pass when speed matters:
- What is the fantasy?
- Why is the current version too safe?
- What is one bold twist that would make people care?
- What is the smallest believable version of that twist?

## Usage notes

This lens is especially useful for:
- early concept work
- pitch sharpening
- fantasy-first ideation
- stale systems that feel technically fine but emotionally dead
- design teams stuck in competent compromise

Common patterns to watch for:
- the design describes what the player does, but not what they become
- the system has verbs but no myth
- the feature list is long, but the memorable moments list is empty
- ambition is present in marketing language only
- the team is protecting scope by killing identity

## Working principle

The goal is not to be right. The goal is to make a better design harder to ignore.

Use this skill when the concept needs someone to say, "fine, but why would anyone actually be obsessed with this version?"
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-fairness-frustration-audit
description: Audit a game, feature, failure loop, combat encounter, reward system, progression wall, or high-variance mechanic for perceived fairness and frustration. Use when diagnosing whether players feel cheated, whether difficulty feels deserved, whether randomness, feedback, and challenge interact badly, or why a design remains technically functional yet still produces anger, blame, or refusal to retry.
---

# Game Design Fairness and Frustration Audit

Audit a design by asking whether it feels fair, understandable, and worth retrying.

Use this skill when the real question is not merely "is it balanced" but "why does this make players mad?" This audit combines three lenses:
- attribution theory: who or what players blame
- flow theory: whether challenge and skill stay aligned over time
- perceived randomness: whether uncertainty feels exciting, suspicious, or rigged

Focus on player perception. Mechanical correctness is not enough if the experience still feels hostile.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

Players will accept difficulty, failure, and uncertainty when they feel:
- the cause is understandable
- they had meaningful influence
- the challenge matched a learnable demand
- luck was visible, bounded, or mitigable

Players reject the same systems when outcomes feel:
- arbitrary
- hidden
- uncontrollable
- disproportionate
- repeatedly punishing without teaching

## What to produce

Generate:
1. **Fairness assessment** - whether the experience feels fair, questionable, or unfair
2. **Frustration profile** - what kind of frustration it creates and why
3. **Attribution diagnosis** - how players explain the outcome
4. **Randomness diagnosis** - how uncertainty is perceived and whether it is trusted
5. **Flow diagnosis** - where challenge-skill mismatch amplifies frustration
6. **Design actions** - what to change first to reduce hostility and improve retry willingness

## Process

### 1. Define the audit target
Clarify:
- what exact mechanic, loop, or scenario is producing the concern
- whether the issue centers on failure, reward, difficulty, or inconsistency
- what player segment is feeling the pain most

Write:
- **Audit target**
- **Player segment**
- **Observed complaint or risk**

### 2. Reconstruct the player-facing event
Map:
- what the player tried to do
- what the system did in response
- what role randomness played
- what feedback the player saw
- what the cost of failure was

Ask:
- What did the player think would happen?
- What actually happened?
- What evidence did the game provide to explain the result?
- What could the player realistically have done differently?

### 3. Run the attribution lens
Judge whether the likely reading is:
- internal or external
- stable or unstable
- controllable or uncontrollable

Translate that into the likely player sentence, not just the technical classification.

### 4. Run the randomness lens
Examine:
- whether randomness is visible or hidden
- whether it changes frequency, impact, or both
- whether the player can mitigate, predict, or prepare for it
- whether streaks or outliers feel suspicious
- whether randomness is being mistaken for execution failure or designer malice

### 5. Run the flow lens
Check:
- whether challenge exceeded current skill too sharply
- whether the player had enough teaching or support before the demand hit
- whether repetition creates learning or just repeated punishment
- whether the experience becomes anxious, exhausting, or deadening over time

### 6. Identify compounding frustration patterns
Pay special attention to combinations like:
- high challenge + low clarity
- high punishment + low controllability
- hidden RNG + severe loss
- repeated failure + stable external attribution
- long retry cycle + low learning value

This is where frustration often shifts from healthy tension into "I am done with this."

### 7. Grade the fairness experience
Use a direct classification:
- **Fair** - hard, but understandable and teachable
- **Questionable** - some understandable basis, but trust is fragile
- **Unfair** - outcomes feel hostile, hidden, or insufficiently controllable

State clearly whether the main problem is:
- clarity
- control
- randomness
- pacing
- punishment
- inconsistency
- or a combination

### 8. Convert findings into design changes
For each issue, specify:
- **Problem**
- **Why it feels unfair**
- **Suggested change**
- **Expected emotional effect**

Examples:
- add telegraphing -> reduces external blame
- expose odds or logic -> reduces suspicion
- add mitigation or counterplay -> increases control
- soften punishment during learning -> preserves retry motivation
- shorten retry cycle -> converts frustration into iteration

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Fairness Assessment
- Overall: Fair / Questionable / Unfair
- Why: ...

### Frustration Profile
- ...

### Attribution Diagnosis
- ...

### Randomness Diagnosis
- ...

### Flow Diagnosis
- ...

### Root Causes
- ...

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

### Minimal Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- Why does the player feel cheated?
- Is the main issue hidden cause, low control, bad RNG framing, or challenge mismatch?
- Does the player feel like retrying or quitting?
- What is the smallest change that most improves trust?

## Usage notes

This audit is especially useful for:
- boss fights
- roguelite losses
- gacha or loot outcomes
- PvP or PvE streak complaints
- onboarding punishments
- progression walls
- one-shot kills
- card draw variance
- AI behavior that feels inconsistent or "scripted"

Common patterns to watch for:
- a mathematically fair system can still feel unfair if its logic is hidden
- low-probability disasters feel much worse when the player had no mitigation tools
- high punishment demands high clarity
- frustration becomes toxic when players cannot convert failure into learning
- if players blame luck, the system, and pacing at the same time, fix trust before tuning difficulty

## Working principle

A fair game can still frustrate. The key question is whether the frustration points toward mastery or away from the game.

Use this skill when players are not just struggling, but suspecting the design itself.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-flow-audit
description: Audit a game, feature, level sequence, combat loop, progression curve, onboarding path, event structure, or return-player journey through the lens of Flow theory. Use when evaluating whether challenge and skill stay aligned over time, diagnosing boredom, anxiety, frustration spikes, difficulty cliffs, dead zones, or pacing drift, or identifying where a design stops feeling absorbing and starts feeling exhausting or empty.
---

# Game Design Flow Audit

Audit a design by asking whether it keeps players in a productive state of engagement over time.

Use this skill to evaluate whether challenge rises in step with player skill, where the experience becomes boring or overwhelming, and which moments break the player's sense of momentum. Focus on temporal experience and pacing, not static difficulty labels.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

Flow emerges when challenge and player skill stay in meaningful tension and grow together over time.

Typical failure shapes:
- **Challenge above skill** -> anxiety, confusion, frustration
- **Skill above challenge** -> boredom, autopilot, disengagement
- **No visible skill growth** -> stagnation, flatness, drop-off

A flow audit is not just about whether the game is hard. It is about whether the game keeps giving the player something they can meaningfully rise to.

## What to produce

Generate:
1. **Flow curve summary** - the overall engagement shape over time
2. **Phase breakdown** - where the player is in flow, boredom, or anxiety
3. **Breakpoints** - the exact moments where flow is likely to break
4. **Skill-versus-challenge diagnosis** - what is misaligned and why
5. **Design actions** - specific changes to restore momentum and absorption

## Process

### 1. Define the audit target
Clarify:
- what part of the experience is being audited
- what player segment matters most
- what time window matters most

Write:
- **Audit target**
- **Player segment**
- **Relevant timeline**

### 2. Map the experience over time
Break the target into phases such as:
- first 30 seconds
- first 5 minutes
- first session
- early mastery
- midgame
- endgame
- return-player re-entry

For each phase, identify:
- what the player is trying to do
- what the game asks of them
- what counts as success
- how much support exists

### 3. Identify the required skill axes
Separate the skill demands into useful buckets such as:
- mechanical execution
- tactical judgment
- strategic planning
- system comprehension
- attention management
- social coordination

Ask:
- What does the player actually need to be good at here?
- Which skills are newly introduced, tested, or combined?
- Which skills are ignored or overemphasized?

### 4. Judge challenge versus skill in each phase
For every phase, evaluate:
- current challenge level
- expected player skill level
- resulting flow state

Use this format:

| Phase | Key challenge | Expected player skill | Likely state |
|---|---|---|---|
| ... | ... | ... | Flow / Boredom / Anxiety |

### 5. Identify breakpoints and transition failures
Look for moments where:
- the game asks for mastery before teaching
- difficulty spikes without warning
- complexity stacks too quickly
- the loop becomes repetitive without new pressure
- rewards stall while demands rise
- the player loses sight of goals or progress

Name the specific handoff or step where flow breaks, not just the general area.

### 6. Evaluate pacing and learning support
Assess whether the design:
- introduces one meaningful complexity at a time
- gives feedback fast enough to support learning
- varies challenge without becoming chaotic
- creates enough novelty to prevent boredom
- allows recovery after failure
- respects differences between new, intermediate, and expert players

### 7. Convert findings into design changes
For each issue, specify:
- **Breakpoint**
- **Why flow breaks there**
- **Suggested change**
- **Expected effect on the curve**

Examples:
- reduce early enemy density -> lowers anxiety spike
- delay second-system introduction -> reduces overload
- add optional mastery pressure later -> reduces boredom plateau
- improve re-entry summary -> restores flow for returning players

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Flow Curve Summary
- ...

### Phase Breakdown
- ...

### Critical Breakpoints
- ...

### Skill vs Challenge Analysis
- ...

### Segment Sensitivity
- ...

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

### Minimal Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- Where is the player likely bored?
- Where are they likely overwhelmed?
- What is the first major flow break?
- Which skill is under-supported?
- What one change would most improve challenge-skill alignment?

## Usage notes

This audit is especially useful for:
- FTUE and onboarding
- first combat sequences
- midgame pacing drift
- live event structures
- difficulty progression
- mission sequencing
- roguelite run structure
- endgame mastery loops
- return-player catch-up experiences

Common patterns to watch for:
- early spikes create churn before skill identity forms
- flat midgames create low-energy retention even with decent progression
- too much support can prevent anxiety but still create boredom
- raw stat inflation often breaks flow worse than richer decision-making does
- the same challenge can produce flow for experts and anxiety for newcomers

## Working principle

Players stay absorbed when the game keeps saying, "you can stretch a bit further."

Use this skill when a design feels off in motion: too flat, too spiky, too tiring, or just mysteriously less compelling than it should be.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-attribution-audit
description: "Audit a game, feature, combat scenario, progression step, failure state, onboarding beat, or reward outcome through the lens of attribution theory: how players explain success and failure. Use when evaluating whether players will blame themselves, the system, luck, or hidden rules; diagnosing perceived unfairness, learned helplessness, rage, or churn after losses; or identifying where clarity, control, and feedback are too weak for healthy learning."
---

# Game Design Attribution Audit

Audit a design by asking how players will explain what just happened.

Use this skill to evaluate whether a success or failure is likely to be interpreted as deserved, learnable, and controllable, or as arbitrary, unfair, and outside the player's influence. Focus on player perception of causality, not designer intent or mechanical correctness.

Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family.
Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure.

## Core principle

Players do not respond only to outcomes. They respond to the story they tell themselves about why the outcome happened.

Healthy failure attribution usually feels:
- internal enough to preserve responsibility
- controllable enough to support improvement
- unstable enough to preserve hope

Toxic failure attribution usually feels:
- external
- uncontrollable
- stable

That combination produces reactions like "the game screwed me" or "this always happens and I can do nothing about it."

## Attribution lenses

### 1. Locus
Ask whether the player is likely to locate the cause internally or externally.

- **Internal**: "I made the wrong choice" or "I misplayed"
- **External**: "the game cheated" or "the system decided against me"

### 2. Stability
Ask whether the player sees the cause as recurring or one-off.

- **Stable**: "this is just how this game always works"
- **Unstable**: "that happened this time, but next run could go differently"

### 3. Controllability
Ask whether the player believes they can influence the outcome in future attempts.

- **Controllable**: "I can improve this"
- **Uncontrollable**: "nothing I do matters"

## What to produce

Generate:
1. **Attribution profile** - likely player interpretation across locus, stability, and controllability
2. **Perception summary** - what the player is likely to think happened
3. **Fairness diagnosis** - whether the outcome feels deserved, understandable, and learnable
4. **Risk assessment** - frustration, learned helplessness, toxicity, or churn risk
5. **Design actions** - specific changes to improve attribution quality

## Process

### 1. Define the audit target
Clarify:
- what exact scenario, feature, or failure state is being audited
- what outcome triggered the audit
- who the relevant player is

Write:
- **Audit target**
- **Outcome type**
- **Player context**

### 2. Reconstruct the event from the player's point of view
Map:
- what the player did
- what the system did
- what feedback the player received
- what information was visible versus hidden

Ask:
- What action did the player believe they were taking?
- What result did they expect?
- What actually happened?
- What evidence did the game provide about cause and effect?

### 3. Classify the likely attribution profile
For the observed outcome, judge:
- **Locus** - internal, mixed, or external
- **Stability** - stable, mixed, or unstable
- **Controllability** - high, partial, or low

Use this format:

| Dimension | Likely player reading | Why |
|---|---|---|
| Locus | Internal / Mixed / External | ... |
| Stability | Stable / Mixed / Unstable | ... |
| Controllability | High / Partial / Low | ... |

### 4. Infer the likely player interpretation
Translate the attribution profile into player-facing language.

Examples:
- "I got greedy and deserved that"
- "That was bad luck, but I could have mitigated it"
- "The game hid the rule and punished me"
- "This encounter is just broken"

Prefer the exact sentence a frustrated player might actually say.

### 5. Diagnose why the attribution landed there
Look for root causes such as:
- hidden mechanics
- weak telegraphing
- delayed or ambiguous feedback
- inconsistent rules
- excessive randomness
- low agency or missing mitigation tools
- punishment that is too severe for the level of clarity provided

### 6. Check compounding risk patterns
Pay special attention to combinations like:
- low clarity + high punishment
- high randomness + low mitigation
- repeated failure + stable external attribution
- weak feedback + complex systems
- low control + high stakes

These combinations tend to create helplessness, blame, and churn faster than any one issue alone.

### 7. Convert the diagnosis into design changes
For each issue, specify:
- **Problem**
- **Why players read it that way**
- **Suggested change**
- **Expected perception shift**

Examples:
- improve telegraphing -> shifts blame from system to player decision
- expose hidden rules -> increases controllability
- add mitigation option -> turns fatalism into recoverable error
- reduce punishment severity -> lowers hostility during learning

## Response structure

Use this structure unless the user asks for something else:

### Audit Target
- ...

### Event Reconstruction
- ...

### Attribution Profile
- Locus: ...
- Stability: ...
- Controllability: ...

### Likely Player Interpretation
- ...

### Fairness and Learning Diagnosis
- ...

### Risk Assessment
- ...

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

### Minimal Fix
- ...

## Fast mode

Use this quick pass when speed matters:
- What does the player think caused the outcome?
- Does it feel internal or external?
- Does it feel controllable next time?
- Does it feel like a one-off or a permanent rule?
- What one change would most improve perceived control or clarity?

## Usage notes

This audit is especially useful for:
- combat deaths
- boss fights
- failure loops
- loot outcomes
- economy punishments
- onboarding mistakes
- puzzle failures
- competitive losses
- high-RNG systems that may be misread as rigged

Common patterns to watch for:
- a system can be mechanically fair and still attract external blame
- a hard loss can feel acceptable if the cause is clear and avoidable
- severe punishment raises the attribution bar: clarity and control must rise with it
- repeated confusion hardens unstable frustration into stable hostility

## Working principle

A good failure says, "you can learn this."
A bad failure says, "the game just does that."

Use this skill when you need to understand not only what happened, but what players will believe happened.
FILE:references/family-conventions.md
# Family Conventions

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

- Sound like a sharp design partner, not a textbook.
- Do not pad with praise or softening filler.
- Do not confuse length with rigor.
- If the design is muddled, say it is muddled.
- If the design has a strong core, say that too.
FILE:references/output-patterns.md
# Output Patterns

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

---
name: game-design-perceived-randomness-audit
description: Audit a game feature, combat system, loot table, reward loop, procedural system, chance mechanic, or uncertainty-driven design by how players are likely to perceive its randomness. Use when you need to evaluate whether a system will feel fair, streaky, rigged, sabotaging, manipulable, or skill-undermining; when players may misread independent events as patterned; or when randomness may sit too close to player action and create frustration. Analyze expectation gaps, gambler's-fallacy-style reactions, hidden pattern-seeking, input-versus-output randomness, perceived fairness, exploit risk, and ways to reshape presentation or mechanics.
---

# Game Design Perceived Randomness Audit

Audit not just the math of randomness, but the psychology of how players will read it.

Use this skill when the core question is not only "is this random system balanced?" but also "what story will players tell themselves about this randomness?" The goal is to catch places where independent events will be perceived as rigged patterns, where streaks will feel malicious, where uncertainty undermines competence, or where the game could use presentation or structure to make randomness feel fairer and more legible.

Read `references/perception-patterns.md` when you need the key psychology behind randomness perception.
Read `references/audit-checklist.md` when you need a compact checklist of design risks and mitigation levers.

## Core behavior

- Keep the analysis practical, not statistical-for-its-own-sake.
- Audit player perception, not only formal probability.
- Distinguish actual randomness from perceived randomness.
- Identify where players will imagine patterns, sabotage, or "the game knows what I need and withholds it" behavior.
- Check whether randomness happens before the decision or between the decision and the outcome.
- Treat randomness that interferes directly with player action as more dangerous than randomness that shapes the environment.
- Look for streak pain, expectation mismatch, control illusions, and competence damage.
- Recommend concrete fixes in system design, UX, communication, and presentation.

## What to ask first

Prioritize these questions:
1. What is the feature or random system?
2. What outcomes are random?
3. What does the player know before acting, and what is hidden until after acting?
4. What player action is this randomness attached to?
5. What does the player usually want in the moment when the random outcome occurs?
6. How often does the randomness happen, and how visible are streaks?
7. Is the system meant to feel exciting, fair, learnable, punishing, suspenseful, or skill-testing?
8. Are there safeguards, pity rules, weighted drops, rerolls, previews, or player-choice layers already present?

If information is missing, infer cautiously and state the assumption.

## What to diagnose

Quickly identify:
- whether the player is likely to assume hidden patterns in independent outcomes
- whether gambler's-fallacy-style expectations will make the system feel unfair after streaks
- whether players will expect conditional fairness such as "I have not gotten X lately so I should get it soon"
- whether randomness is input randomness, output randomness, or an unhealthy blur of both
- whether the system damages the feeling of competence by making deliberate actions resolve unpredictably
- whether players can meaningfully react to uncertainty using skill
- whether the presentation helps players understand the randomness or makes it feel rigged
- whether the mitigation method creates exploit risk or false promises

## Response structure

Always organize the answer using this structure.

### System Read
- describe the random system in plain language
- state what is actually random and what is not

### Player Expectation Read
- explain what players are likely to expect from the system
- identify likely mistaken assumptions about balance, streak correction, fairness, or hidden intent

### Perceived Fairness Risk
- explain when the system is likely to feel fair, unfair, rigged, streaky, or malicious
- highlight the most likely frustration story players will tell themselves

### Randomness Placement
- identify whether this is mostly input randomness or output randomness
- explain whether randomness happens before the player chooses or after the player commits
- say whether that placement supports or undermines skill expression

### Competence and Agency Read
- explain whether players can adapt to the uncertainty with skill
- identify where randomness is likely to invalidate intentional play
- note whether the system feels like a challenge to respond to or a sabotage of action

### Risk Diagnosis
- give the top 2 to 5 perception risks
- include streak pain, hidden-intent suspicion, exploitability, or expectation mismatch where relevant

### Recommendation
- recommend specific design, UX, or messaging changes
- separate must-fix from optional polish when useful

## Common risk patterns

Raise these when relevant:
- truly independent drops being perceived as "due"
- players believing the game withholds exactly what they currently need
- random combat resolution making skillful decisions feel invalidated
- pity systems that help fairness but become exploitable if too legible
- procedural/input randomness producing wildly different challenge levels with too little response time
- opaque weighting creating conspiracy theories
- visible streaks without framing, smoothing, or counterweights
- systems that are mathematically fair over long runs but emotionally awful in short runs

## Useful mitigation levers

Only recommend what fits the design intent.

- move randomness earlier so the player reacts to it rather than being blindsided by it
- reduce output randomness on high-stakes actions
- add soft streak smoothing or pity protection
- batch outcomes into more even distributions when fairness matters more than pure entropy
- provide player choice among random options
- expose clearer odds or stronger telegraphing
- separate excitement randomness from core skill resolution
- use presentation to give the player a clearer sense of authorship or controlled reveal
- shift reward pools by context carefully, while watching for exploit loops

## Strong use cases

This skill is especially useful for:
- loot drops and chest rewards
- gacha, pity, and streak-protection systems
- crit chance, hit chance, dodge, and proc systems
- random combat resolution
- procedural encounter or room generation
- event reward pools
- roguelike runs with variable offer quality
- randomness-heavy retention loops
- any design where players say the system feels rigged

## Weaker use cases

This skill is less useful for:
- systems with no meaningful uncertainty
- purely economic balance review without a perception question
- broad game critique where randomness is not a major issue

## Style guidance

- Be concrete.
- Do not hide behind statistics if the player-facing feeling is bad.
- Do not assume mathematically fair means experientially fair.
- If a system is perception-safe even though players may still complain sometimes, say that too.
- If the right fix is presentation rather than probability tuning, say so.
- If the right fix is to remove randomness from a player action entirely, say so directly.

## Fast mode

Use this compressed flow when the user wants a quick answer:
- what is random here
- what will players assume about that randomness
- will it feel fair or rigged
- is the randomness before or after player choice
- does it support skill or sabotage action
- what should change first

## Working principle

Players do not experience randomness as raw probability tables. They experience it as felt fairness, perceived intent, streak memory, and the degree to which their choices still seem to matter.

FILE:references/audit-checklist.md
# Audit Checklist

Use this file as a compact evaluation pass.

## Clarify the system
- What exactly is random?
- What is deterministic?
- How visible are the probabilities?
- How often does the random outcome occur?
- How high-stakes is each roll or draw?

## Expectation risks
- What does a normal player expect to happen over 5, 10, or 20 repetitions?
- Will the player expect short-run balance from a long-run random process?
- Will players believe the system is "due" to produce an outcome?
- Will streaks be highly visible and emotionally memorable?

## Placement risks
- Is the randomness before choice or after commitment?
- Can the player react to the uncertainty using skill?
- Does the randomness change the environment or sabotage the action?

## Fairness-perception risks
- When will the system feel rigged even if it is fair?
- What moments of need make bad outcomes feel malicious?
- Does the game accidentally create the story that it withholds exactly what the player wants?
- Is the short-run emotional experience much worse than the long-run math suggests?

## Agency and competence risks
- Does the player still feel smart when they play well?
- Can skill reduce the pain of bad luck?
- Does the system invalidate good decisions too often?
- Does randomness blur feedback so much that learning becomes muddy?

## Mitigation levers
- reduce output randomness
- move uncertainty earlier
- add pity or streak smoothing
- give a choice among random options
- expose clearer odds
- soften high-stakes streak pain
- reshape reward pools by context
- separate flavor randomness from core skill resolution

## Final verdict prompt
Ask:
- What is the biggest perceived-randomness failure here?
- What is the single highest-leverage fix?
- If no major fix is needed, why is this system perception-safe?

FILE:references/perception-patterns.md
# Perception Patterns

Use this file when you need the core ideas behind how players read randomness.

## 1. Brains look for patterns even in noise

Players naturally search for patterns, intent, and causality.
This is adaptive in life and misleading in random systems.
As a result, players will often believe:
- streaks mean something
- a system is "due" to correct
- the game is reacting to their current need
- unlucky outcomes imply hidden sabotage

## 2. Gambler's-fallacy-style expectations

Independent outcomes do not self-correct in the short run.
Players still often expect them to.

Common player stories:
- "I have missed five times, so the next one should hit"
- "I have not seen this drop in a while, so I should get it soon"
- "The system keeps giving me the one thing I do not need"

Audit implication:
- mathematically fair systems can still feel deeply unfair
- long-run fairness is weak protection against short-run resentment

## 3. Input randomness versus output randomness

### Input randomness
Randomness appears before the player chooses.
Examples:
- cards drawn into hand
- visible shop offers
- procedural room layout revealed before choice
- enemy spawn mix shown early enough to adapt

This usually supports skill better because the player responds to uncertainty.

### Output randomness
Randomness happens after the player chooses and between action and result.
Examples:
- hit chance after choosing an attack
- crit chance deciding the value of a committed action
- random chest result after the player already paid the cost

This is more dangerous because it can sever the link between intention and result.
It is more likely to damage competence and fairness perception.

## 4. Competence and action predictability

Players want uncertain situations.
They do not usually want their deliberate actions to feel untrustworthy.

Good pattern:
- the world is uncertain, but my action behaves as expected

Risky pattern:
- my action itself becomes random or resolves in a way I could not plan around

Audit implication:
- randomness that creates scenarios can be healthy
- randomness that corrupts the resolution of skillful action is more likely to frustrate

## 5. The system-feels-rigged story

When outcomes repeatedly clash with immediate player need, players often infer intent.
Example:
- low health -> no healing drops
- almost enough currency -> no currency drops
- need one upgrade material -> anything but that material

This can happen even with fair independent probabilities.
But the player story becomes:
- the game knows
- the game withholds
- the game is trolling me

Audit implication:
- check not only odds but moments of need
- identify where context amplifies perceived malice

## 6. Mitigation families

Different problems need different fixes.

### Smoothing
Use pity systems, bad-luck protection, or more even distribution when fairness matters more than purity.

### Repositioning randomness
Move randomness earlier so the player reacts to it rather than being blindsided by it.

### Choice injection
Offer several random options and let the player choose one.
This preserves surprise while restoring agency.

### Presentation and telegraphing
Use clearer framing, stronger anticipation, and visible affordances so randomness feels legible rather than arbitrary.

### Context-sensitive weighting
Adjust drop weights or outcomes by context only when the exploit risk is acceptable.

## 7. Main audit question

Do not ask only:
- "Is this mathematically fair?"

Also ask:
- "What will players believe about this randomness?"
- "What frustration story will the system generate?"
- "Does the randomness challenge player skill or erase it?"

---
name: game-dev-time-estimator
description: Help a beginner or early-stage game team estimate the likely development time for a game concept based on scope, target milestone, current team, skill coverage, work model, and production constraints. Use when someone asks how long a game might take, whether their current team can hit a target date, what timeline range they should expect for a prototype, vertical slice, release, or live F2P project, or how missing roles and part-time availability change development time. Ask for missing information when concept, team, scope, or staffing assumptions are unclear, then provide a rough timeline range, main schedule drivers, hidden time sinks, and ways to shorten the path.
---

# Game Dev Time Estimator

Estimate likely timeline ranges, not fake precision.

Use this skill when the user needs a practical schedule read on a game concept, milestone, or team setup. The goal is to help beginners understand which assumptions drive time, what the current team can realistically deliver, where hidden schedule drag comes from, and how scope choices affect duration.

Read `references/time-drivers.md` when you need a checklist of the main things that push timelines up or down.
Read `references/estimation-modes.md` when the user has not provided enough team detail or when you need to switch into scenario mode.

## Core behavior

- Keep the language simple and non-jargony.
- Ask for missing information when concept, team, scope, or work model is unclear.
- Give ranges, not fake precise delivery dates.
- Explain assumptions clearly.
- Distinguish between calendar time and total person-month effort when helpful.
- Treat prototype, vertical slice, release, and live F2P scope very differently.
- Ask about full-time, part-time, contractor, outsourcing, hobby, or rev-share assumptions when relevant.
- Ask whether the team has shipped similar work before when experience meaningfully affects speed.
- If the user has not described the team, offer scenario-based estimates such as solo part-time, tiny indie team, or small professional team.
- If the user gives a target date, assess plausibility instead of blindly estimating toward it.

## What to ask first

Prioritize these questions:
1. What is the game concept in plain language?
2. What is the target platform?
3. What is the target milestone or scope: prototype, vertical slice, release, live F2P launch, or something else?
4. Who is already on the team?
5. What can each person actually do well?
6. Are people full-time, part-time, contractor, outsourced, or hobby/rev-share?
7. Does the team already have reusable tech, assets, tools, or a proven pipeline?
8. Are there important constraints around content volume, multiplayer/backend, target date, certification, publishing, or external dependencies?

If key information is missing, ask 2 to 5 focused questions. If the user wants a fast estimate, state assumptions and continue.

## What to diagnose

Quickly identify:
- the main time drivers for this concept
- whether schedule risk comes mostly from implementation, content production, coordination, polish, or approvals
- what the current team can do in parallel versus what is bottlenecked through one person
- what missing disciplines will slow progress even if they do not add much direct budget
- whether the user is underestimating iteration, QA, UI, content integration, platform prep, or online/live-service time
- whether the milestone is realistic for the stated team and availability
- whether the user is confusing best-case build time with realistic calendar time

## Common time sinks to consider

Do not always list all of these. Only raise what matters.

- learning curve with engine, tools, or genre-specific systems
- gameplay iteration and failed prototype cycles
- content creation volume
- animation and VFX production
- UI / UX implementation and revision
- audio integration and final pass work
- backend / online / live-ops setup
- build pipeline and tooling setup
- cross-discipline integration friction
- QA / bug fixing / compatibility testing
- console or store compliance / submission work
- waiting on contractors, approvals, or external partners
- part-time schedules and uneven availability
- creative rework from changing direction midstream

## Response structure

Always organize the answer using this structure.

### Project Snapshot
- one short summary of the game and milestone
- one sentence on what kind of timeline shape this project usually has

### Assumptions
- scope assumptions
- team assumptions
- availability assumptions
- tooling / pipeline assumptions
- timeline constraints if relevant

### Main Schedule Drivers
- list the top factors driving time for this project
- explain why they matter here

### What the Current Team Can Parallelize
- explain what can move simultaneously
- identify bottlenecks or single-threaded work
- distinguish fully covered from partly covered

### Likely Hidden Time Sinks
- list schedule drag the project probably still faces
- explain which are must-plan-for versus optional risk buffers

### Rough Time Range
- low case
- expected case
- high case
- short explanation of what changes between them

### Ways to Shorten the Timeline
- scope cuts
- milestone reduction
- art/style simplification
- fewer platforms
- fewer online dependencies
- better reuse of tools, assets, middleware, or contractors where sensible
- more realistic sequencing and fewer parallel workstreams when coordination overhead is hurting

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

## Estimation modes

### Team-known mode
Use when the user described the team.
- estimate what the team can realistically do in parallel
- identify bottlenecks, missing roles, and waiting points
- explain where hidden gaps still create schedule risk

### Team-unknown mode
Use when the user did not describe the team.
- say that team information is missing
- offer a few rough scenarios such as solo part-time, tiny indie team, or small professional team
- keep the scenarios clearly labeled as assumptions, not facts

### Target-date mode
Use when the user asks whether they can hit a deadline.
- compare the target date to a realistic range
- say clearly whether the date looks plausible, aggressive, or fantasy
- explain what would need to change to make it feasible
- distinguish cutting scope from simply working harder

### Milestone-specific mode
Adjust strongly by milestone:
- **Prototype**: low polish, placeholder-heavy, learning-focused, iteration-heavy
- **Vertical slice**: stronger presentation, UX, polish, and cross-discipline quality bar
- **Release**: much broader production, QA, content, business, and platform-readiness burden
- **Live F2P / online**: higher ongoing time needs for backend, analytics, economy tuning, content cadence, support, and operations

## Scope sensitivity

Call out these common schedule traps when relevant:
- assuming part-time work compresses calendar time more than it actually does
- assuming a vertical slice schedule scales linearly into full production
- ignoring iteration and rework time
- forgetting UI, audio, QA, and integration passes
- underestimating content production and polish time
- treating existing team members as if they cover roles they only partly cover
- assuming adding people always makes things faster even when onboarding and coordination slow things down
- forgetting submission, approvals, localization, or store-readiness work near the end

## Style guidance

- Be practical and transparent.
- Do not pretend the estimate is precise.
- Give directional confidence, not fake production certainty.
- If the project sounds under-timed, say so directly.
- If the timeline could become realistic through scope cuts, explain how.
- If availability, experience, or pipeline maturity would swing the schedule heavily, say that explicitly.

## Fast mode

Use this compressed flow when the user wants a quick answer:
- what are you making
- what milestone are you targeting
- who is on the team
- how available are they
- what is most likely to slow this down
- what timeline range is plausible
- how could the timeline be shortened

## Working principle

A useful early time estimate is not a fake launch date. It is a clear explanation of which assumptions are creating schedule risk, what the team can actually do in parallel, and where the biggest hidden delays are likely to appear.

FILE:references/estimation-modes.md
# Estimation Modes

Use this file when the user input is incomplete, when you need scenario framing, or when a deadline plausibility check is more useful than a generic estimate.

## 1. Team-known mode

Use when the user described the team with at least rough role and availability detail.

Focus on:
- what can happen in parallel
- which workstreams bottleneck through one person
- where missing coverage creates waiting time
- how experience level changes speed

Good output pattern:
- current team summary
- likely parallel work
- likely bottlenecks
- low / expected / high schedule range
- what would shorten the schedule

## 2. Team-unknown mode

Use when team information is missing.

Offer labeled scenarios such as:
- solo part-time beginner
- solo full-time experienced developer
- tiny indie team with mixed skills
- small professional team with solid coverage

Keep scenario names plain and clearly hypothetical.
Do not imply the user actually has that team.

## 3. Target-date mode

Use when the user asks something like:
- can we do this in 6 months?
- could this ship by next summer?
- is this realistic by Q4?

Approach:
1. estimate a realistic range first
2. compare the requested deadline against that range
3. label the deadline as plausible, aggressive, or unrealistic
4. explain what must change to make it plausible

Prefer language like:
- plausible if scope stays tight
- possible but aggressive
- unrealistic without major cuts
- fantasy unless the milestone is redefined

## 4. Milestone mode

Shift the estimate based on what the user is actually trying to reach.

### Prototype
- optimize for learning speed
- assume placeholder assets
- include iteration and failed experiments

### Vertical slice
- assume one polished representative slice
- raise the bar for UX, art consistency, and polish
- include more integration and presentation work

### Release
- include content breadth, QA, stability, business readiness, and endgame finishing work

### Live F2P / online
- include backend, telemetry, balancing cadence, support needs, and operational readiness

## 5. Confidence language

Use confidence language instead of pretending the estimate is exact.

Examples:
- high uncertainty because team details are missing
- moderate confidence if the team has shipped similar work
- low confidence because content scope is still undefined
- confidence would improve a lot after a prototype or feature list cut

FILE:references/time-drivers.md
# Time Drivers

Use this file when you need a quick checklist of what usually stretches or compresses game development timelines.

## Biggest timeline multipliers

### Scope shape
- Number of core systems
- Content volume
- Number of playable characters, levels, enemies, modes, or biomes
- Required polish level
- Number of target platforms
- Online or live-service requirements

### Team shape
- Solo versus duo versus small team
- Full-time versus part-time availability
- Seniority and prior shipped experience
- Whether key disciplines are missing
- How much work bottlenecks through one person
- Coordination overhead once multiple people depend on each other

### Production maturity
- Existing codebase or prototype reuse
- Existing art style, asset library, or outsourcing pipeline
- Familiarity with engine and tools
- Build pipeline and testing maturity
- Clarity of design versus likely rework rate

### Technical difficulty
- Multiplayer / netcode / backend
- Procedural systems or AI-heavy behavior
- Cross-platform optimization
- Save systems, economy, progression, analytics
- Platform-specific certification or compliance constraints

### Content burden
- High-volume authored content
- Animation workload
- Narrative and localization load
- UX flow complexity
- Audio implementation and iteration

## Fast heuristics

Use these as rough reasoning aids, not formulas.

- A prototype often spends more time on learning and iteration than on polish.
- A vertical slice often takes longer than beginners expect because presentation quality rises sharply.
- A release schedule usually grows non-linearly versus a prototype because content, QA, and stability work expand fast.
- Online and live F2P scope usually add both upfront setup time and recurring operational time.
- Part-time teams usually lose time not just from fewer hours but from context-switching and slower feedback loops.
- Adding people helps only when work can be split cleanly and the pipeline is already organized.

## Common hidden delays

Raise these when the user sounds overly optimistic.

- tool learning
- prototype restarts
- waiting on art, UI, or audio handoff
- bug fixing late in production
- integration passes between disciplines
- store submission prep
- performance optimization
- platform-specific fixes
- contractor lag or revision rounds
- changing direction after playtests

## Questions that improve the estimate

Ask only the ones that matter.

1. Is this a prototype, vertical slice, release, or live service launch?
2. How many people are actually working on it, and how available are they?
3. Which disciplines are truly covered in-house?
4. Is the game content-light or content-hungry?
5. Is there multiplayer, backend, or live operations?
6. Is there existing tech or a mature pipeline to reuse?
7. Is there a target date that is driving decisions?

---
name: stripe-api-actions
description: Use Stripe's live REST API for authenticated write actions. Use when you need to create or update Stripe customers, products, prices, payment links, refunds, subscriptions, or metadata with a secret key supplied via STRIPE_SECRET_KEY. Keep this separate from read-only inspection when the task changes live billing or payment state.
---

# Stripe API Actions

Use this skill for live Stripe write operations.

## Quick start

1. Set `STRIPE_SECRET_KEY` in the current shell environment.
2. Read `references/actions-and-safety.md` for the supported write actions and example commands.
3. Require `--confirm` on every write command.

## Core workflow

### 1. Confirm scope

Before running a write action, identify exactly which Stripe object should change and what the expected result is.

### 2. Use explicit commands

Examples:

```bash
python skills/stripe-api-actions/scripts/stripe_actions.py create_customer --name "Alice" --email "[email protected]" --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_product --name "Monthly Plan" --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_price --product prod_123 --unit-amount 900 --currency eur --interval month --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_payment_link --price price_123 --quantity 1 --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_refund --payment-intent pi_123 --amount 500 --reason requested_by_customer --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py cancel_subscription sub_123 --invoice-now --prorate --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py update_metadata /customers/cus_123 --metadata external_id=42 --confirm
```

### 3. Prefer narrow changes

Prefer creating or updating the minimum necessary object rather than bundling several unrelated changes into one step.

## Safety rules

- Do not store live Stripe secrets in skill files.
- Require `--confirm` for every write action.
- Be cautious with refunds and subscription cancellation.
- If a task affects live money flow or billing state, double-check the target object IDs first.

## Resources

- `scripts/stripe_actions.py` — minimal authenticated Stripe write helper using Python standard library
- `references/actions-and-safety.md` — supported actions, caveats, and example commands

FILE:references/actions-and-safety.md
# Stripe API Actions and Safety

## Purpose

Use this skill for authenticated write actions against Stripe.

## Secret handling

- Read `STRIPE_SECRET_KEY` from the environment.
- Never hardcode live keys in skill files.
- Treat keys shared in chat as compromised and rotate them.

## Supported write actions

- create customer
- update customer
- create product
- create price
- create payment link
- create refund
- cancel subscription
- update metadata on supported objects

## Safety pattern

- Require `--confirm` for every write action.
- Preview the exact command before running it when possible.
- Be extra careful with refunds and subscription cancellation.
- Prefer metadata updates over destructive changes when that solves the need.

## Important notes

- `unit_amount` values are in the smallest currency unit, e.g. cents for EUR/USD.
- `create_price` becomes recurring only when `--interval` is supplied.
- `create_refund` can accept either a payment intent or a charge.
- `cancel_subscription` is immediate cancellation via Stripe API delete semantics.

## Example commands

```bash
python skills/stripe-api-actions/scripts/stripe_actions.py create_customer --name "Alice" --email "[email protected]" --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_product --name "Monthly Plan" --description "Recurring support plan" --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_price --product prod_123 --unit-amount 900 --currency eur --interval month --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_payment_link --price price_123 --quantity 1 --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py update_metadata /customers/cus_123 --metadata external_id=42 --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py create_refund --payment-intent pi_123 --amount 500 --reason requested_by_customer --confirm
python skills/stripe-api-actions/scripts/stripe_actions.py cancel_subscription sub_123 --invoice-now --prorate --confirm
```

FILE:scripts/stripe_actions.py
#!/usr/bin/env python3
import argparse
import json
import os
import urllib.parse
import urllib.request

BASE = "https://api.stripe.com/v1"


def get_key() -> str:
    key = os.environ.get("STRIPE_SECRET_KEY", "").strip()
    if not key:
        raise SystemExit("Missing STRIPE_SECRET_KEY environment variable.")
    return key


def request(method: str, path: str, params=None):
    key = get_key()
    url = BASE + path
    data = None
    headers = {
        "Authorization": f"Bearer {key}",
        "User-Agent": "openclaw-stripe-api-actions-skill/1.0",
    }
    if params:
        encoded = urllib.parse.urlencode(params, doseq=True)
        if method.upper() == "GET":
            url += ("?" if "?" not in url else "&") + encoded
        else:
            data = encoded.encode("utf-8")
            headers["Content-Type"] = "application/x-www-form-urlencoded"
    req = urllib.request.Request(url, data=data, headers=headers, method=method.upper())
    try:
        with urllib.request.urlopen(req, timeout=60) as resp:
            return json.loads(resp.read().decode("utf-8"))
    except urllib.error.HTTPError as e:
        body = e.read().decode("utf-8", errors="replace")
        try:
            parsed = json.loads(body)
        except Exception:
            parsed = {"error": {"message": body, "type": "http_error", "status": e.code}}
        print(json.dumps(parsed, indent=2, ensure_ascii=False))
        raise SystemExit(1)


def print_json(obj):
    print(json.dumps(obj, indent=2, ensure_ascii=False))


def parse_metadata(items):
    result = {}
    for item in items or []:
        if "=" not in item:
            raise SystemExit(f"Invalid metadata item: {item}. Expected key=value")
        key, value = item.split("=", 1)
        result[key] = value
    return result


def require_confirm(args):
    if not getattr(args, "confirm", False):
        raise SystemExit("Refusing write action without --confirm")


def main():
    p = argparse.ArgumentParser(description="Stripe write-capable helper for OpenClaw skill use")
    sub = p.add_subparsers(dest="cmd", required=True)

    cust = sub.add_parser("create_customer", help="Create customer")
    cust.add_argument("--name")
    cust.add_argument("--email")
    cust.add_argument("--phone")
    cust.add_argument("--description")
    cust.add_argument("--metadata", action="append", default=[])
    cust.add_argument("--confirm", action="store_true")

    upd_cust = sub.add_parser("update_customer", help="Update customer")
    upd_cust.add_argument("customer_id")
    upd_cust.add_argument("--name")
    upd_cust.add_argument("--email")
    upd_cust.add_argument("--phone")
    upd_cust.add_argument("--description")
    upd_cust.add_argument("--metadata", action="append", default=[])
    upd_cust.add_argument("--confirm", action="store_true")

    prod = sub.add_parser("create_product", help="Create product")
    prod.add_argument("--name", required=True)
    prod.add_argument("--description")
    prod.add_argument("--metadata", action="append", default=[])
    prod.add_argument("--confirm", action="store_true")

    price = sub.add_parser("create_price", help="Create price")
    price.add_argument("--product", required=True)
    price.add_argument("--unit-amount", required=True, type=int)
    price.add_argument("--currency", required=True)
    price.add_argument("--interval", choices=["day", "week", "month", "year"])
    price.add_argument("--confirm", action="store_true")

    link = sub.add_parser("create_payment_link", help="Create payment link")
    link.add_argument("--price", required=True)
    link.add_argument("--quantity", type=int, default=1)
    link.add_argument("--confirm", action="store_true")

    refund = sub.add_parser("create_refund", help="Create refund")
    refund.add_argument("--payment-intent")
    refund.add_argument("--charge")
    refund.add_argument("--amount", type=int)
    refund.add_argument("--reason", choices=["duplicate", "fraudulent", "requested_by_customer"])
    refund.add_argument("--confirm", action="store_true")

    cancel = sub.add_parser("cancel_subscription", help="Cancel subscription")
    cancel.add_argument("subscription_id")
    cancel.add_argument("--invoice-now", action="store_true")
    cancel.add_argument("--prorate", action="store_true")
    cancel.add_argument("--confirm", action="store_true")

    meta = sub.add_parser("update_metadata", help="Update metadata on a supported object path")
    meta.add_argument("path", help="API path like /customers/cus_123 or /products/prod_123")
    meta.add_argument("--metadata", action="append", default=[], required=True)
    meta.add_argument("--confirm", action="store_true")

    args = p.parse_args()

    if args.cmd == "create_customer":
        require_confirm(args)
        params = {k: v for k, v in {
            "name": args.name,
            "email": args.email,
            "phone": args.phone,
            "description": args.description,
        }.items() if v is not None}
        for k, v in parse_metadata(args.metadata).items():
            params[f"metadata[{k}]"] = v
        print_json(request("POST", "/customers", params))
        return

    if args.cmd == "update_customer":
        require_confirm(args)
        params = {k: v for k, v in {
            "name": args.name,
            "email": args.email,
            "phone": args.phone,
            "description": args.description,
        }.items() if v is not None}
        for k, v in parse_metadata(args.metadata).items():
            params[f"metadata[{k}]"] = v
        print_json(request("POST", f"/customers/{args.customer_id}", params))
        return

    if args.cmd == "create_product":
        require_confirm(args)
        params = {"name": args.name}
        if args.description is not None:
            params["description"] = args.description
        for k, v in parse_metadata(args.metadata).items():
            params[f"metadata[{k}]"] = v
        print_json(request("POST", "/products", params))
        return

    if args.cmd == "create_price":
        require_confirm(args)
        params = {
            "product": args.product,
            "unit_amount": args.unit_amount,
            "currency": args.currency,
        }
        if args.interval:
            params["recurring[interval]"] = args.interval
        print_json(request("POST", "/prices", params))
        return

    if args.cmd == "create_payment_link":
        require_confirm(args)
        params = {
            "line_items[0][price]": args.price,
            "line_items[0][quantity]": args.quantity,
        }
        print_json(request("POST", "/payment_links", params))
        return

    if args.cmd == "create_refund":
        require_confirm(args)
        if not args.payment_intent and not args.charge:
            raise SystemExit("Provide --payment-intent or --charge")
        params = {}
        if args.payment_intent:
            params["payment_intent"] = args.payment_intent
        if args.charge:
            params["charge"] = args.charge
        if args.amount is not None:
            params["amount"] = args.amount
        if args.reason:
            params["reason"] = args.reason
        print_json(request("POST", "/refunds", params))
        return

    if args.cmd == "cancel_subscription":
        require_confirm(args)
        params = {
            "invoice_now": "true" if args.invoice_now else "false",
            "prorate": "true" if args.prorate else "false",
        }
        print_json(request("DELETE", f"/subscriptions/{args.subscription_id}", params))
        return

    if args.cmd == "update_metadata":
        require_confirm(args)
        path = args.path if args.path.startswith("/") else f"/{args.path}"
        params = {}
        for k, v in parse_metadata(args.metadata).items():
            params[f"metadata[{k}]"] = v
        print_json(request("POST", path, params))
        return


if __name__ == "__main__":
    main()

---
name: stripe-api
description: Use Stripe's live REST API for authenticated account inspection and operational lookup. Use when you need to connect to a Stripe account with a secret key, inspect account details, list customers/products/prices/payments/subscriptions/invoices/refunds/disputes/payouts/webhook endpoints, or retrieve a specific Stripe object safely via read-only commands.
---

# Stripe API

Use this skill for real Stripe API access.

## Quick start

1. Set `STRIPE_SECRET_KEY` in the local shell environment.
2. Start with read-only inspection:
   - `python skills/stripe-api/scripts/stripe_api.py account`
   - `python skills/stripe-api/scripts/stripe_api.py payment_intents --limit 10`
   - `python skills/stripe-api/scripts/stripe_api.py customers --limit 10`
3. Read `references/objects-and-workflows.md` when you need object guidance or a sensible inspection order.

## Core workflow

### 1. Verify access

Run:

```bash
python skills/stripe-api/scripts/stripe_api.py account
```

If this fails with authentication errors, fix the environment variable first.

### 2. Inspect the account safely

Use read-only list commands first:

```bash
python skills/stripe-api/scripts/stripe_api.py products --limit 20
python skills/stripe-api/scripts/stripe_api.py prices --limit 20
python skills/stripe-api/scripts/stripe_api.py payment_intents --limit 20
python skills/stripe-api/scripts/stripe_api.py charges --limit 20
python skills/stripe-api/scripts/stripe_api.py invoices --limit 20
python skills/stripe-api/scripts/stripe_api.py subscriptions --limit 20
python skills/stripe-api/scripts/stripe_api.py payouts --limit 20
python skills/stripe-api/scripts/stripe_api.py disputes --limit 20
python skills/stripe-api/scripts/stripe_api.py webhook_endpoints --limit 20
```

### 3. Retrieve a known object directly

```bash
python skills/stripe-api/scripts/stripe_api.py get /customers/cus_123
python skills/stripe-api/scripts/stripe_api.py get /payment_intents/pi_123
```

### 4. Search customers

```bash
python skills/stripe-api/scripts/stripe_api.py search_customers "email:'[email protected]'"
```

## Safety rules

- Do not put live secrets in the skill files.
- Do not commit or publish secrets.
- Default to read-only operations.
- Before any write action in the future, confirm with the user.
- Treat secrets shared in chat as compromised and recommend rotation.

## Resources

- `scripts/stripe_api.py` — minimal authenticated Stripe API helper using only Python standard library
- `references/objects-and-workflows.md` — common Stripe objects, safe inspection order, and search examples

FILE:references/objects-and-workflows.md
# Stripe API Objects and Workflows

## Read-first safety rules

- Treat any `sk_live_...` secret as highly sensitive.
- Never store live keys in `SKILL.md`, scripts, git-tracked files, or chat transcripts.
- Prefer environment variable `STRIPE_SECRET_KEY`.
- Default to read-only inspection first.
- Ask before any write action that could move money, refund, cancel, or modify billing state.

## Common objects

- `account`: Stripe account identity, business profile, capabilities
- `customers`: people or businesses you bill
- `products`: what you sell
- `prices`: billing terms for products
- `payment_intents`: payment lifecycle state machine
- `charges`: resulting charge records
- `subscriptions`: recurring billing contracts
- `invoices`: billing documents and payment attempts
- `refunds`: money returned to customers
- `disputes`: chargebacks and card disputes
- `payouts`: transfers from Stripe balance to bank
- `balance_transactions`: ledger-style balance events
- `webhook_endpoints`: webhook destinations configured on the account

## Suggested inspection flow

1. Retrieve `/account`
2. List recent `payment_intents`, `charges`, and `invoices`
3. List `products` and `prices`
4. List `subscriptions` if recurring billing matters
5. Inspect `payouts`, `balance_transactions`, and `disputes`
6. Inspect `webhook_endpoints`

## Useful customer search examples

Customer search query language examples:

- `email:'[email protected]'`
- `name:'Alice Example'`
- `metadata['external_id']:'12345'`

## Write actions to add later carefully

Possible future additions:

- create customer
- create product
- create price
- create refund
- cancel subscription
- create checkout session / payment link

Keep those separate from read-only inspection commands and require explicit user confirmation before use.

FILE:scripts/stripe_api.py
#!/usr/bin/env python3
import argparse
import json
import os
import urllib.parse
import urllib.request

BASE = "https://api.stripe.com/v1"


def get_key() -> str:
    key = os.environ.get("STRIPE_SECRET_KEY", "").strip()
    if not key:
        raise SystemExit("Missing STRIPE_SECRET_KEY environment variable.")
    return key


def request(method: str, path: str, params=None):
    key = get_key()
    url = BASE + path
    data = None
    headers = {
        "Authorization": f"Bearer {key}",
        "User-Agent": "openclaw-stripe-api-skill/1.0",
    }
    if params:
        encoded = urllib.parse.urlencode(params, doseq=True)
        if method.upper() == "GET":
            url += ("?" if "?" not in url else "&") + encoded
        else:
            data = encoded.encode("utf-8")
            headers["Content-Type"] = "application/x-www-form-urlencoded"
    req = urllib.request.Request(url, data=data, headers=headers, method=method.upper())
    try:
        with urllib.request.urlopen(req, timeout=60) as resp:
            return json.loads(resp.read().decode("utf-8"))
    except urllib.error.HTTPError as e:
        body = e.read().decode("utf-8", errors="replace")
        try:
            parsed = json.loads(body)
        except Exception:
            parsed = {"error": {"message": body, "type": "http_error", "status": e.code}}
        print(json.dumps(parsed, indent=2, ensure_ascii=False))
        raise SystemExit(1)


def print_json(obj):
    print(json.dumps(obj, indent=2, ensure_ascii=False))


def main():
    p = argparse.ArgumentParser(description="Minimal Stripe API helper for OpenClaw skill use")
    sub = p.add_subparsers(dest="cmd", required=True)

    sub.add_parser("account", help="Retrieve account details")

    for name, help_text in [
        ("customers", "List customers"),
        ("products", "List products"),
        ("prices", "List prices"),
        ("charges", "List charges"),
        ("payment_intents", "List payment intents"),
        ("subscriptions", "List subscriptions"),
        ("invoices", "List invoices"),
        ("refunds", "List refunds"),
        ("disputes", "List disputes"),
        ("payouts", "List payouts"),
        ("balance_transactions", "List balance transactions"),
        ("webhook_endpoints", "List webhook endpoints"),
    ]:
        sp = sub.add_parser(name, help=help_text)
        sp.add_argument("--limit", type=int, default=10)

    search = sub.add_parser("search_customers", help="Search customers")
    search.add_argument("query")
    search.add_argument("--limit", type=int, default=10)

    get_obj = sub.add_parser("get", help="Retrieve an object by API path, e.g. /customers/cus_123")
    get_obj.add_argument("path")

    args = p.parse_args()

    if args.cmd == "account":
        print_json(request("GET", "/account"))
        return

    listing = {
        "customers": "/customers",
        "products": "/products",
        "prices": "/prices",
        "charges": "/charges",
        "payment_intents": "/payment_intents",
        "subscriptions": "/subscriptions",
        "invoices": "/invoices",
        "refunds": "/refunds",
        "disputes": "/disputes",
        "payouts": "/payouts",
        "balance_transactions": "/balance_transactions",
        "webhook_endpoints": "/webhook_endpoints",
    }
    if args.cmd in listing:
        print_json(request("GET", listing[args.cmd], {"limit": args.limit}))
        return

    if args.cmd == "search_customers":
        print_json(request("GET", "/customers/search", {"query": args.query, "limit": args.limit}))
        return

    if args.cmd == "get":
        path = args.path if args.path.startswith("/") else f"/{args.path}"
        print_json(request("GET", path))
        return


if __name__ == "__main__":
    main()

---
name: software-team-conflict-patterns
description: Help analyze recurring conflict patterns on software or game projects by identifying likely collaboration archetypes, behavior patterns, project risks, and practical response strategies. Use when someone describes a teammate, lead, founder, stakeholder, client, producer, or collaborator whose recurring behavior is creating friction, slowing decisions, damaging trust, or disrupting execution. Focus on observable behavior and project consequences, not clinical diagnosis, then suggest safer and more effective next moves.
---

# Software Team Conflict Patterns

Analyze recurring collaboration problems without pretending to diagnose people.

Use this skill when the user describes a difficult person or recurring team conflict on a software or game project and needs help understanding the likely behavior pattern, why it causes friction, and how to respond productively. The goal is not to label people for sport. The goal is to identify useful patterns, protect project progress, and suggest practical next moves.

Read `references/neil-on-software-archetypes.md` when you need the full 48-archetype taxonomy from the Neil on Software source material, including mutation paths, dangerous pairings, likelihood-of-fixing signals, danger-to-project signals, and extracted fix strategies.
Read `references/pattern-notes.md` when you need a shorter local shorthand set of patterns.
Read `references/response-strategies.md` when you need guidance on boundaries, documentation, reframing, escalation, and other response moves.

## Core behavior

- Focus on observable behavior, not amateur clinical diagnosis.
- Treat archetypes as rough pattern labels, not absolute truth.
- Explain uncertainty when the situation could fit multiple patterns.
- Prioritize practical response strategy over moral judgment.
- Consider both the difficult behavior and the surrounding team system that enables or amplifies it.
- Distinguish between a one-off bad moment and a recurring pattern.
- Suggest safer next moves when the situation involves power imbalance, retaliation risk, or trust collapse.
- Avoid revenge logic, humiliation tactics, or manipulative advice.

## What to ask first

Prioritize these questions:
1. What is happening?
2. Who is involved and what role does each person have?
3. What recurring behavior or pattern are you seeing?
4. How is it affecting the project, team, or decisions?
5. What have you already tried?
6. What outcome do you want?
7. Is there a power imbalance, dependency, or retaliation risk?

If the user gives only a short story, infer the likely conflict pattern carefully and state assumptions.

## What to diagnose

Quickly identify:
- the recurring behavior pattern or archetype that best fits the description
- whether multiple patterns may be interacting
- whether the issue is primarily about ego, control, avoidance, indecision, chaos, blame-shifting, status signaling, or weak communication
- whether the team context is rewarding or enabling the behavior
- what bad responses are likely to escalate the problem
- what realistic response options the user actually has

Prefer the exact archetype names from the source material instead of inventing new labels when one of the named patterns fits.

## Named archetypes from the source material

Default to the 48 Neil on Software archetypes documented in `references/neil-on-software-archetypes.md`.

Use the exact archetype label when it fits. If the story does not fit one cleanly, say which two or three named archetypes are most relevant and explain why. If a locally downloaded source page was missing for one of the 48, say that the archetype name is part of the taxonomy but the local notes are incomplete.

Also use these source-material signals when available:
- what the archetype can mutate into
- what it is dangerous when coupled with
- likelihood of fixing
- danger to project
- the extracted fix or mitigation strategy

## Response structure

Always organize the answer using this structure.

### Situation Summary
- summarize the conflict in plain language
- state the actual project problem, not just the personality problem

### Likely Conflict Pattern(s)
- identify the most likely named archetype from the source material
- use the exact archetype label when possible
- mention uncertainty if more than one pattern fits
- if relevant, list a primary archetype and secondary archetype
- mention mutation paths or dangerous pairings if they materially increase the risk

### Evidence in the Story
- point to the behaviors that support the reading
- distinguish observed facts from interpretation

### Risks if This Continues
- project risks
- communication risks
- trust or morale risks
- escalation risks
- whether the source material marks the archetype as especially dangerous to the project or especially likely/unlikely to fix

### Recommended Strategy
- how to communicate
- what to document
- what boundaries to set
- what to avoid
- whether to escalate, reframe, narrow decisions, or create process guardrails
- incorporate the source-material fix strategy, but translate it into realistic team-safe action rather than copying it blindly

### Practical Next Move
- suggest the next useful conversation, message, meeting move, or documentation step

## Style guidance

- Be practical, not theatrical.
- Do not write the person off as evil unless the behavior clearly warrants bluntness.
- Do not promise that one clever sentence will fix deep structural conflict.
- Prefer small strategic moves over fantasy confrontation scenes.
- If the user has little power, optimize for safety and documentation, not dominance.
- If the system around the person is the real problem, say so.

## Important cautions

- Do not diagnose mental illness.
- Do not recommend manipulation, humiliation, or retaliation.
- Do not assume malicious intent when incompetence, fear, incentives, or confusion may explain the behavior.
- Do not treat pattern labels as identity-level truth.
- Recommend escalation carefully when the user faces role or power risk.

## Fast mode

Use this compressed flow when the user wants a quick answer:
- what recurring behavior is happening
- which named archetype from the source material it most resembles
- why it is damaging the project
- what response is most likely to help
- what should the user do next

## Working principle

A difficult project person is not just a personality puzzle. They are a recurring behavior pattern interacting with incentives, power, habits, and team structure. The useful question is not "what is wrong with them?" but "which named archetype or combination of archetypes best matches the recurring behavior, what damage is it causing, and what is the smartest safe response?"

FILE:references/neil-on-software-archetypes.md
# Neil on Software Difficult-People Archetypes

## What this reference contains

- 48 archetypes named in the downloaded Neil on Software pages and navigation
- Detailed notes for the 40 archetypes with local source pages present in `C:\Users\Big Dell\Downloads\Difficult People`
- Mention-only placeholders for 8 archetypes whose names appear in the navigation but whose individual pages were not present locally
- For detailed entries: role, one-line definition, mutation paths, dangerous pairings, likelihood of fixing, danger to project, and extracted problem/solution notes

## Category index

### Product Managers
- [The People Pleaser](#the-people-pleaser)
- [The Scope Wiggler](#the-scope-wiggler)
- [The Patent Author](#the-patent-author)
- [The Napkin Sketcher](#the-napkin-sketcher)
- [The Executive Assistant](#the-executive-assistant)
- [The Sales Liaison](#the-sales-liaison)
- [The Dictator](#the-dictator)
- [The Scope Creeper](#the-scope-creeper)

### Designers
- [The Note Taker](#the-note-taker)
- [The Disenfranchised](#the-disenfranchised)
- [The Artist](#the-artist)
- [The Professor](#the-professor)
- [The Distrusted](#the-distrusted)
- [The Blueprinter](#the-blueprinter)

### Project Managers
- [The Meeting Scheduler](#the-meeting-scheduler)
- [The Statistician](#the-statistician)
- [The Delusional](#the-delusional)
- [The Pessimist](#the-pessimist)
- [The Optimist](#the-optimist)
- [The Cheerleader](#the-cheerleader)
- [The Tyrant](#the-tyrant)
- [The Process Obsessed](#the-process-obsessed)
- [The Hoverer](#the-hoverer)

### Dev Managers
- [The Formerly Technical](#the-formerly-technical)
- [The Non-Technical](#the-non-technical)
- [The Ladder Climber](#the-ladder-climber)
- [The Peacemaker](#the-peacemaker)
- [The Wants-to-be-Technical](#the-wants-to-be-technical)

### Software Developers
- [The Diva](#the-diva)
- [The Idealist](#the-idealist)
- [The Rockstar](#the-rockstar)
- [The Aspiring Manager](#the-aspiring-manager)
- [The Hostage Taker](#the-hostage-taker)
- [The Bull in the China Shop](#the-bull-in-the-china-shop)
- [The Incompetent](#the-incompetent)
- [The Extreme Underestimator](#the-extreme-underestimator)
- [The Extreme Overestimator](#the-extreme-overestimator)
- [The Soldier](#the-soldier)
- [The Technology Enamored](#the-technology-enamored)
- [The Legacy Maintainer](#the-legacy-maintainer)

### Testers
- [The Firehose](#the-firehose)
- [The Blamer](#the-blamer)
- [The Alarmist](#the-alarmist)
- [The Scientist](#the-scientist)
- [The Misleader](#the-misleader)
- [The Downtrodden](#the-downtrodden)
- [The Random Clicker](#the-random-clicker)
- [The Flippant](#the-flippant)

## How to use this reference inside the skill

- Prefer the exact archetype names from this source when a story clearly matches one.
- If the situation mixes patterns, name a primary archetype and one or two secondary archetypes.
- Use mutation paths and dangerous pairings as risk multipliers, not as deterministic predictions.
- Treat `Likelihood of fixing` and `Danger to project` as rough triage signals.
- Use the `Fix/strategy notes` as source-derived guidance, then translate them into safer team-language and concrete next moves.
- Do not treat these labels as diagnosis or identity-level truth.

## Recommended reading order per case

1. Archetype name and role
2. Definition
3. Mutation paths and dangerous pairings
4. Likelihood of fixing and danger to project
5. Fix/strategy notes
6. Problem notes only when deeper context is needed

## Product Managers

### The People Pleaser

- **Role:** Product Manager
- **Definition:** who believes their core job responsibility is to seek concessions and compromises between the development teams and stakeholders.
- **Can mutate into:** The Executive Assistant, The Sales Liaison
- **Dangerous when coupled with:** The Disenfranchised
- **Likelihood of fixing:** None
- **Danger to project:** High
- **Problem notes:** Product Managers often have to mediate between two groups comprising of very strong personalities: Stakeholders, who know what they want the product to do Developers, who know how to build the product Optimally, the relationship between stakeholders and developers is one of collaborative give-and-take, but often it is quite contentious. The People Pleaser Product Manager finds themselves unable to control these two groups, and instead tries to build consensus through a series of compromises, resulting in neither group being happy with the final product. It is fair to say that the People Pleaser Product Manager has given up managerial control over the product. Instead, they are only mediating between stakeholders and developers in an attempt to document whatever both parties can agree to or live with. As they normally have to do this under time pressure, it is the ideal circumstance for groupthink. Products developed by groupthink are easy to identify: no one likes the final product. “Design through compromise” is a recipe for disaster, as it can result in an unsalable product. If the initial product offering is rejected by customers, the project will most certainly be declared a failure, and it is unlikely that it will be allowed to continue.
- **Fix/strategy notes:** To manage two groups made up of strong personalities requires a great deal of managerial skill and experience. A firm but fair hand must be used to settle down each group, and align them towards the common goal of building a great product. This high managerial bar is what makes the People Pleaser so difficult to fix: If they were capable of controlling both groups, they would have already. People who have the capability to effectively manage groups comprising of strong personalities will have most likely been promoted out of the role of being a Product Manager, as this is a key attribute of upper management. Ultimately, if the stakeholder and developers cannot be coached into working together more effectively, the People Pleaser Product Manager will have to be replaced. Not doing so will, in all likelihood, result in the project producing an unsalable product, and therefore the project being canceled.
- **Local source:** `The People Pleaser - Neil on Software.html`

### The Scope Wiggler

- **Role:** Product Manager
- **Definition:** who bypasses change control and impact analysis by presenting a big requirements change as a series of small changes distributed over time.
- **Can mutate into:** The Scope Creeper
- **Dangerous when coupled with:** The Disenfranchised, The Soldier
- **Likelihood of fixing:** Low
- **Danger to project:** High
- **Problem notes:** Agile and Waterfall methodologies both have mechanisms to limit, track, and control change: Agile methodologies are built around giving full visibility to changes, such that all team members have the ability to adapt to the change. Waterfall methodologies have change control committees, that often include an impact analysis before approving the change. But what if a Product Manager wants to quietly correct their mistakes in order to protect the perception that they write solid requirements? As all projects have a tolerance for small changes, they can get a big change done under-the-radar by simply presenting their big change as a series of small changes over time. This devious method of Product Management causes the project to decay from the inside-out at every level: Project Managers are denied the benefits of having full visibility into requirements changes, and therefore cannot appropriately set expectations with project stakeholders. Developers are denied the opportunity to design a holistic solution to the big change, often resulting in them having to throw out large amounts of work once they realize the true intent of the small series of changes. QA must constantly adjust test cases, often only after realizing that they failed to catch bugs in a feature that had requirements changed they were not aware of. The Scope Wiggler Product Manager’s true damage is likely seen through the decay in the quality of the codebase. By keeping their end goal a secret, developers are lured into bending the code gradually over time until it can no longer be bent. When code has gotten into this state, it is normally costly to fix, and so it never is. This phenomenon is at the heart of most monolithic legacy code bases that can no longer be adapted to meet new requirements. The Scope Wiggler Product Manager is the most insidious of all Product Manager personalities. They most likely have self-elected to wiggle scope, and see it as an effective way of them getting what they want. Their particular brand of achieving their end goals often leaves the project in shambles as it dies a death of a thousand cuts.
- **Fix/strategy notes:** The Scope Wiggler Product Manager has decided that the most effective way to influence the direction of the product is through deception and deceit. This stems from personal belief that are not quickly or easily changed: They believe they cannot be seen as having made a mistake. They care more about getting their job done than about the success of the project as a whole. They do not care about the difficulties they are inflicting on others. As a result, fixing the Scope Wiggler Product Manager is as easy as changing their innate character. Perhaps with a compelling enough personal coaching, they can be made more confident in themselves in admitting mistakes, more committed to overall project success, and more empathetic to their teammates. However, the required shift in character is so great that at best only lip-service will be provided, and instead of improving, they will only become more cunning and subtle in how they go about getting their way.
- **Local source:** `The Scope Wiggler - Neil on Software.html`

### The Patent Author

- **Role:** Product Manager
- **Definition:** who produces such a high volume of requirements documentation that it creates a barrier to adapting to change, as the documentation must be kept up to date.
- **Can mutate into:** The Dictator
- **Dangerous when coupled with:** The Blueprinter, The Scientist
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** The core responsibility of a Product Manager is to articulate business requirements. On small development teams this can be done verbally, or through the use of terse requirements documents where the expectation is that the Product Manager will be consulted for details. On large projects (especially those involving remote teams) these requirements documents must be much more explicit, with minutia clearly spelled out to erase ambiguity that could lead to features being implemented incorrectly. The Patent Author Product Manager has written documentation so far out of proportion to what is needed, that they have introduced significant cost to making even the smallest change. Generally, Developers do not enjoy reading long requirements documents, as they are dull, boring, and remove any opportunity for Developer creativity. QA, on the other hand, have the opposite reaction, as it makes writing test cases far easier if requirements details are spelled out in advance. However, verbose documentation comes at a cost: the documentation itself has to be reviewed, approved, and maintained every time there is a change. The issue with the Patent Author Product Manager is one of change cost, which leads directly to opportunity cost. With the care and feeding of tomes of documents, the following legitimate sources of change have potentially huge project impacts: Threats from competing products. Feedback based on a customer reviews. Changed required due to technical feasibility constraints. Reduction to scope necessary to meet deadlines. Changes of opinion among stakeholders upon actual use of the product. As the volume of documentation increases, the ability of the project to adapt to these changes decreases, yet over the lifetime of the product changes such as these are inevitable.
- **Fix/strategy notes:** Bear in mind that the Patent Author Product Manager is only a problem when their level of documentation is substantially more than the project requires. There are many legitimate situations where explicit documentation is essential: Projects requiring non-trivial integrations, whereby all parties involved must build to a common specification for the integration to go smoothly. Projects that have hardware components, in that changing the hardware after manufacture is impossible. Projects involving remote teams across multiple time-zones such that documentation is the only practical means of communicating requirements. Project involving outside contractors, where project deliverables are tied to contracts, and therefore must be clearly articulated. If the Patent Author Project Manager has proven to be problematic, the solution is to characterize the project as being Agile, as opposed to Waterfall. This difference is well understood as it relates to documentation, so simple defining the project as Agile and phasing out the existing documentation will eventually solve the problem. The challenge then is to educate the Product Manager on Agile methodologies, and provided they are open to the change (which they often are, as Agile places less demands on them) many educational resources exist.
- **Local source:** `The Patent Author - Neil on Software.html`

### The Napkin Sketcher

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Executive Assistant

- **Role:** Product Manager
- **Definition:** who only documents what the stakeholders have asked for, but denies access to the stakeholders, such that requirements cannot be negotiated.
- **Can mutate into:** The Dictator, The Patent Author
- **Dangerous when coupled with:** The Disenfranchised, The Tyrant
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** A key component of being a Product Manager is collecting feature requests from stakeholders, and codifying these requirements into a holistic product vision. These stakeholders can have very strong personalities, as they tend to be higher up in the organization. As a result, they can force the Product Manager into a position of pure documentation, removing the Product Manager from the decision making process. With the belief that the will of the stakeholders is written in stone, the Executive Assistant Product Manager then simply hands the requirements to the development team, claiming that this is what has to be built, as this is what was asked for by the stakeholders. The Executive Assistant Product Manager’s key issue is that they eliminate collaboration between the people defining the work, and the people doing the work. Claiming that they represent the immutable will of the stakeholders, they will appear exasperated at any questioning of the requirements, and will simply state that “This is what was asked for.” Unfortunately, this is a fallacy, as what is in the documentation is the Executive Assistants interpretation of what the stakeholders have asked for, rather than what the stakeholders may truly want if given the opportunity to directly collaborate with the development team. To make matters worse, it is common for the Executive Assistant product manager to present the inverse situation to the stakeholders: that the development team does not wish to speak to them directly. Excuses can range from the developers being “Too technical” to communicate at a level the stakeholders would understand, or “Too busy” to engage in open-ended conversations about product direction.
- **Fix/strategy notes:** The solution to an Executive Assistant product manager is to simply go around them, and call collaborative meetings between the stakeholders and the development teams. Indeed, this is a key tenet of Agile methodologies. At this point, they are documenting what is collaboratively decided, rather than their interpretation of what the stakeholders asked for. This may come as a relief, or as a slight, depending on how this change is interpreted by the Product Manager.
- **Local source:** `The Executive Assistant - Neil on Software.html`

### The Sales Liaison

- **Role:** Product Manager
- **Definition:** who is only concerned with meeting the demands of the sales team, giving no thought to a holistic product vision.
- **Can mutate into:** The Executive Assistant, The Dictator
- **Dangerous when coupled with:** The Note Taker
- **Likelihood of fixing:** Low
- **Danger to project:** Low
- **Problem notes:** The sales team within an organization is tasked with closing sales in order to drive revenue. This fact can lead a Product Manager to believe that this is the entirety of their role: to transmit requirements from the sales team to the product development team. This has the undesirable effect of leaving the product directionless, as it is pulled from one disjointed requirement to the other, as it lacks any overarching product vision. A Product Manager who quickly and accurately documents and hands off requirements coming from the sales team to the development team is generally considered to be good at their job. The problem, however, is that satisfying individual requests from customers will lead to a bloated product over time, comprised of features that appeal to only a few customers. The longer this is allowed to go on, the more disjointed and clumsy the product will seem. Capturing what customers are asking for is vitally important to ensure a sellable product is being developed. However, a Product Manager must also have a vision for what the product offering is, such that it can be relevant to as many customers as possible. If their only purpose is to transmit requirements from the sales organization to the development organization, their job can be done by a collaborative requirements reporting system, where the sales team directly submits feature requests to the development team.
- **Fix/strategy notes:** “Vision” is not something can be trained, taught, or coached: either the product manager has a vision for the product, or they do not. Unfortunately, if they had a vision for the project, they would not have allowed themselves to become a Sales Liaison, as they would have been influencing the product all along rather than just passing off requirements. The way to address the Sales Liaison is to move them into a marketing function, with their job being defined as capturing customer feedback from sales. This documentation would then need to be given to the new Product Manager who can incorporate this customers feedback into the new overarching product vision.
- **Local source:** `The Sales Liaison - Neil on Software.html`

### The Dictator

- **Role:** Product Manager
- **Definition:** that rejects any idea that did not come from them.
- **Can mutate into:** The Patent Author
- **Dangerous when coupled with:** The Diva
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** Despite a movement towards collaboration, the software development industry still has a clear division of labor: Product Managers write the requirements, and Developers write the software. There are Product Managers who believe that Developers should only write software, and that the defining of requirements should be done exclusively by them. This mindset then prevents developers from providing the Product Manager feedback on: The cost of a feature, allowing the Product Manager to make prudent choices on the relative importance of what they are asking for. Simplifications in features that would allow a faster time to market without reducing the product’s business value. Changes in features to allow the development team to use preexisting capabilities, or to use off-the-shelf solutions. The Dictator Product Manager either has not realized the benefits of collaborating with developers, or has decided that this level of collaboration is not worth doing. It is rare that a Product Manager would not be aware of these benefits, and it is therefore much more common that they feel it is not worth doing. Sadly, this is most often a result of bad past experiences with Developer collaboration. There are some situations where Developers should implement the requirements handed to them without question, as when the Product Manager is an expert in a domain the Developers know nothing about. However, these situations are not common, and generally projects will benefit immensely from having Developers give their input to the requirements.
- **Fix/strategy notes:** If The Dictator Product Manager does not realize the benefits of collaboration with developers, a relatively short discussion with them from upper management will settle this rather quickly. This will most likely come as a relief, as they can now share ownership of the product direction, reducing their burden to be perfect in every product decision. More often, however, The Dictator Product Manager has been made through bad past experiences with developers where: They were subtly or not-so-subtly accused of not knowing how to do their job, or of being little value to the project. They were seen as merely shepherds of requirements (see “ The Executive Assistant “), rather than having any real decision making power, and therefore having no say in product direction. After “collaboration”, very little of their original product direction remained, as developers chipped away at requirements claiming requirements were wrong or technically unfeasible. As bad past experiences are the cause of this variant of The Dictator, the solution is to create good new experiences. To this end, a representative of the developers should approach The Dictator with assurances that the experience of collaboration with them will be pleasant and productive (see “ The Peacemaker ” Development Manager). This same representative should then facilitate developer requirements review meetings to keep the collaboration healthy, shutting down developers who would squander any nascent goodwill.
- **Local source:** `The Dictator - Neil on Software.html`

### The Scope Creeper

- **Role:** Product Manager
- **Definition:** who increases the scope of a project while keeping the delivery date the same.
- **Can mutate into:** The Scope Wiggler
- **Dangerous when coupled with:** The Tyrant
- **Likelihood of fixing:** None
- **Danger to project:** Extremely High
- **Problem notes:** For as long as projects have existed in human history, the Scope Creeper Product Manager has existed. In our everyday life, scope creep is the norm for things as simple as grocery shopping to as complex as home renovations. On a software development project, the consequences of a Scope Creeper Product Manager can be dire, as increasing scope without moving the delivery date will directly result in project failure. To be a Scope Creeper, the Product Manager must have following two characteristics: They define the scope They set the delivery date The Scope Creeper is a problem because they will not give the project more time to build the additional scope they have added. For any project, there is a overwhelming probability that scope will increase thanks to: Customer feature requests that, if not met, will result in lost revenue. Requirements that were always desired by the stakeholder were never documented by the Project Manager. Competitive pressure putting more demands on the product’s feature set (especially true of long-running projects). Also, for any project, there is a overwhelming pressure to meet a delivery date thanks to: Keeping the faith of the stakeholders Keeping the project within budget Meeting revenue targets Meeting contractual obligations The Scope Creeper Product Manager is caught between a rock and a hard place, and has made the choice that asking the project team to produce more in the same amount of time is a better option than trimming scope. Across the software development industry, the Scope Creeper is the #1 source of misery for project team members, as there are only two ways to produce more in the same period of time: Increase efficiency Work more hours If a project team is lucky, they can simply improve efficiency to absorb the additional scope. More often, however, the response is to work more hours, which has the following devastating effects on the project: Top talent will leave, as they can easily get jobs at companies who will not demand long work hours The people remaining will burn out, dramatically reducing their productivity Quality will go out the window at every level, as quality is first to go when long hours are demanded This inevitably results in the project missing it’s deadlines, or meeting them with very low quality, or both resulting in the failure of the project.
- **Fix/strategy notes:** To recap on the phenomenon that results in a Scope Creeper product manager: They have increased scope. The will not move delivery date. The result of increasing scope without moving delivery date will result in project failure. Therefore, by definition Scope Creeper product managers will cause the project to fail. The solution lies in taking one or both of the following course of action Reduce scope. Move delivery date. Which is far easier said than done. Indeed, if it were that easy, there would be no Scope Creeper Product Managers, and the software development industry would be far better off. It is important to realize that an organization creates a Scope Creeper Product Manager by allowing the following tenets to remain in place: Projects must deliver all requirements asked for. Projects must not miss delivery dates. It is acceptable to have employees work overtime to meet delivery dates. Therefore, even if you replace the Scope Creeper Product Manager, their replacement will simply become the new Scope Creeper. As a result, the only solution is to change the organization, and organizational change can rarely be done in time to save a project.
- **Local source:** `The Scope Creeper - Neil on Software.html`

## Designers

### The Note Taker

- **Role:** Designer
- **Definition:** who is relegated to doing nothing more than documenting the ideas of others.
- **Can mutate into:** The Distrusted
- **Dangerous when coupled with:** The Patent Author
- **Likelihood of fixing:** High
- **Danger to project:** Medium
- **Problem notes:** Everyone uses software every day, leading many project team members to feel qualified to comment on what is or isn’t a good User Interface (UI). This typically comes in the form of “I like” or “I don’t like”, and the expectation is that the designer’s job is to capture the likes and dislikes of the group. A Designer operating exclusively in this mode is The Note Taker, whereby they are only capturing the ideas of the group, rather than providing any design direction of their own. All designers must present their design to a project team for acceptance, but what differentiates The Note Taker from a healthy design review process is the order in which documentation is written: If documentation precedes feedback, it is a healthy design review process. If dictation precedes documentation, the designer is only taking notes. The Note Taker is not performing the role of a designer, regardless of their background or true capability. When they are in a pure documentation role, their job can be done by anyone who knows how to use graphics software. Indeed, this is often why The Note Taker is employed: other team members do not know how to produce design documentation with graphics software. The core issue with The Note Taker is that there is no designer on staff. The more complex the requirements, the more a lack of design direction will result in a clumsy UI. All too often, this is how most enterprise software is “designed”: with no designer at all.
- **Fix/strategy notes:** How big a problem The Note Taker is depends entirely on what role the project needs a designer to play. If the stakeholders have specific UI requirements, as they would if the requirements were based on a feature done by their competitors, then the Note Taker is most likely performing the role the project needs them to. If you truly do need design direction and contribution for the project to be successful, which path to take when fixing The Note Taker depends on their skill level: If taking notes is the extent of their capability, you will need to find someone else to fill the role of a designer. If they have simply relegated themselves to their fate of taking notes (see “ The Disenfranchised ” Designer), the design authority needs to be given to them by the project leadership and stakeholders. Granting authority is simple, and costs the organization nothing, provided the Product Managers are confident enough in the designer’s ability. Having been granted this authority, it is then important that the designer works to establish and maintain credibility, or risk their authority being taken away (see “ The Distrusted ” designer).
- **Local source:** `The Note Taker - Neil on Software.html`

### The Disenfranchised

- **Role:** Designer
- **Definition:** who feels they are powerless to influence the design of the project, and therefore are not providing design direction.
- **Can mutate into:** The Note Taker
- **Dangerous when coupled with:** The Dictator, The Diva
- **Likelihood of fixing:** None
- **Danger to project:** None
- **Problem notes:** Everyone has a breaking point, and designers are no different. Many designers working on large software development projects participate in an unfortunate yet predictable sequence of events: They are given vague requirements that they need to interpret. The stakeholders tell them they have free reign to interpret them as they feel best. The designer interprets the requirements into a user interface design that they feel is best for the user. The designer presents their design to the stakeholders. The stakeholders pick apart the design, demanding a long list of changes, many of which ignore basic design principles or will make the product harder to use. The design is resubmitted to the stakeholders. The stakeholders offer commentary on what they think are the remaining problems with the design, resulting in a shorter list of changes which further corrupt the usability and aesthetics of the product. The designer complies, presenting the final design to the stakeholders, which the stakeholders begrudgingly accept with sentiments such as “We can always improve it later”. The designer presents the UI requirements to the development team. The development team complains that the UI designs have poor usability and aesthetics, demanding a long list of changes, many of which ignore basic design principles and will make the product harder to use. The designer complies, presenting a revised design to the development team. The development team begrudgingly agrees that the design is good enough to start implementing. During implementation of the design, the designer is asked to compromise on their design as certain UI requirements will “Take too long to develop” or that they can use off-the-shelf UI components if the design requirements are changed. During QA, the designer attempts to open bugs where the implemented UI does not match the design specification, which the project team argues are low priority bugs. The product ships, and customers complain about the UI, and the designer is blamed. This sequence is more the rule than the exception, and is the main reason many designers of enterprise software are deeply unhappy in their role. In this state of unhappiness, The Disenfranchised designer gives up on trying to influence the design process, and instead just goes through the motions from paycheck-to-paycheck as they look for a new job. As a result, the project no longer has a designer on staff, and the product’s UI slowly spirals into an unusable ugly mess.
- **Fix/strategy notes:** It is easy to mistake The Disenfranchised designer as a case of burnout, to which rest and relaxation are the cure. However, it is not exhaustion or stress that has left the designer in this state of listless unhappiness, it is the process they are forced to follow. It is tempting to believe that the solution is to simply fix the process, but the process is endemic to the software development industry as a whole, and is therefore not easily changed. It is also tempting to believe that replacing the designer is a solution, but the new designer will also quickly become The Disenfranchised. Indeed, with a process that cannot be fixed, there is no fixing the problem. The Disenfranchised designer does not pose a danger to the project, as they are following the process the project asks of them. The only impact is they are not acting as a guard to the deterioration of the product’s UI, which frankly most companies cannot measure and therefore do not care about. Therefore, the long term effect is a successfully delivered project, but with a resulting product that will never live up to its full potential.
- **Local source:** `The Disenfranchised - Neil on Software.html`

### The Artist

- **Role:** Designer
- **Definition:** who is more concerned with how the product looks and feels than if it does anything useful for the end user.
- **Can mutate into:** The Distrusted
- **Dangerous when coupled with:** The Napkin Sketcher
- **Likelihood of fixing:** None
- **Danger to project:** Extremely High
- **Problem notes:** Software development projects build or enhanced products that are hopefully of use to someone. As such, they tend to have utilitarian user interfaces that emphasize function over form. The Artist places more emphasis on form than function, leading to more design direction related to: color; negative-space; font; iconography; animation; transparency; gradients; and shadows; rather than the user’s tasks and goals. The UI requirements are therefore thin on specific interactions, while being very detailed on look and feel. This then leads to churn on UI requirements, as questions will be raised as the product is being built and tested that The Artist has not considered, and typically has no good answers to. In the final analysis, The Artist designer produces poor requirements. Generally, their “requirements” will be nothing more than a series of screen shots defining only how they want the product to look. There will be some placement of controls on the screen, but without detail as to their function. When pressed for details, they will typically refer the developer to the Product Manager’s requirements, expecting the development team to fill in the gaps between a static screen composition and a functioning product. If The Artist is paired with developers that have user interface implementation background, they can most likely fill in the gaps for themselves, but this then leaves QA in a position whereby the do not know how to test the product. A typical sequence of events is as follows: The Artist presents their typically beautiful screen compositions to the stakeholders, which receives rave reviews based purely on its aesthetics. The Artist provides the developers with the same approved screen compositions. The developer fills in gaps in the requirements to the best of their ability. QA then attempts to test the UI, realizing that they are not sure how the product is supposed to function, leading them to ask the stakeholders for clarity. As this is the first time the stakeholders have been exposed to how the UI actually works, they will typically have changes, the extent of which could range from minor tweaks to throwing out the UI completely and starting over. The Artist designer can have a devastating impact on the project’s time lines. They create a situation where there is a high probability that major changes can come very late in the project, potentially causing entire features to be completely rewritten.
- **Fix/strategy notes:** When faced with The Artist, most project team members will say exactly the same thing: “Add more details.” As simple and straightforward this may seem, it is normally beyond the capability of The Artist. Typically, people who go to school for the arts, and/or choose a career in the arts, do not also have the analytical and technical skill required to write detailed system interaction requirements. Indeed, with enough time and effort anyone can learn anything, but this poses yet another problem: The Artists does not want to learn these skills as it takes them away from their true passion. To “fix” The Artist is to change a key aspect of their professional identity, and to a certain degree who they are as a person. This is not reasonable, and in many situations is not desirable. The Artist is not necessarily bad at what they do; it is that they are being asked to do the wrong thing. While they cannot (and perhaps, should not) be fixed, a mitigation strategy is to pair them with an Interaction Designer who has more emphasis on defining the usability of the application, than its look and feel (see “ The Professor ” designer). This partnership of Visual Designer/Interaction Designer is common in the industry for companies with the budget to hire more than one designer.
- **Local source:** `The Artist - Neil on Software.html`

### The Professor

- **Role:** Designer
- **Definition:** so committed to the science and theory of user interface design, that they ignore the UI requirements coming from the stakeholders.
- **Can mutate into:** The Blueprinter
- **Dangerous when coupled with:** The Patent Author
- **Likelihood of fixing:** None
- **Danger to project:** Extremely High
- **Problem notes:** User Interface (UI) design has its roots in Human Computer Interaction (HCI), a field of study that has existed since the early 1980s. The associated research and the resultant best practices – if followed – will result in an easy-to-use UI. Unfortunately, most Product Managers do not know or care about HCI, and specify requirements that fly in the face of decades of HCI research. The Professor Designer responds by simply ignoring the specifics of the requirements, and instead translates the requirements into a UI that is rejected by the Product Managers, halting the project. The Professor designer is the only personality type that can halt the project completely, and as a result is extremely dangerous. Requirements cannot be handed off to developers, as The Professor cannot get approval on the UI from the Product Managers. However, the Professor refuses to change the UI as it is “correct” with regards to HCI-based analysis. The obvious solution is for them to compromise, but they will not, as they view their role as enforcing HCI standards. They are no more likely to change their position than a security analyst making recommendations to patch security holes. Ultimately, they see their job as blocking Product Management’s poor UI decisions – and block them they will. The Professor is only a problem when they do not have absolute control over the User Interface. If they do, the project will flow smoothly and will most likely have a UI the users will love. If they do not, the project will simply stop. If the project has a fixed delivery date, every day the requirements are not handed off is another day the developer cannot begin developing the requirements. This effect is amplified in projects utilizing Waterfall methodologies, where the developers are waiting for all the documentation before they can begin with analysis and implementation. The result is that the project runs out of time having delivered nothing.
- **Fix/strategy notes:** You can no more fix The Professor than you can fix your doctor: If you have a disease, then you have a disease, and their recommendations for treatment will not change just because you disagree with them. Like a doctor, The Professor is doing the job they have been trained to do, and they have conditioned themselves to trust their training regardless of outside objection. The argument could be made that The Professor is not a problem at all, and that it is Product Management who is stepping outside of their area of responsibility. Indeed, this power struggle is why the project has deadlocked. Ultimately, the best solution would be to convince Product Management to give up all UI control, leaving it in the capable hands of The Professor, but then you are removing a large part of a Product Manager’s ability to manage the product.
- **Local source:** `The Professor - Neil on Software.html`

### The Distrusted

- **Role:** Designer
- **Definition:** who has lost all credibility with the project team, leading to their UI requirements being ignored as they are deemed to be not in the products’ best interest.
- **Can mutate into:** The Disenfranchised
- **Dangerous when coupled with:** The Diva, The Legacy Maintainer
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** Designers should be hired based on their portfolio, rather than their resume. This is to make sure that their designer’s tastes and usability standards match that of the project team, which will help provide the much needed credibility they will need later when presenting their designs. Not to hire based on a portfolio leaves it up to chance that their designs will be accepted, and if they are not, they run the serious risk of becoming The Distrusted designer, whereby all of their design direction is ignored by the project team. If a designer is fully capable to not only design simple and intuitive user interactions, as well as beautiful and elegant visual designs, they run a very low risk of having their designs rejected by the project team. This is because, for the most part, everyone can recognize when a UI is well done. However, many designers do not have the necessary mix of HCI science and artistic ability to win over a project team full of highly opinionated individuals. As a result, every imperfect design they put before the project team chips away at their credibility until it is gone. Design, by its nature, is subjective. There is no direct quantitative measure that can determine if a design is good or not, therefore requiring UI designs to be sold, rather than documented and handed off. Not doing so runs the risk of a strong-willed project team simply rejecting the design, and refusing to implement it.
- **Fix/strategy notes:** The solution to fixing the Distrusted Designer depends on their competency. If they lack the competency to do the job required of them, they will have to be removed. If they do have the necessary competency, there are two broad (and complementary) techniques that can be used to establish their credibility with the project team: First, if the rejected designs are the result of the designer documenting what was asked for by the stakeholders (see “ The Note Taker ”), the solution is to have them submit a design that has no influence from the stakeholders. Even if the design is then rejected by the stakeholders, credibility will be reestablished, with the added effect of the project team being sympathetic to the designer’s plight. Second, if a single design solution cannot be edited into one that the project team can accept, the designer can produce multiple design solutions to the same problem. This demonstrates to the project team the designer’s diligence and breadth of skill, while creating a more collaborative design review environment as people feel free to reject a design, but support another.
- **Local source:** `The Distrusted - Neil on Software.html`

### The Blueprinter

- **Role:** Designer
- **Definition:** who specifies every detail of the UI to such a fine level of specification that there is no leeway for developers to choose alternative implementations that can reduce development time.
- **Can mutate into:** The Disenfranchised
- **Dangerous when coupled with:** The Patent Author
- **Likelihood of fixing:** High
- **Danger to project:** None
- **Problem notes:** Detailed requirements are important for knowing what to build before you build it. However, a huge amount of efficiency can be gained through collaborating with the development team as to alternative user interfaces that are easier to implement, or can be implemented using preexisting or third party implementations. The Blueprinter has shut down this collaboration by giving the developers no leeway in choosing alternate UI solutions that would save development time. At the heart of Waterfall methodologies are detailed documentation of requirements. The thought is that with every detail thought out well in advance, there will be little wasted effort, as once a solution is implemented, it is implemented to specifications and therefore completed. This repeatable and predictable process is coveted in large organizations. However, allowing developers to implement UIs different than those specified can lead to a massive savings in terms of cost and time line. There are a multitude of UI components and libraries that are easy to drop-in and configure, saving both development and testing time, as well as effectively outsourcing maintenance and upgrades. The Blueprinter often does not appreciate the difficulty of creating non-trivial UI components from scratch. When there is truly a need for a novel UI, as there is when creating competitive differentiation, then this work is unavoidable. However, in many instances, compromises can be made to line up the requirements up with preexisting components. If The Blueprinter refuses to compromise on their requirements, the project has potential to be many times more expensive to develop than it has to be.
- **Fix/strategy notes:** Thanks to the detail of requirements coming from The Blueprinter, the project is perfectly predictable; resulting in them being no risk to the project’s success provided adequate budget is allocated to implement the entirety of the UI requirements. Most Project Managers would love to have The Blueprinter designer on staff for the predictability they can provide when coupled with developers who are able to deliver features within the estimated time and budget. While The Blueprinter does not pose a risk to an adequately funded project, they do have the potential effect of needlessly driving up the cost of the project. The difference between the cost of assembling a UI from pre-made components, and writing the components from scratch to meet detailed requirements can be staggering. Additionally, writing the components from scratch can significantly delay time-to-market, thereby incurring an opportunity cost. If one wishes to fix The Blueprinter, one only has to ask them to compromise on their requirements for the sake of the project’s time line and budget. It is unlikely that they will refuse to do so, but can at times happen (see “ The Professor ” designer).
- **Local source:** `The Blueprinter - Neil on Software.html`

## Project Managers

### The Meeting Scheduler

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Statistician

- **Role:** Project Manager
- **Definition:** who is only concerned with establishing lists and checking items off, regardless of what those items are.
- **Can mutate into:** The Hoverer, The Meeting Scheduler, The Delusional, The Tyrant
- **Dangerous when coupled with:** The Patent Author, The Soldier
- **Likelihood of fixing:** Low
- **Danger to project:** Low
- **Problem notes:** To complete any project of any type, there are two irrefutable steps: Make a list of things to do. Check items off the list until it is done. The Statistician Project Manager has concluded that the maintenance of this list represents the entirety of their job responsibility. They are not concerned about what is on this list, only that it has items on it, and that they are being checked off at a predictable pace. The Statistician does not evaluate or offer any critical thinking towards what the items on the list are, and instead rely on others to tell them both the items, and when they are due. The greatest concern with The Statistician Project Manager is that their job can be done by project management software. In this way, they are not needed. Often, The Statistician will become the owner of this software, and are extremely concerned with keeping it up to date. The project itself can be in shambles, delivering the wrong thing, delivering late, and with low quality, but so long as things are recorded properly, The Statistician does not feel that anything is wrong. Fortunately, provided all they do is make lists and track that items are checked off, they do no harm to the project other than being out of touch with what is really happening on the project. The key worry of the Statistician is that they can quickly mutate into something far worse.
- **Fix/strategy notes:** The Statistician project manager is difficult to solve, because the detail orientation that is in their nature is deeply ingrained, quite possibly from childhood. If someone believes lists are important, they will not suddenly change their thinking just because you tell them to. Furthermore, lists are important, but they are only a map, not the landscape itself. This confusing paradox of lists being important, yet not being the focus, makes coaching The Statistician Project Manager difficult. The key skill The Statistician is lacking is people skills, in that they would rather interact with a list rather than interact with people. Encourage them to talk to people about what they are doing, and why they are doing it, rather than simply asking for a list of items they are working on. However, poorly executed, this can result in them micromanaging (see “ The Hoverer ” Project Manager). Finally, ask them to write a paragraph-form executive summary project status rather than a list of items that are or are not complete, which will force them to think of the project more holistically.
- **Local source:** `The Statistician - Neil on Software.html`

### The Delusional

- **Role:** Project Manager
- **Definition:** so out of touch with the realities of the project, that they are representing falsehoods to the stakeholders.
- **Can mutate into:** The Optimist, The Pessimist
- **Dangerous when coupled with:** The Extreme Underestimator
- **Likelihood of fixing:** High
- **Danger to project:** Extremely High
- **Problem notes:** The core responsibility of a Project Manager is to report status on the project. This is called “Setting Expectations”, and “Meeting Expectations” is the yardstick by which project success is measured. A good Project Manager will set expectations with the stakeholders through a combination of quantitative and qualitative data, as well as their own professional experiences. The Delusional Project Manager, on the other hand, will base it solely on their instincts. The following are the key phrases to look for when identifying The Delusional Project Manager: “I have a bad feeling about this.” “I don’t think we’re going to make this date” “I think we’re going to be fine” “I don’t see a problem.” “This decision makes me uncomfortable.” Notice the use of “I” and “me”: dead giveaways that their perception is based on themselves, rather than data gathered and analyzed. It’s important to note the difference between The Delusional, The Pessimist and The Optimist Project Managers: The Pessimist, based on their interpretation of quantitative and qualitative information, has formed the opinion that the project will fail. The Optimist, based on their interpretation of quantitative and qualitative information, has formed the opinion that the project will succeed. The Delusional, based on nothing but their own instincts, have formed an opinion regarding success or failure completely out of alignment with reality. The Delusional is one of the few personalities that can sink entire projects all by themselves. You should be extremely concerned when The Delusional Project Manager is having private meetings with stakeholders, as the following can take place: They tell the stakeholders that all is lost, and that the project will never go to production, causing the stakeholders to cancel the project. They tell the stakeholders that everything is fine, and will hit all its dates, causing the stakeholder to be increasingly frustrated as dates are missed, leading to them canceling the project.
- **Fix/strategy notes:** Fortunately, The Delusional Project Manager is fixable via a two-step process: Ask them why they feel the way they feel. Show them quantitative and qualitative data that contradict their instincts. The goal of asking them to articulate how they feel is to help them realize that their judgment is not based on anything tangible, but is instead just a subjective assessment based on their gut feelings. It is vitally important that they reach this conclusion on their own – they will not react well to being told that they have bad project management instincts. The technique is to continue to ask them “Why do you feel that way?” until you achieve a breakthrough. Once they make this realization, present them with hard facts of the project. For example, if they say, “The quality of this product is going out the window,” present them with a graph showing how the bug count has been dropping steadily over the last few months. If they say, “We are going to be ready on the delivery date” present them with a list of incomplete tasks, and the historical rate of task completion that prove otherwise. At this point, it should simply be a matter of allowing reason and logic to take their course. If they remain delusional, simply repeat the process as many times as necessary.
- **Local source:** `The Delusional - Neil on Software.html`

### The Pessimist

- **Role:** Project Manager
- **Definition:** that has concluded that the project will fail, cannot be convinced otherwise, and is vocal about their belief.
- **Can mutate into:** The Delusional
- **Dangerous when coupled with:** The Alarmist
- **Likelihood of fixing:** None
- **Danger to project:** Extremely High
- **Problem notes:** Most software development projects fail by one measure or another: They go over their staffing budget. They miss their delivery dates. They cannot deliver all the functionality required. The resulting system has performance, stability, or scalability issues. They have a large number of bugs upon completion. In the real world, this is to be expected, and at times embraced as an unavoidable reality. The Pessimist Project Manager, however, has held the project to such a standard that the project cannot meet it, and therefore have declared a project a failure well in advance of the project actually failing. The Pessimist Project Manager is easy to spot as they have two defining characteristics: They have cherry-picked the project status information to focus on the negative, ignoring or discounting any positive signs. They are passionate in their delivery, which is often full of emotional drama. Their attitude can convince the project stakeholders that the project has no hope of being delivered, leading directly to project cancellation.
- **Fix/strategy notes:** The Pessimist Project Manager is impossible to fix, as they are often unhappy in their personal life, job responsibilities, career path, or the company itself. As such, their negativity has nothing to do with the project itself, and is instead a personal problem. The best that can be done is to offer a combination of career and life counseling, which few companies are willing to do. This leads to the often inevitable conclusion of them leaving, or the company firing them.
- **Local source:** `The Pessimist - Neil on Software.html`

### The Optimist

- **Role:** Project Manager
- **Definition:** that has convinced themselves of project success regardless of evidence to the contrary.
- **Can mutate into:** The Cheerleader, The Delusional
- **Dangerous when coupled with:** The Extreme Underestimator
- **Likelihood of fixing:** Low
- **Danger to project:** Extremely High
- **Problem notes:** Generally, positivity is appreciated, as people enjoy working with positive people. The Optimist Project Manager’s flaw is that they let their generally positive outlook interfere with their ability to interpret warning signs on the project. Instead of taking action to correct problems, they choose to ignore what they interpret as unhealthy negativity, and instead choose to only report on what is going well. This breeds a culture of complacency or despondency among project team members, while leading stakeholders to the false belief that everything is going well. In any leadership role, optimism in the face of adversity is an important asset. To determine if a project manager is The Optimist, rather than a courageous leader, the following tests can be applied: Do they seem appreciative of receiving bad news? Do they often give unwarranted compliments? Are they perpetually in a good mood, regardless of how low the morale of a project is? Do they avoid confrontation, even if confrontation is warranted? Do they seem more focused on being well liked, than the project succeeding? The Optimist project managers are often the cause of a project’s failure because they ignore problems that will cause the project to fail. The longer the project goes on, the worse this effect will be.
- **Fix/strategy notes:** The similarities between The Optimist Project Managers and a courageous leader is why they are seldom identified, and therefore rarely fixed. By the time it is realized that they are simply optimists, it is often far too late, as the project will have already failed. Organizations will tend to promote what they perceive to be courageous leaders. As a result, being an optimist project manager will tend to have great career rewards if coupled with the ability to convince the stakeholders that the project failed for reasons outside of their control. Whether the reason for being The Optimist Project Manager is for personal career advancement, not wanting to confront an inconvenient truth, or simply being naive, their damage to the project is the same. The only difference is if they are promoted or fired.
- **Local source:** `The Optimist - Neil on Software.html`

### The Cheerleader

- **Role:** Project Manager
- **Definition:** who focuses on making sure everyone on the project is happy, rather than if the project will be successful.
- **Can mutate into:** The Optimist
- **Dangerous when coupled with:** The Peacemaker
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** High morale is important in the execution of any project, as project members will tend to be more creative and productive when morale is high. When a project is doing badly, it is natural for the morale to drop until the situation on the project improves. During these times, rather than focusing on fixing problems on the project, the Cheerleader project manager focuses on improving morale. The Cheerleader and The Optimist Project Managers share the characteristic of positivity, but how this manifests is fundamentally different: The Optimist is ignorant of any problems facing the project, and is feeding bad information to stakeholders. The Cheerleader sees project success exclusively in terms of morale: Low morale is a failing project; High morale is a successful project. The stakeholders themselves are an afterthought if they are considered at all. The Cheerleader Project Manager is very easy to spot: They will spontaneously show up with treats like coffee and donuts. They will declare it important that everyone have one-on-one meetings with their managers “so that they are being heard”. They will tend to lead conversations towards the personal, wishing to speak about people’s life outside of work (thinking this may be a source of unhappiness). They will send positive emails, post positive posters around the office, and generally represent an overly positive attitude. They will argue for better office furniture, better lighting, and generally a better working environment. They will bear the torch against poor working conditions, such as few career path options, insufficient staff training, and working overtime. The will arrange after-hour social gatherings with the team unattached to important project milestones. They are very concerned about being well liked by project members. This may seem like exactly what someone would want in a project manager, but there are two causes for concern: These activities only offer a temporary boost in morale, which fades quickly once people are reminded of project realities. They are not addressing the root causes of any low morale, preferring instead immediate short-term morale boosters. In this way, The Cheerleader ends up being well liked, but are not really doing the job of a project manager.
- **Fix/strategy notes:** The core problem is that The Cheerleader does not have many tools in their belt, as they typically do not have much experience as project managers. The solution, therefore, is to give them more tools by providing training. Fortunately, there are staggering amount of resources available for project managers to learn how to manage projects. With their new tools in hand, encourage them to focus on discovering the root causes of why morale is low, rather than trying to “fix” low morale. Once discovered, empower them to fix the problems. Considering that their natural inclination is to help people feel better, they will take to finding and fixing root causes aggressively once they know what to look for. At this point, you will have a very potent mix in a project manager: someone who uses morale as a meter to look for problems in the project, and then tracks down these problems and fixes them. Because their motivation comes from compassion towards their fellow human, problems at the root cause of low morale will be quickly stamped out. Incidentally, it is in their nature to be kind to others, so it’s unlikely they will stop the positive aspects of being a cheerleader, so “fixing” them should not eliminate their good parts. Indeed, if there is to be investment spend in grooming a project manager; one could do worse than to start with The Cheerleader.
- **Local source:** `The Cheerleader - Neil on Software.html`

### The Tyrant

- **Role:** Project Manager
- **Definition:** that treats project members with contempt in the name of motivating them to work harder.
- **Can mutate into:** The Pessimist
- **Dangerous when coupled with:** The Soldier, The Bull in the China Shop
- **Likelihood of fixing:** High
- **Danger to project:** Extremely High
- **Problem notes:** Software development projects tend to have a host of strong personalities, each of which must be aligned and focused on the goal of delivering the project. Therefore project managers must exert authority over the project members to ensure project success. The Tyrant Project Manager abuses this authority by using negative reinforcement to achieve results. While The Tyrant Project Manager may not be well liked, project stakeholders often believe that their “firm hand” is just what the project needs to be successful, especially if the project is currently behind schedule. The fact that using threats and punishment does, in fact, act as a motivator to many personality types (see “ The Soldier ” developer), leads to many project managers adopting this personality. The actual problem with The Tyrant project managers is difficult to spot, but is incredibly damaging to the project. The most talented and experienced project members will leave when they feel they are being mistreated, as they are highly employable at other companies. Employees who cannot readily find other employment will stay, leaving the project staffed with people who are otherwise unemployable. The longer The Tyrant project manager stays in charge, the more dramatic this slow talent drain will become. Eventually, once all of the competent project members have been driven off, it will be impossible to add talented and experienced project members to the project, as potential employees will not want to work with an incompetent team (a fact readily exposed during interviews). It is important to note that the Tyrant project manager is normally introduced into a project at the worst possible moment: when the project is in trouble. Projects that are in jeopardy of failing need to dump incompetent team members while keeping competent team members, but The Tyrant project manager causes exactly the opposite effect.
- **Fix/strategy notes:** To fix The Tyrant project manager, they will have to make the self-realization that their behavior is negatively impacting the project. To do this, there are two general approaches to follow: First, present them with quantitative data reflecting their project management style: How many valuable employees have left. Their success rate at attracting talent. How many features are being delivered. How many bugs are being generated. How many deadlines are being missed. Graphs over time are particularly effective at relating this information. Second, inform them of what you expect this data to reflect in the near future. This will most likely have them express exasperation and hopeless, as they do not know how to positively impact these measures of project success. This will then be the ideal circumstance to offer coaching on how to be a better project manager, which should cover the following: How they conduct themselves in front of employees. How they communicate project failures and successes. How they can identify and weed out incompetent project members. How they can attract and retain competent project members. Provided someone exists who can provide this coaching, they are entirely fixable due to the following characteristics intrinsic to humans: People don’t like to be mean. People like to be liked. People like to be effective. The only challenge then is if the project team will accept their new approach despite bad experiences in the past. Gaining their acceptance may very well be as simple as calling a meeting, with the theme being “I’m sorry” and “I’ve changed for the better”.
- **Local source:** `The Tyrant - Neil on Software.html`

### The Process Obsessed

- **Role:** Project Manager
- **Definition:** so obsessed with process, they forget their job is to help the project be successful.
- **Can mutate into:** The Tyrant
- **Dangerous when coupled with:** The Dictator
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** Any project manager, if sent to a training course on project management or finishes reading a book on project management, runs the risk of becoming The Process Obsessed. This can happen to the best of people, so it’s important to be patient with them. There are two broad categories of processes obsessed project managers: Waterfall Obsessed Agile Obsessed While their training course/book may have called them different things, you can put them into the proper bucket easily by applying the following test: Waterfall Obsessed believe all problems can be solve through more documentation e.g. “From now on, we are going to write systems requirements document for every business requirements document.” Agile Obsessed believe all problems can be solved through frequent short meetings e.g. “From now on, we’re going to have daily morning stand up meetings that last no more than 15 minutes.” The goal of any project manager is the delivery of the project on time, and on budget. The process we use facilitates that end. When a project manager becomes obsessed with following a process, they can ignore this fact and instead fixate on the question of, “Are we following the process properly?” at the detriment of their other job responsibilities.
- **Fix/strategy notes:** Whatever you do, do not attempt to take their process from them, or argue against the process. What you are dealing with is more of a religious zealot than a rational person, and they have convinced themselves of a truth: Their process will “fix” the project. If they perceive that the project is “broken”, and you try to say, “That won’t help us”, they will simply consider you a part of the reason why the project is broken. The solution to a The Process Obsessed Project Manager is simple: agree to whatever they say you should do, but gently remind them that “It takes time to turn a big ship” and “Rome wasn’t built in a day”. What you’re trying to do is get them to agree to implement their new process through a series of small changes, rather than a big-bang change. This will allow them to learn through experience which techniques are effective and which are not. As they gain this experience, they will learn to adapt their process to the situation on the ground and will hopefully realize process is a means to an end, not a means unto itself.
- **Local source:** `The Process Obsessed - Neil on Software.html`

### The Hoverer

- **Role:** Project Manager
- **Definition:** who believes that constantly asking for status keeps people focused on completing their tasks.
- **Can mutate into:** The Statistician
- **Dangerous when coupled with:** The Soldier, The Bull in the China Shop
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** When project managers sit at their desks, away from the project members doing work, it is easy for them to feel as if they have nothing to do. This drives them to do anything necessary to feel useful and relevant. For The Hoverer Project Manager, the most obvious way for them to appear productive is to verify this work is actually being done by the team. This is frequently accomplished through the following methods: Sending emails to ask for project status. Scheduling meetings to discuss status. Requiring that timesheets be filled out with detailed breakdowns. Requiring that loosely defined objectives be broken down into fine-grained tasks. Initiating spontaneous in-person meetings in order to ask team members for their status. The Hoverer is commonly known by another name: a micro-manager. Their project management techniques are interpreted by project team members as any or all of the following: Nagging Pestering Harassing Distracting Disrupting Annoying It is common that project members will develop a deep resentment for The Hoverer Project Manager, as their perception is: The Project Manager does not trust them to manage their own time. The Project Manager does not believe their estimates. The Project Manager does not understand the necessity of being left alone to solve problems. The Project Manager has no value other than to ask for and report on status. This perception gives rise to a them-versus-us situation between the project manager and the project team members, stifling useful communication that the project manager could otherwise use to correct real problems on the project. Instead of engaging with “the Hoverer” in effort to foster cooperation and collaboration, the project team members avoid any additional contact with the project manager for fear of being (once again) asked for status.
- **Fix/strategy notes:** The Hoverer Project Manager personality is such a common occurrence that it is considered to be the main job responsibility of project managers. Assuming the inevitable, the only question in most team members’ minds is to what degree they will be pestered for status, often forming an internal threshold for which they feel they will be asked for status too frequently. Since most project team members will have learned to adapt to being constantly harassed for status, The Hoverer does not present a high risk to the project, but it will tend to crowd-out useful conversation that could otherwise be had. The Hoverer emerges as a result of poor visibility with regards to a team’s productivity. Therefore, the solution to is to collocate this Project Manager with the entire project team. If not collocated with the team, The Hoverer is overcome with the urge to directly ask the team members for status. When they are collocated, project managers will absorb current project status simply by overhearing conversation that organically occurs within the team. In this mode of operation, project managers are truly the most effective, as they will only feel compelled to intervene if productivity is truly being hampered.
- **Local source:** `The Hoverer - Neil on Software.html`

## Dev Managers

### The Formerly Technical

- **Role:** Development Manager
- **Definition:** who was a software developer as some point in their past, leading them to believe their technical opinion in still relevant with today’s technology.
- **Can mutate into:** The Wants-to-be-Technical
- **Dangerous when coupled with:** The Rockstar
- **Likelihood of fixing:** High
- **Danger to project:** High
- **Problem notes:** Technology changes so rapidly, that over time former software developers will quickly find their skills obsolete. Development Managers are often former developers, in which case they fall into one of two distinct categories: Development managers who still code. Development manager who no longer code. Development Managers who no longer code are The Formerly Technical, but often are in denial as to this fact. This denial leads them to believe that their opinions are still relevant in technical decision making, when in fact they can be completely out of touch with the current technology landscape. The Formerly Technical Development Manager does the most damage when they choose to exercise their authority in the following areas: Deciding the system architecture. Choosing technologies for the team. Determining which technical skillsets to hire for. Each of these areas have the same characteristic: The negative impact of their decisions take a long time to be noticed by non-technical decision makers. The negative impact on the software developers, however, can be instant, and can directly result in developers leaving out of frustration.
- **Fix/strategy notes:** Top software development companies require that their development managers regularly write code, to ensure that they do not become The Formerly Technical. Unfortunately, many development managers became managers in order to escape coding (see “ The Aspiring Manager ” Developer), resulting in the typical definition of a development manager being that of someone who used to be technical. There are three different solutions that will solve or mitigate The Formerly Technical Development Manager: Require that they code, measured by their actual contribution to the codebase (see “ The Wants-to-be-Technical ” Development Manager) Remove them from the technical decision making process by top-down edict, relegating them to a pure resource manager of questionable value (see “ The Non-Technical ” Development Manager) Have them bow-out of the technical decision making process by demonstrating their lack of technical knowledge.
- **Local source:** `The Formerly Technical - Neil on Software.html`

### The Non-Technical

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Ladder Climber

- **Role:** Development Manager
- **Definition:** with ambitions to advance their career, and sees their development team only as a means to do so.
- **Can mutate into:** The Aspiring Manager
- **Dangerous when coupled with:** The Tyrant
- **Likelihood of fixing:** None
- **Danger to project:** Extremely High
- **Problem notes:** Practically everyone would like to increase their compensation over time, and additional compensation is generally tied to getting a better title. In organizations with clearly articulated career advancement criteria, employees can rest assured that compensation and promotion will come with time and hard work. However, in companies where additional compensation is subjectively decided upon by upper management, political maneuvering is seen by some as the only way to move up the corporate ladder. The Ladder Climber Development Manager has committed to the strategy of political maneuvering, and sees their direct reports solely as a means to advance their career. It is important to create a distinction between The Ladder Climber Development Manager and someone who simply wishes to do the best job they can in hopes of a promotion: Their focus is only on being promoted, not what is in the best interest of the project or the company. It is entirely possible that they hate the company they work for, and have no interest in the project succeeding. Instead, they are singularly focused on the goal of their own advancement. To be effective, The Ladder Climber cannot be honest with others about their goals, and sometimes not even honest with themselves. This makes them particularly difficult to pick out, but they can reveal themselves in subtle and nuanced ways: They make questionable decisions that upon close analysis could only be justified by that fact that the decisions are in their best interest. Their opinions and attitude will change to match that of the people able to decide upon their promotion. They work aggressively to have private audience with upper management, excluding those who could question the accuracy or sincerity of their statements. Their involvement with their direct reports are limited to only that which has upward visibility, e.g. pushing for more aggressive estimates, or deciding on a technology favored by upper management. Development Managers, unlike Product Managers and Project Managers, can deny all responsibility if the project fails as they have no project-specific assignments. If they see that the project is failing, they often will position themselves to emerge into a position of authority. Once in that position, they are incentivized to hasten the project’s failure.
- **Fix/strategy notes:** Fire them.
- **Local source:** `The Ladder Climber - Neil on Software.html`

### The Peacemaker

- **Role:** Development Manager
- **Definition:** who believes arguments are counterproductive, and therefore works to suppress debate of any kind.
- **Can mutate into:** The Cheerleader
- **Dangerous when coupled with:** The Tyrant
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** There is no single right way to develop software. This leads to arguments among developers which a development manager must sometimes mediate. These arguments can range from something as trivial as code formatting, to as impactful as which developers should be on the project. The Peacemaker Development Manager, rather than facilitating a technical debate to a productive decision, only wishes to eliminate what they perceive to be unproductive conflict. Being caught between two strong-willed personalities arguing conflicting points is both stressful and exhausting. It takes a special type of individual to patiently listen to differing opinions, clarify misunderstood points, and remain objective so as to propose the best course forward – especially if it is unpopular. More often than not, people will reach their breaking point, and will simply wish for the argument to stop by any means necessary – be it through a clumsy compromise or by a forceful edict to stop the debate entirely. Facilitating technical debate is an important aspect of technical leadership. Differing skill levels, experiences, competing methodologies, and a wide array of technology choices create a breeding ground for conflicting opinions. These arguments can become heated, and in some cases can genuinely lead to a loss of productivity. However, suppressing arguments entirely will damage morale, stifle innovation, and lead to missed opportunities in improving the project’s outcome.
- **Fix/strategy notes:** The Peacemaker Development Manager has two solvable weaknesses: They cannot tell the difference between an unproductive fight and a productive debate. They do not know how to effectively facilitate technical arguments. Begin by informing The Peacemaker that they must not consider every argument to be unproductive, providing illustrative examples from recent memory. Through careful retroactive analysis, it is likely that they will acknowledge that some debates were cut-off before reaching their logical and potentially productive conclusion. Next, training must be provided on meeting facilitation and conflict resolution. While this is a characteristic that some people innately possess, it is also a skill that can be learned. Books and seminars are helpful, but being able to observe a properly facilitated technical debate between the developers on their own team can provide the most meaningful impact. To that end, bringing in an internal or external mediator can not only settle any immediate arguments, but also act as a coach to everyone involved, from the development managers to those directly involved in current or future debates.
- **Local source:** `The Peacemaker - Neil on Software.html`

### The Wants-to-be-Technical

- **Role:** Development Manager
- **Definition:** who wishes to return to the life of coding, after discovering that the life of a development manager is not for them.
- **Can mutate into:** The Incompetent
- **Dangerous when coupled with:** The Statistician
- **Likelihood of fixing:** Low
- **Danger to project:** Low
- **Problem notes:** Every software developer is faced with only two choices for career advancement: Management, hopefully one day leading to an executive position. Technical Leadership, hopefully one day leading to a Lead or Principal Architect For those who choose management, they may be in for a rude awakening when they finally come to grips with what management truly entails: Having to constantly interview and hire developers to compensate for the natural staff turnover endemic to the software development industry. Being held responsible for the actions of developers they cannot control. Dealing with constantly disgruntled developers who demand more entitlements. Sitting in endless meetings where their contribution is either not needed or not wanted. Writing performance reviews and other unwanted administrative tasks. Never having the opportunity to code, and therefore feeling their technical skills atrophy. When the development manager finally realizes that they have had enough of the life of a manager, and wishes to return to being a software developer, The Wants-to-be-Technical Development Manager will seek an opportunity to slip back into the role of coding. Considering that the best development managers do also code, this should be a good thing, but all too often their time away from coding has left them with inadequate skills to resume their former career path. The problem occurs when the development team catches wind of this change in their manager’s career objective. Developers will often conclude that their manager abandoned being a software developer because they felt it was too difficult, then failed at being a manager, and now lacks the qualifications to be a software developer, but wishes to do so while retaining their managerial authority and compensation. To put it simply, they are not doing their job as a development manager, and are instead an incompetent developer.
- **Fix/strategy notes:** If The Wants-to-be-Technical Development Manager can quickly re-learn the skills required to be a software developer, a lack of competence will no longer be an issue. Indeed, this is entirely possible provided that technologies have not differed too drastically from when they last developed software. This then results in a development manager who is now competent at coding, and provided they can be convinced to live with their managerial responsibilities can be a far more effective development manager than they were before. Unfortunately, if a development manager has waited too long to reverse their career path, they may find themselves having to start from ground zero and slowly work their way back up. Most companies will not be supportive of this re-training, and most certainly not at the pay scale of a development manager. This creates an awkward situation for everyone involved, as there is no clear cause for termination, yet there is no incentive for The Wants-to-be-Technical Development Manager to leave. The only option then is to give them an ultimatum: Remain focused on their duties as a Development Manager, at the risk of being terminated for not doing their job Gain the required technical skill to be a software developer on their own time, at which point the organization will consider if they are qualified for any open software development slots. The first solution will result in an unhappy and unproductive employee, which is in no one’s best interest. The second is much more desirable, but the reality is few organizations will support an employee taking on less responsibility unless it is also associated with reduced compensation.
- **Local source:** `The Wants-to-be-Technical - Neil on Software.html`

## Software Developers

### The Diva

- **Role:** Difficult Software Developer
- **Definition:** so convinced of their irreplaceability that they adopt an attitude of arrogance that makes them impossible to manage.
- **Can mutate into:** The Hostage Taker
- **Dangerous when coupled with:** The Cheerleader
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** At some level, to manage someone, they have to do what you say. The Diva Developer cannot be managed because at their core, they do not believe they work for you, and instead that you have the privilege of working with them. They believe themselves to be utterly irreplaceable, and therefore believe that they hold all the cards in any discussion. Contrary to their own belief, The Diva Developer is not necessarily a skilled developer (see “ The Rockstar ” Developer). Their arrogance is based on their view of themselves in the organization, not their actual technical skill. As a result, it is all too common for The Diva developer to rate their skill level much higher than that of their peers, when in truth it is not. This generally leads The Diva Developer to be disliked by their fellow developers. To determine if you have The Diva Developer on your hands, you can look out for these common catch phrases: “That’s stupid – I’m not doing it like that.” “We should be doing it this way.” “If you don’t like it then you can talk to my manager.” “Well, we’ll see about that.” “I’ll go talk to your boss about it and see what they say.” The Diva will not take direction. They consider any attempt to be managed as an insult, as they are above having to be accountable for their actions. The Diva problem personality is commonly found among long-time developers who were deeply involved in the companies early success. Now, years later, thanks to their long standing relationships with company founders, believe they are beyond reproach by a mere middle-manager. The Diva does not represent a material danger to the project, as they typically do nothing but blow hot air. They are disruptive, however, and tend to have a negative effect on moral – especially among newer, more productive Developers. They must therefore be brought back in line in order for the project to flow smoothly.
- **Fix/strategy notes:** The solution to The Diva Developer is to disprove their core belief: That they are irreplaceable and therefore can do whatever they want. The most direct way to disprove this belief is to hire their replacement to work closely with them. To adequately convey to the (most likely in denial) Diva that this is indeed their replacement, two conditions must be satisfied: The replacement must be better qualified than The Diva It must be made clear to The Diva that their replacement has no other job than to shadow and be trained by The Diva as their replacement. The quicker the replacement is at picking up any legacy knowledge The Diva may possess (see “ The Legacy Maintainer ” and “ The Hostage Taker ” Developers), the faster The Diva will fall into line. The effect can be dramatic, such that you may see a turnaround in attitude in only a few days. Ultimately, they are no longer irreplaceable, and therefore are no longer a diva – they are simply a bad employee. The only hope The Diva then has of retaining their self-perception of status is to get promoted into a managerial position (see “ The Aspiring Manager ” developer). The more savvy The Diva, the earlier in the training of their replacement they will attempt to do this. Promoting them is ill-advised, however, as you will most likely see resignations from developers The Diva is put in charge of. Therefore, upon rejection of their request for promotion, they are left with only two choices: Fall in line with the other developers, or leave. In either case, your problem is solved.
- **Local source:** `The Diva - Neil on Software.html`

### The Idealist

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Rockstar

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Aspiring Manager

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Hostage Taker

- **Role:** Difficult Software Developer
- **Definition:** who has written a piece of mission-critical software, and refuses to let any other developer work on it so that they may remain indispensable.
- **Can mutate into:** The Diva, The Legacy Maintainer
- **Dangerous when coupled with:** The Incompetent
- **Likelihood of fixing:** High
- **Danger to project:** High
- **Problem notes:** To anyone with financial responsibilities, job security is important. Additionally, to anyone wishing to have low job stress, working with the familiar is far easier than working with the unfamiliar. At the intersection of these two desires is The Hostage Taker, a developer who has written and exclusively owns a critical piece of software, and refuses to work on anything else. The Hostage Taker is normally a poor software engineer, and ironically that deficiency translates into a major asset: Their software is typically incomprehensible to anyone but them, and therefore other developers are intimidated to wade into the quagmire that is their code for fear of doing more harm than good. All new work for the mission-critical system must therefore go to The Hostage Taker, thus continuing the vicious cycle. The Hostage Taker is routinely defensive and confrontational, and are absolutely closed off to critique or collaboration regarding their codebase. If truly backed into a corner, they will threaten to leave, and because no other developer wishes to own their poorly designed and woefully implemented piece of software, their bluff is rarely called. This can place them as a choke point in the project, as the entire fate of the project rests on their desire and ability to deliver.
- **Fix/strategy notes:** As dangerous as The Hostage Taker is, the solution is straightforward: Give two or more developers responsibility for The Hostage Taker’s part of the system, and assign The Hostage Taker to a new part of system. There will be a period of time of no productivity as the new developers attempt to understand and redesign the code that was taken hostage, but once that period is over, The Hostage Taker will have been fully neutralized and no longer pose a problem.
- **Local source:** `The Hostage Taker - Neil on Software.html`

### The Bull in the China Shop

- **Role:** Difficult Software Developer
- **Definition:** so focused on getting the work done, that they completely forgo any notion of quality.
- **Can mutate into:** The Soldier
- **Dangerous when coupled with:** The Tyrant, The Firehose
- **Likelihood of fixing:** High
- **Danger to project:** Medium
- **Problem notes:** The pressure on software developers is enormous. “The internet never sleeps” means that often neither do software developers. In order to try and regain a semblance of work/life balance, The Bull in the China Shop developer just wants to complete their list of tasks as quickly as possible and get home to their family. The Bull in the China Shop is created by project pressures. No matter how good the developer, if project pressures increase enough, they will inevitably stop testing their own work, and instead rely on QA (see “ The Blamer ” QA) as their exclusive means of finding bugs. Furthermore, in the name of expediency, they will forgo practices such as peer code reviews; automated testing; and refactoring; leaving the code in a state of disrepair. This poorly designed software then causes new bugs, and the codebase rapidly deteriorates into a geyser of bugs that can never be plugged. The Bull in the China Shop is living in a constant state of stress, inflicted upon them by those in charge. They are victims of a poorly planned and run project, yet they are seen as the problem. The phrase “Burn-out and replace” is used in reference to Bull’s in the China Shop, as the constant stress will eventually break them, and they will either leave or be fired due to their perceived incompetence.
- **Fix/strategy notes:** As they are not the problem, the problem must be rectified by the organization taking the following steps: Put a hard break on the project to create some breathing room. This is normally done by dramatically reducing scope or pushing out the deadline considerably. In the calm period this creates, facilitate a candid “lesson’s learned” where The Bull(s) in the China Shop have the opportunity to air their grievances. Do a root cause analysis of the bugs, and fix the root causes. Do not rush this, and make sure they are all addressed before proceeding. Address any cases of burnout among the developers by forcing the developers to take off-the-books time off. Organizations rarely do this, but it is highly effective. When the team regroups, assess the project holistically to set new scope and delivery dates. While these steps offer a clear path to fixing the problem, they are almost never taken as management is the cause of the problem, yet management must be the source of the solution. However, provided management recognizes their role in creating Bulls in the China Shop, in a few weeks the damage can be repaired and the project put back on course.
- **Local source:** `The Bull in the China Shop - Neil on Software.html`

### The Incompetent

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Extreme Underestimator

- **Role:** Difficult Software Developer
- **Definition:** who consistently massively underestimates the amount of time needed to complete a task.
- **Can mutate into:** The Extreme Overestimator
- **Dangerous when coupled with:** The Optimist
- **Likelihood of fixing:** High
- **Danger to project:** Medium
- **Problem notes:** Underestimation is such a pervasive symptom in the software industry that people do not even think to call it out as a problem. Everyone everywhere underestimates tasks, and in many cases, it is accepted as part of doing business. However, The Extreme Underestimator developer takes this to an entirely new level, as they can always be counted on to miss their deadlines by large margins. The Extreme Underestimator’s impact to the project is simply one of predictability: Without good estimates, it is impossible to plan for the future. Software release deliverables are sometimes tied to contractual obligations with customers and/or partners, thus making predictability a business necessity. A little unpredictability is to be expected, as the reality is that the entire software industry is built around the fact that one cannot accurately predict how long writing software will take. The Extreme Underestimator abuses this tolerance for being late by delivering their tasks weeks late, when their original commitment is that of a couple of days; or worse, months late when they committed to a couple of weeks. The Extreme Underestimator fundamentally does not grasp the negative impact these kinds of schedule delays have on the overall success of the project. They may also consider estimation itself to be a useless practice, as it is their belief that nothing can ever be accurately estimated. In this way, they may come across as blasé when asked for estimates, or arbitrarily throw out a number when asked for how long it will take without any form of analysis.
- **Fix/strategy notes:** Thankfully, The Extreme Underestimator can be fixed, but it does require several guidelines to be followed: They must only be asked to estimate in codebases in which they are intimately familiar. They must only be asked to estimate when using technologies they are intimately familiar. Never ask them to estimate on new features, only enhancements to existing features. Care must be taken to ensure that they fully understand all of the requirements – they cannot be given the liberty to make requirement interpretations on the fly. Require The Extreme Underestimator to add “TODO” comments in the areas where they will have to make changes. This will reinforce the dependent relationship between software complexity and estimates. Make them accountable by presenting their estimates to a group qualified to challenge their timelines. After The Extreme Underestimator has gone through this process a few times, and delivered on their commitments, you can begin to trust them in estimating new features in codebases and technologies they are less familiar with. During this rehabilitation process, pay close attention to the way in which they are meeting their deadlines: Has their quality suffered from them taking shortcuts to make their dates (see “ The Bull in the China Shop ” Developer). If so, encourage them to add the requisite time for testing. Are they working overtime to make their dates (see “ The Soldier ” developer)? If so, encourage them to add the time necessary to ensure work is completed during business hours, and that overtime is for contingency and should remain as such. Provided The Extreme Underestimator takes their rehabilitation seriously, they have the opportunity to grow into a highly trusted member of the development team, as trust is given to developers who deliver the correct requirements, with sufficient quality, at the date committed to. Once prove they can do this consistently, it can be justification for promotion or a raise, which itself can be offered as an incentive to commit to their rehabilitation.
- **Local source:** `The Extreme Underestimator - Neil on Software.html`

### The Extreme Overestimator

- **Role:** Difficult Software Developer
- **Definition:** who has become so afraid of missing their deadlines that they ask for as much additional time as they can get away with.
- **Can mutate into:** The Bull in the China Shop
- **Dangerous when coupled with:** The Pessimist, The Telepath
- **Likelihood of fixing:** Low
- **Danger to project:** None
- **Problem notes:** Given the choice, most project managers would much rather have developers who overestimate, than those who underestimate. The rationale is that while they may take a long time, they are at least predictable. The Extreme Overestimator is very aware of this, and takes full advantage of it by asking for as much time as they can get away with, rather than taking into consideration how much time it would actually take to do their work. The Extreme Overestimators are sometimes impossible to spot. They can be mistaken for being mature and responsible, as unlike their seemingly less experienced fellow developers, they never miss a deadline. There are some signs, however, that distinguish them: Their fellow developers, when asked for the same estimate, provide a dramatically shorter amount of time. If you give them a due date, they immediately state they can make that date, without doing any formal estimation at all. In the case where they quickly say they can make a date, if you move the date up slightly, they will also agree to that date. This means the extra time between the two dates are not really needed for completion of the task The Extreme Overestimators make the company less competitive. If you are racing against a competitor to deliver a feature, you will always be slower to market.
- **Fix/strategy notes:** The Extreme Overestimator is created by an organization as it punishes developers for being late. Their natural reaction is to ask for as much time as possible to minimize their chances of being late. This may seem simple to fix, but there are three things working against you: Being The Extreme Overestimator is a far lower stress mode of operation than attempting to do proper estimation. The Extreme Overestimators will tend to be rewarded and promoted in a development environment, far above those who miss important deadlines. The business has to increase their tolerance for being late, which most businesses are incapable of doing once a particular delivery mindset has been established. Therefore the problem is fixable, but there is no will to fix it. By their very nature, they pose no danger to the project, but potentially pose a great danger to the future viability of the company.
- **Local source:** `The Extreme Overestimator - Neil on Software.html`

### The Soldier

- **Role:** Difficult Software Developer
- **Definition:** who does exactly what they are told without questions, regardless if it is the right thing to do.
- **Can mutate into:** The Bull in the China Shop
- **Dangerous when coupled with:** The Tyrant, The Ghost
- **Likelihood of fixing:** None
- **Danger to project:** Low
- **Problem notes:** From a management perspective, what could be better than a developer who does exactly what they are told to? Indeed, the key problem with The Diva Developer is that they will not do what they are instructed to, so surely a fully obedient developer is a boon to the project. Unfortunately, The Soldier carries its own liability: they will dutifully march off a cliff if instructed to do so, dragging the whole project with them. The Soldier Developer can be of any level of competency – from The Incompetent to The Rock Star and anywhere in between. The key characteristic of The Soldier is their compliance: they will do what you tell them to do without question, every time. It’s easy to mistake this for fantastic leadership motivating the troops, but the fact is that excellence in leadership is very rare. There are multiple paths that lead to the creations of The Soldier developer: You have rejected their objections so many times that they have simply stopped complaining, as they see there is no point. If their objections were valid, then you will have lost a valuable source of information as to how to improve. The Soldier only wants to do the minimum to get by, and doing only and exactly what was asked of them is by definition the minimum. They know you are asking them to do the wrong thing, and want you to suffer the consequences. They are so fed up that they are looking for another job, and are just biding their time until they find one. They lack the knowledge and experience to know they are doing the wrong thing, and therefore stumble blindly forward. They fear being punished for making mistakes, and believe that doing only and exactly what they are asked for is the best way to avoid punishment. They have convinced themselves that being fully compliant is the path to career advancement, which is a sad situation as this is almost never true in the innovation-driven field of software development. They are actually an ex-military trained soldier and have brought that mentality into their new career of software development. As a result, despite how pleasant is may seem at first glance, it is a rarely a good thing if you have The Soldier Developer on your hands.
- **Fix/strategy notes:** Provided you are instructing them to do the right things, The Soldier can be of no trouble to a project at all. In fact, with strong leadership, having a staff of soldiers is highly effective. However, if you need feedback from your developers to help collaboratively guide the project, you will get no such collaboration. This leaves you in a situation of not knowing what you do not know, and The Soldier is not about to tell you. If you can identify the source of why The Soldier is so compliant without question, you have a shot at fixing them. However, by their very nature, they will not be open about why they are the way they are. Their communication will normally be closed off, and they will want to keep the conversation on specific topics you have asked to speak to them about. If you press them on if there is a problem, the most likely response is “No”, regardless of their true feelings. Your best hope is to glean from others they have confided in as to what their true issues are, but this requires that their confidants betray their trust, which is not likely to happen. Even if it does, and you do find their true issue, you then have to fix it, which can be difficult. Then provided you fix it, you have to hope The Soldier changes their behavior, as only they can change themselves. All in all, they are nearly an impossible problem to fix. So, it tends to be a better investment to put strong leadership in place.
- **Local source:** `The Soldier - Neil on Software.html`

### The Technology Enamored

- **Role:** Difficult Software Developer
- **Definition:** that is so excited to try new technologies that they will introduce them into the project regardless of if they are appropriate.
- **Can mutate into:** The Hostage Taker
- **Dangerous when coupled with:** The Idealist, The Ranger
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** To successfully deliver a product to production, technology choices will have to be made. These choices have to be made carefully, and with great consideration towards the specific set of business problems that need to be solved. The Technology Enamored Developer, on the other hand, just likes playing around with new technologies. All developers are technology enamored to a point – they have to be in order to keep their skills current. However, when a developer confuses their professional responsibility to make sound technical choices, and their personal desire to learn new things, you can end up with a technology stack wildly out of alignment with what the business problem warrants. The Technology Enamored Developer is very easy to pick out of a crowd. They will frequently and publicly advocate using a new technology, but will often have a flimsy justification for doing so. They will also suddenly switch technologies midstream without telling anyone, catching other developers by surprise. In many cases, it may actually be a superior technical solution to the particular problem they are facing at the moment, but as it has not gone through a proper vetting process, it may in fact a poor fit for the project as a whole.
- **Fix/strategy notes:** While they can be annoying, fixing the Technology Enamored developer is simplicity itself if the company has established a standard technology stack. Then, all that is required is to correct developers when they deviate from that stack. If you don’t have an established technology stack, it is highly recommended that you define one before you need it, as it will be awkward to introduce it after The Technology Enamored developer has proven to be a problem. Telling The Technology Enamored Developer that they cannot introduce their new technology will most likely hurt their morale, but that morale can be quickly repaired by asking them to do a presentation on the new technology. This is an extremely healthy outlet, as the team can discuss as a group if the corporate technology stack should be changed after the presentation. Most developers will be satisfied simply by having their day in court, even if they do not like the final judgment.
- **Local source:** `The Technology Enamored - Neil on Software.html`

### The Legacy Maintainer

- **Role:** Difficult Software Developer
- **Definition:** whose only capability is the maintenance of legacy software, and therefore is incapable of taking on new work.
- **Can mutate into:** The Hostage Taker, The Soldier
- **Dangerous when coupled with:** The Artist
- **Likelihood of fixing:** None
- **Danger to project:** None
- **Problem notes:** When a developer first joins a company, they tend to be full of fire and passion as they attempt to prove themselves to their new employer. Overtime, however, that passion is often replaced with complacency, as they believe their tenure with the company has granted them certain privileges. The main entitlement they believe they have is to continue to maintain the systems they have built, which means they are unwilling to take on work in other parts of the system. The issue with The Legacy Maintainer is a question of scale: they are simply not a part of the resource pool you can pull from for doing new work. At that point, it becomes a question if you can afford to keep them on staff, which itself comes down to if you can get other developers to take over their legacy maintenance tasks. It is typically difficult to convince other developers to do this for two reasons: Legacy software tends to be badly written, and therefore difficult to work in. Maintenance is a dead-end career path, as you are not doing anything new or innovative that may get you recognized. This is why The Legacy Maintainers end up being with the company for a very long time. Often, they have been with the company since its inception, and were the authors of the software upon which the company was built. As the company grew, however, they did not get promoted into management, or attempt to learn new skills or new parts of the system, leaving them firmly entrenched in the only software they know.
- **Fix/strategy notes:** The Legacy Maintainer does not really pose a problem provided you understand that they are not a resource for new project work. At most, they should be asked to fix bugs and implement small feature enhancements. The only problem arises is if they refuse to let anyone else learn their part of the system (see “ The Hostage Taker ” Developer). There is no fixing The Legacy Maintainer, as they have no desire to be fixed. They have the same mentality about software development as does a factory worker: they want to do the same thing day in day out for their entire career and then retire. That attitude is not something that can be broken, as it is ingrained in who they are. One of the ways this attitude can change is if they experience a life event (getting married, having a child, buying a house, etc.) which requires that they make more money, and they realize that maintaining legacy software is no path to promotion. Unfortunately, this is something you have no control over.
- **Local source:** `The Legacy Maintainer - Neil on Software.html`

## Testers

### The Firehose

- **Role:** Tester
- **Definition:** who floods the developers with so many bug reports so quickly that they overwhelm the development team with a backlog of bugs they will never finishing working through.
- **Can mutate into:** The Alarmist
- **Dangerous when coupled with:** The Statistician
- **Likelihood of fixing:** High
- **Danger to project:** High
- **Problem notes:** When a bug is found, it is important that it is reported accurately and then quickly assigned to the appropriate developer to fix. However, there are QA testers who can find and report bugs so quickly so as to exceed the development team’s ability to fix them, creating an ever-growing list of bugs that can never be closed. On the surface, this can simply be interpreted as the product having severe quality problems, however, that is not always the case. The Firehose QA tester, as opposed to a normal QA tester testing a system with a lot of bugs, is creating a storm of bugs with any or all of the following characteristics: Their bug reports are not very detailed, allowing them to report more bugs more quickly. Many bugs are duplicates of others, as they are only variations of a single root cause. No time is spent reproducing a bug, as seeing a bug once is all that is needed to generate a bug report. Firehose QA testers are often created through direct or indirect organizational pressure: the more bugs you find, the better you are doing your job. This results in QA testers who are diligently tracking down the actual root cause of the bugs, and reporting them clearly and concisely being seen as less productive than the Firehose who is merely going for number of bugs reported per unit time. The Firehose’s effect on a project is sheer panic, as they give the impression that the product was built poorly, and that the project is now behind schedule. Their effect on morale can be immediate and dramatic, causing the development team to throw up their hands as they wait for a break in the onslaught of bug reports.
- **Fix/strategy notes:** Before any effort goes into fixing a Firehose QA tester, it is vitally important that you identify them as a Firehose, rather than an efficient QA tester testing a bug riddled system. The clearest indication is the following complaints from developers: Most bugs are duplicates of others. Many bugs have the same obvious root cause, and therefore could have been reported by a single bug. Bug reports lack detail. The solution to a Firehose QA is to inform them that there is no incentive to report a high volume of bugs, but rather that the goal is to improve the quality of the system. This shifts their focus from reporting as many bugs as possible to helping developers find problems in the system. Quality should then improve at the same (or better) pace, but without the panic.
- **Local source:** `The Firehose - Neil on Software.html`

### The Blamer

- **Role:** Tester
- **Definition:** who accuses the developers of not testing their work whenever they find a bug.
- **Can mutate into:** The Alarmist
- **Dangerous when coupled with:** The Statistician
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** Every bug theoretically could have been found and fixed by a developer before QA found and reported it. This leads some QA testers to take each bug found as further evidence that the developers are not testing their work sufficiently. This is an undeniable fact, empowering the Blamer QA tester to be even more vocal with their disparaging assessment of the development team. The Blamer QA tester is ultimately caustic to the morale of the project. Rather than helping to improve the quality of the product, their focus is on proving that the development team is not doing their job. Every bug, rather than being taken at face value, is added to the pile of evidence that developers have developed an overreliance on QA to find bugs that they should have found instead. Sadly, the Blamer QA is normally made by the organization through a fairly predictable process: A critical bug is found in production The QA tester is blamed for missing the bug This happens far too often, and it is therefore understandable that the QA tester would defend themselves using an argument that is irrefutable.
- **Fix/strategy notes:** Before any effort should be made to fix the Blamer, the organization must first stop blaming QA for missing bugs that find their way into production. Whomever is doing the blaming must be coached into a more productive method of helping the entire development organization improve its ability to deliver quality software, rather than just singling out QA. Once the organization has stopped blaming QA for missing bugs, a Blamer QA can be addressed by offering them a shift in perspective, as well as a shift in attitude: The shift in perspective is that developers are only human, and they are prone to making mistakes. To compensate for their human tendency to make mistakes, the QA organization acts as a guard against their mistakes affecting customers. Additionally, due to the tedious nature of software development, it is all too easy for a developer not to see the forest for the trees, as they are so focused on solving a particular problem that they forget to test something seemingly obvious. The shift in attitude is simply one of teamwork, and that teammates should not blame each other for making mistakes, and instead should help them recover from their mistakes for the benefit of the team. In the role of QA, it is especially important to establish a partnership with the development team for the sake of the project, and smooth bug identification, bug reporting, and bug fixing life cycle is critical to ensure the quality of a product.
- **Local source:** `The Blamer - Neil on Software.html`

### The Alarmist

- **Role:** Tester
- **Definition:** who has declared that the entire product is of an unacceptable level of quality based only on their first impressions.
- **Can mutate into:** The Blamer, The Firehose
- **Dangerous when coupled with:** The Pessimist
- **Likelihood of fixing:** High
- **Danger to project:** High
- **Problem notes:** The nature of applications is that quality from feature to feature will be uneven. Some features may be relatively simple, or developed by highly skilled developers, and therefore have little or no bugs. Some features may be relatively complex, or developed by less skilled developers, and therefore be riddled with bugs. The Alarmist QA tester has had the bad luck of having the first area they have tested be of low quality, and has therefore declared that the entire product is of low quality without any further investigation. Much can and has been said about a developer being frustrated by a QA tester wasting their time (see “ The Misleader ” QA), but this situation cuts both ways. All too often, a developer will knowingly hand off software that they have not thoroughly tested in order to receive credit for completed work, or to claim they have met a deadline. When a QA tester begins to test such a system, they are immediately met with a host of bugs that should have legitimately been caught by the developer. It is therefore understandable that they would extrapolate what they are seeing to the entire product, and declare that the product as a whole is of too low a quality. The Alarmist QA tester is normally someone with some level of authority within the QA organization, and therefore their opinion is well respected within the organization. The greater their level of authority, the more devastating their impact on the project. A typical disaster scenario is the following: The product is delivered to QA The Alarmist QA begins testing an area of the application with an appalling level of quality The Alarmist QA halts all testing efforts, and escalates to upper management that there is a severe quality problem with the product. This is a classic case of throwing out the baby with the bathwater. Sometimes, QA will have made the right judgment call, especially when the development team has a reputation of passing off untested software to QA. When it is the wrong judgment call, however, it may have only been a single poor developer has made the entire development team look bad, as their work just so happened to be the first set of work tested by the Alarmist QA.
- **Fix/strategy notes:** A QA tester becomes the Alarmist after having been burnt repeatedly by the development team. If the development team had consistently delivered high quality software to the QA team in the past, there would be no opportunity for an Alarmist to emerge. Once a QA tester has become an Alarmist, however, it may be difficult for the development team to win back their trust, especially if the development team includes The Incompetent or The Bull in the China Shop developers. Typically – especially on large development teams – low quality is caused by individual developers rather than the team as a whole. It is therefore imperative that work done by these less competent developers be last on the list to verify, or effort must be taken to not have the Alarmist test their work. Doing this, however, runs the risk of masking the true issue: that there are developers on the team negatively impacting the project.
- **Local source:** `The Alarmist - Neil on Software.html`

### The Scientist

- **Role:** Tester
- **Definition:** who spends the majority of time documenting bugs, rather than finding new bugs.
- **Can mutate into:** The Downtrodden
- **Dangerous when coupled with:** The Patent Author
- **Likelihood of fixing:** High
- **Danger to project:** Low
- **Problem notes:** Finding problems in a system can be as much fun as going on a treasure hunt, and then solving a puzzle when you find the treasure can also be interesting. It could be argued that a QA tester who views the process of finding bugs this way is ideal, but a problem can exist if the QA tester seeks to thoroughly document their journey of discovery. Rather than focusing in on just the core problem, the developer must read through a lengthy story containing information that is mostly of little use, trying to pick out the pieces of relevant information. The Scientist QA tester has taken the message of “Thoroughly document your bugs” to the extreme. Bugs are reported in paragraph form, rather than as a concise description followed by a clear sequence of steps to reproduce. Reading a bug from the Scientist QA tester is very time consuming, and at the end it still may not be clear what the problem actually is. It is common for the description to include the discovery of many bugs, with the description referring to an area of the system rather than a specific problem. The chief complaint from developers when receiving bug reports from Scientists is low signal-to-noise ratios, when they are spending their time sifting through a stream of consciousness looking for detail about specific problems. This leads to wasted time and frustration among the developers, as well as wasted time for the QA tester who is spending far too much time documenting irrelevant details.
- **Fix/strategy notes:** The Scientist QA Tester represents a simple training opportunity on how to write bugs. Often, making the switch to writing clearer bug reports will be instant once they know what is expected. The most effective way to coach them on how to transition their reporting style is to rewrite one or more of their bug reports into the format that you are expecting, which serves as a before-and-after reference guide to them in the future. What you should be left with is an enthusiastic QA tester who generates clear and concise bug reports, which could not be more ideal.
- **Local source:** `The Scientist - Neil on Software.html`

### The Misleader

- **Role:** Tester
- **Definition:** who often reports bugs inaccurately, leading the developer down the wrong path as they attempt to reproduce and fix the problem.
- **Can mutate into:** The Alarmist
- **Dangerous when coupled with:** The Statistician
- **Likelihood of fixing:** High
- **Danger to project:** High
- **Problem notes:** Reporting a bug requires the following: The ability to spot that there is, in fact, a bug The ability to determine the steps to reproduce the bug The ability to describe the bug holistically, often pointing to root cause The ability to clearly articulate the steps to reproduce At any one of these steps, it is possible for the bug report to mislead the developer, causing the developer to waste time: If there is no bug, the developer wastes time attempting to find a problem that does not exist If the bug cannot actually be reproduced, the developer wastes time attempting to reproduce it If the bug is not described properly, the developer can waste time looking for too specific or too broad root cause If the steps to reproduce are difficult to follow, or inaccurate, the developer wastes time attempting to interpret them, or may declare their is no bug when one still exists Occasionally misleading a developer will happen as a result of humans making mistakes, and this is to be expected. However, the Misleader QA does this habitually, creating a significant amount of frustration among the developers. If this situation is allowed to continue, the QA tester will eventually lose credibility with the developers, and legitimate bugs they find will go unfixed as developers reject their bug reports as a matter of course.
- **Fix/strategy notes:** The Misleader QA tester is often good at finding bugs; they are just poor at documenting them. Therefore, training them how to report a bug properly is worth the effort. One of the more effective techniques to help the Misleader improve is to have them observe a developer using one of their bug reports to diagnose an issue. This is as simple as sitting them next to a developer who has received one of their bug reports, and have them quietly observe (without intervention) what the developer goes through. This normally leads to a healthy conversation about how to better report a bug that both the Developer and QA appreciate.
- **Local source:** `The Misleader - Neil on Software.html`

### The Downtrodden

- **Role:** Tester
- **Definition:** who has been beaten down by developers to the point that they hardly report any bugs for fear of developer bullying.
- **Can mutate into:** The Flippant
- **Dangerous when coupled with:** The Diva, The Hostage Taker
- **Likelihood of fixing:** Low
- **Danger to project:** Low
- **Problem notes:** There is perhaps no greater display of condescension than the typical conduct of developers towards QA. Furthermore, it is not uncommon to see a QA tester openly bullied by aggressive developers, even when reporting a legitimate bug in their code. To combat this, a successful QA must have the following characteristics when dealing with aggressive developers: Already have won a large amount of credibility with the developers, such that their bugs are always taken seriously Have an equally aggressive personality, with the perseverance to argue a developer into admitting the bug truly exists. Sadly, not many QA testers have these characteristics, and are therefore run over by developers who see QA as the first person to blame when a bug is found. As counter-intuitive as it may seem, this is an all-to-common situation given the following: The Developer has a very high sense of self-importance (see “ The Diva ” Developer) The Developer believes they know how the system works far better than the QA tester (see “ The Hostage Taker ” Developer) Once a QA has been thoroughly beaten-down over time, they will tend to avoid confrontation with these hostile developers to regulate their work stress. The consequence is that bugs in their developers’ system will seldom be reported, even though bugs may exist. Typically, this situation is only discovered when problems surface in production, and an investigation is made into why the bug wasn’t caught by QA. The Downtrodden QA will then have any of the following explanations: They spoke to the developer verbally, and was told it was not a bug. They filed a bug report, but it was rejected by the developer. They found the bug, but did not “think it was important enough to write up” The passive nature of The Downtrodden QA tester will often make them hard to diagnose. The key will be to characterize the developers they work with, looking for signs of hostility that should be readily apparent.
- **Fix/strategy notes:** The QA tester is being bullied by the developers – pure and simple. As such, the developers should be treated as any bully should: Warned to immediately cease and desist in their aggressive behavior. Coached on professional communication. Fired if they cannot correct their behavior. The situation may have progressed to the point where HR may have to step in, especially if it has degraded into a situation of open hostility. It is sad that this situation is more of the norm that the exception, and it is then only a question as to what degree it happens.
- **Local source:** `The Downtrodden - Neil on Software.html`

### The Random Clicker

- **Status:** Mentioned in the downloaded navigation, but the dedicated source page was not present locally.
- **Use in the skill:** Name this archetype explicitly if the user mentions it or if it appears in the source taxonomy, but avoid inventing detailed mutation paths, pairings, or fixes without a fuller source page.

### The Flippant

- **Role:** Tester
- **Definition:** whose bug reports are so passive aggressive that developers interpret them as being rude.
- **Can mutate into:** The Blamer
- **Dangerous when coupled with:** The Diva
- **Likelihood of fixing:** Low
- **Danger to project:** Low
- **Problem notes:** Properly filing a bug report is labor intensive and cognitively a heavy process, and there are some QA testers who refuse to put much effort into it. These are usually QA tester with some level of entitlement, as they do not feel that they need to put any effort into their bug reports. It is also common for them to hold a disparaging view of the development team, and do not consider it worth their time to do any type of analysis on the bug: their general statement should be enough to have the development hop to figuring out what was discovered. Typical bug reports from the Flippant QA tester are as follows: “This isn’t working” “This is broken again” “This problem would be obvious if you actually used it” “I’m not sure why this was missed” “Test this more thoroughly next time” “I don’t know why we can’t get this right.” Obviously, the developers are less than pleased receiving a bug report where these statements are given instead of steps to reproduce. It is rare that a professional QA analyst would report bugs like this, but they are common when other members of the organization are called upon to report bugs, as this is likely to happen when there is limited time to test an application before a release, and QA short-staffed. The result of adding this “Help” to QA is generally chaos, as bug are being rejected by the developers, creating more strife among the project team, further deepening resentment.
- **Fix/strategy notes:** Generally, QA should be left to professional QA testers. Unfortunately, there is a sentiment in the industry in “anyone can do QA” but this is not true. It is more accurate to say that anyone can discover a bug, but typically only professional QA testers can identify important bugs hidden in edge cases, and report them in a way that the developer can immediately understand, reproduce, and therefore fix. Normally, the person acting as a Flippant QA tester believes they have every right to be flippant. If they are a member of the QA staff, they should be warned to correct their behavior as it is counterproductive, and not the job that is required of them. If they are part of an auxiliary QA staff brought in to augment the QA department, they should not be allowed to report bugs until they are able to do so professionally. Often, it is far more efficient to simply remove a Flippant QA tester than to attempt to fix them. Certainly, they have made it clear that they do not wish to do QA testing, so this is most likely in everyone’s best interest.
- **Local source:** `The Flippant - Neil on Software.html`

FILE:references/pattern-notes.md
# Pattern Notes

Use this reference when you need rough, non-clinical labels for recurring conflict behavior on software or game projects.

## Chronic blocker / reflexive naysayer

Typical pattern:
- shoots down ideas early
- defaults to risk, cost, or failure framing
- rarely offers workable alternatives

Common drivers:
- status signaling
- fear of failure
- habit of critique over ownership

## Moving-goalpost stakeholder

Typical pattern:
- changes success criteria repeatedly
- reframes requests after work is already underway
- creates ambiguity about what done means

Common drivers:
- indecision
- image management
- weak strategic clarity

## Conflict-avoidant decision dodger

Typical pattern:
- delays hard calls
- keeps options open too long
- avoids direct disagreement
- lets ambiguity accumulate

Common drivers:
- fear of blame
- fear of conflict
- low confidence

## Status-driven critic / smartest-person pattern

Typical pattern:
- needs to be the sharpest voice in the room
- critiques publicly and performs intelligence
- may resist ideas more when they are not the source

Common drivers:
- insecurity
- status competition
- identity tied to expertise dominance

## Chaotic priority shifter

Typical pattern:
- changes priorities constantly
- creates urgent work without preserving focus
- interrupts systems with reactive demands

Common drivers:
- anxiety
- lack of planning discipline
- reward systems that praise visible urgency over consistent delivery

## Passive-aggressive non-cooperator

Typical pattern:
- says yes in the meeting, resists in execution
- withholds information, follow-through, or goodwill
- creates friction indirectly rather than openly

Common drivers:
- resentment
- conflict avoidance
- low trust

## Blame-shifter

Typical pattern:
- rewrites history
- externalizes responsibility
- protects image by redirecting fault

Common drivers:
- insecurity
- punitive culture
- fear of status loss

## Heroic firefighter

Typical pattern:
- solves crises dramatically
- may benefit from environments staying chaotic
- underinvests in boring prevention and process

Common drivers:
- identity built around rescue
- reward structure that celebrates heroics
- impatience with maintenance work

## Vague visionary

Typical pattern:
- speaks in big goals or exciting abstractions
- struggles to define boundaries, tradeoffs, or execution detail
- creates inspiration without decision-quality clarity

Common drivers:
- creativity without operational discipline
- aversion to constraint

## Controlling micromanager

Typical pattern:
- over-specifies work
- struggles to delegate trustfully
- reopens solved details repeatedly

Common drivers:
- anxiety
- perfectionism
- lack of trust

## Absent decision-maker

Typical pattern:
- owns decisions in theory but is hard to pin down in practice
- leaves others blocked or guessing
- appears only after momentum is lost

Common drivers:
- overload
- avoidance
- unclear accountability

## Important note

These are rough pattern labels for tactical analysis.
A real situation can involve several patterns at once, and the surrounding team system may be more important than the person alone.

FILE:references/response-strategies.md
# Response Strategies

Use this reference when converting a conflict-pattern read into practical next steps.

## General response moves

### Narrow the decision
Use when people create confusion through abstraction, opinion sprawl, or changing goals.

Examples:
- define the exact decision needed
- define who owns it
- define the deadline
- define what success means

### Create written alignment
Use when memory, accountability, or revisionism is a problem.

Examples:
- recap decisions in writing
- document scope and success criteria
- log changes and owners
- confirm agreements after meetings

### Reduce public status combat
Use when a person performs dominance or critique in group settings.

Examples:
- move detail disputes to smaller settings
- ask for alternatives, not just objections
- require decision-oriented framing rather than performative criticism

### Add process guardrails
Use when chaos or inconsistency is the real issue.

Examples:
- change review cadence
- freeze priorities for a period
- require change requests instead of drive-by demands
- create a clear approval path

### Set boundaries
Use when cooperation is repeatedly undermined.

Examples:
- define what you can and cannot do without certain inputs
- stop absorbing unowned ambiguity silently
- name dependencies clearly

### Escalate carefully
Use when direct handling is failing and the user has enough support or evidence.

Examples:
- escalate with documented patterns, not emotional accusations
- describe impact on delivery and risk
- propose a corrective structure, not just a complaint

## Things to avoid

- public humiliation attempts
- mind-reading certainty about motives
- long emotional essays instead of concrete requests
- escalating with weak evidence
- trying to win by being sharper, meaner, or more theatrical than the other person

## Useful sentence patterns

- "I think we may be changing the target after work has started. Can we lock the success criteria before continuing?"
- "I can move forward once we decide between A and B. Who owns that call and by when?"
- "I want to avoid losing the thread here, so I’m writing down the agreed scope and owners."
- "If priorities have changed, I need to know what drops so the team is not implicitly working on everything."
- "I’m hearing concerns, but I need a concrete alternative to act on. What do you recommend instead?"

## Safety note

If the situation includes strong power imbalance, retaliation risk, harassment, or repeated trust collapse, optimize for documentation, witnesses, and safer escalation rather than direct confrontation fantasy.

---
name: game-design-fogg-behavior-audit
description: "Audit a game feature, flow, event, onboarding step, progression action, monetization surface, retention mechanic, or social prompt using the Fogg Behavior Model: Motivation, Ability, Prompt. Use when evaluating whether a design actually causes the intended player behavior, diagnosing weak feature adoption, identifying friction or mistimed prompts, or understanding why a feature that seems valuable is not being used."
---

# Game Design Fogg Behavior Audit

Evaluate whether a feature actually produces the behavior it is trying to cause.

Use this skill when the main question is behavioral: will players do the thing, and if not, why not? The goal is not to give a broad aesthetic critique. The goal is to identify whether the intended player action is supported by enough motivation, enough ability, and the right prompt at the right moment.

Read `references/fogg-notes.md` when you need a concise reminder of the model and the main failure patterns.
Read `references/game-examples.md` when you want examples of how Motivation, Ability, and Prompt show up in game features.

## Core behavior

- Keep the analysis practical, not academic.
- Always identify the target behavior first.
- Do not audit a feature in the abstract if the intended player action is unclear.
- Evaluate Motivation, Ability, and Prompt separately before giving a verdict.
- Identify which of the three is the main bottleneck.
- Recommend specific fixes, not vague advice.
- Focus especially on feature design, onboarding, retention loops, event participation, progression actions, social actions, and monetization prompts.

## What to ask first

Prioritize these questions:
1. What exact player behavior is this feature trying to cause?
2. What is the feature or flow?
3. Who is the target player or player state?
4. When is the player supposed to do the action?
5. What reward, value, urgency, or reason does the player have to do it?
6. What friction, prerequisites, or UI steps stand between the player and the action?
7. What prompt or trigger is currently used?

If the target behavior is vague, ask for clarification or infer the most likely behavior and state the assumption.

## What to diagnose

Quickly identify:
- whether the intended behavior is clear and specific
- whether players have enough reason to do it now
- whether the action is easy enough in the current context
- whether the prompt appears at the right moment
- whether the prompt is visible, timely, and relevant
- whether the feature is failing mostly because of low motivation, low ability, weak prompting, or a mismatch between all three

## Response structure

Always organize the answer using this structure.

### Target Behavior
- state the exact player action the feature is trying to produce
- if needed, distinguish primary and secondary behaviors

### Motivation Read
- what makes the player want to do it
- what weakens desire or relevance
- whether the reward, emotional appeal, status, urgency, curiosity, fear of loss, or identity fit is strong enough

### Ability Read
- what makes the action easy or hard
- clarity
- step count
- cognitive load
- time cost
- resource or skill gates
- UI friction

### Prompt Read
- what currently prompts the behavior
- whether the prompt is visible, understandable, and well-timed
- whether the prompt hits when motivation and ability are high enough

### Failure Diagnosis
- identify the main bottleneck
- say whether the feature mostly fails because players do not want it, cannot easily do it, are not being prompted well, or are being prompted at the wrong time

### Recommendation
- recommend specific changes
- if useful, separate fixes into motivation, ability, and prompt improvements

## Strong use cases

This skill is especially useful for:
- FTUE and tutorial steps
- daily or return-player actions
- event entry and event participation
- reward claims and progression interactions
- store offers and monetization prompts
- battle pass or mission adoption
- social invites or guild actions
- underused buttons, tabs, or feature entries
- any feature that seems valuable on paper but is not being used much

## Weaker use cases

This skill is less useful for:
- broad game vision critique without a specific target behavior
- purely aesthetic review
- open-ended sandbox play where the intended behavior is intentionally loose
- high-level worldbuilding analysis

## Style guidance

- Be concrete.
- Do not turn the analysis into generic behavioral-science fluff.
- Keep the focus on what the player is actually being asked to do.
- If the feature is trying to drive too many behaviors at once, say so.
- If the behavior target itself is bad or confused, say that before tuning Motivation, Ability, or Prompt.

## Fast mode

Use this compressed flow when the user wants a quick answer:
- what exact behavior is this feature trying to cause
- do players want to do it
- can they easily do it
- are they prompted at the right moment
- which of the three is weakest
- what should change first

## Working principle

A feature does not succeed just because it exists, is visible, or is theoretically valuable. It succeeds when the player has enough reason to act, enough ability to act, and a prompt that lands at the right moment.

FILE:references/fogg-notes.md
# Fogg Notes

Use this reference when you need a concise reminder of the Fogg Behavior Model.

## Core model

Behavior is most likely to happen when three things meet:
- **Motivation** - the player wants to do it
- **Ability** - the player can do it easily enough
- **Prompt** - something triggers the action at the right moment

If one of these is too weak, the behavior often does not happen.

## Game-friendly interpretation

### Motivation
Possible sources:
- reward value
- emotional payoff
- status
- competition
- curiosity
- urgency
- fear of missing out or loss
- social meaning
- identity fit

Common failure patterns:
- reward is too weak
- player does not understand why it matters
- feature feels irrelevant in current progression state
- the effort feels larger than the payoff

### Ability
Possible blockers:
- too many steps
- poor discoverability
- confusing UI
- too much reading
- high time cost
- skill gate
- currency or resource gate
- contextual mismatch

Common failure patterns:
- feature is technically available but practically annoying
- the player is prompted when busy, confused, or underpowered
- the action depends on prerequisites the player does not yet have

### Prompt
Possible forms:
- button placement
- notification
- tutorial callout
- event banner
- reward reminder
- social invitation
- contextual nudge after a relevant success or failure

Common failure patterns:
- prompt appears too early
- prompt appears too late
- prompt appears when ability is low
- prompt is visually weak or easy to ignore
- prompt frequency creates blindness or irritation

## Important caution

Do not assume the answer is always "add motivation".
Many weak features fail because the action is too annoying, unclear, or badly timed, not because the reward is too small.

FILE:references/game-examples.md
# Game Examples

Use this reference when you want examples of how Motivation, Ability, and Prompt show up in game feature design.

## FTUE prompt to equip an item

Target behavior:
- equip the newly earned item

Possible failure diagnosis:
- **Motivation** is fine because the reward is obvious
- **Ability** is weak if the inventory is confusing or buried
- **Prompt** is weak if the game never highlights where to tap next

## Daily event participation

Target behavior:
- enter the event and play at least one run

Possible failure diagnosis:
- **Motivation** may be weak if rewards feel generic
- **Ability** may be weak if entry requires too many prerequisite taps or currencies
- **Prompt** may be weak if the event appears when the player is already overloaded with menus

## Battle pass claim flow

Target behavior:
- open the pass and claim rewards regularly

Possible failure diagnosis:
- **Motivation** is usually decent because rewards exist
- **Ability** can fail if claim flow is tedious or hidden
- **Prompt** can fail if reminders are subtle, late, or visually drowned out by other surfaces

## Social invite feature

Target behavior:
- invite a friend

Possible failure diagnosis:
- **Motivation** may be weak if social value is unclear
- **Ability** may be weak if the invite path is awkward or requires too much setup
- **Prompt** may be weak if the request appears before the player has enough positive investment to recommend the game

## Limited-time store offer

Target behavior:
- tap and purchase or at least inspect the offer

Possible failure diagnosis:
- **Motivation** may fail if value is unclear
- **Ability** may fail if pricing or contents are confusing
- **Prompt** may fail if the offer appears at a moment of low trust or high frustration

## Return-player notification

Target behavior:
- reopen the game after being away

Possible failure diagnosis:
- **Motivation** may fail if the content is not compelling
- **Ability** may fail if returning feels cognitively expensive or the session startup is slow
- **Prompt** may fail if timing is bad or if notifications are too generic to matter

---
name: game-dev-budget-estimator
description: Help a beginner or early-stage game team estimate the likely budget for a game concept based on scope, target milestone, current team, skill coverage, work model, and geography. Use when someone asks how much a game might cost, what budget range they should expect, whether their current team meaningfully reduces cost, what missing roles would add to budget, or how to estimate cost for a prototype, vertical slice, release, or live F2P project. Ask for missing information when concept, team, scope, or cost assumptions are unclear, then provide a rough budget range, main cost drivers, hidden cost buckets, and ways to reduce spend.
---

# Game Dev Budget Estimator

Estimate likely cost ranges, not fake precision.

Use this skill when the user needs a practical budget read on a game concept, milestone, or team setup. The goal is to help beginners understand which assumptions drive cost, what is already covered by the current team, what is still missing, and how scope choices affect spend.

Read `references/cost-drivers.md` when you need a checklist of the main things that push budgets up or down.
Read `references/estimation-modes.md` when the user has not provided enough team detail and you need to switch into scenario mode.

## Core behavior

- Keep the language simple and non-jargony.
- Ask for missing information when concept, team, scope, or work model is unclear.
- Give ranges, not fake precise totals.
- Explain assumptions clearly.
- Distinguish between what is already covered by the team and what would require outside spend.
- Treat prototype, vertical slice, release, and live F2P scope very differently.
- Ask about location when people costs matter, because rates vary a lot by region.
- Ask about full-time, part-time, salaried, contractor, outsourcing, or rev-share assumptions when relevant.
- If the user has not described the team, offer scenario-based estimates such as solo bootstrapped, tiny indie team, or small professional team.

## What to ask first

Prioritize these questions:
1. What is the game concept in plain language?
2. What is the target platform?
3. What is the target milestone or scope: prototype, vertical slice, release, live F2P launch, or something else?
4. Who is already on the team?
5. What can each person actually do well?
6. Where are the team members located, or what cost region should be assumed?
7. Are they full-time, part-time, contractor, outsourced, or hobby/rev-share?
8. Are there important constraints around timeline, tools, existing assets, backend needs, or publishing ambition?

If key information is missing, ask 2 to 5 focused questions. If the user wants a fast estimate, state assumptions and continue.

## What to diagnose

Quickly identify:
- the main cost drivers for this concept
- whether people cost is the dominant factor or whether tooling, backend, content, or polish also matter heavily
- what costs are already covered internally by the existing team
- what missing disciplines are likely to require hiring, contracting, or scope cuts
- whether the user is underestimating live-service, online, content, QA, UI, or audio cost
- whether the milestone is realistic for the stated team and budget assumptions

## Common cost buckets to consider

Do not always list all of these. Only raise what matters.

- salaries or contractor rates
- art production
- animation and VFX
- UI / UX
- audio / music / sound design
- gameplay and systems engineering
- backend / online / live-ops engineering
- design and production support
- QA / testing
- tools, middleware, engine licenses, plugins
- localization
- store readiness, compliance, age ratings, platform requirements
- marketing, trailer, pitch materials, community, or user acquisition
- legal, accounting, and business setup

## Response structure

Always organize the answer using this structure.

### Project Snapshot
- one short summary of the game and milestone
- one sentence on what kind of budget shape this project usually has

### Assumptions
- scope assumptions
- team assumptions
- location assumptions
- work-model assumptions
- timeline assumptions if relevant

### Main Cost Drivers
- list the top factors driving cost for this project
- explain why they matter here

### What Is Already Covered
- explain what the current team meaningfully reduces or eliminates
- distinguish fully covered from partly covered

### Likely Missing Cost Buckets
- list outside spend the project probably still needs
- explain which are must-have versus optional

### Rough Budget Range
- low case
- expected case
- high case
- short explanation of what changes between them

### Ways to Reduce Budget
- scope cuts
- team composition changes
- art/style simplification
- fewer platforms
- fewer online dependencies
- more middleware, asset packs, or contractor use where sensible

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

## Estimation modes

### Team-known mode
Use when the user described the team.
- estimate what the team already covers
- estimate what still costs money
- explain where hidden gaps still create budget risk

### Team-unknown mode
Use when the user did not describe the team.
- say that team information is missing
- offer a few rough scenarios such as solo bootstrapped, tiny indie team, or small professional team
- keep the scenarios clearly labeled as assumptions, not facts

### Milestone-specific mode
Adjust strongly by milestone:
- **Prototype**: low polish, placeholder-heavy, learning-focused
- **Vertical slice**: stronger presentation, UX, polish, and cross-discipline quality bar
- **Release**: much broader production, QA, content, business, and platform-readiness burden
- **Live F2P / online**: higher ongoing costs for backend, analytics, economy tuning, content cadence, support, and operations

## Scope sensitivity

Call out these common budget traps when relevant:
- assuming part-time work is free
- assuming a vertical slice budget scales linearly into full production
- ignoring UI, audio, QA, and integration time
- forgetting backend, analytics, and live-ops overhead for F2P or online games
- treating existing team members as if they cover roles they only partly cover
- assuming art quantity and polish level will stay cheap at larger scope

## Style guidance

- Be practical and transparent.
- Do not pretend the estimate is precise.
- Give directional confidence, not spreadsheet theater.
- If the project sounds under-budgeted, say so directly.
- If the project could become affordable through scope cuts, explain how.
- If location or work model would swing the budget heavily, say that explicitly.

## Fast mode

Use this compressed flow when the user wants a quick answer:
- what are you making
- what milestone are you targeting
- who is on the team
- what cost region should be assumed
- what will likely cost real money
- what budget range is plausible
- how could the budget be reduced

## Working principle

A useful early budget estimate is not a perfect total. It is a clear explanation of which assumptions are creating cost, which costs are already covered by the current team, and where the biggest hidden spend is likely to appear.

FILE:references/cost-drivers.md
# Cost Drivers

Use this reference when estimating what makes a project cheap, moderate, or expensive.

## Core drivers

### Team size and role coverage
- more people usually means more direct cost
- weak role coverage can create contractor cost or production delays
- hidden gaps often appear in UI, audio, QA, production, and backend

### Geography / rate region
- rates vary heavily by country and city
- remote contractors, local hires, and outsourced vendors can differ dramatically
- ask for region when people cost is a major unknown

### Work model
- full-time staff
- part-time staff
- contractors
- outsourcing
- rev-share or hobby collaboration

Important note:
- low cash cost does not always mean low real cost
- part-time and rev-share setups can still create timeline risk, coordination cost, and quality variance

### Milestone type
- prototypes are usually much cheaper than slices
- slices are usually much cheaper than production releases
- live F2P or online launches increase both up-front and ongoing cost

### Art intensity
- high-fidelity art, animation, VFX, and UI polish can dominate cost quickly
- stylized or constrained art direction often reduces budget pressure

### Content volume
- lots of levels, missions, enemies, items, or narrative content can quietly become one of the biggest cost multipliers

### Technical complexity
- online multiplayer
- backend services
- procedural systems
- cross-platform support
- live operations

### Polish expectations
- a rough prototype can ignore much of this
- a pitchable slice often cannot
- a release absolutely cannot

## Common hidden costs
- QA and bug fixing
- integration time
- onboarding and UX cleanup
- tools and plugins
- localization
- legal / business setup
- platform compliance
- community / support / operations

## Simplification levers
- reduce the number of platforms
- reduce online dependence
- reduce content volume
- lower polish target for the first milestone
- use existing tools, assets, or middleware
- move from release ambition to prototype or slice ambition

FILE:references/estimation-modes.md
# Estimation Modes

Use this reference when deciding how to estimate with incomplete information.

## Team-known mode

Use when the user described the current team.

Focus on:
- what labor cost is already covered internally
- what gaps still need outside spend
- where partial coverage still creates risk
- whether timeline assumptions make the budget misleading

## Team-unknown mode

Use when the user did not describe the team.

Offer 2 to 4 rough scenarios such as:
- solo bootstrapped
- solo plus contractors
- tiny indie team
- small professional team

Keep them clearly labeled as assumptions.
Do not present scenario estimates as if they are project-specific facts.

## Location-unknown mode

Use when the team location is missing.

Say that regional labor cost can shift the estimate heavily.
Offer a range that explicitly depends on low-cost, mid-cost, or high-cost labor assumptions.

## Timeline-unknown mode

Use when no timeline or availability is provided.

State that duration and utilization can change both cash spend and delivery risk.
If needed, give a rough estimate without timeline detail but warn that it is less reliable.

## Good practice

When information is missing:
1. ask the most important questions first
2. if the user wants speed, continue with labeled assumptions
3. separate known facts from assumed facts
4. explain what would most change the estimate

---
name: game-dev-team-gap
description: Help a beginner or early-stage game team figure out which roles, skills, or disciplines they are missing for a given game concept and target scope. Use when someone asks who they are missing, whether their current team can realistically build the project, what roles they still need, what the riskiest team gaps are, or what the minimum viable team would be if no team is described yet. Ask about the game concept, target platform, intended milestone or scope, team composition, and actual skillset, then identify likely gaps, role overlaps, risky weak spots, and the smallest workable team shape.
---

# Game Dev Team Gap

Figure out who is missing, what is weakly covered, what can be safely combined, and what the minimum viable team might be.

Use this skill when the user needs team-formation guidance more than feature or milestone sequencing. The goal is not to design the perfect studio org chart. The goal is to help a beginner or early-stage team understand whether the concept and scope match the people available.

Read `references/role-patterns.md` when you need common role groupings and substitution patterns.
Read `references/minimum-team-shapes.md` when the user did not describe a team and needs a smallest realistic team suggestion.

## Core behavior

- Keep the language simple and non-jargony.
- Focus on practical coverage, not corporate titles.
- Ask only the minimum questions needed to identify major gaps.
- Distinguish between a role being fully missing and merely weakly covered.
- Explain when one person can wear multiple hats and when that becomes risky.
- Support solo, duo, and small-team realities.
- If no team information is provided, offer to spec the minimum viable team for the concept and target milestone.
- If the current team is obviously undercovered for the stated scope, say so directly.
- Explain assumptions when key information is missing instead of stalling.

## What to ask first

Prioritize these questions:
1. What is the game concept in plain language?
2. What is the target platform?
3. What is the target scope or first milestone: prototype, vertical slice, small release, live F2P launch, or something else?
4. Who is currently on the team?
5. What can each person actually do well right now?
6. Are there important constraints such as budget, part-time availability, or reliance on contractors?

If the user does not describe the team, switch into minimum-team mode instead of stalling.

## What to diagnose

Quickly identify:
- the core disciplines the concept depends on
- whether the missing work is creative, technical, production, or content-heavy
- whether the team has critical implementation coverage
- whether the team has dangerous single points of failure
- whether the team size and skill mix match the intended milestone
- whether external help, outsourcing, tools, or asset packs could reasonably cover some gaps
- whether the user is trying to hit a milestone that their current coverage cannot realistically support

## Common role areas to consider

Do not always list all of these. Only raise the ones that matter for the concept.

- gameplay programming
- technical / systems engineering
- game design
- 2D art or 3D art
- animation
- UI / UX
- audio / music / sound design
- level or content design
- writing / narrative
- production / planning
- backend / online / live-ops engineering
- QA / playtesting support
- marketing / business / publishing support

## Response structure

Always organize the answer using this structure.

### Project Snapshot
- one short summary of the game and target milestone
- one sentence on what kinds of work the project most depends on

### Current Team Read
- who is on the team
- what is clearly covered
- what is partly covered
- assumptions if information is missing

### Missing or Weakly Covered Roles
- list likely missing roles or skill areas
- explain why each matters for this concept and scope
- distinguish must-have from nice-to-have

### Minimum Viable Team
- describe the smallest realistic team shape for this project or milestone
- explain which hats can be combined safely
- explain which hats become risky to combine

### Risky Gaps
- give the top 2 to 4 team-related risks
- highlight single points of failure, unrealistic role stacking, or hidden workload cliffs

### Ways to Cover the Gaps
- hire
- find a cofounder or collaborator
- use contractors
- reduce scope
- use existing tools, middleware, or asset packs
- postpone features that require missing roles

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

## Minimum-team mode

If the user has not described a team:
- say that no team information was provided
- offer the smallest sensible team shape for the concept and milestone
- keep it realistic rather than idealized
- mention which roles can be one person and which become a bottleneck if missing
- avoid suggesting a dream team when the user only needs a workable first version

## Scope sensitivity

Adjust the answer based on the milestone.

### Prototype
- prioritize core gameplay, fast iteration, and enough content support to test the idea
- many roles can be approximated or temporarily covered with placeholders

### Vertical slice
- require stronger art, UX, polish, and production clarity
- role gaps around presentation become more important

### Release
- require broader coverage for QA, content production, business, store readiness, support, and technical stability

### Live F2P or online scope
- raise the bar sharply for backend, analytics, economy tuning, live operations, support, and ongoing content capacity

## Team-size adaptation

### Solo
- emphasize what the person is not covering
- recommend scope reduction aggressively
- suggest tools, outsourcing, or asset packs where appropriate

### Duo
- identify missing third-discipline problems
- flag if both people are strong in the same area and weak in another critical one

### Small team
- identify role overlap, bottlenecks, and coordination gaps
- point out when nobody clearly owns production, UX, backend, or content pipeline

## Style guidance

- Be practical, not romantic.
- Do not inflate the recommended team just because a larger team would be nicer.
- Do not understate risk just to sound encouraging.
- Prefer plain role descriptions over fancy job titles.
- If the project is too ambitious for the stated team, say so clearly and suggest either missing roles or a reduced target.
- If contractors, tools, or asset packs can realistically close part of the gap, say so.

## Fast mode

Use this compressed flow when the user wants a quick answer:
- what are you making
- what milestone are you targeting
- who is already on the team
- what is missing
- what is the smallest workable team for this
- how could you cover the missing parts cheaply or realistically

## Working principle

A team problem is usually not "we need more people" in the abstract. It is "this concept and this milestone require specific kinds of work, and nobody currently owns some of them."

FILE:references/minimum-team-shapes.md
# Minimum Team Shapes

Use this reference when the user did not describe the team, or when you need to explain the smallest realistic team shape for a concept and milestone.

## General rule

The minimum team is not the ideal team. It is the smallest set of coverage that makes the chosen milestone realistically achievable.

## Prototype-focused concepts

### Small offline gameplay prototype
Possible minimum:
- 1 gameplay-capable builder who can implement the core loop
- optional second person for art, content, or design support

Notes:
- placeholder assets are acceptable
- polished UI and audio can be minimal
- production can stay informal

## Vertical-slice concepts

### Presentation-sensitive vertical slice
Possible minimum:
- 1 implementation owner
- 1 art / presentation owner
- optional third support in design, UI, audio, or production depending on genre

Notes:
- one-person vertical slices are possible, but risk rises fast if the slice depends heavily on polish
- presentation gaps matter more here than in prototype mode

## Content-heavy or narrative-heavy concepts
Possible minimum:
- 1 implementation owner
- 1 art or content owner
- 1 writing / narrative / content support if the concept strongly depends on authored material

## F2P-heavy or live-service-leaning concepts
Possible minimum for a convincing early slice:
- 1 implementation owner
- 1 presentation owner
- 1 design / economy / product-thinking owner

Notes:
- for an actual live launch, this usually stops being a true small-team problem and starts needing ongoing ops coverage
- analytics, tuning, support, and content cadence are often underestimated

## Online / backend-dependent concepts
Possible minimum:
- 1 gameplay owner
- 1 backend / network-capable owner
- 1 art / UX or content owner

Notes:
- if nobody owns backend or networking, the concept is usually undercovered even if the rest of the team is strong

## Simplification advice

When the team is weaker than the concept:
- reduce online dependence
- reduce content volume
- reduce art style complexity
- reduce number of systems that need specialist support
- change the first milestone from release to prototype or slice

FILE:references/role-patterns.md
# Role Patterns

Use this reference when deciding which disciplines matter most for a given concept and how roles can combine on a small team.

## Common practical role buckets

### Gameplay / technical implementation
- gameplay programmer
- systems programmer
- technical generalist
- backend engineer for online or live-service work

### Design
- game designer
- systems designer
- level or content designer
- economy designer for F2P-heavy projects

### Art
- 2D artist
- 3D artist
- UI artist
- animator
- VFX artist

### Experience / usability
- UI / UX designer
- onboarding / flow thinker
- readability and information-design support

### Audio
- sound designer
- composer
- audio implementer

### Content / narrative
- writer
- narrative designer
- level builder
- mission or content author

### Production / operations
- producer
- project manager
- milestone and dependency owner
- QA / playtest organizer

## Useful small-team combinations

These can sometimes be one person on a small project:
- gameplay programmer + technical generalist
- game designer + level/content designer
- 2D artist + UI artist
- writer + narrative designer
- producer + designer on a tiny team

## Risky combinations

These combinations are possible, but often become weak spots:
- solo programmer + all art + UI + audio + production
- two programmers with no design or art support on a presentation-heavy slice
- artist-led team with no strong implementation owner
- design-heavy team with no production owner and no one who can actually build the systems
- F2P ambition without anyone comfortable with economy, tuning, analytics, or operations
- online multiplayer plan without clear backend/network ownership

## Important distinction

A role can be:
- fully covered
- partly covered
- weakly covered
- missing entirely

Prefer that language over yes/no judgments. Small teams often survive through partial coverage, but the risk should still be named.