El recorrido de la ruta 4: desde el concepto de skill (markdown invocable) hasta el build en la práctica, terminando con agentes que deciden por sí solos y se ejecutan sin que estés presente.
Mapa de la ruta
Contenido detallado
📦 Skills: concepto y anatomía
La skill es un workflow en Markdown que invocas como slash command. Aquí: qué es, dónde está (.claude/skills), la anatomía del SKILL.md, cómo las skills llaman a las tools, cuándo usar una skill o escribir directamente, skills vs. CLAUDE.md y cómo compartirlas y versionarlas.
Un archivo Markdown con instrucciones: conceptualmente, lo mismo que un «workflow» (la capa W de WAT), pero guardado en un directorio especial y expuesto como slash command.
Dejas de volver a explicar la misma tarea: el proceso se vuelve invocable y consistente.
Skill = workflow invocable; markdown; el mismo proceso cada vez.
Cada skill vive en su propia carpeta dentro de .claude/skills, con un archivo markdown que la define; entonces aparece como un slash command (p. ej.: /draft-email).
Es cómo el agente «descubre» la skill y la expone para que la invoques.
Una carpeta por skill; los slash commands se convirtieron en skills; descubrimiento automático.
O SKILL.md define el nombre, la descripción (cuándo activarla), los argumentos esperados y las instrucciones paso a paso.
La descripción es lo que le indica al agente CUÁNDO usar la skill; los argumentos son lo que te pide.
Nombre; descripción que activa; argumentos; pasos.
Una skill todavía puede activar tools (scripts de Python: búsqueda web, scraping, generación de documentos); el framework WAT permanece intacto por debajo.
Una skill no es solo texto: es un proceso que ejecuta trabajo real mediante tools.
Skill ≈ W; tools ≈ T; el agente decide cuándo ejecutar cada tool.
Usa una skill para workflows repetidos, cuando la consistencia importa o para instrucciones complejas o fáciles de olvidar. Para una tarea de una frase o un experimento único, solo escribe: usar una skill sería exagerado.
Saber cuándo empaquetar evita tanto el caos como el over-engineering.
Repetición → skill; algo puntual → escribir; consistencia; compartir.
CLAUDE.md guarda solo las reglas de todas las sesiones (propósito, objetivo, framework); las instrucciones por tarea van en skills, que se cargan bajo demanda solo cuando se invocan.
Poner todo en CLAUDE.md desborda la ventana de contexto; las skills ahorran tokens.
Cada sesión frente a bajo demanda; 20-50 skills no aumentan el tamaño; ventana de contexto.
Como la skill es un archivo en la carpeta del proyecto, se puede versionar en Git y compartir con el equipo; todos obtienen el mismo proceso confiable.
Una skill probada en la práctica se convierte en un activo del equipo, no en conocimiento atrapado en una cabeza.
Archivo = versionable; compartible; delegar y olvidar.
🔨 Construcción práctica de Skills
Manos a la obra: pedir una skill en el formato oficial, crear y probar la skill "redactar correo electrónico" (/draft-email), invocarla sin argumentos, reutilizarla con contexto limpio, crear la skill «documento → diapositivas», conectar una skill de diseño lista para usar y crear tu biblioteca de skills.
No necesitas saber escribir skills: describes el workflow (entradas, comportamiento, dónde guardar) y le pides al agente que lo convierta en un slash command siguiendo el formato oficial.
La misma mentalidad de vibe coding: describe el resultado y la IA genera la skill.
Formato oficial; Plan Mode; describir las entradas/salida.
La primera build: una skill que recibe viñetas, destinatario y tono, y redacta un correo pulido, conciso y sin rodeos, guardándolo en la carpeta temporal. Se convierte en el slash command /draft-email.
Es el ejemplo canónico de una skill reutilizable de principio a fin.
Argumentos (viñetas/destinatario/tono); SKILL.md; carpeta temporal.
Si llamas al comando slash sin pasar datos, el agente te preguntará por los datos que faltan (destinatario, tono, viñetas) antes de ejecutarlo.
La skill es robusta: nunca funciona "a ciegas"; recopila lo necesario.
Recopilación de datos de entrada; argumentos faltantes; experiencia guiada.
Para volver a usarlo, limpias la conversación (/clear) y vuelve a llamar al slash command con nuevas entradas: una salida fresca y consistente que siempre sigue las mismas reglas.
Contexto limpio = ejecuciones predecibles; la skill garantiza el mismo estándar.
Limpiar entre usos; mantener la consistencia; para modificarlo, solo tienes que pedirlo.
Una segunda skill que lee un documento, extrae los puntos clave y crea una presentación profesional, usando tools Python por debajo.
Muestra cómo la skill resume contenido extenso en un deck estructurado y reutilizable.
Resumir → estructurar; herramientas de generación; iterar el diseño.
Integrar una skill de diseño ya existente mejora la calidad visual sin que tengas que describir manualmente cada detalle del diseño.
Las skills se componen: superpones una skill de diseño a tu workflow.
Composición de skills; skill de diseño; reutilización de conocimiento listo para usar.
Un catálogo de ideas de skills listas para que las armes: notas → acciones, datos → PDF, correo electrónico, resumen de reunión, brief de investigación.
Te da puntos de partida concretos para construir tu propia biblioteca.
Catálogo; skills probadas en la práctica; guardar lo que funciona.
🤖 Agentes: locales, programados y por evento
El salto a sistemas que deciden por sí solos: qué es un agente (razona, se adapta, se autocorrige), agente local bajo demanda, el ciclo de automejora, agente programado (cron), agente por evento (webhook), el agentic gap, diseñar para producción desde el 1.er prompt y cuándo un «agente» es solo un script.
A diferencia de la automatización tradicional (tú conectas cada paso), un agente recibe el resultado deseado y razona, se adapta, hace preguntas y se recupera por sí solo cuando algo falla.
Es la frontera entre «conecta todo a mano» y «di el resultado».
Razona; se adapta; se autocorrige; no determinista.
El asistente como agente personal: investiga, crea archivos, itera sobre el resultado y se vuelve más inteligente con cada uso; todo se ejecuta localmente, sin deploy.
Es la forma más sencilla de agente; construye intuición antes de pasar a la nube.
Local; bajo demanda; observas y aprendes.
El agente ejecuta un workflow, se encuentra con un error, lo diagnostica, corrige la tool y actualiza el workflow para que el error no vuelva a aparecer; las ejecuciones son más fluidas y rápidas.
Es el superpoder de los agentes locales y exactamente lo que desaparece en producción.
Fallar → corregir → actualizar; aprender del fallo; persistir el fix.
Un agente que funciona solo a la hora programada por un patrón cron (5 campos; p. ej., 0 7 * * * = todos los días a las 7 h) — investiga, sintetiza y guarda el resultado, sin que tengas que estar presente.
Es la primera forma de agente que escala más allá de «cuando apareces».
Cron (5 campos); se ejecuta unattended; programa.
Un agente que se activa cuando se llama a un webhook (una URL que escucha datos), recibe un payload: un «timbre digital» que pone el trabajo en marcha.
Es cómo un formulario, una app u otro sistema activa a tu agente.
Webhook = timbre; payload; auth Bearer.
Cuando el agente se ejecuta en la nube según una agenda o un evento, el asistente ya no está supervisándolo para autocorregirse: el sistema se ejecuta, pero no se adapta por sí solo, y un fallo puede pasar desapercibido.
Es el riesgo central en producción; define cómo diseñas el agente.
Sin autocuración; fallas silenciosas; los logs y las alertas cierran la brecha.
Los cuatro requisitos del build unattended: entradas fijas, salida estructurada y predecible, manejo de errores integrado y registro en cada paso — todo desde el 1.er prompt.
Como el agente no se autocura, diseñas la robustez de la salida.
Entradas fijas; salida estructurada; try/catch; registrar todo.
No toda automatización necesita razonamiento: si la tarea es fija y predecible, un script determinista es más barato y confiable que un agente, y esa es una opción válida.
Saber la diferencia evita pagar por una inteligencia que no necesitas.
Determinístico vs. agéntico; «boring is beautiful»; costo vs. adaptación.