| name | balance-check |
| description | Analyzes game balance data files, formulas, and configuration to identify outliers, broken progressions, degenerate strategies, and economy imbalances. Use after modifying any balance-related data or design. Use when user says 'balance report', 'check game balance', 'run a balance check'. |
| argument-hint | [system-name|path-to-data-file] |
| user-invocable | true |
| allowed-tools | Read, Glob, Grep |
| agent | economy-designer |
Phase 1: Identify Balance Domain
Determine the balance domain from $ARGUMENTS[0]:
- Combat → weapon/ability DPS, time-to-kill, damage type interactions
- Economy → resource faucets/sinks, acquisition rates, item pricing
- Progression → XP/power curves, dead zones, power spikes
- Loot → rarity distribution, pity timers, inventory pressure
- File path given → load that file directly and infer domain from content
If no argument, ask the user which system to check.
Phase 2: Read Data Files
Read relevant files from assets/data/ and design/balance/ for the identified domain.
Note every file read — they will appear in the Data Sources section of the report.
Phase 3: Read Design Document
Read the GDD for the system from design/gdd/ to understand intended design targets,
tuning knobs, and expected value ranges. This is the baseline for "correct" behaviour.
Phase 4: Perform Analysis
Run domain-specific checks:
Combat balance:
- Calculate DPS for all weapons/abilities at each power tier
- Check time-to-kill at each tier
- Identify any options that dominate all others (strictly better)
- Check if defensive options can create unkillable states
- Verify damage type/resistance interactions are balanced
Economy balance:
- Map all resource faucets and sinks with flow rates
- Project resource accumulation over time
- Check for infinite resource loops
- Verify gold sinks scale with gold generation
- Check if any items are never worth purchasing
Progression balance:
- Plot the XP curve and power curve
- Check for dead zones (no meaningful progression for too long)
- Check for power spikes (sudden jumps in capability)
- Verify content gates align with expected player power
- Check if skip/grind strategies break intended pacing
Loot balance:
- Calculate expected time to acquire each rarity tier
- Check pity timer math
- Verify no loot is strictly useless at any stage
- Check inventory pressure vs acquisition rate
Phase 5: Output the Analysis
## Balance Check: [System Name]
### Data Sources Analyzed
- [List of files read]
### Health Summary: [HEALTHY / CONCERNS / CRITICAL ISSUES]
### Outliers Detected
| Item/Value | Expected Range | Actual | Issue |
|-----------|---------------|--------|-------|
### Degenerate Strategies Found
- [Strategy description and why it is problematic]
### Progression Analysis
[Graph description or table showing progression curve health]
### Recommendations
| Priority | Issue | Suggested Fix | Impact |
|----------|-------|--------------|--------|
### Values That Need Attention
[Specific values with suggested adjustments and rationale]
Phase 6: Fix & Verify Cycle
After presenting the report, ask:
"Would you like to fix any of these balance issues now?"
If yes:
- Ask which issue to address first (refer to the Recommendations table by priority row)
- Guide the user to update the relevant data file in
assets/data/ or formula in design/balance/
- After each fix, offer to re-run the relevant balance checks to verify no new outliers were introduced
- If the fix changes a tuning knob defined in a GDD or referenced by an ADR, remind the user:
"This value is defined in a design document. Run /propagate-design-change [path] on the affected GDD to find downstream impacts before committing."
If no:
- Summarize open issues and suggest saving the report to
design/balance/balance-check-[system]-[date].md for later
End with:
"Re-run /balance-check after fixes to verify."
