Game Design Core Loop Extractor

SKILL.md

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