2.1 Abra Toda Sessão com um Plano | Mestre em Contexto e Tokens

🎯 Plan mode oficial

O Claude Code tem um modo plano nativo. Ativado, o Claude só tem acesso a ferramentas de leitura — ele pode investigar, mas não tocar em arquivo. A saída é um plano estruturado que você revisa antes de liberar a execução.

Duas formas de entrar em plan mode

⌨️

Opção A — Atalho Shift+Tab

Cicla pelos 3 modos disponíveis:

default → accept edits → plan mode → (ciclo)

📝

Opção B — Comando /plan [descrição]

Entra direto com o objetivo embutido. Ex.: /plan adicionar auth JWT ao endpoint /login.

🔒O que Claude pode (e não pode) fazer em plan mode

✓ Permitido (read-only)

•Read — ler arquivos
•Grep — buscar no código
•Glob — listar arquivos
•WebFetch / WebSearch

✗ Bloqueado

•Edit / Write — modificar arquivos
•Bash destrutivo
•MCPs que modificam estado externo
•Qualquer side-effect não reversível

💡Por que isso é importante

A restrição não é limitação — é guard-rail. O Claude não consegue "pular direto para código" mesmo que queira. Ele investiga, monta plano, apresenta. Você aprova conscientemente. É o contrário de "executa e vê no que dá".

📝 Template de abertura de sessão

Este é o prompt que você cola toda vez que abre uma sessão nova para um trabalho não-trivial. Quatro linhas. Estrutura fixa. Preenche os placeholders.

Prompt copiável template de abertura

Vamos trabalhar em modo planejamento.
Objetivo: [X]
Contexto: [repo / arquivos relevantes]
Antes de tocar em código, me proponha um plano em no máximo 5 passos.

Exemplo preenchido

Vamos trabalhar em modo planejamento.

Objetivo: adicionar rate limiting no endpoint /api/login

Contexto: src/api/auth/*, usar Redis que já está em docker-compose.yml

Antes de tocar em código, me proponha um plano em no máximo 5 passos.

Anatomia das 4 linhas

🎛️

Linha 1 — Declara o modo

Reforça plan mode textualmente mesmo se já ativado pelo atalho. Claude fica "no pé" da regra.

🎯

Linha 2 — Objetivo único

Uma coisa só, específica. Se tem "e", provavelmente são duas sessões.

📍

Linha 3 — Contexto pontual

Indica onde olhar sem despejar 20 arquivos. Claude abre por demanda.

📐

Linha 4 — Restrição de tamanho

"Máximo 5 passos" força enxugamento. Sem isso, planos viram tratados.

⏱️Vale os 30 segundos

Copiar-colar e preencher leva meio minuto. Depois desse meio minuto você tem um plano avaliado, sem surpresas. Vs. "começar direto": 5 minutos até perceber que o modelo entendeu errado.

🔍 Como bom plano evita retrabalho

Retrabalho é o maior sumidouro de tokens. Um plano revisado antes de executar captura 80% dos erros que iriam aparecer depois, num estágio onde corrigir custa ~0 tokens.

❌ Sem plano — "faça tudo"

Você:

"implementa cache para os endpoints /api/*"

→Claude escolhe Redis (você queria in-memory)

→Aplica em /api/metrics (você não queria)

→TTL fixo de 60s (você queria config)

→15 turnos depois, metade refeita

Custo real

~US$ 3,80

✓ Com plano — 3 passos claros

Plano proposto:

1. middleware in-memory com TTL config
2. aplicar em /api/products e /api/users
3. não tocar em /api/metrics

→Você corrige antes: "TTL via env, não config file"

→Aprova e executa em 3 turnos

→Zero retrabalho

Custo real

~US$ 0,60

Economia com plano

~6×

no mesmo trabalho. Dois minutos de planejamento valem a conta.

4 erros que planejar filtra

Escopo inflado — Claude decide tocar em mais arquivos que necessário. Plano mostra o mapa, você poda.

Escolha técnica errada — Redis vs in-memory, bcrypt vs argon2. No plano dá para alinhar; depois é refactor.

Suposição não declarada — "Assumi que vocês usam Zod". Se não usam, descobriu antes de codar.

Ordem ruim — Testes antes da implementação? Migration antes do model? Plano deixa visível.

💡 Perguntar primeiro, executar depois

Um plano que diz "não sei X, me explica?" é melhor que um plano confiante que chuta. Plan mode incentiva isso porque Claude tem tools de leitura — ele consegue ir até onde o código permite antes de admitir limite.

✗ Plano confiante que chuta

1. Criar middleware em src/middleware/rate.ts

2. Usar express-rate-limit

3. Configurar 100 req/min

4. Aplicar globalmente

Problema: seu projeto usa Fastify, não Express. E o limite devia ser por rota. Vai descobrir no passo 4.

✓ Plano que admite incerteza

Antes de propor passos, tenho perguntas:

• Você usa Fastify ou Express? Vi fastify/plugin no package.json

• Rate limit por rota ou global?

• Redis está disponível em dev também?

→ Respondeu → Claude gera plano correto na primeira.

🧠Incentivo via CLAUDE.md

Coloque uma linha como esta no seu CLAUDE.md:

> Em plan mode, prefira perguntar quando houver ambiguidade a assumir. Listar perguntas antes do plano é encorajado.

Isso calibra o Claude para o comportamento que você quer — sem precisar pedir toda vez.

Tipos de incerteza que valem pergunta

Categoria	Exemplo	Custo se errar
Stack	ORM? Framework HTTP?	refactor inteiro
Convenção	camelCase ou snake?	find & replace
Escopo	Mobile também?	dobra o trabalho
Segurança	Tokens em cookie ou header?	revisão completa
Performance	Cache agressivo ou conservador?	ajuste de config

📐 Planos pequenos: 3–5 passos

Se seu "plano" tem 10 passos, você não fez um plano — fez um projeto. Projetos precisam de etapas com handoff. Planos cabem em 3–5 passos executáveis numa sessão.

Tamanho do plano — regras de bolso

Ideal

Bug fix, feature pequena, refactor pontual. Fecha em 1 sessão.

Máximo saudável

Feature de tamanho médio. Sessão cheia, mas cabe.

Vira projeto

Tem que quebrar em 2 sessões com handoff entre elas.

10+

Quebra obrigatória

Vai estourar contexto ou context rot antes de acabar.

✗ Plano inchado (9 passos)

1. Criar migration

2. Criar model

3. Criar repository

4. Criar service

5. Criar controller

6. Criar rotas

7. Criar DTOs

8. Adicionar validation

9. Adicionar testes

Parece completo mas não cabe numa sessão. Até o passo 5, contexto já está saturado.

✓ Plano enxuto (3+3 passos)

Sessão A (data layer)

1. Migration + model

2. Repository

3. Testes do repository

Sessão B (HTTP layer) — handoff

1. Service + DTOs

2. Controller + rotas

3. Testes de integração

✂️Quando Claude sugerir 8+ passos

Responda: "ok, qual é o MVP dentro disso? Vamos fechar o primeiro bloco de 3 passos, depois conversamos para o segundo." Você acabou de transformar um projeto em duas sessões — e garantiu que cada uma termine.

🔄 Revisar plano antes de aceitar

Plano apresentado ≠ plano aprovado. Esta é a etapa mais barata de corrigir — antes do primeiro Edit, você ainda gastou poucos tokens e zero linhas de código.

Checklist mental antes de aprovar

Objetivo bate? — O plano endereça o que eu pedi, nem mais nem menos?

Ordem faz sentido? — Cada passo libera o seguinte?

Cada passo é específico? — Ou há vaguezas tipo "ajustar conforme necessário"?

Escolhas técnicas corretas? — Bibliotecas, padrões, estruturas alinhados com o projeto?

Cabe em 3–5 passos? — Ou inflou? Se inflou, qual o MVP?

Existem suposições escondidas? — Claude assumiu algo que eu não validei?

💬Frases que refinam sem reescrever tudo

"refina passo 2 — detalhe qual arquivo, qual função"

"inverta 3 e 4, faz mais sentido"

"tire o passo 5, fora do escopo dessa sessão"

"no passo 1, use zod em vez de joi"

"o passo 2 está vago, especifique o arquivo"

Edições cirúrgicas preservam o resto do plano. Mais barato que pedir "faça tudo de novo".

✓ Revisão ativa

✓Leia cada passo completo
✓Desafie suposições nomeadas
✓Refine passo a passo
✓Só aprove quando estiver limpo

✗ Aprovação no automático

✗"ok, pode fazer"
✗Saltar o passo vago "e o que mais for necessário"
✗Aceitar plano de 12 passos
✗Ignorar sinal de alerta ("talvez", "se eu entendi")

📋Resumo do Módulo

✓

Plan mode é oficial — Shift+Tab ou /plan, só read-only

✓

Template de 4 linhas — modo, objetivo, contexto, tamanho

✓

Plano bom evita retrabalho — ~6× de economia em exemplo real

✓

Pergunte antes de executar — incerteza admitida > suposição silenciosa

✓

3–5 passos, não 10 — se maior, é projeto e vai para 2 sessões

✓

Revise antes de aprovar — checklist de 6 perguntas

Próximo módulo:

2.2 — 🧱 Trabalhe em Blocos

Como fatiar a execução em unidades curtas, com checkpoints entre cada uma.

← Voltar para Trilha Próximo: Trabalhe em Blocos →