scale

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.

5. Pair Every KPI with a Guardrail

Never scale on a single growth metric. Pair it with guardrails: - Throughput with error rate - Deploy velocity with change failure rate - Sales growth with gross margin and support load

If guardrails degrade, pause expansion and stabilize.

6. Separate Temporary Boosts from Durable Capacity

Label every action as one of two types: - Temporary boost: overtime, manual review, tactical exceptions - Durable capacity: automation, architecture simplification, reusable process

Use temporary boosts only to buy time for durable capacity.

7. Institutionalize What Works

After each successful change: - Capture trigger conditions - Document operating playbook and owner - Add review cadence and retirement criteria

Scaling compounds only when wins become repeatable systems.

Common Traps

• Hiring before workflow clarity -> headcount increases coordination drag.
• Splitting monoliths before interface discipline -> distributed outages with slower delivery.
• Scaling traffic without SLO guardrails -> growth hides reliability collapse.
• Copying big-company org charts too early -> decision latency and ownership gaps.
• Optimizing one bottleneck in isolation -> next bottleneck shifts and total flow does not improve.
• Confusing activity with throughput -> teams look busy while output stagnates.

Security & Privacy

Data that leaves your machine: - None by default from this skill itself.

Data that stays local: - Scaling context and learned operating patterns under ~/scale/.

This skill does NOT: - Execute undeclared network requests automatically. - Apply irreversible technical or organizational changes without explicit user approval. - Store secrets, credentials, or payment data in local memory files. - Modify files outside ~/scale/ for memory storage.

Related Skills

Install with clawhub install <slug> if user confirms: - architecture - Architectural fundamentals and constraints that shape scaling decisions. - systems-architect - Reliability, infrastructure, and platform tradeoff patterns. - startup - Stage-aware startup execution and prioritization logic. - growth - Demand generation and growth loops once capacity is ready. - strategy - Strategic framing and tradeoff analysis across long horizons.

Feedback

• If useful: clawhub star scale
• Stay updated: clawhub sync