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