Escreva um briefing de contexto do Claude que você nunca mais redigita
5 min de leitura
A maioria das pessoas começa todo novo chat do mesmo jeito: uma ou duas frases de contexto e depois o pedido de fato. Seu cargo, sua equipe, no que você trabalha neste trimestre, tudo redigitado de memória, um pouco diferente a cada vez. Funciona, mas é o mesmo custo de configuração pago várias vezes por uma informação que na verdade não mudou.
Dica
Um briefing de contexto não é um prompt mais longo. É o punhado de fatos que são verdadeiros não importa o que você peça naquele dia, escritos uma vez para você parar de decidir de novo como formulá-los.
Se você redigita as mesmas três frases toda semana, elas pertencem a um briefing, não à sua memória.
O que realmente pertence a um briefing
Um briefing de contexto é curto de propósito. Ele guarda os fatos que continuam verdadeiros em muitos pedidos diferentes, não os detalhes específicos da tarefa de hoje. Misturar os dois é o que faz as pessoas desistirem da ideia depois de uma tentativa, já que um briefing que tenta cobrir tudo dá tanto trabalho de manter quanto redigitar.
Seu cargo e sua equipe, com especificidade suficiente para fazer diferença
Termos padrão ou jargão que seu trabalho usa e que o Claude não conheceria de outro modo
Prioridades atuais ou contexto que moldam como você quer que a maioria das coisas seja abordada agora
O que não pertence: qualquer coisa específica de uma tarefa. O prazo deste e-mail em particular, o público deste slide em particular, o número exato deste relatório em particular. Esse detalhe muda toda vez, então pertence ao próprio prompt, não a um briefing que você teria de editar sem parar para mantê-lo correto.
Um erro comum é escrever algo mais próximo de uma biografia completa da equipe do que de um briefing: o nome de cada subordinado direto, cada projeto passado, cada ferramenta que a equipe já usou. Nada disso muda como o Claude deve abordar um pedido típico seu, então nada disso merece um lugar em algo que deve ficar curto o bastante para ser de fato reutilizado. Se um fato não mudaria como o Claude lida com a maioria dos seus pedidos, ele pertence a um documento em outro lugar, não aqui.
Este é o meu contexto: sou líder de operações numa empresa de logística de 40 pessoas. Minha equipe cuida do relacionamento com fornecedores e da documentação de processos internos. Usamos “POP” para procedimento operacional padrão e “a corrida do 3º tri” para nos referir ao nosso projeto atual de consolidação do armazém. Tenha isso em mente pelo resto desta conversa.
”Repare no que falta nesse briefing: nenhuma menção à tarefa específica de hoje. Ela vem depois, no pedido de fato, quando o contexto já está estabelecido.
Onde um briefing realmente vive
Para uma necessidade avulsa, colar o briefing no começo de um chat basta. Custa uma colagem em vez de fragmentos espalhados por dez frases soltas, e o Claude o tem pelo resto daquela conversa.
Para um trabalho que atravessa muitos chats ao longo de semanas ou meses, redigitar o mesmo briefing no começo de todo novo chat anula o propósito. É exatamente a lacuna que um Projeto fecha: guarde o briefing uma vez como instruções permanentes de um Projeto, e todo chat que você iniciar dentro dele já tem esse contexto, sem nada para colar. Se você ainda não configurou um, o artigo sobre trabalhar com Projetos nesta trilha cobre exatamente quando vale a pena.
A linha divisória é a frequência, não a importância. Um briefing para uma única apresentação de grande peso ainda só precisa ser colado uma vez, no começo daquele chat. Um briefing para uma função contínua, que você redigitaria dezenas de vezes ao longo de um trimestre, é o que de fato justifica o custo de configuração de um Projeto.
Dentro do Claude Tutorial
Escrever algo uma vez para parar de repetir é um hábito transferível.
Um briefing de contexto reutilizável é uma versão de um padrão que aparece em todo lugar: escreva a parte estável uma vez, reutilize-a e só mexa na parte que de fato muda. O app tem uma lição completa sobre esse hábito, com prática que se leva muito além de escrever um briefing.
Testando e atualizando quando ele fica ultrapassado
Um briefing que você escreve uma vez e nunca revisita se afasta devagar da realidade. Sua equipe muda, um projeto termina, o jargão que você usava seis meses atrás deixa de significar algo para qualquer um, inclusive você. Trate um briefing como um documento vivo, não como uma tarefa de configuração única.
- 1
Escreva uma primeira versão curta
De três a cinco frases. Se for maior, está resvalando para detalhes específicos de tarefa que pertencem aos prompts individuais.
- 2
Teste num pedido real
Cole o briefing e peça algo que você pediria de qualquer modo. Confira se a resposta de fato reflete o contexto, não só se o Claude confirmou que o leu.
- 3
Revise o que não pegou
Se um termo não foi captado direito, ou uma prioridade não moldou a resposta como você esperava, reescreva aquela única linha em vez do briefing inteiro.
- 4
Revisite quando algo real mudar
Um novo cargo, um projeto encerrado, um jargão que ninguém mais usa. Trate isso como o gatilho para atualizar, não um cronograma fixo.
Com base no contexto que dei acima, algo sobre meu cargo ou a corrida do 3º tri parece desatualizado ou falta algo que mudaria como você abordaria um pedido típico meu? Pergunte-me diretamente se algo não estiver claro.
”Um briefing que realmente funciona some no fundo. Você para de notar que o está usando, e esse é o ponto: o custo de configuração só precisava ser pago uma vez.
Continue lendo
- Trabalhando com Projetos: dando ao Claude um contexto que permanece: onde um briefing como este pertence quando seu trabalho passa de um punhado de chats.
- Começando com o Claude: o hábito anterior de manter um conjunto curto de instruções reutilizáveis, que este artigo transforma em algo mais durável.