Cómo crear tus propias Claude Code Skills en 2026: tutorial paso a paso con SKILL.md

Las Claude Code Skills son la novedad más útil que ha aterrizado en el CLI de Anthropic en lo que va de 2026. Si llevabas meses copiando el mismo prompt gigante cada vez que arrancabas una sesión ("eres un experto en mi codebase, usa Vitest, sigue el estilo Airbnb, jamás toques la carpeta legacy, etc."), las Skills existen precisamente para acabar con esa fricción. Una Skill es una carpeta con un SKILL.md que Claude Code descubre al arrancar y carga bajo demanda cuando la tarea del usuario coincide con su trigger. Ni más prompts pegados a mano, ni más contexto malgastado en instrucciones que solo aplican a un tipo de trabajo.

En este tutorial vas a crear desde cero tu primera Skill: un especialista en escribir tests con Vitest que se activa solo cuando pides tests, valida su estructura con un script helper y trae plantillas listas para copiar. Cubriremos la diferencia entre Skills y otras piezas de extensibilidad (Hooks, Subagents, MCP), la anatomía completa del SKILL.md con frontmatter YAML, cómo publicarla en tu equipo por Git y qué Skills públicas del repo anthropics/skills merece la pena instalar de partida. Al final tendrás un patrón replicable para convertir cualquier workflow repetido en una Skill compartible.

Qué son las Claude Code Skills y por qué son mejores que copiar prompts

Una Skill es un directorio con al menos un archivo SKILL.md compuesto por un frontmatter YAML (metadatos: nombre, descripción, cuándo usarla) y un cuerpo Markdown (las instrucciones detalladas para Claude). Opcionalmente puede incluir helper scripts (bash, Python, Node), assets (plantillas, ejemplos, snippets) y ficheros de referencia adicionales que la Skill decide leer si la tarea lo requiere. Claude Code inspecciona el frontmatter en cada sesión, pero solo carga el cuerpo Markdown cuando el modelo decide que la tarea coincide con la descripción. Ese diseño lazy es lo que hace las Skills escalables: puedes tener treinta Skills instaladas sin comerte todo el contexto.

La ventaja frente a copiar y pegar prompts es enorme. Un prompt largo pegado a mano al inicio de sesión consume tokens en toda la conversación, aunque el 90 por ciento no aplique a lo que estás haciendo. Con Skills, el mismo cuerpo de instrucciones solo entra en contexto cuando lo necesitas. Además vives con las Skills en el repo: se versionan, se revisan por PR, se comparten entre compañeros de equipo y se auditan como cualquier otro fichero fuente. Es la diferencia entre "tengo un Notion con mis prompts favoritos" y "tengo un sistema operativo de instrucciones que se instala con git clone". Si vienes de la escuela de Managed Agents de Anthropic, este es el mecanismo local equivalente al que analizamos en el artículo sobre Managed Agents y Dreaming.

Skills vs Hooks vs Subagents vs MCP: tabla comparativa

Antes de escribir tu primera Skill conviene tener claro dónde encaja en el ecosistema de extensibilidad de Claude Code. Los cuatro mecanismos son complementarios, no sustitutos:

• Skills: instrucciones cargadas bajo demanda según el contexto de la tarea. Cambian el cómo del modelo (estilo, checklist, dominio). Ejecución: siempre dentro del turno de Claude, sin proceso externo.
• Hooks: comandos shell que el harness ejecuta en eventos concretos (pre/post edit, pre/post commit, on tool call, on stop). Son deterministas y automáticos: el hook no depende de que Claude "decida" invocarlo. Ideales para linters, formateadores, cargar variables de entorno o disparar tests después de guardar.
• Subagents: procesos hijos de Claude Code con su propio contexto y (a veces) sus propios permisos. Se lanzan con la herramienta Agent y devuelven un único mensaje al agente padre. Sirven para tareas paralelizables, búsqueda amplia sin ensuciar el contexto principal, o segunda opinión de un revisor.
• MCP servers: procesos independientes que exponen tools, resources y prompts vía Model Context Protocol. Aportan capacidades nuevas (leer tu Postgres, escribir en Notion, consultar Sentry). Si tienes dudas sobre cuándo montar tu propio servidor, mira el tutorial de servidores MCP en TypeScript.

Regla mental sencilla: si quieres cambiar cómo trabaja Claude en cierto tipo de tarea, es una Skill. Si quieres ejecutar algo determinista en un evento del ciclo de vida, es un Hook. Si necesitas trabajo paralelo o contexto aislado, es un Subagent. Si tienes que hablar con un sistema externo, es un MCP server. Muchas soluciones profesionales combinan los cuatro: una Skill "Review PR" que invoca un Subagent, que a su vez usa un MCP server de GitHub, todo cerrado por un Hook post-review que corre linters.

Anatomía de una Skill: estructura de carpeta

La estructura mínima es esta:

~/.claude/skills/vitest-writer/
  SKILL.md              # obligatorio: frontmatter YAML + body Markdown
  scripts/
    validate-tests.sh   # opcional: helpers ejecutables
  templates/
    unit.test.ts        # opcional: assets referenciados desde el body
    component.test.tsx
  references/
    matchers.md         # opcional: referencia extendida cargada solo si hace falta

Claude Code busca Skills en dos ubicaciones estándar. Las Skills de usuario viven en ~/.claude/skills/ y están disponibles en todos tus proyectos. Las Skills de proyecto viven en ./.claude/skills/ dentro del repositorio y se comparten con quien clone el repo (es la forma canónica de repartirlas por equipo). Cuando una Skill de proyecto y una de usuario tienen el mismo nombre, gana la de proyecto: te permite sobrescribir el comportamiento genérico con reglas concretas del cliente.

El SKILL.md siempre tiene dos partes. Arriba, un bloque YAML entre --- con las llaves que Claude usa para decidir cuándo activarla. Abajo, Markdown libre con las instrucciones detalladas que quieres que el modelo siga. El frontmatter se lee al arrancar; el body solo entra en contexto si la Skill se activa. Ese contraste marca cómo debes escribir cada parte: frontmatter conciso y muy específico, body extenso y accionable.

Requisitos previos

Necesitas tres cosas y no cuesta nada arrancar:

• Claude Code instalado en su versión de julio de 2026 o superior (soporte de Skills es estable desde la primavera de 2026). Instalación con npm install -g @anthropic-ai/claude-code o desde claude.com/claude-code.
• Cuenta Claude o clave API: la cuenta Claude Pro/Max ya viene con crédito de CLI incluido. Si prefieres pago por uso, exporta ANTHROPIC_API_KEY.
• Editor con soporte Markdown y YAML: cualquier VS Code, Cursor, Zed o Neovim funciona. Nada exótico.

Si vienes de otro CLI de IA y aún no dominas Claude Code, pásate primero por el tutorial de Claude Code. Este artículo asume que ya sabes lanzar una sesión y usar /help.

Paso 1: Crear la estructura ~/.claude/skills/mi-skill/

Empezamos con una Skill de usuario para probar rápido; luego la moveremos al repo si nos gusta. Abre la terminal:

mkdir -p ~/.claude/skills/vitest-writer/scripts
mkdir -p ~/.claude/skills/vitest-writer/templates
touch ~/.claude/skills/vitest-writer/SKILL.md

Nombra la carpeta con kebab-case y descriptiva: vitest-writer, react-a11y-review, arkaia-blog-json. El nombre de la carpeta acaba siendo el identificador visible en logs y menús: si es genérico ("tests", "docs") chocarás con Skills públicas del mismo nombre. Sé específico.

Un consejo temprano: si vas a crear varias Skills, agrúpalas por dominio con prefijos (test-vitest, test-playwright, test-jest) para que el árbol siga siendo legible dentro de un año.

Paso 2: Escribir el SKILL.md con frontmatter YAML

Abre ~/.claude/skills/vitest-writer/SKILL.md y añade el frontmatter YAML. Estas son las claves que Claude Code interpreta:

---
name: vitest-writer
description: Escribe tests unitarios y de integración con Vitest siguiendo el estilo del proyecto (arrange/act/assert, describe anidados, mocks con vi.fn). Incluye plantillas y un script de validación.
when-to-use: Cuando el usuario pida escribir, refactorizar o revisar tests en un proyecto TypeScript/JavaScript que use Vitest. Activa también en "añade cobertura", "escribe pruebas" o si detectas vitest.config.ts en el repo.
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
version: 0.1.0
---

Las cuatro claves críticas:

• name: identificador único de la Skill. Debe coincidir con el nombre de la carpeta para evitar sorpresas. kebab-case, sin espacios.
• description: qué hace la Skill. Es lo que Claude ve al inspeccionar el árbol de Skills disponibles. Escríbela como si vendieras la Skill a un compañero: hazlo específico y concreto.
• when-to-use (a veces documentada como parte de description, aunque muchos equipos la separan): la señal más importante. Aquí describes los triggers: qué palabras, archivos, contexto o intención del usuario deben activar la Skill. Claude lee esto en cada turno y decide si carga el body.
• allowed-tools: lista blanca de herramientas que la Skill puede usar. Si tu Skill solo lee y edita, no le des Bash. El principio de menor privilegio protege ante Skills públicas comprometidas.

La clave version es opcional pero recomendada: te permite iterar sin romper compatibilidad con equipos que dependen de comportamientos concretos. Sigue SemVer.

Paso 3: Escribir el body Markdown con instrucciones detalladas

Debajo del segundo --- del frontmatter viene el body. Aquí sí puedes extenderte: es lo que Claude leerá cuando la Skill se active. Escríbelo pensando en un compañero técnico nuevo al que le explicas tu manera de escribir tests. Estructura recomendada:

# Vitest Writer

Esta Skill te convierte en especialista escribiendo tests con Vitest.

## Principios innegociables

1. **Arrange / Act / Assert**: separa las tres fases con comentarios cuando el test supere 15 líneas.
2. **Un aserto por test**, salvo pruebas de estado agregado.
3. **No mocks globales**: usa `vi.fn()` local dentro de `beforeEach`.
4. **Nombres de test en presente indicativo**: "suma dos enteros positivos", no "debería sumar".
5. **Cobertura crítica primero**: happy path, edge cases (0, negativos, null), y errores.

## Estructura de fichero

Todo fichero de test empieza así:

```typescript
import { describe, expect, it, beforeEach, vi } from "vitest";
import { SUT } from "./sut";

describe("SUT", () => {
  beforeEach(() => { vi.restoreAllMocks(); });

  describe("nombre-del-método", () => {
    it("caso feliz", () => { /* ... */ });
    it("edge case relevante", () => { /* ... */ });
  });
});
```

## Plantillas disponibles

- `templates/unit.test.ts`: prueba unitaria de función pura.
- `templates/component.test.tsx`: prueba de componente React con Testing Library.
- `templates/integration.test.ts`: prueba de integración con MSW.

Copia la plantilla que corresponda antes de escribir.

## Validación

Antes de terminar la tarea, ejecuta `scripts/validate-tests.sh `
que comprueba que el fichero tiene describe, at least un it y un expect.

Fíjate en el tono: imperativo, específico, sin ambigüedad. Las Skills que funcionan mejor son las que no dejan margen a la interpretación. Si en tu equipo hay una regla no escrita ("nunca usamos any", "todos los ficheros terminan con newline"), escríbela en la Skill. El modelo la respetará porque forma parte de su prompt en ese turno.

Paso 4: Añadir un helper script

Los helper scripts son código ejecutable que Claude puede invocar desde la Skill. No es obligatorio, pero eleva la Skill de "instrucciones" a "herramienta". Crea ~/.claude/skills/vitest-writer/scripts/validate-tests.sh:

#!/usr/bin/env bash
set -euo pipefail

file="${1:-}"
if [[ -z "$file" || ! -f "$file" ]]; then
  echo "Uso: validate-tests.sh " >&2
  exit 2
fi

grep -q "describe(" "$file" || { echo "FALLO: falta describe()" >&2; exit 1; }
grep -q "it("       "$file" || { echo "FALLO: falta it()"       >&2; exit 1; }
grep -q "expect("   "$file" || { echo "FALLO: falta expect()"   >&2; exit 1; }

echo "OK: $file contiene la estructura mínima de Vitest"

Márcalo ejecutable: chmod +x ~/.claude/skills/vitest-writer/scripts/validate-tests.sh. Ahora en el body del SKILL.md puedes referenciar la ruta relativa (Claude Code resuelve automáticamente contra el directorio de la Skill) y el modelo lo ejecutará con la tool Bash cuando toque validar. Es una técnica extremadamente potente: cualquier Skill puede exponer utilidades deterministas escritas por ti, no reglas negociables por el LLM.

Buenas prácticas para scripts helper: siempre set -euo pipefail en bash, código de salida 0 para éxito y otro para fallo, mensajes de error claros a stderr, sin dependencias externas exóticas (o documéntalas en el body del SKILL.md).

Paso 5: Añadir assets (plantillas y ejemplos)

Las plantillas son gold: le ahorran al modelo pensar el andamiaje y le dejan concentrarse en el contenido específico. Crea ~/.claude/skills/vitest-writer/templates/unit.test.ts:

import { describe, expect, it, beforeEach, vi } from "vitest";
import { NOMBRE_FUNCION } from "./NOMBRE_MODULO";

describe("NOMBRE_FUNCION", () => {
  beforeEach(() => {
    vi.restoreAllMocks();
  });

  it("devuelve el valor esperado en caso feliz", () => {
    // Arrange
    const input = /* ... */;

    // Act
    const output = NOMBRE_FUNCION(input);

    // Assert
    expect(output).toBe(/* ... */);
  });

  it("lanza cuando el input es inválido", () => {
    expect(() => NOMBRE_FUNCION(null as any)).toThrow(/inválido/);
  });
});

Y un segundo asset para componentes React: templates/component.test.tsx con la equivalente basada en Testing Library. Nombra las variables como placeholders (NOMBRE_FUNCION, NOMBRE_MODULO) para que sea obvio qué sustituir. Cuanto más detalladas las plantillas, menos tokens gasta Claude escribiendo boilerplate.

Extra útil: una carpeta references/ con Markdown ampliado (por ejemplo references/matchers.md con todos los matchers avanzados de Vitest). El body del SKILL.md menciona su existencia y Claude decide leerla solo si la tarea lo requiere. Es la manera de tener información profunda sin cargarla siempre.

Paso 6: Reiniciar Claude Code y verificar carga

Las Skills se descubren al arrancar la sesión. Cierra Claude Code con /exit y vuelve a lanzarlo. Al iniciarse escaneará ~/.claude/skills/ y ./.claude/skills/ del proyecto actual. Comprueba que tu Skill figura ejecutando en el prompt:

/skills

Deberías ver vitest-writer en la lista con su descripción resumida. Si no aparece, verifica tres cosas: nombre de la carpeta correcto, frontmatter YAML válido (sin tabs, con guiones dobles alrededor), y permisos de lectura sobre el directorio. Un YAML malformado suele romper la carga silenciosamente; valida con yamllint SKILL.md o pasando el fichero por python -c "import yaml,sys; yaml.safe_load(open('SKILL.md').read().split('---')[1])".

Si tienes varias Skills instaladas y no sabes cuál se activará, usa /skills --verbose (o el flag equivalente de tu versión): muestra la descripción completa y el criterio de activación. Es imprescindible cuando empiezas a acumular más de diez.

Paso 7: Probar la Skill delegando una tarea que la matchea

Ahora la prueba de fuego. Pide a Claude Code una tarea que active la Skill:

Escribe tests unitarios con Vitest para la función parseCurrency
que está en src/utils/currency.ts.

Si el frontmatter está bien redactado, Claude reconocerá que la tarea encaja con when-to-use y cargará el body. En los logs internos verás una línea del tipo <skill-loaded name="vitest-writer"> (dependerá de tu versión: algunas la muestran en /log, otras solo en modo verbose). El resultado: Claude escribe los tests siguiendo tu plantilla, aplica los principios innegociables y ejecuta scripts/validate-tests.sh al terminar para confirmar la estructura.

Ahora prueba una tarea que no debería activarla:

Refactoriza el componente  para usar Zustand en lugar de Context.

La Skill no debe cargarse, y no debes ver ninguna referencia a Vitest. Si se carga cuando no toca, tu when-to-use es demasiado amplio: refínalo. Si no se carga cuando sí toca (petición explícita de tests), es demasiado estrecho: enriquécelo con sinónimos y contexto.

Paso 8: Iterar y ajustar el frontmatter

La primera versión de una Skill casi nunca es la definitiva. Vas a iterar sobre tres ejes:

1. Precisión del when-to-use: es la parte que más se ajusta. Añade sinónimos ("añade cobertura", "escribe pruebas", "comprueba comportamiento"), señales de repo ("si existe vitest.config.ts") y anti-patrones ("NO activar si el proyecto usa Jest o Playwright").
2. Concisión del body: cada línea del body cuesta tokens cuando la Skill se carga. Elimina duplicaciones, mueve detalles a references/ si son poco frecuentes.
3. Robustez del script: haz que el helper falle rápido y con mensaje claro. Un script que devuelve exit 0 con warning es peor que uno que falla fuerte.

Truco de iteración rápida: durante desarrollo, activa un modo verbose que registre cuándo se carga la Skill y con qué motivo. Muchos equipos añaden una línea al body: "cuando te actives, imprime al principio 'skill vitest-writer activa'". Es feo pero delata regressions.

Paso 9: Publicar la Skill en tu equipo

Cuando la Skill esté madura, muévela del scope de usuario al del proyecto para compartirla:

cd /ruta/a/tu/repo
mkdir -p .claude/skills
cp -r ~/.claude/skills/vitest-writer .claude/skills/

git add .claude/skills/vitest-writer
git commit -m "feat(claude): añadir Skill vitest-writer para tests estandarizados"
git push

Cualquier compañero que clone el repo verá la Skill activa la próxima vez que arranque Claude Code en ese directorio, sin ningún paso manual. Es la vía canónica para codificar cultura de equipo: las convenciones dejan de vivir en una wiki que nadie consulta y pasan a aplicarse automáticamente cuando alguien pide ayuda al asistente.

Buenas prácticas de gobernanza: revisa las Skills en pull request como cualquier otro código, especialmente el frontmatter y los helper scripts (son código ejecutable con acceso al repo). Firma commits con GPG si tu equipo lo exige. Añade un CODEOWNERS para .claude/skills/ si la organización necesita gatekeepers. Y documenta la lista de Skills activas en el README del proyecto para que un dev nuevo entienda por qué el asistente se comporta de cierta manera.

Ejemplo completo de SKILL.md

Para dejarlo todo en un solo lugar, este es el SKILL.md final consolidado que puedes copiar y adaptar:

---
name: vitest-writer
description: Escribe tests con Vitest siguiendo el estilo del proyecto (AAA, describe anidados, mocks locales con vi.fn) y valida la estructura al terminar.
when-to-use: |
  Cuando el usuario pida escribir, refactorizar o revisar tests en un
  proyecto TypeScript o JavaScript que use Vitest. Activa también en
  "añade cobertura", "escribe pruebas", "comprueba comportamiento"
  o si detectas vitest.config.ts o vitest.config.js en la raíz.
  NO activar si el proyecto usa Jest, Mocha o Playwright.
allowed-tools: [Read, Write, Edit, Bash]
version: 0.1.0
---

# Vitest Writer

Especialista en tests con Vitest.

## Principios innegociables

1. Arrange / Act / Assert con comentarios si el test pasa de 15 líneas.
2. Un aserto por test salvo pruebas de estado agregado.
3. Mocks locales con `vi.fn()` dentro de `beforeEach`. Nada global.
4. Nombres de test en presente indicativo ("suma dos enteros positivos").
5. Cobertura: happy path, edge cases (0, negativos, null), errores.

## Antes de empezar

- Copia la plantilla de `templates/unit.test.ts` o
  `templates/component.test.tsx` según corresponda.
- Sustituye `NOMBRE_FUNCION` y `NOMBRE_MODULO` por los valores reales.

## Al terminar

- Ejecuta `bash scripts/validate-tests.sh ` para
  verificar que el test tiene la estructura mínima.
- Si el script falla, corrige antes de dar la tarea por completada.

## Referencias

- Matchers avanzados y snapshots: `references/matchers.md`.
- Setup de Testing Library: `references/testing-library.md`.

Cabe en menos de 30 líneas y contiene toda la información crítica. Ese es el volumen sano de un SKILL.md: si se te va a 300 líneas, probablemente estás mezclando dos Skills en una.

Skills públicas útiles del repo anthropics/skills

Anthropic mantiene el repositorio público github.com/anthropics/skills con Skills oficiales que puedes clonar directamente. Algunas que merece la pena instalar de partida:

• deep-research: convierte a Claude en un investigador con fan-out de búsquedas web, verificación adversarial de fuentes y síntesis con citas. Perfecta cuando pides informes técnicos.
• verify: fuerza a Claude a verificar que un cambio de código realmente funciona corriéndolo end-to-end, no solo revisando tests o typecheck. Debería ser obligatoria en todo repo serio.
• code-review: revisor sistemático que aplica un checklist configurable de bugs de corrección y limpieza. Se combina con --fix para aplicar automáticamente.
• simplify: pasada de calidad sobre el diff (reuso, simplificación, eficiencia). No busca bugs; para eso usa code-review.
• artifact-design: guía de diseño para cuando estás creando Artifacts (páginas HTML compartibles) para que salgan visualmente coherentes.
• dataviz: recetas y validador de paleta para producir gráficos y dashboards accesibles con matplotlib, plotly, D3 o Recharts.

Instalación típica: git clone https://github.com/anthropics/skills ~/anthropic-skills y enlaza las que quieras con ln -s ~/anthropic-skills/verify ~/.claude/skills/verify. Así conservas la posibilidad de git pull para actualizarlas. Otra alternativa es copiarlas al repo del proyecto si quieres versionarlas con tu código.

Errores comunes y troubleshooting

Estos son los tropiezos habituales cuando empiezas a crear Skills:

• La Skill no aparece en /skills: frontmatter YAML malformado. Comprueba con un linter. Errores típicos: tabs en lugar de espacios, comillas mal cerradas, guiones dobles fuera de sitio.
• La Skill se activa siempre, incluso cuando no toca: when-to-use demasiado genérico. Añade condiciones negativas explícitas ("NO activar si...").
• La Skill nunca se activa aunque la tarea encaja: descripción demasiado técnica. Piensa en las palabras que usaría un usuario, no el vocabulario interno.
• El helper script no se encuentra: rutas relativas mal escritas. Usa siempre scripts/nombre.sh desde el body, nunca rutas absolutas del sistema de un solo dev.
• Colisión de nombres entre Skill de usuario y de proyecto: gana la de proyecto. Si quieres el comportamiento inverso, renombra la de proyecto o borra la de usuario.
• Explosión de contexto: body enorme cargado en cada activación. Mueve detalles a references/ y menciónalos en el body como "consulta X.md si necesitas Y".
• La Skill queda obsoleta: versiona el frontmatter, añade fecha en el body y monta un recordatorio trimestral para revisar Skills críticas.

Material recomendado para trabajar con Claude Code Skills

Estos productos elevan el flujo de trabajo alrededor de Claude Code y de la escritura de Skills. Todos con enlaces afiliados Amazon (tag webmasteroson-21):

• Monitor BenQ RD280U: 4K con modo Coding y proporción 3:2 pensada para leer código y ficheros Markdown largos como los SKILL.md. Ver precio actual en Amazon.
• Monitor LG 29WP60G-B ultrawide: 29" ultrapanorámico ideal para tener el editor, la terminal con Claude Code y la documentación en paralelo. Ver precio actual en Amazon.
• Teclado Logitech MX Keys: teclas silenciosas y retroiluminadas, imprescindible cuando pasas horas iterando el frontmatter de una Skill. Ver precio actual en Amazon.
• Ratón Logitech MX Master 3S: scroll ultrarrápido para revisar diffs largos y tres dispositivos emparejables. Ver precio actual en Amazon.
• Webcam Logitech Brio: 4K nítida para hacer pair programming remoto enseñando cómo escribiste una Skill. Ver precio actual en Amazon.
• Silla Secretlab Titan Evo: soporte lumbar magnético y densidad de espuma pensada para jornadas largas escribiendo instrucciones detalladas. Ver precio actual en Amazon.
• Libro Aprende Claude Code CLI: manual actualizado que cubre CLI, hooks, subagentes y Skills. Complemento perfecto para este tutorial. Ver precio actual en Amazon.

Conclusión

Las Claude Code Skills convierten cualquier workflow repetido en un artefacto compartible, versionable y cargado bajo demanda. Con lo que has aprendido puedes: eliminar prompts pegados a mano, codificar cultura de equipo en el repo, dar a cada tipo de tarea el especialista adecuado sin saturar el contexto principal y beneficiarte del ecosistema público de anthropics/skills. Todo con un archivo Markdown y opcionalmente un puñado de scripts bash.

Próximos pasos naturales: crea Skills para las tres tareas que más repites en tu día ("escribir tests", "revisar PR", "generar migración de DB"), publícalas en el repo de tu equipo, mide antes/después la calidad de las respuestas de Claude y, cuando domines el patrón, contribuye al repo público. Si quieres seguir profundizando en agentes autónomos, mira el tutorial de Cursor Background Agents y la guía de Managed Agents.

Preguntas frecuentes