$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-design-pillars-extractorExtract 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
| 1 | # Game Design Design Pillars Extractor |
| 2 | |
| 3 | Extract the real pillars a design is built around, not the polite slogans attached to it. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | 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. |
| 8 | |
| 9 | Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family. |
| 10 | Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure. |
| 11 | |
| 12 | ## Core principle |
| 13 | |
| 14 | A meaningful design pillar does two things: |
| 15 | - names what the design is trying hard to deliver |
| 16 | - implies what the design is willing to sacrifice to deliver it |
| 17 | |
| 18 | If a pillar does not create a constraint, it is not a pillar yet. |
| 19 | |
| 20 | ## What to produce |
| 21 | |
| 22 | Generate: |
| 23 | 1. **Extracted pillars** - 3 to 5 clear, testable pillars |
| 24 | 2. **Support map** - which systems actually reinforce each pillar |
| 25 | 3. **Conflict map** - where systems or candidate pillars push against each other |
| 26 | 4. **Missing or weak dimensions** - important priorities that are undefined, accidental, or under-supported |
| 27 | 5. **Decision guidance** - which pillars should dominate future choices |
| 28 | |
| 29 | ## Process |
| 30 | |
| 31 | ### 1. Define the extraction target |
| 32 | Clarify: |
| 33 | - what exact game, feature set, or loop is being analyzed |
| 34 | - whether the pillars are for the whole product or a subset |
| 35 | - whether you are extracting current pillars or intended pillars |
| 36 | |
| 37 | Write: |
| 38 | - **Extraction target** |
| 39 | - **Scope** |
| 40 | - **Current versus intended state** |
| 41 | |
| 42 | ### 2. Map the dominant design behaviors |
| 43 | Look at: |
| 44 | - core loop |
| 45 | - repeat decisions |
| 46 | - reward structure |
| 47 | - punishment structure |
| 48 | - progression model |
| 49 | - randomness profile |
| 50 | - pacing |
| 51 | - agency level |
| 52 | - social or solo emphasis |
| 53 | |
| 54 | Ask: |
| 55 | - What does the design repeatedly encourage the player to do? |
| 56 | - What kinds of decisions matter most? |
| 57 | - What behaviors are rewarded, tolerated, or ignored? |
| 58 | |
| 59 | ### 3. Infer the implicit priorities |
| 60 | Ask: |
| 61 | - What is this design optimizing for in practice? |
| 62 | - What is it willing to make harder, slower, riskier, narrower, or less accessible in order to preserve that? |
| 63 | - Which experiences seem central rather than incidental? |
| 64 | |
| 65 | This is where you move from feature description to design intention. |
| 66 | |
| 67 | ### 4. Detect tradeoffs and contradictions |
| 68 | Look for places where: |
| 69 | - one system rewards patience while another rewards speed |
| 70 | - one feature pushes mastery while another floods the loop with noise |
| 71 | - one layer promises freedom while another funnels players into one dominant path |
| 72 | - a supposed pillar is not actually reinforced by gameplay |
| 73 | |
| 74 | Do not hide contradictions. Surface them. |
| 75 | |
| 76 | ### 5. Synthesize 3 to 5 pillars |
| 77 | For each pillar, provide: |
| 78 | - **Name** |
| 79 | - **What it means** |
| 80 | - **What it prioritizes** |
| 81 | - **What it sacrifices** |
| 82 | - **Which systems support it** |
| 83 | |
| 84 | Prefer short, sharp names that imply a stance, such as: |
| 85 | - Controlled Chaos |
| 86 | - Readable Mastery |
| 87 | - High-Risk Commitment |
| 88 | - Expressive Preparation |
| 89 | - Ruthless Momentum |
| 90 | |
| 91 | Avoid vague filler such as: |
| 92 | - Fun |
| 93 | - Immersion |
| 94 | - Engagement |
| 95 | - Quality |
| 96 | - Innovation |
| 97 | |
| 98 | ### 6. Identify missing or weak pillars |
| 99 | Ask: |
| 100 | - Which important experience dimensions are currently accidental or under-defined? |
| 101 | - Which design goals are talked about but not structurally supported? |
| 102 | - Which player promises are present in language but absent in systems? |
| 103 | |
| 104 | ### 7. Turn the pillars into decision guidance |
| 105 | State: |
| 106 | - which pillar should win when tradeoffs appear |
| 107 | - which features do not support any pillar and should be challenged |
| 108 | - which future ideas fit or violate the extracted set |
| 109 | |
| 110 | ## Response structure |
| 111 | |
| 112 | Use this structure unless the user asks for something else: |
| 113 | |
| 114 | ### Extraction Target |
| 115 | - ... |
| 116 | |
| 117 | ### Extracted Design Pillars |
| 118 | 1. ... |
| 119 | 2. ... |
| 120 | 3. ... |
| 121 | |
| 122 | For each pillar: |
| 123 | - Meaning: ... |
| 124 | - Prioritizes: ... |
| 125 | - Sacrifices: ... |
| 126 | - Supporting systems: ... |
| 127 | |
| 128 | ### Conflicts and Contradictions |
| 129 | - ... |
| 130 | |
| 131 | ### Missing or Weak Pillars |
| 132 | - ... |
| 133 | |
| 134 | ### Decision Guidance |
| 135 | 1. ... |
| 136 | 2. ... |
| 137 | 3. ... |
| 138 | |
| 139 | ## Fast mode |
| 140 | |
| 141 | Use this quick pass when speed matters: |
| 142 | - What does the design reward most consistently? |
| 143 | - What is it clearly willing to sacrifice? |
| 144 | - What three priorities best describe the actual game? |
| 145 | - Which feature does not belong? |
| 146 | |
| 147 | ## Usage notes |
| 148 | |
| 149 | This extractor is especially useful for: |
| 150 | - early concept framing |
| 151 | - preproduction alignment |
| 152 | - pitch cleanup |
| 153 | - feature tria |