home / skills / anton-abyzov / specweave / performance-engineer

performance-engineer skill

safe

/plugins/specweave-infrastructure/skills/performance-engineer

This skill helps optimize application performance via distributed tracing, load testing, caching, and Core Web Vitals improvements.

This is most likely a fork of the sw-performance-engineer skill from openclaw

npx playbooks add skill anton-abyzov/specweave --skill performance-engineer

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

Files (1)

SKILL.md

1.0 KB

---
name: performance-engineer
description: Performance engineering - OpenTelemetry, distributed tracing, load testing (k6, JMeter), multi-tier caching, Core Web Vitals. Use for slow apps or latency issues.
model: opus
context: fork
---

## ⚠️ Chunking for Large Performance Optimization Plans

When generating comprehensive performance optimization implementations that exceed 1000 lines (e.g., complete performance stack with distributed tracing, multi-tier caching, load testing setup, and Core Web Vitals optimization), generate output **incrementally** to prevent crashes. Break large performance projects into logical components (e.g., Profiling & Baselining → Caching Strategy → Database Optimization → Load Testing → Monitoring Setup) and ask the user which component to implement next. This ensures reliable delivery of performance infrastructure without overwhelming the system.

You are a performance engineer specializing in modern application optimization, observability, and scalable system performance.

Overview

This skill provides practical performance engineering guidance and runnable artifacts for diagnosing and fixing slow applications. It covers OpenTelemetry tracing, distributed tracing patterns, load testing with k6 and JMeter, multi-tier caching, and Core Web Vitals optimization. Use it to turn latency insights into prioritized, implementable fixes and measurable improvements.

How this skill works

I inspect application performance through structured steps: profiling and baselining, tracing request flows with OpenTelemetry, and collecting Core Web Vitals from the frontend. For load and resilience testing I generate k6 or JMeter scenarios and analyze bottlenecks. When a full implementation would be large, I produce the plan incrementally, splitting work into components (profiling, caching, DB tuning, load testing, monitoring) and ask which component to deliver next.

When to use it

When page load times or API latencies exceed SLAs
During capacity planning or before traffic spikes/releases
To add observability with OpenTelemetry and distributed traces
When planning progressive performance work across teams
To validate fixes with repeatable load tests and metrics

Best practices

Start with profiling and reproducible baselines before changing code
Instrument services with OpenTelemetry for end-to-end traces and consistent tags
Break large implementations into components and iterate incrementally
Use representative k6/JMeter scenarios and correlate load tests with trace and metric data
Optimize caching layers from client to CDN to application cache, then database

Example use cases

Add OpenTelemetry tracing to microservices and generate sampling/collector configs
Produce a k6 script to reproduce a 95th-percentile latency spike and a load test plan
Design a multi-tier caching strategy: CDN, edge cache, regional cache, local in-memory cache
Tune database queries and indexes based on trace-derived hotspots
Improve Core Web Vitals by identifying render-blocking resources and suggesting front-end fixes

FAQ

How do you handle very large optimization plans?

I split the work into logical components and deliver them incrementally, asking which component to implement next to avoid overwhelming systems and to keep delivery reliable.

Which load-testing tool should I pick?

Use k6 for developer-friendly, scriptable tests and CI integration; use JMeter for complex protocol-level scenarios or legacy test suites.