Cuando usás Claude Code todos los días, empezás a notar un patrón. Le pedís un code review el lunes y te da un análisis detallado. El martes lo mismo y te lista tres bullets genéricos. Mismo modelo, mismo pedido, resultado completamente distinto.
No es que esté mal. Es un modelo que predice tokens, no una máquina exacta. Cada vez que lo usás, empieza de 0. Sin memoria de cómo lo hizo antes. Sin contexto de cómo trabajás vos.
¿Y si hubiera una forma de enseñarle? ¿De escribir una vez cómo querés que trabaje y que lo aplique siempre?
Eso son las Skills.
Estuve semanas experimentando con ellas, rompiendo cosas, descartando lo que no funcionaba. Por eso escribí este artículo. No busco resumirte la documentación, sino contarte todo lo que aprendí. Al final, vas a entender qué son, cómo funcionan por dentro y vas a poder crear la tuya desde cero.
Empecemos.
Una Skill son instrucciones.
Le explicás a Claude cómo querés que haga una tarea: qué revisar primero, qué ignorar, qué formato usar. La próxima vez que le pedís esa tarea, la hace exactamente como vos le indicaste.
Pensalo así: un chef sabe cocinar. Tiene técnica, criterio, años de experiencia. Pero si entra a trabajar a tu restaurante sin conocer tus recetas, va a cocinar bien, pero a su manera. No es que sea malo, sino que nadie le explicó cómo trabajás vos.
Una Skill es la receta. No le enseñás a cocinar, eso ya lo sabe. Le explicás cómo querés que cocine.
flowchart LR
A["🧑🍳\n**EL CHEF**\nClaude\n\nTécnica, criterio y años de\nexperiencia. Sabe cocinar muy bien."]
B["📖\n**LA RECETA**\nLa Skill\n\nCómo querés que cocine en tu\nrestaurante, con tus ingredientes."]
C["✓\n**EL RESULTADO**\nA tu manera\n\nCocina bien y exactamente como vos\nle indicaste. Siempre."]
A -->|+| B --> C
Ejemplo concreto: una Skill de code review.
En el archivo le explicás que primero revise la legibilidad, después la complejidad, después la performance. Que las funciones de más de 20 líneas hay que refactorizar. Que siempre termine con un resumen ordenado por impacto. Todo eso, escrito una vez.
Ejemplo concreto: una Skill de code review.
En el archivo le explicás que primero revise la legibilidad, después la complejidad, después la performance. Que las funciones de más de 20 líneas hay que refactorizar. Que siempre termine con un resumen ordenado por impacto. Todo eso, escrito una vez.
Ahora cada vez que le pedís un code review, sigue esas indicaciones. Sin que vos se las repitas. Sin que tengas que aclarar nada. Claude trabaja como vos querés, no como le parece a él.
Y esa es la ventaja real de las Skills: dejás de repetirte.
block-beta
columns 2
block:sinSkill:1
S["SIN SKILL"]
SLUN["**LUNES**\nVos: 'revisá este PR'\n\nAnálisis detallado de 8 puntos con ejemplos de código, ordenado por impacto..."]
SMAR["**MARTES**\nVos: 'revisá este PR'\n\n• Mejorar nombres de variables\n• Agregar manejo de errores\n• Considerar performance"]
SJUE["**JUEVES**\nVos: 'revisá este PR'\n\nEl código se ve bien en general. Algunos comentarios menores sobre el estilo...\n\n⚠ Cada sesión empieza sin contexto. El modelo predice tokens, no recuerda cómo lo hizo antes."]
end
VS["VS"]:1
block:conSkill:1
C["CON SKILL"]
CLUN["**LUNES**\nVos: 'revisá este PR'\n\n1. Legibilidad ✓ 2. Complejidad: función línea 47 supera 20 líneas → refactor sugerido. Resumen por impacto..."]
CMAR["**MARTES**\nVos: 'revisá este PR'\n\n1. Legibilidad ✓ 2. Complejidad: función línea 23 supera 20 líneas → refactor sugerido. Resumen por impacto..."]
CJUE["**JUEVES**\nVos: 'revisá este PR'\n\n1. Legibilidad ✓ 2. Complejidad ✓ 3. Performance: query N+1 detectado. Resumen por impacto...\n\n✓ Las instrucciones están en el archivo. Claude las aplica siempre, sin que las repitas."]
end
Si todavía te suena abstracto, no te preocupes. Vamos a seguir profundizando y va a hacer click.
3 problemas que tiene casi todo el que usa Claude regularmente:
El problema de consistencia. Le pedís un code review el lunes y te da un análisis detallado. El martes lo mismo y te lista tres bullets genéricos. Skills bloquean eso porque Claude sigue las mismas instrucciones cada vez.
El problema de calidad. Claude sabe hacer code review, pero no sabe que vos querés que revise legibilidad antes que performance, o que las funciones de más de 20 líneas son candidatas a refactorizar. Skills le enseñan lo que aprendiste vos.
El problema de eficiencia. Cada vez que abrís una conversación nueva, tenés que volver a explicar todo ese contexto. Tu stack, tus preferencias, tus restricciones. Skills lo recuerdan por vos.
El único archivo obligatorio es el SKILL.md. Tiene 2 partes.
my-skill/
├── SKILL.md OBLIGATORIO # Instrucciones principales
├── template.md # Template para que Claude complete
├── examples/
│ └── sample.md # Output de ejemplo con el formato esperado
└── scripts/
└── validate.sh # Script que Claude puede ejecutar
El frontmatter. Un bloque YAML al inicio del archivo con el nombre y la descripción. El nombre se convierte en el comando que usás para invocarla. La descripción es lo que Claude lee para decidir si activarla o no.
Tenés 2 formas de activarla. La primera es escribiendo /code-review directamente en el chat. La segunda es automática: si tu descripción dice "usá cuando el usuario pida revisar un PR", Claude la activa solo cuando le pedís eso, sin que vos la invoques manualmente.
El body. Las instrucciones en markdown. Acá es donde escribís el workflow, tu expertise, las herramientas a usar y los recursos disponibles.
flowchart LR
subgraph FM["FRONTMATTER"]
A["**A name**\nSe convierte en el comando.\nEscribís /code-review para\ninvocarla manualmente."]
B["**B description**\nClaude la lee para decidir si\nactivarla. Si incluye cuándo usarla,\nse activa automáticamente sin que\nescribas el comando."]
C["**C allowed-tools**\nRestringe qué herramientas puede\nusar Claude. Solo Read, Grep y\nGlob: puede leer, no puede\nmodificar nada."]
end
subgraph BODY["BODY"]
D["**D Sección de instrucciones**\nMarkdown puro. Acá escribís el\nworkflow, las reglas, los criterios.\nClaude lo lee cuando la Skill se\nactiva."]
E["**E Pasos ordenados**\nSin orden explícito, Claude decide\nqué hacer primero. Con pasos\nnumerados, sigue tu secuencia\nexacta."]
end
subgraph CODE["SKILL.md"]
direction TB
F["---\nname: code-review\ndescription: Revisá el código para detectar bugs,\nmejorar legibilidad y performance.\nUsá cuando pidan 'code review'.\nallowed-tools: Read, Grep, Glob\n---\n\n## Proceso\n1. Revisá la legibilidad del código\n2. Identificá complejidad innecesaria\n3. Chequeá performance\n4. Funciones +20 líneas → refactor\n5. Resumen ordenado por impacto"]
end
CODE --- FM
CODE --- BODY
Después del SKILL.md, podés agregar carpetas según lo que necesite la Skill:
references/ para documentación extra que Claude consulta cuando la necesita. Guías de estilo, esquemas, convenciones del equipo.
scripts/ para código que Claude puede ejecutar. Validar un archivo antes de entregarlo, verificar que algo se generó correctamente.
templates/ para archivos base que Claude usa en el output. Tu template de PowerPoint, un archivo HTML de base, tu logo.
Claude no carga todas las Skills de una. Usa un sistema llamado progressive disclosure: carga solo lo que necesita, cuando lo necesita.
Funciona en 3 niveles. Siguiendo el ejemplo de la Skill de code review:
Nivel 1: nombre y descripción. Es lo único que se carga al inicio de cada sesión. Claude escanea todas las descripciones disponibles y decide cuál activar. Ve code-review: Revisá el código para detectar bugs... y lo tiene en cuenta.
Nivel 2: el SKILL.md completo. Le pedís "revisá este PR" y matchea. Recién ahí lee todo el SKILL.md: el workflow, tus reglas, los criterios de refactorización.
Nivel 3: scripts, references y templates. Si tu Skill tiene un script que valida el formato del código, lo carga solo si lo necesita para esa tarea. Si no, no existe.
flowchart LR
subgraph N1["① Nombre + Descripción\nAl inicio de cada sesión"]
direction TB
n1a["• name: code-review"]
n1b["• description: Revisá el código..."]
n1c["~~• ## Proceso~~"]
n1d["~~• scripts/validate.py~~"]
n1e["~~• references/guide.md~~"]
n1f["Solo esto. Claude escanea qué Skills\nexisten y cuándo activarlas."]
end
subgraph N2["② SKILL.md completo\nCuando matchea tu pedido"]
direction TB
n2a["• name: code-review"]
n2b["• description: Revisá el código..."]
n2c["• ## Proceso"]
n2d["• Paso 1, 2, 3, 4, 5..."]
n2e["~~• scripts/validate.py~~"]
n2f["~~• references/guide.md~~"]
n2g["Lee el workflow completo, tus reglas y\ncriterios."]
end
subgraph N3["③ Scripts + References\nSolo si los necesita"]
direction TB
n3a["• name: code-review"]
n3b["• description: Revisá el código..."]
n3c["• ## Proceso"]
n3d["• Paso 1, 2, 3, 4, 5..."]
n3e["• scripts/validate.py"]
n3f["• references/guide.md"]
n3g["Si no se necesitan, no existen. 50 Skills\ninstaladas no afectan el rendimiento."]
end
N1 -->|→| N2 -->|→| N3
WARNING["⚠ Límite práctico: **15.000 caracteres** para la lista completa de Skills. Descripciones cortas y precisas."]
Esto significa que podés tener 50 Skills instaladas con mucho contenido cada una, y nada de eso afecta el rendimiento hasta que se necesita.
Por eso la descripción es lo más importante que escribís. Si es vaga, Claude no sabe cuándo activar la Skill y todo lo que escribiste adentro queda invisible.
Y hay un límite práctico: 15.000 caracteres para la lista completa de Skills. Si tenés muchas con descripciones largas, las últimas pueden quedar fuera. Cortas y precisas.
La señal más clara: si te encontrás escribiendo el mismo contexto en cada conversación, ya tenés una Skill sin escribir.
3 casos concretos donde vale la pena:
Cuando el output depende de contexto que el modelo no tiene. Tu stack, tus convenciones, cómo trabaja tu equipo. Por ejemplo: cada vez que pedís un componente de React, terminás aclarando que usás Tailwind, que los props necesitan defaults, que los estilos van inline. Si lo repetís en cada conversación, es una Skill.
Cuando el resultado tiene que ser consistente. Si le pedís una presentación y a veces arranca con un slide, otras va directo al problema, otras te pregunta qué querés, la razón es que nadie le explicó cómo querés que lo haga.
Cuando el proceso tiene pasos que se olvidan. Querés que en un code review siempre revise seguridad antes de sugerir refactors. Sin una Skill, a veces lo hace, a veces no.
flowchart LR
subgraph REP["SEÑALES DE REPETICIÓN"]
r1["1× 'Tené en cuenta que usamos Tailwind y los\ncomponentes van en /src/components'"]
r2["2× 'Acordate de revisar legibilidad antes que\nperformance, como la vez pasada'"]
r3["3× 'Ya te dije: el resumen siempre va al final,\nordenado por impacto'"]
end
SKILL["SKILL\nCANDIDATA"]
subgraph RESULT["code-review / SKILL.md"]
res1["Stack: React + Tailwind, componentes en /src/components"]
res2["Orden: legibilidad → complejidad → performance"]
res3["Funciones +20 líneas → refactor obligatorio"]
res4["Resumen siempre al final, por impacto"]
res5["✓ Escrito una vez. Aplicado siempre. Sin que lo repitas\nnunca más."]
end
REP -->|→| SKILL -->|→| RESULT
Lo que no tiene sentido: crear una Skill para algo que hacés una vez, o para tareas donde el contexto cambia tanto que instrucciones fijas no ayudan. Una Skill es un marco, no una solución universal.
Anthropic tiene Skills oficiales que podés instalar directamente desde Claude Code. Las encontrás en:
https://github.com/anthropics/skills
Para instalarlas, ejecutás este comando en Claude Code:
/plugin install document-skills@anthropic-agent-skillsDOCX. Crea y edita documentos de Word. Maneja tracked changes, comentarios, tablas e imágenes manteniendo el formato correcto. También extrae texto y analiza el contenido de archivos existentes.
XLSX. Crea spreadsheets con fórmulas, formato y visualizaciones. Lee y analiza datos de archivos existentes, modifica hojas manteniendo las fórmulas intactas y genera gráficos a partir de los datos.
PDF. Extrae texto y tablas, crea nuevos PDFs, mergea y splitea documentos, rota páginas, llena formularios y procesa archivos escaneados con OCR.
PPTX. Crea y edita presentaciones. Genera slides con layouts, tipografías y paletas de colores. También lee y analiza presentaciones existentes.
Frontend Design. Genera interfaces web con criterio de diseño: tipografía, color, composición y jerarquía visual. Produce componentes que se ven trabajados, no genéricos.
Si querés explorar miles de Skills de la comunidad, podés hacerlo desde https://skills.sh. Pero tené cuidado: estas Skills no están verificadas por Anthropic. Una Skill puede incluir scripts que Claude ejecuta directamente en tu entorno. Si instalás una sin revisarla, ese script podría acceder a archivos, hacer requests a servicios externos o ejecutar comandos en tu máquina.
Antes de instalar cualquier Skill de la comunidad, revisá el SKILL.md y los scripts. Si tiene código que no entendés, no la instales.
Las Skills no son solo personales. Las podés compartir con todo tu equipo.
Hay 2 tipos según dónde las guardás:
Skills personales. Van en ~/.claude/skills/ y están disponibles en todos tus proyectos. Son las que creás para tu flujo de trabajo individual, las que experimentás, las que todavía no estás seguro si compartir.
Skills de proyecto. Van en .claude/skills/ dentro del repositorio. Se commitean a git y cuando alguien hace pull, las tiene disponibles automáticamente. Acá van las convenciones del equipo, los workflows compartidos, los scripts que todos usan.
flowchart LR
subgraph PERSONAL["👤 Skills personales\nSolo disponibles para vos. Para experimentar, iterar y flujos individuales."]
direction TB
p1["~/.claude/skills/"]
p2["~/.claude/\n└── skills/\n ├── code-review/\n ├── pr-summary/\n └── deep-research/"]
p3["• Disponible en todos tus proyectos\n• No se commitea a git\n• Ideal para Skills experimentales"]
end
subgraph PROYECTO["👥 Skills de proyecto\nCommiteadas al repo. Cuando alguien hace pull, las tiene disponibles automáticamente."]
direction TB
pr1["mi-proyecto/.claude/skills/"]
pr2["mi-proyecto/ # raíz del repo\n├── package.json\n├── ...\n└── .claude/ # ← acá\n └── skills/\n ├── pr-checklist/\n └── component-gen/"]
pr3["• Commiteada a git, disponible para todos\n• Convenciones compartidas del equipo\n• Mismo criterio para todos los devs"]
end
La ventaja es clara: escribís la Skill una vez y todo el equipo trabaja con el mismo criterio. No más inconsistencias entre lo que genera un dev y otro.
Y hay algo más que vale la pena mencionar: podés restringir qué herramientas puede usar Claude cuando una Skill está activa. Con el campo allowed-tools en el frontmatter, le decís exactamente con qué puede trabajar.
---
name: code-reviewer
description: Revisá el código para detectar bugs y mejorar calidad.
allowed-tools: Read, Grep, Glob
---En este caso, la Skill solo puede leer archivos. No puede modificar nada. Útil cuando querés que el agente analice sin tocar.
Las Skills también se pueden combinar con tools y servidores MCP. Esto las hace mucho más poderosas porque el agente no solo sigue instrucciones, sino que puede interactuar con servicios externos.
flowchart TB
SKILL["📄 SKILL.md\nOrquesta tools según el\nworkflow definido"]
FS["📁 File System\nRead, Write, Glob, Grep\nen el codebase"]
GH["🍴 GitHub MCP\nPRs, Issues, reviews,\nmerge"]
BASH["💻 Bash / Terminal\nScripts, validaciones,\ncomandos del sistema"]
API["🌐 APIs externas\nServicios, webhooks,\nintegraciones"]
FS <-->|↔| SKILL
SKILL <-->|↔| GH
BASH <-->|↔| SKILL
SKILL <-->|↔| API
Por ejemplo, una Skill que automatiza el flujo completo de un PR en GitHub. Le pedís "revisá y mergeá el PR #42" y el agente ejecuta todo:
El agente usa el MCP de GitHub para ejecutar cada paso. Vos solo pedís el resultado.
EJEMPLO — PR FLOW COMPLETO CON GITHUB MCP
---
name: github-pr-flow
description: Revisá, aprobá y mergeá PRs. Usá cuando el usuario quiera revisar o mergear un PR.
allowed-tools: Bash(gh *)
---
## Flujo
1. Fetcheá el diff: `gh pr diff <número>` # ← MCP ejecuta esto
2. Revisá los cambios
3. Si pasan los criterios, aprobá: `gh pr review --approve`
4. Mergeá: `gh pr merge --squash`
5. Confirmá que fue exitosoEsta combinación es donde las Skills se vuelven verdaderamente agénticas. Dejás de pedirle cosas a Claude y empezás a delegarle procesos completos.
El error más común es querer diseñar la Skill perfecta desde el principio. No funciona así. Las mejores que tengo las construí iterando, no planificando.
Paso 1: detectá la repetición. Esta semana, cada vez que le des contexto al agente antes de pedirle algo, anotalo. "Tené en cuenta que usamos Tailwind", "el formato tiene que ser este", "primero validá antes de procesar". Si lo escribiste más de 3 veces, es candidata.
Paso 2: creá la carpeta. Una vez que tenés el caso de uso, creás la carpeta y el archivo:
mkdir ~/.claude/skills/nombre-de-tu-skill
touch ~/.claude/skills/nombre-de-tu-skill/SKILL.mdtambién podés pedirle a Claude que lo haga por vos.
Paso 3: escribí la versión mínima. Solo lo esencial para el caso más común. Una Skill de cinco líneas que funciona bien vale más que una de cien que el agente sigue a medias. Si tu Skill de code review tiene 80 reglas, va a ignorar la mitad.
Paso 4: probala con casos reales. Ejecutá la misma tarea con y sin la Skill. Si el output con Skill es notablemente mejor, vas bien. Si no ves diferencia, las instrucciones son demasiado genéricas.
Paso 5: iterá en base a lo que falla. Cada vez que el agente haga algo que no querías, preguntate si esa corrección debería estar en la Skill. Si le estás diciendo "no, el resumen va al principio" por tercera vez, eso va a la Skill.
Paso 6: usá a Claude para mejorarla. Pegá tu SKILL.md en una conversación y pedile que la revise. Que identifique instrucciones ambiguas, que sugiera ejemplos, que mejore la descripción para que matchee mejor. Claude entiende el formato y puede ayudarte a iterar mucho más rápido que haciéndolo solo.
Y si querés ir un paso más allá, Anthropic tiene una Skill oficial llamada skill-creator que te guía paso a paso en el proceso de crear una Skill desde cero: desde definir el caso de uso hasta escribir el frontmatter y validar las instrucciones. La encontrás en el mismo repositorio que las demás Skills oficiales.
Estas son las que más impacto tienen en la calidad de tus Skills:
Sé conciso. Claude ya es inteligente. No le expliques cosas que ya sabe. Cada línea que escribís compite con el resto del contexto. Si te preguntás "¿realmente necesita saber esto?", probablemente no.
La descripción lo es todo. Escribila en tercera persona, que incluya qué hace la Skill y cuándo activarla. "Procesa archivos Excel" no alcanza. "Analizá spreadsheets, creá pivot tables y generá gráficos. Usá cuando el usuario mencione archivos Excel, datos tabulares o .xlsx" sí.
Mantené el SKILL.md bajo 500 líneas. Si necesitás más, mové el contenido a archivos separados en references/ y referencialos desde el SKILL.md. Un nivel de profundidad, no más.
Usá workflows con pasos claros. Para tareas complejas, definí el orden exacto. Paso 1, paso 2, paso 3. Sin esto, Claude decide solo qué hacer primero.
Implementá loops de validación. Si la Skill genera algo, que valide el output antes de darlo por terminado. Ejecutar → validar → corregir → repetir. Mejora enormemente la calidad.
Dale el nivel de libertad correcto. Si la tarea tiene una sola forma correcta de hacerse, dásela exacta. Si tiene múltiples enfoques válidos, dejale margen. No todo necesita instrucciones estrictas.
Probala con casos reales, no con ejemplos ideales. Una Skill puede funcionar perfecto en teoría y fallar en la práctica. Testear con tareas reales es lo único que revela los gaps.
block-beta
columns 2
block:b01:2
t01["01 La descripción lo es todo\nEscribila en tercera persona. Que incluya qué hace la Skill y cuándo activarla."]
vaga["✗ VAGA\n'Procesa archivos Excel'"]
precisa["✓ PRECISA\n'Analizá spreadsheets, creá pivot tables y generá gráficos. Usá cuando el usuario mencione archivos Excel, datos tabulares o .xlsx'"]
end
block:b02:1
t02["02 Sé conciso\nClaude ya es inteligente. No le expliques cosas que ya sabe. Cada línea que escribís compite con el resto del contexto."]
end
block:b03:1
t03["03 SKILL.md bajo 500 líneas\nSi necesitás más, mové el contenido a references/ y referencialos. Un nivel de profundidad, no más."]
end
block:b04:1
t04["04 Workflows con pasos claros\nPara tareas complejas, definí el orden exacto. Paso 1, paso 2, paso 3. Sin esto, Claude decide solo qué hacer primero."]
end
block:b05:1
t05["05 Loops de validación\nSi la Skill genera algo, que valide el output antes de darlo por terminado. Ejecutar → validar → corregir → repetir."]
end
block:b06:2
t06["06 Probala con casos reales, no con ejemplos ideales\nUna Skill puede funcionar perfecto en teoría y fallar en la práctica. Testear con tareas reales es lo único que revela los gaps. La señal más clara: ¿el output es notablemente mejor que sin la Skill?"]
end
block:b07:2
t07["07 Dale el nivel de libertad correcto\nSi la tarea tiene una sola forma correcta, dásela exacta. Si tiene múltiples enfoques válidos, dejale margen. No todo necesita instrucciones estrictas."]
end
Ejecutá la misma tarea 3 veces. Si cada ejecución parece una conversación distinta, la Skill necesita trabajo.
3 señales de que algo está mal:
El agente ignora instrucciones. Le pediste que valide antes de ejecutar y lo saltea. Generalmente las instrucciones están enterradas o son ambiguas. "Tené en cuenta la seguridad" no es una instrucción, es una sugerencia. "Antes de ejecutar cualquier query, validá que los inputs no contengan caracteres especiales" sí lo es.
La descripción no matchea. La Skill se activa cuando no debería, o no se activa cuando sí debería. Revisá la descripción antes que el body, casi siempre el problema está ahí.
El output es genérico. Se parece a lo que Claude haría sin la Skill. La diferencia entre "hacé un buen code review" y "revisá legibilidad primero, después complejidad, marcá funciones de más de 20 líneas como candidatas a refactorizar, y terminá con un resumen ordenado por impacto" es enorme.
La pregunta después de cada ejecución es una sola: ¿esto es mejor que lo que hubiera producido sin la Skill? Si la respuesta no es clara, hay algo para mejorar.
Dos patrones que vale la pena conocer una vez que tenés experiencia con Skills básicas.
Inyectar contexto dinámico. Con la sintaxis !comando podés ejecutar comandos de shell antes de que Claude vea el contenido de la Skill. El output reemplaza al placeholder, así Claude recibe datos reales, no el comando en sí.
Por ejemplo, una Skill de resumen de PR que fetchea los datos del pull request automáticamente:
flowchart LR
A["SKILL.md incluye\n\`gh pr diff\`"]
B["El comando se ejecuta antes\nde que Claude lo vea"]
C["Claude recibe el diff real,\nno el comando"]
A -->|→| B -->|→| C
SKILL.md — contexto dinámico con !comando
---
name: pr-summary
allowed-tools: Bash(gh *)
---
## Contexto del PR
- Diff: !`gh pr diff` # ← se ejecuta antes, Claude ve el resultado
- Comentarios: !`gh pr view --comments`
- Archivos: !`gh pr diff --name-only`
Resumí este pull request basándote en el contexto de arriba.Cuando la Skill corre, los comandos se ejecutan primero y Claude recibe el prompt ya con los datos adentro. Esto es preprocesamiento, no algo que Claude ejecuta.
Correr una Skill en un subagente. Agregando context: fork al frontmatter, la Skill corre en un contexto aislado. No tiene acceso al historial de la conversación. Útil para tareas de research o análisis que no necesitan contexto previo y que querés que corran de forma independiente.
flowchart LR
subgraph SIN["Sin context: fork"]
H["Historial de la conversación"]
S1["Skill"]
H --> S1
note1["Tiene acceso a todo el contexto previo"]
end
VS["VS"]
subgraph CON["Con context: fork"]
H2["Historial de la conversación\n🔒 bloqueado"]
S2["Skill (aislada)"]
note2["Contexto limpio. Útil para research o análisis independiente."]
end
SKILL.md — subagente con context: fork
---
name: deep-research
context: fork # ← contexto aislado
agent: Explore
---
Investigá $ARGUMENTS en el codebase:
1. Encontrá archivos relevantes
2. Analizá el código
3. Resumí los hallazgos con referencias específicasSkills funcionan muy bien para que Claude trabaje como vos querés. No es fácil diseñarlas, requiere ser preciso en lo que pedís y anticipar casos que no contemplás. Pero es una habilidad que se va entrenando. Una combinación de prompt engineering y testing.
Una vez que hacés click, empezás a notar que hay tareas del día a día que se pueden convertir en Skills. El agente empieza a pensar como vos, a ejecutar las cosas como a vos te gustan.
A mí me sirven mucho para automatizar procesos. La última en la que estuve trabajando mapea todas las requests HTTP a servicios externos y exporta una colección a Postman o Insomnia. Extremadamente útil cuando trabajás en un equipo con más de 10 repositorios.
Podés crear Skills para resolver vulnerabilidades, para que el agente haga research y te resuma un tema a tu manera, para cualquier tarea que repitas y que tenga un proceso claro detrás.
Mi consejo: empezá hoy.
Probá a crear una Skill chica. Que lea un texto que le pasás y te haga un resumen con puntos importantes y que te recomiende temas para seguir profundizando.