📊

Skill 18 min lectura Claude Code

Performance Testing Skills
performance-report-analysis

Un skill de Claude Code que toma los resultados de tu test de carga y produce dos reportes: uno técnico con hallazgos, severidades y acciones concretas, y uno de negocio que traduce cada métrica a impacto de usuario sin percentiles ni jerga.

k6GatlingLocustJMeterArtilleryClaude CodePerformance AnalysisReporting

Por Rodrigo Campos · 2026-03-15

Tabla de contenidos

rcampos09/performance-testing-skills

Repositorio público · MIT License · Compatible con Claude Code, Cursor y Windsurf

¿Qué es un Claude Code Skill?

Los skills de Claude Code son instrucciones especializadas que se instalan localmente y se activan cuando el contexto de la conversación lo requiere. No son plugins ni extensiones; Claude los aplica sin que tengas que pedirlo.

Una vez instalado performance-report-analysis, si pegas los resultados de un test de carga y pides análisis, Claude aplica el skill: sigue el orden de triage, identifica bottlenecks y produce los dos reportes. No necesitas decirle cómo hacerlo.

🔍

Triage estructurado

Errores primero, throughput, p95 vs SLA, tendencia temporal, desglose por endpoint

📄

Dos reportes

Técnico para el equipo de ingeniería, negocio para stakeholders sin jerga

🛠️

Multi-herramienta

k6 · Gatling · Locust · JMeter · Artillery — interpreta el output nativo de cada una

Instalación

Un solo comando. Compatible con Claude Code, Cursor y Windsurf.

Instalar todos los skills del repositorio

Instalar solo este skill

Skills disponibles

El repositorio incluye varios skills. Se agregan nuevos con cada actualización.

performance-report-analysis

Recibe los resultados de un test de carga en cualquier formato y produce dos reportes: uno técnico con SLA compliance, regresiones con deltas calculados, hallazgos con severidad y acciones; y uno de negocio que traduce cada métrica a impacto de usuario. Cubre 13 evaluaciones de calidad.

Se activa cuando mencionas:

analiza resultadosreporte de performanceinterpreta outputk6 resultsGatling reportLocust statsJMeter summarySLA compliancebottleneckp95error ratethroughput analysisperformance summary

k6GatlingLocustJMeterArtillery

Preguntas antes del análisis

Antes de analizar nada, el skill hace preguntas. Da por hecho que hay contexto que los datos no tienen, así que lo recopila primero. Las preguntas están en tres grupos.

Grupo A

Siempre, antes de empezar

¿Qué herramienta usaste?¿El test completó según el plan?¿Quién leerá el reporte?

Grupo B

Si faltan datos críticos

¿Tienes percentiles o solo el promedio?¿Tienes SLAs definidas?¿Qué tipo de errores aparecen?

Si no hay SLAs definidas, el skill usa referencias de industria y lo dice explícitamente. Si solo tienes la media sin percentiles, lo señala como limitación antes de continuar.

Grupo C

Si hay hallazgos sospechosos

¿Había monitoreo de infra activo?¿Tienes un baseline para comparar?¿Ocurrió algo durante el test?

Las preguntas del Grupo C solo aparecen cuando los datos lo justifican. Si el test fue limpio y los datos son completos, el skill no interrumpe el flujo con preguntas que no aportan contexto útil.

Diferencia con performance-testing-strategy

Son skills complementarios que actúan en momentos distintos del ciclo de vida. Si no tienes performance-testing-strategy instalado, puedes encontrarlo aquí.

🎯

performance-testing-strategy

Antes del test

Pregunta por tipo de tráfico, SLAs, tiempo disponible
Define qué tipos de prueba ejecutar y en qué orden
Genera el plan estratégico adaptado a tu contexto
Tool-agnostic: la estrategia no depende de la herramienta

📊

performance-report-analysis

Después del test

Recibe los resultados y aplica el orden de triage
Identifica bottlenecks entre 9 patrones conocidos
Produce reporte técnico y reporte de negocio
Conoce el output nativo de cada herramienta

La diferencia práctica: strategy te dice qué ejecutar y por qué. report-analysis toma lo que ejecutaste y te dice qué encontró, qué rompió, y cómo comunicarlo. Uno planifica, el otro interpreta.

El orden de triage

El skill no empieza por las métricas más llamativas ni por el p95. Sigue un orden fijo de triage que garantiza que los problemas críticos aparezcan primero, sin que queden enterrados en métricas globales.

Errores primero

Tasa de error total y desglose por tipo. Si hay más de un 1% de errores, el resto del análisis es secundario hasta entender qué falló y por qué.

Throughput alcanzado

RPS real vs RPS objetivo. Si el sistema no alcanzó la carga planificada, los percentiles de latencia no son representativos del escenario que querías probar.

p95 vs SLA

Comparación directa de cada endpoint contra el SLA definido. No reporta solo la media global — la media puede ocultar que el 5% de los usuarios tiene una experiencia inaceptable.

Tendencia temporal

Detecta si la latencia creció durante el test. Un sistema que responde bien los primeros 5 minutos pero degrada a los 20 tiene un problema diferente al que falla desde el inicio.

Desglose por endpoint

Identifica qué endpoints específicos concentran errores o latencia alta. Los promedios globales enmascaran que un solo endpoint crítico puede estar tirando el sistema.

Ejemplo de conversación con el skill activo

El skill aplica el triage en orden aunque los datos estén incompletos, y lo indica explícitamente cuando faltan datos para algún paso.

Análisis en profundidad

El triage determina qué revisar primero. Dentro del análisis hay capas más específicas que comparar métricas con umbrales.

Distribución de latencia

Identifica 6 patrones de firma: distribución compacta, cola larga, p50 creciente con p95 estable, crecimiento exponencial, distribución bimodal, y plateau bajo estrés. Cada patrón apunta a un problema distinto. No es lo mismo una cola larga que un crecimiento exponencial, aunque ambos tengan un p95 alto.

Clasificación de errores

Separa timeout, 4xx, 5xx y connection refused. Y distingue si el error es una señal de bug en el código o una señal de capacidad: el sistema rechaza solicitudes porque está saturado, no porque haya un defecto.

Detección de regresiones

Calcula deltas explícitos respecto al baseline. Los umbrales por defecto: más del 20% de aumento en latencia activa el flag. Cualquier aumento en error rate, aunque sea del 0.1%, también lo activa. Los deltas aparecen calculados en el reporte, no solo como tendencia.

Spike y warm-up

Mide el recovery time después de un pico de carga: cuánto tardó el sistema en volver a la latencia base. Excluye el periodo de warm-up del cálculo de SLA cuando el sistema necesita tiempo para calentarse, y lo indica explícitamente en el reporte.

Interpretación de gráficos

Si describes el comportamiento de un gráfico o adjuntas una imagen, el skill sabe qué buscar en cada tipo: tendencias de degradación en response time over time, saturación en RPS bajo carga creciente, la relación entre VU count y latencia, y anomalías en la distribución de percentiles a lo largo del tiempo.

Los 2 reportes

El mismo test produce dos documentos para dos audiencias distintas. El problema habitual es que los ingenieros escriben el reporte técnico y se lo mandan directamente al negocio, que no sabe qué hacer con un p95.

Reporte técnico

Para el equipo de ingeniería y QA

▸

SLA compliance por endpoint con valores exactos y % de cumplimiento

▸

Regresiones con deltas calculados respecto al baseline. Umbral por defecto: más del 20% en latencia o cualquier aumento en error rate activa el flag

▸

Hallazgos con severidad en 5 niveles (Critical / High / Medium / Low / Informational) y acciones concretas para cada uno

▸

Diagnóstico de bottleneck con el patrón identificado y cómo confirmarlo

Reporte de negocio

Para stakeholders y product managers

▸

Sin percentiles crudos: "el 5% de los usuarios esperó más de 2 segundos", no "p95=2000ms"

▸

Impacto de usuario estimado en usuarios afectados o transacciones fallidas por minuto

▸

Semáforo de estado: apto para producción / apto con condiciones / no apto

▸

Próximos pasos en lenguaje de negocio, sin tecnicismos ni referencias a herramientas

El skill nunca mezcla las audiencias. Si el equipo necesita el reporte técnico primero para revisar antes de compartir con negocio, puedes pedirle explícitamente que genere solo uno de los dos.

Multi-herramienta: conoce el output nativo

Leer los números no es suficiente. Cada herramienta tiene su propio vocabulario y sus propias trampas, y el skill conoce las diferencias específicas que importan al interpretar resultados.

Distingue entre checks (validaciones que nunca fallan el test) y http_req_failed (errores de red reales). Un check al 80% no es lo mismo que un error rate del 80%.

Gatling

Diferencia entre KO (request fallida por assertion) y errores HTTP (respuestas 4xx/5xx). El reporte HTML puede mostrar 0 errores aunque haya requests con status 500 si no configuraste assertions.

Locust

Separa failures (excepciones Python) de requests con status de error. También identifica si el throughput real se limitó por el wait_time configurado, no por el sistema bajo prueba.

JMeter

Distingue elapsed (tiempo total del sampler, incluyendo DNS y conexión) de latency (tiempo hasta el primer byte). Un elapsed alto con latency baja indica problema de red, no de la aplicación.

Artillery

Interpreta los escenarios de vusers.completed vs vusers.failed y los p999 que Artillery reporta por defecto. Sabe que un engine.http.request_rate bajo puede indicar throttling del cliente, no del servidor.

Diagnóstico de bottlenecks: 9 patrones

El skill identifica el tipo de bottleneck a partir de la firma de métricas. Cada patrón tiene síntomas distintos en los datos: no es lo mismo un memory leak que un thread pool agotado, aunque ambos produzcan latencia alta.

CPU saturation

Latencia crece linealmente con la carga. Sin memory leak. Throughput se estanca en un techo fijo.

Memory leak

Latencia crece con el tiempo aunque la carga sea constante. Los Endurance tests lo revelan; el Smoke test no.

DB connection pool

Errores de timeout concentrados en endpoints que usan base de datos. Latencia bimodal: rápido o muy lento, sin término medio.

Thread pool exhaustion

Throughput cae en pico. Los requests se encolan pero no se procesan. El servidor responde pero tarde.

Red / I/O

Latency alta pero elapsed normal en JMeter. En k6, http_req_connecting y http_req_tls_handshaking consumen la mayoría del tiempo.

Dependencias externas

Latencia alta en endpoints que llaman a terceros. El sistema responde bien en aislamiento pero falla con carga real.

Cold start

Las primeras iteraciones del test son lentas y luego se normalizan. Frecuente en servicios serverless o con JVM sin warm-up.

Event loop (async)

Latencia p99 muy alta pero p50 normal. El event loop procesa bien la mayoría pero bloquea en operaciones síncronas.

Cache stampede

Picos de latencia periódicos y breves. El sistema se recupera solo. Correlaciona con TTL de caché expirado.

El skill no confirma el diagnóstico: lo propone como hipótesis con los síntomas observados en los datos y sugiere cómo confirmarlo. La diferencia importa porque un mal diagnóstico lleva a optimizar el lugar equivocado.

Archivos de referencia

El skill incluye tres archivos de conocimiento especializado que carga bajo demanda, solo cuando el análisis los necesita. No los carga en cada conversación.

TOOL-REPORT-FORMATS.md

Lectura campo por campo del output de k6, Gatling, Locust, JMeter y Artillery. Incluye una tabla de equivalencia cross-tool: cómo se llama la misma métrica en cada herramienta y qué significa cada campo nativo.

BOTTLENECK-PATTERNS.md

9 patrones de bottleneck con sus firmas de síntomas. CPU saturation, memory leak, DB connection pool (5 sub-patrones), thread pool exhaustion, red/I/O, dependencias externas, cold start, event loop async y cache stampede.

REPORT-TEMPLATES.md

3 plantillas listas para usar: reporte técnico completo, reporte para stakeholders de negocio y regression gate. Incluye una tarjeta de traducción de percentiles para convertir métricas técnicas a lenguaje de usuario sin perder precisión.

Workflow completo con los dos skills

Los dos skills cubren el ciclo completo de un test de performance: desde el diseño hasta la comunicación de resultados. Si no tienes instalado performance-testing-strategy, puedes instalarlo por separado.

✅

Con ambos skills

Diseñas con criterio, ejecutas con la herramienta que prefieras y comunicas resultados a dos audiencias sin tener que reformatear nada a mano.

📌

Solo report-analysis

También funciona de forma independiente. Si ya tienes una estrategia definida, puedes instalar únicamente este skill para el análisis.

📊

Del resultado al reporte en un paso

El repositorio es público y libre de usar. MIT License. Si encuentras un bug o quieres proponer mejoras, abre un issue en GitHub.

Ver repositorio en GitHub 🎯 Ver performance-testing-strategy ← Volver a Learning