Skills de Claude Code: Catalogo Completo con Ejemplos y Templates [2026]

1mi-proyecto/
2  .claude/
3    skills/
4      commit.md          # Skill de proyecto
5      review-pr.md       # Skill de proyecto
6      test.md            # Skill de proyecto
7    settings.json        # Configuracion del proyecto
8    settings.local.json  # Configuracion local (gitignored)
9  CLAUDE.md              # Instrucciones del proyecto
10  src/
11  package.json

1---
2name: nombre-del-skill
3description: Descripcion breve de lo que hace
4---
5 
6Aqui va el prompt que Claude Code ejecutara cuando invoques /nombre-del-skill.
7 
8Puedes usar markdown, listas, instrucciones detalladas, ejemplos de codigo
9y cualquier formato que necesites.

1---
2name: security-audit
3description: Auditoría de seguridad completa del proyecto
4args:
5  - nombre: severity
6    description: Nivel mínimo de severidad (low, medium, high, critical)
7    required: false
8    default: medium
9tools:
10  - Bash
11  - Read
12  - Grep
13allowedCommands:
14  - npm
15  - git
16  - grep
17---

1# Invocar sin argumentos
2/commit
3 
4# Invocar con argumentos
5/review-pr 142
6 
7# Invocar con flags
8/test --coverage
9 
10# Ver todos los skills disponibles
11/skills

1---
2name: commit
3description: Genera un mensaje de commit semántico analizando los cambios staged
4---
5 
6Analiza los cambios staged en git (git diff --staged) y genera un mensaje de commit
7siguiendo la convención Conventional Commits:
8 
9Formato obligatorio:
10- tipo(scope): descripcion breve (max 72 caracteres)
11- Linea en blanco
12- Cuerpo descriptivo explicando el "por qué" (no el "qué")
13- Linea en blanco
14- Footer con breaking changes si aplica
15 
16Tipos permitidos: feat, fix, docs, style, refactor, perf, test, build, ci, chore
17 
18Reglas:
191. Analiza TODOS los archivos modificados, no solo el primero
202. Si hay más de 3 archivos en diferentes módulos, sugiere dividir en commits
213. El scope debe ser el módulo o directorio principal afectado
224. Usa imperativo en español para el cuerpo: "Añade", "Corrige", "Elimina"
235. Si detectas un breaking change, incluye "BREAKING CHANGE:" en el footer
24 
25Ejecuta: git status y git diff --staged
26Luego propón el mensaje y pide confirmación antes de hacer el commit.

1---
2name: review-pr
3description: Revisa el código del PR actual o un PR específico por número
4---
5 
6Realiza una revisión completa del código del Pull Request.
7 
8Si se proporciona un número de PR, revisa ese PR. Si no, revisa los cambios
9de la rama actual respecto a main.
10 
11Estructura de la revisión:
12 
13## 1. Resumen
14- Qué hace este PR en 2-3 frases
15- Archivos modificados y líneas cambiadas
16 
17## 2. Análisis de calidad
18Para cada archivo modificado, evalúa:
19- Legibilidad del código (nombres, estructura)
20- Complejidad ciclomática (flag si > 10)
21- Duplicación de código
22- Manejo de errores
23- Type safety (para TypeScript)
24 
25## 3. Problemas encontrados
26Clasifica cada problema como:
27- CRITICAL: Bugs, vulnerabilidades de seguridad, pérdida de datos
28- WARNING: Code smells, rendimiento subóptimo, malas prácticas
29- SUGGESTION: Mejoras opcionales de estilo o legibilidad
30 
31## 4. Tests
32- ¿Se han añadido tests para los cambios?
33- ¿Los tests existentes siguen pasando?
34- Sugerencias de tests que faltan
35 
36## 5. Veredicto
37- APPROVE / REQUEST_CHANGES / COMMENT
38- Resumen de los cambios necesarios antes de merge
39 
40Ejecuta: git log main..HEAD --oneline y git diff main...HEAD

1---
2name: test
3description: Genera tests unitarios para un archivo o módulo específico
4---
5 
6Genera tests completos para el archivo o módulo indicado.
7 
8Pasos:
91. Lee el archivo objetivo y analiza todas las funciones/métodos exportados
102. Identifica el framework de testing del proyecto (Jest, Vitest, Mocha, pytest)
113. Genera tests que cubran:
12   - Caso feliz (happy path) para cada función
13   - Casos límite (null, undefined, array vacío, string vacío)
14   - Manejo de errores (throws, rejects, error responses)
15   - Edge cases específicos del dominio
16 
17Reglas:
18- Usa el mismo lenguaje que el archivo fuente
19- Importa desde rutas relativas correctas del proyecto
20- Usa mocks solo cuando sea estrictamente necesario
21- Cada test debe tener un nombre descriptivo en español
22- Agrupa tests con describe() por función
23- Target: cobertura mínima del 80% de branches
24- No generes tests triviales (getter/setter sin lógica)
25 
26Formato de salida: crea el archivo de test en la ubicación correcta según
27la convención del proyecto (__tests__/, *.test.ts, *.spec.ts).

1---
2name: refactor
3description: Analiza y refactoriza código identificando code smells y mejoras
4---
5 
6Analiza el archivo o módulo indicado y propón refactorizaciones concretas.
7 
8Proceso:
91. Lee el código y detecta estos code smells:
10   - Funciones de más de 30 líneas
11   - Más de 3 niveles de anidamiento
12   - Código duplicado (DRY violations)
13   - God classes o god functions
14   - Magic numbers/strings sin constantes
15   - Parámetros booleanos (flag arguments)
16   - Acoplamiento excesivo entre módulos
17 
182. Para cada refactorización propuesta, muestra:
19   - Qué: descripción del cambio
20   - Por qué: problema que resuelve
21   - Antes: código actual
22   - Después: código refactorizado
23   - Riesgo: bajo/medio/alto
24 
253. Ordena las refactorizaciones por impacto (mayor primero)
26 
274. Aplica solo las refactorizaciones aprobadas por el usuario
28 
29Regla crítica: NUNCA cambies la interfaz pública (exports, API endpoints,
30props de componentes) sin confirmación explícita.

1---
2name: docs
3description: Genera documentación JSDoc/TSDoc para un archivo o módulo
4---
5 
6Genera documentación completa para el archivo indicado.
7 
8Tipos de documentación según el archivo:
9- .ts/.tsx/.js/.jsx: JSDoc/TSDoc con @param, @returns, @throws, @example
10- .py: Docstrings Google-style con Args, Returns, Raises, Examples
11- README: Genera README.md del módulo con instalación, uso y API
12- API endpoints: Genera documentación OpenAPI/Swagger
13 
14Para cada función/clase, incluye:
151. Descripción breve (1 línea)
162. Descripción detallada si la lógica no es obvia
173. @param con tipo y descripción para cada parámetro
184. @returns con tipo y descripción
195. @throws para cada excepción posible
206. @example con al menos 1 ejemplo de uso real
21 
22Reglas:
23- No documentes lo obvio (getters simples, constructores triviales)
24- Usa español para las descripciones
25- Los @example deben ser ejecutables (código válido)
26- Mantén el estilo de documentación existente en el proyecto

1---
2name: debug
3description: Diagnostica un error a partir del mensaje, stack trace o comportamiento
4---
5 
6Diagnostica el error proporcionado siguiendo este proceso sistemático:
7 
81. REPRODUCIR: Identifica los pasos para reproducir el error
9   - Lee el stack trace si se proporciona
10   - Localiza el archivo y línea exactos
11   - Identifica el contexto de ejecución
12 
132. ANALIZAR: Investiga la causa raíz
14   - Lee el código fuente en la línea del error
15   - Revisa las dependencias y versiones
16   - Busca issues conocidos en el proyecto
17   - Verifica tipos y contratos de las funciones involucradas
18 
193. DIAGNOSTICAR: Presenta las causas probables
20   - Causa más probable (80%+): explicación detallada
21   - Causas alternativas: lista con probabilidad estimada
22   - Factores contribuyentes: configuración, entorno, datos
23 
244. SOLUCIONAR: Propón la corrección
25   - Fix mínimo: el cambio más pequeño que resuelve el problema
26   - Fix completo: corrección + tests + prevención
27   - Muestra el diff exacto para cada opción
28 
295. PREVENIR: Sugiere cómo evitar que vuelva a pasar
30   - Test que habría detectado el bug
31   - Mejora de tipos o validación
32   - Documentación si aplica
33 
34Acepta como input: mensaje de error, stack trace, descripción del comportamiento,
35o simplemente "el test X falla".

1---
2name: migrate
3description: Genera migraciones de base de datos seguras con rollback
4---
5 
6Genera una migración de base de datos según la descripción proporcionada.
7 
8Detecta automáticamente el ORM/herramienta del proyecto:
9- Prisma: genera archivo de migración + actualiza schema.prisma
10- TypeORM: genera migración con up() y down()
11- Knex: genera migración con exports.up y exports.down
12- Django: genera migración de Django
13- SQL puro: genera archivo .sql con UP y DOWN
14 
15Cada migración DEBE incluir:
161. Migración UP (aplicar cambios)
172. Migración DOWN (revertir cambios - OBLIGATORIO)
183. Comentarios explicando cada operación
194. Manejo de datos existentes si aplica
20 
21Validaciones de seguridad:
22- NUNCA genera DROP TABLE sin confirmación
23- NUNCA genera DELETE FROM sin WHERE
24- Las columnas NOT NULL nuevas deben tener DEFAULT o migración de datos
25- Los índices deben tener nombre explícito
26- Las foreign keys deben tener ON DELETE definido
27 
28Formato de nombre: YYYYMMDD_HHMMSS_descripcion_breve

1---
2name: security-audit
3description: Auditoría de seguridad completa del proyecto
4---
5 
6Realiza una auditoría de seguridad exhaustiva del proyecto.
7 
8Checklist de revisión (por categoría):
9 
10## Dependencias
11- Ejecuta: npm audit / pip audit / cargo audit
12- Revisa dependencias con vulnerabilidades conocidas
13- Identifica dependencias desactualizadas (más de 6 meses)
14- Busca dependencias con pocos mantenedores (riesgo supply chain)
15 
16## Secretos y credenciales
17- Busca: API keys, tokens, contraseñas hardcodeadas
18- Revisa: .env files no gitignored, archivos de configuración
19- Verifica: .gitignore incluye .env, credentials, *.pem, *.key
20 
21## Inputs y validación
22- Busca: SQL injection, XSS, command injection
23- Revisa: validación de inputs en endpoints/formularios
24- Verifica: sanitización de datos antes de renderizar
25 
26## Autenticación y autorización
27- Revisa: manejo de sesiones, tokens JWT
28- Verifica: rutas protegidas, middleware de auth
29- Busca: endpoints sin autenticación que deberían tenerla
30 
31## Configuración
32- Revisa: headers de seguridad (CORS, CSP, HSTS)
33- Verifica: configuración de producción vs desarrollo
34- Busca: debug mode habilitado, verbose logging en prod
35 
36Genera reporte con severidad: CRITICAL / HIGH / MEDIUM / LOW / INFO
37Ordena por severidad descendente.

1---
2name: performance
3description: Analiza rendimiento y propone optimizaciones concretas
4---
5 
6Analiza el rendimiento del archivo o módulo indicado.
7 
8Áreas de análisis:
9 
10## Complejidad algorítmica
11- Identifica bucles O(n²) o peor que podrían optimizarse
12- Busca operaciones de array ineficientes (filter+map vs reduce)
13- Detecta re-cálculos innecesarios (candidatos a memoización)
14 
15## Rendimiento de red
16- Llamadas API secuenciales que podrían ser paralelas (Promise.all)
17- Falta de caché en respuestas que cambian poco
18- Payloads excesivos (selecciona solo campos necesarios)
19 
20## Rendimiento de renderizado (frontend)
21- Re-renders innecesarios en React (useMemo, useCallback, React.memo)
22- Imágenes sin optimizar (next/image, lazy loading)
23- Bundles excesivos (code splitting, dynamic imports)
24- DOM excesivo (virtualización para listas largas)
25 
26## Base de datos
27- Queries N+1 (eager loading vs lazy loading)
28- Índices faltantes en columnas de WHERE/JOIN
29- Queries sin LIMIT en tablas grandes
30 
31Para cada optimización:
321. Problema detectado + impacto estimado
332. Código actual (antes)
343. Código optimizado (después)
354. Mejora esperada (ms, %, reducción de memoria)

1---
2name: deploy-check
3description: Checklist de verificación antes de desplegar a producción
4---
5 
6Ejecuta una verificación completa antes del despliegue a producción.
7 
8## 1. Build
9- Ejecuta: npm run build (o equivalente)
10- Verifica: build exitoso sin warnings críticos
11- Comprueba: tamaño del bundle (alerta si > 500KB gzipped)
12 
13## 2. Tests
14- Ejecuta: npm test (o equivalente)
15- Verifica: todos los tests pasan
16- Comprueba: cobertura mínima según configuración del proyecto
17 
18## 3. Linting
19- Ejecuta: npm run lint
20- Verifica: 0 errores (los warnings son aceptables)
21 
22## 4. Variables de entorno
23- Compara: .env.example vs variables necesarias en producción
24- Verifica: no hay valores de desarrollo hardcodeados
25- Comprueba: las URLs apuntan a producción (no localhost)
26 
27## 5. Base de datos
28- Verifica: migraciones pendientes aplicadas
29- Comprueba: seeds de producción actualizados si aplica
30 
31## 6. Seguridad
32- Ejecuta: npm audit --production
33- Verifica: no hay vulnerabilidades CRITICAL o HIGH
34- Comprueba: headers de seguridad configurados
35 
36## 7. Git
37- Verifica: rama correcta (main/master)
38- Comprueba: no hay commits de merge pendientes
39- Confirma: tag de versión creado
40 
41Genera reporte: PASS (listo para deploy) o FAIL (con lista de bloqueantes).

1---
2name: onboard
3description: Genera guía de onboarding personalizada para nuevos miembros del equipo
4---
5 
6Genera una guía de onboarding completa para un nuevo miembro del equipo.
7 
8Analiza el proyecto y genera:
9 
10## 1. Visión general del proyecto
11- Qué hace la aplicación (en 3 frases)
12- Stack tecnológico completo con versiones
13- Arquitectura a alto nivel (monolito, microservicios, serverless)
14- Servicios externos de los que depende
15 
16## 2. Setup local
17- Requisitos previos (Node, Python, Docker, etc.)
18- Pasos exactos para levantar el entorno (copiar .env, instalar deps, etc.)
19- Cómo verificar que todo funciona
20- Problemas comunes de setup y cómo resolverlos
21 
22## 3. Estructura del código
23- Directorios principales y qué contienen
24- Patrones de arquitectura usados
25- Convenciones de nombrado
26- Dónde encontrar cada tipo de código (rutas, modelos, servicios, tests)
27 
28## 4. Flujo de trabajo
29- Cómo crear una rama
30- Convención de commits
31- Proceso de PR y revisión
32- Pipeline de CI/CD
33 
34## 5. Primeras tareas sugeridas
35- 3 issues de dificultad baja etiquetados como "good first issue"
36- 1 tarea de documentación para familiarizarse con el código

1---
2name: code-standards
3description: Verifica que el código cumple los estándares del equipo
4---
5 
6Revisa el código cambiado contra los estándares del equipo definidos en CLAUDE.md.
7 
8Verifica:
9 
10## Nombrado
11- Variables y funciones: camelCase (TS/JS) o snake_case (Python)
12- Componentes React: PascalCase
13- Constantes: UPPER_SNAKE_CASE
14- Archivos: kebab-case para módulos, PascalCase para componentes
15 
16## Estructura
17- Funciones de máximo 30 líneas
18- Archivos de máximo 300 líneas
19- Máximo 3 niveles de anidamiento
20- Un export principal por archivo (excepto utils)
21 
22## Patrones obligatorios
23- Error handling: try/catch en todo código async
24- Logging: usar el logger del proyecto, nunca console.log en producción
25- Types: no usar 'any' en TypeScript (excepto justificado con comentario)
26- Imports: usar alias del proyecto (@/), nunca rutas relativas de más de 2 niveles
27 
28## Prohibiciones
29- No usar var (solo const y let)
30- No dejar TODO sin ticket asociado
31- No commitear código comentado
32- No usar !important en CSS sin justificación
33 
34Para cada violación muestra: archivo, línea, regla violada, corrección sugerida.

1---
2name: sprint-review
3description: Genera resumen automático del sprint basado en commits y PRs
4---
5 
6Genera un resumen del sprint actual analizando la actividad de Git.
7 
8Analiza los commits de las últimas 2 semanas (o el rango de fechas indicado).
9 
10Estructura del resumen:
11 
12## Métricas del sprint
13- Total de commits: X
14- PRs merged: X
15- Archivos modificados: X
16- Líneas añadidas/eliminadas: +X / -X
17- Contribuidores activos: lista
18 
19## Funcionalidades completadas
20- Agrupa commits por feature (basado en branches y mensajes)
21- Para cada feature: descripción, PRs asociados, autor principal
22 
23## Bugs corregidos
24- Lista de fix commits con descripción del problema resuelto
25 
26## Deuda técnica
27- Refactorizaciones realizadas
28- Mejoras de testing (cobertura antes vs después)
29 
30## Puntos de atención
31- Archivos con más cambios (posible hotspot de bugs)
32- PRs que tardaron más de 3 días en mergearse
33- Tests que se deshabilitaron durante el sprint
34 
35Formato de salida: Markdown listo para compartir en Slack o Confluence.

1---
2name: incident
3description: Guía de respuesta rápida ante incidencias en producción
4---
5 
6Inicia el protocolo de respuesta a incidencias.
7 
8## 1. Triaje (primeros 5 minutos)
9- Qué servicio está afectado
10- Cuántos usuarios impactados (estimación)
11- Desde cuándo ocurre (primer reporte)
12- Severidad: SEV1 (caída total), SEV2 (degradación), SEV3 (menor), SEV4 (cosmético)
13 
14## 2. Diagnóstico rápido
15- Revisa los últimos 5 deploys (git log --oneline -5 en producción)
16- Busca cambios recientes en archivos de configuración
17- Verifica estado de servicios externos (bases de datos, APIs de terceros)
18- Revisa logs de error recientes
19 
20## 3. Mitigación
21- Si el problema es un deploy reciente: genera comando de rollback
22- Si es un servicio externo: genera fallback o circuit breaker temporal
23- Si es un problema de datos: identifica la query o migración problemática
24 
25## 4. Documentación post-mortem
26Genera plantilla de post-mortem con:
27- Timeline de eventos
28- Causa raíz
29- Impacto (usuarios, duración, datos)
30- Acciones correctivas con responsable y fecha
31- Lecciones aprendidas

1---
2name: architecture
3description: Crea un ADR (Architecture Decision Record) para decisiones técnicas
4---
5 
6Genera un Architecture Decision Record (ADR) para documentar una decisión técnica.
7 
8Formato ADR:
9 
10# ADR-XXXX: [Título de la decisión]
11 
12## Estado
13Propuesto | Aceptado | Deprecado | Sustituido por ADR-XXXX
14 
15## Contexto
16- Cuál es el problema o necesidad que motiva esta decisión
17- Qué restricciones técnicas y de negocio existen
18- Qué intentos previos se han hecho
19 
20## Decisión
21- Qué se ha decidido hacer (en 2-3 frases)
22- Justificación técnica de la decisión
23 
24## Alternativas consideradas
25| Alternativa | Pros | Contras | Por qué se descartó |
26|-------------|------|---------|---------------------|
27| Opción A    | ...  | ...     | ...                 |
28| Opción B    | ...  | ...     | ...                 |
29 
30## Consecuencias
31- Positivas: qué mejora con esta decisión
32- Negativas: qué trade-offs asumimos
33- Riesgos: qué puede salir mal y cómo mitigarlo
34 
35## Referencias
36- Links a documentación, RFCs, benchmarks
37 
38Guarda el ADR en docs/adr/ con numeración secuencial (busca el último número).

1---
2name: api-design
3description: Revisa y sugiere mejoras en el diseño de endpoints API REST/GraphQL
4---
5 
6Revisa el diseño del endpoint o API indicada siguiendo las mejores prácticas.
7 
8Checklist de revisión:
9 
10## Nomenclatura
11- URLs en plural y kebab-case (/api/v1/blog-posts)
12- Verbos HTTP correctos (GET lectura, POST creación, PUT/PATCH actualización, DELETE borrado)
13- No usar verbos en URLs (/api/users NO /api/getUsers)
14 
15## Request/Response
16- Paginación para colecciones (cursor-based preferido sobre offset)
17- Filtros y ordenación consistentes (?sort=created_at&order=desc)
18- Response envelope consistente: { data, meta, errors }
19- Códigos HTTP correctos (201 Created, 204 No Content, 422 Validation)
20 
21## Seguridad
22- Autenticación requerida en endpoints sensibles
23- Rate limiting configurado
24- Validación de inputs con esquema (Zod, Joi, Pydantic)
25- CORS configurado correctamente
26 
27## Documentación
28- OpenAPI/Swagger spec actualizada
29- Ejemplos de request/response para cada endpoint
30- Errores documentados con códigos y mensajes
31 
32## Versionado
33- Estrategia de versionado definida (URL, header, query param)
34- Política de deprecación documentada
35 
36Genera: reporte de mejoras + ejemplo de spec OpenAPI corregida.

1---
2name: compliance-check
3description: Verifica cumplimiento normativo (GDPR, accesibilidad, licencias)
4---
5 
6Ejecuta verificaciones de cumplimiento normativo del proyecto.
7 
8## GDPR / Protección de datos
9- Busca almacenamiento de datos personales sin consentimiento
10- Verifica que existen mecanismos de borrado de datos (derecho al olvido)
11- Comprueba cifrado de datos sensibles en reposo y tránsito
12- Revisa que no se envían datos a terceros sin documentar
13 
14## Accesibilidad (WCAG 2.1 AA)
15- Imágenes con alt text descriptivo
16- Formularios con labels asociados
17- Contraste de colores mínimo 4.5:1
18- Navegación por teclado funcional
19- Roles ARIA correctos
20 
21## Licencias de dependencias
22- Lista todas las dependencias con su licencia
23- Flag licencias problemáticas: GPL en proyecto propietario
24- Verifica compatibilidad de licencias
25- Genera archivo THIRD_PARTY_LICENSES si no existe
26 
27## Logging y auditoría
28- Verifica que no se loggean datos sensibles (passwords, tokens, PII)
29- Comprueba que existe audit trail para operaciones críticas
30- Revisa retención de logs según política de la empresa
31 
32Genera reporte de compliance con estado: PASS / FAIL / WARNING por categoría.

1---
2name: changelog
3description: Genera changelog automático desde los commits entre dos tags/releases
4---
5 
6Genera un CHANGELOG siguiendo el formato Keep a Changelog (keepachangelog.com).
7 
8Analiza los commits entre el tag indicado (o último tag) y HEAD.
9 
10Formato de salida:
11 
12## [X.Y.Z] - YYYY-MM-DD
13 
14### Añadido (Added)
15- Nuevas funcionalidades (commits tipo feat)
16 
17### Cambiado (Changed)
18- Cambios en funcionalidades existentes (commits tipo refactor, perf)
19 
20### Deprecado (Deprecated)
21- Funcionalidades que se eliminarán en futuras versiones
22 
23### Eliminado (Removed)
24- Funcionalidades eliminadas
25 
26### Corregido (Fixed)
27- Corrección de bugs (commits tipo fix)
28 
29### Seguridad (Security)
30- Correcciones de vulnerabilidades
31 
32Reglas:
33- Agrupa commits por tipo, no por fecha
34- Cada entrada es una frase legible por humanos (no el mensaje de commit raw)
35- Incluye referencia al PR o issue si existe
36- Si un commit tiene BREAKING CHANGE, destácalo al inicio

1---
2name: estimate
3description: Estima esfuerzo y complejidad de una tarea analizando el código afectado
4---
5 
6Analiza la tarea descrita y proporciona una estimación de esfuerzo.
7 
8Proceso:
91. Identifica los archivos y módulos que habría que modificar
102. Evalúa la complejidad de cada cambio
113. Identifica dependencias y riesgos
12 
13Formato de estimación:
14 
15## Desglose de la tarea
16| Subtarea | Archivos afectados | Complejidad | Horas estimadas |
17|----------|-------------------|-------------|-----------------|
18| ...      | ...               | Baja/Media/Alta | X-Y h       |
19 
20## Estimación total
21- Optimista: X horas
22- Realista: Y horas
23- Pesimista: Z horas
24- Story points sugeridos: N (escala Fibonacci: 1,2,3,5,8,13)
25 
26## Riesgos que pueden aumentar la estimación
27- Dependencias externas
28- Código legacy sin tests
29- Requisitos ambiguos
30- Necesidad de migración de datos
31 
32## Recomendaciones
33- Sugerir si conviene dividir la tarea
34- Identificar tareas que se pueden paralelizar
35- Pre-requisitos que deben completarse antes

1---
2name: knowledge-base
3description: Busca en la documentación interna del proyecto para responder preguntas
4---
5 
6Busca en la documentación interna del proyecto para responder la pregunta del usuario.
7 
8Fuentes de búsqueda (en orden de prioridad):
91. CLAUDE.md del proyecto
102. README.md y docs/
113. Comentarios en código y JSDoc
124. Archivos de configuración (package.json, tsconfig, etc.)
135. ADRs (Architecture Decision Records) en docs/adr/
146. CHANGELOG.md
157. Commits recientes relacionados con la pregunta
16 
17Formato de respuesta:
181. Respuesta directa a la pregunta
192. Fuente exacta (archivo + línea) de donde se obtuvo la información
203. Contexto adicional relevante
214. Si no encuentra la respuesta: indica qué documentación falta y sugiere crearla
22 
23Reglas:
24- No inventes información que no esté en los archivos del proyecto
25- Si hay información contradictoria entre fuentes, prioriza el orden indicado
26- Cita siempre la fuente exacta

1---
2name: seo-audit
3description: Auditoría SEO técnica completa para proyectos web
4---
5 
6Realiza una auditoría SEO técnica del proyecto web.
7 
8## Meta tags
9- Verifica: title (50-60 chars), description (150-160 chars) en cada página
10- Busca: páginas sin meta description o con duplicadas
11- Comprueba: canonical URLs correctas (www vs no-www)
12- Revisa: Open Graph y Twitter Cards en todas las páginas
13 
14## Estructura
15- Verifica: un solo H1 por página
16- Comprueba: jerarquía correcta de headings (H1 > H2 > H3, sin saltos)
17- Busca: imágenes sin alt text
18- Revisa: enlaces internos rotos
19 
20## Rendimiento SEO
21- Verifica: sitemap.xml existe y es válido
22- Comprueba: robots.txt configurado correctamente
23- Revisa: URLs amigables (kebab-case, sin parámetros innecesarios)
24- Busca: redirects 301 configurados para URLs antiguas
25 
26## Datos estructurados
27- Verifica: JSON-LD en páginas clave (Article, Organization, FAQ, BreadcrumbList)
28- Comprueba: schema válido contra schema.org
29- Revisa: breadcrumbs implementados
30 
31## Core Web Vitals
32- Analiza: tamaño de imágenes (sugiere WebP/AVIF)
33- Busca: JavaScript bloqueante en el render
34- Revisa: lazy loading en imágenes below-the-fold
35 
36Genera reporte con prioridades: CRITICAL > HIGH > MEDIUM > LOW.

1---
2name: i18n
3description: Prepara el código para internacionalización o extrae textos para traducir
4---
5 
6Analiza el proyecto y genera todo lo necesario para internacionalización.
7 
8Modo 1: Preparar proyecto para i18n
9- Detecta framework de i18n existente (next-intl, react-i18next, vue-i18n)
10- Si no existe, recomienda el más adecuado para el stack
11- Genera configuración base
12 
13Modo 2: Extraer textos
14- Escanea todos los archivos del proyecto
15- Extrae textos hardcodeados en componentes, páginas y templates
16- Genera archivo de traducciones base (es.json, en.json)
17- Reemplaza textos por claves de traducción: t('key')
18 
19Formato del archivo de traducciones:
20{
21  "common": {
22    "save": "Guardar",
23    "cancel": "Cancelar"
24  },
25  "pages": {
26    "home": {
27      "title": "Página de inicio",
28      "subtitle": "Bienvenido"
29    }
30  }
31}
32 
33Reglas:
34- Las claves deben ser descriptivas (pages.home.title, no key_001)
35- Agrupa por contexto (common, pages, components, errors)
36- Incluye plurales cuando sea necesario
37- No extraigas textos de logs o mensajes de debug

1---
2name: accessibility
3description: Verifica accesibilidad WCAG 2.1 AA en componentes y páginas
4---
5 
6Audita la accesibilidad del componente o página indicada.
7 
8Checklist WCAG 2.1 AA:
9 
10## Perceptible
11- Imágenes: alt text descriptivo (no "imagen", no vacío excepto decorativas)
12- Videos: subtítulos y transcripciones
13- Contraste: mínimo 4.5:1 texto normal, 3:1 texto grande
14- Responsive: contenido legible a 200% zoom
15 
16## Operable
17- Teclado: todos los elementos interactivos accesibles con Tab
18- Focus: indicador de focus visible (no outline: none sin alternativa)
19- Skip links: link "Saltar al contenido" en la navegación
20- Timeouts: usuario puede extender o pausar
21 
22## Comprensible
23- Labels: todos los inputs tienen label asociado (htmlFor/id)
24- Errores: mensajes de error descriptivos junto al campo
25- Idioma: lang attribute en html tag
26- Consistencia: navegación consistente entre páginas
27 
28## Robusto
29- Roles ARIA: usados correctamente (no redundantes con HTML semántico)
30- Landmarks: main, nav, header, footer, aside
31- Live regions: aria-live para contenido dinámico
32- Validación: HTML válido
33 
34Para cada problema: severidad, línea, regla WCAG violada, corrección con código.

1---
2name: data-pipeline
3description: Diseña un pipeline de datos ETL/ELT con código y documentación
4---
5 
6Diseña un pipeline de datos basado en la descripción proporcionada.
7 
8Genera:
9 
10## 1. Arquitectura del pipeline
11- Fuentes de datos (origen)
12- Transformaciones necesarias
13- Destino (data warehouse, lake, API)
14- Frecuencia de ejecución
15 
16## 2. Código del pipeline
17- Extract: conectores a las fuentes de datos
18- Transform: lógica de limpieza, validación y transformación
19- Load: escritura al destino con manejo de errores
20 
21## 3. Manejo de errores
22- Reintentos con backoff exponencial
23- Dead letter queue para registros fallidos
24- Alertas en caso de fallo
25 
26## 4. Monitorización
27- Métricas: registros procesados, tiempo de ejecución, tasa de error
28- Logs estructurados
29- Dashboard sugerido
30 
31Herramientas soportadas: Apache Airflow, Prefect, Dagster, dbt, Python scripts.

1---
2name: prompt-engineer
3description: Optimiza prompts para LLMs siguiendo las mejores prácticas
4---
5 
6Analiza y optimiza el prompt proporcionado para obtener mejores resultados.
7 
8Técnicas de optimización aplicadas:
9 
101. Claridad: eliminar ambigüedades y ser específico
112. Estructura: usar formato claro (listas, secciones, ejemplos)
123. Contexto: añadir contexto relevante sin ruido
134. Restricciones: definir explícitamente qué NO hacer
145. Few-shot: añadir 2-3 ejemplos de input/output esperado
156. Chain of thought: pedir razonamiento paso a paso si aplica
167. Output format: especificar formato exacto de salida
17 
18Para cada optimización muestra:
19- Prompt original (lo que tenías)
20- Prompt optimizado (lo que deberías usar)
21- Por qué es mejor (explicación de la mejora)
22- Resultado esperado (qué diferencia verás)

1---
2name: cost-estimate
3description: Estima costes mensuales de infraestructura cloud
4---
5 
6Analiza la arquitectura del proyecto y estima costes mensuales en la nube.
7 
8Proveedores soportados: AWS, GCP, Azure, Vercel, Railway, Fly.io
9 
10Análisis por servicio:
11- Compute: instancias, funciones serverless, contenedores
12- Storage: bases de datos, object storage, CDN
13- Network: transferencia de datos, load balancers, DNS
14- Otros: monitorización, logging, CI/CD, backups
15 
16Genera tabla de costes:
17| Servicio | Tier/Config | Coste mensual | Notas |
18|----------|-------------|---------------|-------|
19| ...      | ...         | XX EUR        | ...   |
20| **Total** |            | **XXX EUR**   |       |
21 
22Incluye:
23- Estimación para 3 escenarios de tráfico (1K, 10K, 100K MAU)
24- Recomendaciones para reducir costes
25- Free tier vs primer euro: cuándo empiezas a pagar

1---
2name: benchmark
3description: Crea y ejecuta benchmarks de rendimiento para funciones críticas
4---
5 
6Genera benchmarks de rendimiento para el código indicado.
7 
8Para cada función/endpoint a benchmarkear:
9 
101. Setup: preparar datos de prueba realistas
112. Warmup: 100 iteraciones de calentamiento (JIT, caché)
123. Ejecución: 1000+ iteraciones medidas
134. Medición: tiempo medio, P50, P95, P99, desviación estándar
145. Memoria: heap usado antes y después
156. Comparación: si hay implementación alternativa, ejecutar ambas
16 
17Formato de resultados:
18| Función | Ops/sec | Media | P95 | P99 | Memoria |
19|---------|---------|-------|-----|-----|---------|
20| v1      | 10,000  | 0.1ms | 0.3ms | 0.8ms | 2MB |
21| v2      | 25,000  | 0.04ms | 0.1ms | 0.3ms | 1.5MB |
22 
23Genera código de benchmark ejecutable con: Benchmark.js (JS), pytest-benchmark
24(Python), criterion (Rust), o el framework nativo del lenguaje.

1---
2name: schema-design
3description: Diseña o revisa esquema de base de datos con mejores prácticas
4---
5 
6Diseña o revisa el esquema de base de datos según los requisitos.
7 
8Genera:
91. Diagrama entidad-relación (formato Mermaid para visualizar)
102. SQL de creación de tablas con tipos correctos
113. Índices recomendados basados en queries esperadas
124. Constraints: foreign keys, unique, check
135. Migraciones si es un cambio sobre esquema existente
14 
15Mejores prácticas aplicadas:
16- Normalización hasta 3NF (desnormalizar solo con justificación)
17- UUIDs vs auto-increment según el caso
18- Timestamps: created_at y updated_at en todas las tablas
19- Soft delete vs hard delete (deleted_at nullable)
20- Tipos correctos: no usar varchar(255) para todo
21- Enums como tipos nativos de la BD o tablas de lookup

1---
2name: monitoring
3description: Configura monitorización y alertas para la aplicación
4---
5 
6Genera configuración de monitorización completa.
7 
8## Métricas de aplicación (RED method)
9- Rate: peticiones por segundo
10- Errors: tasa de errores (4xx, 5xx)
11- Duration: latencia P50, P95, P99
12 
13## Health checks
14- Endpoint /health con verificación de dependencias
15- Liveness probe (la app responde)
16- Readiness probe (la app puede servir tráfico)
17 
18## Alertas recomendadas
19| Alerta | Condición | Severidad | Acción |
20|--------|-----------|-----------|--------|
21| Error rate alto | >5% en 5 min | Critical | Notificar oncall |
22| Latencia alta | P99 >2s en 10 min | Warning | Investigar |
23| Memoria alta | >85% durante 15 min | Warning | Scale up |
24| Disco lleno | >90% | Critical | Limpiar logs |
25 
26Herramientas soportadas: Prometheus + Grafana, Datadog, New Relic,
27Sentry (errores), Uptime Robot (disponibilidad).

1---
2name: disaster-recovery
3description: Genera plan de recuperación ante desastres (DR) del proyecto
4---
5 
6Genera un plan de Disaster Recovery (DR) para el proyecto.
7 
8## Inventario de servicios críticos
9- Lista servicios, bases de datos, APIs externas
10- RPO (Recovery Point Objective): cuántos datos puedes perder
11- RTO (Recovery Time Objective): cuánto tiempo puedes estar caído
12 
13## Estrategias de backup
14| Servicio | Frecuencia backup | Retención | Ubicación | Test de restauración |
15|----------|-------------------|-----------|-----------|---------------------|
16| BD principal | Cada 6h | 30 días | Región secundaria | Mensual |
17| Object storage | Continuo | 90 días | Multi-región | Trimestral |
18 
19## Runbooks de recuperación
20Para cada escenario de fallo:
211. Base de datos corrompida: pasos para restaurar desde backup
222. Región cloud caída: failover a región secundaria
233. Credenciales comprometidas: rotación de secretos
244. Ataque DDoS: activar protección y mitigación
25 
26## Pruebas de DR
27- Calendario de simulacros (mínimo trimestral)
28- Checklist de verificación post-recuperación
29- Métricas: RTO real vs objetivo, RPO real vs objetivo

1{
2  "hooks": {
3    "PreToolUse": [
4      {
5        "matcher": "Edit",
6        "command": "node .claude/hooks/pre-edit-lint.js $FILE"
7      }
8    ],
9    "PostToolUse": [
10      {
11        "matcher": "Edit",
12        "command": "npx prettier --write $FILE"
13      },
14      {
15        "matcher": "Bash",
16        "command": "node .claude/hooks/post-bash-audit.js"
17      }
18    ],
19    "Notification": [
20      {
21        "matcher": ".*",
22        "command": "node .claude/hooks/slack-notify.js"
23      }
24    ]
25  }
26}

1// Hook PreToolUse para Bash cuando el comando contiene "git commit"
2const { execSync } = require('child_process');
3 
4const command = process.env.CLAUDE_TOOL_INPUT;
5 
6if (command && command.includes('git commit')) {
7  try {
8    console.log('[Hook] Ejecutando lint antes del commit...');
9    execSync('npx eslint . --ext .ts,.tsx,.js,.jsx --quiet', {
10      stdio: 'inherit'
11    });
12    console.log('[Hook] Lint OK - procediendo con commit');
13    process.exit(0); // Permitir el commit
14  } catch (error) {
15    console.error('[Hook] Lint FALLIDO - commit bloqueado');
16    console.error('Corrige los errores de lint antes de commitear.');
17    process.exit(1); // Bloquear el commit
18  }
19}
20 
21process.exit(0); // Si no es un commit, no interferir

1{
2  "hooks": {
3    "PostToolUse": [
4      {
5        "matcher": "Edit",
6        "command": "npx prettier --write $FILE 2>/dev/null || true"
7      }
8    ]
9  }
10}

1const https = require('https');
2 
3const SLACK_WEBHOOK = process.env.SLACK_WEBHOOK_URL;
4const message = process.env.CLAUDE_NOTIFICATION_MESSAGE || 'Tarea completada';
5 
6if (SLACK_WEBHOOK) {
7  const payload = JSON.stringify({
8    text: `[Claude Code] ${message}`,
9    channel: '#dev-notifications'
10  });
11 
12  const url = new URL(SLACK_WEBHOOK);
13  const options = {
14    hostname: url.hostname,
15    path: url.pathname,
16    method: 'POST',
17    headers: { 'Content-Type': 'application/json' }
18  };
19 
20  const req = https.request(options);
21  req.write(payload);
22  req.end();
23}

1# CLAUDE.md
2 
3## Stack del proyecto
4- Framework: Next.js 15 con App Router
5- Lenguaje: TypeScript (strict mode)
6- Estilos: Tailwind CSS
7- Tests: Vitest + Testing Library
8- Base de datos: PostgreSQL con Prisma ORM
9- CI/CD: GitHub Actions
10 
11## Comandos de desarrollo
12- `pnpm dev` - Servidor de desarrollo (puerto 3000)
13- `pnpm build` - Build de producción
14- `pnpm test` - Ejecutar tests
15- `pnpm lint` - Linting
16- `pnpm db:migrate` - Aplicar migraciones
17 
18## Convenciones de código
19- Commits: Conventional Commits en español
20- Funciones: máximo 30 líneas
21- Archivos: máximo 300 líneas
22- Imports: usar alias @/ (nunca rutas relativas largas)
23- Types: prohibido usar 'any' sin justificación
24 
25## Reglas de negocio
26- Los precios siempre incluyen IVA en España (21%)
27- Los emails se envían solo en horario laboral (9-18h CET)
28- Los datos de usuario se eliminan a los 30 días de baja
29 
30## Archivos que NUNCA deben modificarse
31- .env.production
32- prisma/migrations/ (solo crear nuevas, nunca editar existentes)
33- public/robots.txt
34 
35## Patrones del proyecto
36- Server Components por defecto, Client Components solo para interactividad
37- Data fetching en Server Components, nunca en Client Components
38- Error boundaries en cada layout
39- Loading states en cada página

1templates/
2  nextjs-fullstack/
3    .claude/
4      skills/
5        commit.md
6        test.md
7        review-pr.md
8        deploy-check.md
9      settings.json
10      hooks/
11        pre-commit-lint.js
12        post-edit-format.js
13    CLAUDE.md
14    README.md   # Instrucciones de uso del template

1# Opcion 1: Copiar directamente
2cp -r templates/nextjs-fullstack/.claude mi-nuevo-proyecto/.claude
3cp templates/nextjs-fullstack/CLAUDE.md mi-nuevo-proyecto/CLAUDE.md
4 
5# Opcion 2: Usar un script de setup
6#!/bin/bash
7# setup-claude-code.sh
8TEMPLATE=${1:-"nextjs-fullstack"}
9DEST=${2:-"."}
10 
11echo "Aplicando template '$TEMPLATE' en '$DEST'..."
12cp -r "templates/$TEMPLATE/.claude" "$DEST/.claude"
13cp "templates/$TEMPLATE/CLAUDE.md" "$DEST/CLAUDE.md"
14echo "Template aplicado. Skills disponibles:"
15ls "$DEST/.claude/skills/"

1# Desde la raíz de tu proyecto
2mkdir -p .claude/skills

1# Ejemplo: skill para crear componentes React
2touch .claude/skills/component.md

1---
2name: component
3description: Crea un componente React con TypeScript, tests y estilos
4---
5 
6Crea un nuevo componente React siguiendo la estructura del proyecto.
7 
8Parámetro: nombre del componente (PascalCase)
9 
10Genera estos archivos:
111. components/{nombre}/{nombre}.tsx - Componente con TypeScript
122. components/{nombre}/{nombre}.test.tsx - Tests con Vitest
133. components/{nombre}/index.ts - Re-export
14 
15El componente debe:
16- Usar TypeScript con interfaz de Props explícita
17- Ser Server Component por defecto (sin 'use client')
18- Usar Tailwind CSS para estilos
19- Incluir prop className para personalización
20- Tener al menos 3 tests: render, props, accesibilidad
21 
22Ejemplo de estructura:
23interface {Nombre}Props {
24  className?: string;
25  children?: React.ReactNode;
26}
27 
28export function {Nombre}({ className, children }: {Nombre}Props) {
29  return (
30    <div className={cn("", className)}>
31      {children}
32    </div>
33  );
34}

1# Abre Claude Code en tu proyecto
2claude
3 
4# Invoca el skill
5> /component UserCard
6 
7# Claude Code generará los 3 archivos siguiendo las instrucciones del skill