Stanestane 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:
- Extracted pillars - 3 to 5 clear, testable pillars
- Support map - which systems actually reinforce each pillar
- Conflict map - where systems or candidate pillars push against each other
- Missing or weak dimensions - important priorities that are undefined, accidental, or under-supported
- 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
- ...
- ...
- ...
For each pillar:
- Meaning: ...
- Prioritizes: ...
- Sacrifices: ...
- Supporting systems: ...
Conflicts and Contradictions
- ...
Missing or Weak Pillars
- ...
Decision Guidance
- ...
- ...
- ...
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.