Tarefa grande demais para uma sessão? Como fatiar o trabalho para o Claude Code terminar

Fala aí, beleza? Existe um tipo de pedido que nunca fecha

Você descreve a entrega inteira, a sessão anda, arquivo abre, arquivo fecha, o contexto vai enchendo, e no fim do dia não tem UMA coisa que você consiga rodar e dizer "isso aqui está pronto"

O problema quase nunca é o modelo

É o tamanho do pedido: escopo largo demais pra uma rodada só, sem nenhum ponto de chegada no meio do caminho

A solução é chata de tão simples: fatiar

Cada fatia com um resultado verificável no fim, fechada antes de abrir a próxima

Bora ver como fazer isso na prática?

Sinais de que a tarefa está larga demais para uma sessão

Antes de cortar, vale reconhecer o sintoma

Se algum desses aparecer na sua sessão, o escopo já passou do ponto

A investigação se espalha e não para mais:

Você pede uma coisa e a sessão sai lendo meio repositório atrás de contexto

A documentação oficial de boas práticas trata investigação sem escopo como erro comum, e a correção sugerida é escopar as investigações de forma estreita ou usar subagentes, pra exploração não consumir o contexto principal

Causa: o pedido não delimitou ONDE olhar

Correção: dizer o recorte, ou mandar a leitura pesada pra um subagente e trazer só a resposta de volta

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

A janela de contexto enche no meio do trabalho:

O sinal clássico é a conversa ficar longa e a sessão começar a perder o fio do que era importante

Diagnóstico primeiro, chute depois: o comando /context mostra ao vivo o que está ocupando a janela, por categoria, com sugestões de otimização

/context

Se o que está ocupando espaço é exploração antiga, /compact resume a conversa e aceita instrução de foco, pra você escolher o que fica em vez de deixar a passagem automática adivinhar

/compact focus on the auth bug fix

E se a próxima coisa é OUTRA tarefa, o /clear começa do zero mantendo a memória do projeto

Vale saber que a janela cheia não encerra a sessão: o Claude Code compacta automaticamente ao se aproximar do limite, e o ponto em que isso roda depende do modelo e da configuração

Modelos sem contexto estendido compactam na fronteira de 200K tokens

Sessões com contexto estendido de 1M compactam por volta de 967K tokens por padrão, ajustável pela variável CLAUDE_CODE_AUTO_COMPACT_WINDOW

Dá pra mexer nisso pela sessão também, com /autocompact e a contagem de tokens:

/autocompact 500k

Só que compactar não é fatiar, beleza? Compactação salva a sessão, ela não te dá um resultado pronto

O plano vira lista sem fim:

Você abre o modo plano, o plano nasce com uma dúzia de itens, e cada item mexe em um canto diferente do projeto

Causa: você pediu a entrega inteira, e o plano só refletiu isso

Correção: cortar o plano até sobrar o pedaço que cabe em UMA verificação

O resto não morre, ele vira a fatia seguinte

Nada é verificável no fim:

Esse é o pior, porque parece progresso

Muito arquivo mudado e nenhum jeito de provar que funciona

A documentação é dura nesse ponto: "Sempre forneça verificação (testes, scripts, screenshots). Se você não consegue verificar, não faça o ship"

Como prevenir os quatro? Escrevendo o resultado verificável ANTES de mandar o pedido

Se você não consegue dizer o que vai rodar pra provar que a fatia fechou, a fatia ainda está grande demais

O que deixar pronto antes de fatiar

Nada de configuração exótica aqui, é o básico que faz o método funcionar

Projeto sob controle de versão. O Claude Code salva checkpoints do estado do código e deixa voltar atrás pelo menu de rewind, mas o seu histórico de commits é o que dá segurança pra experimentar sem medo em cada fatia

Um CLAUDE.md na raiz do repositório. Arquivos CLAUDE.md dão instruções persistentes e são lidos no início de toda sessão, o que importa MUITO quando você fecha e abre sessão a cada fatia

É ali que moram as convenções do projeto, o comando de teste, o que não pode ser tocado

Escopo global vai em ~/.claude/, e dentro da sessão o comando /memory navega e abre os arquivos de memória

/memory

Noção de quanto contexto e quanto limite você tem. /context pro contexto, e /usage pra ver a quebra do que conta contra os limites nos planos Pro, Max, Team e Enterprise

Nos planos por assinatura o limite de sessão reinicia a cada 5 horas, e os planos Max têm ainda um limite semanal que reinicia em horário fixo da semana

Saber disso muda o corte: fatia pequena e fechada aproveita melhor a janela do que uma maratona que não entrega nada

Como fatiar a entrega passo a passo

O roteiro abaixo é um ciclo

Você roda ele inteiro por fatia, e só depois abre a próxima

1. Escreva o resultado verificável da fatia em uma frase. Não é "melhorar o login", é "o teste X passa" ou "essa tela abre com o estado novo e eu tiro um screenshot". O erro comum deste passo é descrever a MUDANÇA em vez da PROVA: se a frase não contém algo que roda, você ainda não tem uma fatia

2. Decida plano ou pedido direto pela regra do diff. A documentação orienta usar plano quando a mudança envolve vários arquivos ou o código é desconhecido, e pedir direto quando o escopo é claro e a correção é pequena. A regra prática publicada é: "se você consegue descrever o diff em uma frase, pule o plano". O erro comum é planejar tudo por precaução e gastar contexto num plano que você não precisava

3. Abra o modo plano e corte o plano até sobrar uma fatia. Shift+Tab até a barra de status mostrar o modo plano ligado, ou já iniciar a sessão com a flag:

   claude --permission-mode plan

No modo plano o Claude lê arquivos e responde sem alterar nada, então dá pra discutir o corte sem risco

Ctrl+G abre o plano no editor de texto pra você editar direto, e é aí que você APAGA o que não é desta fatia

O erro comum deste passo é aprovar um plano bonito e completo: plano completo é o inimigo, você quer o plano curto

4. Mande a exploração pesada pra subagentes. Subagentes preservam contexto mantendo exploração e implementação fora da conversa principal, além de permitir limitar ferramentas, reutilizar configurações e rotear tarefas pra modelos mais baratos. Se você já brincou de subagente por tarefa ou execução em lotes, a lógica é a mesma aqui: quem varre o repositório não é quem escreve o código. E como dá pra escolher modelo por tipo de trabalho, vale o mesmo raciocínio de escolher o modelo por tarefa, com o barato fazendo a leitura e o caro fazendo a decisão. O erro comum é deixar a conversa principal ler tudo e chegar na hora de implementar já sem espaço

5. Execute e verifique. Rode o que você escreveu no passo 1: teste, script ou screenshot. O erro comum é aceitar "deve funcionar" como fechamento, e a régua da documentação não deixa: sem verificação, não tem ship

6. Revise o diff em contexto limpo. A recomendação é revisar o diff em um contexto limpo antes de dar a tarefa por concluída, e existe uma skill embutida pra isso:

   /code-review

Ela revisa o diff atual em um subagente novo e devolve os achados pra sessão

O erro comum é pedir revisão na MESMA conversa que escreveu o código: quem acabou de justificar a decisão tende a concordar com ela

7. Feche a fatia antes de abrir a próxima. Se a próxima fatia é independente, /clear e começa do zero com a memória do projeto intacta. Se ela precisa levar alguma coisa junto, /compact com instrução de foco, apontando o que deve sobreviver no resumo. O erro comum é emendar a fatia nova na conversa velha e carregar contexto que já não serve pra nada

8. Quando a fatia der errado, volte. O comando /rewind, ou Esc duas vezes com o campo de entrada vazio, abre o menu de rewind. As opções de restaurar código só aparecem quando o checkpoint selecionado tem alterações de arquivo registradas. E se liga nisso: checkpoints são apagados junto com as sessões após 30 dias, então eles servem pra desfazer o que acabou de acontecer na sessão, e quem te dá segurança de verdade continua sendo o histórico de commits

Repare que o ciclo tem começo, meio e fim claros

É isso que faz o Claude Code TERMINAR: não é prompt mágico, é ponto de chegada perto o suficiente pra ser alcançado

Exemplos de corte: como três entregas grandes viram fatias

A teoria é fácil, o difícil é decidir ONDE cortar

Três recortes que aparecem sempre:

Refatoração que toca muitos arquivos:

O instinto é pedir a refatoração inteira de uma vez, e é exatamente aí que a sessão se perde

O corte é por comportamento preservado: uma fatia por unidade que já tem como ser provada

A verificação que fecha cada fatia é a suíte de testes daquele pedaço passando igual antes da mudança

A exploração de "quem usa isso aqui" vai pra subagente, não pra conversa principal

Feature nova de ponta a ponta:

Aqui o corte é por camada, e cada camada precisa terminar em algo que roda

Uma fatia pro dado e as regras, com teste como verificação

Outra fatia pro caminho que expõe isso, verificada por script ou chamada real

Outra pra interface, verificada por screenshot

O erro clássico é fatiar por camada mas verificar só no fim: aí você não fatiou nada, só adiou o problema

Migração ou varredura repetitiva:

Esse é o mais fácil de cortar e o mais fácil de errar

O corte é por lote, e a primeira fatia é sempre UM caso, feito com cuidado e verificado

Esse primeiro caso vira o padrão

As fatias seguintes aplicam o padrão em lotes, com a mesma verificação em cada lote

E aqui os subagentes brilham, porque cada item do lote é trabalho isolado que não precisa morar na conversa principal

O próximo passo

Se tem uma coisa pra levar deste post é essa: fatia sem verificação não é fatia, é só uma pausa no meio da mesma tarefa gigante

A ação imediata é curtinha

Roda /context na sessão que está aberta agora e olha o que está ocupando espaço

Escreve em UMA frase o resultado verificável da próxima fatia, aquele que você consegue rodar

Abre o modo plano com Shift+Tab e corta o plano até sobrar só ela

Depois é o ciclo: executa, verifica, revisa em contexto limpo, fecha e abre a próxima

É menos empolgante que pedir o projeto inteiro de uma vez, e é o que faz a entrega chegar no fim 😀

até o próximo post!