$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-core-loop-extractorExtract 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 disco
| 1 | # Game Design Core Loop Extractor |
| 2 | |
| 3 | Extract the actual repeatable loop that drives the experience, not a decorative feature list pretending to be structure. |
| 4 | |
| 5 | 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. |
| 6 | |
| 7 | Read `references/family-conventions.md` when you want the shared style, prioritization, and diagnosis rules for this game-design skill family. |
| 8 | Read `references/output-patterns.md` when you want the preferred recommendation and minimal-fix structure. |
| 9 | |
| 10 | ## Core principle |
| 11 | |
| 12 | A core loop is not just a sequence of actions. It is a repeatable motivational circuit. |
| 13 | |
| 14 | A useful loop definition identifies: |
| 15 | - what the player does |
| 16 | - what the game returns |
| 17 | - what state changes as a result |
| 18 | - why the player wants to re-enter the loop |
| 19 | |
| 20 | If the loop cannot explain why the player comes back for another cycle, it is incomplete. |
| 21 | |
| 22 | ## What to produce |
| 23 | |
| 24 | Generate: |
| 25 | 1. **Extracted core loop** - the clearest repeatable loop implied by the design |
| 26 | 2. **Loop step breakdown** - the key stages in order |
| 27 | 3. **Loop drivers** - what reward, pressure, tension, or fantasy pulls the player back in |
| 28 | 4. **Loop breaks and dead steps** - where the loop is weak, bloated, confusing, or non-motivating |
| 29 | 5. **Design implications** - what to simplify, strengthen, cut, or separate |
| 30 | |
| 31 | ## Process |
| 32 | |
| 33 | ### 1. Define the extraction target |
| 34 | Clarify: |
| 35 | - what exact game, feature set, or slice is being analyzed |
| 36 | - whether you are extracting the top-level game loop or a sub-loop |
| 37 | - whether a claimed loop already exists in the documentation |
| 38 | |
| 39 | Write: |
| 40 | - **Extraction target** |
| 41 | - **Loop scope** |
| 42 | - **Claimed loop if any** |
| 43 | |
| 44 | ### 2. Identify the repeated player cycle |
| 45 | Ask: |
| 46 | - What does the player do over and over? |
| 47 | - What starts the cycle? |
| 48 | - What ends one cycle and begins the next? |
| 49 | - What resource, state, knowledge, or opportunity changes each time? |
| 50 | |
| 51 | Look for actual recurrence, not one-time setup or occasional side systems. |
| 52 | |
| 53 | ### 3. Break the loop into action, feedback, reward, and renewed intent |
| 54 | For each stage, identify: |
| 55 | - **Player action** |
| 56 | - **Game response** |
| 57 | - **Reward or consequence** |
| 58 | - **Reason to continue** |
| 59 | |
| 60 | Useful questions: |
| 61 | - What is the player's immediate objective? |
| 62 | - What result does the game return? |
| 63 | - What makes the next cycle attractive or necessary? |
| 64 | - Where does tension accumulate or release? |
| 65 | |
| 66 | ### 4. Distinguish core loop from support systems |
| 67 | Separate: |
| 68 | - the actual core loop |
| 69 | - progression loops |
| 70 | - economy loops |
| 71 | - meta loops |
| 72 | - social loops |
| 73 | - retention wrappers |
| 74 | |
| 75 | A design often has many loops. Do not confuse scaffolding with the main engine. |
| 76 | |
| 77 | Ask: |
| 78 | - If optional layers vanished, what loop would still define the game minute to minute? |
| 79 | - Which systems amplify the loop versus merely decorate it? |
| 80 | |
| 81 | ### 5. Test the loop for motivational completeness |
| 82 | Check whether the loop contains: |
| 83 | - clear initiation |
| 84 | - meaningful action |
| 85 | - readable feedback |
| 86 | - satisfying reward or consequence |
| 87 | - a genuine reason to repeat |
| 88 | |
| 89 | Common failure signs: |
| 90 | - one or more steps are vague |
| 91 | - reward does not materially matter |
| 92 | - repetition exists without renewed motivation |
| 93 | - the loop is really several disconnected chains awkwardly stapled together |
| 94 | - the loop is too long to feel cyclical |
| 95 | |
| 96 | ### 6. Identify dead steps, bloat, and false loops |
| 97 | Look for: |
| 98 | - steps that do not change player state meaningfully |
| 99 | - chores inserted between meaningful beats |
| 100 | - feedback that is too weak to reinforce repetition |
| 101 | - loops that are structurally present but emotionally flat |
| 102 | - claimed loops that are really just content progression, not recurrence |
| 103 | |
| 104 | ### 7. Write the extracted loop clearly |
| 105 | Prefer a concise format such as: |
| 106 | - **Observe -> choose -> act -> resolve -> gain -> re-enter** |
| 107 | or |
| 108 | - **Explore -> fight -> earn -> upgrade -> explore again** |
| 109 | |
| 110 | Then explain why this loop has pull. |
| 111 | |
| 112 | ### 8. Convert the loop into design implications |
| 113 | For each important part of the loop, specify: |
| 114 | - **Loop step** |
| 115 | - **Current strength or weakness** |
| 116 | - **What to change** |
| 117 | - **Expected effect on repeat engagement** |
| 118 | |
| 119 | Examples: |
| 120 | - weak reward read -> improve feedback and clearer state change |
| 121 | - bloated transition step -> shorten or remove the chore layer |
| 122 | - no renewed tension -> add scarcity, discovery, escalation, or strategic consequence |
| 123 | |
| 124 | ## Response structure |
| 125 | |
| 126 | Use this structure unless the user asks for something else: |
| 127 | |
| 128 | ### Extr |