capacity-planning-analysis

Capacity Planning Analysis

When to Use

Use this skill when you need to estimate capacity needs and scaling triggers from workload, utilization, and growth assumptions.
Use it to review an existing plan, result, or evidence set and produce actionable improvements.
Use it when context is incomplete but a bounded first pass is still valuable.

Default to Markdown for review, execution, and incremental refinement.
When the user requests tables, CSV, JSON, or ticket fields, preserve risk, evidence, priority, and boundary information.
For machine-consumed output, confirm the schema, enums, and required fields first.

Read and follow prompts/capacity-planning-analysis.md, including its input contract, execution rules, minimum coverage, and output order.
Add only context that changes the decision: scope, environment, version, constraints, evidence, and success criteria.
Audit the input, then separate confirmed facts, working assumptions, and open questions.
Rank by risk and evidence strength, and produce an artifact that can be executed or reviewed directly.
If information is missing, deliver a bounded first pass and state which conclusions remain unsupported.

When calibrating domain outcomes, valid controls, or evidence gaps, read references/domain-decision-example.md for sanitized input, per-item oracles, and reproducible calculations.
Always read prompts/capacity-planning-analysis.md; it is the complete execution specification for this skill.
For evaluation or regression, read evals/eval.yaml and the relevant cases under evals/cases/.
Load references/, examples/, scripts/, or output-formats.md only when those directories exist and the task needs them.

For each point record environment/config/instances, workload mix, arrival/completion throughput, latency percentiles, errors, CPU/memory/queues, and window. Trace measurement→SLO→candidate capacity.
Estimate only within measured SLO-acceptable regions. CPU percentage cannot linearly predict throughput; unmeasured points remain candidates constrained by downstream saturation/scaling delay.
Under supplied constant-rate/queue assumptions, scaling-wait backlog=max(0,arrivals−validated service rate)×wait seconds; check backlog latency/recovery, not only totals.
Use measured or explicitly conditional capacity after project-specified instance/dependency failure. Missing failure data cannot establish adequate headroom; margin, growth, cost, and acceptance come from the project.

use ranges instead of false precision when data is missing
separate averages from peaks
tie capacity conclusions to SLOs and validation
Never invent system behavior, fields, data, metrics, or root causes absent from the evidence.
Link important conclusions to evidence; mark unsupported conclusions as hypotheses with a verification method.
Explain priority using business impact, likelihood, or detectability.

Covered: peaks and bursts, concurrency and throughput, resource bottlenecks, safety margin, growth scenarios, degradation, cost, scaling lead time.
Separated facts, assumptions, gaps, and recommendations.
Gave high-risk items a priority, evidence basis, owner or next action.
Defined verifiable decision criteria instead of generic advice.
Performed no unauthorized production writes or destructive actions.

Listing checks without preconditions, expected outcomes, or evidence.
Marking everything high priority and avoiding tradeoffs.
Substituting tool names or generic theory for domain reasoning.
Refusing incomplete input, or pretending incomplete evidence supports certainty.

Start with paths most likely to cause business loss, safety issues, or release blockage.
Reduce uncertainty through the smallest verifiable experiment and record reproduction conditions.
Make the artifact executable and independently reviewable by another engineer.