Como dar contexto ao Claude sem repetir tudo em toda conversa

Fala aí, beleza? Toda conversa nova com o Claude começa no zero absoluto, e é aí que você paga o pedágio de novo

Explica a stack, explica o que não pode mudar, explica como quer a resposta formatada, cola o mesmo trecho de código de sempre

Dez minutos de digitação antes de fazer o pedido de verdade

O problema não é o modelo, é o hábito de escrever o pedido. Contexto colado na pressa morre junto com o chat, e no dia seguinte tu recomeça tudo

A saída é montar UM bloco de contexto reaproveitável: objetivo, restrições, formato esperado e um exemplo do que é bom. Escreve uma vez, cola em qualquer conversa nova, e depois guarda num lugar que carrega sozinho

Bora ver na prática? 🙂

O que você precisa antes de começar

A lista é curtinha, não precisa de PC da Nasa aqui:

• Uma conta do Claude (os Projects estão disponíveis inclusive no plano grátis, com máximo de 5 projetos) ou o Claude Code instalado no seu projeto
• Um editor de texto qualquer pra escrever o bloco, pode ser o mesmo editor do teu código
• Clareza sobre o que se REPETE nas tuas conversas: stack, regras do projeto, formato de saída que tu sempre pede

Esse último item é o que dá trabalho de verdade

Abre as suas últimas conversas e olha o que tu digitou três, quatro vezes. Aquilo ali é o teu bloco de contexto esperando pra nascer

Como montar o bloco de contexto reaproveitável (passo a passo)

A ideia é ter um esqueleto fixo de quatro partes, e só trocar o recheio conforme o projeto

Se você já mexeu com template de documento, é a mesma lógica: a forma fica, o conteúdo muda

1. Escreva o objetivo em uma frase

Uma frase, não um parágrafo. O que essa conversa precisa produzir?

“Gerar migrations do banco seguindo o padrão do projeto” é objetivo

“Me ajudar no sistema” não é nada

O erro comum deste passo: objetivo vago. Quando o objetivo é genérico, a resposta vem genérica e tu culpa o modelo

2. Liste as restrições, inclusive as óbvias pra você

Aqui entra o que NÃO fazer e os limites do projeto: biblioteca proibida, pasta que não se toca, versão presa, convenção de nome

Aquilo que tu acha óbvio demais pra escrever é justamente o que o Claude não tem como adivinhar

O erro comum deste passo: restrição implícita. Tu sabe que aquele arquivo é legado e não pode mexer, mas isso mora só na tua cabeça

3. Descreva o formato esperado da resposta

Quer o diff completo ou só o trecho alterado? Quer explicação antes ou depois do código? Quer lista, tabela, texto corrido?

Escreve isso uma vez e para de corrigir formato em toda resposta

O erro comum deste passo: pedir formato só depois de receber a resposta errada, o que gasta duas rodadas pra fazer o trabalho de uma

4. Cole um exemplo do que é uma boa resposta

Essa é a parte que mais muda o jogo, e não é achismo meu: é a técnica de exemplos (multishot) do guia oficial de prompting da Anthropic, que cobre clareza, exemplos, estruturação com XML, role prompting, thinking e encadeamento de prompts

Pega uma resposta antiga que ficou boa de verdade e cola ela como referência

O erro comum deste passo: exemplo genérico. Exemplo inventado na hora ensina o modelo a imitar coisa que tu nem quer

5. Separe as partes com tags XML

A documentação da Anthropic recomenda usar tags XML quando o prompt tem componentes diferentes (contexto, instruções e exemplos), porque isso ajuda o Claude a interpretar o pedido com mais precisão

Na prática, fica assim:

<instructions>
Objetivo: gerar migrations do banco seguindo o padrao do projeto

Restricoes:
- nao alterar arquivos dentro de /legacy
- toda migration precisa de rollback
- nome no formato NNNN_descricao_curta
</instructions>

<formatting>
Responda com o arquivo completo em bloco de codigo,
depois 2 linhas explicando o que muda no banco
</formatting>

<example>
0042_add_index_slug.sql
(cola aqui uma migration real que ficou boa)
</example>

E se tu precisa passar documentos junto, a orientação é envolver cada um em tags <document>, com as subtags <document_content> e <source>:

<document>
  <source>docs/convencoes-do-time.md</source>
  <document_content>
  ...conteudo do arquivo...
  </document_content>
</document>

O erro comum deste passo: jogar tudo num blocão só, sem separação. Aí instrução, exemplo e documento viram a mesma sopa e o modelo tem que chutar quem é quem

6. Corte o que não serve mais

A Anthropic tem um material próprio sobre engenharia de contexto para agentes de IA, e a linha central é essa: contexto é recurso a ser CURADO, não acumulado

Bloco de contexto é jardim, não porão. Toda vez que uma regra morre no projeto, ela sai do bloco

O erro comum deste passo: o bloco que só cresce. Ele vira uma bagunça com regra de 2024 convivendo com regra de hoje, e o modelo obedece as duas

Se você já sentiu as respostas ficarem arrastadas conforme o projeto engorda, vale entender antes se a lentidão é do seu projeto ou do serviço, porque o remédio é bem diferente em cada caso

Onde guardar o bloco para ele carregar sozinho

Colar o bloco em toda conversa já resolve muita coisa

Mas dá pra fazer melhor: cada produto tem o seu lugar pra guardar isso e carregar sem tu pedir

Atenção aqui, porque as coisas NÃO se misturam: instrução de Claude Code não vale pro Claude.ai e vice-versa

No Claude Code:

O Claude Code tem dois sistemas de memória complementares: os arquivos CLAUDE.md, que são as instruções que VOCÊ escreve, e a memória automática, que são notas que o próprio Claude escreve a partir das suas correções e preferências

Os dois são carregados no início de cada conversa

1. Comece pelo /init

O comando /init gera um CLAUDE.md inicial analisando o codebase, com comandos de build, instruções de teste e convenções do projeto

É um ponto de partida bem melhor que a folha em branco, e depois tu edita em cima

2. Coloque o arquivo no caminho certo

O CLAUDE.md do projeto pode ficar em dois caminhos aceitos: ./CLAUDE.md ou ./.claude/CLAUDE.md

Escolhe um e segue nele

3. Entenda quando cada arquivo carrega

Os arquivos CLAUDE.md e CLAUDE.local.md que estão na hierarquia de diretórios ACIMA do diretório de trabalho são carregados por inteiro na abertura da sessão

Já os que estão em subpastas carregam sob demanda, quando o Claude lê arquivos daquelas pastas

Isso muda como tu organiza: regra que vale sempre fica em cima, regra de um módulo específico fica na pasta dele

4. Separe o que é seu do que é do time

Para preferências privadas por projeto, aquelas que não devem entrar no controle de versão, existe o CLAUDE.local.md na raiz do projeto, carregado junto do CLAUDE.md

A orientação é adicionar ele no .gitignore

O erro comum deste passo: commitar preferência pessoal e encher o repositório do time com mania sua 😛

5. Decida sobre a memória automática

A memória automática é ligada e desligada pelo comando /memory dentro da sessão, que grava a chave autoMemoryEnabled nas configurações de usuário, em ~/.claude/settings.json

6. Saiba o que é do projeto e o que é seu

O Claude Code lê instruções, configurações, skills, subagents e memória tanto do diretório do projeto quanto de ~/.claude no diretório home

O que está em ~/.claude é configuração pessoal e vale para TODOS os seus projetos

O que está no projeto pode ser commitado no git para o time

No Claude.ai:

Aqui o nome da coisa é Projects

Eles são espaços de trabalho independentes, com histórico de conversas e base de conhecimento próprios, onde tu sobe documentos e dá contexto para chats focados

1. Use as instruções de projeto pro seu bloco

As instruções de projeto valem apenas para os chats daquele projeto e servem para dar contexto e requisitos específicos, incluindo tom e perspectiva de um papel ou setor

Esse escopo restrito é ótimo: tu pode ter um projeto com regras de código e outro com regras de escrita, sem um contaminar o outro

2. Suba os documentos na base de conhecimento

Na base de conhecimento você pode subir documentos, textos, código e outros arquivos, que o Claude usa como contexto e pano de fundo nos chats daquele projeto

É onde vive aquele PDF de especificação que tu cola pedaço em toda conversa

3. Saiba o que o seu plano entrega

Os Projects estão disponíveis para todos os usuários do Claude, inclusive contas gratuitas, com limite de 5 projetos no grátis

Já o conhecimento de projeto ampliado por RAG é exclusivo dos planos pagos: quando o conteúdo do projeto se aproxima do limite de contexto, o modo RAG entra e expande a capacidade

Três blocos de contexto prontos para adaptar

O esqueleto é sempre o mesmo (objetivo, restrições, formato, exemplo), muda só o recheio

É por isso que o hábito viaja: aprende uma vez, usa em conversa de código, de texto e de dados

Bloco 1: projeto de código

<instructions>
Objetivo: implementar features na API mantendo o padrao existente

Contexto: Node + TypeScript, Postgres, testes em Vitest

Restricoes:
- nada de nova dependencia sem eu aprovar
- toda query nova precisa de teste
- nao refatorar arquivo que nao faz parte do pedido
</instructions>

<formatting>
Entregue o diff apenas dos arquivos alterados,
e uma lista curta do que testar na mao depois
</formatting>

<example>
(cole aqui um diff antigo seu, daqueles que ficaram redondos)
</example>

Esse bloco fica ULTRA útil quando o código é antigo e cheio de armadilha, que é o cenário de quem precisa refatorar um projeto legado sem quebrar o que já funciona

Bloco 2: escrita e conteúdo

<instructions>
Objetivo: escrever posts para um publico de devs iniciantes

Restricoes:
- nada de jargao sem explicar na primeira vez
- sem promessa de formula magica
- nada de numero que eu nao tenha verificado
</instructions>

<formatting>
Paragrafos de 2 a 3 frases, subtitulos que respondem uma duvida,
e uma conclusao curta recapitulando
</formatting>

<example>
(cole um paragrafo SEU que representa bem o tom que voce quer)
</example>

Repara que o exemplo aqui não é decorativo: é ele que carrega o tom, coisa que adjetivo nenhum consegue explicar direito

Bloco 3: análise de dados ou relatório

<instructions>
Objetivo: analisar o export mensal de vendas e apontar o que mudou

Fonte: CSV exportado do sistema, uma linha por pedido
Recorte: comparar sempre com o mesmo mes do ano anterior

Restricoes:
- nao inventar numero que nao esta no arquivo
- se um dado faltar, dizer que faltou em vez de estimar
</instructions>

<formatting>
Comece com 3 conclusoes em bullet,
depois a tabela com os numeros que sustentam cada uma
</formatting>

<example>
(cole um relatorio anterior que voce considerou bom)
</example>

Mesmo esqueleto, recheio completamente diferente, e o ganho é igual nos três: tu para de reexplicar o mundo toda santa vez 😀

O próximo passo

O ganho aqui não vem de escrever MAIS, vem de escrever uma vez e reusar

Quem cola contexto na pressa escreve o mesmo parágrafo cinquenta vezes no mês. Quem monta o bloco escreve uma vez, guarda, e depois só ajusta

Então o próximo passo é bem concreto: abre um documento agora, escolhe o projeto em que tu mais trabalha e escreve as quatro partes

Objetivo em uma frase, restrições, formato esperado, exemplo do que é bom

Depois coloca no lugar certo: CLAUDE.md se você usa Claude Code, instruções de projeto se você usa o Claude.ai

E volta nele de tempos em tempos pra cortar o que morreu, porque projeto muda e contexto velho atrapalha mais que ajuda

Começa pequeno, com quatro linhas mesmo. Ele cresce sozinho conforme tu percebe o que anda repetindo…

até o próximo post!