Contenido detallado
⚡ Comandos slash: atajos que ahorran tiempo
Escribes / y aparece una lista de acciones al instante. Son los slash commands — la forma más económica de controlar el estado de tu sesión. Dos son indispensables de ahora en adelante: /context muestra cuánto de la ventana de contexto ya se usó, y /clear reinicias la conversación y empiezas desde cero.
Acciones rápidas integradas en Claude Code, que se activan al escribir /. Piensa en atajos de teclado, pero en texto.
Son la forma más barata de gestionar la sesión. Saber qué ocupa espacio y cuándo reiniciar evita que baje la calidad.
/clear = abrir una pestaña nueva (contexto fresco) · comandos personalizados · las skills se convierten en comandos al instalarlas.
Los dos comandos que más vas a usar en este módulo
/context # quanto da janela já foi consumido /clear # zera a conversa — igual a abrir uma aba nova / # abre a lista de todos os comandos disponíveis
💡 Consejo práctico
Al instalarse, varias skills aparecen como comandos slash. Cuando tengas dudas sobre lo que está disponible, escribe solo / y desplázate por la lista: es tu «menú» de la sesión.
🧠 Contexto y tokens: el precipicio invisible
Toda conversación tiene un precipicio. Cuanto más larga, peor es el rendimiento: fenómeno llamado deterioro del contexto. Es el error n.º 1 de los principiantes: usar la misma ventana todo el día. Gestionar el contexto es precisamente lo que separa un buen resultado de uno mediocre.
Context rot es la pérdida de rendimiento a medida que crece la conversación. Cuanto más historial se acumula, más se pierde el modelo.
El contexto es un recurso finito. Quien lo trata como desechable mantiene la calidad alta tarea tras tarea.
Una tarea, una ventana · al terminar, descártala (/clear) · /context para ver el consumo · modelo adecuado para la tarea.
Abre y mide
Ejecuta /context al principio para ver el uso actual de la ventana.
Haz una tarea enfocada
Una tarea pequeña y bien delimitada. No mezcles cinco temas en la misma ventana.
¿Terminaste? Descártalo
Ejecuta /clear antes de empezar algo nuevo. Contexto fresco, calidad preservada.
📊 El modelo adecuado para cada tarea
- •No todo requiere el modelo más potente: las tareas simples funcionan bien con modelos más ligeros.
- •Usar el modelo ligero para lo sencillo ahorra costos y permite escalar mejor.
- •Guarda el modelo más potente para el razonamiento difícil y la revisión crítica.
🎯 Skills: el libro de recetas del especialista
Una skill es un conjunto de instrucciones, un archivo SKILL.md con nombre, descripción y paso a paso; Claude lo carga por sí solo cuando la tarea coincide. Sin una skill, el modelo improvisa; con una skill, sigue una receta probada y siempre ofrece el mismo nivel de calidad.
Un procedimiento reutilizable empaquetado en un SKILL.md. Pide "arma una presentación" y la skill de presentación se activa sin que la menciones por su nombre.
Las skills son "la ciencia detrás del output". Toda tarea que repites puede convertirse en una skill: codificas una vez y aprovechas el patrón para siempre.
La skill se descubre mediante descripción (el disparador) · comprueba qué existe escribiendo / + nombre · tres piezas: nombre, descripción, contenido.
✓ Una skill bien hecha
- ✓Descripción clara del cuando usar — es lo que hace que la skill «se active» en el momento adecuado.
- ✓Procedimiento breve y directo, fácil de seguir.
- ✓Probada: pides la tarea y la skill se activa sola.
✗ Skill que no se activa
- ✗Descripción vaga o genérica — Claude nunca sabe cuándo aplicarla.
- ✗Paso a paso largo y confuso, lleno de excepciones.
- ✗Nunca se ha probado: solo descubres que no se activa cuando llega el momento.
Construir tu skill desde cero: pídelo así
Vamos criar uma skill para padronizar meu resumo de reunião. Comece pela DESCRIÇÃO (quando ela deve ser usada), depois o passo a passo. Entregue como um SKILL.md pronto para revisar.
Profundiza (opcional): la descripción lo es todo
Claude elige la skill leyendo la descripción, no el cuerpo. Una descripción genérica ("ayuda con textos") rara vez se activa; una específica ("úsalo cuando el usuario pida un resumen de reunión con decisiones y próximos pasos") se activa en el momento indicado. Esmérate en ella como si fuera el disparador, porque lo es.
🔌 MCP: el enchufe universal
O Model Context Protocol (MCP) es un estándar abierto que permite que el modelo se comunique con APIs y servicios sin que tengas que escribir la integración. Una API es un manual técnico que las máquinas usan para comunicarse entre sí; MCP es el adaptador estandarizado por encima de ella. No programas el «pegamento»: enumeras el servidor MCP y lo pides en portugués.
Un estándar abierto (anunciado por Anthropic a finales de 2024) que le da a Claude una ventana a tus herramientas: correo electrónico, datos, scrapers, servicios.
En vez de memorizar endpoints y escribir código de integración, conversas con la herramienta. Hoy casi todas las herramientas serias tienen un servidor MCP.
API = máquina a máquina · MCP = envoltorio que expone solo lo necesario · MCP local mantiene tu clave en tu máquina, sin intermediarios.
✓ Con MCP
- ✓Pides en portugués: "busca mis últimos correos no leídos".
- ✓La clave queda en una variable de entorno, nunca en el chat.
- ✓Un solo estándar sirve para cualquier herramienta con servidor MCP.
✗ Sin MCP (API directa)
- ✗Memorizas endpoints y escribes a mano la "chuleta" de integración.
- ✗Riesgo de pegar la clave en el lugar equivocado.
- ✗Un código diferente para mantener cada servicio.
Crear un MCP local (ejemplo: servicio de video): pídelo así
Quiero crear un MCP local para [SERVICIO]. La clave de API ya está como variable de entorno. Enumera las funcionalidades disponibles, elige las más útiles para mi uso y crea el MCP local. Al final, explica cómo llamarlo en una conversación.
🔒 La clave nunca va en el chat
La clave de API vive en una variable de entorno local: nunca pegada en la conversación ni en un archivo versionado. Un MCP local se ejecuta directamente en tu máquina y mantiene la clave allí, lejos de cualquier intermediario.
👥 Subagentes: delegar para terminar más rápido
En vez de un trabajador que hace todo en secuencia, abres una equipo. Subagentes son agentes activados para tareas separadas, cada uno con su propia ventana de contexto. El trabajo independiente se ejecuta en paralelo y termina antes.
El trabajo en paralelo: varios agentes trabajando al mismo tiempo, cada uno con su propio contexto.
Excelente para investigar desde varios ángulos y dividir un proyecto en frentes. Lo que es independiente termina antes.
Delega las partes que no dependen unas de otras · cada subagente devuelve solo la conclusión (no el historial sin procesar) · eso protege tu contexto principal.
Divide en partes independientes
Divide la tarea en frentes que no dependan unos de otros (X, Y, Z).
Lanza los subagentes
"Crea tres subagentes: uno analiza X, otro Y y otro Z." Cada uno devuelve solo las conclusiones.
Recopila y consolida
Reúne los resultados en un cuadro comparativo en el agente principal.
Fan-out en paralelo — pídelo así
Haz [TAREFA]. Crea tres subagentes independientes: - subagente 1: analiza [ángulo X] - subagente 2: analiza [ángulo Y] - subagente 3: analiza [ángulo Z] Cada uno devuelve solo las conclusiones. Después, consolídalas en un cuadro comparativo.
🔁 Ciclo de crítica: uno crea, otro revisa
"Claude evalúa el trabajo de Claude." Pedirle que crear es una cosa; pedirle a revisar es algo completamente distinto, y mejora mucho el resultado. La revisión automática detecta errores que el autor no ve.
Un flujo en el que un agente crea el entregable y otro asume el papel de revisor crítico, señala los puntos débiles y devuelve la versión corregida.
La revisión detecta lo que el autor no ve. Incluso puedes usar un modelo diferente como revisor para obtener un segundo punto de vista.
Separa los roles (autor x crítico) · pide la crítica de forma explícita · itera una o dos rondas · otras CLI de modelos pueden participar como revisores externos.
Cambiar de rol para revisar: pídelo así
Você acabou de criar [ENTREGÁVEL]. Agora mude de papel: seja um revisor crítico e rigoroso. Aponte furos, vieses e o que faltou. Em seguida entregue a versão final corrigida.
Profundiza (opcional): por qué funciona separar los roles
Cuando el mismo agente crea y juzga en la misma respiración, tiende a defender su propio borrador. Al pedir explícitamente «ahora sé el crítico», reinicias su postura: el objetivo pasa a ser encontrar problemas, no justificar decisiones. Una o dos rondas suelen bastar; más que eso da resultados decrecientes.
Autoevaluación (opcional): ¿cuál es la mejor manera de evitar el deterioro del contexto?
🧪 Ejemplo práctico guiado: mininvestigación «dónde vivir»
Vamos a unir skills + subagentes + bucle de crítica en una tarea real — y ver la gestión del contexto en la práctica.
Sesión limpia
Ejecuta /clear y después /context para confirmar que está en cero.
Lanza subagentes
"Investiga el mejor lugar para vivir. Tres subagentes: financiero/tributario, calidad de vida, clima y seguridad. Cada uno devuelve solo las conclusiones."
Consolida
Cuando vuelvan los tres, pídele al agente principal una tabla comparativa.
Ciclo de crítica
"Ahora actúa como revisor crítico: señala lagunas, sesgos y lo que faltó. Después entrega la versión final corregida."
Verifica el contexto
Ejecuta /context. Observa cuánto creció la ventana — y por qué vas a querer /clear antes de la siguiente tarea.
✏️ Ejercicios
1. Higiene del contexto (fácil)
Ejecuta /context, haz una tarea breve, ejecuta /context de nuevo y después /clear. Criterio: sabes cuánto consumió la tarea y la ventana vuelve a cero después del /clear.
2. Usar una skill lista (medio)
Instala una colección de skills de fuentes confiables y confirma una skill con / + nombre y úsala en una tarea real. Criterio: la skill aparece en la lista y produce output según su estándar.
3. Tu primera skill (medio)
Crea una skill para una tarea que repites (p. ej., estandarizar el resumen de una reunión). Criterio: al pedir la tarea, se activa la skill y el resultado sale consistente.
4. MCP local (medio)
Conecta una herramienta que uses vía MCP (con la clave en el entorno). Criterio: llamas a la herramienta en portugués, sin escribir el endpoint, y la clave nunca apareció en el chat.
5. Crítico en paralelo (difícil)
Pide cualquier creación y luego activa un subagente revisor para que la critique y te devuelva la versión final. Criterio: la versión final corrige al menos un problema señalado en la crítica.
⌨️ Prompts listos
Cuatro instrucciones para activar las funciones avanzadas. Úsalas como punto de partida y adáptalas a tu caso. La base de datos completa está en Biblioteca → Prompts.
Verificar y limpiar el contexto
Antes de começarmos, me diga: o que está ocupando minha janela de contexto agora? Se passar de metade, sugira o que descartar. (equivalente a /context)
Crear una skill desde cero (canónico)
Quero criar uma skill para [TAREFA QUE REPITO]. Primeiro escreva a DESCRIÇÃO (quando esta skill deve ser usada). Depois o passo a passo que você deve seguir toda vez. Entregue como um SKILL.md pronto para eu revisar.
Original (EN):
I want to create a skill for [REPEATED TASK]. First write the DESCRIPTION (when this skill should trigger). Then the step-by-step you must follow every time. Output it as a ready-to-review SKILL.md.
Lanzar subagentes en paralelo
Haz [TAREFA]. Crea tres subagentes independientes: - subagente 1: analiza [ángulo X] - subagente 2: analiza [ángulo Y] - subagente 3: analiza [ángulo Z] Cada uno devuelve solo las conclusiones. Después, consolídalas en un cuadro comparativo.
Auditar una skill de terceros antes de instalarla
Vou instalar esta skill de terceiros. Leia o SKILL.md, me diga em bullets o que ela executa, que acessos ela pede e qualquer sinal de risco. Só recomende usar se for seguro.
⚠️ Errores comunes
- ✗Usar la misma ventana todo el día. Conversación larga = deterioro del contexto = caída de calidad. Una tarea por ventana;
/clearal terminar. - ✗Instalar una skill de fuente dudosa. Una skill es código que se ejecuta en tu máquina. Lee el
SKILL.mde instálalo solo desde una fuente confiable. - ✗Pegar claves de API en el chat. Las claves se guardan en variables de entorno locales, nunca en el cuerpo de la conversación ni en archivos versionados.
- ✗Saltarte la revisión. Aceptar el primer borrador sin un ciclo de crítica deja pasar errores. Crear y revisar son pasos diferentes.
- ✗Paralelizar tareas dependientes. Los subagentes brillan en el trabajo independiente. Si la parte B depende de la A, ejecutarlas en paralelo solo genera retrabajo.
✅ Resumen del módulo
/context mide, /clear se reinicia; una tarea por ventana vence a deterioro del contexto.Lista de verificación de finalización
- ☐ Sé usar
/contexte/cleary entiendo qué es deterioro del contexto. - ☐ Instalé y usé una skill lista de una fuente confiable.
- ☐ Creé al menos una skill desde cero (nombre + descripción + paso a paso).
- ☐ Conecté una herramienta externa mediante MCP, con la clave en el entorno.
- ☐ Puse en marcha subagentes en paralelo y consolidé los resultados.
- ☐ Ejecuté un ciclo de crítica (crear → revisar → versión final).
- ☐ Puedo elegir el modelo adecuado para tareas simples y complejas.
🎉 ¡Fin de la Ruta 1!
Completaste los Fundamentos. Siguiente ruta: Construir — empieza por el módulo 2.1, del sitio web desde cero hasta el deploy.