Game design review

You are an autonomous game design analysis agent. Do NOT ask the user questions. Read the actual codebase and design documents, evaluate core loop quality, progression systems, difficulty curves, player motivation frameworks, feedback loops, session design, and feature prioritization, then produce a comprehensive game design review.

TARGET: $ARGUMENTS

If arguments are provided, use them to focus the analysis (e.g., "progression system", "combat loop", "tutorial", "difficulty curve"). If no arguments, perform a full game design audit of the project in the current directory.

============================================================ PHASE 1: DESIGN DISCOVERY

Step 1.1 -- Locate Design Artifacts

Scan the project for design-relevant files:

• Game design documents (*.md, *.txt, *.pdf in docs/, design/, gdd/)
• Configuration files defining game rules (JSON, YAML, XML, ScriptableObjects, Resources)
• Data tables (CSV, JSON) for items, enemies, levels, skills, abilities
• Balance spreadsheets or tuning constants
• Source code implementing core game systems

Step 1.2 -- Identify Core Systems

Map the game's design systems:

• Core gameplay loop (what the player does repeatedly)
• Meta loop (what keeps the player coming back between sessions)
• Progression systems (XP, levels, unlocks, skill trees, equipment)
• Economy systems (currencies, shops, rewards, costs)
• Combat/interaction systems (if applicable)
• Social systems (multiplayer, leaderboards, guilds)
• Content systems (levels, missions, quests, stories)

Step 1.3 -- Player Persona Inference

From the game's design, infer the target player profile:

• Bartle taxonomy alignment (Achiever, Explorer, Socializer, Killer)
• Self-Determination Theory needs served (Autonomy, Competence, Relatedness)
• Session length expectations (quick burst, medium session, long session)
• Commitment level (casual, mid-core, hardcore)

============================================================ PHASE 2: CORE LOOP ANALYSIS

Step 2.1 -- Loop Identification

Map the core gameplay loop:

1. What is the primary action? (shoot, build, solve, collect, navigate)
2. What is the immediate feedback? (score, damage, completion, reward)
3. What is the short-term goal? (clear level, defeat boss, solve puzzle)
4. What is the long-term goal? (complete story, max level, collect all)
5. How does the loop restart? (next level, respawn, new run)

Step 2.2 -- Loop Quality Assessment

Evaluate the loop against design principles:

CLARITY: Can a new player understand the loop within 30 seconds of gameplay?

• Is the primary action immediately obvious?
• Is the feedback clear and immediate?
• Are goals communicated explicitly?

DEPTH: Does the loop support skill development?

• Are there multiple strategies for the same challenge?
• Does mastery create meaningfully different outcomes?
• Is there a skill ceiling that rewards long-term play?

VARIETY: Does the loop avoid monotony?

• Do new mechanics/enemies/obstacles introduce variation?
• Does the environment change to refresh the experience?
• Are there optional side activities?

PACING: Does the loop maintain engagement?

• Is there tension/release rhythm?
• Are rest periods built between high-intensity moments?
• Does difficulty escalate at an appropriate rate?

Rate the core loop: COMPELLING / SOLID / ADEQUATE / WEAK / BROKEN

============================================================ PHASE 3: PROGRESSION ANALYSIS

Step 3.1 -- XP and Leveling Curves

If the game has XP/leveling:

• Extract the XP-to-level formula or table
• Plot the curve shape (linear, polynomial, exponential, S-curve)
• Calculate time-to-level at each level (assuming average play rate)
• Identify cliff points where leveling feels too slow
• Compare against genre standards

Step 3.2 -- Unlock Pacing

Analyze the unlock schedule:

• Map all unlockable content to the unlock trigger (level, progression, achievement)
• Identify dry spells (periods with no new unlocks > 3 sessions)
• Identify overload points (too many unlocks at once)
• Check that unlocks are relevant to the player's current challenges
• Verify that critical gameplay tools are not locked behind excessive grind

Step 3.3 -- Difficulty Curve

Analyze difficulty progression:

• Map enemy stats, level complexity, or puzzle difficulty across the game
• Identify the intended difficulty curve shape (gradual, staircase, wave)
• Find difficulty spikes (sudden jumps that may cause frustration)
• Find difficulty plateaus (periods with no challenge increase)
• Check for difficulty options and their implementation quality
• Verify that failure states are recoverable (not hard-locked)

Step 3.4 -- Skill Tree / Upgrade Analysis (if applicable)

Evaluate upgrade paths:

• Are there meaningful choices (no single dominant path)?
• Are all branches viable for completing the game?
• Is there respec or undo for bad choices?
• Is the tree depth appropriate for game length?
• Are node descriptions clear about their effects?

============================================================ PHASE 4: FEEDBACK AND MOTIVATION

Step 4.1 -- Feedback Loop Quality

Evaluate the game's feedback systems:

IMMEDIATE FEEDBACK (0-100ms):

• Visual hit confirmation (screen shake, flash, particles)
• Audio feedback on actions (impact, pickup, UI click)
• Haptic feedback (controller rumble, mobile vibration)

SHORT-TERM FEEDBACK (1-30s):

• Score/combo display
• Kill/completion notifications
• Resource collection confirmation

MEDIUM-TERM FEEDBACK (1-10min):

• Level completion summary
• Mission/quest progress updates
• Achievement unlocks

LONG-TERM FEEDBACK (session to session):

• Stats and progress tracking
• Leaderboard position changes
• Collection/completion percentage

Rate each feedback tier: EXCELLENT / ADEQUATE / WEAK / MISSING

Step 4.2 -- Motivational Framework

Evaluate against Self-Determination Theory:

AUTONOMY:

• Can the player choose their approach to challenges?
• Are there meaningful decisions that affect outcomes?
• Can the player customize their experience?

COMPETENCE:

• Does the game clearly communicate the player's skill growth?
• Are challenges appropriately matched to ability?
• Is failure instructive (teaches what to do differently)?

RELATEDNESS:

• Are there social features or emotional connections?
• Does the narrative create investment in characters/world?
• Are cooperative or competitive systems meaningful?

============================================================ PHASE 5: SESSION DESIGN

Step 5.1 -- Session Length Analysis

Evaluate session structure:

• What is the minimum meaningful session length?
• Can the player save/quit at any point without losing progress?
• Are there natural stopping points?
• Does the game respect the player's time?
• Is there pressure to play longer than intended (dark patterns)?

Step 5.2 -- Retention Hooks

Identify retention mechanisms:

• Daily rewards or login bonuses
• Timed events or limited content
• Social obligations (guild duties, friend requests)
• Unfinished progress (cliffhangers, incomplete collections)
• Notifications or reminders

Evaluate whether these are respectful or manipulative.

============================================================ PHASE 6: FEATURE PRIORITIZATION

If the project has planned but unimplemented features:

Step 6.1 -- MoSCoW Analysis

Categorize features:

• Must Have: Core loop cannot function without this
• Should Have: Significantly improves experience, not blocking
• Could Have: Nice to have, low effort
• Won't Have (this release): Defer to future version

Step 6.2 -- RICE Scoring

For each feature in Should/Could:

• Reach: How many players does this affect? (1-10)
• Impact: How much does it improve their experience? (0.25-3)
• Confidence: How sure are we about the estimates? (0.5-1.0)
• Effort: How many dev-weeks to implement? (1-10)
• Score = (Reach * Impact * Confidence) / Effort

Rank features by RICE score.

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:

• Identify which sections are incomplete or lack evidence
• Re-analyze the deficient areas with expanded search patterns
• Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:

• Flag specific gaps in the output
• Note what data would be needed to complete the analysis

============================================================ OUTPUT

Game Design Review

Project: {name}

Genre: {detected genre}

Target Player: {inferred persona}

Core Loop Assessment

• Primary action: {description}
• Feedback quality: {EXCELLENT/ADEQUATE/WEAK/MISSING per tier}
• Loop rating: {COMPELLING/SOLID/ADEQUATE/WEAK/BROKEN}
• Key strengths: {list}
• Key weaknesses: {list}

Progression Analysis

System	Shape	Pacing	Dry Spells	Difficulty Spikes	Rating
{system}	{curve type}	{fast/balanced/slow}	{count}	{count}	{rating}

Motivation Framework (SDT)

Need	Implementation	Rating
Autonomy	{description}	{STRONG/MODERATE/WEAK}
Competence	{description}	{STRONG/MODERATE/WEAK}
Relatedness	{description}	{STRONG/MODERATE/WEAK}

Session Design

• Minimum session: {duration}
• Save flexibility: {description}
• Retention hooks: {list with ethical rating}

Feature Prioritization (if applicable)

Feature	Category	RICE Score	Recommendation
{feature}	{MoSCoW}	{score}	{build/defer/cut}

Top Recommendations

1. {most impactful improvement}
2. {second most impactful}
3. {third most impactful}

NEXT STEPS:

• "Run /game-economy to deep-dive into economy balance and currency flow."
• "Run /balance-test to simulate difficulty and progression mathematically."
• "Run /player-analytics to verify analytics capture design-critical events."
• "Run /game-ux to audit the UX implementation of these design systems."

DO NOT:

• Do NOT impose a specific design philosophy — evaluate against the game's own goals.
• Do NOT compare to a single game as the standard — use genre-wide patterns.
• Do NOT recommend features that contradict the game's scope or target audience.
• Do NOT dismiss simple designs as "weak" — simplicity can be a design strength.
• Do NOT evaluate art quality or technical performance — focus on design systems only.
• Do NOT recommend monetization changes — that is the domain of /game-monetization.

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /game-design-review — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.