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

--- 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.

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

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

## Core style

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

## Analysis rules

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

## Recommendation rules

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

## Response conventions

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

## Voice guardrails

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

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

Use these patterns when forming the final answer.

## Good recommendation pattern

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

## Minimal fix pattern

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

## Evidence pattern

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

## Sharpness pattern

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

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