Cómo convertir un agente de IA en una herramienta especializada usando skills

20 de Agosto del 202611 minIA, Agentes, Skills, Productividad, Claude Code, Codex, DevOps

Respuesta corta (60 segundos): Un agente generalista es una navaja suiza: sabe hacer de todo pero no domina ningún flujo en serio. Especializarlo es codificar un procedimiento concreto (auditar SEO, migrar una base de datos, escribir commits convencionales) en una skill que el agente carga automáticamente cuando la tarea coincide. El proceso tiene seis pasos: 1) definí el flujo a especializar, 2) seleccioná entre una skill de terceros o una propia, 3) revisá permisos y procedencia antes de instalar, 4) instalá y versionala en tu repo, 5) probala en un entorno aislado y 6) mantené el conjunto: combiná habilidades que se complementen y podá lo que ya no usás. Al final, el mismo agente de siempre se comporta como una herramienta dedicada — sin cambiar de modelo ni de plataforma.

En el post anterior vimos qué es una skill y cómo auditar una antes de instalarla. Quedé en que la parte difícil no es entender el concepto, sino llevarlo a la práctica: cómo pasás de "tengo un agente que hace de todo" a "tengo una herramienta especializada que hace mi flujo bien, sin que yo tenga que explicarle nada cada vez". Eso es exactamente lo que cubre este post.

La navaja suiza vs el destornillador especializado

Pensá en tu agente generalista como una navaja suiza. Te saca de apuros en cualquier momento, pero si el 80% de tu uso es un solo movimiento —digamos, destornillar—, cargar una navaja que además tiene sierra, tijera y sacacorchos es puro ruido.

Especializar el agente es fabricar el destornillador: mismo metal, misma mano, pero con una sola función, hecha exactamente a la medida de tu tarea y sin que tengas que pensarla. La navaja no se tira — se guarda para cuando la necesitás. La skill tampoco reemplaza al agente: lo equipa para un flujo puntual.

La consecuencia práctica es enorme. Hoy, sin skills, cada vez que querés que tu agente audite el blog tenés que:

1. Explicarle qué es una auditoría SEO para vos.
2. Dictarle el orden de los pasos.
3. Corregirlo cuando se saltea uno.
4. Repetir todo en el próximo chat, porque no guarda nada entre sesiones.

Con una skill, esa explicación de 40 líneas vive una sola vez en SKILL.md. El agente la lee cuando corresponde, la aplica siempre igual y vos solo decís "auditá el blog". Ese es el salto de generalista a herramienta especializada.

Paso 1 — Definir el flujo a especializar

Antes de tocar nada, respondé dos preguntas:

• ¿Qué repito una y otra vez? Buscá el flujo que hacés por lo menos una vez por semana y que hoy requiere pegar el mismo prompt largo cada vez.
• ¿Es genérico o específico? Auditar SEO, revisar un PR o hacer una migración estándar son flujos que cualquiera conoce bien. Un convenio de tu empresa, tu style guide o el orden de deploy a producción son específicos de vos.

Una forma práctica de detectarlo: la próxima vez que pegues un prompt largo que ya pegaste antes, ese es un candidato. Si ese prompt describe un procedimiento que se repite igual, convertilo en skill.

Paso 2 — Seleccionar: instalar o crear

Dos rutas, según lo que respondiste arriba.

Instalá de terceros cuando…

• El flujo es genérico y bien documentado (SEO, tests, migraciones, linting).
• Viene de un autor o registry curado que podés verificar.
• No necesitás que conozca detalles de tu repo o tu negocio.

Ventaja: lo desarrolla y mantiene otra gente. Riesgo: heredás su superficie de ataque — por eso siempre sigue el paso 3.

Creá la tuya cuando…

• El procedimiento es específico de tu repo, tu equipo o tu negocio.
• Lo repetís bastante como para que valga la pena escribirlo una vez.
• Tenés un checklist o un manual que ya usás y que podés volcar a SKILL.md.

Ventaja: se adapta exactamente a tu flujo y solo toca tus archivos. Costo: sos responsable de mantenerla.

La regla de pulgar, en una línea: genérico y verificado, de terceros; propio y recurrente, tuyo. Cuando estás en el borde, empezá por instalar y probar una de terceros: te da el patrón y el resultado sin invertir en crear la tuya.

Paso 3 — Revisar permisos y procedencia (siempre)

Este paso no se saltea ni siquiera para skills propias (las tuyas también evolucionan y agregás código con el tiempo). El checklist de cuatro puntos, aplicado de forma práctica:

Un truco concreto que uso: mirá el diff de instalación, no solo el README. Antes de mergear la skill, abrí los archivos que trae y leé el código que ejecuta — no la descripción. La descripción te dice lo que el autor quiere que creas; el código te dice lo que realmente hace. Si una skill "de SEO" trae un scripts/fetch.js que llama a un host raro, eso se ve en el diff antes que en el README.

Paso 4 — Instalar y versionar

Cada agente tiene su carpeta de skills, pero el patrón es idéntico:

Para una skill de terceros, copiás el directorio a esa carpeta:

~

# Ejemplo: instalar una skill de auditoría SEO en Claude Code
# Desde un registry curado o un repo, copiás la carpeta de la skill:
mkdir -p .claude/skills/seo-audit
cp -r ~/descargas/seo-audit/* .claude/skills/seo-audit/

# Revisás qué estás a punto de commitear
git add .claude/skills/seo-audit/
git diff --cached --stat

# La versionás como cualquier dependencia
git commit -m "feat(skills): instalar skill de auditoría SEO"

Aunque la skill sea de terceros, versionala en tu repo. Eso te da tres cosas gratis: un diff revisable de lo que instalaste, una copia estable que no se rompe si el origen desaparece, y la posibilidad de hacerle ajustes locales con un PR. Un detalle que vale la pena: si la instalás del registry oficial del agente, solés poder anotar la versión en un archivo de manifiesto; si la copiás a mano, registrá el origen y la versión en un README o un comentario del commit.

Paso 5 — Probar todo lo que puedas, en aislado

Instalar no es terminar; es empezar. Probar una skill significa confirmar tres cosas:

1. Que se carga — el agente detecta la tarea y activa la skill.
2. Que sigue el procedimiento — hace los pasos en orden y con el detalle esperado.
3. Que no hace de más — no toca archivos ni hace llamadas que no debería.

La forma más segura de probar es en un entorno aislado: un worktree, una rama aparte o un directorio de prueba donde una falla no rompa nada. Un caso mínimo del flujo real — no el flujo completo, sino un recorte representativo.

~

# Probar en un worktree aislado, no en tu repo principal
git worktree add ../prueba-skill -b test/skill-seo-audit

# En ese worktree, corrés el prompt de activación:
# "Auditá el SEO de la página /blog/mi-post/"

# Y verificás en el razonamiento del agente que:
# 1. Cargó la skill (lo menciona al arrancar)
# 2. Siguió el orden de pasos de SKILL.md
# 3. El output coincide con lo que la skill promete

Mi pregunta favorita para validar que la skill se cargó no es "¿funcionó?" sino "¿qué skill estás usando y por qué?". Un agente que cargó bien la skill te dice el nombre y los pasos que sigue. Si te da una respuesta genérica sin mencionar el procedimiento de la skill, probablemente la ignoró y está improvisando — y entonces el problema no es la skill sino su descripción (ver abajo, paso 6).

También probá el caso de rechazo: pedile algo que claramente NO es del dominio de la skill. Si la carga de todas formas o se comporta raro, la descripción está demasiado amplia y confunde al agente.

Paso 6 — Combinar y mantener el conjunto

Combinar habilidades

Un flujo real rara vez es un solo dominio. "Publicar un post" puede implicar auditoría SEO, distribución en redes y chequeo de accesibilidad. Ahí entran varias skills, y funcionan bien siempre que cada una acote su descripción para que el agente decida cuál cargar y en qué orden.

El patrón es composición, no competencia: una skill define el flujo general y otras aportan subprocedimientos reutilizables. Las contradicciones entre skills son raras si cada description es precisa y no se pisan entre sí. Si dos skills reclaman el mismo territorio con instrucciones opuestas, el agente se confunde — en ese caso separá responsabilidades o fusioná las dos en una.

Mantener el conjunto

Las skills no son "instalá y olvidate". Son dependencias, y se mantienen como tal:

• Llevá una lista explícita — qué skills tenés, de dónde salieron, en qué versión. Un README o un manifiesto en tu repo alcanza.
• Actualizá de a una, revisando el diff — nunca actualices el conjunto completo a ciegas; cada actualización es una revisión de permisos y procedencia de nuevo.
• Podá lo que no usás — una skill instalada y olvidada es superficie de ataque muerta y ruido para el agente. Si hace tres meses que no la cargás, borrala; git la conserva si la necesitás después.
• Revisá las descripciones — si el agente no la carga cuando debería, la description no coincide con cómo pedís la tarea. Afinar la descripción suele arreglar la activación sin tocar el procedimiento.

~

# Mantenimiento: un manifiesto mínimo en tu repo
.skills/MANIFEST.md  (o docs/skills.md)

# Formato sugerido — tabla simple:
# | Skill | Origen | Versión | Último uso | Nota |
# | seo-audit | github.com/autor/seo-audit | v2.1 | weekly | en uso |
# | pr-review | propia | local | daily | style-guide interno |
# | migracion-db | github.com/autor/migrate | v0.9 | nunca | PODAR |

Un ciclo trimestral de poda es suficiente para la mayoría de los repos: listar, marcar las que no se usaron, decidir entre actualizar, ajustar o borrar.

El resultado

Después de los seis pasos, el mismo agente que "sabe hacer de todo" se siente como otra cosa: le pedís "auditá el blog" y ejecuta tu procedimiento completo, en el mismo orden, sin que expliques nada. Los pasos son:

1. Definí el flujo que repetís.
2. Seleccioná entre skill de terceros o propia.
3. Revisá permisos y procedencia en el diff, no en el README.
4. Instalá y versionala en tu repo.
5. Probala en aislado — carga, procedimiento y "no hace de más".
6. Combiná y mantené — composición limpia y poda periódica.

No necesitás otro modelo ni otra plataforma. Necesitás codificar el procedimiento que ya sabés hacer en una skill, y dejar que el agente la cargue cuando le toca.

Sources and verified data:

• Claude Code skills documentation (Anthropic, 2026) — formato de SKILL.md, carpeta .claude/skills/ y carga bajo demanda.
• Codex CLI skills reference (OpenAI, 2026) — patrón equivalente en el ecosistema OpenAI y .codex/skills/.
• Pi coding agent skills format — spec del frontmatter name + description y carpetas .pi/skills/ / .agents/skills/.
• Git worktrees para agentes de programación (Carlos.lat, 2026) — flujo para probar skills en un entorno aislado sin romper el repo principal.
• Qué son las skills de un agente de IA (Carlos.lat, 2026) — checklist completo de permisos y procedencia que se referencia en el paso 3.
• OWASP Top 10 for LLM Applications (2025) — framework para evaluar superficie de ataque en herramientas de agentes.