Handoff: a skill do Claude Code que ninguém usa e deveria

O problema que me fez testar a Handoff

Eu trabalho com sessões longas no Claude Code. Refatoração de código, configuração de infra, ajuste de templates — qualquer coisa que envolva mais de 20 trocas começa a ter um problema sutil: o modelo perde o fio da meia.

Não é que ele esquece o que você pediu. É que o contexto acumulado começa a competir com o contexto novo. Você pede para corrigir um bug, ele corrige, mas esquece que cinco mensagens atrás você tinha definido uma convenção de nome. Ou pior: ele repete um erro que já tinha sido corrigido porque a sessão ficou grande demais.

Eu tentei de tudo. Resumos manuais no meio da sessão. Copiar e colar trechos relevantes. Começar sessão nova e reexplicar tudo. Nada era eficiente o suficiente.

O que a Handoff faz de diferente

A skill Handoff do Matt Pocock resolve um problema específico: ela comprime uma sessão inteira do Claude Code em um documento markdown estruturado. Não é um resumo genérico. É um documento que captura o que foi feito, o que falta fazer, decisões tomadas, erros encontrados e o estado atual do trabalho.

A instalação é simples:

`bash npx skills add mattpocock/skills skill=handoff -y -g `

Depois de instalada, você pede para o Claude Code gerar o handoff no final de uma sessão longa. Ele cria um documento que você pode:

1. Carregar em uma sessão nova do Claude Code para continuar de onde parou.
2. Passar para outro agente (Codex, Hermes, OpenCode) como briefing.
3. Versionar no git como documentação viva do que foi feito.

Onde eu testei e o que aconteceu

Minha primeira tentativa foi em uma refatoração de um script Python que mexe com o blog engine. A sessão tinha umas 40 trocas, e o Claude começou a sugerir soluções que eu já tinha descartado no início. Pedi o handoff, ele gerou o documento, e eu abri uma sessão nova carregando aquele arquivo.

A diferença foi imediata. A nova sessão sabia exatamente o que já tinha sido feito, quais abordagens não funcionaram, e qual era o próximo passo. Não precisei reexplicar nada.

O segundo teste foi mais interessante: eu usei o handoff para passar contexto do Claude Code para o Hermes. Como o Hermes tem skills diferentes e capacidades diferentes, o documento serviu como briefing. Funcionou bem para tarefas de infra, mas para código puro o Claude Code continua sendo melhor para executar.

Onde quase me enganou

O handoff não é mágica. Se a sessão original já estava confusa — muitas idas e voltas, decisões contraditórias, código parcialmente implementado — o documento de handoff reflete essa confusão. Ele comprime o estado, não corrige o estado.

Na segunda vez que usei, a sessão tinha uma ambiguidade que eu não tinha resolvido: eu queria dois comportamentos mutuamente exclusivos no mesmo script. O handoff documentou ambos como válidos, e a nova sessão tentou implementar os dois, gerando código quebrado.

A lição: antes de pedir o handoff, vale resolver ambiguidades pendentes. O documento é tão bom quanto a sessão que ele comprime.

Quando vale a pena e quando não vale

Vale a pena quando:

• A sessão passou de 20-30 trocas e o modelo começa a repetir erros.
• Você precisa trocar de agente (Claude → Hermes, Claude → Codex).
• Você quer versionar o andamento de um projeto complexo.

Não vale a pena quando:

• A tarefa é curta e direta (menos de 10 trocas).
• A sessão já está confusa demais — limpe antes de comprimir.
• Você não tem onde guardar o documento gerado (ele vai para /tmp por padrão).

Como eu integrei no meu fluxo

Hoje, qualquer sessão do Claude Code que passa de 25 trocas eu peço o handoff. Salvo o documento na pasta do projeto, commito no git, e se precisar continuar, carrego na próxima sessão. Isso eliminou uns 80% das vezes em que eu precisava reexplicar contexto.

Para quem trabalha com múltiplos agentes — e se você usa Hermes, Claude Code e Codex, provavelmente trabalha — o handoff é a ponte que faltava entre eles. Não é perfeito, mas é o melhor jeito que eu encontrei de não perder trabalho entre sessões.