Un skill de Claude Code que se activa automáticamente cuando describes una tarea de load testing o performance. Sin comandos slash. Sin configuración manual. Solo describes lo que necesitas y el skill estructura la solución correcta.
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 usuarios" o "migra este script de JMeter a Gatling", 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-lenguaje
Java · Kotlin · Scala · TypeScript · JavaScript
Instalación
Un solo comando. Compatible con Claude Code, Cursor y Windsurf.
Instalar todos los skills del repositorio
Instalar solo el skill de Gatling
Requisitos del entorno
Runtime
Versión mínima
Uso
Java (JVM)
11+
Gatling en Java, Kotlin o Scala
Maven
3.8+
Build tool para Java/Kotlin
Gradle
8.x (Gradle 9 no soportado aún)
Alternativa a Maven
Node.js
18+
Gatling en JavaScript/TypeScript
Skills disponibles
El repositorio incluye actualmente un skill. Se agregan nuevos con cada actualización.
GB
gatling-best-practices
Estructura, valida y corrige simulaciones de Gatling en todos sus lenguajes. Aplica el patrón de 5 bloques y detecta los 7 errores más frecuentes antes de que lleguen a producción.
Se activa cuando mencionas:
load testingperformance testingstress testingGatlingvirtual usersVUsramp-upinjection profilessimulationsJMeter migrationk6 migrationthroughputresponse time SLAsbenchmark API
JavaKotlinScalaTypeScriptJavaScript
Cómo funciona en la práctica
El skill entrega siempre tres cosas. Nunca menos.
1
Archivo completo y ejecutable
Una simulación completa en el lenguaje que elijas — nunca un fragmento parcial que requiera que tú completes el resto.
2
El comando exacto para ejecutarlo
Con todos los parámetros de entorno necesarios — baseUrl, usuarios, duración. Listo para copiar y pegar en tu terminal.
3
Explicación del enfoque elegido
Una línea que explica el perfil de inyección seleccionado y por qué se ajusta al objetivo del test — para que puedas justificarlo en tu equipo.
Ejemplo de conversación con el skill activo
El skill detecta automáticamente la intención de performance testing aunque no uses las palabras exactas "Gatling" o "load test".
El patrón de 5 bloques
Toda simulación generada por el skill sigue esta estructura en orden. Si algún bloque está ausente o en el orden equivocado, el test puede compilar pero producir resultados incorrectos o inútiles.
01
Protocol
Base URL, headers globales y configuración de la conexión HTTP. Define el contrato base que todos los usuarios virtuales usarán.
02
Feeders
Datos de prueba inyectados por usuario virtual — credenciales, IDs, payloads. Cada VU debe tener datos únicos para simular usuarios reales.
03
Scenario
Cadena ordenada de requests con pausas entre ellos. Sin pauses, los VUs disparan requests a velocidad máxima, generando una carga 10-100× más alta que la real.
04
Injection Profiles
Cuántos usuarios, a qué ritmo y por cuánto tiempo. Smoke (2-5 VUs), ramp (aumento gradual), constant (carga sostenida), o spike (pico repentino).
05
Assertions
Criterios de paso/falla: tasa de éxito mínima y percentil p95 de tiempo de respuesta. Sin assertions, Gatling termina con código 0 aunque todo haya fallado.
Los 7 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 pause() 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.
Un token estático hace que todos los VUs envíen sesiones idénticas — lo que invalida el test porque el servidor puede cachear la respuesta o detectar la sesión duplicada.