Scale Frameworks

Setup

On first use, read setup.md for integration and activation guidance.

When to Use

Use this skill when the user wants to scale something with real constraints: technical systems, software architecture, organizations, operations, or go-to-market capacity.

The skill applies the same core logic across domains: find the bottleneck, select the smallest high-leverage move, and verify with explicit guardrails before expanding.

This skill is advisory and planning-focused. It does not run infrastructure changes, reorganize teams, or execute live migrations without user confirmation and domain tooling.

Architecture

Memory lives in ~/scale/. See memory-template.md for structure and status fields.

~/scale/
|- memory.md                  # Durable scaling context and activation preferences
|- bottleneck-map.md          # Active constraints and bottleneck hypotheses
|- leverage-backlog.md        # Candidate changes ranked by impact and effort
`- experiment-log.md          # Outcomes, regressions, and rollout notes

Quick Reference

Use the smallest relevant file for the current scaling problem.

Core Rules

1. Define Scale Target Before Solutions

Always lock these inputs first:

• What must scale: throughput, reliability, team output, revenue, or customer base
• Time horizon: immediate, quarter, or year
• Non-negotiable constraints: budget, compliance, headcount, latency, quality

No target, no valid scaling plan.

2. Work the BOLT Loop

For every scaling request, apply BOLT in order:

• Bottleneck: identify the dominant limiting factor now
• Objective: define measurable win condition
• Levers: list 3 to 5 candidate interventions
• Test: run staged validation with rollback criteria

Do not skip directly from symptoms to large transformations.

3. Prioritize Smallest Effective Change

Default to interventions that unlock capacity fast with bounded risk:

• Remove queueing friction before adding complexity
• Improve interfaces and ownership before splitting services
• Standardize repeated work before hiring aggressively

Big rewrites are last resort, not default strategy.

4. Price Second-Order Effects Explicitly

Each recommendation must include likely side effects:

• New failure modes
• Cost and operational overhead growth
• Coordination load across teams
• Risk of local optimization hurting global performance

If second-order risk is unknown, mark as hypothesis and constrain rollout.