Skip to main content

Claude Code y OpenCode: un curso acelerado

15 conceptos · 80% del uso real

Imagina que pudieras decirle a tu equipo: "Mira el borrador de mi ensayo, corrige los errores de gramática, reorganiza los párrafos para que el argumento fluya mejor y guarda la nueva versión". Y que realmente lo hiciera. No solo que sugiera cambios para que los hagas tú, sino que abra tus archivos, haga las ediciones y guarde el resultado mientras lo observas.

Eso es lo que hacen Claude Code y OpenCode. Son herramientas de IA que trabajan directamente en tu equipo. Tú describes lo que quieres, ellas hacen el trabajo y tú revisas el resultado.

Este curso acelerado te enseña 15 conceptos que cubren cerca del 80% de lo que usarás en el día a día. Al final sabrás qué puede hacer cada herramienta, cuándo usar cada función y cómo evitar los errores más comunes.

Una idea que vuelve más fácil de entender todo lo demás: la mayoría de las técnicas "avanzadas" de estas herramientas se reducen a una sola cosa: darle a la IA la información correcta en el momento correcto, y mantener fuera la información que no viene al caso. Cada sección de este curso se conecta con esa idea.

Requisito previo: Prompting con IA en 2026. Ese curso te enseñó a hablar con la IA: darle contexto, pedir las cosas con claridad, revisar el trabajo de la IA. Este curso enseña qué pasa cuando la IA puede de verdad tocar tus archivos y ejecutar comandos en tu equipo.

Dos herramientas, un solo conjunto de habilidades

Este curso cubre dos herramientas en paralelo: Claude Code (de Anthropic) y OpenCode (de código abierto, funciona con cualquier modelo de IA). Enseñamos ambas por una razón práctica: si una técnica funciona en las dos herramientas, es una habilidad real, no un truco específico de una herramienta. Las habilidades que aprendas se transfieren entre ellas.

Claude CodeOpenCode
Creado porAnthropicComunidad de código abierto
Modelos de IASolo ClaudeClaude, GPT, Gemini, DeepSeek, modelos locales
Mejor paraEl mejor rendimiento de Claude sin configuraciónFlexibilidad, control de costos, modelos gratuitos
PrecioSuscripción o APIModelos gratuitos disponibles, o usa tu propia clave de API

Elige la que mejor se ajuste a tu situación. Todo lo de este curso funciona en ambas.

Actualizado a mayo de 2026. Ambas herramientas se actualizan con frecuencia. Antes de empezar cualquier sesión, ejecuta claude update o opencode upgrade para asegurarte de tener la última versión. Si todavía no tienes ninguna herramienta instalada, la instalación se cubre en la sección 1 más abajo.

Elige tu herramienta y la página te sigue

A lo largo de esta página, las secciones que difieren entre Claude Code y OpenCode tienen un selector. Elige una y todos los selectores de la página seguirán tu elección.

¿Quieres la versión completa de algún tema?

Esto es un curso acelerado: el 80% del uso real en una sola lectura. Para el tratamiento completo de cada tema de abajo, consulta el Capítulo 14: Trabajar con agentes generales y de codificación y el Capítulo 17: Claude Code para equipos, CI/CD y configuración avanzada.

Qué cubre este curso

ParteTemaQué aprendes
1FundamentosQué son estas herramientas, modo plan, permisos, cómo elegir tu modelo
2Gestión del contextoPor qué las conversaciones empeoran con el tiempo y cómo arreglarlo
3El archivo de reglasCómo configurar instrucciones permanentes para tu proyecto
4Personalizar tu herramientaComandos y skills, hooks/plugins, subagentes
5Conectarse con el mundoConectar la IA con servicios externos (MCP)
6Ejemplo práctico completoUna tarea completa, de principio a fin, en ambas herramientas
7Dónde ejecutarlasTerminal, IDE, web, escritorio
8Las dos herramientas juntasUsar ambas herramientas en el mismo proyecto

¿Prefieres aprender haciendo? Salta primero a la Parte 6 para ver el ejemplo práctico completo, y luego vuelve.


📚 Material de apoyo

Abrir la presentación completa

Ver la presentación completa: Codificación Agéntica, curso acelerado


Parte 1: Fundamentos

Estos cuatro conceptos son la base sobre la que se construye todo lo demás.

1. Qué son realmente estas herramientas

La mayoría de la gente cree que son chatbots que saben de código. No lo son. Un chatbot responde preguntas. Claude Code y OpenCode toman acción. Leen tus archivos, los editan, ejecutan comandos en tu equipo y siguen adelante hasta terminar la tarea. Tú describes lo que quieres, ellas hacen el trabajo, tú revisas el resultado.

El mayor cambio de mentalidad: deja de hacer preguntas, empieza a dar instrucciones.

Hacer una pregunta (débil)Dar una instrucción (fuerte)
"¿Cómo organizo mis notas?""Lee todos los archivos de la carpeta notes/. Crea un único archivo de resumen llamado weekly-summary.md que liste cada tarea pendiente, agrupada por persona. Omite todo lo marcado como [private]."

El primer prompt te da una explicación que luego tienes que ejecutar tú. El segundo prompt hace el trabajo por ti. Esa es la diferencia. (Es la misma idea del concepto 1 de Prompting con IA, pero con más en juego, porque la IA de verdad está cambiando tus archivos.)

¿Todavía no tienes ninguna de las dos herramientas instalada? Instala una ahora antes de seguir leyendo. Todo lo que viene después da por hecho que puedes abrir una terminal y probar cosas.

# macOS / Linux / WSL — recomendado (se actualiza solo)
curl -fsSL https://claude.ai/install.sh | bash

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

# macOS Homebrew (sin actualización automática — ejecuta `brew upgrade claude-code` cada cierto tiempo)
brew install --cask claude-code

# Alternativa con npm
npm install -g @anthropic-ai/claude-code

Referencia completa: code.claude.com/docs.

# Todas las plataformas — recomendado
curl -fsSL https://opencode.ai/install | bash

# macOS Homebrew
brew install opencode

# npm / bun / pnpm / yarn
npm install -g opencode-ai

Referencia completa: opencode.ai/docs.

Una vez instalada, abre una terminal en cualquier carpeta donde quieras trabajar y escribe claude (o opencode). Eso te lleva a tu primera sesión.

Comprobación rápida: ¿qué modelo estás usando? Antes de entrar en materia, confirma con qué modelo estás hablando en realidad, para no quemar sin querer un modelo caro en trabajo sencillo, ni preguntarte por qué uno barato se queda corto.

Escribe /status para ver tu modelo actual, junto con tu plan, el directorio de trabajo y el uso de contexto. Para ver la lista completa y cambiar, escribe /model y elige del menú; el cambio surte efecto de inmediato, sin reiniciar.

Escribe /models para ver todos los modelos de los proveedores que tienes conectados y cambiar entre ellos; el modelo activo también se muestra en la TUI. (Desde la línea de comandos, opencode models imprime los nombres provider/model disponibles, útil para fijar uno por defecto en tu configuración.)

Algunos modelos "gratuitos" de OpenCode son modelos sigilosos anónimos

Cuando ejecutas /models, algunas de las opciones gratuitas son modelos sigilosos (stealth models): se publican bajo un nombre en clave y sin revelar quién los hizo (por ejemplo, Big Pickle de OpenCode Zen en el momento de escribir esto). Vale la pena conocerlos, con dos advertencias:

  • Son temporales y sin anuncio previo. Un modelo sigiloso es un proveedor que prueba algo en silencio antes de revelarlo. Puede cambiar de comportamiento, cambiar de nombre o desaparecer sin aviso, así que no construyas hábitos, valores por defecto ni configuraciones de cursos o proyectos en torno a uno.
  • "Gratis" puede significar que el producto eres tú. Durante la ventana de pruebas gratuita de un modelo, tus prompts y tu código pueden usarse para entrenarlo y mejorarlo. Nunca apuntes un modelo sigiloso a nada confidencial: trabajo de clientes, repositorios privados, cualquier cosa bajo acuerdo de confidencialidad.

Están bien para experimentos desechables y para probar el flujo de trabajo. Para cualquier cosa de la que dependas, prefiere un modelo estable y de facturación privada (consulta el recuadro de DeepSeek V4 más abajo), donde el proveedor, los precios y la política de datos son todos conocidos y no van a cambiar bajo tus pies.

Pruébalo mientras lees

De aquí en adelante, cada concepto de esta página es algo que puedes probar en esa sesión, no solo leer. Mantén una terminal abierta junto a esta página y ejecuta cada idea a medida que la encuentres.

Actualizado a 2026. Ambas herramientas se actualizan con frecuencia. Antes de empezar cualquier sesión, ejecuta claude update o opencode upgrade para asegurarte de tener la última versión.

El modelo capaz más barato para OpenCode: DeepSeek V4

Como OpenCode es independiente del modelo, puedes apuntarlo al que dé la mejor relación entre costo y calidad. Entre los modelos alojados, el de mejor valor a mediados de 2026 es DeepSeek V4, que viene en dos niveles:

  • deepseek-v4-flash: la opción económica por defecto. Alrededor de $0,14 por cada millón de tokens de entrada (tan bajo como $0,0028 con un acierto de caché) y $0,28 por cada millón de tokens de salida, con una ventana de contexto de 1 millón de tokens y soporte para llamadas a herramientas. Estandariza este nivel para estudiantes y trabajo de alto volumen.
  • deepseek-v4-pro: el nivel superior cuando necesitas un razonamiento más fuerte. Más capaz, y aun así una fracción del precio de los modelos de frontera.

Configúralo (≈1 minuto): ejecuta opencode → escribe /connect → escribe deepseek → pega tu clave de API (crea la clave ahí y añade un pequeño saldo prepago: DeepSeek es de pago por uso, así que la clave no funcionará hasta que la cuenta tenga crédito) → elige el modelo. La guía propia de DeepSeek selecciona V4-Pro por defecto, así que elige deepseek-v4-flash si quieres la opción más barata.

Los precios y los niveles cambian a menudo; consulta la página en vivo antes de hacer tu presupuesto.

📘 Guía de integración DeepSeek + OpenCode · 💰 Modelos y precios de DeepSeek

Esto combina de forma natural con la división planificar / ejecutar: planifica con un modelo de frontera y luego deja que una sesión barata de OpenCode con DeepSeek haga la ejecución.

¿Quieres los precios de DeepSeek dentro de Claude Code? (avanzado, opcional)

Claude Code habla con los modelos de Anthropic por defecto, pero puedes apuntarlo a DeepSeek V4. Dos caminos:

  • El camino nativo simple. DeepSeek expone un endpoint compatible con Anthropic, así que puedes ejecutar Claude Code directamente contra él fijando ANTHROPIC_BASE_URL=https://api.deepseek.com/anthropic y tu clave de DeepSeek como token de autenticación antes de lanzar claude. Sin herramientas adicionales.
  • El camino del enrutador: claude-code-router. Un proxy comunitario que se coloca delante de Claude Code y te permite enrutar solicitudes a DeepSeek (y otros proveedores), incluso con distintos modelos por tarea; por ejemplo, un modelo de frontera para planificar y deepseek-v4-flash para ejecutar. Lo lanzas con ccr code en lugar de claude. Consulta el repositorio para la instalación y la configuración.

Dos advertencias honestas: ambos son configuraciones de terceros / no oficiales, así que pueden romperse cuando Claude Code se actualiza, y pierdes "el mejor rendimiento de Claude sin configuración" para el que Claude Code está ajustado. Si tu objetivo principal es codificar barato con DeepSeek, OpenCode es el camino más suave (es independiente del modelo por diseño); estos caminos son para cuando quieres específicamente la interfaz de Claude Code y los precios de DeepSeek.

2. Modo plan (la función más desaprovechada)

Normalmente, cuando le das una instrucción a estas herramientas, empiezan a trabajar de inmediato: leen archivos, editan código, ejecutan comandos. El modo plan cambia eso. Pone a la IA en un estado de "mira pero no toques". La IA puede leer tus archivos y pensar en la tarea, pero no puede cambiar nada. En vez de hacer el trabajo, escribe un plan paso a paso de lo que haría. Tú lees el plan, sugieres cambios y solo entonces la dejas empezar el trabajo real.

Ambas herramientas lo permiten. La forma de activarlo es un poco distinta, pero la idea es la misma.

Presiona Shift+Tab para alternar entre los modos de permisos. La primera vez entras en aceptación automática; la segunda vez entras en modo plan. En modo plan, el modelo puede leer pero no escribir: sin ediciones de archivos, sin comandos de shell.

Presiona Tab para alternar entre el modo Build (la IA puede hacer de todo) y el modo Plan (la IA solo puede leer, no cambiar nada). En modo Plan, si le pides que escriba o edite algo, te dirá que no puede y esperará a que vuelvas a Build. La misma idea que en Claude Code: primero mirar, después actuar.

Cómo se ve en la práctica. Entras en modo plan y luego escribes una instrucción normal:

Escribe un poema sobre mi madre y guárdalo como for-mom.md.

En vez de escribirlo, la IA primero vuelve con un plan:

Plan

  1. Escribir un poema de 5 estrofas al estilo de un soneto clásico.
  2. Usar un lenguaje formal y anticuado.
  3. Avanzar hacia un final grandioso y dramático.
  4. Guardar como for-mom.md.

Todavía no he escrito nada. Aprueba para continuar, o dime qué ajustar.

Eso no es lo que tenías en mente: querías algo corto, cálido y sencillo, no un soneto formal. Así que le replicas:

Que sea corto y cálido: cuatro versos, lenguaje cotidiano, nada grandioso. Algo que podría escribir en una tarjeta de cumpleaños.

La IA actualiza el plan. Ahora sí apruebas, y escribe el poema que de verdad querías, en vez de entregarte un soneto formal del que tendrías que explicar cómo salir.

¿Por qué molestarse con un plan? Por dos razones:

  1. Atrapas los errores antes de que ocurran. Es exactamente lo que acaba de pasar arriba: la suposición equivocada salió a la luz en el plan, no en un borrador terminado del que habrías tenido que zafarte a fuerza de explicaciones. En un poema de cuatro versos es un ahorro menor; cuando la IA está a punto de editar 10 archivos, es la diferencia entre una corrección rápida y una limpieza larga.
  2. La IA hace mejor trabajo cuando planifica primero. Escribir un plan obliga a la IA a pensar la tarea antes de empezar. Sin un plan, intenta pensar y escribir al mismo tiempo, y el resultado suele ser peor.

Regla general: si la tarea va a tomar más de 10 minutos, usa primero el modo plan. Para tareas más grandes, pídele a la IA que guarde el plan en un archivo (como docs/plans/my-plan.md) para poder volver a él más tarde o compartirlo con una sesión nueva.

Piénsalo como escribir un esquema antes de un ensayo. No empezarías a escribir un trabajo de 10 páginas sin conocer su estructura. La misma idea aquí: planifica primero, luego construye.

3. Disciplina de permisos

Cada vez que estas herramientas quieren hacer algo (editar un archivo, ejecutar un comando), te piden permiso primero. Puedes saltarte esto y dejar que hagan todo sin preguntar, pero no lo hagas cuando estás empezando. Quieres ver qué hace la IA antes de que lo haga.

Después de unas pocas sesiones, notarás que algunas acciones siempre son seguras (como leer archivos o ejecutar pruebas). Puedes decirle a la herramienta que deje de preguntar por esas acciones específicas y las apruebe de forma automática. Así se hace:

No te preocupes por el código de abajo

No necesitas entender cada línea. La explicación después de cada bloque de código te dice qué hace. A medida que uses la herramienta, estas configuraciones empezarán a tener sentido de forma natural.

.claude/settings.json:

{
"permissions": {
"allow": [
"Read",
"Edit",
"Write",
"Bash(npm test)",
"Bash(npm run lint)",
"Bash(npm run build)",
"Bash(git status)",
"Bash(git diff *)",
"Bash(git log *)"
],
"deny": ["Bash(rm -rf *)", "Bash(npm publish *)", "Bash(git push *)"]
}
}

opencode.json:

{
"$schema": "https://opencode.ai/config.json",
"permission": {
"*": "ask",
"read": "allow",
"edit": "allow",
"bash": {
"*": "ask",
"npm test": "allow",
"npm run lint": "allow",
"npm run build": "allow",
"git status*": "allow",
"git diff*": "allow",
"git log*": "allow",
"rm -rf*": "deny",
"npm publish*": "deny",
"git push*": "deny"
}
}
}

OpenCode te da más control sobre los permisos. Puedes fijar reglas para cada tipo de acción por separado (leer, editar, ejecutar comandos). También tiene una función de seguridad integrada: si la IA intenta la misma acción tres veces seguidas sin avanzar, se detiene automáticamente.

Consejo: configura las notificaciones. Estas herramientas pueden trabajar en tareas largas mientras tú haces otras cosas. El truco que vuelve esto útil es recibir una notificación cuando la IA termina o necesita tu intervención. Así puedes iniciar una tarea, cambiar a otro trabajo y volver cuando se te necesite.

  • Claude Code: herramientas de la comunidad como cc-notify pueden enviarte notificaciones de escritorio.
  • OpenCode: la aplicación de escritorio envía notificaciones automáticamente. Para la versión de terminal, puedes añadir un plugin que te avise.

4. Ajusta el modelo a la tarea

Ambas herramientas te dejan elegir qué modelo de IA hace el trabajo, y cambiar toma un solo comando. La mayoría de los principiantes nunca tocan este ajuste, lo cual es un error en ambas direcciones: o queman un modelo caro en tareas triviales, o pelean con un modelo débil contra un problema difícil y se culpan a sí mismos por los malos resultados.

Detrás de la elección hay un equilibrio simple. Los modelos más capaces son los mejores pensadores: planifican, razonan sobre código complicado y manejan la ambigüedad, pero cuestan más y agotan tus límites más rápido. Los modelos más baratos (y gratuitos) son perfectamente buenos siguiendo un plan claro: editar archivos, ejecutar pruebas, reformatear, cambios repetitivos. La habilidad está en mandar cada tipo de trabajo al modelo correcto.

El trabajoRecurre a
Planificar, arquitectura, "averiguar cómo hacer esto", depurar algo confusoEl modelo más capaz que tengas
Seguir un plan que ya aprobaste: ediciones de rutina, formato, ejecutar pruebas, código repetitivoUn modelo más barato o gratuito
Una pregunta rápida o un arreglo de una líneaEl que ya esté cargado; no le des tantas vueltas

Ya aprendiste a ver y cambiar tu modelo en el Concepto 1. El hábito es elegirlo a propósito:

Escribe /model para alternar entre un Claude más capaz (para el pensamiento difícil) y uno más rápido y barato (para el trabajo de rutina); el cambio surte efecto de inmediato, sin reiniciar. Una configuración común es dejar que el modelo fuerte se encargue del modo plan y uno más rápido haga la ejecución, para que el pensamiento caro ocurra una sola vez, al principio.

Como OpenCode es independiente del modelo, tu elección es más amplia: escribe /models para alternar entre todos los proveedores que has conectado: un modelo de frontera para planificar, un modelo alojado barato como deepseek-v4-flash (consulta el consejo de DeepSeek V4 en el Concepto 1) o incluso un modelo gratuito o local para la ejecución. También puedes fijar uno por defecto en opencode.json y darles a los subagentes su propio modelo más barato.

Esto combina directamente con el modo plan (Concepto 2). La parte cara de cualquier tarea es el pensamiento: leer el proyecto, decidir el enfoque, anticipar qué podría salir mal. Una vez que eso es un plan escrito, el resto es "solo sigue estos pasos", algo que un modelo barato hace sin problema. Así que: planifica con un modelo fuerte, ejecuta con uno barato. Ese único movimiento es de donde sale la mayor parte del ahorro, sin pérdida de calidad, y es la columna vertebral de la división planificar / ejecutar de la Parte 8.

Dos advertencias honestas. Primera, los modelos más baratos necesitan instrucciones más claras: siguen bien un buen plan, pero improvisan mal, así que cuanto más débil el modelo, más tiene que detallar el plan. Segunda, no optimices de más: cambiar de modelo cada pocos minutos te cuesta atención para ahorrar centavos. Quédate por defecto en un modelo fuerte, baja a uno barato para las tareas obvias y déjalo ahí.

Regla general: un modelo fuerte para decidir qué hacer, un modelo barato para hacerlo. Cuando un modelo barato empieza a dar vueltas en círculo, esa es tu señal de que la tarea necesitaba el más fuerte; sube de nivel, no sigas reintentando.


Parte 2: Gestión del contexto

Esta es la idea más importante de todo el curso: en cualquier momento, el modelo solo puede actuar sobre lo que tiene enfrente en ese instante, su contexto. Y ese contexto no es un único cajón grande donde echas cosas. Es una pila de capas, y pagas por cada capa en cada turno.

El contexto de una sesión mostrado como una pila de cinco capas, cada una con un costo de tokens en cada turno. Siempre activas: (1) el prompt del sistema y las definiciones de herramientas, cargados en cada turno; (2) el archivo de reglas (CLAUDE.md / AGENTS.md), cargado una vez al inicio de la sesión. Crecen y se reducen: (3) la conversación hasta ahora, que /compact reduce y /clear borra. Bajo demanda: (4) los archivos que has referenciado y (5) el contenido completo de la skill activa, cargados solo cuando se usan. Un subagente se ejecuta en su propio contexto aislado y devuelve solo un resumen. En resumen: cada capa se paga en cada turno, así que mantén la pila ligera.

Lo que importa no son las cinco etiquetas, sino la división del lado izquierdo. Las capas de arriba son fijas: el prompt del sistema y tu archivo de reglas se cargan, quieras o no. Todo lo de abajo es tuyo para gestionarlo: la conversación crece hasta que la reduces con /compact o la borras con /clear, los archivos se cargan solo cuando los señalas, las skills se cargan solo cuando se invocan, y un subagente hace su lectura pesada en una ventana aparte y te devuelve solo un resumen.

Ese es todo el juego. La buena gestión del contexto no es un truco; es el hábito de mantener esa pila ligera: cargar lo que la tarea necesita y limpiar lo que no. Una pila inflada cuesta más tokens, pero lo peor es que sepulta lo que importa: cuanta más basura hay en la ventana, más le cuesta al modelo encontrar la señal, y más se desvían sus respuestas.

En el curso de Prompting con IA aprendiste que lo que le das a la IA importa más que cómo se lo pides. Aquí hay más en juego: en un chat, un mal contexto te da una mala respuesta; con estas herramientas, un mal contexto significa que la IA escribe mal código directamente en tu proyecto. Por eso todo el resto de la Parte 2 es solo una forma concreta de controlar una de estas capas, y por eso, si recuerdas una sección de este curso acelerado, que sea esta. Funciona igual en ambas herramientas.

5. El deterioro del contexto es real

La IA solo puede retener una cantidad limitada de información a la vez. A esto se le llama ventana de contexto. Piénsalo como un chat grupal: la IA solo puede ver los mensajes de este chat. Si mencionaste algo antes en el chat, la IA puede subir y verlo. Si nunca lo dijiste, la IA no lo sabe. La IA moderna puede manejar un chat muy largo (cientos de miles de palabras), pero aun así tiene límites.

Por esto importa:

Problema 1: el chat se alarga más rápido de lo que crees.

Cada mensaje que envías, cada archivo que le pides a la IA que lea, cada respuesta que da la IA: todo se suma al historial del chat. Después de 20 o 30 mensajes de ida y vuelta, más unos cuantos archivos que pediste que mirara, el chat ya es muy largo.

La parte engañosa: no hay ninguna advertencia que te diga "esta conversación se está poniendo demasiado larga". Simplemente sigue creciendo en silencio en segundo plano.

Problema 2: la IA empeora al recordar cosas a medida que crece la conversación.

Aquí está la parte sorprendente. Incluso antes de llegar al límite, la IA empieza a tener dificultades. Cuando la conversación es muy larga, a la IA le cuesta más encontrar las partes importantes. Puede que notes:

  • La IA ignora algo que le dijiste 20 mensajes atrás (lo dijiste, pero fue hace tanto que la IA pierde el hilo)
  • La IA rehace un trabajo que ya había terminado (olvidó que ya lo había hecho)
  • La IA se confunde con nombres o detalles que antes tenía bien

A esto se le llama deterioro del contexto (context rot). La conversación sigue, pero la calidad del trabajo de la IA empeora poco a poco porque hay demasiada información vieja acumulándose.

Problema 3: las conversaciones más largas cuestan más dinero.

Cada vez que envías un mensaje, la IA no lee solo tu mensaje nuevo. Vuelve a leer la conversación entera desde el primer mensaje. Así que si has tenido 30 mensajes de ida y vuelta, la IA lee los 30 mensajes otra vez cada vez que envías el mensaje número 31.

Si pagas por uso (como en la mayoría de las configuraciones de OpenCode), esto significa que las conversaciones más largas cuestan mucho más dinero. Si tienes un plan de suscripción (como Claude Code Pro), alcanzas tus límites de uso diarios más rápido. De cualquier forma, una conversación larga y desordenada agota tu presupuesto.

La conclusión: mantén tus conversaciones cortas y enfocadas. Dale a la IA solo la información que necesita para la tarea actual, no todo lo que tienes. Una conversación limpia y enfocada funciona mucho mejor que una larga y abarrotada.

Un gráfico que muestra que la IA recuerda bien las cosas en conversaciones cortas, empieza a tener dificultades en las de longitud media y pierde el hilo de los detalles en conversaciones muy largas, incluso antes de llegar al límite máximo.

Revisa qué tan lleno está tu contexto. No puedes mantener la pila ligera si no puedes verla. Ambas herramientas te dejan leer tu uso actual, solo que lo muestran de forma distinta.

Escribe /context para ver un desglose completo: total de tokens usados respecto a la ventana (por ejemplo, 25.6k/1m tokens (3%)), separado por categoría: prompt del sistema, herramientas, archivo de memoria/reglas, skills y tu conversación. Incluso señala qué conviene recortar. También obtienes un porcentaje en marcha cerca del campo de entrada mientras trabajas, así no tienes que estar preguntando.

OpenCode muestra tu uso en vivo en su interfaz (la vista de terminal a pantalla completa): modelo activo, tokens usados y porcentaje de la ventana. Dónde aparece exactamente en pantalla varía según la versión y el ancho de la terminal, así que busca el indicador de tokens/porcentaje en marcha. Todavía no hay un comando integrado tipo /context con desglose, así que lees ese medidor desde la interfaz en vez de pedirlo. (Plugins de la comunidad pueden añadir un comando /context con desglose completo si quieres uno.)

Sea cual sea la herramienta en la que estés, el movimiento es el mismo: echa un vistazo al medidor, no esperes a que se llene. La calidad tiende a caer mucho antes de que la ventana esté técnicamente llena; una vez que una sesión pasa más o menos de la mitad de su ventana, esa es tu señal para /compact o /clear (a continuación), no cuando llegue al 100%.

6. /clear y /compact

Cuando el chat se pone demasiado largo, tienes dos opciones. Asegúrate de elegir la correcta:

Opción 1: empezar un chat nuevo. Úsala cuando hayas terminado una tarea y quieras empezar algo completamente distinto. El chat viejo se borra.

  • Claude Code: escribe /clear
  • OpenCode: escribe /new (o /clear)

Opción 2: reducir el chat actual. Úsala cuando sigues trabajando en la misma tarea pero el chat se ha puesto demasiado largo. La IA lee toda la conversación, escribe un resumen corto y descarta todo lo demás. Sigues trabajando a partir del resumen.

  • Ambas herramientas: escribe /compact

Puedes decirle qué conservar: /compact conserva los nombres de archivo y las decisiones que tomamos.

No las confundas. /clear borra todo y empieza de cero. /compact conserva las partes importantes y elimina el resto. Si usas /clear a mitad de una tarea, pierdes todo tu avance. Si usas /compact cuando deberías haber empezado de cero, arrastras el desorden viejo a una tarea nueva.

7. Reanudar sesiones

Cada conversación que tienes se guarda automáticamente. Puedes cerrar la herramienta, apagar tu equipo y volver más tarde para continuar exactamente donde lo dejaste.

  • Claude Code: ejecuta claude --resume en tu terminal. Verás una lista de tus conversaciones anteriores. Elige una y continúa.
  • OpenCode: escribe /sessions (o /resume) dentro de la herramienta para ver tus conversaciones guardadas.

Por qué es útil:

  • Continúa mañana. Las tareas grandes a menudo toman más de una sentada. En vez de empezar de cero, simplemente reanuda donde te detuviste.
  • Trabaja en varias cosas. Puedes tener una conversación trabajando en una tarea y otra conversación trabajando en una tarea distinta. Cambia entre ellas cuando quieras.

Consejo: si guardaste un archivo de plan antes (como docs/plans/my-plan.md), también puedes iniciar una conversación nueva y decirle: "Lee docs/plans/my-plan.md y continúa desde el paso 4". El archivo de plan funciona como respaldo por si no puedes reanudar la conversación vieja. (Para más detalles, consulta el Capítulo 17 § Gestión de sesiones.)

¿Y si la IA cometió un error? Puedes deshacerlo.

A veces la IA edita el archivo equivocado, escribe mal código o malinterpreta lo que pediste. No te asustes: ambas herramientas te dejan revertir, de formas un poco distintas:

  • Claude Code: presiona Esc dos veces (con el campo de entrada vacío), o escribe /rewind. Obtienes un menú de cada prompt de la sesión; elige uno y elige qué restaurar: el código, la conversación o ambos. Ten en cuenta que esto deshace las propias ediciones de archivos de la IA, no las cosas que hizo ejecutando comandos de shell (un archivo borrado o movido no volverá por esta vía). No hay "rehacer": el rewind te lleva a un punto elegido en vez de avanzar y retroceder paso a paso, así que haz rewind con cuidado.
  • OpenCode: escribe /undo para revertir el último cambio de la IA, y /redo si cambias de opinión. Esto funciona usando git por debajo, así que tu proyecto necesita ser un repositorio git.

De cualquier forma, trata esto como una red de seguridad para experimentos, no como un sustituto de git. Para cualquier cosa que quieras conservar, confírmala con commit: los puntos de control y el deshacer son comodidades a nivel de sesión, no historial permanente.

Una pequeña diferencia

El deshacer de Claude Code cubre las ediciones de archivos pero no los comandos de terminal. Por ejemplo, si la IA ejecutó un comando que borró un archivo, el deshacer no lo recuperará. El deshacer de OpenCode cubre todo (ediciones de archivos y comandos de terminal) porque usa git para rastrear todos los cambios.

Regla rápida de decisión para los tres comandos:

Tres comandos comparados. /clear (o /new): borra toda la conversación, úsalo al cambiar de tarea. /compact: reduce la conversación conservando solo las partes importantes, úsalo cuando la misma tarea se vuelve demasiado larga. /undo: deshace lo último que hizo la IA, incluidos los cambios de archivos, úsalo cuando la IA cometió un error.

Diagnóstico: cuando el contexto se echa a perder

¿Cómo sabes cuándo el chat se ha puesto demasiado largo? Atento a estas señales:

  • La IA sigue pidiendo disculpas pero en realidad no arregla nada.
  • La IA cambia el mismo trozo de código una y otra vez sin mejorarlo.
  • La IA menciona archivos o nombres que no existen en tu proyecto.
  • La IA olvida una regla que le diste antes en la misma conversación.
  • Las respuestas de la IA se vuelven más largas y vagas en vez de más útiles.

Cuando veas cualquiera de estas señales, deja de enviar mensajes. Tu primer instinto será explicar el problema una vez más. No lo hagas. Enviar más mensajes a una conversación ya sobrecargada solo la empeora.

En cambio, reinicia:

  • Usa /compact si quieres seguir trabajando en la misma tarea (guarda las partes importantes y limpia el resto).
  • Usa /clear (o /new en OpenCode) si quieres empezar completamente de cero.

Cinco minutos de reinicio valen más que una hora peleando con una IA que ya no puede seguir el hilo de la conversación.

Diagnóstico: cuando los costos del contexto se disparan

Recuerda: una conversación larga y desordenada no solo empeora el trabajo de la IA, también te cuesta más dinero. A medida que la conversación crece, la IA tiene más texto que procesar en cada mensaje.

Un matiz importante: el almacenamiento en caché. Podrías suponer que pagas el precio completo por volver a leer toda la conversación en cada mensaje. Por lo general no es así, pero el descuento viene del proveedor del modelo, no de la herramienta. La mayoría de las API de los principales modelos (Anthropic, DeepSeek y otras) admiten el almacenamiento en caché de prompts (prompt caching): guardan la parte estable del frente de tu contexto (el prompt del sistema, tu archivo de reglas, los turnos anteriores) y la reutilizan con un descuento fuerte (a menudo alrededor de una décima parte del precio normal, a veces mucho menos), así que pagas el precio completo solo por lo que es nuevo desde tu último mensaje. Claude Code y OpenCode están hechos para mantener estable ese frente y que la caché siga funcionando, pero el almacenamiento en caché en sí es una función del proveedor, y un modelo que no lo tiene no recibe descuento. La trampa: el descuento se mantiene solo mientras el frente del contexto no cambie. Edita tu archivo de reglas, o salta de un lado a otro de tu historial, y la caché se reinicia desde ese punto y vuelves a pagar el precio completo. (Las cachés también caducan después de que una sesión queda inactiva un rato.) Por eso los picos de abajo ocurren como ocurren.

Qué notasPor qué ocurreCómo arreglarlo
Tu uso subió de golpe a mitad de la conversaciónCambiaste tu archivo de configuración (CLAUDE.md o AGENTS.md), lo que reinicia el descuento de la caché y obliga a la IA a reprocesar todo desde ceroDevuelve el archivo de configuración a como estaba, o acepta el pico de una sola vez
Cada mensaje cuesta más que el anteriorLa conversación sigue creciendo. La IA lee cada vez más archivos sin limpiar los viejosUsa /compact para reducir la conversación. Dile qué conservar: /compact conserva los nombres de archivo y las decisiones
La IA escribe respuestas extremadamente largasHiciste una pregunta sencilla pero la IA está explicando de más. O el modo de razonamiento de la IA está demasiado alto para la tareaPide "solo código, sin explicación". O baja el esfuerzo de razonamiento en la configuración
Tu factura mensual es mucho más alta de lo esperadoEstás usando el modelo de IA más potente (y caro) para cada tarea, incluso las simplesUsa el modelo caro para planificar y para problemas difíciles. Usa un modelo más barato para tareas simples como formatear o ejecutar pruebas (Concepto 4)

El patrón detrás de todas estas es el mismo: las conversaciones más cortas, enfocadas y estables cuestan menos y funcionan mejor que las largas y desordenadas.


Parte 3: El archivo de reglas

8. CLAUDE.md / AGENTS.md, bien hecho

Ambas herramientas te dejan crear un archivo especial que la IA lee al inicio de cada conversación. Piénsalo como un conjunto de instrucciones permanentes para tu proyecto. Cada vez que inicias una sesión nueva, la IA lee este archivo primero, así conoce las reglas.

  • Claude Code llama a este archivo CLAUDE.md
  • OpenCode llama a este archivo AGENTS.md

No necesitas escribir este archivo tú mismo. Ejecuta /init en cualquiera de las dos herramientas y la IA escaneará la carpeta de tu proyecto y creará el archivo por ti. Después de eso, tu trabajo es borrar las partes que no necesitas. La IA tiende a generar un archivo muy largo. La mayor parte es innecesaria.

(Para un recorrido completo, consulta el Capítulo 14 § CLAUDE.md y AGENTS.md. Para configuraciones de equipo avanzadas, consulta el Capítulo 17 § La jerarquía de configuración de CLAUDE.md.)

Cambiar entre herramientas

Si ya tienes un CLAUDE.md y cambias a OpenCode, no necesitas reescribirlo. OpenCode lee CLAUDE.md automáticamente cuando no existe ningún AGENTS.md. Si existen ambos archivos, OpenCode usa AGENTS.md e ignora CLAUDE.md.

El mayor error que comete la gente: tratan este archivo como un manual completo, metiendo en él todo sobre el proyecto: arquitectura, reglas de codificación, convenciones de nombres, preferencias del equipo. ¿El problema? La IA lee este archivo en cada mensaje. Un archivo de reglas enorme ralentiza la IA y consume tu espacio de conversación, incluso cuando la mayor parte de la información no viene al caso de la tarea actual.

Mantenlo corto. Escribe solo lo que la IA no puede deducir mirando tus archivos. Piénsalo como una tabla de contenidos, no como una enciclopedia. Señala otros archivos para los detalles y deja que la IA los cargue solo cuando los necesite:

CLAUDE.md. La sintaxis @filename carga automáticamente los archivos referenciados cuando vienen al caso:

# Project: my-app

## Stack

Next.js 14, TypeScript, Postgres, Drizzle ORM.

## Commands

- `npm run dev`: start local server
- `npm test`: run vitest
- `npm run db:migrate`: apply migrations

## Critical rules

- Never edit files in `src/generated/`. They're rebuilt by codegen.
- All API routes use the auth middleware in `src/lib/auth.ts`.
- See @docs/conventions.md for naming and folder rules.
- See @docs/db-schema.md for table structure.

AGENTS.md. La misma estructura. Una diferencia: en Claude Code, escribir @docs/conventions.md carga ese archivo automáticamente cuando se necesita. En OpenCode, esto no funciona de forma automática. Tienes dos opciones: o escribes en tu AGENTS.md "carga docs/conventions.md cuando venga al caso", o listas los archivos en opencode.json:

# Project: my-app

## Stack

Next.js 14, TypeScript, Postgres, Drizzle ORM.

## Commands

- `npm run dev`: start local server
- `npm test`: run vitest
- `npm run db:migrate`: apply migrations

## Critical rules

- Never edit files in `src/generated/`. They're rebuilt by codegen.
- All API routes use the auth middleware in `src/lib/auth.ts`.

## External references

When you encounter @docs/conventions.md or @docs/db-schema.md, load them
on a need-to-know basis with the read tool. Do not preemptively load all
references; only load what's relevant to the current task.

O, más limpio, lístalos en opencode.json:

{
"$schema": "https://opencode.ai/config.json",
"instructions": ["docs/conventions.md", "docs/db-schema.md"]
}

Esto no es solo para proyectos de código. Puedes usar el mismo archivo de reglas para cualquier tipo de trabajo: escribir ensayos, organizar investigación, llevar un blog, planificar eventos. Este es un ejemplo para un proyecto de escritura:

# Project: blog-and-newsletter

## What this is

A folder of drafts, research, and published posts. I write a weekly newsletter and occasional long-form posts.

## Where things live

- `drafts/`: in-progress posts, one per file
- `research/`: source notes and clippings, organized by topic
- `published/`: shipped posts (do not edit)

## Critical rules

- Never edit anything in `published/`. Fixes go in a new draft with a correction note.
- Footnotes go in `[brackets]` inline; we resolve them to numbered footnotes only at publish time.
- Tone: conversational, no bullet lists in body copy.

La misma idea que el ejemplo de código de arriba: mantenlo corto e incluye solo cosas que la IA no puede deducir por su cuenta.

Una prueba simple para cada línea que añadas: pregúntate: "Si quito esta línea, ¿la IA cometerá un error?" Si la respuesta es no, bórrala. Por ejemplo, no necesitas decirle a la IA que tu proyecto usa Python si todos los archivos terminan en .py. La IA puede verlo. Pero necesitas decirle a la IA "nunca edites archivos de la carpeta published/", porque no hay forma de que la IA lo sepa con solo mirar.

Añade reglas cuando algo salga mal, no antes. Si la IA comete un error que tu archivo de reglas habría evitado, añade esa regla. No intentes adivinar de antemano todos los errores posibles. Con el tiempo, tu archivo de reglas crecerá de forma natural hasta volverse algo útil.

Dos formas de escribir un archivo de reglas comparadas. La forma incorrecta (en rojo): un archivo enorme con todo sobre el proyecto, leído en cada mensaje aunque la mayor parte no se necesite. La forma correcta (en verde): un archivo corto con solo lo esencial, que señala otros archivos que se cargan solo cuando la IA los necesita. Mucho más barato y funciona mejor.


Parte 4: Personalizar tu herramienta

Ambas herramientas te dejan añadir varios tipos de función personalizada. Cada una resuelve un problema distinto:

Tres tipos de función personalizada. Comando/Skill: un único sistema de prompt guardado en un archivo que invocas escribiendo /nombre o que el modelo invoca solo a partir de su descripción. Hook/Plugin: una regla que se aplica de forma automática cada vez, sin criterio del modelo. Subagente: un ayudante aparte con su propia ventana de contexto que devuelve solo un resumen.

TipoQué haceCuándo usarlo
Comando / SkillUn prompt guardado y reutilizable en un archivo. Lo invocas escribiendo /nombre, o el modelo lo invoca automáticamente cuando la tarea coincide con su descripción.Te descubres escribiendo las mismas instrucciones una y otra vez, o quieres que el modelo aplique las instrucciones correctas sin que tengas que acordarte de pedirlo.
Hook / PluginUna regla que se ejecuta automáticamente cada vez, pase lo que paseAlgo debe ocurrir siempre (como "nunca borres esta carpeta")
SubagenteUn ayudante de IA aparte que trabaja por su cuenta y solo devuelve la respuestaNecesitas que la IA haga una búsqueda o investigación grande sin abarrotar tu conversación principal

Todos son formas de mantener tus conversaciones limpias y tu IA enfocada. Las siguientes secciones explican cada uno.

9. Comandos y skills

Son dos nombres para la misma idea: una instrucción guardada y reutilizable que vive en un archivo para no tener que volver a escribirla. Lo único que varía es cómo se invoca.

  • La invocas tú. Escribes /review y se ejecuta: tú decides cuándo.
  • La invoca el modelo. Dale al archivo una description y el modelo la ejecuta por su cuenta cuando tu tarea coincide, así no tienes que acordarte de que existe.

Un archivo así también puede llevar material de apoyo (una carpeta de plantillas, guías de estilo o documentos de referencia) que se carga solo cuando el prompt realmente se ejecuta, más unas pocas líneas de frontmatter que fijan su nombre, cuándo se activa y qué herramientas puede usar.

"Si el modelo ya sabe hacer esto, ¿por qué escribir una skill?" Es la pregunta que detiene a la mayoría de la gente, y tiene una respuesta clara. El modelo carga una enorme cantidad de conocimiento general de su entrenamiento, pero el conocimiento general tiene tres huecos que una skill cierra:

  • No conoce tus particularidades. El modelo sabe cómo funcionan los mensajes de commit en general; no conoce el formato de tu equipo, las peculiaridades de tu proyecto, los flags exactos de tu herramienta interna ni nada que haya aparecido después de su corte de entrenamiento. La skill aporta la parte que nunca estuvo en su entrenamiento.
  • Saber no es lo mismo que hacerlo igual dos veces. Pídele al modelo que "limpie esta transcripción" cinco veces y obtendrás cinco procedimientos un poco distintos. Una skill fija los pasos exactos, así obtienes el mismo procedimiento cada vez, en vez de una improvisación nueva.
  • No va a recurrir al enfoque correcto por sí solo. El conocimiento del entrenamiento solo aflora si tu prompt resulta activarlo. La description de una skill es ese disparador: pone el procedimiento correcto frente al modelo en el momento en que la tarea coincide, así no tienes que acordarte de pedirlo.

Y hace todo esto sin inflar tu conversación: solo la descripción corta está en el contexto desde el principio; las instrucciones completas y cualquier archivo de referencia se cargan solo cuando la skill realmente se dispara, la misma disciplina de contexto de la Parte 2. En una línea: el modelo aporta el conocimiento general; la skill aporta tus particularidades, un enfoque consistente y las instrucciones correctas en el momento correcto. (Piensa en una persona recién contratada, brillante, que conoce todo el campo pero todavía necesita tu manual, una lista de verificación y que le pasen la página correcta en el momento correcto.)

¿Una skill vuelve determinista al modelo? No, y vale la pena saber por qué.

Los LLM son probabilísticos: el modelo muestrea cada palabra siguiente de un rango de opciones, así que el mismo prompt puede volver redactado de forma distinta, y lo mismo pasa con la misma skill. Una skill no apaga eso. Lo que hace es estrechar el rango de salidas probables: elimina la variación del tipo "el modelo inventó un enfoque distinto esta vez", no la del nivel de palabra. Pasas de cinco procedimientos distintos a el mismo procedimiento, redactado un poco distinto en cada ejecución. Eso es consistencia de enfoque, no salida idéntica.

Cuando un paso tiene que estar garantizado (mismo resultado, siempre, sin excepciones), no le pidas al modelo que lo haga de memoria. Llévalo a código: haz que la skill ejecute un script, un formateador o una prueba, o aplícalo con un hook/plugin (siguiente sección), que es código común y por lo tanto determinista. Regla general: las skills vuelven fiable el enfoque; los scripts y los hooks vuelven garantizado el resultado.

En Claude Code, un comando y una skill son lo mismo. Pon tus archivos de prompt en .claude/skills/: una carpeta con un SKILL.md dentro. El nombre de la carpeta se vuelve el nombre del comando, así que .claude/skills/review/SKILL.md te da /review.

El caso más simple: un prompt que invocas tú. Sin description, el modelo no lo ejecutará solo; lo disparas con /review:

Review the current diff for:

1. Bugs and edge cases
2. Test coverage gaps
3. Naming and readability
4. Adherence to @docs/conventions.md

Be specific. Quote the lines you're commenting on.

Añade una description y el modelo también puede recurrir a ella por su cuenta cuando una tarea coincide:

---
name: extract-transcript
description: Extract a clean transcript from a YouTube video URL. Use when the user provides a YouTube link and asks for the transcript, captions, or text of the video.
---

# Extract YouTube transcript

1. Take the URL from the user's message.
2. Run `yt-dlp --skip-download --write-auto-sub --sub-format vtt "$URL"`.
3. Convert the VTT to plain text: strip timestamps, deduplicate overlapping captions.
4. Save to `transcripts/{video-id}.txt`.

For formatting conventions (paragraph breaks, speaker labels), see `references/style.md`.

Ese references/style.md es la parte de "llevar más": el modelo lo lee solo cuando esta skill se ejecuta, así que no te cuesta nada el resto del tiempo. Fíjate en la ruta relativa simple: dentro de una skill no usas la sintaxis de autoimportación @ de tu archivo de reglas (Parte 3). @ fuerza la carga de un archivo en el contexto en el momento en que se carga el archivo de reglas; una referencia de skill está pensada para quedarse sin cargar hasta que el modelo realmente la necesita y la lee por sí mismo. Una ruta simple (o un enlace markdown relativo como [style](references/style.md)) es justo lo que mantiene funcionando esa carga perezosa.

OpenCode mantiene los comandos y las skills como dos cosas separadas: no las ha fusionado como sí lo hizo Claude Code:

  • Una skill es una carpeta SKILL.md con instrucciones que el agente carga por su cuenta cuando una tarea coincide con su descripción. El formato es idéntico al de Claude Code, y OpenCode busca en .opencode/skills/, ~/.config/opencode/skills/ y el .claude/skills/ de Claude Code, así que una skill escrita para cualquiera de las dos herramientas funciona en ambas, sin cambios.
  • Un comando es un prompt guardado que disparas tú escribiendo /nombre, almacenado como un archivo markdown en .opencode/commands/ (proyecto) o ~/.config/opencode/commands/ (personal).

OpenCode también lista cada skill en el menú de barra como un comando invocable (mostrado con un sufijo :skill), así que puedes disparar una skill manualmente, pero las dos siguen siendo distintas por debajo: un comando es un prompt que envías, una skill es conocimiento que el agente trae cuando viene al caso.

Un prompt que invocas tú: .opencode/commands/review.md (el frontmatter es opcional; admite description, agent, model y subtask):

---
description: Review the current diff
agent: plan
subtask: true
---

Review the current diff for:

1. Bugs and edge cases
2. Test coverage gaps
3. Naming and readability
4. Adherence to docs/conventions.md

Be specific. Quote the lines you're commenting on.

Una skill que el agente puede invocar solo: .opencode/skills/extract-transcript/SKILL.md (idéntica a la skill de Claude Code de arriba; también aparece en el menú de barra como /extract-transcript:skill):

---
name: extract-transcript
description: Extract a clean transcript from a YouTube video URL. Use when the user provides a YouTube link and asks for the transcript, captions, or text of the video.
---

# Extract YouTube transcript

1. Take the URL from the user's message.
2. Run `yt-dlp --skip-download --write-auto-sub --sub-format vtt "$URL"`.
3. Convert the VTT to plain text: strip timestamps, deduplicate overlapping captions.
4. Save to `transcripts/{video-id}.txt`.

For formatting conventions (paragraph breaks, speaker labels), see `references/style.md`.
Los cambios surten efecto de inmediato, con una excepción

Un comando o skill que añades o editas dentro de una carpeta existente (.claude/skills/, ~/.claude/skills/, o los equivalentes de OpenCode) surte efecto de inmediato, sin necesidad de reiniciar. El único caso que todavía necesita reinicio es crear un directorio de skills de nivel superior totalmente nuevo que no existía cuando empezó la sesión, porque la herramienta solo puede vigilar carpetas que conocía al arrancar.

Por qué guardarlo en vez de simplemente escribirlo cada vez. Un prompt de revisión débil ("revisa mi trabajo") casi siempre obtiene un alegre "¡se ve genial!", porque el modelo tiende a darte la razón (sicofancia, del curso de Prompting con IA). Lo que funciona es una lista de verificación que lo obligue a comprobar cosas específicas una por una, para que no pueda esconderse tras un "se ve bien". Pero una lista de verificación es tediosa de reescribir, así que en un día ajetreado no lo harás, y caerás en la versión perezosa justo cuando más necesitas el rigor. Guardarla como /review elimina esa fricción: escribes el prompt exigente una vez, y de ahí en adelante una sola pulsación ejecuta la lista de verificación completa cada vez. Esa es la verdadera ventaja de guardar: no un mejor prompt (ese podrías escribirlo a mano), sino un mejor prompt que se vuelve el valor por defecto sin esfuerzo, en lugar de lo que te saltas.

Esto también funciona para tareas que no son de código. Un /standup que escribe un resumen diario a partir de tus notas: guárdalo como una skill (Claude Code) o un comando (OpenCode) con este cuerpo:

Read yesterday's note in `journal/`. Produce a 4-line standup:

1. What I shipped yesterday (1 line)
2. What I'm working on today (1 line)
3. Blockers (1 line, "none" if clear)
4. One thing I learned (1 line)

Tone: telegraphic. No filler.

La misma forma que /review, distinto dominio. El mismo truco funciona para /digest (convertir una carpeta de correos en tareas pendientes), /draft-reply (escribir una respuesta educada al correo de esta ruta) o cualquier tarea repetitiva que sigas reescribiendo. La prueba: si escribes las mismas instrucciones más de dos veces, guárdalas. ¿Quieres dispararla tú? Invócala con /nombre. ¿Quieres que el modelo recurra a ella por su cuenta? Dale una description.

Unas pocas reglas que las vuelven fiables:

  • La descripción es la línea más importante. El modelo la lee para decidir si dispara la skill. Vaga ("ayuda con videos") se activa demasiado seguido; específica ("Úsala cuando el usuario proporcione un enlace de YouTube y pida la transcripción") se activa solo cuando debe.
  • Mantén SKILL.md corto. Pon las instrucciones principales en SKILL.md y mueve el detalle adicional (guías de estilo, plantillas, material de referencia) a archivos separados en la misma carpeta. Se cargan solo cuando se necesitan.
  • Haz skills pequeñas, no grandes. Para investigar, redactar, formatear y revisar, no construyas una sola skill gigante; construye cuatro (research, draft, format, review) que hagan cada una una sola cosa y se pasen el trabajo a través de archivos. Cada una solo necesita el contexto de su propio paso, lo que mantiene la conversación limpia.

No tienes que escribirlas desde cero. Claude Code incluye un generador de skills que construye skills nuevas paso a paso; OpenCode tiene un flujo de creación de agentes parecido. (Consulta la documentación actual de tu herramienta para el comando exacto: estos se renombran a menudo.) La versión en profundidad (estructura de carpetas, frontmatter, paso de argumentos, cómo estructurar una skill de varios pasos) está en el Capítulo 14 § Enséñale a Claude tu forma de trabajar y el Capítulo 14 § Construye tus propias skills.

10. Hooks (Claude Code) / Plugins (OpenCode)

Los comandos y las skills dependen de que el modelo decida usarlos. Pero a veces necesitas una regla que se ejecute cada vez, pase lo que pase, sin depender de que el modelo la recuerde. Para eso sirven los hooks (en Claude Code) y los plugins (en OpenCode).

Por ejemplo: "Nunca dejes que la IA ejecute un comando que borre todos los archivos". No quieres que la IA decida si seguir esa regla. Quieres que se aplique automáticamente, cada vez, sin excepciones.

Ambas herramientas lo permiten, pero la forma de configurarlo es distinta en cada una. Esta es la sección donde las dos herramientas más difieren.

Los nombres pueden confundir

Claude Code usa la palabra "hook" para estas reglas automáticas. OpenCode usa la palabra "plugin". Hacen lo mismo, solo con nombres distintos. (Claude Code también tiene una función aparte llamada "plugins" que significa algo completamente distinto. Ignórala por ahora.)

Los hooks son reglas automáticas que añades a .claude/settings.json. Se ejecutan en momentos específicos: cuando empieza una sesión, cuando envías un mensaje, o justo antes de que la IA ejecute un comando; esos tres son solo ejemplos. Claude Code puede disparar hooks en alrededor de 30 eventos del ciclo de vida, desde el inicio de la sesión y el envío del prompt hasta antes/después del uso de una herramienta, la compactación y el fin de la sesión. Un hook tiene dos partes: un matcher que elige qué herramienta vigilar (por nombre, como "Bash" o "Edit|Write"), y un command (un comando de shell o un script) que decide si permitir la acción. Si ese comando termina con código 2, se bloquea a la IA para que no haga la acción.

Este es un ejemplo que impide que la IA ejecute rm -rf (un comando peligroso que borra todo):

{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.command' | grep -q 'rm -rf' && { echo 'Blocked dangerous command' >&2; exit 2; } || exit 0"
}
]
}
]
}
}

Cómo funciona: el matcher ("Bash") significa que este hook solo se ejecuta antes de los comandos de Bash. Cuando la IA está a punto de ejecutar uno, Claude Code le pasa los detalles del comando a tu script como JSON por la entrada estándar. El script extrae el texto real del comando con jq, lo revisa en busca de rm -rf con grep y, si coincide, imprime un mensaje a stderr y termina con código 2. El código de salida 2 es la señal específica que le dice a Claude Code "bloquea esta acción"; cualquier otro código de salida la deja pasar, razón por la cual el caso seguro termina en exit 0. La idea clave: el matcher elige la herramienta, el script decide si bloquear. Eso es todo lo que necesitas saber por ahora. Hay un ejemplo más detallado en la Parte 6 más abajo.

Dos detalles pequeños que vuelven los hooks más fáciles de llevar. Primero, las versiones recientes de Claude Code añaden un campo if que prefiltra un hook por herramienta y argumentos usando la misma sintaxis que las reglas de permisos, así que "if": "Bash(rm -rf *)" hace que el hook se dispare solo en los comandos que coincidan, y puedes saltarte el grep dentro del script. (Las versiones más viejas ignoran if y ejecutan el hook siempre, razón por la cual la versión con grep de arriba todavía funciona en todas partes.) Segundo, los hooks pueden vivir en ~/.claude/settings.json para aplicarse en todos tus proyectos, no solo en .claude/settings.json para uno; escribe /hooks para confirmar que un hook está registrado si no se dispara.

Los plugins son archivos pequeños de JavaScript (o TypeScript) que pones en tu carpeta de plugins de OpenCode: .opencode/plugins/ para un proyecto, o ~/.config/opencode/plugins/ para aplicarlos en todas partes. Hacen lo mismo que los hooks de Claude Code (bloquear o modificar acciones automáticamente), pero los escribes en código en vez de en JSON. Este es el mismo ejemplo de "bloquear rm -rf":

// .opencode/plugins/block-dangerous.js
export const BlockDangerousPlugin = async () => {
return {
"tool.execute.before": async (input, output) => {
if (input.tool === "bash" && output.args.command?.includes("rm -rf")) {
throw new Error("Blocked dangerous command");
}
},
};
};

Los plugins de OpenCode pueden hacer más que solo bloquear acciones. Pueden reaccionar a muchos eventos distintos: cuando empieza una sesión, cuando la IA termina de trabajar, cuando se edita un archivo, y más. También pueden enviarte notificaciones, añadir herramientas personalizadas y reconfigurar cómo se resume la conversación cuando se compacta. No necesitas aprender todo esto de inmediato. Solo debes saber que los plugins son la opción más potente si la necesitas más adelante.

Fíjate en que la carpeta está en plural: plugins/, no plugin/. Un plugin que nunca se dispara en silencio suele estar en el directorio equivocado; el cargador solo vigila .opencode/plugins/ (proyecto) y ~/.config/opencode/plugins/ (global). OpenCode avanza rápido, así que echa un vistazo a la documentación actual si algo se comporta de forma inesperada.

Un ejemplo práctico: supón que a veces dejas marcadores [TODO] en tus borradores y olvidas quitarlos antes de publicar. Puedes configurar un hook (Claude Code) o plugin (OpenCode) que bloquee automáticamente que la IA guarde cualquier archivo en la carpeta published/ si todavía contiene un marcador [TODO]. Nunca tienes que acordarte de revisar; la herramienta lo hace por ti.

¿Cuál deberías usar?

Comparación de hooks frente a plugins. Los hooks de Claude Code son reglas simples en JSON, fáciles de configurar, mejores para comprobaciones simples como bloquear un comando. Los plugins de OpenCode son archivos de JavaScript, más potentes, mejores para reglas complejas que necesitan reaccionar a muchos eventos distintos. Ambos hacen el mismo trabajo: aplicar reglas automáticamente.

Hooks de Claude CodePlugins de OpenCode
Cómo los escribesUnas pocas líneas de JSON en un archivo de configuración, que apuntan a un comando de shell o un scriptUn archivo pequeño de JavaScript
Más fácil paraReglas simples como "bloquear este comando"Reglas complejas que necesitan comprobar varias cosas
Lo que necesitas saberComandos básicos de terminal (y un poco de jq/grep para comprobaciones de contenido)JavaScript básico

Un buen hábito: comprueba en el momento del commit, no en cada edición. Es tentador hacer que un hook se dispare en cada cambio de archivo, pero interrumpir a la IA a mitad de la tarea tiende a confundirla: está detenida en medio de un pensamiento. En cambio, déjala terminar el trabajo y pon tu comprobación en el commit (el momento en que intenta guardar un punto de control con git commit). En ese punto, ejecuta tus pruebas y tu formateador. Si pasan, el commit sigue adelante. Si fallan, tu hook bloquea el commit y le devuelve el error a la IA, que lo lee y arregla el problema por su cuenta antes de volver a intentarlo. Tú no haces nada; la comprobación fallida es la instrucción. (La Parte 6, Paso 6, muestra exactamente esto en acción.)

Usa hooks/plugins para las cosas que necesitas que sean verdad el 100% del tiempo. Usa skills para las cosas que te gustaría que el modelo recordara la mayor parte del tiempo.

11. Subagentes

Un subagente es una instancia de agente aislada con su propia ventana de contexto. Le delegas una tarea; trabaja en privado; te devuelve un resumen. Sus búsquedas de archivos, sus volcados de registros y sus lecturas exploratorias nunca tocan tu hilo principal.

Por qué importa, en términos de gestión del contexto: lo más envenenante para el contexto que puedes hacer es "explorar el codebase para encontrar dónde ocurre X". Ese tipo de tarea arrastra decenas de archivos al contexto, la mayoría de los cuales no necesitas. Hacerlo en un subagente significa que tu sesión principal solo ve la conclusión ("X ocurre en src/services/billing.ts:142"), no la búsqueda.

Hay dos clases, y ayuda tenerlas claras: los subagentes que tu herramienta trae de fábrica (no los escribes tú, simplemente existen y se disparan automáticamente), y los personalizados que escribes tú mismo.

Subagentes integrados: ya los tienes. Sin configuración; la herramienta recurre a ellos cuando una tarea encaja.

  • Claude Code trae Explore (búsqueda de solo lectura en el codebase, ejecutada en un modelo rápido y barato), Plan (investigación de solo lectura usada durante el modo plan) y un agente de propósito general para trabajo de varios pasos que además necesita hacer cambios.
  • OpenCode trae Explore (búsqueda de solo lectura), General (trabajo delegado más amplio) y Scout (investigación de solo lectura de documentación externa y dependencias).

En Claude Code, el modo plan le pasa automáticamente su investigación del codebase a un subagente de solo lectura, así que la mayor parte del tiempo los usarás sin pensarlo; el modelo incluso puede entrar en modo plan por su cuenta cuando se le pide. En OpenCode, el agente Plan (un agente primario al que cambias con Tab) invoca subagentes de la misma forma, o puedes llamar a uno explícitamente con @explore.

Subagentes personalizados: los escribes tú cuando sigues lanzando el mismo tipo de trabajador con las mismas instrucciones. Un subagente personalizado es un archivo markdown con un poco de frontmatter (su nombre, cuándo usarlo, qué herramientas puede tocar) más un prompt del sistema. (Aviso: el Scout integrado de OpenCode ya hace investigación de documentación externa, así que el doc-fetcher de abajo es más un ejemplo didáctico ahí que algo que necesites construir.)

.claude/agents/doc-fetcher.md:

---
name: doc-fetcher
description: Fetches and summarizes external library documentation. Use when the user references a library and we need to understand its current API.
tools: WebFetch, Read, Write
---

You are a documentation researcher. Given a library name and a topic, fetch the official docs, extract only the API surface relevant to the topic, and write a focused summary to `tmp/docs-{library}.md`. Don't paste full pages: extract the patterns and signatures we need.

.opencode/agents/doc-fetcher.md:

---
description: Fetches and summarizes external library documentation. Use when the user references a library and we need to understand its current API.
mode: subagent
permission:
edit: ask
bash: deny
webfetch: allow
---

You are a documentation researcher. Given a library name and a topic, fetch the official docs, extract only the API surface relevant to the topic, and write a focused summary to `tmp/docs-{library}.md`. Don't paste full pages: extract the patterns and signatures we need.

Dónde ponerlos, y una forma más fácil de crear uno. Guarda el archivo en la carpeta de tu proyecto para que todo el equipo lo tenga, o en tu carpeta personal para usarlo en todos tus proyectos:

  • Claude Code: .claude/agents/ (proyecto) o ~/.claude/agents/ (personal). En vez de escribir el archivo a mano, ejecuta /agents para generar uno mediante un prompt guiado. Un detalle: un archivo que añades o editas en disco solo se carga al inicio de la siguiente sesión, mientras que los agentes creados con /agents funcionan de inmediato.
  • OpenCode: .opencode/agents/ (proyecto) o ~/.config/opencode/agents/ (personal); el nombre del archivo se vuelve el nombre del agente. O ejecuta opencode agent create para generar uno. (También puedes definir agentes en línea en opencode.json si prefieres la configuración a un archivo aparte.)

Dos cosas que vale la pena saber. Puedes darle a un subagente su propio modelo más barato y rápido (la misma idea de ajustar el modelo del Concepto 4, y la razón por la que el Explore de Claude Code se ejecuta en un modelo económico y rápido por defecto). Y en Claude Code un subagente no puede lanzar más subagentes (sin anidamiento infinito); para delegación de varias etapas, encadénalos desde tu sesión principal o recurre a los flujos de trabajo dinámicos (más abajo).

Los subagentes personalizados también funcionan para tareas que no son de código. Por ejemplo, imagina que tienes un PDF largo (un capítulo de libro de texto, un artículo de investigación o un contrato) y quieres un resumen. En vez de pegar el documento entero en tu conversación (lo que llenaría tu chat rápido), puedes enviar un subagente a leerlo y traer solo el resumen:

---
name: pdf-summarizer
description: Reads a long PDF and writes a focused summary. Use when the user references a PDF and wants the key points without dumping the whole document into the conversation.
tools: Read, Write
---

You are a research summarizer. Given a PDF path and a question, read the document, extract only the passages relevant to the question, and write a focused summary to `tmp/summary-{pdf-name}.md`. Do not paste full pages: pull out the patterns, claims, and quotes the user actually needs.

El subagente lee el PDF entero por su cuenta. Tu conversación principal nunca ve las 200 páginas. Solo recibe el resumen corto al final. Ese es el sentido completo: mantén la lectura pesada aparte para que tu conversación principal se quede limpia.

¿Cómo se usan los subagentes? De dos formas, igual para los integrados y los personalizados, en ambas herramientas:

  1. Automáticamente. Si escribiste una buena descripción para tu subagente, la IA lo usará por su cuenta cuando la tarea coincida. Así es como usarás los subagentes la mayor parte del tiempo.
  2. Manualmente. Escribe @nombre-del-subagente en tu mensaje para decirle a la IA exactamente qué subagente usar. Hazlo cuando quieras asegurarte de que se ejecute uno específico.

Regla simple: si una tarea requiere leer mucha información que tu conversación principal no necesita, envía un subagente a hacerlo. (El Capítulo 14 § Subagentes y orquestación tiene la guía completa.)

Por qué importan los subagentes. Sin un subagente: la IA busca entre decenas de archivos y todo eso llena tu conversación principal. Con un subagente: la búsqueda ocurre aparte, y solo un resumen corto vuelve a tu conversación. Mucho menos desorden.

¿Skill o subagente? Se confunden con facilidad. Ambos son reutilizables, ambos pueden dispararse solos desde una description, y ambos aparecieron en la Parte 4. La diferencia se reduce a dónde se ejecuta el trabajo:

Skill (Concepto 9)Subagente
Se ejecuta entu conversación actual: misma ventana, mismo modelo, mismas herramientassu propia ventana aislada
Qué esun procedimiento o experiencia que sigue tu agenteun trabajador aparte que hace un trozo de trabajo por ti
Qué te devuelvesalida en línea, como parte del chat en cursosolo un resumen; la parte intermedia verbosa (búsquedas, volcados de archivos, callejones sin salida) nunca entra en tu contexto
Modelo y herramientaslo que esté usando la sesiónpuede ejecutar un modelo más barato/rápido y un conjunto de herramientas restringido y aislado
Costo y latenciabarato e instantáneo: solo carga textocosto de arranque (empieza a ciegas y reúne su propio contexto), pero mantiene tu ventana limpia
Mejor paraaplicar un enfoque consistente en línea, con margen para ir y volveraislar trabajo de alto volumen (exploración, documentos largos, triaje de registros) o aislar herramientas

En una línea: una skill cambia cómo trabaja tu agente actual; un subagente le pasa el trabajo a otro aparte que reporta de vuelta. Una skill es el manual de jugadas; un subagente es un compañero de equipo al que delegas.

Y se componen en vez de competir: un subagente puede usar skills. En Claude Code o las precargas (lista skills: [api-conventions, error-handling] en el frontmatter del subagente y ese contenido está en su contexto desde el primer turno) o dejas que recurra a las skills por su cuenta en tiempo de ejecución (quita Skill de sus tools solo si quieres prohibirlo). OpenCode es igual: un subagente usa skills a menos que se le deniegue su permiso skill. Así que la elección nunca es skill o subagente; a menudo es un subagente que sostiene la skill correcta.

Ir a lo grande (solo Claude Code): para trabajos muy grandes, Claude Code puede ejecutar de decenas a cientos de subagentes en paralelo y revisar su trabajo; se llaman flujos de trabajo dinámicos. Es solo de Claude Code y usa muchos más tokens, así que queda fuera de la pila por defecto accesible en costo.


Parte 5: Conectarse con el mundo

12. MCP, usado con honestidad

MCP significa Model Context Protocol (Protocolo de Contexto de Modelo). Es una forma de conectar la IA con otras apps y servicios que ya usas: Slack, Google Docs, Notion, GitHub, bases de datos y más. Una vez conectada, la IA puede leer y escribir en esos servicios directamente.

"¿Esto no es solo una API?" Casi, y vale la pena tenerlo claro antes de conectar nada. MCP es un envoltorio estándar alrededor de las API y otras herramientas, no un reemplazo de ellas. Una API en crudo necesita que alguien escriba el pegamento cada vez (manejar la autenticación, dar forma a las solicitudes y decirle al modelo cómo llamarla); un servidor MCP ya hizo eso y anuncia sus herramientas, así que el agente puede descubrirlas y usarlas sin código de integración. Así que la verdadera pregunta nunca es "¿MCP o API?", sino "¿esto merece una conexión permanente, o el agente puede simplemente llamar a la cosa directamente?". Las reglas de usar/saltar de abajo responden justo eso.

Tanto Claude Code como OpenCode admiten MCP. Como MCP es un estándar abierto, el mismo servidor funciona con cualquiera de las dos herramientas, pero la configuración no se transfiere, así que lo añades por separado en cada una (guardan sus conexiones en archivos distintos).

Así se añade una conexión MCP en cada herramienta:

Añade servidores con la CLI (claude mcp add --transport http <name> <url>), que por defecto escribe en ~/.claude.json (personal). Añade --scope project para escribir en su lugar un .mcp.json compartible en la raíz de tu proyecto. Luego ejecuta /mcp dentro de Claude Code para revisar el estado e iniciar sesión en cualquier servidor que necesite OAuth. (Nota: esto no es .claude/settings.json, que es para permisos y hooks.)

Se declara en opencode.json. Usa "type": "remote" para un servidor alojado (con una url) o "type": "local" para uno que se ejecuta como un proceso local (con un command como ["npx", "-y", "some-mcp"]):

{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"sentry": {
"type": "remote",
"url": "https://mcp.sentry.dev/mcp",
"oauth": {}
},
"context7": {
"type": "remote",
"url": "https://mcp.context7.com/mcp"
}
}
}

Para servidores que necesitan inicio de sesión, ejecuta opencode mcp auth <name> para hacer el flujo de OAuth; opencode mcp list muestra el estado de cada servidor.

Por qué es útil: sin MCP, la IA solo puede trabajar con los archivos de tu equipo. Con MCP, la IA puede alcanzar más allá de tu equipo e interactuar con servicios en línea. Por ejemplo: podrías pedirle a la IA "revisa mi Slack por si hay mensajes de mi equipo de hoy" o "crea un nuevo issue en GitHub para este error", y la IA lo haría de verdad en vez de solo decirte cómo hacerlo tú.

El uso más serio: conectar tu sistema de registro. Un sistema de registro (system of record) es el hogar autoritativo de un tipo de dato dado, la única copia que todos tratan como la verdad: tu base de datos, tu CRM, tu sistema de tickets, una base de conocimiento de la empresa. MCP es como apuntas el agente a uno para que responda a partir de datos vivos y autoritativos, en lugar de una copia obsoleta que pegaste o un dato a medias recordado del entrenamiento. Pregunta "¿cuál es el estado actual del pedido 4471?" y el agente consulta la base de datos real a través de MCP en vez de adivinar. Así es también como un cuerpo de conocimiento (un libro, un conjunto de documentación, un wiki interno) se vuelve consultable: levanta un servidor MCP delante de él y cualquier herramienta puede hacerle preguntas y obtener respuestas ancladas en la fuente. Cada AI Worker también se ejecuta contra un sistema de registro usando MCP.

Pero ten cuidado: no conectes todo. Cada conexión MCP puede ocupar espacio en tu conversación, incluso cuando no la estás usando. La propia documentación de OpenCode advierte: "Ciertos servidores MCP, como el servidor MCP de GitHub, tienden a añadir muchos tokens y pueden exceder con facilidad el límite de contexto." Una diferencia que vale la pena conocer: Claude Code ahora difiere las definiciones de herramientas de MCP por defecto (carga la descripción completa de una herramienta solo cuando está a punto de usarla), así que los servidores adicionales cuestan poco contexto ahí. OpenCode las carga por adelantado, así que sé especialmente selectivo de ese lado. De cualquier forma, el hábito es el mismo: conecta solo lo que de verdad necesitas. Esa es también la verdadera respuesta a la preocupación de que MCP infla el contexto: la solución es estratificar (cargar las herramientas de forma perezosa, apoyarte en la CLI para los trabajos simples y empujar el trabajo pesado de MCP a un subagente del Concepto 11), no abandonar MCP.

Cuándo usar MCP y cuándo saltárselo:

  • Usa MCP cuando el servicio necesita que la IA inicie sesión o se mantenga conectada. Por ejemplo: leer tu Google Calendar, navegar por un sitio web o consultar una base de datos que requiere contraseña.
  • Sáltate MCP cuando la IA puede obtener el mismo resultado ejecutando un comando de terminal simple. Por ejemplo: en vez de conectarte a GitHub a través de MCP, la IA puede simplemente ejecutar gh issue list en la terminal para ver tus issues. Sin inicio de sesión, sin conexión, sin configuración adicional.

Empieza con una o dos conexiones que de verdad necesites. No instales diez solo porque están disponibles.


Parte 6: Un ejemplo práctico completo, dos veces

Aquí es donde todo se junta. Harás una tarea completa de principio a fin, usando los conceptos que aprendiste arriba. La tarea se hace dos veces: una en Claude Code y otra en OpenCode, para que veas que los pasos son casi iguales.

No se requiere programar. Este ejemplo usa notas de reuniones, pero no necesitas ser programador para seguirlo. Si alguna vez tomaste notas en una reunión, una clase o un proyecto en grupo, ya entiendes la tarea.

Tu tarea

Tienes una carpeta llamada notes/ con cinco archivos de notas de reuniones. El problema: están desordenados. Cada reunión escribió sus tareas pendientes de una forma distinta. Algunas usan el encabezado "Action Items". Algunas usan "Todos". Una usa "todo" en minúsculas. Algunas tareas pendientes están enterradas dentro de otras secciones donde no pensarías en buscar. Y algunos elementos están marcados como [private] o [HR], lo que significa que nunca deben compartirse públicamente.

Tu meta: crear un único archivo limpio llamado weekly-actions.md que:

  • Liste cada tarea pendiente de las cinco reuniones
  • Las agrupe por quién es responsable
  • Muestre de qué reunión salió cada elemento
  • Deje fuera todo lo marcado como [private] o [HR]
  • No omita ni un solo elemento
  • Te advierta si alguna fecha límite cae en un día festivo
📁 Consigue primero los cinco archivos de partida (haz clic para expandir)

Copia estos en una carpeta notes/ antes de empezar. El ejemplo está diseñado en torno a ellos: cada archivo cumple un papel específico, así que si te saltas uno, uno de los pasos de abajo deja de funcionar. (¿Prefieres saltarte la configuración de carpetas? Pega los cinco archivos directamente en el chat de tu herramienta y pídele que los trate como el contenido de notes/.)

notes/2026-12-07-monday-team-meeting.md

# Monday Team Meeting - 2026-12-07

Attendees: @sara, @diego, @priya, @marcus

## Discussion

Reviewed last month's customer satisfaction scores. Renewals are down slightly in the small-business segment.

## Action Items

- @sara: draft a revised welcome email by Dec 18
- @diego: check spam-folder reports with our email vendor by Dec 16
- @marcus: pull renewal numbers for the last two quarters and share with the team
- @sara: finalize offer terms for the new account manager [HR]

notes/2026-12-08-customer-feedback.md

# Customer Feedback Review - 2026-12-08

Attendees: @sara, @amara, @marcus

## Summary

Read through the top twenty customer comments from last week. Three themes came up: pricing page is confusing, the call-back service is slow, and the FAQ on the website is out of date.

## Todos

- rewrite the pricing page in plain language
- @marcus: log a complaint with the call center vendor about response times
- look into why the FAQ has not been updated in six months
- @amara: draft a customer note explaining the upcoming changes
- review all printed brochures for outdated photos and pricing

notes/2026-12-08-q1-planning.md

# Q1 2027 Planning - 2026-12-08

Attendees: @sara, @diego, @amara, @lukas

## Initiatives

We walked through the four candidate initiatives for Q1.

### Year-end promotional campaign

Time-bound: wraps before the holiday break.

#### Action Items

- @amara: finalize the year-end promotional brochure by Dec 25
- @lukas: confirm placement with paid media partners by Dec 20

### Onboarding overhaul

Top priority next quarter.

## todo

- @diego: write the project brief by Jan 15
- @sara: own messaging and visual direction

notes/2026-12-09-all-hands-prep.md

# All-Hands Prep - 2026-12-09

Attendees: @sara, @marcus

## Agenda

Walked through the December all-hands agenda. Most slides are in good shape; a couple still need owners.

## Next Steps

- @marcus: set up the video call and record a practice run
- @sara: finalize the Q4 numbers slide
- @sara: prepare the bonus and compensation talking points [private]
- @marcus: book the venue for the team holiday dinner

notes/2026-12-11-vendor-review.md

# Vendor Review - 2026-12-11

Attendees: @sara, @amara, external partner

## Summary

Confidential contract negotiation with our printing and fulfillment vendor. Details under NDA.

## Action Items

- @sara: circulate the revised contract to the vendor [private]
- @amara: draft the internal announcement once terms are agreed [private]
- @sara: review the legal redlines on the new pricing schedule [private]

Cómo está organizado este recorrido

Abajo hay ocho pasos. Cada paso sigue el mismo patrón:

  1. Qué hacer en Claude Code (las instrucciones exactas)
  2. Por qué importa este paso (una breve explicación)
  3. Qué cambia en OpenCode (si algo cambia, se anota aquí. Si dice "idéntico", entonces ambas herramientas funcionan igual en ese paso)

Paso 1: Configura tu archivo de reglas

En Claude Code: abre Claude Code en la carpeta de tu proyecto. Ejecuta /init. La IA escaneará tu carpeta y creará un archivo llamado CLAUDE.md. Será demasiado largo. Borra la mayor parte y conserva solo esto:

# weekly-rollup

## Layout

- `notes/`: meeting notes, one file per meeting
- `weekly-actions.md`: the rollup we are creating
- `plans/weekly-rollup-plan.md`: the plan we will save and reuse

## Critical rules

- Action items can appear under `## Action Items`, `## Todos`, `## Next Steps`, or `## todo` (one meeting uses lowercase). Look at all heading levels, not just the top.
- Owners are written as `@name`. Items with no owner go to an "Unassigned" section.
- Never include any bullet tagged `[private]` or `[HR]`.

Por qué importa: la IA lee este archivo al inicio de cada mensaje. Un archivo largo ralentiza las cosas y desperdicia espacio. Así que conservas solo lo que la IA no puede deducir mirando la carpeta misma. La regla de privacidad es especialmente importante, porque la IA no tiene forma de saber que los elementos [private] deben ocultarse.

En OpenCode: lo mismo, pero el archivo se llama AGENTS.md en vez de CLAUDE.md. Si ya tienes un CLAUDE.md, OpenCode también lo leerá.

Configuración de una sola vez: convierte esta carpeta en un repositorio git

Un par de pasos posteriores guardan tu trabajo con git commit (y el deshacer de OpenCode también se apoya en git). Si esta carpeta todavía no es un repositorio, ejecuta git init una vez ahora para que esos pasos funcionen. Ya que estás, en Claude Code la comprobación de seguridad del Paso 6 usa una herramienta pequeña llamada jq; la mayoría de los sistemas la tienen, pero si el Paso 6 da el error "jq: command not found", instálala (brew install jq, o apt install jq en Linux).


Paso 2: Haz un plan antes de hacer nada

En Claude Code: presiona Shift+Tab dos veces para activar el modo plan (la IA puede leer pero no cambiar nada). Luego escribe:

Read every file in notes/. Produce weekly-actions.md grouped by
owner. For each item include the action, the source filename, and
the meeting date. Skip anything tagged [private] or [HR]. Do not
lose any action items.

La IA piensa un minuto y vuelve con un plan escrito de lo que hará.

Por qué importa: leer un plan toma 30 segundos. Deshacer un error toma mucho más. Planifica siempre primero.

En OpenCode: presiona Tab para cambiar al modo Plan. Todo lo demás es igual.


Paso 3: Revisa el plan y corrige errores

En Claude Code: lee el plan con cuidado. Probablemente dos cosas estarán mal en él.

La primera: solo mencionará los encabezados de nivel superior (## Action Items, ## Todos). Pero uno de tus archivos de reuniones (las notas de planificación del Q1) esconde tareas pendientes dentro de ### Year-end promotional campaign, con un #### Action Items debajo. El plan se las saltaría.

La segunda: no dirá qué hacer con las tareas pendientes que no tienen responsable (sin @name al lado, como el "rewrite the pricing page in plain language" del archivo de comentarios de clientes). Esas desaparecerían en silencio.

Le replicas:

Two changes. (1) Look at all heading levels, not just the top.
Some action items live under sub-headings. (2) Items without an
owner go to an "Unassigned" section at the bottom; never drop
them.

La IA actualiza el plan. Pídele que guarde el plan final en plans/weekly-rollup-plan.md para que puedas reutilizarlo la semana que viene.

Por qué importa: es mucho más fácil arreglar un plan que arreglar trabajo terminado. Atrapa los problemas ahora, cuando no cuesta nada.

En OpenCode: los mismos pasos, sin diferencias.


Paso 4: Deja que la IA haga el trabajo

En Claude Code: presiona Shift+Tab para salir del modo plan. Dile a la IA que siga adelante.

La IA lee los cinco archivos de reuniones, crea weekly-actions.md, agrupa los elementos por responsable, quita los elementos [private] y [HR] y pone los elementos sin responsable en una sección "Unassigned". Lo ves suceder.

Por qué importa: como planificaste primero, el resultado es casi correcto al primer intento.

Revisa dónde terminó el archivo

weekly-actions.md debería estar en la carpeta principal de tu proyecto, junto a la carpeta notes/, no dentro de ella. Si la IA lo puso en el lugar equivocado, puede que a tu archivo de reglas del Paso 1 le falte la sección Layout.

En OpenCode: la IA te pedirá aprobación antes de escribir cada archivo. Puedes decir que sí, o configurar la aprobación automática en opencode.json para ejecuciones futuras.


Paso 5: Limpia la conversación

En Claude Code: la conversación ya es larga. La IA ha leído todas las notas de reuniones, y todo ese texto sigue ocupando espacio, incluidos los elementos privados que se saltó. Ya no necesitas nada de eso. Escribe:

/compact keep the heading rules, the owner list, and the
private/HR exclusion rule

La IA resume la conversación y descarta todo lo demás. Solo quedan las partes que le dijiste que conservara.

Por qué importa: una conversación larga y abarrotada empeora a la IA, no la mejora. Además cuesta más. Limpia lo que ya no necesitas, sobre todo el contenido privado que no debería quedarse en memoria.

En OpenCode: el mismo comando, el mismo resultado.


Paso 6: Añade una comprobación de seguridad automática

En Claude Code: antes de guardar tu trabajo, quieres asegurarte de que ninguna reunión quedó fuera por accidente. Añadirás un hook: una comprobación automática que se ejecuta cada vez que la IA intenta guardar (commit) tu trabajo. ("Guardar" aquí significa el punto de control de git commit, el momento en que registras una instantánea en git, no solo escribir el archivo weekly-actions.md.)

Este es el único paso de aspecto técnico

La introducción prometió nada de programación, y eso sigue en pie: aquí vas a pegar un bloque, no a escribirlo, y no necesitas entender el código. La explicación en lenguaje sencillo justo después es todo lo que necesitas. (También depende de que esta carpeta sea un repositorio git; consulta el consejo de configuración del Paso 1.)

No le pidas al modelo que escriba este: pégalo

Este es el único lugar del capítulo donde pegas tú mismo un bloque de configuración en vez de dejar que el modelo lo escriba. Hay dos razones, ambas aprendidas a la mala.

(1) "Hook" es ambiguo. Si le dices al modelo "crea un hook", Claude Code puede recurrir a un git hook (un archivo en .git/hooks/) en lugar de un hook de Claude Code (una entrada en .claude/settings.json). Son cosas distintas; quieres la segunda.

(2) La IA romperá la comprobación de seguridad sin querer. Tu archivo de reglas dice que se salte los elementos [private]. Si le pides a la IA que escriba el hook, leerá esa regla y "servicialmente" añadirá la misma lógica de salto al hook. Eso significa que la reunión de revisión de proveedores (donde cada elemento es [private]) queda ignorada en silencio por el hook, y nunca se levanta ninguna advertencia. Pero todo el sentido del hook es atrapar exactamente ese caso: una reunión que parece haberse omitido. No puedes pedirle a la IA que construya una comprobación de seguridad contra sus propias reglas. Siempre encontrará la forma de ser "servicial" y vencer la comprobación.

El movimiento seguro es simplemente pegar la configuración.

Abre .claude/settings.json (crea el archivo si no existe) y pega esto exactamente:

{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.command' | grep -q '^git commit' || exit 0; for f in notes/*.md; do grep -q \"$(basename $f)\" weekly-actions.md || { echo \"Missing: $f\" >&2; exit 2; }; done"
}
]
}
]
}
}

Qué hace esto en lenguaje sencillo: cada vez que la IA intenta guardar (commit) tu trabajo, este hook comprueba una cosa simple: ¿cada archivo de reunión de notes/ se menciona en algún lugar de weekly-actions.md? Si falta algún nombre de archivo, bloquea el guardado. No revisa el contenido, no mira las etiquetas [private], no hace excepciones. Solo revisa los nombres de archivo. Ese es todo el sentido.

Observa qué pasa. Dile a la IA que haga commit. La comprobación de seguridad se dispara: Missing: notes/2026-12-11-vendor-review.md. ¿Por qué? Porque cada tarea pendiente de esa reunión estaba etiquetada como [private], y tus reglas del Paso 1 dicen que se salte los elementos privados. Así que cuando la IA construyó el resumen, no tenía nada que escribir de ese archivo, y el nombre del archivo nunca apareció. El hook no sabe nada de eso. Solo ve un nombre de archivo que falta y bloquea el guardado.

El modelo lee el error y parcha el resumen con una entrada de marcador de posición que nombra el archivo explícitamente, por ejemplo:

## From 2026-12-11-vendor-review.md

- All items confidential — see meeting owner.

El nombre del archivo ya está presente en weekly-actions.md, el grep del hook lo encuentra, el commit sigue adelante. Nada privado se filtró al resumen; el rastro de auditoría está intacto.

Tú no hiciste nada durante este bucle. La red de seguridad atrapó el error y el modelo se corrigió solo.

Por qué. Las cosas que quieres que sean verdad cada vez no deberían depender de que el modelo lo recuerde. Deberían comprobarse automáticamente. Y la comprobación debería vivir en un lugar que el modelo no pueda reescribir en silencio para complacerse a sí mismo: por eso este es un pegado, no un prompt.

Qué cambia en OpenCode. OpenCode llama a esto plugins en vez de hooks, y se escriben como un archivo pequeño de JavaScript. La misma idea, el mismo resultado, la misma lógica de pegar-no-pedir. Crea .opencode/plugins/check-rollup-complete.js (puede que la carpeta todavía no exista) y pega esto:

// .opencode/plugins/check-rollup-complete.js
import { readdirSync, readFileSync } from "fs";

export const CheckRollupCompletePlugin = async ({ $ }) => {
return {
"tool.execute.before": async (input, output) => {
if (
input.tool === "bash" &&
output.args.command?.startsWith("git commit")
) {
const rollup = readFileSync("weekly-actions.md", "utf8");
const missing = readdirSync("notes")
.filter((f) => f.endsWith(".md"))
.filter((f) => !rollup.includes(f));
if (missing.length) {
throw new Error(`Missing from rollup: ${missing.join(", ")}`);
}
}
},
};
};

La misma forma: lista cada archivo de notes/, comprueba que cada nombre base esté en el resumen, lanza un error si falta alguno. Sin filtro [private] dentro. El comportamiento es idéntico a la versión de Claude Code: archivo que falta, commit bloqueado, modelo que se corrige solo.

El material de hooks/plugins en profundidad (códigos de salida, sintaxis del matcher, la lista completa de eventos) está en el Capítulo 14 § Hooks y extensibilidad (y Plugins: ponerlo todo junto para el lado de OpenCode).


Paso 7: Envía una tarea secundaria a un ayudante

En Claude Code: algunas tareas pendientes tienen fechas límite como "by Dec 25" o "before year-end". Quieres comprobar si alguna de esas fechas cae en un día festivo. Escribe:

Use a research helper to look up the 2026 international public
holidays list and write the dates to tmp/holidays-2026.md.

Un ayudante (subagente) va a la web, encuentra las fechas de los festivos y las guarda en un archivo pequeño. Tu conversación principal nunca ve la página web completa. Solo ve el archivo pequeño con las fechas.

Este es el mismo patrón que el subagente del Concepto 11: un ayudante con acceso a la web que devuelve solo un resumen. El de allá se llamaba doc-fetcher y estaba descrito de forma estrecha para documentación de bibliotecas, así que para una búsqueda general como esta, o le das a ese ayudante una descripción más amplia (por ejemplo, "buscar y resumir referencias y consultas externas") o creas un pequeño agente researcher con las herramientas WebFetch y Write. El sentido del paso es la delegación, no el agente exacto.

La IA luego compara las fechas límite de tu resumen con las fechas de los festivos y añade una advertencia como ⚠ falls on Christmas Day junto a cualquier fecha límite que caiga en un festivo.

Por qué importa: si la IA hubiera buscado la página web directamente, habría volcado una enorme cantidad de texto en tu conversación. Enviar un ayudante mantiene tu conversación limpia.

En OpenCode: llama a tu ayudante de investigación directamente por su nombre, por ejemplo @researcher. El mismo resultado.


Paso 8: Guarda esto como una skill para la próxima vez

En Claude Code: harás esta tarea cada semana. En vez de recordar todos estos pasos el próximo viernes, pídele a la IA que guarde todo como una skill:

Create a skill at ~/.claude/skills/weekly-meeting-rollup/SKILL.md
based on what we just did. Include: the four heading variants,
the all-headings rule, the private/HR exclusion, the Unassigned
section, the missing-file check, and the holiday cross-reference.

El próximo viernes, solo escribe "do the weekly rollup" y la IA usará esta skill automáticamente. Todas las reglas que configuraste hoy (variantes de encabezado, filtro de privacidad, sección sin asignar, comprobación de festivos) se aplican cada vez sin que tengas que recordar nada.

Por qué importa: el trabajo que hiciste hoy no fue solo para hoy. Le enseñaste a la IA cómo hacer esta tarea de ahora en adelante.

En OpenCode: la skill se guarda en una carpeta un poco distinta, pero el archivo en sí es idéntico. Puedes copiarlo entre las dos herramientas y funciona en ambas.


Qué acaba de pasar

Mira de nuevo los ocho pasos. Ninguno te exigió escribir código. Ninguno te exigió saber qué es una API. Lo que de verdad hiciste fueron ocho pequeños actos de gestionar la atención del modelo: decirle qué mirar, cuándo planificar, cuándo olvidar, cuándo delegar, cuándo dejar de confiar en sí mismo y cuándo recordar.

Eso es todo el capítulo.

Y mira lo poco que difirió entre las dos herramientas:

  • Un nombre de archivo distinto para el archivo de reglas (CLAUDE.md frente a AGENTS.md)
  • Una pulsación de tecla distinta para entrar en modo plan (Shift+Tab frente a Tab)
  • Un lenguaje distinto para el archivo de la red de seguridad (JSON frente a JavaScript)
  • Una carpeta distinta para la skill al final (pero el mismo archivo)

Eso es todo.

Los ocho pasos del ejemplo práctico en paralelo en ambas herramientas. Cada paso muestra qué haces en Claude Code y qué cambia en OpenCode. Las diferencias entre las dos herramientas son pequeñas: un nombre de archivo distinto, un atajo de teclado distinto o un formato de configuración distinto. El razonamiento detrás de cada paso es idéntico.

El pensamiento es la herramienta. Las configuraciones son decoración. Aprende a pensar de esta forma y tus habilidades sobreviven a cualquier herramienta que termine ganando.


13. ¿Terminal, IDE o escritorio?

Ambas herramientas se ejecutan en varios lugares.

Claude Code: terminal (CLI), plugins de VS Code / JetBrains, una aplicación de escritorio (un espacio de trabajo Code en macOS y Windows, no en Linux, hecho para ejecutar varias sesiones en paralelo, cada una en su propio worktree de git), la web (claude.com), una aplicación móvil y sesiones alojadas en la nube para trabajo asíncrono que puedes revisar desde cualquiera de ellas.

OpenCode: terminal (la TUI es la insignia), una aplicación de escritorio (en beta, en macOS / Windows / Linux), una extensión de VS Code más otros editores como Zed a través de su servidor ACP, una interfaz web mediante el SDK, e integraciones como un agente de GitHub y un bot de Slack.

Elige la que se ajuste a lo que estás haciendo. Si escribes código, el plugin de VS Code o JetBrains es excelente porque puedes ver a la IA editar tus archivos en tiempo real. Si ejecutas tareas más largas y quieres hacer otras cosas mientras esperas, la terminal funciona bien. Para trabajo que no es de código, las opciones más fáciles son las apps web o, del lado de Claude, la pestaña Cowork de la app de escritorio, el modo de trabajo de conocimiento que se sitúa junto a la pestaña Code (que es Claude Code) en la misma app.

La recomendación fuerte, en cualquiera de las dos herramientas: empieza en la terminal o en un plugin de IDE. Una vez que entiendes qué pasa por debajo (qué archivos lee el modelo, qué comandos ejecuta, qué decisiones toma), cualquier otra interfaz se vuelve un envoltorio delgado que puedes leer a través de él. Si empiezas en una interfaz muy abstraída, te costará depurar cuando las cosas se tuerzan, porque no sabrás qué puede torcerse.

14. Construye una biblioteca personal de contexto, despacio

Una vez que tengas unos pocos proyectos usando cualquiera de las herramientas, notarás que escribes cosas parecidas en cada archivo de reglas: tu estilo de código, tus convenciones de commit, tu filosofía de pruebas. Deja de copiar y pegar.

Pon las partes compartidas en tu configuración de inicio y referéncialas desde el archivo de reglas de cada proyecto:

~/.claude/CLAUDE.md (cargado en cada proyecto):

# CLAUDE.md

@~/.claude/style/typescript.md
@~/.claude/style/commits.md

Luego mantén el propio CLAUDE.md de cada proyecto para lo que es único de ese proyecto; el archivo global de arriba (y los estilos que importa) se trae a todas partes automáticamente.

~/.config/opencode/:

// ~/.config/opencode/opencode.json
{
"$schema": "https://opencode.ai/config.json",
"instructions": ["style/typescript.md", "style/commits.md"]
}

Más un AGENTS.md específico del proyecto para lo que es único de ese proyecto.

La misma idea funciona para las skills. Una skill commit-message o una skill code-review en ~/.claude/skills/ (que OpenCode también lee) o ~/.config/opencode/skills/ está disponible en todas partes automáticamente.

No intentes construir todo esto de golpe. Es tentador pasar un fin de semana montando la biblioteca personal perfecta. No lo hagas. En cambio, añade cosas una a una, solo cuando de verdad las necesites. Añade una guía de estilo después de que la IA escriba código en el estilo equivocado. Añade una skill de commit después de escribir las mismas instrucciones de commit por tercera vez. Una biblioteca construida a partir de problemas reales se mantiene pequeña y útil. Una biblioteca diseñada por adelantado termina grande e ignorada.

15. Memoria más allá de lo básico

Para la mayoría de la gente, reanudar conversaciones viejas y mantener un buen archivo de reglas es suficiente. Pero si quieres que la IA recuerde cosas incluso después de empezar una conversación nueva, estas son tus opciones:

  • Una carpeta notes/ en tu proyecto. Después de terminar una tarea, pídele a la IA que escriba un resumen corto de lo que hizo y qué decisiones se tomaron. Guárdalo en una carpeta notes/. La próxima vez, la IA puede leer esas notas para ponerse al día. Simple, sin configuración, funciona en ambas herramientas.
  • Un servidor MCP de memoria. Estos le dan a la IA una forma de guardar y recordar información entre conversaciones. Existen varios gratuitos y funcionan en ambas herramientas.
  • Búsqueda entre conversaciones viejas. Algunas configuraciones te dejan buscar en tus conversaciones pasadas para encontrar "¿ya resolví esto antes?". Consulta la documentación de tu herramienta para ver qué hay disponible.

Las herramientas están empezando a hacer la versión simple por ti. Claude Code ahora tiene una memoria automática integrada: a medida que trabajas, escribe sus propias notas cortas sobre tus correcciones y preferencias y las recarga al inicio de cada sesión; la idea de la carpeta notes/, automatizada. (Funciona en los planes Claude Pro y Max y todavía se está desplegando, así que no cuentes con ella en todas partes aún; la carpeta notes/ manual es el enfoque que funciona en cualquier herramienta, con cualquier modelo.) De cualquier forma, esto solo refuerza la regla de abajo.

Elige según lo que de verdad necesites. Si solo quieres recordar decisiones de un proyecto, una carpeta notes/ es suficiente. Si quieres que la IA recuerde todo en todos tus proyectos, necesitas algo más avanzado. No montes herramientas complejas antes de tener un problema real que resolver.


Parte 8: Las dos herramientas juntas, Claude Code y OpenCode

Hasta ahora, este curso ha tratado a Claude Code y OpenCode como dos opciones: elige una y apréndela. Pero una vez que te sientes cómodo con lo básico, puedes de verdad usar ambas herramientas juntas en el mismo proyecto. Esto no es solo un plan de respaldo. Cada herramienta tiene fortalezas que la otra no tiene, y combinarlas puede ser más eficaz que usar cualquiera de las dos por separado.

Mantenerlo seguro: worktrees de git

Antes de mirar los patrones, hay un problema de seguridad que resolver primero.

Si ejecutas dos sesiones de IA en el mismo proyecto al mismo tiempo, y ambas intentan editar el mismo archivo, una sobrescribirá los cambios de la otra. Eso es un desastre.

La solución se llama worktrees de git. Piénsalo como hacer una copia de la carpeta de tu proyecto, pero más inteligente. Cada copia (llamada "worktree") es su propio espacio de trabajo donde la IA puede trabajar de forma independiente. Los cambios en un worktree no afectan al otro. Cuando ambos terminan, fusionas los resultados con git.

Así se configura:

Cómo funciona paso a paso:

# Step 1: Go to your project folder
cd myproject

# Step 2: Create two worktrees (two separate copies, each on a NEW branch)
# The -b flag creates the branch; without it, git expects the branch to already exist.
git worktree add -b my-branch-1 ../myproject-copy1
git worktree add -b my-branch-2 ../myproject-copy2

Ahora tienes dos carpetas separadas (myproject-copy1 y myproject-copy2), cada una con su propia copia de tu proyecto en una rama distinta.

# Step 3: Open Claude Code in one copy
cd ../myproject-copy1
claude

# Step 4: Open OpenCode in the other copy (in a separate terminal window)
cd ../myproject-copy2
opencode

Ambas herramientas de IA trabajan ahora al mismo tiempo en copias distintas. No pueden sobrescribir los archivos de la otra.

# Step 5: When you're happy with the work, go back to the main folder and
# merge each branch into your main branch (it may be called main or master).
# Because the two sessions worked in different files (see the rule below),
# these merges should apply cleanly.
cd ../myproject
git merge my-branch-1
git merge my-branch-2

# Step 6: Clean up the copies (this removes the worktrees; your merged
# commits are safe in the main branch)
git worktree remove ../myproject-copy1
git worktree remove ../myproject-copy2

La regla de edición de archivos, en tres niveles:

PatrónVeredicto
Dos sesiones editando el mismo archivo a la vezMala: gana la última escritura, se pierden las ediciones de la otra sesión
Dos sesiones editando directorios distintosBuena: sin contención, la aceleración en paralelo es real
Una sesión edita, confirma y le pasa el relevo a la otraAceptable: el commit es el artefacto del relevo

Regla general: empieza con una sesión por tarea. Añade una segunda solo cuando puedas señalar con claridad qué archivos posee cada sesión. El costo mental de alternar entre dos sesiones agentic es real; solo vale la pena cuando el trabajo de verdad se reparte.

La capa compartida que hace funcionar cualquiera de estas cosas son las reglas y skills del proyecto. Ambas herramientas leen el mismo CLAUDE.md y el mismo directorio .claude/skills/ (los Conceptos 8 y 9 lo cubren). Una sola fuente de verdad para las convenciones del proyecto; dos herramientas que la consumen.

Patrón 1: división planificar / ejecutar

La parte difícil de cualquier tarea es averiguar qué hacer: leer el proyecto, decidir un enfoque, pensar qué podría salir mal. La parte fácil es hacerlo de verdad una vez que tienes un plan claro. Los modelos de IA reflejan esto: los modelos más potentes (y caros) son los mejores en la parte de pensar y planificar. Los modelos más baratos pueden manejar perfectamente la parte directa de "solo sigue estas instrucciones".

Cómo hacerlo en la práctica:

  1. Abre Claude Code en modo plan. Describe lo que quieres. Deja que cree un plan detallado.
  2. Guarda el plan en un archivo (como docs/plans/my-feature.md).
  3. Abre OpenCode en un worktree aparte, usando un modelo de IA más barato. Dile: read docs/plans/my-feature.md and implement it.
  4. OpenCode sigue el plan: edita archivos, ejecuta pruebas, arregla el formato.
  5. (Opcional) Vuelve a Claude Code para revisar los cambios antes de fusionarlos.

El archivo de plan es el contrato. Sobrevive a la pérdida de la sesión, codifica las decisiones de arquitectura y le permite a la sesión barata trabajar sin rehacer el pensamiento caro. Este patrón por sí solo suele entregar la mayor parte del ahorro que los equipos esperan obtener de "cambiar a un modelo más barato", sin perder la calidad de la planificación con un modelo de frontera.

Patrón 2: revisión entre modelos

En el curso de Prompting con IA aprendiste que hacer que una segunda IA revise el trabajo de la primera atrapa más errores. Aquí hacemos lo mismo con las herramientas de codificación.

Por qué funciona: la IA que escribió el código es la peor para revisarlo. Tiene los mismos puntos ciegos que causaron los errores en primer lugar. Un modelo de IA distinto (de una empresa distinta, entrenado con datos distintos) notará cosas que el primero pasó por alto.

Cómo hacerlo:

  1. Herramienta A (cualquier modelo) escribe el código en su propio worktree.
  2. Herramienta B (un modelo de IA distinto) lee los cambios y escribe una revisión en docs/reviews/my-feature.md. No edita ningún código; solo escribe comentarios.
  3. Herramienta A lee la revisión y decide qué sugerencias seguir.

Esto es más útil de lo que parece. Incluso un modelo de IA barato usado como revisor atrapa problemas reales: casos límite que faltan, problemas de seguridad, nombres confusos, código sin usar. El costo de ejecutar una revisión es pequeño; el costo de encontrar un error después de haberlo publicado ya es mucho mayor.

Los mejores resultados vienen de mezclar proveedores de IA. Claude revisando el propio código de Claude pasará por alto las mismas cosas. Pero GPT revisando el código de Claude (o al revés) atrapa tipos distintos de errores. Usar la misma IA para escribir y revisar sigue siendo mejor que ninguna revisión, pero usar IA distintas es mucho mejor.

Qué se queda en una sola herramienta

No siempre necesitas dos herramientas. Usar ambas juntas implica configuración adicional: dos configuraciones, dos listas de permisos, dos sistemas de notificación. Para tareas pequeñas (arreglar un error, escribir una función, limpiar un archivo), una herramienta en una sesión es más rápida y simple.

Cuándo usar dos herramientas juntas:

  • La tarea es lo bastante grande como para que planificar y construir sean pasos claramente separados
  • Quieres ahorrar dinero usando un modelo más barato para la parte de construir
  • Quieres una revisión independiente de una IA distinta antes de fusionar

Para todo lo demás, una sola herramienta basta. Las habilidades que aprendiste en las Partes 1-7 son las que usarás la mayor parte del tiempo.


Cómo volverte de verdad bueno en esto

Leer este curso acelerado no te vuelve bueno en estas herramientas. Usarlas de verdad sí. Así se ve el proceso de aprendizaje:

Empezarás haciendo todo manualmente. Te toparás con problemas. Esos problemas son tu forma de aprender. Cada problema apunta de vuelta a uno de los quince conceptos de este curso:

El problema con el que te topasQué arreglar
"¿Por qué la IA sigue olvidando las reglas de mi proyecto?"Tu archivo de reglas falta o es demasiado largo (Concepto 8)
"¿Por qué la IA acaba de borrar una carpeta importante?"Tus permisos no son lo bastante estrictos (Concepto 3)
"¿Por qué la IA empeora después de una hora de chatear?"La conversación es demasiado larga; usa /compact (Concepto 6)
"¿Por qué mi factura (o mi límite de uso) se dispara en trabajo simple?"Estás usando un modelo caro para todo; ajusta el modelo a la tarea (Concepto 4)
"¿Por qué escribo las mismas instrucciones cada semana?"Convierte esas instrucciones en una skill (Concepto 9)
"¿Por qué se rompió todo cuando la IA intentó guardar?"Necesitas un hook o plugin para atrapar eso (Concepto 10)
"¿Por qué buscar entre archivos abarrota mi conversación?"Usa un subagente para hacer la búsqueda aparte (Concepto 11)

Arregla cada problema cuando te topes con él, no antes. Empieza con un archivo de reglas pequeño. Añade una línea cuando algo salga mal. Crea tu primera skill cuando notes que te estás repitiendo. Añade un hook cuando se rompa algo que debería haberse atrapado automáticamente. Deja que tu configuración crezca de forma natural a partir de la experiencia real.

La verdadera habilidad no es memorizar quince conceptos. Es reconocer qué concepto usar cuando aparece un problema. Eso solo viene de la práctica.

Tus habilidades se transfieren entre herramientas. Una vez que aprendes a pensar de esta forma en una herramienta, cambiar a la otra es fácil. Los botones y los ajustes son distintos, pero el pensamiento es el mismo. Elige una herramienta, empieza con un proyecto, usa el modo plan y mantén tus conversaciones cortas. Todo lo demás se construye a partir de ahí.


Referencia rápida

Los 15 conceptos en una línea cada uno

  1. Estas herramientas hacen el trabajo, no solo responden preguntas. (Qué son) Da instrucciones, no preguntas.
  2. Modo plan. (Función) Haz que la IA te muestre su plan antes de cambiar nada. (Shift+Tab en Claude Code, Tab en OpenCode.)
  3. Permisos. (Ajustes) La IA pregunta antes de cada acción. Empieza aprobando manualmente. Aprueba automáticamente las acciones seguras más tarde.
  4. Ajusta el modelo a la tarea. (Elección de modelo) Modelo fuerte para planificar y razonar; modelo barato o gratuito para ejecutar. Cambia con /model (Claude Code) o /models (OpenCode).
  5. Las conversaciones empeoran a medida que se alargan. (Contexto) La IA pierde el hilo de los detalles y cuesta más. Mantén las conversaciones enfocadas.
  6. /clear = empezar de cero. /compact = misma tarea, menos desorden. (Comandos) No los confundas.
  7. Reanuda conversaciones viejas. (Comandos) Vuelve mañana y continúa donde te detuviste. Guarda los planes en archivos como respaldo.
  8. Archivo de reglas. (CLAUDE.md / AGENTS.md) Mantenlo corto. Escribe solo lo que la IA no puede deducir mirando tus archivos.
  9. Comandos y skills. (.claude/skills/) Un solo sistema de prompt guardado: lo invocas con /nombre, o el modelo lo invoca solo a partir de su descripción.
  10. Hooks / Plugins. (settings.json / .opencode/plugins/) Reglas que se ejecutan cada vez, pase lo que pase. La IA no puede saltárselas.
  11. Subagentes. (.claude/agents/) Envía un ayudante a hacer la lectura pesada para que tu conversación principal se quede limpia.
  12. MCP. (Conexiones externas) Conecta la IA con servicios en línea (Slack, GitHub, bases de datos). Añade solo lo que de verdad necesitas.
  13. Dónde ejecutarlas. (Terminal / IDE / Web) Empieza en la terminal o en un plugin de IDE para ver qué hace la IA.
  14. Biblioteca personal. (~/.claude/ / ~/.config/opencode/) Comparte tus reglas y skills entre proyectos. Constrúyela despacio a partir de problemas reales.
  15. Memoria. (Carpeta notes/) Reanudar conversaciones y un buen archivo de reglas basta para la mayoría de la gente. Añade una carpeta notes/ si necesitas más.

Referencia rápida de comandos

Quieres...Claude CodeOpenCode
Inicializar el archivo de reglas del proyecto/init/init
Entrar en modo planShift+Tab (dos veces)Tab (alterna al agente Plan)
Cambiar el modelo/model/models
Borrar la conversación, empezar de cero/clear/new (o /clear)
Resumir y continuar/compact/compact (o /summarize)
Reanudar una sesión guardadaclaude --resume/sessions (o /resume)
Volver a un mensaje anteriorEsc Esc (o /rewind)/undo
Revertir las ediciones de archivos del modeloEsc Esc (puntos de control)/undo (necesita git)
Revertir cambios de archivos hechos por comandos bash(no rastreado)/undo (diff de todo el árbol)
Rehacer (revertir el último /undo)(no incluido)/redo
Exportar o compartir la conversación/export (guarda una transcripción)/share (enlace público) o /export

Referencia rápida de ubicación de archivos

QuéClaude CodeOpenCode
Reglas del proyectoCLAUDE.mdAGENTS.md (también lee CLAUDE.md como alternativa)
Permisos del proyecto.claude/settings.jsonopencode.json
Comandos del proyecto.claude/commands/*.md.opencode/commands/*.md
Skills del proyecto.claude/skills/<name>/SKILL.md.opencode/skills/<name>/SKILL.md (también lee .claude/skills/)
Hooks/plugins del proyecto.claude/settings.json (bloque hooks).opencode/plugins/*.{js,ts}
Subagentes del proyecto.claude/agents/*.md.opencode/agents/*.md
Reglas personales/globales~/.claude/CLAUDE.md~/.config/opencode/AGENTS.md
Comandos/skills/agentes personales~/.claude/{commands,skills,agents}/~/.config/opencode/{commands,skills,agents}/
Servidores MCP.mcp.json (proyecto) / ~/.claude.json (personal)opencode.json (bloque mcp)

Árbol de decisión de tipo de extensión

Need to do the same thing repeatedly, manually?
→ Slash command (CC) / Custom command (OC)

Want the model to apply expertise automatically when a task matches?
→ Skill

Need something to happen every single time, no model judgment?
→ Hook (CC) / Plugin (OC)

Need a chunk of work done in isolation so it doesn't pollute main context?
→ Subagent

Cuando algo se siente mal

Model apologizing without progress, rewriting the same code,
hallucinating variables, contradicting earlier constraints?
→ Context is poisoned. Stop typing. Run /compact or /clear.
Don't try to fix it with another prompt.

Ayuda de estudio: tarjetas didácticas


Cuestionario: 52 preguntas sobre los 15 conceptos

Pon a prueba lo que aprendiste. Cada sesión muestra un conjunto nuevo de 18 preguntas, así que obtienes preguntas nuevas cada vez que lo repites.

Checking access...