Scaling readiness: load test, perf budgets, caching, capacity planning. Use for /scale, "load test", "can this handle more users", "performance", "caching strategy", or any scaling question. Trigger liberally.
On first invocation, read references/orchestrator.md and follow its welcome protocol.
Assess and improve an app's ability to handle growth. Covers load testing,
performance budgets, caching strategy, query optimization, CDN config, and
capacity planning. Produces a scaling readiness report with a concrete upgrade
path from current capacity to target capacity.
/scale — Command Reference
SCALE OPS COMMANDS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ASSESS
/scale audit Full scaling readiness assessment
/scale budget Set or audit performance budgets
/scale bottleneck Identify the #1 scaling bottleneck
TEST
/scale loadtest Run load test against target URL
/scale benchmark Benchmark specific endpoints
OPTIMIZE
/scale cache Design or audit caching strategy
/scale queries Audit and optimize database queries
/scale cdn CDN and edge optimization
PLAN
/scale plan Capacity plan from current → target users
/scale cost Cost projection at target scale
UTILITIES
/checkpoint Show checkpoint status
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Type any command to begin. /scale to see this again.
Skills relacionados
Scaling Readiness Assessment (/scale audit)
Comprehensive evaluation of how the app handles load. Produces a readiness
score and prioritized optimization list.
-- D1: no built-in slow query log, but you can time queries in code
-- Wrap queries with timing:
async function timedQuery<T>(db: D1Database, sql: string, params: any[]): Promise<{ result: T; ms: number }> {
const start = performance.now();
const result = await db.prepare(sql).bind(...params).all();
const ms = performance.now() - start;
if (ms > 50) console.warn(`Slow query (${ms.toFixed(0)}ms): ${sql.substring(0, 100)}`);
return { result: result.results as T, ms };
}
Common Query Optimizations
Problem
Detection
Fix
Missing index
Query on column without index, table > 1K rows
CREATE INDEX idx_table_col ON table(col)
N+1 queries
Loop with DB call inside (fetch list, then fetch detail per item)
Use JOIN or batch query
SELECT *
Fetching all columns when only 2-3 needed
List specific columns
Unbounded query
No LIMIT on list queries
Add pagination (LIMIT + OFFSET or cursor)
Repeated queries
Same query called multiple times per request
Cache result in request context
Missing compound index
WHERE on multiple columns, each indexed separately
CREATE INDEX idx_tbl_a_b ON tbl(a, b)
EXPLAIN for D1
-- D1 supports EXPLAIN QUERY PLAN
EXPLAIN QUERY PLAN SELECT * FROM sessions WHERE user_id = ? AND created_at > ?;
-- Look for: SCAN TABLE (bad) vs SEARCH TABLE USING INDEX (good)
Current deployment config → infrastructure baseline
integrations-engineer
API rate limits → external constraints
Read by
Why
deploy-ops
Readiness score → deploy confidence at scale
code-auditor
Performance budgets → /audit perf thresholds
app-architect
Cost projections → spec cost estimates
Principles
Measure before optimizing. Load test first. The bottleneck is rarely where
you think it is.
Cache the read path, optimize the write path. Most apps are 90% reads.
Caching reads buys the most headroom with the least complexity.
D1 is enough until it isn't. For aidops-scale (< 100 users), D1's free
tier handles everything. Don't migrate to Postgres speculatively.
Performance budgets are guardrails, not goals. Set them once, enforce in
CI, forget about them until they break.
Scale the bottleneck, not the stack. If the bottleneck is a missing index,
adding a CDN won't help. Fix the actual constraint.
Cost scales with usage, not preparation. CF's pay-per-request model means
you don't pay for capacity you don't use. Build the optimization, deploy it,
and let usage determine cost.