plan-capacity
Perform capacity planning using historical metrics and growth models. Use predict_linear for forecasting, identify resource constraints, calculate headroom, and recommend scaling actions before saturation. Use before seasonal traffic spikes or product launches, during quarterly capacity reviews, when resource utilization trends upward, or before budget planning cycles.
Best use case
plan-capacity is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Perform capacity planning using historical metrics and growth models. Use predict_linear for forecasting, identify resource constraints, calculate headroom, and recommend scaling actions before saturation. Use before seasonal traffic spikes or product launches, during quarterly capacity reviews, when resource utilization trends upward, or before budget planning cycles.
Teams using plan-capacity should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/plan-capacity/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How plan-capacity Compares
| Feature / Agent | plan-capacity | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Perform capacity planning using historical metrics and growth models. Use predict_linear for forecasting, identify resource constraints, calculate headroom, and recommend scaling actions before saturation. Use before seasonal traffic spikes or product launches, during quarterly capacity reviews, when resource utilization trends upward, or before budget planning cycles.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Plan Capacity
Forecast resource needs and prevent saturation through data-driven capacity planning.
## When to Use
- Before seasonal traffic spikes (holidays, sales events)
- When planning new feature launches
- During quarterly capacity reviews
- When resource utilization trends upward
- Before budget planning cycles
## Inputs
- **Required**: Historical metrics (CPU, memory, disk, network, requests/sec)
- **Required**: Time range for trend analysis (minimum 4 weeks)
- **Optional**: Business growth projections (expected user growth, feature launches)
- **Optional**: Budget constraints
## Procedure
### Step 1: Collect Historical Metrics
Query Prometheus for key resource metrics:
```promql
# CPU usage trend over 8 weeks
avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)
# Memory usage trend
avg(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes) by (instance)
# Disk usage growth
avg(node_filesystem_size_bytes - node_filesystem_free_bytes) by (instance, device)
# Request rate growth
sum(rate(http_requests_total[5m])) by (service)
# Database connection pool usage
avg(db_connection_pool_used / db_connection_pool_max) by (instance)
```
Export to analyze:
```bash
# Export 8 weeks of CPU data
curl -G 'http://prometheus:9090/api/v1/query_range' \
--data-urlencode 'query=avg(rate(node_cpu_seconds_total{mode!="idle"}[5m])) by (instance)' \
--data-urlencode 'start=2024-12-15T00:00:00Z' \
--data-urlencode 'end=2025-02-09T00:00:00Z' \
--data-urlencode 'step=1h' | jq '.data.result' > cpu_8weeks.json
```
**Got:** Clean time series data for each resource with no large gaps.
**If fail:** Missing data reduces forecast accuracy. Check metric retention and scrape intervals.
### Step 2: Calculate Growth Rates with predict_linear
Use Prometheus's `predict_linear()` to forecast saturation:
```promql
# Predict when CPU will hit 80% (4 weeks ahead)
predict_linear(
avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))[8w:],
4*7*24*3600 # 4 weeks in seconds
) > 0.80
# Predict disk full date (8 weeks ahead)
predict_linear(
avg(node_filesystem_size_bytes - node_filesystem_free_bytes)[8w:],
8*7*24*3600
) > 0.95 * avg(node_filesystem_size_bytes)
# Predict memory pressure (2 weeks ahead)
predict_linear(
avg(node_memory_MemTotal_bytes - node_memory_MemAvailable_bytes)[8w:],
2*7*24*3600
) / avg(node_memory_MemTotal_bytes) > 0.90
# Predict request rate capacity breach (4 weeks ahead)
predict_linear(
sum(rate(http_requests_total[5m]))[8w:],
4*7*24*3600
) > 10000 # known capacity limit
```
Create a forecasting dashboard:
```json
{
"dashboard": {
"title": "Capacity Forecast",
"panels": [
{
"title": "CPU Saturation Forecast (4 weeks)",
"targets": [
{
"expr": "predict_linear(avg(rate(node_cpu_seconds_total{mode!=\"idle\"}[5m]))[8w:], 4*7*24*3600)",
"legendFormat": "Predicted CPU"
},
{
"expr": "0.80",
"legendFormat": "Target Threshold (80%)"
}
]
},
{
"title": "Disk Full Date",
"targets": [
{
"expr": "(avg(node_filesystem_size_bytes) - predict_linear(avg(node_filesystem_free_bytes)[8w:], 8*7*24*3600)) / avg(node_filesystem_size_bytes)",
"legendFormat": "Predicted Usage %"
}
]
}
]
}
}
```
**Got:** Clear visualization showing when resources will breach thresholds.
**If fail:** If predictions look wrong (negative values, wild swings), check for:
- Insufficient history (need minimum 4 weeks)
- Step spikes (deployments, migrations) distorting trend
- Seasonal patterns not captured by linear model
### Step 3: Calculate Current Headroom
Determine safety margin before saturation:
```promql
# CPU headroom (percentage remaining before 80% threshold)
(0.80 - avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))) / 0.80 * 100
# Memory headroom (bytes remaining before 90% usage)
avg(node_memory_MemAvailable_bytes) - (avg(node_memory_MemTotal_bytes) * 0.10)
# Request rate headroom (requests/sec before saturation)
10000 - sum(rate(http_requests_total[5m]))
# Time until saturation (weeks until CPU hits 80%)
(0.80 - avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))) /
deriv(avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))[8w:]) /
(7*24*3600)
```
Create a headroom summary report:
```bash
cat > capacity_headroom.md <<'EOF'
# Capacity Headroom Report (2025-02-09)
## Current Utilization
- **CPU**: 45% average (target: <80%)
- **Memory**: 62% (target: <90%)
- **Disk**: 71% (target: <95%)
- **Request Rate**: 4,200 req/s (capacity: 10,000)
## Headroom Analysis
- **CPU**: 35% headroom → ~12 weeks until saturation
- **Memory**: 28% headroom → ~16 weeks until saturation
- **Disk**: 24% headroom → ~8 weeks until full
- **Request Rate**: 5,800 req/s headroom → ~20 weeks until capacity
## Priority Actions
1. **Disk**: Implement log rotation or expand volume within 4 weeks
2. **CPU**: Plan horizontal scaling in next quarter
3. **Memory**: Monitor but no immediate action needed
EOF
```
**Got:** Quantified headroom for each resource with time-to-saturation estimates.
**If fail:** If headroom is already negative, you're in reactive mode. Immediate scaling needed.
### Step 4: Model Growth Scenarios
Factor in business projections:
```python
# Example Python script for scenario modeling
import pandas as pd
import numpy as np
# Load historical data
df = pd.read_json('cpu_8weeks.json')
# Calculate weekly growth rate
growth_rate_weekly = df['value'].pct_change(periods=7).mean()
# Scenario 1: Current trend
weeks_ahead = 12
current_trend = df['value'].iloc[-1] * (1 + growth_rate_weekly) ** weeks_ahead
# Scenario 2: 2x user growth (marketing campaign)
accelerated_trend = df['value'].iloc[-1] * (1 + growth_rate_weekly * 2) ** weeks_ahead
# Scenario 3: New feature launch (+30% baseline)
feature_launch = (df['value'].iloc[-1] * 1.30) * (1 + growth_rate_weekly) ** weeks_ahead
print(f"Current Trend (12 weeks): {current_trend:.1%} CPU")
print(f"2x Growth Scenario: {accelerated_trend:.1%} CPU")
print(f"Feature Launch Scenario: {feature_launch:.1%} CPU")
print(f"Threshold: 80%")
```
**Got:** Multiple scenarios showing impact of business changes on capacity.
**If fail:** If scenarios exceed capacity, prioritize scaling before the event.
### Step 5: Generate Scaling Recommendations
Create actionable recommendations:
```markdown
## Capacity Scaling Plan
### Immediate Actions (Next 4 Weeks)
1. **Disk Expansion** [Priority: HIGH]
- Current: 500GB, 71% used
- Projected full date: 2025-04-01 (8 weeks)
- Action: Expand to 1TB by 2025-03-15
- Cost: $50/month additional
- Justification: 5 weeks lead time needed
2. **Log Rotation Policy** [Priority: MEDIUM]
- Current: Logs retained 90 days
- Action: Reduce to 30 days, archive to S3
- Savings: ~150GB disk space
- Cost: $5/month S3 storage
### Near-Term Actions (Next Quarter)
3. **Horizontal Scaling - API Tier** [Priority: MEDIUM]
- Current: 4 instances, 45% CPU
- Projected: 65% CPU by 2025-05-01
- Action: Add 2 instances (to 6 total)
- Cost: $400/month
- Trigger: When CPU avg exceeds 60% for 7 days
4. **Database Connection Pool** [Priority: LOW]
- Current: 50 max connections, 40% used
- Projected: 55% by Q3
- Action: Increase to 75 in Q2
- Cost: None (configuration change)
### Long-Term Planning (Next 6 Months)
5. **Migration to Auto-Scaling** [Priority: MEDIUM]
- Current: Manual scaling
- Action: Implement Kubernetes HPA (Horizontal Pod Autoscaler)
- Timeline: Q3 2025
- Benefit: Automatic response to load spikes
```
**Got:** Prioritized list with costs, timelines, and trigger conditions.
**If fail:** If recommendations are rejected due to cost, revisit thresholds or accept risk.
### Step 6: Set Up Capacity Alerts
Create alerts for low headroom:
```yaml
# capacity_alerts.yml
groups:
- name: capacity
interval: 1h
rules:
- alert: CPUCapacityLow
expr: |
(0.80 - avg(rate(node_cpu_seconds_total{mode!="idle"}[5m]))) / 0.80 < 0.20
for: 24h
labels:
severity: warning
annotations:
summary: "CPU headroom below 20%"
description: "Current CPU headroom: {{ $value | humanizePercentage }}. Scaling needed within 4 weeks."
- alert: DiskFillForecast
expr: |
predict_linear(avg(node_filesystem_free_bytes)[8w:], 4*7*24*3600) < 0.10 * avg(node_filesystem_size_bytes)
for: 1h
labels:
severity: warning
annotations:
summary: "Disk projected to fill within 4 weeks"
description: "Expand disk volume soon."
- alert: MemoryCapacityLow
expr: |
avg(node_memory_MemAvailable_bytes) < 0.15 * avg(node_memory_MemTotal_bytes)
for: 6h
labels:
severity: warning
annotations:
summary: "Memory headroom below 15%"
```
**Got:** Alerts fire before saturation, giving time to scale proactively.
**If fail:** Tune thresholds if alerts fire too often (alert fatigue) or too late (reactive scrambling).
## Validation
- [ ] Historical metrics cover at least 8 weeks
- [ ] `predict_linear()` queries return sensible forecasts (no negative values)
- [ ] Headroom calculated for all critical resources
- [ ] Growth scenarios include business projections
- [ ] Scaling recommendations have costs and timelines
- [ ] Capacity alerts configured and tested
- [ ] Report reviewed with engineering leadership and finance
## Pitfalls
- **Insufficient history**: Linear predictions need 4+ weeks of data. Less than that, forecasts are unreliable.
- **Ignoring step changes**: Deployments, migrations, or feature launches create spikes that distort trends. Filter or annotate.
- **Linear assumption**: Not all growth is linear. Exponential growth (viral products) needs different models.
- **Forgetting lead time**: Cloud provisioning is fast, but procurement, budgets, and migrations take weeks. Plan early.
- **No budget alignment**: Capacity planning without budget buy-in leads to last-minute scrambles. Involve finance early.
## Related Skills
- `setup-prometheus-monitoring` - collect the metrics used for capacity planning
- `build-grafana-dashboards` - visualize forecasts and headroom
- `optimize-cloud-costs` - balance capacity planning with cost optimizationRelated Skills
plan-tour-route
Plan a multi-stop tour route with waypoint optimization, drive/walk time estimation, and POI discovery along the route using OSM data. Covers geocoding, nearest-neighbor and TSP-based ordering, time/distance matrix calculation, and itinerary generation with points of interest. Use when planning a road trip or walking tour with multiple destinations, optimizing visit order to minimize travel time, discovering sites along a route, or comparing driving versus walking versus public transport options.
plan-sprint
Plan a sprint by refining backlog items, defining a sprint goal, calculating team capacity, selecting items, and decomposing them into tasks. Produces a SPRINT-PLAN.md with goal, selected items, task breakdown, and capacity allocation. Use when starting a new sprint in a Scrum or agile project, re-planning after significant scope change, transitioning from ad-hoc work to structured sprint cadence, or after backlog grooming when items are ready for inclusion.
plan-spectroscopic-analysis
Plan a comprehensive spectroscopic analysis campaign by defining the analytical question, assessing sample characteristics, selecting appropriate techniques using a decision matrix, planning sample preparation for each technique, sequencing analyses from non-destructive to destructive, and defining success criteria with a cross-validation strategy.
plan-release-cycle
Plan a software release cycle with milestones, feature freezes, release candidates, and go/no-go criteria. Covers calendar-based and feature-based release strategies. Use when starting planning for a major or minor version release, transitioning from ad-hoc to structured release cadence, coordinating a release across multiple teams or components, defining quality gates for a regulated project, or planning the first public release (v1.0.0) of a project.
plan-hiking-tour
Plan a hiking tour with trail selection by difficulty (SAC/UIAA), time estimation using Munter's formula, elevation analysis, and safety assessment. Covers multi-day hut-to-hut tours, day hikes, and alpine routes with terrain classification and group fitness considerations. Use when planning a day hike or multi-day trekking tour, selecting trails appropriate for a group's fitness and experience, estimating realistic hiking times, or planning hut-to-hut tours with overnight logistics.
plan-garden-calendar
Plan garden activities using solar, lunar, and biodynamic calendars. Covers USDA hardiness zones, frost date calculation, equinox/solstice anchoring, synodic lunar cycle (waxing/waning), ascending/descending moon, Maria Thun biodynamic calendar (root/leaf/flower/fruit days), succession planting schedules, and seasonal task planning. Use when planning a new growing season and needing a planting schedule, integrating lunar or biodynamic timing into garden practice, calculating frost dates and planting windows for a specific zone, setting up succession planting for continuous harvest, or conducting end-of-season review.
plan-eu-relocation
Plan a complete EU/DACH relocation timeline with dependency mapping between bureaucratic steps, deadline tracking, and country-specific procedure identification. Use when planning a move between EU/DACH countries, relocating from a non-EU country to an EU/DACH destination, coordinating employment-based relocation with employer HR, managing a relocation with tight deadlines, or when needing a single document that maps the entire relocation process end-to-end.
forage-plants
Identify and safely gather edible and useful wild plants. Covers safety rules and deadly plant recognition, habitat reading, multi-feature identification methodology, the universal edibility test, sustainable harvesting practices, preparation methods, reaction monitoring, and building knowledge with beginner-friendly universal species. Use when supplementing food supply in a wilderness or survival setting, needing medicinal or utility plants, identifying plants around camp for safety, or in long-term scenarios where foraging extends available rations.
skill-name-here
One to three sentences describing what this skill accomplishes, followed by key activation triggers. This field is the primary mechanism agents use to decide whether to activate the skill — it is read during discovery before the full body is loaded. Start with a verb. Include the most important "when to use" conditions inline. Max 1024 characters.
write-vignette
Create R package vignettes using R Markdown or Quarto. Covers vignette setup, YAML configuration, code chunk options, building and testing, and CRAN requirements for vignettes. Use when adding a Getting Started tutorial, documenting complex workflows spanning multiple functions, creating domain-specific guides, or when CRAN submission requires user-facing documentation beyond function help pages.
write-validation-documentation
Write IQ/OQ/PQ validation documentation for computerized systems in regulated environments. Covers protocols, reports, test scripts, deviation handling, and approval workflows. Use when validating R or other software for regulated use, preparing for a regulatory audit, documenting qualification of computing environments, or creating and updating validation protocols and reports for new or re-qualified systems.
write-testthat-tests
Write comprehensive testthat (edition 3) tests for R package functions. Covers test organization, expectations, fixtures, mocking, snapshot tests, parameterized tests, and achieving high coverage. Use when adding tests for new package functions, increasing test coverage for existing code, writing regression tests for bug fixes, or setting up test infrastructure for a package that lacks it.