¿Qué es un Skill en Claude Code?

Un skill es un archivo Markdown con instrucciones estructuradas que define cómo realizar una tarea específica. No es código ejecutable ni un plugin: es conocimiento de dominio codificado de forma que Claude puede leerlo, internalizarlo y aplicarlo durante una sesión de trabajo.

Cuando invocas un skill (ya sea mediante /nombre-del-skill o cuando el agente lo activa automáticamente), Claude lee el SKILL.md correspondiente y lo incorpora a su contexto activo. A partir de ese momento, sigue los pasos, criterios, y patrones definidos en ese archivo como si fueran instrucciones explícitas del usuario.

Mecanismo de Invocación

El ciclo completo de invocación funciona así:

sequenceDiagram
    participant U as Usuario
    participant CC as Claude Code
    participant FS as Filesystem
    participant LLM as LLM (Claude)

    U->>CC: /tdd-workflow
    CC->>FS: Busca ~/.claude/skills/tdd-workflow/SKILL.md
    FS-->>CC: Contenido del SKILL.md
    CC->>LLM: Inyecta contenido en contexto del sistema
    LLM-->>U: Aplica workflow durante toda la sesión

Claude Code busca el archivo SKILL.md en rutas predefinidas, lo inyecta en el contexto del sistema, y desde ese momento el LLM tiene acceso a todas las instrucciones del skill como si formaran parte de sus instrucciones base. El skill permanece activo durante toda la sesión a menos que se invoque otro que lo reemplace.

Diferencia Entre Skill y Agente

Un agente es una instancia de Claude con un rol específico que puede tomar decisiones, lanzar herramientas, y completar tareas de forma autónoma. Un skill es un conjunto de instrucciones que un agente (o el mismo Claude Code) sigue para realizar su trabajo.

graph LR
    S[Skill] -->|instruye a| A[Agente]
    A -->|ejecuta con| T[Herramientas]
    A -->|sigue| W[Workflow del Skill]
    S -->|define| C[Criterios de Calidad]
    S -->|establece| P[Pasos y Patrones]

La distinción práctica: cuando ves un archivo SKILL.md, es un skill. Cuando ves un agent.md o un AGENT.md, es la definición de un agente con su propia identidad, rol y permisos. Un agente puede usar múltiples skills; un skill no tiene autonomía por sí mismo.

Cómo Claude Lee y Aplica un Skill

Cuando se carga un skill, Claude no solo “recuerda” las instrucciones: las trata como restricciones activas durante la sesión. Si el skill de TDD dice “escribe los tests primero”, Claude rechazará (o advertirá) si el usuario le pide implementar código sin tests. Si el skill de verification-loop define 6 fases de verificación, Claude las ejecutará en orden al finalizar cada cambio significativo.

Los skills bien diseñados incluyen:

• Triggers explícitos: cuándo debe activarse el workflow
• Decision trees: qué hacer ante diferentes situaciones
• Output format: cómo reportar resultados
• Exit criteria: cuándo considerar que el workflow está completo

---

Anatomía Completa de un SKILL.md

Todo archivo SKILL.md sigue una estructura que combina un frontmatter YAML con secciones Markdown semiestructuradas. Veamos la anatomía completa:

Frontmatter

---
name: nombre-del-skill
description: >
  Descripción de una o dos oraciones. Esta descripción es crítica porque
  Claude la usa para determinar cuándo activar el skill automáticamente.
origin: ECC
version: "1.0"
tags: ["testing", "quality"]
---

Campos del frontmatter:

• name: Identificador único, kebab-case. Debe coincidir con el nombre del directorio padre.
• description: La descripción más importante del skill. Claude la usa como criterio de matching cuando decide si debe activar el skill automáticamente basándose en el contexto de la tarea.
• origin: Indica quién creó el skill. ECC para skills de Everything Claude Code, o el nombre de tu organización para skills propios.
• version: Control de versiones semántico opcional pero recomendado.
• tags: Categorías para búsqueda y filtrado.

Secciones Obligatorias

1. Título y Descripción

# /nombre-del-skill — Título Descriptivo

Párrafo introductorio que explica el propósito del skill en 2-3 oraciones.
Debe responder: ¿qué problema resuelve? ¿cuándo usarlo?

2. When to Use / Trigger

## Trigger
Use this skill when:
- [condición 1]
- [condición 2]
- [condición 3]

Esta sección es fundamental para los skills que se activan automáticamente. Claude la analiza para determinar si el contexto actual coincide con los triggers definidos.

3. How It Works / Steps

## Steps
1. [Paso 1 con descripción]
2. [Paso 2 con descripción]
3. [Paso 3 con descripción]

Los pasos deben ser atómicos, verificables, y ordenados lógicamente. Cada paso debe tener un criterio claro de completitud.

4. Output Format

## Output
Report format:
- ✅ [check] — [estado]
- ❌ [check] — [problema encontrado]

Summary: [una línea describiendo el resultado]

Definir el formato de output es crítico para que los resultados sean consistentes entre sesiones.

Secciones Opcionales

Decision Matrix: Para skills que deben tomar decisiones entre múltiples opciones:

## Decision Matrix
| Condición | Acción |
|-----------|--------|
| Caso A    | Hacer X |
| Caso B    | Hacer Y |
| Default   | Hacer Z |

Examples: Casos de uso concretos que ilustran el skill en acción:

## Examples
### Ejemplo 1: Feature nueva con dependencias externas
Contexto: El usuario quiere agregar autenticación OAuth.
Aplicación del skill: Primero buscar librerías OAuth existentes...

Anti-patterns: Lo que el skill explícitamente prohíbe:

## Anti-patterns
- NO implementar antes de buscar soluciones existentes
- NO asumir que una librería popular = librería adecuada para el proyecto

Configuration: Variables configurables del skill:

## Configuration
- `MIN_COVERAGE`: Cobertura mínima requerida (default: 80%)
- `TIMEOUT`: Tiempo máximo por fase (default: 5 minutos)

Anti-Patrones en el Diseño de SKILL.md

Los siguientes errores degradan la efectividad de un skill:

• Instrucciones ambiguas: “Asegúrate de que el código sea bueno” — ¿qué significa “bueno”? Define criterios cuantificables.
• Steps demasiado largos: Un step que incluye 5 sub-acciones debe dividirse en steps separados.
• Sin exit criteria: Si el skill no define cuándo termina, Claude puede ejecutarlo indefinidamente o cortarlo prematuramente.
• Contradicciones internas: Si el step 2 dice “usa TypeScript estricto” y el step 4 dice “usa any si es necesario”, Claude no sabe qué priorizar.
• Sin formato de output: Los resultados variarán entre sesiones y serán difíciles de parsear por otros skills o agentes.

---

Tipos de Skills: Agent Skill vs User-Invocable Skill

User-Invocable Skills

Son skills que el usuario activa explícitamente con un comando slash. El usuario escribe /tdd-workflow y Claude carga e internaliza ese skill. Características:

• El usuario controla cuándo activarlos
• Típicamente modifican el comportamiento para toda la sesión
• Son perfectos para workflows complejos que requieren múltiples pasos del usuario
• Ejemplos: tdd-workflow, verification-loop, search-first

Agent Skills

Son skills diseñados para ser invocados por el agente automáticamente cuando detecta el contexto apropiado. El agente lee las descripciones de todos los skills disponibles y decide cuál aplicar. Características:

• El agente decide cuándo activarlos basándose en los triggers
• Son más granulares y enfocados en tareas específicas
• Ideales para verificaciones, análisis, y transformaciones automatizadas
• Ejemplos: security-scan, coding-standards, benchmark

graph TD
    T[Tarea del Usuario] --> D{¿Activa cuál skill?}
    D -->|Usuario escribe /tdd-workflow| UI[User-Invocable Skill]
    D -->|Agente detecta "nuevo feature"| AS[Agent Skill automático]
    UI --> WF[Workflow multi-paso interactivo]
    AS --> AA[Acción automática del agente]

Skills Híbridos

Algunos skills funcionan en ambos modos. verification-loop puede ser invocado por el usuario al terminar una sesión de trabajo, pero también puede ser disparado automáticamente por el agente antes de un commit o deployment. El skill define ambos casos en su sección de triggers.

---

El SKILL.md de search-first Analizado

El skill search-first es uno de los más fundamentales de ECC porque resuelve el problema más común en desarrollo de software: reimplementar lo que ya existe.

Frontmatter

---
name: search-first
description: Research-before-coding workflow. Search for existing tools, libraries,
  and patterns before writing custom code. Invokes the researcher agent.
origin: ECC
---

La description tiene dos oraciones estratégicas. La primera define el workflow. La segunda menciona explícitamente que “invoca el researcher agent” — esto es intencional: Claude sabe que debe activar su capacidad de búsqueda antes de codear.

Sección Trigger

## Trigger
Use this skill when:
- Starting a new feature that likely has existing solutions
- Adding a dependency or integration
- Before creating a new utility, helper, or abstraction

Los tres triggers cubren los momentos críticos donde los developers típicamente reinventan la rueda:

1. Features nuevas: El 80% de las features tienen soluciones parciales o completas en npm/PyPI/crates.io/pkg.go.dev
2. Dependencias: Antes de elegir una librería, ¿hay alternativas más ligeras o mejor mantenidas?
3. Utilities y helpers: Las funciones de “utilidad” suelen existir en librerías como lodash, date-fns, o la librería estándar del lenguaje

Decision Matrix

## Decision Matrix
| Signal | Action |
|--------|--------|
| Exact match, well-maintained, MIT/Apache | Adopt |
| Partial match, good foundation | Extend |
| Multiple weak matches | Compose |
| Nothing suitable found | Build |

Esta matriz es el corazón del skill. Cuatro acciones cubren todos los casos posibles:

• Adopt: Si existe una librería que hace exactamente lo que necesitas, bajo licencia compatible, con mantenimiento activo — úsala sin modificar.
• Extend: Si existe una base sólida pero le falta funcionalidad específica, extiende en lugar de reimplementar.
• Compose: Si múltiples librerías pequeñas juntas resuelven el problema, compónlas en lugar de construir una solución monolítica.
• Build: Solo cuando no existe nada viable. Y cuando se llega a este punto, el skill exige documentar POR QUÉ se construyó desde cero.

Filosofía del Skill

search-first codifica un principio de ingeniería: el código que no existe no tiene bugs, no necesita mantenimiento, y no aumenta la deuda técnica. Cada línea de código personalizado es una carga futura. La búsqueda sistemática antes de implementar reduce esta carga significativamente.

El skill también protege contra el bias cognitivo del developer de preferir el código propio. Al tener un proceso estructurado de evaluación, la decisión de “construir vs. comprar” se vuelve objetiva.

---

El SKILL.md de verification-loop Analizado

verification-loop es el skill de quality gate de ECC. Su propósito es asegurar que ningún cambio llegue a producción sin pasar por un conjunto completo de verificaciones.

Las Seis Fases

## Verification Phases:
Phase 1: Build Verification - npm run build
Phase 2: Type Check - npx tsc --noEmit
Phase 3: Lint Check - npm run lint
Phase 4: Test Suite - npm run test --coverage
Phase 5: Security Scan - grep for secrets
Phase 6: Diff Review - git diff --stat

Cada fase tiene una razón específica de ser en este orden:

Phase 1 — Build: Si el código no compila, nada más importa. Esta fase falla rápido y evita ejecutar las fases costosas (tests) con código roto.

Phase 2 — Type Check: Los errores de tipos suelen aparecer solo en --noEmit porque el build puede hacer transpilación más laxa. Esta fase captura type errors que el build ignora.

Phase 3 — Lint: Estilo, patrones problemáticos, y reglas de equipo. Se ejecuta después de types porque los errores de tipos generan falsos positivos en algunos linters.

Phase 4 — Test Suite con Coverage: La suite completa con reporte de cobertura. Al ir al final de las fases de código, solo se ejecuta si las fases anteriores pasaron, ahorrando tiempo.

Phase 5 — Security Scan: Búsqueda de secrets en el diff. Detecta API keys, passwords, y tokens que pudieron colarse en el código. Se hace post-tests porque el diff final es más pequeño y preciso.

Phase 6 — Diff Review: Revisión visual del resumen de cambios. Es la “segunda mirada” que detecta cambios inesperados o archivos modificados accidentalmente.

Output Format

Output: VERIFICATION REPORT con Build/Types/Lint/Tests/Security/Diff

El report usa un formato de semáforo: cada fase reporta ✅ (pasó), ⚠️ (warnings), o ❌ (falló con detalles). El report final incluye un resumen ejecutivo de una línea.

Integración con Hooks

verification-loop está diseñado para integrarse con los hooks de Claude Code. Se puede configurar para ejecutarse automáticamente en pre-commit o pre-push, convirtiendo el skill en una barrera de calidad automatizada que ningún commit puede eludir.

---

El SKILL.md de tdd-workflow Analizado

tdd-workflow implementa Test-Driven Development con una variante que va más allá del ciclo Red-Green-Refactor clásico: incluye la fase de definición de User Journeys antes de escribir cualquier test.

El Ciclo Completo

## TDD Workflow Steps
Step 1: Write User Journeys
Step 2: Generate Test Cases
Step 3: Run Tests (should FAIL)
Step 4: Implement Code (minimal)
Step 5: Run Tests Again (should PASS)
Step 6: Refactor
Step 7: Verify Coverage 80%+

Step 1 — User Journeys: Antes de pensar en tests técnicos, el skill exige describir el comportamiento desde la perspectiva del usuario. “Como usuario, cuando hago X, espero ver Y.” Este paso fuerza claridad de requisitos antes de cualquier código.

Step 2 — Test Cases: A partir de los User Journeys se generan casos de test concretos. Un Journey puede generar múltiples test cases (happy path, edge cases, error cases).

Step 3 — Run Tests (RED): Los tests deben FALLAR. Si un test pasa sin haber implementado el código, significa que el test está mal escrito o que la funcionalidad ya existe.

Step 4 — Implement Code (minimal): La implementación más simple posible que haga pasar los tests. Nada más, nada menos. El skill explícitamente prohíbe over-engineering en esta fase.

Step 5 — Run Tests Again (GREEN): Todos los tests deben pasar. Si alguno falla, se regresa al paso 4.

Step 6 — Refactor: Con los tests en verde como red de seguridad, se refactoriza el código para mejorar legibilidad, performance, y estructura. Los tests verifican que el refactor no rompe nada.

Step 7 — Coverage 80%+: El skill define 80% como el umbral mínimo de cobertura. Por debajo de ese umbral, el workflow no está completo.

Mocking Patterns Incluidos

El skill incluye templates de mocks para los servicios más comunes:

// Supabase mock
vi.mock('@supabase/supabase-js', () => ({
  createClient: vi.fn(() => ({
    from: vi.fn(() => ({
      select: vi.fn().mockResolvedValue({ data: [], error: null })
    }))
  }))
}))

// Redis mock
vi.mock('ioredis', () => {
  return vi.fn().mockImplementation(() => ({
    get: vi.fn().mockResolvedValue(null),
    set: vi.fn().mockResolvedValue('OK'),
    del: vi.fn().mockResolvedValue(1)
  }))
})

// OpenAI mock
vi.mock('openai', () => ({
  default: vi.fn().mockImplementation(() => ({
    chat: {
      completions: {
        create: vi.fn().mockResolvedValue({
          choices: [{ message: { content: 'mocked response' } }]
        })
      }
    }
  }))
}))

Estos mocks eliminan la fricción de configurar las integraciones en tests, permitiendo que el developer se enfoque en la lógica de negocio.

Test File Organization

El skill define una estructura de organización de archivos de test:

src/
  features/
    auth/
      auth.service.ts
      auth.service.unit.test.ts      # Unit tests
      auth.service.integration.test.ts  # Integration tests
tests/
  e2e/
    auth.e2e.test.ts                 # End-to-end tests

Esta separación por tipo de test permite ejecutar solo los tests relevantes durante el desarrollo y todos los tests en CI/CD.

---

Skills por Categoría: Core

Los skills core son los que deberían estar activos en prácticamente cualquier proyecto. Representan las prácticas de ingeniería más fundamentales.

search-first

Workflow de investigación pre-implementación. Antes de escribir cualquier código, obliga a buscar soluciones existentes usando la Decision Matrix (Adopt/Extend/Compose/Build). Reduce la deuda técnica al evitar reimplementar librerías existentes. Especialmente valioso en ecosistemas ricos como npm o PyPI donde es fácil perderse las mejores opciones disponibles.

tdd-workflow

Implementación completa de Test-Driven Development con 7 pasos, desde User Journeys hasta verificación de cobertura 80%+. Incluye templates de mocks para Supabase, Redis, y OpenAI. Define la organización de archivos de test por tipo (unit, integration, e2e). Cambia el paradigma de “escribir tests para verificar código existente” a “escribir tests como especificación ejecutable del comportamiento deseado”.

verification-loop

Sistema de verificación de 6 fases: Build → TypeCheck → Lint → Tests → SecurityScan → DiffReview. Genera un VERIFICATION REPORT estandarizado con status por fase. Diseñado para integrarse con pre-commit hooks. Asegura que cada cambio pase por el mismo conjunto de verificaciones independientemente del desarrollador que lo haga.

coding-standards

Define los estándares de código aplicables a cualquier lenguaje. Incluye convenciones de naming, estructura de funciones (máximo 20 líneas por función), manejo de errores explícito, y principios como “una función, una responsabilidad”. Es el skill más genérico y sirve como base para todos los skills de lenguaje específicos.

strategic-compact

Skill de gestión de contexto. Cuando una sesión de Claude Code se vuelve larga y el contexto se satura, este skill define una estrategia para compactar el contexto de forma inteligente: preservar decisiones clave, descartar scaffolding temporal, y mantener el estado crítico del proyecto. Previene el problema de “context drift” donde Claude empieza a olvidar decisiones tomadas al inicio de la sesión.

eval-harness

Sistema de evaluación de calidad de outputs. Define cómo construir un harness de evaluación para medir la calidad de respuestas de LLMs en tareas específicas. Incluye criterios de evaluación, métricas, y formato de reporte. Fundamental para proyectos que usan Claude como parte de un pipeline de producción y necesitan monitorear la calidad de outputs.

continuous-learning

Skill para capturar y sistematizar aprendizajes durante el desarrollo. Define un formato para documentar “qué funcionó”, “qué no funcionó”, y “por qué” en cada iteración. Genera una base de conocimiento que mejora futuras sesiones de trabajo. Útil en proyectos donde el equipo necesita construir expertise colectivo sobre tecnologías nuevas.

continuous-learning-v2

Versión mejorada de continuous-learning con integración de RAG (Retrieval-Augmented Generation). Almacena los aprendizajes en un formato vectorizable para búsqueda semántica. Permite que futuras sesiones recuperen conocimiento relevante basado en contexto, no solo por keywords. Requiere configuración adicional de un vector store.

iterative-retrieval

Workflow para tareas que requieren múltiples ciclos de búsqueda y refinamiento. Cuando una query inicial retorna resultados insuficientes, el skill define cómo reformular la query, combinar resultados parciales, y converger hacia una respuesta completa. Fundamental para research tasks donde la información está distribuida en múltiples fuentes.

cost-aware-llm-pipeline

Define patrones para optimizar el costo de llamadas a LLMs en producción. Incluye estrategias de caching, routing de queries a modelos de menor costo según complejidad, batching de requests, y monitoreo de token usage. Para proyectos con alto volumen de llamadas a la API de Claude u otros LLMs, este skill puede reducir costos entre 40-80%.

regex-vs-llm-structured-text

Decision framework para elegir entre regex y LLM para tareas de extracción de texto estructurado. Define criterios concretos: si el patrón es perfectamente predecible y el performance importa → regex. Si el texto tiene variaciones naturales, requiere comprensión semántica, o el mantenimiento del pattern sería costoso → LLM. Incluye benchmarks de latencia y costo para ayudar a la decisión.

---

Skills Frontend

Los skills de frontend cubren desde patrones de componentes hasta testing end-to-end y diseño visual.

frontend-patterns

Patrones específicos para desarrollo React y Next.js. Cubre: composición de componentes, custom hooks para lógica compartida, Server Components vs Client Components en Next.js 15+, manejo de estado con Zustand y Jotai, data fetching patterns con SWR y TanStack Query, y optimización de renders con memo y useCallback. Se invoca al iniciar trabajo en un proyecto React/Next.js para establecer las convenciones del proyecto.

Cuándo invocar: Al crear componentes nuevos, al agregar state management, al decidir entre Server/Client components.

frontend-slides

Genera presentaciones HTML estáticas sin dependencias externas. Las slides usan CSS puro con navegación por teclado, son deployables como archivos estáticos, y tienen un diseño limpio y profesional. Ideal para presentaciones técnicas donde no quieres depender de PowerPoint o herramientas de slides externas. El output es un único archivo HTML autocontenido.

Cuándo invocar: Cuando necesitas una presentación técnica rápida que puedas versionar en git y deployar como static asset.

e2e-testing

Patrones de testing end-to-end con Playwright siguiendo el Page Object Model (POM). Define la estructura de archivos de test, fixtures compartidos, selectores semánticos (preferir data-testid sobre CSS selectors), y estrategias para tests de autenticación. Incluye configuración de CI/CD para tests paralelos y manejo de flaky tests.

Cuándo invocar: Al agregar tests E2E, al refactorizar tests existentes, al configurar Playwright en un proyecto nuevo.

browser-qa

Skill de QA manual asistida por browser automation. Define un checklist de verificación visual y funcional que Claude ejecuta usando herramientas de browser. Cubre: renderizado responsive, accesibilidad básica (ARIA, contraste), funcionalidad de formularios, y flujos críticos de usuario. Genera un reporte de QA con screenshots de issues encontrados.

Cuándo invocar: Antes de releases, después de cambios de diseño significativos, para auditorías de accesibilidad rápidas.

design-system

Patrones para construir y mantener un design system en código. Define tokens de diseño (colores, tipografía, spacing), la arquitectura de componentes base (Button, Input, Modal), documentación de componentes con Storybook, y versionado del design system. Asegura consistencia visual entre todas las partes de la aplicación.

Cuándo invocar: Al crear componentes de UI nuevos, al extraer un componente reutilizable, al establecer tokens de diseño.

---

Skills Backend

Los skills backend cubren desde patrones de API hasta deployment y gestión de bases de datos.

backend-patterns

Patrones generales de desarrollo backend aplicables a cualquier framework. Incluye: estructura de capas (Controller → Service → Repository), manejo de errores con Result types, validación de inputs en el borde de la aplicación, logging estructurado, y health checks. Establece las convenciones arquitectónicas del proyecto backend.

Ejemplo: Al crear un nuevo endpoint REST, el skill define que la lógica de negocio va en el Service, la validación en el Controller, y el acceso a datos en el Repository.

api-design

Principios y patrones para diseño de APIs REST y GraphQL. Cubre: naming conventions para endpoints, versionado de API, paginación estandarizada, manejo de errores HTTP, documentación OpenAPI/Swagger, y rate limiting. Define el contrato de la API antes de implementarla, asegurando que sea intuitiva para los consumers.

Ejemplo de endpoint bien diseñado según el skill:

GET  /api/v1/users/{id}              # Obtener usuario
POST /api/v1/users                   # Crear usuario
PUT  /api/v1/users/{id}              # Reemplazar usuario completo
PATCH /api/v1/users/{id}             # Actualizar campos específicos
DELETE /api/v1/users/{id}            # Eliminar usuario
GET  /api/v1/users/{id}/orders       # Recurso anidado

deployment-patterns

Estrategias de deployment para aplicaciones en producción. Cubre: blue-green deployments, canary releases, feature flags, rollback procedures, y health check endpoints. Define los criterios para decidir qué estrategia usar según el nivel de riesgo del cambio y los SLAs del servicio.

docker-patterns

Patrones para Dockerización eficiente de aplicaciones. Incluye: multi-stage builds para imágenes pequeñas, optimización del layer caching en Dockerfile, configuración de docker-compose para desarrollo local, manejo de secrets en containers, y configuración de healthchecks. El skill especifica que las imágenes de producción no deben incluir herramientas de desarrollo.

Ejemplo de multi-stage build optimizado:

# Build stage
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production

# Production stage
FROM node:20-alpine AS production
WORKDIR /app
COPY --from=builder /app/node_modules ./node_modules
COPY . .
EXPOSE 3000
USER node
CMD ["node", "dist/server.js"]

database-migrations

Workflow para gestión segura de migraciones de base de datos. Define: naming conventions para archivos de migración, estrategia de up/down migrations, testing de migraciones en ambiente de staging antes de producción, y manejo de migraciones que requieren downtime. Especifica que las migraciones deben ser idempotentes cuando sea posible.

postgres-patterns

Patrones específicos de PostgreSQL para desarrollo de aplicaciones. Cubre: indexación correcta para queries frecuentes, uso de JSONB vs columnas separadas, particionamiento de tablas grandes, configuración de connection pooling con PgBouncer, y análisis de query performance con EXPLAIN ANALYZE. Incluye patrones de Row-Level Security (RLS) para multi-tenancy.

mcp-server-patterns

Patrones para construir MCP (Model Context Protocol) servers. Define la estructura de un MCP server, cómo exponer tools, resources, y prompts, manejo de autenticación, y testing de MCP servers. Para proyectos que necesitan extender las capacidades de Claude con herramientas custom.

---

Skills de Seguridad

Los skills de seguridad son auditores automáticos que detectan vulnerabilidades comunes antes de que lleguen a producción.

security-review

Checklist completo de revisión de seguridad para cualquier tipo de aplicación. Organizado en categorías:

• Authentication: ¿Contraseñas hasheadas con bcrypt/argon2? ¿JWT con expiración? ¿Rate limiting en login?
• Authorization: ¿Verificación de permisos en cada endpoint? ¿Principio de menor privilegio?
• Input Validation: ¿Sanitización de inputs? ¿Protección contra SQL injection? ¿Validación de file uploads?
• Data Exposure: ¿Se filtran campos sensibles en responses? ¿HTTPS obligatorio?
• Dependencies: ¿Dependencias con vulnerabilidades conocidas? ¿npm audit limpio?

Genera un reporte por severidad: Critical, High, Medium, Low.

security-scan

Versión automatizada y más rápida de security-review. Enfocada en detección de secrets hardcodeados, patrones de SQL injection, y configuraciones inseguras comunes. Se puede ejecutar como pre-commit hook. Busca patterns como:

API_KEY = "sk-..."
password = "hardcoded123"
"SELECT * FROM " + userInput
eval(userControlledInput)

Diseñado para ser el primer filtro de seguridad, rápido y con pocos falsos positivos.

django-security

Checklist de seguridad específico para proyectos Django. Verifica: DEBUG=False en producción, SECRET_KEY no expuesto, configuración de CORS correcta, CSRF protection habilitado, uso de django-axes para rate limiting, validación de file uploads, y configuración de headers de seguridad (HSTS, X-Frame-Options, CSP). También revisa el uso correcto del ORM para prevenir injection attacks.

Vulnerabilidades que detecta:

• Django Admin accesible desde internet sin restricción de IP
• ALLOWED_HOSTS = ['*'] en producción
• Uso de raw() queries sin parámetros escapeados
• Media files servidos directamente sin autenticación
• Cookies de sesión sin Secure flag

laravel-security

Equivalente de django-security para el ecosistema PHP/Laravel. Verifica: configuración de APP_ENV y APP_DEBUG, protección CSRF en formularios, validación de requests con Form Request classes, manejo seguro de file uploads, configuración de rate limiting en rutas de autenticación, y uso correcto del Query Builder vs Eloquent para prevenir SQL injection.

Vulnerabilidades que detecta:

• Uso de DB::statement() con interpolación de strings
• Rutas sin middleware de autenticación
• Validación de uploads solo por extensión (bypass con MIME spoofing)
• Tokens de API almacenados en texto plano

springboot-security

Auditoría de seguridad para aplicaciones Spring Boot. Verifica: configuración de Spring Security, CORS policy, JWT validation correcta, protección contra CSRF en endpoints stateful, manejo de excepciones que no exponen stack traces, y configuración de actuator endpoints en producción.

Vulnerabilidades que detecta:

• Actuator endpoints expuestos sin autenticación (/actuator/env, /actuator/heapdump)
• Uso de @CrossOrigin(origins = "*") sin restricciones
• Deserialización de objetos Java desde inputs externos
• Logging de datos sensibles (passwords, tokens) en INFO/DEBUG

---

Skills TypeScript / JavaScript

coding-standards

Estándares de código TypeScript/JavaScript para proyectos modernos. Incluye: configuración de tsconfig.json con strict: true, convenciones de naming (PascalCase para types/interfaces, camelCase para variables/funciones), manejo de async/await consistente, error handling con tipos explícitos, y prohibición de any. Define el límite de complejidad ciclomática por función (máximo 10).

bun-runtime

Patrones para aprovechar Bun como runtime y package manager. Cubre: diferencias de API entre Bun y Node.js, uso de Bun.serve() para HTTP servers, Bun.file() para file I/O optimizado, sqlite integrado con bun:sqlite, y testing nativo con bun:test. Incluye benchmarks comparativos para motivar decisiones de migración.

---

Skills Python

python-patterns

Patrones idiomáticos de Python para proyectos modernos. Cubre: type hints completos con mypy, dataclasses y Pydantic para modelos de datos, context managers para recursos, generators para procesamiento eficiente de datos, y async/await con asyncio. Define convenciones de proyecto: estructura de módulos, manejo de configuración con python-dotenv, y logging estructurado con structlog.

python-testing

Framework completo de testing para Python. Define la estructura de tests con pytest, uso de fixtures para setup/teardown, mocking con unittest.mock y pytest-mock, parametrización de tests con @pytest.mark.parametrize, y cobertura con pytest-cov. Incluye patrones para testear código async con pytest-asyncio y para testear APIs FastAPI con TestClient.

# Ejemplo de test pattern del skill
@pytest.mark.parametrize("input,expected", [
    ("hello", "HELLO"),
    ("", ""),
    ("123", "123"),
])
def test_uppercase(input: str, expected: str) -> None:
    assert to_uppercase(input) == expected

django-patterns

Arquitectura de proyectos Django con mejores prácticas. Cubre: estructura de apps, uso de select_related y prefetch_related para N+1 queries, signals con moderación (preferir services explícitos), class-based views vs function-based views, configuración de settings por ambiente con django-environ, y uso de django-q para tareas asíncronas.

django-tdd

TDD adaptado al contexto de Django. Define cómo escribir tests de modelos, views, forms, y management commands. Incluye patrones para TestCase vs TransactionTestCase, uso de factory_boy para fixtures, y testing de tareas de Celery. El skill define que cada view debe tener tests para: status codes, template context, redirects, y permisos.

django-verification

Checklist de verificación post-implementación para proyectos Django. Verifica: migraciones pendientes (manage.py migrate --check), checks del sistema (manage.py check --deploy), collectstatic configurado correctamente, y que no hay imports circulares. Complementa verification-loop con checks específicos del ecosistema Django.

pytorch-patterns

Patrones de desarrollo con PyTorch para proyectos de ML/DL. Cubre: estructura de Dataset y DataLoader, training loop con validation, checkpointing de modelos, uso de torch.no_grad() en inference, reproducibilidad con seeds, y profiling de performance. Define cómo organizar experimentos con MLflow o WandB para tracking.

---

Skills Go

golang-patterns

Patrones idiomáticos de Go para proyectos de producción. Cubre: manejo de errores con error wrapping (fmt.Errorf("context: %w", err)), interfaces pequeñas y enfocadas, goroutines con context para cancelación, uso de channels vs mutex según el caso, y estructura de proyectos con cmd/, internal/, pkg/. Define cómo organizar la inyección de dependencias sin frameworks.

// Pattern de manejo de errores del skill
func processUser(ctx context.Context, id string) (*User, error) {
    user, err := repo.FindByID(ctx, id)
    if err != nil {
        return nil, fmt.Errorf("processUser: finding user %s: %w", id, err)
    }
    // ...
    return user, nil
}

golang-testing

Testing en Go con las mejores prácticas del ecosistema. Cubre: table-driven tests, uso de testify para assertions expresivas, mocking con interfaces (no magic mocking), benchmarks con testing.B, y testing de HTTP handlers con httptest. Define la convención de naming de test helpers y la estructura de test files.

// Table-driven test pattern del skill
func TestCalculateTotal(t *testing.T) {
    tests := []struct {
        name     string
        items    []Item
        expected float64
    }{
        {"empty cart", []Item{}, 0.0},
        {"single item", []Item{{Price: 10.0, Qty: 2}}, 20.0},
        {"with discount", []Item{{Price: 100.0, Qty: 1, Discount: 0.1}}, 90.0},
    }

    for _, tt := range tests {
        t.Run(tt.name, func(t *testing.T) {
            assert.Equal(t, tt.expected, CalculateTotal(tt.items))
        })
    }
}

---

Skills Java / Kotlin

java-coding-standards

Estándares de código Java para proyectos enterprise modernos. Cubre: Java 21+ features (Records, Pattern Matching, Sealed Classes), convenciones de naming, Javadoc obligatorio para APIs públicas, uso de Optional para valores nullable, y streams API vs loops tradicionales. Define límites de complejidad y organización de packages.

jpa-patterns

Patrones seguros y eficientes con JPA/Hibernate. Aborda el problema clásico de N+1 queries con soluciones concretas: @EntityGraph, JPQL con JOIN FETCH, y projections para consultas de solo lectura. Define cuándo usar @Transactional y con qué nivel de aislamiento. Incluye patrones para soft deletes con @SQLDelete y @Where.

// Pattern de EntityGraph del skill para evitar N+1
@EntityGraph(attributePaths = {"orders", "orders.items"})
Optional<User> findByIdWithOrders(Long id);

springboot-patterns

Arquitectura de aplicaciones Spring Boot con mejores prácticas. Cubre: estructura de capas con separación de concerns, uso de DTOs vs Entities en la capa web, configuración con @ConfigurationProperties (no @Value individual), manejo de excepciones con @ControllerAdvice, y actuator para health monitoring. Define cómo organizar la configuración por perfil (dev/staging/prod).

springboot-tdd

TDD adaptado a Spring Boot. Define el uso de @WebMvcTest para tests de controllers sin levantar el contexto completo, @DataJpaTest para tests de repositorios con H2 en memoria, y @SpringBootTest solo para integration tests que requieren el contexto completo. Incluye patrones con MockMvc para testing de endpoints REST.

springboot-verification

Verificación específica para proyectos Spring Boot antes de deployment. Verifica: beans duplicados o conflictivos, propiedades de configuración requeridas presentes, flyway/liquibase sin migraciones pendientes, y que los actuator endpoints estén correctamente protegidos. Complementa verification-loop con el contexto específico de Spring Boot.

kotlin-patterns

Patrones idiomáticos de Kotlin aprovechando las características del lenguaje. Cubre: extension functions para código expresivo, data classes con copy(), sealed classes para modelar estados, coroutines con structured concurrency, y null safety con el operador Elvis y let/run/also. Define cuándo usar object vs companion object y el uso correcto de by lazy.

// Sealed class pattern para estados del skill
sealed class Result<out T> {
    data class Success<T>(val data: T) : Result<T>()
    data class Error(val message: String, val cause: Throwable? = null) : Result<Nothing>()
    object Loading : Result<Nothing>()
}

kotlin-testing

Testing con Kotlin y Kotest/JUnit 5. Cubre: uso de shouldBe, shouldThrow, y matchers expresivos de Kotest, property-based testing con Kotest Property, mocking con MockK (el mock framework nativo de Kotlin), y testing de coroutines con runTest. Define la organización de tests en describe/context/it blocks para mejor legibilidad.

---

Skills Swift

swift-actor-persistence

Patrones para persistencia de datos usando Swift Actors. Resuelve el problema de thread safety en acceso a bases de datos (CoreData, SwiftData) usando actors que garantizan acceso serializado. Define patrones para @ModelActor en SwiftData, cómo exponer operaciones async de un actor, y manejo de conflictos de concurrencia en data persistence.

// Actor pattern del skill para CoreData
@ModelActor
actor DatabaseService {
    func fetchUsers() async throws -> [User] {
        let descriptor = FetchDescriptor<User>(sortBy: [SortDescriptor(\.name)])
        return try modelContext.fetch(descriptor)
    }
}

swift-concurrency-6-2

Patrones de Swift Concurrency con Swift 6.2. Cubre los cambios importantes de Swift 6 en manejo de sendability, uso de @Sendable closures, migration guide desde GCD (Grand Central Dispatch), y nuevas APIs de async sequences. Especialmente útil para proyectos que migran de callbacks y completion handlers a async/await.

swift-protocol-di-testing

Dependency Injection en Swift mediante protocolos para testabilidad. Define el patrón de protocol + concrete implementation + mock implementation, uso de @EnvironmentObject vs DI explícita en SwiftUI, y cómo organizar los mocks de test. Este patrón es el estándar de facto en proyectos Swift porque Swift no tiene un framework de DI dominante.

// Protocol DI pattern del skill
protocol UserRepository {
    func fetch(id: String) async throws -> User
}

// En producción
struct RemoteUserRepository: UserRepository {
    func fetch(id: String) async throws -> User { /* ... */ }
}

// En tests
struct MockUserRepository: UserRepository {
    var stubbedUser: User?
    func fetch(id: String) async throws -> User {
        guard let user = stubbedUser else { throw TestError.notConfigured }
        return user
    }
}

swiftui-patterns

Patrones de arquitectura para apps SwiftUI. Cubre: MVVM con @Observable (Swift 5.9+), coordinators para navegación compleja, manejo de estado con @State, @Binding, y @Environment, y separación de concerns en views grandes. Define cuándo extraer un subview, cómo manejar loading/error states, y patrones para preview providers reutilizables.

---

Skills AI / ML

Los skills de AI/ML son algunos de los más sofisticados de ECC porque codifican patrones de ingeniería que están emergiendo en tiempo real con el campo.

agent-eval

Framework para evaluar la calidad de agentes de AI. Define métricas de evaluación: task completion rate, herramienta correctamente invocada, número de pasos para completar una tarea, y calidad del output. Incluye el diseño de evaluation sets con casos de test representativos, edge cases, y casos adversariales.

agent-harness-construction

Cómo construir un harness de testing para agentes de AI. Un harness provee un ambiente controlado donde el agente puede ejecutar sus herramientas de forma simulada o real, los resultados son capturados y evaluados automáticamente, y múltiples corridas pueden compararse estadísticamente. Fundamental para detectar regressions en el comportamiento de agentes.

agentic-engineering

Principios de ingeniería para sistemas agénticos en producción. Cubre: diseño de tool interfaces que minimicen errores del LLM, estrategias de retry con backoff, manejo de estados intermedios en workflows largos, observabilidad (logging de cada llamada de herramienta), y límites de seguridad (qué herramientas puede invocar el agente y con qué restricciones).

ai-first-engineering

Paradigma de desarrollo donde el LLM no es un add-on sino el componente central del sistema. Define cómo diseñar aplicaciones donde la lógica de negocio vive en prompts estructurados, cómo versionar y evaluar prompts como código, y cómo construir pipelines donde múltiples modelos especializados colaboran.

cost-aware-llm-pipeline

Diseño de pipelines de LLM conscientes del costo. Estrategias incluidas:

1. Prompt caching: Reutilizar el context de system prompts caros
2. Model routing: Usar Claude Haiku para clasificación, Sonnet para síntesis, Opus para razonamiento complejo
3. Request batching: Agrupar requests similares para reducir overhead
4. Output caching: Cachear respuestas determinísticas con TTL apropiado
5. Token counting pre-flight: Estimar el costo antes de enviar un request y rechazar si excede budget

deep-research

Workflow para investigación exhaustiva usando múltiples fuentes. Define el proceso: formular queries de búsqueda desde múltiples ángulos, sintetizar información de fuentes contradictorias, identificar gaps de información, y estructurar los findings en un reporte accionable. Útil para análisis de mercado, due diligence técnico, y investigación académica asistida.

eval-harness

Sistema completo para evaluaciones de LLM. Define cómo crear un test suite de evaluación con: prompts de evaluación (el “juez LLM”), rubrics con criterios cuantificables, baseline comparisons, y reporte estadístico de resultados. El output incluye tablas comparativas entre versiones de un modelo o sistema.

iterative-retrieval

Workflow para RAG (Retrieval-Augmented Generation) iterativo. En lugar de hacer una sola búsqueda y responder, este skill define múltiples ciclos: búsqueda inicial → análisis de gaps → búsqueda refinada → síntesis. Útil cuando la respuesta correcta requiere información de múltiples chunks que individualmente son insuficientes.

regex-vs-llm-structured-text

Framework de decisión para elegir la herramienta correcta de parsing. La heurística central:

graph TD
    P[¿Texto a parsear?] --> Q1{¿Patrón perfectamente predecible?}
    Q1 -->|Sí| Q2{¿Performance crítica < 1ms?}
    Q1 -->|No| Q3{¿Variaciones naturales del lenguaje?}
    Q2 -->|Sí| R[Regex]
    Q2 -->|No| Q4{¿Mantenimiento costoso?}
    Q3 -->|Sí| L[LLM con structured output]
    Q4 -->|Sí| L
    Q4 -->|No| R

---

Skills de Contenido y Negocio

article-writing

Workflow para escribir artículos técnicos de alta calidad. Define el proceso: investigación del tema, estructura del artículo (hook → problema → solución → ejemplos → conclusión), revisión de precisión técnica, y optimización para lecturabilidad. Incluye checklist de calidad: ¿el código compila? ¿los links funcionan? ¿el nivel de expertise objetivo es consistente?

content-engine

Sistema para producción de contenido a escala. Define cómo crear templates de contenido, proceso editorial con múltiples revisiones, y pipeline de publicación. Útil para equipos que necesitan producir contenido técnico consistente (documentación, blog posts, changelogs) de forma sistemática.

market-research

Workflow estructurado para investigación de mercado con LLM asistido. Define las dimensiones de análisis: tamaño de mercado, competidores, customer segments, pricing, y tendencias. Incluye fuentes recomendadas por tipo de información y formato del reporte final.

investor-materials

Templates y guidelines para crear materiales de fundraising de calidad: pitch deck, financial model, data room. Define la narrativa efectiva para cada tipo de inversor (angel, VC, growth equity), qué métricas incluir según el stage, y cómo presentar el team slide efectivamente.

product-lens

Framework para analizar y documentar decisiones de producto. Aplica el análisis de Jobs-to-be-Done, matriz de priorización ICE (Impact/Confidence/Effort), y definición de success metrics por feature. Útil para PMs y founders que trabajan con Claude para análisis de producto.

---

Skills de Orquestación

autonomous-loops

Patrones para agentes que operan en bucles autónomos sin supervisión constante del usuario. Define: criterios de stop (cuándo el agente debe detenerse y pedir input humano), checkpoints de progreso, manejo de errores sin bloquear el loop, y reporte de actividad para auditoría. Fundamental para tareas de larga duración como migrations, refactors masivos, o research extenso.

claude-devfleet

Orquestación de múltiples agentes Claude trabajando en paralelo. Define cómo dividir una tarea grande en subtareas independientes que múltiples instancias pueden trabajar simultáneamente, cómo mergear los resultados, y cómo resolver conflictos entre el trabajo de diferentes agentes. Requiere un sistema de coordinación para evitar que dos agentes modifiquen el mismo archivo.

---

Cómo Crear un Skill Propio

Crear un skill propio permite codificar el conocimiento específico de tu dominio, stack tecnológico, o convenciones de equipo de forma que Claude pueda aplicarlas consistentemente.

Template Completo de SKILL.md

---
name: mi-skill
description: >
  Una oración que describe qué hace el skill y cuándo activarlo automáticamente.
  Sé específico: "Analiza componentes React para detectar oportunidades de memoización"
  es mejor que "Mejora el performance de React".
origin: MiOrganizacion
version: "1.0"
tags: ["react", "performance", "optimization"]
---

# /mi-skill — Título Descriptivo del Skill

Párrafo introductorio (2-3 oraciones): qué problema resuelve, para quién es,
y qué output produce.

## Trigger
Use this skill when:
- [Condición específica 1 — sé concreto]
- [Condición específica 2]
- [Condición específica 3]

## Steps

### Step 1: [Nombre del Paso]
[Descripción de qué hace este paso, cómo verificar que completó correctamente,
y cuál es el criterio de éxito]

### Step 2: [Nombre del Paso]
[...]

## Decision Matrix
| Condición | Acción recomendada |
|-----------|-------------------|
| [Caso A]  | [Qué hacer] |
| [Caso B]  | [Qué hacer] |
| Default   | [Qué hacer cuando no hay match] |

## Output Format

SKILL REPORT — [Nombre del Skill]

[Sección 1]: ✅/❌ [Estado] [Sección 2]: ✅/❌ [Estado] [Sección 3]: ⚠️ [Advertencia]

Summary: [Una línea describiendo el resultado overall] Next action: [Qué hacer con este resultado]

## Examples

### Ejemplo 1: [Nombre del Caso]
Contexto: [Describe la situación]
Input: [Qué input recibe el skill]
Expected output: [Qué debería producir]

## Anti-patterns
- NO [hacer esto en esta situación porque...]
- NO [esta aproximación porque lleva a...]

## Configuration
- `PARAMETRO_1`: [Descripción] (default: [valor])
- `PARAMETRO_2`: [Descripción] (default: [valor])

7 Pasos para Crear un Skill Efectivo

Paso 1 — Identificar el workflow repetido

Observa qué procesos ejecutas manualmente una y otra vez en tu proyecto. Si te encuentras dando las mismas instrucciones a Claude en diferentes sesiones, ese es un candidato para skill.

Paso 2 — Documentar el proceso actual

Antes de crear el skill, ejecuta el proceso una vez de forma manual y documenta cada decisión: ¿qué inputs recibes? ¿qué verificaciones haces? ¿cómo decides entre alternativas? ¿qué output produces?

Paso 3 — Identificar los decision points

Los momentos donde el proceso podría ir por diferentes caminos son los que necesitan Decision Matrix en el skill. Si siempre hay una sola forma de proceder, un paso lineal es suficiente.

Paso 4 — Definir el output format

Decide exactamente cómo se verá el resultado del skill. El formato debe ser: consistente entre ejecuciones, parseable por otros skills si es necesario, y accionable (debe quedar claro qué hacer con el resultado).

Paso 5 — Escribir el SKILL.md

Usando el template anterior, escribe la primera versión. En este punto, prioriza claridad sobre completitud. Un skill incompleto que es claro es mejor que un skill completo que es ambiguo.

Paso 6 — Probar el skill

Invoca el skill con /mi-skill y observa si Claude lo ejecuta como esperabas. Los puntos de fricción son señales de que el skill necesita más claridad en esas secciones.

Paso 7 — Iterar

Los mejores skills se refinan con uso. Agrega casos a la Decision Matrix cuando encuentres situaciones no cubiertas. Actualiza los anti-patterns cuando alguien (o Claude) cometa el error que el skill debería prevenir.

Criterios de Calidad de un Skill

Un skill bien diseñado cumple estos criterios:

• Determinista: Dado el mismo input y contexto, produce el mismo output (o al menos el mismo tipo de output)
• Autocontenido: No requiere que el usuario tenga conocimiento previo del workflow para usarlo
• Focalizado: Hace una cosa bien, no diez cosas mediocremente
• Medible: Tiene criterios claros de éxito y fallo
• Accionable: El output siempre indica qué hacer a continuación

---

Skill Placement Policy

Una de las decisiones más importantes al trabajar con skills es DÓNDE colocarlos. ECC define dos ubicaciones con propósitos distintos.

~/.claude/skills/ — Skills del Usuario

Esta ubicación almacena skills que aplican a TODOS tus proyectos. Son skills de dominio personal o estándares de tu organización que quieres disponibles en cualquier proyecto donde trabajes.

Ejemplos de skills que van aquí:

• my-coding-standards: Las convenciones personales de código que sigues siempre
• commit-conventions: El formato de commits de tu organización
• security-checklist: El checklist de seguridad de tu empresa
• Skills de ECC curados que usas en todos tus proyectos

{repo}/skills/ — Skills del Proyecto

Esta ubicación almacena skills específicos de un proyecto. Son conocimiento de dominio del proyecto que no aplica fuera de él.

Ejemplos de skills que van aquí:

• deploy-workflow: Los pasos específicos de deployment de este proyecto
• domain-patterns: Patrones del dominio de negocio específico
• integration-testing: El proceso de testing de las integraciones específicas de este proyecto

Regla de Decisión

graph TD
    Q[¿Aplica a todos mis proyectos?] -->|Sí| U[~/.claude/skills/]
    Q -->|No| Q2{¿Aplica a este proyecto?}
    Q2 -->|Sí| R[repo/skills/]
    Q2 -->|No| D[No es un skill, es documentación del proyecto]

Prioridad de Carga

Cuando un skill con el mismo nombre existe en ambas ubicaciones, el skill del repositorio tiene prioridad. Esto permite que los proyectos sobrescriban los defaults del usuario cuando tienen requisitos específicos.

---

Skills y Tokens

El costo de tokens de los skills es una consideración práctica importante, especialmente en proyectos con muchos skills o sesiones largas.

Cálculo Aproximado

Un SKILL.md típico tiene entre 500 y 2000 tokens. Un skill complejo con muchos ejemplos puede llegar a 5000 tokens. Si tienes 20 skills cargados simultáneamente, estás consumiendo entre 10,000 y 100,000 tokens solo en definiciones de skills.

Con modelos que tienen ventanas de contexto de 200K tokens (Claude Sonnet), cargar 20 skills consume entre 5% y 50% del contexto disponible antes de escribir una línea de código.

Estrategia de Selección

La regla práctica: carga solo los skills que usarás en la sesión actual.

graph LR
    T[Tipo de tarea] --> A{¿Qué skills activos?}
    A -->|Nueva feature con TDD| B[tdd-workflow + search-first + coding-standards]
    A -->|Code review de seguridad| C[security-review + verification-loop]
    A -->|Refactor de arquitectura| D[coding-standards + backend-patterns + api-design]
    A -->|Deploy| E[deployment-patterns + verification-loop + docker-patterns]

Skills Siempre Activos vs Skills Bajo Demanda

Algunos skills son tan fundamentales que vale la pena tenerlos siempre activos aunque consuman tokens:

• coding-standards: El costo de inconsistencias de código supera el costo de tokens
• security-scan: El costo de un security issue en producción supera el costo de tokens

Otros skills solo se activan cuando la tarea los requiere:

• pytorch-patterns: Solo para proyectos de ML
• investor-materials: Solo para sesiones de fundraising
• frontend-slides: Solo cuando se necesita crear una presentación

---

Skill Composer Pattern

El Skill Composer Pattern combina múltiples skills en un workflow de orden superior. En lugar de invocar skills individualmente, defines un “meta-skill” que orquesta otros skills en secuencia.

Ejemplo: full-feature-workflow

---
name: full-feature-workflow
description: >
  Workflow completo para implementar una feature nueva: search-first,
  TDD, coding standards, y verification. Usa para features de producción.
origin: MyProject
---

# /full-feature-workflow — Feature Development Complete Workflow

Orquesta el proceso completo de desarrollo de una feature nueva.

## Steps

### Step 1: Research (search-first)
Ejecuta el workflow de /search-first para la feature solicitada.
Documenta la decisión: Adopt/Extend/Compose/Build con justificación.

### Step 2: Design
Define las interfaces antes de implementar.
Crea el test suite mínimo que describe el comportamiento esperado.

### Step 3: TDD (tdd-workflow)
Ejecuta /tdd-workflow para la implementación.
Criterio de éxito: cobertura 80%+, todos los tests en verde.

### Step 4: Standards Check (coding-standards)
Aplica /coding-standards al código generado.
Refactoriza cualquier violación antes de continuar.

### Step 5: Verification (verification-loop)
Ejecuta /verification-loop completo.
No continuar si alguna fase falla.

## Output
Feature implementada con:
- Decision documentada (search-first)
- Tests en verde con 80%+ cobertura
- Estándares de código cumplidos
- Verificación completa pasada

Este meta-skill garantiza que cada feature sigue exactamente el mismo proceso sin que el desarrollador tenga que recordar el orden correcto de invocación.

Composition Patterns

Hay tres patrones de composición de skills:

Secuencial: Los skills se ejecutan uno después del otro. El output de uno puede ser input del siguiente.

graph LR
    SF[search-first] --> TDD[tdd-workflow] --> CS[coding-standards] --> VL[verification-loop]

Paralelo: Múltiples skills se ejecutan concurrentemente sobre el mismo código. Útil para análisis que son independientes entre sí.

graph TD
    C[Código a revisar] --> SR[security-review]
    C --> CS[coding-standards]
    C --> P[performance-patterns]
    SR --> R[Reporte combinado]
    CS --> R
    P --> R

Condicional: El siguiente skill a ejecutar depende del output del skill anterior.

graph TD
    SF[search-first] --> D{¿Resultado?}
    D -->|Adopt| A[Solo integration patterns]
    D -->|Extend| E[tdd-workflow + extension patterns]
    D -->|Build| B[tdd-workflow completo + architecture patterns]

---

skill-create: Generar Skills desde el Git History

ECC incluye un skill especial llamado skill-create que analiza el historial de git de un proyecto y genera automáticamente skills basados en los patrones de trabajo observados.

Cómo Funciona el Análisis

skill-create examina:

1. Commit messages: Detecta patrones como “fix: N+1 query”, “refactor: extract service”, “feat: add auth middleware” — estos son candidatos a skills de patrones comunes
2. Archivos más modificados: Los archivos que se modifican frecuentemente juntos sugieren un workflow relacionado que podría formalizarse en un skill
3. Code reviews y PR descriptions: Si el proyecto usa GitHub/GitLab, analiza los comentarios de review para encontrar patrones de feedback recurrente
4. Test files: Los patrones de testing repetidos (setup/teardown, mocking strategies) son buenos candidatos para skills de testing

Qué Genera

Para cada patrón detectado, skill-create genera un borrador de SKILL.md con:

• Un nombre sugerido basado en el patrón
• Una descripción derivada de los contextos donde apareció el patrón
• Steps basados en las modificaciones de código observadas
• Ejemplos reales del historial del proyecto

Cómo Refinarlo

El output de skill-create es un borrador, no un skill listo para usar. El proceso de refinamiento:

1. Revisar el nombre: ¿es descriptivo y específico?
2. Validar los steps: ¿reflejan el proceso real o son artefactos del análisis?
3. Agregar el Output Format: skill-create raramente genera buenos formatos de output
4. Probar el skill: invocarlo en una tarea real y ajustar según el comportamiento observado

---

skill-health: Verificar Estado de Skills

El comando /skill-health es un meta-skill que audita la calidad de todos los skills instalados.

Qué Revisa

skill-health evalúa cada SKILL.md en todas las ubicaciones configuradas:

Completitud estructural:

• ✅/❌ Frontmatter completo (name, description, origin)
• ✅/❌ Sección Trigger presente
• ✅/❌ Steps definidos
• ✅/❌ Output Format definido

Calidad del contenido:

• ✅/❌ Description tiene más de 15 palabras (descriptions cortas son ambiguas)
• ✅/❌ Al menos 2 triggers definidos
• ✅/❌ Output Format incluye criterios de éxito y fallo
• ⚠️ Skills sin ejemplos (recomendado pero no obligatorio)

Consistencia del sistema:

• ✅/❌ No hay skills con el mismo nombre en múltiples ubicaciones sin documentación
• ⚠️ Skills sin uso reciente (más de 30 días sin ser invocados)
• ⚠️ Skills con versiones desactualizadas respecto al changelog de ECC

Output de skill-health

SKILL HEALTH REPORT
===================
Total skills: 23
  ~/.claude/skills/: 15
  repo/skills/: 8

✅ Healthy: 19
⚠️  Warnings: 3
❌ Issues: 1

ISSUES:
❌ my-deploy-workflow: Missing Output Format section

WARNINGS:
⚠️  custom-lint-rules: No examples defined
⚠️  legacy-migration: Last used 45 days ago — consider archiving
⚠️  frontend-patterns: Local version v1.0, ECC latest v1.3

RECOMMENDATIONS:
1. Fix my-deploy-workflow before next use (missing output format causes inconsistent behavior)
2. Update frontend-patterns to v1.3 (includes React 19 patterns)

---

Mejores Prácticas para Skills Efectivos

Después de trabajar con el sistema de skills de ECC, estas 15 reglas emergen como las más impactantes:

1. La descripción es el 50% del skill Claude usa la descripción para decidir cuándo activar el skill automáticamente. Una descripción vaga produce activaciones incorrectas o ninguna activación. Invierte tiempo en la descripción.

2. Un skill, un workflow Si sientes que un skill debería dividirse en “parte A para X” y “parte B para Y”, ya tienes dos skills. La cohesión importa.

3. Los steps deben ser verificables Cada step debe tener un criterio claro de completitud. “Mejora el código” no es verificable. “Refactoriza funciones con más de 20 líneas hasta que todas tengan menos de 20 líneas” sí lo es.

4. Primero el formato de output Define cómo se verá el resultado antes de escribir los steps. El formato de output guía la estructura de los steps, no al revés.

5. Los ejemplos no son opcionales Los skills sin ejemplos son difíciles de debuggear cuando Claude los aplica incorrectamente. Un ejemplo clarifica lo que 5 párrafos de descripción no pueden.

6. Versiona tus skills Los skills evolucionan. Sin versiones, no puedes saber qué versión está corriendo en producción vs en desarrollo.

7. Los anti-patterns son tan importantes como los patterns Un skill que dice “haz X” pero no dice “no hagas Y” dejará a Claude aplicando Y en los casos que no están explícitamente cubiertos.

8. Prueba los edge cases en los triggers ¿Qué pasa si el trigger aplica parcialmente? Define el comportamiento para casos borderline.

9. Usa la Decision Matrix para todo lo no trivial Si hay más de dos formas de abordar una situación, usa una Decision Matrix. Las matrices hacen el razonamiento explícito y consistente.

10. No dupliques conocimiento entre skills Si dos skills dicen lo mismo sobre manejo de errores, consolida esa sección en un skill base y referencia desde los otros.

11. Los skills de seguridad son siempre activos security-scan y security-review deben estar en ~/.claude/skills/ y considerarse siempre activos. El costo de un security incident supera cualquier costo de tokens.

12. Documenta las dependencias entre skills Si tu skill asume que coding-standards está activo, dilo explícitamente en el frontmatter con un campo requires.

13. Separa el “qué” del “cómo” Un skill no debe hardcodear herramientas cuando el objetivo puede lograrse con múltiples herramientas. Define el objetivo, no la herramienta.

14. Los skills más cortos son mejores Un SKILL.md de 50 líneas que define claramente un workflow es mejor que uno de 500 líneas que intenta cubrir todos los casos posibles. Los casos edge van en la Decision Matrix, no en párrafos de prosa.

15. Itera rápido Un skill imperfecto en producción, siendo refinado con uso real, supera al skill perfecto que nunca se termina. Versiona 1.0, úsalo, y mejora a 1.1 con lo que aprendas.

---

Anti-Patrones: 10 Errores Comunes

Anti-patrón 1: El Skill Dios

Un skill que intenta hacer todo: testing, security, documentation, deployment. Resultado: ninguna de las partes se hace bien. Solución: divide en skills especializados y compón con el Skill Composer Pattern.

Anti-patrón 2: Instrucciones Contradictorias

“Usa TypeScript estricto” en el step 2 y “está bien usar any para pasar rápido” en el step 7. Claude no sabe qué priorizar y producirá resultados inconsistentes. Solución: define la jerarquía de prioridades explícitamente o elimina la contradicción.

Anti-patrón 3: Sin Exit Criteria

Un skill de refactoring que dice “refactoriza hasta que el código sea limpio” nunca termina porque “limpio” no tiene definición objetiva. Solución: define métricas concretas de completitud.

Anti-patrón 4: Hardcoding de Herramientas

“Usa Jest para los tests” en un skill que podría usar Vitest, Mocha, o el runner nativo de Bun. Si el usuario tiene Vitest configurado, el skill no funcionará. Solución: detecta la herramienta existente o pregunta al usuario.

Anti-patrón 5: Steps Imperiales

Un step que contiene 20 sub-acciones. Claude necesita steps atómicos para trackear el progreso. Un step de 20 acciones puede ejecutarse parcialmente sin que nadie lo note. Solución: cada acción atómica es un step separado.

Anti-patrón 6: Sin Output Format

El skill termina y Claude reporta los resultados de forma diferente cada vez que se invoca. Hace imposible la automatización y el parsing. Solución: siempre define Output Format, aunque sea simple.

Anti-patrón 7: Description Genérica

“Skill para mejorar la calidad del código” — esta descripción podría aplicar a 50 skills diferentes. Claude no sabrá cuándo activarlo. Solución: sé específico y técnico en la descripción.

Anti-patrón 8: Skills Obsoletos Sin Deprecación

Un skill que hace referencia a Angular 12 en un proyecto que usa Angular 18. Los skills obsoletos producen sugerencias incorrectas. Solución: versiona los skills y establece un proceso de review periódico.

Anti-patrón 9: Triggers Demasiado Amplios

Un trigger de “cuando escribas cualquier código” activa el skill en todos los casos, incluso cuando no es relevante. Esto consume tokens innecesariamente y diluye el enfoque. Solución: define triggers específicos y accionables.

Anti-patrón 10: Skills sin Testing

Crear un skill y nunca probarlo en una tarea real. Los skills tienen bugs como cualquier código. El único testing es invocarlo en escenarios reales y observar el comportamiento. Solución: después de crear un skill, pruébalo con al menos 3 escenarios diferentes antes de considerarlo estable.

---

Ejercicios Prácticos

Ejercicio 1: Analizar un Skill Existente

Objetivo: Desarrollar criterio para evaluar la calidad de un SKILL.md.

Instrucciones:

1. Abre el SKILL.md de verification-loop (ubicado en ~/.claude/skills/verification-loop/SKILL.md)
2. Evalúa cada sección contra los criterios de este capítulo:
   • ¿La descripción es específica y accionable?
   • ¿Los steps son atómicos y verificables?
   • ¿El Output Format está completamente definido?
   • ¿Hay anti-patterns documentados?
3. Identifica al menos una mejora que harías y justifícala

Criterio de éxito: Puedes articular con precisión por qué la mejora propuesta haría el skill más efectivo.

Ejercicio 2: Crear un Skill Desde Cero

Objetivo: Crear un skill real para un proceso que ya haces manualmente.

Instrucciones:

1. Identifica un proceso que repites más de 3 veces por semana en tu trabajo de development
2. Documenta el proceso manualmente: escribe todos los pasos que tomas, las decisiones que tomas en cada punto, y cómo sabes que terminaste
3. Convierte esa documentación al template de SKILL.md
4. Prueba el skill invocándolo con /tu-skill
5. Itera basándote en el comportamiento observado

Criterio de éxito: El skill ejecuta el proceso sin que tengas que dar instrucciones adicionales.

Ejercicio 3: Componer Skills

Objetivo: Crear un meta-skill usando el Skill Composer Pattern.

Instrucciones:

1. Identifica 3 skills que usas en secuencia para una tarea común (ejemplo: search-first → tdd-workflow → verification-loop para una feature nueva)
2. Crea un meta-skill llamado {nombre}-workflow que orqueste los tres
3. Define en el meta-skill qué información debe pasar de un skill al siguiente
4. Define el Output Format del meta-skill (que consolide los outputs de los tres skills individuales)

Criterio de éxito: Puedes completar una tarea invocando solo el meta-skill sin invocar los skills individuales.

Ejercicio 4: Skill de Seguridad Personalizado

Objetivo: Crear un skill de security-review adaptado a tu stack tecnológico.

Instrucciones:

1. Identifica las 5 vulnerabilidades más comunes en tu stack específico (ejemplo: Laravel + MySQL + Redis)
2. Para cada vulnerabilidad, define:
   • Cómo detectarla (qué patrón de código buscar)
   • Cómo reportarla (qué información incluir en el reporte)
   • Cómo corregirla (qué cambio de código hacer)
3. Crea un SKILL.md my-stack-security que cubra las 5 vulnerabilidades
4. Prueba el skill contra un proyecto real

Criterio de éxito: El skill detecta al menos una issue real en un proyecto existente.

Ejercicio 5: Skill Health Audit

Objetivo: Aplicar criterios de calidad a todos los skills instalados.

Instrucciones:

1. Invoca /skill-health en tu instalación de Claude Code
2. Para cada issue reportado, decide: corregir, archivar, o documentar por qué es aceptable
3. Para los 3 skills más usados, revisa si siguen siendo relevantes o necesitan actualización
4. Identifica un skill que debería existir pero no existe, y créalo

Criterio de éxito: /skill-health reporta 0 issues críticos y menos de 3 warnings.

---

Checklist y Resumen

Checklist: Evaluando un SKILL.md

• Frontmatter completo: name, description, origin
• Description es específica, técnica, y tiene 20+ palabras
• Sección Trigger con al menos 2 condiciones concretas
• Steps son atómicos y verificables individualmente
• Cada step tiene criterio de completitud claro
• Decision Matrix presente para todos los casos no triviales
• Output Format completamente definido con ejemplos de ✅ y ❌
• Al menos un Example completo con Input y Expected Output
• Anti-patterns documentados (al menos 2)
• Versión en frontmatter
• Skill probado en al menos 3 escenarios reales

Checklist: Instalando Skills

• Skills globales en ~/.claude/skills/
• Skills del proyecto en {repo}/skills/
• Solo los skills necesarios para la sesión actual activos
• security-scan y security-review siempre activos
• /skill-health sin issues críticos

Checklist: Usando Skills Efectivamente

• Invocar skills explícitamente con /nombre-skill cuando la tarea lo requiere
• No cargar skills que no se usarán en la sesión
• Usar Skill Composer Pattern para workflows multi-step repetidos
• Documentar cualquier desviación del skill con justificación
• Actualizar el skill si el proceso que describe ha cambiado

Resumen del Capítulo

Los skills son la unidad fundamental de conocimiento reutilizable en ECC. Permiten codificar prácticas de ingeniería, patrones de dominio, y workflows de equipo de forma que Claude pueda aplicarlos consistentemente sin necesidad de instrucciones repetidas.

Los tres skills más fundamentales del sistema son:

• search-first: Evita reimplementar lo que ya existe mediante investigación sistemática previa
• tdd-workflow: Garantiza calidad mediante el ciclo completo de Test-Driven Development
• verification-loop: Asegura que cada cambio pasa por todas las verificaciones de calidad necesarias

El ecosistema completo de 108+ skills cubre todos los lenguajes y dominios relevantes para desarrollo moderno, desde frontend con React hasta ML con PyTorch, y desde seguridad hasta gestión de producto.

La arquitectura de skills de ECC sigue el principio de open/closed: el sistema base es estable y confiable, pero es extensible mediante skills propios que codifican el conocimiento específico de tu proyecto, stack, y equipo.

En el siguiente capítulo exploraremos los Agentes de ECC: cómo funcionan, qué agentes están disponibles, y cómo los skills que aprendimos aquí se convierten en el conocimiento que guía a los agentes en sus tareas autónomas.

---

Skills Avanzados: Patrones de Uso en Producción

Esta sección documenta patrones avanzados que emergen cuando los skills se usan en proyectos reales de producción con equipos distribuidos y bases de código grandes.

Pattern: Skill Gating en CI/CD

Una de las aplicaciones más poderosas de los skills es convertirlos en gates automáticos en el pipeline de CI/CD. En lugar de tener checklist manuales que los developers pueden saltarse, los skills se ejecutan automáticamente como parte del pipeline.

graph LR
    PR[Pull Request] --> SK1[verification-loop]
    SK1 -->|✅ Pass| SK2[security-scan]
    SK2 -->|✅ Pass| SK3[coding-standards]
    SK3 -->|✅ Pass| MR[Merge permitido]
    SK1 -->|❌ Fail| BL[Merge bloqueado]
    SK2 -->|❌ Fail| BL
    SK3 -->|❌ Fail| BL

La implementación práctica usa los hooks de Claude Code junto con scripts de CI:

#!/bin/bash
# pre-merge-check.sh — ejecuta skills como gates de CI

# Ejecutar verification-loop
claude -p "Execute /verification-loop on the current diff" \
  --output-format json | jq -e '.status == "PASS"'

if [ $? -ne 0 ]; then
  echo "❌ verification-loop FAILED — merge blocked"
  exit 1
fi

# Ejecutar security-scan
claude -p "Execute /security-scan on staged changes" \
  --output-format json | jq -e '.issues | length == 0'

if [ $? -ne 0 ]; then
  echo "❌ security-scan found issues — merge blocked"
  exit 1
fi

echo "✅ All skill gates passed"
exit 0

Pattern: Skill Versioning con Semver

Para equipos grandes, versionar los skills con semver es fundamental. Los cambios breaking en un skill (un nuevo step obligatorio, cambio de output format) merecen un bump de versión mayor.

---
name: api-design
version: "2.1.3"
# CHANGELOG:
# 2.1.3 - Fix: Decision matrix incluía caso edge de WebSockets
# 2.1.0 - Feature: Agrega sección de GraphQL patterns
# 2.0.0 - BREAKING: Output format cambió de texto a JSON
# 1.x.x - Versión inicial con REST patterns
---

Cuando un skill tiene breaking changes, el equipo necesita un período de transición donde ambas versiones coexisten. La convención de ECC es mantener la versión anterior con el sufijo -legacy hasta que todos los proyectos migren.

Pattern: Skill Inheritance

Cuando múltiples skills comparten una base común, el patrón de herencia evita duplicación. El skill base define los elementos comunes y los skills derivados los extienden.

~/.claude/skills/
  base-testing/
    SKILL.md          # Patrones comunes de testing
  python-testing/
    SKILL.md          # extends: base-testing + patrones Python-específicos
  golang-testing/
    SKILL.md          # extends: base-testing + patrones Go-específicos
  kotlin-testing/
    SKILL.md          # extends: base-testing + patrones Kotlin-específicos

El skill base documenta los principios universales: aislamiento de tests, naming conventions, estructura Arrange-Act-Assert. Los skills derivados solo documentan lo que es diferente en su ecosistema.

Pattern: Skill Telemetry

Para teams que quieren mejorar sus skills basándose en datos reales, implementar telemetría de uso permite tomar decisiones informadas sobre qué skills funcionan bien y cuáles necesitan refinamiento.

Métricas a capturar:

• Frecuencia de invocación por skill
• Tiempo promedio de ejecución
• Tasa de éxito/fallo por skill
• Skills más frecuentemente modificados (indicador de inestabilidad)
• Skills nunca usados después de instalación (candidatos a archivo)

La telemetría se puede implementar como un hook post-skill que registra metadata en un log estructurado:

{
  "timestamp": "2024-12-17T10:30:00Z",
  "skill": "tdd-workflow",
  "invocation_type": "user",
  "outcome": "success",
  "phases_completed": 7,
  "coverage_achieved": 84,
  "session_id": "abc123"
}

---

Skills por Lenguaje: Tabla de Referencia Rápida

La siguiente tabla muestra todos los skills disponibles organizados por lenguaje/tecnología con su caso de uso principal:

JavaScript / TypeScript

Skill	Caso de Uso Principal	Invocación
coding-standards	Estándares generales TS/JS	Al iniciar proyecto o code review
bun-runtime	Patrones específicos de Bun	Al usar Bun como runtime
frontend-patterns	React/Next.js patterns	Al trabajar en frontend
e2e-testing	Playwright + POM	Al agregar tests E2E
browser-qa	QA visual automatizado	Pre-release, post-design-change
design-system	Component library patterns	Al crear/mantener design system
frontend-slides	Presentaciones HTML estáticas	Al crear presentaciones técnicas

Python

Skill	Caso de Uso Principal	Invocación
python-patterns	Patrones idiomáticos Python	Al iniciar desarrollo Python
python-testing	pytest + coverage	Al escribir tests Python
django-patterns	Arquitectura Django	Al iniciar proyecto Django
django-tdd	TDD en Django	Al implementar features Django
django-verification	Checks Django post-implementación	Pre-deploy en Django
django-security	Auditoría seguridad Django	Code review de seguridad
pytorch-patterns	ML/DL con PyTorch	Al trabajar en modelos ML

Java / JVM

Skill	Caso de Uso Principal	Invocación
java-coding-standards	Estándares Java 21+	Al iniciar proyecto Java
jpa-patterns	JPA/Hibernate sin N+1	Al diseñar modelo de datos
springboot-patterns	Arquitectura Spring Boot	Al trabajar en Spring Boot
springboot-tdd	TDD en Spring Boot	Al implementar features
springboot-verification	Checks Spring Boot	Pre-deploy
springboot-security	Seguridad Spring Boot	Auditoría de seguridad
kotlin-patterns	Kotlin idiomático	Al desarrollar en Kotlin
kotlin-testing	Kotest + MockK	Al escribir tests Kotlin

PHP

Skill	Caso de Uso Principal	Invocación
laravel-patterns	Arquitectura Laravel	Al iniciar proyecto Laravel
laravel-tdd	TDD en Laravel	Al implementar features
laravel-verification	Checks Laravel	Pre-deploy
laravel-security	Seguridad Laravel	Auditoría de seguridad

Go

Skill	Caso de Uso Principal	Invocación
golang-patterns	Go idiomático	Al iniciar proyecto Go
golang-testing	Testing Go con testify	Al escribir tests Go

Swift / iOS / macOS

Skill	Caso de Uso Principal	Invocación
swiftui-patterns	Arquitectura SwiftUI	Al desarrollar UI iOS/macOS
swift-concurrency-6-2	Async/await Swift 6	Al migrar a Swift 6 concurrency
swift-actor-persistence	Thread-safe persistence	Al implementar CoreData/SwiftData
swift-protocol-di-testing	DI con protocolos	Al diseñar arquitectura testeable

Mobile (React Native / Android)

Skill	Caso de Uso Principal	Invocación
android-clean-architecture	Clean Architecture Android	Al estructurar proyecto Android
react-native-patterns	Patrones React Native	Al desarrollar apps React Native
flutter-dart-code-review	Code review Flutter/Dart	Al revisar código Flutter

AI / ML / Data

Skill	Caso de Uso Principal	Invocación
agent-eval	Evaluar agentes AI	Al medir calidad de agentes
agent-harness-construction	Construir harness de testing	Al crear test suites para agentes
agentic-engineering	Ingeniería de sistemas agénticos	Al diseñar pipelines agénticos
ai-first-engineering	Aplicaciones LLM-centric	Al diseñar apps AI-first
cost-aware-llm-pipeline	Optimización de costos LLM	Al optimizar pipeline de producción
deep-research	Investigación exhaustiva multi-fuente	Al hacer research complejo
eval-harness	Framework de evaluación LLM	Al crear benchmarks de modelos
iterative-retrieval	RAG iterativo	Al implementar sistemas RAG
pytorch-patterns	PyTorch para producción	Al desarrollar modelos DL
regex-vs-llm-structured-text	Decidir regex vs LLM	Al implementar text parsing

DevOps / Infraestructura

Skill	Caso de Uso Principal	Invocación
deployment-patterns	Estrategias de deployment	Al planificar un release
docker-patterns	Dockerización eficiente	Al containerizar una app
database-migrations	Migrations seguras	Al modificar schema de DB
postgres-patterns	PostgreSQL patterns avanzados	Al optimizar queries Postgres
mcp-server-patterns	Construir MCP servers	Al extender Claude con tools
canary-watch	Monitoreo post-deploy	Después de deployar a producción

Contenido y Negocio

Skill	Caso de Uso Principal	Invocación
article-writing	Artículos técnicos de calidad	Al escribir contenido técnico
content-engine	Producción de contenido a escala	Al sistemar la producción de contenido
market-research	Research de mercado estructurado	Al analizar mercados y competidores
investor-materials	Materials de fundraising	Al preparar pitch deck o data room
product-lens	Análisis y decisiones de producto	Al tomar decisiones de product roadmap
benchmark	Benchmarking de performance	Al medir y comparar performance
blueprint	Documentación de arquitectura	Al documentar decisiones de diseño
architecture-decision-records	ADRs estructurados	Al documentar decisiones técnicas

Orquestación y Meta-Skills

Skill	Caso de Uso Principal	Invocación
autonomous-loops	Agentes en bucles autónomos	Al configurar agentes de larga duración
claude-devfleet	Multi-agente paralelo	Al orquestar múltiples agentes
strategic-compact	Compactación de contexto	Al gestionar sesiones largas
continuous-learning	Sistematizar aprendizajes	Al documentar knowledge de sesiones
continuous-learning-v2	Learning con RAG	Al construir knowledge base con búsqueda
rules-distill	Destilar reglas desde experiencia	Al convertir patrones en reglas
plankton-code-quality	Quality gates ligeros	Al configurar quality checks rápidos
documentation-lookup	Buscar documentación eficientemente	Al investigar APIs y librerías

---

Integración de Skills con CLAUDE.md

El archivo CLAUDE.md del proyecto es el lugar donde se declara qué skills están activos por defecto para todos los que trabajan en el proyecto. Esta integración asegura que todos los miembros del equipo usen los mismos workflows sin necesidad de configuración individual.

Declaración de Skills en CLAUDE.md

## Active Skills

### Always Active
- `/coding-standards` — enforced on all code
- `/security-scan` — runs on every file touched
- `/verification-loop` — required before any commit

### Available (invoke as needed)
- `/tdd-workflow` — for new features
- `/search-first` — before implementing new functionality
- `/api-design` — when adding endpoints

### Project-Specific Skills
Located in `skills/` directory:
- `/deploy-workflow` — deployment process for this project
- `/domain-patterns` — domain-specific patterns for {project name}

Onboarding Automático

Cuando un nuevo developer clona el repositorio y empieza a trabajar con Claude Code, el CLAUDE.md hace el onboarding automático: Claude lee qué skills están activos, los carga, y comienza a aplicar los workflows del proyecto sin que el developer tenga que configurar nada manualmente.

Este es uno de los beneficios más prácticos del sistema de skills: el conocimiento del equipo se comparte automáticamente a través de los archivos de configuración del repositorio.

Skills y Code Review

Los skills pueden integrarse en el proceso de code review documentando qué skills se aplicaron durante la implementación:

## Pull Request: Agregar autenticación OAuth

### Skills aplicados
- [x] /search-first — Evaluado `passport.js` vs `nextauth.js` vs implementación custom. Decisión: NextAuth (Adopt)
- [x] /tdd-workflow — Cobertura final: 87%
- [x] /security-review — Sin findings críticos o high. 2 medium (documentados en PR)
- [x] /verification-loop — Todas las fases pasadas

Este formato hace que el reviewer pueda ver rápidamente qué proceso de calidad se siguió y dónde están los puntos de atención.

---

Casos de Estudio: Skills en Proyectos Reales

Caso 1: Migración de JavaScript a TypeScript Estricto

Problema: Un proyecto con 150 archivos JavaScript necesita migrarse a TypeScript estricto sin romper funcionalidad existente.

Skills utilizados:

1. search-first: Evaluar herramientas de migración automática (ts-migrate, TypeScript’s --allowJs flag)
2. coding-standards: Definir el nivel de strictness objetivo y las reglas de tsconfig
3. tdd-workflow: Para cada módulo migrado, asegurar cobertura de tests antes de modificar

Proceso:

graph TD
    A[150 archivos JS] --> B[search-first: evaluar ts-migrate]
    B --> C{ts-migrate viable?}
    C -->|Sí parcialmente| D[Migrar 80% con ts-migrate]
    C -->|No| E[Migración manual]
    D --> F[Por cada archivo migrado]
    F --> G[tdd-workflow: tests existentes pasan?]
    G -->|No| H[Fix types hasta que pasen]
    G -->|Sí| I[coding-standards: check strict types]
    I --> J[Next archivo]

Resultado: La migración tomó 3 semanas con 0 bugs en producción post-migración. Los skills garantizaron que ningún módulo se marcaba como “migrado” hasta que tenía tests en verde y types correctos.

Caso 2: Auditoría de Seguridad Pre-Launch

Problema: Una startup está a 2 semanas de lanzar su producto y necesita una auditoría de seguridad completa.

Skills utilizados:

• security-review: Auditoría completa de la aplicación
• django-security: Checklist específico para el stack Django
• security-scan: Detección automática de secrets y patterns peligrosos
• postgres-patterns: Verificar que las queries no tienen injection vulnerabilities

Hallazgos del Proceso:

En un proyecto Django típico, los skills detectaron en una sesión de 4 horas:

• 2 Critical: Django Admin accesible públicamente + SECRET_KEY en git history
• 3 High: CORS wildcard, cookies sin Secure flag, raw SQL con interpolación
• 5 Medium: Logging de datos sensibles, dependencias con CVEs conocidos
• 8 Low: Headers de seguridad faltantes, configuraciones subóptimas

Todos los findings fueron corregidos antes del lanzamiento. Sin los skills, este proceso habría requerido un consultor de seguridad externo o habría sido omitido.

Caso 3: Implementar un RAG Pipeline con Cost Awareness

Problema: Un equipo necesita implementar un sistema RAG (Retrieval-Augmented Generation) para búsqueda semántica de documentación interna, con un budget mensual de $500 en API costs.

Skills utilizados:

• search-first: Evaluar Langchain vs LlamaIndex vs implementación custom
• cost-aware-llm-pipeline: Diseñar el pipeline para mantenerse dentro del budget
• iterative-retrieval: Implementar el ciclo de retrieval multi-paso
• eval-harness: Medir la calidad del retrieval contra un conjunto de preguntas de prueba

Decisiones guiadas por los skills:

search-first recomendó usar LlamaIndex (Extend) con adaptaciones para el caso de uso específico.

cost-aware-llm-pipeline diseñó la arquitectura:

• Embeddings: text-embedding-3-small (10x más barato que large, <5% degradación en este dataset)
• Query routing: clasificar queries como “simple” → Claude Haiku, “complejo” → Claude Sonnet
• Caching: 70% de queries son repetidas → cache con Redis, TTL 24h
• Estimación mensual: $127 en lugar de los $800 sin optimizaciones

eval-harness midió: precision@5 = 0.82, recall@10 = 0.91 — métricas aceptables para el caso de uso.

---

La Filosofía Detrás del Sistema de Skills

El sistema de skills de ECC no es simplemente una colección de checklists. Representa una filosofía de trabajo específica: el conocimiento de dominio debe ser explícito, versionado, y ejecutable.

Conocimiento Tácito vs Conocimiento Explícito

En cualquier equipo de desarrollo, existe una enorme cantidad de conocimiento tácito: “los seniors saben que nunca debes hacer X en este framework”, “hay un patrón específico que usamos para Y porque tuvimos un incident hace 2 años”, “los tests de integración siempre necesitan Z”. Este conocimiento vive en las cabezas de las personas y se transmite solo por proximidad.

Los skills convierten este conocimiento tácito en conocimiento explícito. Cuando un senior escribe un security-checklist con las lecciones aprendidas de 5 años de incidents, ese conocimiento ya no depende de que el senior esté disponible. Está codificado, es buscable, y puede ser aplicado por Claude en cualquier momento.

Skills como Memoria Organizacional

Un skill es una forma de memoria organizacional. Las organizaciones que codifican su conocimiento en skills acumulan ventajas compuestas:

• Cada incident que resulta en un nuevo check en security-review hace al equipo más seguro permanentemente
• Cada patrón que se descubre y se codifica en {tech}-patterns acelera el desarrollo de futuros proyectos
• Cada anti-patrón documentado previene que el mismo error se cometa dos veces

Con el tiempo, la biblioteca de skills de una organización se convierte en una ventaja competitiva. Refleja años de aprendizajes específicos del dominio, stack, y contexto de negocio.

Skills y la Democratización del Expertise

Uno de los efectos más profundos del sistema de skills es la democratización del expertise. Un developer junior con acceso a los skills de un equipo experimentado puede seguir los mismos workflows que los seniors, sin necesidad de años de experiencia para “descubrir” los patrones correctos.

Esto no reemplaza la mentoría ni la experiencia directa. Pero reduce la brecha de conocimiento entre juniors y seniors de forma práctica y medible. Y permite que los seniors pasen menos tiempo respondiendo las mismas preguntas y más tiempo creando conocimiento nuevo que se codifica en skills.

graph TD
    E[Experiencia del Senior] -->|se codifica en| S[Skill]
    S -->|democratiza para| J[Developer Junior]
    J -->|usa y descubre| N[Nuevo conocimiento]
    N -->|se agrega al| S
    S -->|mejora con el tiempo| SM[Skill maduro]

El Contrato del Skill

Un skill bien diseñado representa un contrato: “si sigues estos pasos en este orden, con estos criterios, producirás este tipo de resultado con esta calidad”. Este contrato tiene valor porque:

1. Es verificable: Puedes auditar si el skill se siguió correctamente
2. Es mejorable: Si el contrato no produce los resultados esperados, sabes exactamente qué parte del proceso cambiar
3. Es compartible: El mismo contrato puede seguirse por diferentes personas en diferentes proyectos
4. Es automatizable: Un agente puede seguir el contrato sin supervisión humana constante

Esta es la razón por la que los skills son tan centrales en ECC: no son solo “prompts mejorados”. Son contratos de calidad ejecutables.

---

---

Appendix: Referencia de Frontmatter para Skills

Esta referencia documenta todos los campos soportados en el frontmatter de un SKILL.md, con sus tipos, valores permitidos, y ejemplos.

Campos del Frontmatter

name (string, obligatorio)

Identificador único del skill. Debe coincidir exactamente con el nombre del directorio padre. Usa kebab-case. No puede contener espacios ni caracteres especiales.

name: my-custom-skill

description (string, obligatorio)

La descripción más importante del skill. Claude la usa como criterio de matching para activación automática. Debe ser:

• Específica y técnica
• Entre 20 y 100 palabras
• Describir tanto QUÉ hace el skill como CUÁNDO activarlo

description: >
  Analiza componentes React para detectar renders innecesarios, uso incorrecto
  de hooks, y oportunidades de memoización. Usar cuando se reportan problemas
  de performance en la UI o al realizar code review de componentes con estado complejo.

origin (string, obligatorio)

Indica la fuente del skill. Valores convencionales:

• ECC — Everything Claude Code (skills del sistema base)
• Nombre de tu organización para skills propios
• Nombre del proyecto para skills específicos de un repo

origin: ECC
# o
origin: MiEmpresa
# o
origin: proyecto-alpha

version (string, recomendado)

Versión semántica del skill. Permite tracking de cambios y rollback cuando una actualización degrada el comportamiento.

version: "2.1.0"

tags (array de strings, recomendado)

Categorías para búsqueda y filtrado. Facilita encontrar skills relacionados y la generación de índices.

tags: ["testing", "python", "pytest", "coverage"]

requires (array de strings, opcional)

Lista de otros skills que deben estar activos para que este skill funcione correctamente. Claude verificará que estén disponibles al activar el skill.

requires: ["coding-standards", "base-testing"]

conflicts (array de strings, opcional)

Skills que no deben estar activos al mismo tiempo que este skill, por tener instrucciones contradictorias.

conflicts: ["legacy-testing-patterns"]

auto_activate (boolean, opcional, default: false)

Si es true, el skill se activa automáticamente cuando la descripción hace match con el contexto de la tarea, sin necesidad de invocación explícita del usuario.

auto_activate: true

scope (string, opcional)

Define el alcance del skill: session (activo durante toda la sesión) o invocation (activo solo durante la ejecución del skill).

scope: session

priority (integer, opcional, default: 0)

Cuando múltiples skills hacen match con un contexto, el de mayor prioridad tiene precedencia. Rango: 0-100.

priority: 80

Ejemplo de Frontmatter Completo

---
name: react-performance-audit
description: >
  Analiza componentes React para detectar renders innecesarios, uso incorrecto
  de useMemo/useCallback, y oportunidades de code splitting. Activar al
  reportar performance issues en UI React o durante code review de componentes complejos.
origin: MiOrganizacion
version: "1.3.0"
tags: ["react", "performance", "optimization", "frontend"]
requires: ["coding-standards"]
auto_activate: false
scope: session
priority: 60
---

---

Appendix: Glosario de Términos

Skill: Archivo SKILL.md que define un workflow reutilizable con steps, criterios, y output format. No es código ejecutable sino conocimiento de dominio estructurado.

Agent Skill: Skill diseñado para ser invocado automáticamente por un agente basándose en la detección de contexto, sin intervención explícita del usuario.

User-Invocable Skill: Skill que el usuario activa explícitamente mediante un comando /nombre-skill.

Skill Composer: Patrón de diseño que combina múltiples skills en un meta-skill que los orquesta en secuencia, paralelo, o de forma condicional.

Trigger: Condición en el SKILL.md que define cuándo debe activarse el skill. Para agent skills, el agente evalúa los triggers automáticamente.

Decision Matrix: Tabla en el SKILL.md que mapea condiciones a acciones recomendadas. Convierte decisiones implícitas en reglas explícitas y verificables.

Output Format: Sección del SKILL.md que define exactamente cómo se reporta el resultado del skill. Garantiza consistencia entre invocaciones.

Skill Placement: Política que determina si un skill va en ~/.claude/skills/ (global del usuario) o en {repo}/skills/ (específico del proyecto).

Skill Health: Estado de calidad de un skill evaluado contra criterios de completitud, claridad, y testabilidad. Se audita con el comando /skill-health.

Skill Telemetry: Métricas de uso de skills (frecuencia, tasa de éxito, tiempo de ejecución) para informar decisiones de mejora.

Skill Gate: Uso de un skill como barrera automática en un pipeline de CI/CD que bloquea avance si el skill reporta fallos.

Skill Inheritance: Patrón donde un skill base define elementos comunes y skills derivados los extienden con especializaciones sin duplicar la base.

ECC: Everything Claude Code — el sistema que provee la infraestructura de skills, agentes, y herramientas sobre las que se construye este tutorial.

RAG: Retrieval-Augmented Generation — técnica donde un LLM combina su conocimiento base con información recuperada de fuentes externas para producir respuestas más precisas.

MCP: Model Context Protocol — protocolo estándar para que los LLMs se comuniquen con herramientas y fuentes de datos externas.

Context Drift: Fenómeno donde en sesiones largas Claude empieza a olvidar o contradecir decisiones tomadas al inicio de la sesión. El skill strategic-compact lo previene.

---

Siguiente: Capítulo 5: Agentes — Identidad, Roles y Orquestación