Mapa da trilha
Conteúdo detalhado
🎭 Dois agentes lado a lado no mesmo projeto
Session handoff, dois terminais, MCP compartilhado e como evitar que se atropelem.
Resumo curto e estruturado que você pede ao agente atual antes de "passar a bola": foco atual, arquivos tocados, decisões tomadas, problema aberto, próximos passos. Cola no outro agente.
Sem isso, você vira chefe que faz reunião de 30min pra contar contexto pro substituto. Com isso, é uma mensagem de uma página e o outro agente sai escrevendo código em 30 segundos.
Template fixo (foco, arquivos, decisões, próximo passo), uso de skill session-handoff pra padronizar, salvar em arquivo (handoff.md) pra rastrear.
Setup prático: VS Code aberto no projeto, dois painéis de terminal — um rodando claude, outro rodando codex. Os dois enxergam o mesmo filesystem, mesmo git, mesmas docs.
É a configuração que destrava trabalho paralelo: Claude refatora frontend num painel, Codex escreve testes no outro. Sem precisar de IDE separada.
Split terminal, split editor, workspace settings sincronizados, atalhos pra trocar foco, profile de terminal por agente.
Se os dois agentes editam o mesmo arquivo ao mesmo tempo, um sobrescreve o outro. Solução: dividir por área (Claude no src/api/, Codex no src/ui/) ou por tipo (Claude implementa, Codex testa).
É a forma #1 de perder trabalho com workflow dual. Disciplina de divisão evita 100% dos casos. Sem disciplina, vira drama em poucas horas.
Divisão por área de código, divisão por fase (implementar vs revisar), uso de git branch separados por agente, lock manual via comment.
MCP servers (Slack, Gmail, GitHub, banco) rodam como processos independentes. Configurados no .mcp.json (Claude) e config.toml (Codex), os dois agentes conectam no mesmo server.
Você não duplica o server — duplica só a declaração. Server em si é compartilhado, ganha-se consistência (mesmas credenciais, mesmas tools).
Server estático (stdio) vs HTTP, declaração espelhada nos dois runtimes, env vars centralizadas (.env compartilhado), allowlist por runtime.
Hooks são shell commands. Coloca a lógica em scripts/check.sh no projeto, e os dois runtimes apontam o hook pra esse script. Manutenção em um único lugar.
Sem isso você duplica regex de hook em dois lugares diferentes. Com isso, edita o script, os dois agentes obedecem.
Script idempotente, exit code 0/1, scripts no scripts/ do projeto (compartilhados), declaração mínima em settings/config.
Conjunto de regras que você (ou seu time) adota pra escolher agente por tipo de tarefa. Ex: "refactor longo = Claude; testes = Codex; debug paralelo = ambos".
Sem governança, escolha vira intuição (instável). Com regra escrita, novos integrantes do time têm um padrão pra seguir.
Rule of thumb por categoria de task, A/B test pra calibrar, "modelo neutro" no início (pegar o que estiver ocioso), revisão trimestral.
O ecossistema não para. Gemini CLI, Cursor, Copilot, JetBrains AI Assistant estão no roadmap do polyskill como adapters. Sua skill cross-runtime já está pronta — só falta o adapter.
Pra entender que o investimento em escrever no formato portable é à prova de futuro. Não é só "Claude+Codex" — é qualquer runtime que vier.
Adapter como contrato simples (parse/emit/validate), comunidade Early AI Dopters, contribuir adapter via PR, marca da skill independente do runtime.