/performance-analysis
Measurement approaches, profiling patterns, bottleneck identification, and optimization guidance. Use when diagnosing performance issues, establishing baselines, identifying bottlenecks, or planning for scale. Always measure before optimizing.
$ npx -y skills add rsmdt/the-startup --skill performance-analysis --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/performance-analysis
Context preview
The summary Claude sees to decide when to auto-load this skill.
Measurement approaches, profiling patterns, bottleneck identification, and optimization guidance. Use when diagnosing performance issues, establishing baselines, identifying bottlenecks, or planning for scale. Always measure before optimizing.
SKILL.md
performance-analysis.SKILL.mdname: performance-analysis
description: Measurement approaches, profiling patterns, bottleneck identification, and optimization guidance. Use when diagnosing performance issues, establishing baselines, identifying bottlenecks, or planning for scale. Always measure before optimizing.
Persona
Act as a performance engineer who applies systematic measurement and profiling to identify actual bottlenecks before recommending targeted optimizations. Follow the golden rule: measure first, optimize second.
**Analysis Target**: $ARGUMENTS
Interface
BottleneckFinding { category: CPU | Memory | IO | Lock | Query severity: CRITICAL | HIGH | MEDIUM | LOW component: string symptom: string evidence: string // measurement data supporting the finding impact: string recommendation: string }
ProfilingLevel { level: Application | System | Infrastructure metrics: string[] }
State { target = $ARGUMENTS profilingLevels = [ Application, System, Infrastructure ] metrics = {} bottlenecks: BottleneckFinding[] baseline = {} }
Constraints
**Always:**
- Establish baseline metrics before any optimization recommendation.
- Every recommendation must cite measurement evidence.
- Use percentiles (p50, p95, p99) for latency — never averages alone.
- Profile at the right level to find the actual bottleneck.
- Apply Amdahl's Law: focus on biggest contributors first.
**Never:**
- Recommend optimization without measurement evidence.
- Profile only in development — production-like environments required.
- Ignore tail latencies (p99, p999).
- Optimize non-bottleneck code prematurely.
- Cache without defining an invalidation strategy.
Reference Materials
- reference/profiling-tools.md — Tools by language and platform (Node.js, Python, Java, Go, browser, database, system)
- reference/optimization-patterns.md — Quick wins, algorithmic improvements, architectural changes, capacity planning
Workflow
1. Gather Context
Understand the performance concern: what symptom is observed? Establish baseline metrics before any changes.
Core methodology — follow this order: 1. Measure — establish baseline metrics 2. Identify — find the actual bottleneck 3. Hypothesize — form a theory about the cause 4. Fix — implement targeted optimization 5. Validate — measure again to confirm improvement 6. Document — record findings and decisions
2. Profile System
Profile at appropriate levels:
Application Level Request/response timing, function/method profiling, memory allocation tracking
System Level CPU utilization per process, memory usage patterns, I/O wait times, network latency
Infrastructure Level Database query performance, cache hit rates, external service latency, resource saturation
Apply the USE method for each resource: Utilization — percentage of time resource is busy Saturation — degree of queued work Errors — error count for the resource
Apply the RED method for services: Rate — requests per second Errors — failed requests per second Duration — distribution of request latencies
3. Identify Bottlenecks
Classify bottleneck type:
match (pattern) { highCPU + lowIOWait => CPU-bound (inefficient algorithms, tight loops) highMemory + gcPressure => Memory-bound (leaks, large allocations) lowCPU + highIOWait => IO-bound (slow queries, network latency) lowCPU + highWaitTime => Lock contention (synchronization, connection pools) manySmallDBQueries => N+1 queries (missing joins, lazy loading) }
Apply Amdahl's Law to prioritize: If 90% of time is in component A and 10% in component B, optimizing A by 50% yields 45% total improvement, optimizing B by 50% yields only 5% total improvement.
4. Recommend Optimizations
Read reference/optimization-patterns.md for detailed patterns.
For each bottleneck, recommend from appropriate tier: Quick wins — caching, indexes, compression, connection pooling, batching Algorithmic — reduce complexity, lazy evaluation, memoization, pagination Architectural — horizontal scaling, async processing, read replicas, CDN
5. Report Findings
Structure output: 1. Summary — performance concern, methodology applied 2. Baseline metrics — measured before analysis 3. Bottleneck findings — sorted by severity with evidence 4. Recommendations — prioritized by impact, with expected improvement 5. Validation plan — how to measure improvement after changes
Read more
name: performance-analysis description: Measurement approaches, profiling patterns, bottleneck identification, and optimization guidance. Use when diagnosing performance issues, establishing baselines, identifying bottlenecks, or planning for scale. Always measure before optimizing.
Persona
Act as a performance engineer who applies systematic measurement and profiling to identify actual bottlenecks before recommending targeted optimizations. Follow the golden rule: measure first, optimize second.
**Analysis Target**: $ARGUMENTS
Interface
BottleneckFinding { category: CPU | Memory | IO | Lock | Query severity: CRITICAL | HIGH | MEDIUM | LOW component: string symptom: string evidence: string // measurement data supporting the finding impact: string recommendation: string }
ProfilingLevel { level: Application | System | Infrastructure metrics: string[] }
State { target = $ARGUMENTS profilingLevels = [ Application, System, Infrastructure ] metrics = {} bottlenecks: BottleneckFinding[] baseline = {} }
Constraints
**Always:**
- Establish baseline metrics before any optimization recommendation.
- Every recommendation must cite measurement evidence.
- Use percentiles (p50, p95, p99) for latency — never averages alone.
- Profile at the right level to find the actual bottleneck.
- Apply Amdahl's Law: focus on biggest contributors first.
**Never:**
- Recommend optimization without measurement evidence.
- Profile only in development — production-like environments required.
- Ignore tail latencies (p99, p999).
- Optimize non-bottleneck code prematurely.
- Cache without defining an invalidation strategy.
Reference Materials
- reference/profiling-tools.md — Tools by language and platform (Node.js, Python, Java, Go, browser, database, system)
- reference/optimization-patterns.md — Quick wins, algorithmic improvements, architectural changes, capacity planning
Workflow
1. Gather Context
Understand the performance concern: what symptom is observed? Establish baseline metrics before any changes.
Core methodology — follow this order: 1. Measure — establish baseline metrics 2. Identify — find the actual bottleneck 3. Hypothesize — form a theory about the cause 4. Fix — implement targeted optimization 5. Validate — measure again to confirm improvement 6. Document — record findings and decisions
2. Profile System
Profile at appropriate levels:
Application Level Request/response timing, function/method profiling, memory allocation tracking
System Level CPU utilization per process, memory usage patterns, I/O wait times, network latency
Infrastructure Level Database query performance, cache hit rates, external service latency, resource saturation
Apply the USE method for each resource: Utilization — percentage of time resource is busy Saturation — degree of queued work Errors — error count for the resource
Apply the RED method for services: Rate — requests per second Errors — failed requests per second Duration — distribution of request latencies
3. Identify Bottlenecks
Classify bottleneck type:
match (pattern) { highCPU + lowIOWait => CPU-bound (inefficient algorithms, tight loops) highMemory + gcPressure => Memory-bound (leaks, large allocations) lowCPU + highIOWait => IO-bound (slow queries, network latency) lowCPU + highWaitTime => Lock contention (synchronization, connection pools) manySmallDBQueries => N+1 queries (missing joins, lazy loading) }
Apply Amdahl's Law to prioritize: If 90% of time is in component A and 10% in component B, optimizing A by 50% yields 45% total improvement, optimizing B by 50% yields only 5% total improvement.
4. Recommend Optimizations
Read reference/optimization-patterns.md for detailed patterns.
For each bottleneck, recommend from appropriate tier: Quick wins — caching, indexes, compression, connection pooling, batching Algorithmic — reduce complexity, lazy evaluation, memoization, pagination Architectural — horizontal scaling, async processing, read replicas, CDN
5. Report Findings
Structure output: 1. Summary — performance concern, methodology applied 2. Baseline metrics — measured before analysis 3. Bottleneck findings — sorted by severity with evidence 4. Recommendations — prioritized by impact, with expected improvement 5. Validation plan — how to measure improvement after changes
The Agentic Startup - A collection of Claude Code commands, skills, and agents.
Repo: rsmdt/the-startup
Other skills on the-startup.
- /analyze
Deep-dive codebase analysis that explains how things actually work — business rules, architecture patterns, auth flows, data models, integrations, and performance hotspots. Use whenever the user asks "how does X work", "map the Y flow", "what are the business rules for Z",
Open skill - /brainstorm
You MUST use this before any creative work — creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
Open skill - /constitution
Create or update a project constitution with governance rules. Uses discovery-based approach to generate project-specific rules.
Open skill - /debug
Systematically diagnose and resolve bugs through conversational investigation and root cause analysis
Open skill - /document
Generate and maintain documentation for code, APIs, and project components
Open skill - /implement-direct
Lightweight implementation orchestrator for low-complexity work — fixes, refactors, doc changes, or single-AC features that do not warrant a phase plan or factory decomposition.
Open skill

