Claude Cursor opencode Skill

Scale Game

Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download vodailocz-kilo-kit-mcp-skills_problem-solving_scale-game-0448e6c.zip · 1 KB
Part of vodailocz/kilo-kit-mcp — 142 skills

Install

skills CLI npx skills add https://github.com/VoDaiLocz/kilo-kit-mcp/tree/main/skills/problem-solving/scale-game
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install vodailocz-kilo-kit-mcp@llmmart
Git git clone https://github.com/VoDaiLocz/kilo-kit-mcp.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole vodailocz/kilo-kit-mcp collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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
Files (kilo-kit-mcp)
  • SKILL.md 2.3 KB
    ---
    name: Scale Game
    description: Test at extremes (1000x bigger/smaller, instant/year-long) to expose fundamental truths hidden at normal scales
    when_to_use: when uncertain about scalability, edge cases unclear, or validating architecture for production volumes
    version: 1.1.0
    ---
    
    # 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
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related