Mapa de la ruta
Contenido detallado
🎭 Dos agentes lado a lado en el mismo proyecto
Session handoff, dos terminales, MCP compartido y cómo evitar que se estorben.
Resumen breve y estructurado que le pides al agente actual antes de «pasarle el trabajo»: enfoque actual, archivos modificados, decisiones tomadas, problema abierto, próximos pasos. Pégalo en el otro agente.
Sin esto, te conviertes en el jefe que hace una reunión de 30min para poner al tanto a quien te sustituye. Con esto, basta un mensaje de una página y el otro agente empieza a escribir código en 30 segundos.
Plantilla fija (enfoque, archivos, decisiones, siguiente paso), uso de skill session-handoff para estandarizar, guardar en un archivo (handoff.md) para hacer seguimiento.
Setup práctico: VS Code abierto en el proyecto, dos paneles de terminal — uno ejecutando claude, otro en ejecución codex. Ambos ven el mismo filesystem, el mismo git y las mismas docs.
Es la configuración que permite trabajar en paralelo: Claude refactoriza el frontend en un panel y Codex escribe pruebas en el otro. Sin necesidad de un IDE separado.
Terminal dividida, editor dividido, ajustes del espacio de trabajo sincronizados, atajos para cambiar el foco, perfil de terminal por agente.
Si los dos agentes editan el mismo archivo al mismo tiempo, uno sobrescribe al otro. Solución: dividir por área (Claude en el src/api/, Codex en src/ui/) o por tipo (Claude implementa, Codex prueba).
Es la forma #1 de perder trabajo con un workflow dual. La disciplina para dividir el trabajo evita el 100% de los casos. Sin disciplina, se convierte en un drama en pocas horas.
División por área de código, división por fase (implementar vs. revisar), uso de ramas de git separadas por agente, bloqueo manual mediante comment.
Los servidores MCP (Slack, Gmail, GitHub, base de datos) se ejecutan como procesos independientes. Se configuran en el .mcp.json (Claude) y config.toml (Codex), ambos agentes se conectan al mismo server.
No duplicas el server: solo duplicas la declaración. El server en sí se comparte, lo que aporta consistencia (las mismas credenciales y las mismas tools).
Server estático (stdio) vs. HTTP, declaración reflejada en ambos runtimes, variables de entorno centralizadas (.env compartido), allowlist por runtime.
Los hooks son comandos de shell. Coloca la lógica en scripts/check.sh en el proyecto, y ambos runtimes apuntan el hook a este script. Mantenimiento en un solo lugar.
Sin esto, duplicas la regex del hook en dos lugares diferentes. Con esto, editas el script y ambos agentes lo siguen.
Script idempotente, código de salida 0/1, scripts en el scripts/ del proyecto (compartidos), declaración mínima en settings/config.
Conjunto de reglas que tú (o tu equipo) adoptas para elegir un agente según el tipo de tarea. Ej.: "refactor largo = Claude; pruebas = Codex; debug en paralelo = ambos".
Sin gobernanza, la elección se vuelve intuitiva (inestable). Con una regla escrita, los nuevos integrantes del equipo tienen un estándar que seguir.
Regla general por categoría de tarea, prueba A/B para calibrar, «modelo neutral» al inicio (elegir el que esté desocupado), revisión trimestral.
El ecosistema no se detiene. Gemini CLI, Cursor, Copilot y JetBrains AI Assistant están en la hoja de ruta de polyskill como adapters. Tu skill cross-runtime ya está lista; solo falta el adapter.
Para entender que la inversión en escribir en formato portable está preparada para el futuro. No es solo "Claude+Codex": es cualquier runtime que venga.
Adapter como contrato simple (parse/emit/validate), comunidad Early AI Dopters, contribuir con un adapter mediante PR, marca de la skill independiente del runtime.