home / skills / yousufjoyian / claude-skills / scale-game
This skill helps you explore systems under extreme scales to reveal fundamental truths and guide architectural decisions.
npx playbooks add skill yousufjoyian/claude-skills --skill scale-gameReview the files below or copy the command above to add this skill to your agents.
---
name: scale-game
description: Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales
---
# Scale Game
## Overview
Test your approach at extreme scales to find what breaks and what surprisingly survives.
**Core principle:** Extremes expose fundamental truths hidden at normal scales.
## Quick Reference
| Scale Dimension | Test At Extremes | What It Reveals |
|-----------------|------------------|-----------------|
| Volume | 1 item vs 1B items | Algorithmic complexity limits |
| Speed | Instant vs 1 year | Async requirements, caching needs |
| Users | 1 user vs 1B users | Concurrency issues, resource limits |
| Duration | Milliseconds vs years | Memory leaks, state growth |
| Failure rate | Never fails vs always fails | Error handling adequacy |
## Process
1. **Pick dimension** - What could vary extremely?
2. **Test minimum** - What if this was 1000x smaller/faster/fewer?
3. **Test maximum** - What if this was 1000x bigger/slower/more?
4. **Note what breaks** - Where do limits appear?
5. **Note what survives** - What's fundamentally sound?
## Examples
### Example 1: Error Handling
**Normal scale:** "Handle errors when they occur" works fine
**At 1B scale:** Error volume overwhelms logging, crashes system
**Reveals:** Need to make errors impossible (type systems) or expect them (chaos engineering)
### Example 2: Synchronous APIs
**Normal scale:** Direct function calls work
**At global scale:** Network latency makes synchronous calls unusable
**Reveals:** Async/messaging becomes survival requirement, not optimization
### Example 3: In-Memory State
**Normal duration:** Works for hours/days
**At years:** Memory grows unbounded, eventual crash
**Reveals:** Need persistence or periodic cleanup, can't rely on memory
## Red Flags You Need This
- "It works in dev" (but will it work in production?)
- No idea where limits are
- "Should scale fine" (without testing)
- Surprised by production behavior
## Remember
- Extremes reveal fundamentals
- What works at one scale fails at another
- Test both directions (bigger AND smaller)
- Use insights to validate architecture early
This skill teaches a simple, practical method: push designs to extreme scales to expose hidden assumptions and failure modes. By testing 1,000x smaller and 1,000x larger (and instant vs year-long), you discover which parts of a system are brittle or robust. The goal is to reveal fundamental truths early so you can change architecture or operations before production pain.
Pick a dimension that matters (volume, speed, users, duration, failure rate). Run thought experiments, focused tests, or load experiments at extreme low and high values and observe what breaks and what survives. Record the limits you hit, the implicit assumptions that fail, and the design patterns that remain valid. Use those findings to drive concrete architecture, monitoring, and testing changes.
How do I pick which dimension to test first?
Start with the dimension most tied to business risk: user volume for consumer products, duration for long-running state, speed for real-time systems.
Do I need full-scale infrastructure to run these tests?
No. Use targeted simulations, sampling, and thought experiments. Emulate bottlenecks, scale resource usage proportionally, or run focused load tests on critical components.