balance-check

Original：🇺🇸 English

Translated

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

12installs

Sourcedonchitos/claude-code-game-studios

Added on2026-04-19

NPX Install

npx skill4agent add donchitos/claude-code-game-studios balance-check

SKILL.md Content

View Translation Comparison →

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