Skill de Handoff: El Flujo de Trabajo de Claude Code Que Solucionó Mi Sobrecarga de Contexto
La sesión estaba en 142.000 tokens cuando noté que Claude había empezado a repetirse.
Estaba sumergido en una conversación de planificación sobre un nuevo pipeline de contenido Aria — tres marcas, cuatro tipos de publicaciones, un protocolo de investigación compartido, todo el paquete. A mitad de camino, le pedí que elaborara una pequeña refactorización de un skill cron no relacionado que no tenía nada que ver con el pipeline. Cuarenta y cinco minutos después, Claude contradecía educadamente decisiones que habíamos fijado doscientos mensajes antes, mezclaba la lógica del cron con la especificación del contenido, y me citaba mis propios ADRs ligeramente mal. La ventana de contexto de 1M tokens técnicamente seguía abierta. En la práctica, el modelo trabajaba en niebla.
Esa sesión es la razón por la que adopté el skill de handoff. Y una vez que empecé a usar handoff en lugar de /compact para estos momentos, la diferencia no fue sutil — fue la diferencia entre un ingeniero enfocado que termina una tarea limpiamente y uno cansado que sigue reabriendo el mismo hilo de Slack.
Este es el artículo que desearía que alguien me hubiera entregado hace seis semanas. Vamos a desmontar el skill de handoff: cómo funciona, por qué supera a la compactación para trabajo multi-hilo, qué contiene realmente el archivo markdown, cuándo utilizarlo, y cómo lo he incorporado en mi propio flujo de trabajo Aria + Claude Code en este sitio. Al final sabrás exactamente dónde en tus sesiones actuales deberías estar escribiendo un handoff y dónde no.
La ventana de contexto es más grande, y eso empeoró el problema
Déjame establecer la escena correctamente, porque el encuadre importa.
Claude Code ahora viene con una ventana de contexto de 1M tokens. Eso suena como un problema resuelto — échalo todo, el modelo se las arreglará. No es un problema resuelto. La propia documentación de Anthropic lo confirma: la precisión y la recuperación se degradan a medida que el contexto se llena. Las pruebas independientes de equipos que ejecutan Claude Code en producción sitúan el punto de degradación práctica mucho antes del techo — la calidad empieza a caer alrededor de la marca de 120.000 tokens, bastante antes de que la ventana esté técnicamente llena. Algunos equipos reportan pérdida de calidad medible ya al 50% de la capacidad.
Concibo cada ventana de contexto como dos capas apiladas una sobre otra:
- La zona inteligente — los tokens iniciales, el prompt del sistema, los intercambios más recientes. La atención es aguda aquí. El modelo sabe qué preguntaste, qué respondió y qué está sobre la mesa ahora mismo.
- La zona tonta — los tokens posteriores, el medio obsoleto, las partes que el mecanismo de atención tiene que esforzarse para ponderar correctamente. Todavía está "en contexto". Simplemente no recibe el foco que crees.
Una vez que una sesión cruza a la zona tonta, no siempre lo notas. Las respuestas siguen sonando seguras. Pueden seguir citando intercambios anteriores. Pero la precisión cae. Decisiones que tomaste se olvidan o se revierten silenciosamente. Las selecciones de herramientas se vuelven difusas. El código empieza a parecer un compuesto de tres decisiones de diseño diferentes en las que casi habías convergido.
La versión honesta de "1M de contexto" es más bien: 1M de techo, ~120K de zona inteligente confiable, luego una larga curva de degradación. Presupuestar la atención dentro de la ventana es tan importante como el techo mismo — y yo argumentaría que más importante. Escribí sobre este balance en detalle en mi análisis de la gestión de contexto de 1M de Claude Code y en el artículo sobre higiene de contexto en límites de tokens. Ambos siguen aplicando.
Lo que hace el handoff, en una línea: te da una forma limpia de dividir el trabajo entre múltiples sesiones para que cada una permanezca en su propia zona inteligente en lugar de fingir que la zona tonta no existe.
Qué hace realmente el skill de handoff
Aquí está el cambio de flujo de trabajo que hizo clic para mí.
Cuando se invoca el skill de handoff, la sesión actual de Claude Code comprime todo lo relevante — qué intentábamos hacer, qué decidimos, qué probamos, qué sigue abierto, qué archivos tocamos, qué skills debería tomar la siguiente sesión — en un único archivo Markdown. Ese archivo se guarda en el directorio temporal del sistema operativo (para no saturar el espacio de trabajo), y entonces una nueva sesión de Claude Code abre ese archivo y continúa el trabajo sin heredar la carga.
Algunos detalles que tardé un par de intentos en apreciar:
El archivo de handoff está diseñado para el propósito, no es genérico. El skill acepta un argumento describiendo el enfoque de la siguiente sesión. "Continuar el diseño de la API" produce un handoff muy diferente a "construir un prototipo de UI para el diseño que acabamos de esbozar" — incluso cuando ambos provienen de la misma sesión padre. La compresión es intencional, no un resumen sin criterio.
Es un archivo Markdown real, no un blob JSON oculto. Puedo abrirlo, leerlo, editarlo, añadir un párrafo, eliminar una sección, redactar un token antes de pasarlo. Esa es una propiedad que subestimé hasta que intenté hacer lo mismo con el resumen de /compact, que es opaco y con pérdidas de maneras que no puedes auditar.
Apunta en lugar de duplicar. Si habíamos escrito un issue de GitHub o un ADR para el trabajo, el archivo de handoff hace referencia a él en lugar de pegar los contenidos. Suena obvio — excepto que /compact hace lo opuesto. Vuelve a resumir todo, así que la siguiente sesión termina con una paráfrasis difusa del issue que ya habías escrito con precisión.
Incluye una sección de "skills sugeridos". Esta es la parte que quiero que copie cada framework. La sesión actual sabe qué herramientas, skills o patrones de sub-agentes probablemente necesitará la siguiente sesión — TDD, brainstorming, worktrees, verificación — y escribe esa pista en el handoff. La sesión nueva llega ya orientada a la caja de herramientas correcta.
Los datos sensibles se redactan antes de guardar. Claves API, secretos, información personal — el skill los elimina antes de que el archivo llegue al disco. Sigo revisando los handoffs manualmente antes de pasarlos, pero tener eso como predeterminado integrado es mejor que esperar haberlo recordado.
Si has estado usando el framework superpowers de Obra (alrededor de 195k estrellas en GitHub al momento de escribir esto, creciendo rápido), esto te resultará nativo — handoff es exactamente el tipo de skill disciplinado y orientado a metodología que hace funcionar todo ese ecosistema. Cubrí el patrón más amplio en mi review del plugin superpowers. El skill de handoff es la pieza que infrautilicé las primeras semanas hasta que la matemática multi-sesión me alcanzó.
Compactación vs handoff: la comparación que cambió mi forma de trabajar
/compact y handoff se parecen desde la distancia. Ambos producen una vista comprimida de dónde has estado. Resuelven problemas muy diferentes.
Aquí está la comparación directa como los uso ahora:
| Dimensión | /compact (compactación) |
skill handoff |
|---|---|---|
| Topología de sesión | Una única sesión prolongada | Múltiples sesiones con propósito específico |
| Qué comprime | El historial completo de la sesión actual | Solo lo que la siguiente sesión necesita saber |
| A dónde va la salida | De vuelta al contexto de la misma sesión | Un archivo Markdown en el directorio temporal del SO |
| Auditabilidad | Resumen opaco, no editable | Archivo legible, editable antes de pasar |
| Continuidad cross-sesión | Misma conversación, solo más corta | Atención fresca, enfoque delimitado, reset de zona inteligente |
| Portabilidad cross-herramienta | Ninguna — vinculada a esa sesión | Markdown funciona en Claude Code, Codex CLI, Copilot CLI |
| Manejo de datos sensibles | Ninguno por defecto | Paso de redacción antes de guardar |
| Referencia vs duplicado | Vuelve a resumir todo | Referencia artefactos existentes (issues, ADRs, planes) |
| Mejor para | Recortar una sesión que se extendió demasiado en una única tarea coherente | Dividir trabajo no relacionado, prototipos laterales, flujos cross-agente |
| Modo de fallo al usarse mal | Compresión con pérdida de trabajo que aún necesitarás | Dos sesiones que se desvían si el documento de handoff no es preciso |
Lee esa tabla de lado por un segundo. La compactación es una herramienta de memoria — intenta hacer que un solo hilo encaje. El handoff es una herramienta de flujo de trabajo — divide hilos para que cada uno encaje naturalmente. El primero es una curita; el segundo es estructural.
Si tu tarea es "seguir refinando esta misma spec de API tres horas más, solo menos verboso" — compacta. Si tu tarea es "necesito probar un prototipo para responder una pregunta que surgió mientras especificaba la API" — handoff. Confundirlos es el error que cometí durante semanas.
Hay una heurística aún más simple que ahora uso. Pregunta: "¿El siguiente parte de esta conversación compartirá 80%+ del contexto que actualmente está en la ventana?" Si sí, compacta. Si no, handoff. La mayoría de las veces que antes recurría a compact, la respuesta honesta era no.
Cuándo recurrir a un handoff
Tres patrones ganaron un lugar permanente en mi flujo de trabajo.
1. La tentación de la refactorización a mitad de sesión
Estoy inmerso construyendo la feature A. Noto algo en un módulo compartido que está claramente mal diseñado — una función que hace tres cosas, un flag de configuración con el valor predeterminado incorrecto, un test que se ha saltado silenciosamente durante seis commits. El viejo yo lo habría arreglado en ese momento. La sesión actual habría heredado veinte mensajes sobre esa refactorización, la mitad de los cuales seguirían en la ventana cuando volviera a la feature A y tuviera que recordar qué habíamos decidido sobre sus casos límite.
El nuevo yo escribe un handoff. "Refactorizar RoutePlanner.normalize() para separar validación de ruta de formateo. Los tests en tests/router/normalize.test.ts ya cubren los casos. Skills: brainstorming, TDD." La sesión nueva lo recoge, entrega la refactorización, regresa limpia. La sesión de la feature A permanece en la zona inteligente todo el tiempo.
Esta es la ganancia de flujo de trabajo individual más barata que he obtenido de cualquier cambio de herramientas de IA este año. El costo de contaminar una sesión profunda con una refactorización no relacionada es mucho mayor que el costo de escribir un archivo de handoff.
2. Sesiones de interrogación que se ramifican
Las sesiones de interrogación — exploración interactiva impulsada por preguntas donde dejo que Claude ponga a prueba un plan o diseño — son donde el handoff realmente demuestra su valor. Una buena sesión de interrogación va amplia a propósito. Investiga casos límite. Saca a la superficie sub-preguntas. Y de vez en cuando, una de esas sub-preguntas necesita su propia sesión enfocada para ser respondida.
Ejemplo de la semana pasada. Estaba interrogando un plan para una nueva automatización de cluster de contenido. A mitad de camino, Claude preguntó: "¿Has confirmado que el renderizador de markdown maneja admonitions anidadas cuando el post se carga a través de tu CMS?" No lo había hecho. La respuesta fue un desvío de noventa minutos de prototipado que no quería ejecutar dentro de la sesión de interrogación.
Handoff. "Prototipo: alimentar tres posts de prueba con admonitions anidadas a través de la vista previa local del CMS y capturar la salida de renderizado. Skills: prototipo, verificar. Devolver hallazgos a la sesión de interrogación como resultado de un párrafo." La sesión de prototipo corre por separado, genera un resumen en markdown, la sesión de interrogación lee ese resumen y continúa sin haber cargado jamás los posts de prueba o las dependencias del renderizador en su propio contexto.
Ese segundo handoff — el que vuelve del prototipo a la sesión de interrogación — es la parte que me sorprendió. Los handoffs son bidireccionales. La sesión de prototipo escribe sus hallazgos en un documento de handoff y los devuelve. La sesión de interrogación lee tres párrafos de respuesta destilada, no noventa minutos de prueba y error.
3. Sesiones de planificación que se separan de sesiones de construcción
El otro patrón en el que me apoyo fuertemente: separar qué construir de cómo construirlo. Las sesiones de planificación tratan sobre decisiones — qué está en alcance, cuál es el modelo de datos, qué compensaciones importan. Las sesiones de construcción tratan sobre ejecución — escribir el código, ejecutar los tests, verificar la salida.
Estas dos actividades se contaminan mutuamente cuando comparten una ventana. Las conversaciones de planificación generan docenas de pequeñas ramificaciones de "qué pasa si hacemos X" que inflan el contexto pero no sobreviven a la decisión. Las sesiones de construcción acumulan salida de tests, mensajes de error y diffs de archivos que no tienen nada que ver con la especificación original.
Ahora las ejecuto como dos sesiones. La sesión de planificación produce un handoff: las decisiones fijadas, las preguntas abiertas, el plan estructural. La sesión de construcción toma ese handoff, ejecuta, y — si algo durante la construcción invalida una decisión de planificación — escribe un handoff de vuelta. La sesión de planificación reabre, ingiere el feedback y refina. Bucle hasta que la sesión de construcción no tenga nada más que devolver.
Este es el mismo patrón de iteración que describí en el artículo sobre agentes de flujo de trabajo spec, solo que hecho portable entre sesiones. El handoff es lo que hace que ese bucle funcione sin que la ventana de contexto de nadie se llene.
Qué va dentro de un buen archivo de handoff
Si alguna vez solo lees una sección de este artículo, que sea esta.
El documento de handoff tiene un trabajo específico: dar a una sesión nueva suficiente para continuar el trabajo sin arrastrar el ruido que acumuló la sesión padre. Si te equivocas en los contenidos, habrás reconstruido el problema de /compact en un archivo nuevo. Si lo haces bien, la sesión nueva llega como un ingeniero senior que se une a un proyecto a mitad de sprint — informado, orientado, productivo en diez minutos.
Esta es la estructura que ahora uso para cada handoff, ya sea que el skill lo genere o que lo edite a mano:
| Sección | Qué incluir | Qué NO incluir |
|---|---|---|
| Objetivo | Una frase que indique de qué es responsable la siguiente sesión | Historia de fondo de cómo llegamos aquí |
| Ancla de contexto | Enlaces a ADRs, issues de GitHub, documentos de diseño, handoffs anteriores — no los contenidos, solo las referencias | Contenidos pegados de esos documentos |
| Dónde estamos | Estado actual: rama, archivos tocados, qué está desplegado, qué se revirtió | Historia paso a paso de cada cambio |
| Decisiones fijadas | Cosas ya decididas que la siguiente sesión no debe relitigar | La conversación que produjo las decisiones |
| Preguntas abiertas | Las 2-5 cosas aún sin resolver que la siguiente sesión necesita responder | Especulación sobre cada posible pregunta |
| Lo que probamos (y por qué no funcionó) | Callejones sin salida a evitar, escritos como líneas únicas | Transcripciones largas de errores o stack traces |
| Skills sugeridos | TDD, brainstorming, verify, prototype, worktrees — qué skills probablemente usará la siguiente sesión | Prosa de "quizás probar este enfoque" |
| Inicio rápido | El primer comando, el primer archivo a abrir, la primera pregunta a responder | Un tutorial completo |
| Redacciones de datos sensibles | Marcador que muestra qué se redactó y dónde encontrarlo | Los datos sensibles reales |
Dos patrones que la gente pierde cuando escribe handoffs a mano:
No repitas lo que está en el issue. Si hay un issue de GitHub con la historia de usuario, los criterios de aceptación y la justificación del diseño, el archivo de handoff debería decir "ver issue #142" — no parafrasear el issue. Parafrasear es cómo la verdad se desvía.
Sé honesto sobre las preguntas abiertas. La tentación es hacer que el handoff suene completo. "Solo necesitamos entregar esto." Si hay preguntas abiertas, enuméralas. La siguiente sesión las descubrirá de todos modos, y quieres que las descubra en la zona inteligente del nuevo contexto, no después de haberse comprometido con una dirección incorrecta.
Mantengo una pequeña plantilla mental. Objetivo, ancla, estado, fijado, abierto, callejones sin salida, skills, inicio, redacciones. Nueve secciones. La mayoría de las mías terminan en menos de 600 palabras. El punto es que son desechables — lo suficientemente pequeñas para leer en un minuto, lo suficientemente enfocadas para actuar inmediatamente.
Cómo uso los handoffs en mi propio flujo de trabajo
Déjame concretizar esto con cómo realmente lo uso en mejba.me y el sistema de contenido Aria más amplio.
Mi sesión típica de producción de contenido tiene al menos tres fases. Investigar el tema. Planificar el artículo. Escribir el artículo. Cada una de esas fases quiere diferentes herramientas, diferente contexto, diferente atención. La fase de investigación trae resultados de búsqueda, URLs de competidores scrapeadas y estadísticas. La fase de planificación quiere el archivo de voz de marca, la taxonomía de clusters y el mapa de enlaces internos existente. La fase de escritura quiere el plan, la investigación y un editor vacío.
Hace unos meses intenté hacer las tres en una sola sesión de Claude Code. Para cuando estaba escribiendo el tercer artículo de un cluster, el contexto tenía ~80.000 tokens de investigación de los artículos uno y dos todavía flotando, más los planes de ambos, más las tres cargas de voz de marca, más mis notas de trabajo. La calidad caía visiblemente en el segundo artículo.
El nuevo flujo se ve así:
- Sesión de investigación — obtener datos actuales, encontrar vacíos, escanear posts existentes para enlaces internos. Produce un handoff: "Planifica un artículo sobre X usando estos 6 hechos verificados, estos 3 objetivos de enlace interno y este ángulo competitivo." Archivo guardado en directorio temporal.
- Sesión de planificación — ventana nueva. Carga el handoff de investigación. La voz de marca y el mapa de clusters entran limpios. Produce otro handoff: "Escribe un artículo sobre X siguiendo este esquema, usando estas estadísticas específicas, con estos enlaces internos, tocando estos puntos emocionales."
- Sesión de escritura — ventana nueva otra vez. Carga el handoff de planificación. Escribe el artículo. Sin residuos de investigación, sin residuos de planificación, solo el plan y un objetivo.
Cada sesión se mantiene bajo ~60K tokens, profundamente en la zona inteligente, enfocada en su tarea. La calidad de la salida es notablemente mejor que el enfoque de una sola sesión, y los modos de fallo — cuando algo sale mal — son más fáciles de depurar porque puedo leer cada archivo de handoff y ver exactamente qué se pasó.
Para trabajo de código, me apoyo en la misma división. Planificar la arquitectura es una sesión. Construir el primer componente es una sesión. Construir el segundo es una sesión. Si la construcción de un componente plantea una pregunta que la arquitectura no anticipó, eso es un handoff de vuelta a la sesión de planificación. Es la misma lógica que hace que git worktrees con agentes paralelos y sub-agentes bifurcados se sientan tan naturales — todos son el mismo principio: dividir el trabajo a lo largo de fronteras que el modelo puede mantener distintas, en lugar de forzar al modelo a mantener fronteras distintas dentro de un contexto inflado.
Handoffs cross-herramienta: por qué Markdown importó más de lo que esperaba
Casi descarté la elección de Markdown-como-sustrato como obvia. Es la palanca práctica más grande de todo el skill.
Markdown es portable. Un archivo de handoff generado por Claude Code puede ser leído por Codex CLI sin modificación. Puede pasarse a Copilot CLI. Puede cargarse en Gemini CLI. He movido trabajo entre tres herramientas de agentes diferentes en un solo proyecto simplemente pasando el mismo archivo Markdown. Sin conversión de formato, sin código pegamento, sin gimnasia de SDK de agentes.
Aquí es donde los patrones de revisión adversarial se ponen interesantes. He escrito antes sobre ejecutar revisión adversarial de Codex contra la salida de Claude Code. El archivo de handoff es la entrada perfecta para ese patrón. Claude Code produce el trabajo y un handoff describiendo qué hizo y qué sigue abierto. Codex toma el handoff, ejecuta crítica, produce su propio handoff describiendo qué encontró. Claude Code reanuda con la crítica en mano. Cada agente trabaja en su zona inteligente. El archivo Markdown es lo único que tiene que cruzar fronteras.
La misma lógica para sub-agentes DIY. No necesitas un orquestador multi-agente sofisticado para ejecutar tareas especializadas en paralelo. Necesitas una forma de informar a un sub-agente, dejarlo trabajar y reintegrar sus resultados. Los handoffs en Markdown hacen eso sin un framework. El "framework" es el archivo.
La otra cosa que Markdown te da: revisión-antes-de-enviar. Cada handoff que escribo recibe un escaneo de treinta segundos antes de pasarlo. Verifico las cosas obvias — ¿la redacción capturó todos los secretos?, ¿las decisiones fijadas están realmente fijadas?, ¿listó callejones sin salida que resultaron ser el camino correcto después de todo? Ese paso de revisión ha atrapado al menos tres handoffs malos en el último mes. JSON o blobs binarios no te permiten hacer eso.
Lo que el handoff no es
Vale la pena ser honesto sobre los límites, porque el skill no es una respuesta universal.
El handoff no reemplaza la buena disciplina dentro de la sesión. Si dejas que una sesión se extienda por seis temas no relacionados sin dividir nunca, el skill de handoff no te salvará. Solo te dará un resumen ligeramente más limpio de la sesión extendida al final. La disciplina de reconocer cuándo dividir es tuya — el skill solo abarata la división una vez que te comprometes.
El handoff no es para tareas trivialmente cortas. Si todo el trabajo cabe en 20K tokens y una sesión, es mejor terminarlo que escribir un handoff. La sobrecarga del formato de handoff no es gratuita. Lo uso cuando el trabajo realmente va a abarcar múltiples sesiones, no como ceremonia.
El handoff no arregla artefactos upstream defectuosos. Si tus ADRs están equivocados, tus plantillas de issues son vagas y tus planes son imprecisos, el handoff lo reflejará. Las referencias son tan buenas como aquello a lo que apuntan. Noté que mis propios ADRs se volvieron más precisos después de empezar a escribir handoffs que los referenciaban — saber que la siguiente sesión leería esos documentos en frío me hizo escribirlos mejor.
El handoff no es un sustituto de la verificación. Un handoff dice "llegamos aquí." No demuestra que el código funciona. Las sesiones nuevas aún deben ejecutar tests, aún verificar antes de reclamar finalización. El handoff describe intención y estado. La realidad aún debe comprobarse.
El resumen honesto: el handoff es una herramienta de coordinación. Coordina trabajo entre sesiones que de otro modo compartirían contexto deficientemente. No reemplaza el trabajo en sí, la verificación del trabajo, ni los documentos upstream de los que depende el trabajo.
Qué cambia cuando empiezas a trabajar de esta manera
Algunos patrones que he notado en mi propio trabajo desde que el handoff se volvió rutina.
Planifico más antes de construir. Saber que necesitaré escribir un handoff al final de la sesión de planificación me obliga a terminar realmente el plan en lugar de desviarme hacia "déjame simplemente probar lo primero." Si voy a entregar esto a una sesión de construcción, el plan necesita ser lo suficientemente completo para actuar. Esa es una función forzante que el enfoque de una sola sesión no tenía.
Noto el scope creep más rápido. A mitad de sesión, cuando me pillo pensando "déjame también arreglar rápido esta cosa" — ese pensamiento ahora se convierte reflexivamente en "déjame escribir un handoff para esa cosa." El costo de una excursión lateral en la sesión actual es alto. El costo de escribir un handoff y continuar con mi trabajo actual es bajo. La matemática se inclina hacia el enfoque.
Mis sesiones son más cortas. Antes ejecutaba sesiones de Claude Code de una hora como algo normal. Ahora la mayoría de las sesiones duran 20-40 minutos. El trabajo es el mismo; las sesiones simplemente se ajustan al alcance real de la tarea en lugar de agrupar tres tareas en una ventana.
Confío más en mis agentes. Cuando una sesión nueva carga un handoff ajustado y continúa el trabajo limpiamente, la salida se siente más confiable que cuando una sola sesión ha estado corriendo por una hora y el modelo medio recuerda lo que decidimos. La zona inteligente es real. Mantener el trabajo dentro de ella es una inversión de calidad, no un impuesto.
Preguntas Frecuentes
¿Qué es el skill de handoff en Claude Code?
El skill de handoff comprime el contexto relevante de una sesión de Claude Code en un archivo Markdown que una sesión nueva puede usar para continuar el trabajo sin heredar la carga de contexto. Guarda el archivo en el directorio temporal del SO, referencia documentos existentes en lugar de duplicarlos, redacta datos sensibles y sugiere qué skills debería usar la siguiente sesión. Para la configuración completa y patrones de uso, consulta la sección de flujo de trabajo arriba.
¿En qué se diferencia el handoff de /compact?
/compact resume la sesión actual y reemplaza su historial con el resumen, manteniéndote en la misma conversación. handoff produce un archivo Markdown portable enfocado en el objetivo específico de la siguiente sesión, y luego te permite empezar de nuevo. Compact es para recortar una tarea larga; handoff es para dividir trabajo no relacionado entre múltiples sesiones.
¿Cuándo debería usar handoff en lugar de simplemente continuar la sesión?
Usa handoff cuando la siguiente porción de trabajo comparte menos del 80% del contexto actualmente en tu ventana — refactorizaciones a mitad de sesión de código no relacionado, spikes de prototipado que se ramifican de una sesión de interrogación, o separar planificación de ejecución. Si el trabajo es una continuación directa de lo que ya estás haciendo, la compactación suele ser la mejor opción.
¿Cuál es la ventana de contexto práctica antes de que Claude Code empiece a degradarse?
El techo de 1M tokens de Claude Code es la cifra de marketing. La degradación práctica de calidad típicamente comienza alrededor de los 120.000 tokens, con algunos equipos reportando desviaciones notables ya al 50% de la ventana. Presupuestar la atención dentro de la zona inteligente importa más que el techo mismo.
¿Puedo usar handoff con diferentes agentes de codificación IA?
Sí. La salida del handoff es Markdown plano, lo que la hace portable entre Claude Code, Codex CLI, Copilot CLI, Gemini CLI y cualquier otro agente que lea texto. Esto es lo que habilita patrones cross-agente como ejecutar revisión adversarial de Codex contra la salida de Claude Code sin escribir código pegamento personalizado.
Trabajemos Juntos
¿Buscas construir sistemas de IA, automatizar flujos de trabajo o escalar tu infraestructura tecnológica? Me encantaría ayudarte.
- Fiverr (desarrollos personalizados e integraciones): fiverr.com/s/EgxYmWD
- Portfolio: mejba.me
- Ramlit Limited (soluciones empresariales): ramlit.com
- ColorPark (diseño y branding): colorpark.io
- xCyberSecurity (servicios de seguridad): xcybersecurity.io
