De Herramientas a Sistema: Cómo Construir Skills de IA para Tu Flujo de Trabajo

En enero te enseñé las herramientas de IA que uso para diseñar y desarrollar. En febrero te expliqué por qué pierden el hilo a los 30 minutos — tokens, ventanas de contexto, compactación — y cómo solucionarlo con orquestación y memoria persistente.

Pero había un problema que no toqué: la IA empieza cada sesión desde cero.

Da igual que uses Claude Code, Cursor, Copilot o cualquier otro agente. Da igual que trabajes con React, Python, Rails, Go o WordPress. Cada vez que abres una conversación nueva, tu agente no sabe cómo estructuras tu código, qué patrones prefieres, ni qué convenciones lleva tu equipo usando meses. Tiene que redescubrirlo. Y tú tienes que re-explicarlo.

¿Y si tu IA pudiera trabajar como un equipo — con especialistas que conocen tus principios de diseño, dominan tu stack, saben tu voz al escribir, y aplican tus estándares de calidad? No como personas distintas, sino como conocimiento especializado que se activa automáticamente cuando lo necesitas.

Eso es exactamente lo que construí. Se llaman skills. Y lo que voy a explicarte no es qué skills tengo yo — sino cómo construir los tuyos, sin importar tu stack ni tu lenguaje.

El problema: cada sesión empieza de cero

Imagina que cada mañana tu equipo llegara a la oficina sin recordar nada del día anterior. Ni las decisiones de arquitectura, ni los estándares del proyecto, ni las lecciones aprendidas. Eso es lo que pasa cada vez que inicias una nueva conversación con tu agente de IA.

El resultado es predecible:

• Repites instrucciones — "Usa TypeScript estricto", "Sigue la convención de nombrado del proyecto", "No uses esa dependencia, tenemos nuestra propia abstracción"
• Calidad inconsistente — un día genera código impecable, al día siguiente ignora patrones que ya habías establecido
• Pérdida de contexto — las decisiones que tomaste en sesiones anteriores no existen para el agente
• Feedback genérico — pides una revisión de código y obtienes "se ve bien" en vez de análisis contra tus estándares concretos

Este problema no es de un agente específico. Es estructural. Los modelos de lenguaje no tienen memoria entre sesiones. Y aunque algunas herramientas guardan historial, no es lo mismo que conocimiento organizado y activable.

La solución obvia — copiar y pegar un bloque de instrucciones al principio de cada sesión — funciona pero no escala. Cuando tienes 5 principios es manejable. Cuando tienes 50, repartidos entre diseño, desarrollo, contenido y procesos, se vuelve insostenible. Necesitas algo que se active solo, en el momento correcto, sin que tú hagas nada.

Qué es un skill (y por qué no es un prompt)

Un skill es un archivo Markdown — SKILL.md — que contiene instrucciones especializadas, principios, procesos y ejemplos. Vive en tu proyecto o en tu configuración global, y tu agente lo carga automáticamente cuando detecta que tu tarea coincide con los triggers del skill.

La diferencia con un prompt es fundamental:

• Un prompt es una instrucción que escribes cada vez: "Revisa este código siguiendo principios SOLID, con tests unitarios y documentación."
• Un skill se activa solo. Cuando dices "revisa este módulo", el agente detecta que es una tarea de code review y carga el skill correspondiente. No tienes que recordar qué pedir.

La estructura básica es simple:

---
name: code-review
description: Se activa cuando el usuario pide revisar código,
  hacer PR review, o auditar calidad. Triggers: "revisa",
  "review", "audita", "code quality".
---

## Principios
- Legibilidad sobre cleverness
- Cada función hace una sola cosa
- Tests cubren los happy paths y los edge cases

## Proceso
1. Lee el código completo antes de comentar
2. Identifica problemas de arquitectura (los más caros)
3. Revisa naming, tipos y contratos
4. Verifica manejo de errores
5. Sugiere tests si no existen

## Ejemplos
- Bueno: función de 15 líneas con nombre descriptivo y tipos explícitos
- Malo: función de 200 líneas llamada `handleStuff` con `any` en los parámetros

El description es la clave. El agente lo lee y decide si activar el skill según tu tarea. Un buen description con triggers precisos significa que el conocimiento correcto se aplica en el momento correcto, sin que tú intervengas.

Lo interesante de este sistema es que cualquier desarrollador puede construirlo. No importa si trabajas con React, Django, Laravel, Spring Boot o scripts de Bash. Si tienes principios que aplicas repetidamente, puedes convertirlos en un skill.

Tipos de skills que puedes construir

Después de meses construyendo y refinando skills, he identificado cinco categorías que cubren la mayoría de las necesidades. No te las cuento para que copies las mías — sino para que pienses en qué categorías necesitas tú.

Skills de proceso

Son los que definen cómo trabajas. Debugging, TDD, code review, planificación de features, refactoring. No dependen de ningún framework específico — son universales.

Un skill de debugging, por ejemplo, puede codificar tu proceso mental: "Primero reproduce el bug de forma consistente. Luego aísla la variable. Después formula una hipótesis y diseña un experimento para validarla." Suena básico, pero la diferencia entre pedirle eso al agente cada vez y que lo haga automáticamente es enorme.

Otro ejemplo universal: un skill de planificación de features. Antes de escribir código, el agente desglosa la feature en tareas con dependencias, identifica riesgos, define criterios de aceptación y propone un orden de implementación. No porque sea inteligente — sino porque le diste las instrucciones exactas que tú seguirías.

Skills de dominio

Estos sí son específicos de tu stack y tu proyecto. Tu framework, tu sistema de diseño, tus patrones de arquitectura, las convenciones de tu equipo.

Yo tengo skills para mi stack particular. Tú tendrías los tuyos: patrones de Django si trabajas con Python, convenciones de Spring si usas Java, guías de estilo de tu equipo si trabajas en empresa. El punto no es qué framework — es que tus estándares dejan de ser conocimiento tácito y se convierten en instrucciones ejecutables.

Skills de contenido

Escribir bien no es talento misterioso. Es proceso. Un skill de copywriting puede codificar principios como "claridad sobre creatividad" y "beneficios sobre features". Un skill de edición puede aplicar pasadas secuenciales — primero claridad, luego voz, luego relevancia, luego evidencia.

Lo más valioso: cada vez que escribes con el skill activo y corriges el resultado, estás refinando el proceso. Los skills mejoran con el uso porque tú los actualizas cuando encuentran un caso que no cubren.

Skills de crecimiento

SEO técnico, optimización para buscadores con IA, psicología de conversión, optimización de formularios. Son skills que aplican frameworks de análisis probados — no opiniones vagas, sino checklists estructuradas con criterios medibles.

Un skill de SEO técnico, por ejemplo, puede revisar una página en cinco capas ordenadas por prioridad: crawlability, fundamentos técnicos, optimización on-page, calidad de contenido y autoridad. Cada capa tiene criterios específicos y genera recomendaciones accionables. Lo que antes requerías de una auditoría manual de 4 horas, el agente lo ejecuta en minutos — pero con tus criterios, no con un checklist genérico de internet.

Skills meta

La capa más interesante: skills que crean otros skills, que buscan skills relevantes para una tarea, o que orquestan flujos complejos combinando múltiples skills. Aquí es donde el sistema se vuelve recursivo y empieza a escalar de verdad.

Un skill-creator, por ejemplo, te guía para crear nuevos skills: captura la intención, estructura el SKILL.md con triggers precisos, y define un framework de evaluación para medir si el skill mejora los resultados. Otro skill puede funcionar como buscador — le dices "necesito optimizar un formulario de registro" y te sugiere skills de CRO, UX de formularios y onboarding que quizás no hubieras asociado con esa tarea.

Antes y después: cómo cambia el trabajo

La teoría suena bien, pero ¿qué diferencia hay en la práctica? La respuesta corta: la diferencia entre feedback genérico y análisis accionable.

Sin skills, le pides al agente que revise algo y obtienes respuestas correctas pero superficiales. Con skills, el agente aplica tus estándares, detecta violaciones contra tus principios, y genera recomendaciones con valores específicos que puedes aplicar en el momento.

Esto no es magia. Es que el agente tiene acceso a los mismos criterios que tú usarías si revisaras manualmente — pero los aplica de forma exhaustiva y consistente, sin cansarse ni saltarse pasos.

Piénsalo así: sin un skill de code review, el agente aplica "buenas prácticas generales". Con un skill, aplica tu checklist: ¿El PR hace una sola cosa? ¿Los nombres comunican intención? ¿Hay tests para los edge cases? ¿El manejo de errores es explícito? La diferencia es entre "se ve bien" y un análisis estructurado con niveles de severidad y preguntas al autor.

Construyendo tu propio sistema de skills

No necesitas 60 skills para empezar. Necesitas uno. El que resuelva tu problema más recurrente.

Paso 1: Identifica la repetición

¿Qué explicas una y otra vez a tu agente de IA? ¿Qué corriges después de cada output? ¿Qué principios aplicas manualmente que el agente debería conocer?

Algunos patrones comunes:

• "Siempre tengo que recordarle que use TypeScript estricto"
• "Cada vez que genera CSS ignora mi sistema de espaciado"
• "Las revisiones de código son demasiado superficiales"
• "El copy que genera suena a robot corporativo"

Cada uno de esos es un skill esperando ser creado.

Paso 2: Escribe tu primer SKILL.md

Empieza simple. Un skill útil no necesita 500 líneas — necesita 3-5 principios claros, un proceso paso a paso, y un par de ejemplos de bueno vs malo.

---
name: mi-primer-skill
description: Describe cuándo se activa y qué hace.
  Incluye palabras clave que el agente pueda detectar.
---

## Principios
Los 3-5 principios fundamentales que siempre aplicas.

## Proceso
Los pasos que sigues, en orden.

## Ejemplos
Bueno vs malo. Concreto, no abstracto.

Paso 3: Prueba y observa

Usa el skill en tareas reales. Hay tres cosas que vigilar:

1. ¿Se activa cuando debería? Si no, mejora el description con más triggers
2. ¿El output mejora? Si no, tus principios necesitan ser más específicos
3. ¿Aplica los ejemplos? Si no, añade más ejemplos con el formato exacto que esperas

Paso 4: Itera sin piedad

Los mejores skills son los que han pasado por docenas de iteraciones. Cada vez que encuentras un caso que tu skill no cubre, lo añades. Cada vez que el agente interpreta mal una instrucción, la reformulas.

Un skill maduro puede tener sub-documentos, checklists expandidas y cientos de líneas. Pero empezó como un archivo de 20 líneas que resolvía un solo problema.

Un ejemplo completo

Imagina que trabajas en un equipo donde los PR reviews son inconsistentes. Unos días la revisión es profunda, otros días es "LGTM". Podrías crear esto:

---
name: pr-review
description: Se activa cuando se pide revisar un PR, pull request,
  merge request, o diff de código. Triggers: "review PR",
  "revisa este PR", "code review", "check this diff".
---

## Filosofía
Cada PR review es una oportunidad de enseñar y aprender.
No se trata de encontrar errores — se trata de mejorar
el código Y al autor.

## Checklist obligatoria
1. ¿El PR hace UNA sola cosa? Si no, sugerir dividirlo
2. ¿Los nombres comunican intención? (no `data`, `temp`, `x`)
3. ¿Hay tests para los nuevos paths? ¿Y para los edge cases?
4. ¿El manejo de errores es explícito o se swallowea silenciosamente?
5. ¿Hay cambios de API que necesitan documentar?

## Formato de feedback
- CRÍTICO: Bugs potenciales o problemas de seguridad
- IMPORTANTE: Violaciones de arquitectura o patrones del equipo
- SUGERENCIA: Mejoras opcionales de legibilidad o rendimiento
- PREGUNTA: Para entender decisiones del autor

## Anti-patterns
- NO aprobar solo porque "funciona"
- NO bloquear por preferencias de estilo
- NO reescribir el PR entero en los comentarios

Ese skill transforma cada PR review de un ejercicio ad-hoc a un proceso consistente. Y al estar documentado, escala — cualquier persona nueva en el equipo obtiene la misma calidad de revisión desde el primer día.

Composición: cuando los skills trabajan juntos

Un skill individual es útil. Múltiples skills que se componen son un sistema.

La idea es simple: las tareas reales no son atómicas. Escribir un artículo implica estrategia de contenido, redacción, edición y SEO. Desarrollar una feature implica diseño, implementación, revisión y deploy. Cada fase puede activar un skill diferente.

Si leíste el artículo anterior sobre tokens y orquestación, ya conoces el patrón de orquestador + sub-agentes. Los skills añaden una cuarta capa:

• Orquestación divide el trabajo en fases con contexto limpio
• Memoria persistente mantiene decisiones entre sesiones
• Compresión de outputs reduce el ruido en la ventana de contexto
• Skills dan conocimiento especializado a cada fase

Cuando un orquestador lanza un sub-agente para diseñar, ese agente carga los skills de diseño. Cuando lanza uno para implementar, carga los de desarrollo. Cuando lanza el de verificación, carga los de testing y SEO. Cada agente trabaja con el conocimiento relevante para su fase — no con un dump genérico de "buenas prácticas".

El resultado: un sistema donde cada pieza amplifica a las demás. La orquestación da estructura. La memoria da continuidad. Los skills dan profundidad.

Un ejemplo concreto: escribir este artículo. La fase de estrategia activa un skill de contenido que define el tipo de pieza, la audiencia y el posicionamiento SEO. La fase de redacción activa un skill de copywriting que aplica principios como "una idea por sección" y "especificidad sobre vaguedad". La fase de edición activa un skill que ejecuta siete pasadas secuenciales — claridad, voz, relevancia, evidencia, especificidad, emoción y riesgo. Cada fase trabaja con el conocimiento exacto que necesita, sin ruido.

Esto es lo que significa pasar de "usar herramientas" a "tener un sistema".

Organizando tu catálogo

Cuando tienes más de 10-15 skills, necesitas organización. No porque sea burocracia — sino porque si no encuentras un skill cuando lo necesitas, es como si no existiera.

Hay dos enfoques que funcionan:

Por categoría: agrupar skills en carpetas temáticas (proceso, dominio, contenido, crecimiento). Es lo más intuitivo y funciona bien para equipos pequeños.

Con un registro: un archivo central que lista todos los skills con su nombre, descripción y triggers. Así puedes buscar por tarea ("necesito optimizar un formulario") y encontrar skills que quizás no hubieras asociado con esa tarea.

La clave es que el sistema de organización escale contigo. Empieza simple y añade estructura cuando la necesites, no antes.

No se trata de reemplazar, se trata de amplificar

Después de meses construyendo este sistema, lo que he aprendido es simple: la IA no reemplaza tu criterio. Amplifica tu capacidad de aplicarlo.

Sin skills, tu agente es un generalista brillante que empieza de cero cada sesión. Con skills, es un equipo de especialistas que conoce tus estándares, aplica tus principios y te deja enfocarte en las decisiones que realmente importan.

Y lo mejor: el sistema es tuyo. No dependes de que alguien publique un plugin o una extensión. Tus skills codifican tu experiencia, en tu formato, para tus problemas. Son portátiles, editables y mejoran con cada iteración.

Un freelancer con el sistema correcto puede producir con la consistencia y profundidad de un equipo. Un equipo con skills compartidos puede onboardear a nuevos miembros en horas en vez de semanas — porque los estándares no están en la cabeza de nadie, están en archivos que cualquiera puede leer y que el agente aplica automáticamente.

No porque la IA haga el trabajo por ti — sino porque codificas tu experiencia en un formato que escala.

El primer artículo era sobre qué herramientas usar. El segundo, sobre por qué fallan y cómo arreglarlo. Este tercero cierra el arco: las herramientas son el principio. El sistema es lo que importa.

Empieza con un skill. El que más te duela no tener.