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

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

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)