Volver a Learning
🔥
Skill 20 min lectura Claude Code

Performance Testing Skills
k6-best-practices

Un skill de Claude Code que se activa automáticamente cuando describes una tarea de load testing con k6. Sin comandos slash. Sin configuración manual. Solo describes lo que necesitas y el skill estructura la solución correcta en JavaScript o TypeScript.

k6JavaScriptTypeScriptClaude CodeLoad TestingHTTPWebSocketgRPC
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 en tu entorno y se activan de forma automática cuando el contexto de tu conversación lo requiere. No es un plugin, no es una extensión — es conocimiento experto que Claude aplica sin que tengas que pedirlo explícitamente.

Una vez instalado performance-testing-skills, si describes algo como "necesito un test de carga para este endpoint con 100 VUs en k6" o "convierte este JMeter script a k6", Claude detecta la intención y aplica el skill automáticamente — generando un archivo completo y ejecutable con el patrón correcto, no fragmentos de código incompletos.

🎯

Activación automática

Detecta la intención sin slash commands ni configuración por tarea

📄

Archivos completos

Nunca fragmentos parciales — siempre un archivo listo para ejecutar

🔌

Multi-protocolo

HTTP/REST · WebSocket · gRPC

Instalación

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

Instalar todos los skills del repositorio

Terminal ~ $ npx skills add rcampos09/performance-testing-skills Installed: k6-best-practices Skills active in Claude Code, Cursor, Windsurf

Instalar solo el skill de k6

Terminal ~ $ npx skills add rcampos09/performance-testing-skills --skill k6-best-practices Skill k6-best-practices installed successfully

Requisitos del entorno

Runtime Versión mínima Uso
k6 latest Runtime principal para ejecutar los scripts
Node.js 18+ Necesario para soporte TypeScript y bundling
esbuild / webpack opcional Transpilación TypeScript para módulos avanzados

Skills disponibles

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

K6

k6-best-practices

Genera, valida y corrige scripts de k6 en JavaScript y TypeScript. Aplica los 5 bloques esenciales, detecta los 10 errores más frecuentes y selecciona el executor correcto según el modelo de carga.

Se activa cuando mencionas:

k6load testingstress testingvirtual usersVUsthresholdsexecutorsramping-vusarrival rateSharedArrayperformance testingHTTP benchmarkWebSocket testgRPC test
JavaScriptTypeScriptHTTP/RESTWebSocketgRPC

Cómo funciona en la práctica

El skill entrega siempre tres cosas. Nunca menos.

1

Archivo completo y ejecutable

Un script k6 completo en JavaScript o TypeScript — nunca un fragmento parcial que requiera que tú completes el resto.

2

El comando exacto para ejecutarlo

Con todas las variables de entorno necesarias — BASE_URL, VUs, duración. Listo para copiar y pegar en tu terminal.

3

Explicación del executor elegido

Una línea que justifica el executor seleccionado (modelo abierto vs cerrado) y por qué se ajusta al objetivo del test.

Ejemplo de conversación con el skill activo

Claude Code You: Necesito un test de carga para POST /api/checkout con 50 RPS constantes en k6 Claude: → Skill k6-best-practices activado Generando checkout-load-test.js con constant-arrival-rate 50 RPS + thresholds p95... Executor: constant-arrival-rate (modelo abierto — RPS fija independiente de VUs) k6 run -e BASE_URL=https://api.example.com checkout-load-test.js

El skill detecta automáticamente la intención de performance testing aunque no uses explícitamente la palabra "k6".

Los 5 bloques esenciales

Todo script generado por el skill sigue esta estructura. Si algún bloque está ausente o fuera de orden, el test puede ejecutarse pero producir resultados incorrectos o inútiles.

01

Options

Configuración de escenarios, executors y thresholds (SLA gates). Los thresholds son los criterios de pase/falla — si no están aquí, k6 siempre termina con código 0 aunque todo haya fallado.

02

Data

SharedArray para datos parametrizados (usuarios, IDs, payloads). Nunca variables globales: con SharedArray los datos se cargan una vez en memoria y se comparten entre todos los VUs, evitando OOM en tests de alta concurrencia.

03

Setup

Código de inicialización que se ejecuta una sola vez antes del test. Ideal para login global, obtener tokens o semillas de datos. El objeto retornado se pasa a todas las VUs.

04

Default function

La carga de trabajo de cada VU: requests, checks, groups y sleep. Sin sleep(), los VUs disparan requests a velocidad máxima generando 10-100× más carga de la que un usuario real produciría.

05

Teardown

Limpieza post-test que recibe el objeto de setup. Crítico para WebSocket (cerrar conexiones) y gRPC (cerrar canales). En HTTP es opcional pero útil para limpiar datos de prueba.

Los 10 errores críticos que el skill detecta

El skill valida automáticamente estos patrones antes de entregar código. Si los detecta en código existente que le muestras, los corrige y explica por qué.

1

Missing sleep() entre requests

Sin think time, los VUs disparan requests a velocidad máxima — generando 10–100× más carga de la que un usuario real produciría. Los resultados son inútiles para planificación de capacidad.

❌ Incorrecto

export default function() {
  http.get(`${BASE_URL}/a`);
  http.get(`${BASE_URL}/b`);
}

✅ Correcto

export default function() {
  http.get(`${BASE_URL}/a`);
  sleep(1);
  http.get(`${BASE_URL}/b`);
}
2

Tratar check() como gate de test

Los check() en k6 nunca fallan el test — solo registran métricas. Para que el test falle debes definir thresholds en las opciones.

❌ check() no falla el test

check(res, {
  'status 200': (r) =>
    r.status === 200,
});

✅ threshold sí falla el test

// En options:
thresholds: {
  'checks': ['rate>0.99'],
  'http_req_duration': [
    'p(95)<1000'],
}
3

URLs hardcodeadas

Hardcodear la URL base hace que el script solo funcione en un entorno. Parametriza siempre con __ENV para poder apuntar a staging, producción o local sin cambiar código.

❌ Incorrecto

http.get('https://prod.api.com/users');

✅ Correcto

const BASE_URL = __ENV.BASE_URL;
http.get(`${BASE_URL}/users`);
4

Variables globales para test data en vez de SharedArray

Un array global se copia en la memoria de cada VU. Con 500 VUs y 10.000 registros CSV, el consumo de memoria se multiplica por 500. SharedArray carga los datos una sola vez y los comparte entre todos los VUs.

❌ Copia por VU (OOM risk)

const users = JSON.parse(
  open('./users.json')
);

✅ Memoria compartida

const users = new SharedArray(
  'users', () =>
  JSON.parse(open('./users.json'))
);
5

Imports desordenados

Mezclar imports de k6 y externos dificulta la lectura. Agrupar siempre: k6 core → k6 extensions → librerías externas → módulos locales.

6

Executor equivocado para el modelo de carga

Usar ramping-vus cuando necesitas RPS fija te da resultados que varían según el think time. Para RPS constante usa constant-arrival-rate.

7

preAllocatedVUs insuficiente

Si preAllocatedVUs es menor que el pico de carga necesario, k6 descarta iteraciones silenciosamente — sin errores, pero con menos carga real de la esperada.

8

gracefulStop demasiado corto

Un gracefulStop corto corta VUs activos al finalizar el test, inflando artificialmente la tasa de errores. El default de 30s suele ser insuficiente en tests de alta concurrencia.

9

Token compartido entre VUs

Usar un token global hace que todos los VUs actúen como el mismo usuario. El servidor puede cachear la sesión o detectar la duplicidad, invalidando el test por completo.

10

Missing Content-Type en body

Olvidar el header en POST/PUT causa 415 Unsupported Media Type. Usar siempre { headers: { "Content-Type": "application/json" } } o el shorthand de k6.

Guía de executors

Elegir el executor equivocado es el error más frecuente en k6. La decisión clave es si necesitas un modelo abierto (RPS fija) o cerrado (VUs concurrentes).

CLOSED MODEL VUs concurrentes

Los VUs lanzan una iteración y esperan a que termine antes de lanzar la siguiente. El throughput depende del think time y la latencia del sistema.

constant-vus VUs fijos durante toda la duración
ramping-vus Rampa gradual de subida/bajada de VUs
per-vu-iterations N iteraciones exactas por cada VU
shared-iterations Total de iteraciones repartidas entre VUs
OPEN MODEL RPS fija

k6 lanza nuevas iteraciones a un ritmo constante sin esperar a que terminen las anteriores. El throughput es predecible e independiente de la latencia.

constant-arrival-rate RPS constante durante toda la duración
ramping-arrival-rate RPS que sube o baja gradualmente
externally-controlled Control dinámico vía REST API de k6

¿Cuándo usar cada modelo?

Closed model — cuando quieres simular N usuarios navegando simultáneamente (e-commerce, aplicaciones web tradicionales).

Open model — cuando quieres validar un SLA de X RPS o replicar el throughput de producción medido en tus logs (APIs de alta frecuencia, microservicios).

Comandos de ejecución

El skill incluye el comando exacto con las variables de entorno necesarias según el script generado.

Ejecución básica con variables de entorno

$ k6 run -e BASE_URL=https://api.example.com -e VUS=100 checkout-load-test.js

Con output a InfluxDB / Grafana Cloud

$ k6 run --out influxdb=http://localhost:8086/k6 -e BASE_URL=https://api.example.com script.js

TypeScript — compilar y ejecutar

$ npm run build && k6 run -e BASE_URL=https://api.example.com dist/checkout-load-test.js

🔥

Empieza ahora

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