Una skill es un workflow empaquetado en una carpeta especial y activado mediante un slash command; se carga bajo demanda, sin inflar el contexto. El diagrama de abajo muestra cómo la skill se convierte en un comando reutilizable y, a la derecha, el presupuesto de contexto con las zonas que indican cuándo /compact y cuándo dar /clear.
Diagrama ilustrativo — recreación conceptual de las skills y del presupuesto de contexto, no es una captura de pantalla real.
📦 Qué son las skills
Qué es: una skill es, en el fondo, lo mismo que un workflow (la capa W de WAT): instrucciones en markdown, pero guardadas en una carpeta especial, la .claude/skills, con cada skill en su propia subcarpeta y un archivo Markdown de skill dentro. La diferencia está en dónde vive y en cómo se activa: la skill se expone como un slash command, un comando reutilizable que invocas por nombre. Por debajo, la skill puede seguir activando herramientas (scripts Python de búsqueda, scraping y generación de documentos), así que el framework WAT permanece intacto.
💡 Por qué aprender
Las Skills importan por cuatro motivos: consistencia (el mismo proceso cada vez, sin volver a explicarlo), ahorro de tokens (se cargan solo cuando se invocan), compartir (la misma skill le sirve a todo un equipo) y confiabilidad (envuelven pasos complejos y fáciles de olvidar, para que delegues y te olvides). Y lo mejor: no necesitas saber escribir skills; describe el workflow y pídele al agente que lo convierta en un slash command reutilizable.
- •Consistencia: el proceso no varía entre ejecuciones.
- •Tokens: cargada bajo demanda, no en cada sesión.
- •Compartible: distribuye la carpeta y el equipo usa la misma skill.
- •Confiable: envuelve el paso difícil de recordar.
🗂️ Skill ≠ CLAUDE.md
El CLAUDE.md guarda solo las reglas de cada sesión (propósito del proyecto, objetivo principal, framework). Instrucciones por tarea pertenecen a las skills; así evitas exceder la ventana de contexto. Tener 20–50 skills no infla el contexto como lo haría un único CLAUDE.md gigante, porque las skills solo se cargan cuando se invocan.
Conceptos clave
Igual a un workflow.
Una carpeta por skill.
Invocada por nombre.
Se carga solo al usarlo.
⚖️ Skill vs. escribir
Qué es: no toda solicitud merece convertirse en una skill. La decisión es simple: empaqueta cuando la reutilización y la consistencia compensan el esfuerzo de crear la skill; escribe directamente cuando la solicitud es puntual y sencilla. Empaquetar demasiado pronto es overkill; demasiado tarde es una repetición agotadora.
✓ Vale la pena crear una skill
- ✓Es un workflow repetido — haces esto todas las semanas.
- ✓A la consistencia importa — el resultado siempre debe ser el mismo.
- ✓Las instrucciones son complejas o fáciles de olvidar.
- ✓Otras personas de equipo ejecutarán el mismo proceso.
✗ Mejor solo escribir
- ✗Es una tarea única, que no vas a repetir.
- ✗Todavía estás experimentando y el proceso cambia.
- ✗La instrucción cabe en una frase — una skill sería excesiva.
- ✗No se ve que pueda reutilizarse; empaquetarlo solo añadiría fricción.
🎯 Por qué aprender
La regla práctica: en la tercera vez que vayas a escribir casi la misma instrucción larga, detente y pídele al agente que la convierta en una skill. Antes de eso, escribir es más ágil; después, la skill compensa la inversión en pocos usos.
Conceptos clave
Disparador n.º 1 de la skill.
La salida siempre es la misma.
Pasos fáciles de olvidar.
¿Algo puntual? Solo escríbelo.
✉️ Skill en la práctica: /draft-email
Qué es: un build práctico de una skill de redactar un correo electrónico — creada, probada, refinada e invocada como slash command. La anatomía es una carpeta .claude/skills con una subcarpeta por skill, cada una con un SKILL.md que define name, description, los argumentos esperados y los pasos. Los argumentos aquí son, por ejemplo, viñetas con la información clave, el destinatario y el tono. Se puede invocar como /draft-email — los slash commands se unificaron con las skills, comparables a las integradas como /clear.
name: draft-email description: Rascunha um e-mail polido e conciso, sem enrolação. ## Argumentos - bullets: pontos-chave do conteúdo - destinatario: para quem é (ex.: cliente) - tom: profissional | amistoso | formal ## Comportamento 1. Se faltar algum argumento, pergunte antes de escrever. 2. Escreva um e-mail claro, direto e sem enchimento. 3. Salve o rascunho em temporary/outputs/email.md
🛠️ Por qué aprender — el flujo de build
Crear en Plan Mode
Pide una skill que siga el formato oficial y describe las entradas (viñetas, destinatario, tono), el comportamiento y dónde guardar la salida. Aprueba el plan.
Limpiar el contexto e invocar
Limpia la conversación y llama /draft-email. Invocarlo sin argumentos hace que el agente pregunte los datos que faltan.
Reutilizar con nuevas entradas
Limpia de nuevo, llama el slash command con otro destinatario/tono y recibe una salida nueva que sigue las mismas reglas. Para modificar la skill, solo pídele al agente que la cambie.
🎯 Consejo práctico
Limpia el contexto entre usos para tener runs limpios y consistentes. La skill garantiza las las mismas reglas (tono, concisión, estructura) en cada invocación; eso es exactamente lo que diferencia delegar y olvidarse de tener que volver a explicarlo todo.
Conceptos clave
name · description · args.
viñetas · destino · tono.
Sin argumentos, pregunta.
Limpia y vuelve a llamar.
🖼️ Generador de presentaciones
Qué es: otro build completo en el framework WAT — un workflow que toma un documento y genera una presentación profesional a partir de él. Reutiliza el flujo estándar: CLAUDE.md (WAT) → workflow + herramientas → ejecutar → iterar. En Plan Mode, el agente hace preguntas de configuración (lenguaje de la herramienta, cómo extraer los puntos clave, estilo de la presentación). El workflow lee el documento, extrae los puntos y crea el archivo de presentación.
# Workflow: documento → slides ## Entrada Documento em temporary/resources/ (10–16 páginas) ## Passos 1. Ler o documento e extrair os pontos-chave. 2. Estruturar em títulos + bullets por slide. 3. Gerar a apresentação via ferramenta Python. ## Saída Deck (ex.: 26 slides) em temporary/outputs/
🎨 Por qué aprender — iteración y diseño
No necesitas entender las herramientas de Python: basta con comprobar si la lógica del workflow produce el resultado deseado. Siempre hay margen para mejorar el diseño: colores, fuentes, estilo corporativo o informal, combinación de texto con viñetas en lugar de solo viñetas. Y hay un atajo potente para reutilizarlo: sobrescribir una skill pública de diseño de diapositivas al workflow eleva el aspecto visual sin que tengas que explicar manualmente cada necesidad de diseño.
- •Entrada: documento en temporary/resources.
- •Salida: presentación profesional en temporary/outputs.
- •Actualización: una skill de diseño integrada en el workflow.
🎯 Consejo práctico
Ejecuta el build con bypass de permisos solo después de aprobar el plan. Y recuerda: cuando ya te sientas cómodo con el flujo básico, conectar una skill de diseño dedicada es la forma más económica de mejorar la calidad del deck: la skill incluye el conocimiento de diseño que no quieres reescribir.
Conceptos clave
CLAUDE.md → wf+tools.
Extrae y estructura.
Color, fuente, estilo.
Superpuesta al workflow.
🗣️ 5 patrones de prompting
Qué es: cinco patrones de prompting que producen resultados consistentes y de alta calidad. Transforman pedidos vagos en instrucciones que el agente puede ejecutar bien —y cambian tu postura de «operador» a «gerente de un especialista».
Define el objetivo, no los pasos
Di el resultado que quieres; deja que el agente decida la secuencia. Describe el «qué», no el «cómo».
Sé específico sobre la salida
Formato, estructura, nombre de los archivos y dónde guardar. Cuanto más clara sea la salida esperada, menos trabajo tendrás que repetir.
Primero Plan Mode y después ejecuta
Aprueba el plan antes de dejar que el agente actúe; solo entonces pasa al modo de ejecución (omisión de permisos).
Da feedback, no correcciones
"Me gustó la estructura, pero el tono es demasiado formal" funciona mejor que "esto está mal". El feedback actualiza el workflow por debajo.
Trata al agente como especialista
Tú eres el gerente; el agente es el desarrollador. Delega el trabajo técnico y enfócate en describir bien el objetivo y evaluar el resultado.
🎯 Por qué aprender
Estos cinco patrones juntos activan el bucle de automejora: al dar feedback (no una corrección) sobre un resultado bien especificado, el agente ajusta el workflow subyacente — y la próxima ejecución ya sale mejor sin que tengas que volver a explicarlo.
Conceptos clave
Qué, no cómo.
Formato y ubicación.
Planifica primero.
En lugar de corregir.
📉 Context rot y umbrales
Qué es: context rot es la degradación gradual de la calidad a medida que se alarga una sola sesión. La raíz está en cómo funcionan los mecanismos de atención: los errores tienden a aparecer después de ~60% de uso de la ventana, cuando se llena de historial ruidoso y los mensajes recientes (posiblemente irrelevantes) desplazan las reglas centrales del foco del modelo.
| Zonas | Rango | Qué hacer |
|---|---|---|
| Verde | 0–50% | Es seguro: sigue trabajando. |
| Amarillo | 50–70% | Empieza a pensar en compactar. |
| Naranja | 70–85% | Ejecuta /compact proactivamente. |
| Rojo | 85%+ | Ejecuta /clear y vuelve a empezar. |
⚠️ Por qué aprender — la señal de alerta
El desgaste del contexto es real: después de ~60% de uso, espera más errores. No reutilices una conversación saturada para trabajos no relacionados. Si ya corregiste al agente sobre el lo mismo más de dos veces, probablemente el contexto está contaminado: límpialo y vuelve a empezar con un mejor prompt.
Conceptos clave
Los errores empiezan aquí.
La ventana se convierte en ruido.
De verde a rojo.
Señal de contexto desordenado.
🧹 /clear vs /compact
Qué es: dos comandos para gestionar el contexto, con propósitos diferentes. /clear é o restablecimiento total de la conversación; /compact es un resumen inteligente que conserva la información clave y comprime el resto. Saber cuál usar —y cuándo— es lo que mantiene alta la calidad en una sesión larga.
/compact — resumen inteligente
- •Mantiene lo esencial y comprime el historial.
- •Usa en medio de una tarea cuando el contexto aumenta.
- •Ideal en la zona naranja (70–85%).
/clear — reinicio total
- •Borra toda la conversación y empieza desde cero.
- •Usa al cambiar de tarea o cuando la calidad baja.
- •Ideal por encima del 85% o después de 2+ correcciones repetidas.
🎯 Por qué aprender
Regla práctica: compactar cuando todavía estás en la misma tarea, pero el contexto aumentó; limpiar cuando cambias de tarea o cuando la calidad ya se ha deteriorado. Compactar demasiado tarde no recupera el contexto que ya se ha perdido; en ese caso, prefiere limpiar y empezar de nuevo con un prompt mejor.
Conceptos clave
Resume, no borra.
Restablecimiento completo.
Compacta.
Limpia.
💸 Ahorro de tokens
Qué es: un conjunto de estrategias para minimizar el consumo de tokens y el desperdicio de contexto. Como el agente vuelve a leer toda la conversación con cada mensaje, las sesiones largas cuestan más por mensaje; por eso, mantener el contexto conciso también permite mantener bajo el costo.
🪙 Por qué aprender — las 5 estrategias
- •Una tarea por sesión, luego limpia: no arrastres contexto viejo.
- •Define "listo" (p. ej., "exactamente 75 perfiles") para que el agente se detenga y no entre en un bucle.
- •Usa skills para workflows especializados, en vez de inflar el CLAUDE.md.
- •Desactiva los MCP que no uses — cada uno añade definiciones de herramientas al contexto.
- •Mantén el CLAUDE.md conciso (menos de ~500 líneas, solo contenido de toda la sesión).
⚠️ Trampa común
Sin un punto final definido, el agente puede buscar demasiado o entrar en un bucle, desperdiciando tokens. Además, cada servidor MCP activo consume contexto mediante las definiciones de herramientas: dejar activos los que no usas es un desperdicio silencioso.
Conceptos clave
Limpia después.
Para el loop.
En lugar de CLAUDE.md.
Desactiva los que estén inactivos.
✅ 12 consejos finales
Qué es: una lista consolidada de 12 mejores prácticas para crear workflows agénticos de calidad. Es el resumen operativo de todo el recorrido: léela como una lista de verificación antes y durante cada build.
- Empieza siempre en Plan Mode.
- Sé claro sobre el objetivo (p. ej., "75 perfiles de CEOs de empresas tecnológicas", no "haz un scraper").
- Define qué es "listo".
- Trata al agente como especialista — tú gestionas, él desarrolla.
- Administra el contexto proactivamente (compact ~70%, clear al cambiar o fallar, 1 tarea/sesión).
- Usa el bucle de automejora mediante comentarios específicos.
- Guarda claves de API en archivos de entorno.
- Prueba con entradas diferentes.
- Guarda skills probadas en batalla.
- Empieza desde cero cuando bloquearse.
- Desactiva MCP no utilizados.
- Sigue el build temprano para aprender y detectar errores.
🏁 Por qué aprender — el desafío práctico
Pon todo junto en un build propio de principio a fin: notas-de-reunión-para-acciones, generador de PDF, borrador de correo electrónico o un workflow de tu trabajo. Usa el WAT, empieza en Plan Mode, deja que el agente pregunte, aprueba el plan y cambia al modo de omisión de permisos. Usa al menos un MCP y/o una skill cuando tenga sentido (no lo fuerces). Prueba el resultado con 2–3 entradas diferentes: un workflow que solo funciona con una entrada es, en la práctica, un script de un solo uso.
Conceptos clave
Siempre primero.
Específico y medible.
2–3 entradas.
Nunca uses una clave en el chat.
🧠 Verificación rápida
Estás en medio de una tarea, el contexto llegó a ~75% y el agente todavía está enfocado en ella. ¿Qué comando usas?
📌 Resumen del módulo
Próximo Módulo:
3.1 — De lo local a siempre activo: GitHub & Trigger.dev