home / skills / nickcrew / claude-cortex / workflow-performance

workflow-performance skill

/skills/workflow-performance

This skill analyzes and optimizes system performance across baseline, bottlenecks, and infrastructure to accelerate response times and reduce resource usage.

npx playbooks add skill nickcrew/claude-cortex --skill workflow-performance

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
2.9 KB
---
name: workflow-performance
description: Systematic performance analysis and optimization. Use when things are slow, need optimization, or preparing for scale.
---

# Performance Optimization Workflow

Systematic approach to finding and fixing performance issues.

## Phase 1: Baseline
**Agents:** `performance-engineer`

Measure current state:
- Response times (p50, p95, p99)
- Memory usage
- CPU utilization
- Database query times
- Bundle sizes (frontend)
- Render performance

**Output:** Baseline metrics report

## Phase 2: Bottleneck Identification
**Agents:** `performance-engineer`

Analysis:
- Profiling (CPU, memory)
- Query analysis (slow query log, EXPLAIN)
- Bundle analysis (webpack-bundle-analyzer)
- Network analysis (waterfall, latency)

**Output:** Bottleneck list with priority ranking

## Phase 3: Optimization Planning
**Agents:** `requirements-analyst`

- Prioritize by impact vs effort
- Define expected improvements
- Determine implementation order
- Set target metrics

## Phase 4: Database Optimization
**Agents:** `database-optimizer`

Tasks:
- Query optimization (rewrite slow queries)
- Index creation/optimization
- Caching strategy (Redis, memcached)
- Connection pooling

## Phase 5: Code Optimization
**Agents:** `performance-engineer`

Focus:
- Algorithm efficiency (O(n) → O(log n))
- Memory management (leaks, allocation)
- Async operations (parallelize I/O)
- Application-level caching

## Phase 6: Frontend Optimization
**Agents:** `performance-engineer`

Tasks:
- Bundle size reduction
- Code splitting
- Lazy loading
- Asset optimization (images, fonts)
- Render optimization (virtualization, memoization)

## Phase 7: Infrastructure Optimization
**Agents:** `devops-architect`

Areas:
- Scaling strategy (horizontal/vertical)
- Caching layers (CDN, reverse proxy)
- Load balancing
- Resource allocation

## Phase 8: Validation
**Agents:** `performance-engineer`

**Blocking:** Must meet targets

Targets:
- Response time: <200ms (p95)
- Memory usage: <200MB
- Bundle size: <500KB

## Phase 9: Load Testing
**Agents:** `performance-engineer`

Scenarios:
- Normal load (expected traffic)
- Peak load (2-3x normal)
- Stress test (find breaking point)

Duration: 30min per scenario

## Phase 10: Monitoring Setup
**Agents:** `devops-architect`

- Performance dashboards
- Alerting rules (degradation detection)
- Automated profiling (continuous)

## Success Criteria
- [ ] Performance targets met
- [ ] Load tests pass
- [ ] Monitoring in place
- [ ] Documentation complete

## Targets
| Metric | Target |
|--------|--------|
| Response time improvement | 50% |
| Memory reduction | 30% |
| Cost reduction | 20% |

## Quick Reference

| Resource | Reference File |
|---|---|
| **Optimization Techniques** | `skills/workflow-performance/references/optimization-techniques.md` |

## Anti-patterns
- Optimizing without measuring first
- Micro-optimizations before algorithmic fixes
- Optimizing code that isn't the bottleneck
- No load testing before production

Overview

This skill provides a systematic workflow for diagnosing, prioritizing, and fixing performance issues across backend, frontend, database, and infrastructure. It guides teams from baseline measurement through optimizations, validation, load testing, and monitoring to ensure stable, scalable performance. The workflow is practical and outcome-focused, with clear targets and success criteria.

How this skill works

The skill runs a phased process: establish baseline metrics, identify bottlenecks via profiling and analysis, plan optimizations by impact vs effort, then implement targeted fixes in database, code, frontend, and infrastructure. After changes, it validates outcomes against set targets, executes load tests for various traffic scenarios, and installs continuous monitoring and alerts. Each phase produces concrete artifacts: reports, prioritized issue lists, change plans, and monitoring dashboards.

When to use it

  • Application response times are unacceptably slow (high p95/p99).
  • Preparing an app for increased traffic or scaling to new regions.
  • After major feature releases or architecture changes that could affect performance.
  • Before deploying to production when targets have not been validated by tests.
  • When operating costs are rising due to inefficient resource use.

Best practices

  • Measure before changing anything: capture p50/p95/p99, CPU, memory, DB timings, and bundle sizes.
  • Prioritize fixes by impact vs effort and target algorithmic or architectural causes first.
  • Use profiling tools for CPU and memory; analyze slow query logs and EXPLAIN plans for DB work.
  • Write clear validation targets and block releases until targets are met.
  • Automate load tests and continuous profiling; add dashboards and degradation alerts for early detection.

Example use cases

  • Diagnose a backend API with high p95 latency and reduce response times by optimizing queries and adding caching.
  • Shrink frontend bundle size and improve render time via code splitting, lazy loading, and asset optimization.
  • Prepare a service for a marketing-driven traffic spike by load testing at 2–3x expected load and scaling infrastructure accordingly.
  • Cut hosting costs by identifying inefficient resource allocation and implementing horizontal scaling and caching layers.
  • Implement continuous profiling and alerting so regressions are detected before users are impacted.

FAQ

What baseline metrics should I capture first?

Capture response time percentiles (p50, p95, p99), memory and CPU usage, database query times, frontend bundle sizes, and render metrics.

How do I choose optimization priorities?

Rank issues by expected user impact and implementation effort; tackle algorithmic and DB bottlenecks before micro-optimizations.

What targets are recommended?

Use practical targets like p95 < 200ms, memory < 200MB, and bundle size < 500KB, adjusted to your app’s context.