Hoje eu tenho oito Claude Projects ativos. Um pra me ajudar a escrever, um pro desenvolvimento do WP-AutoInsight, um pro meu portfólio e cinco pros clientes que estou atendendo agora. Nenhum compartilha arquivo. Nenhum compartilha instrução. Cada um está configurado pra que, quando eu abro numa segunda de manhã, o Claude já saiba quem é o cliente, que stack ele usa, o que eu já decidi sobre o problema dele até aqui e que tipo de resultado eu quero. Às vezes até o jeito como o Claude me responde muda de um pra outro. Afinal, por que eu não posso ter um Claude com personalidade?
Antes de trabalhar assim, eu nem usava Projects. Trabalhava como a maioria das pessoas trabalha no ChatGPT gratuito: um monte de conversas, arquivos espalhados, contexto faltando o tempo todo, e eu precisando recalibrar o Claude a cada vez pra ele saber do que a gente estava falando. Era pior que inútil. O Claude pegava a voz errada pro cliente errado, citava a stack de outra pessoa ou gerava código num framework que o cliente da vez nem usava. Eu usava a ferramenta como a maioria dos consultores usa: como um histórico de chat metido a besta.
Este post é sobre como usar Claude Projects de verdade se você é freelancer ou consultor e atende vários clientes ao mesmo tempo. A ideia é bem simples: um projeto por cliente, com arquivos e instruções específicos, tratado como infraestrutura de trabalho que você mantém do mesmo jeito que mantém um repositório de código.
Vou passar por um projeto real, do começo ao fim, pra você ver o que vai em cada arquivo e por quê.
O que é um Claude Project, afinal
Um Project é um espaço de trabalho isolado dentro da sua conta do Claude. Ele tem três coisas que a maioria das pessoas nem nota:
Uma base de conhecimento, onde você sobe documentos de referência. O Claude lê esses documentos antes de cada resposta dentro daquele projeto.
Instruções personalizadas que valem pra todo chat dentro do projeto. Não é por mensagem. É em toda mensagem, automaticamente.
Uma janela de contexto de 200K, dividida entre a base de conhecimento e a conversa. Dá umas 500 páginas de texto, o que parece muito até você tentar enfiar ali o código de um cliente, o guia de marca, os últimos três planejamentos trimestrais e dois meses de conversa.
Projects estão nos planos Pro e Team. Se você ainda está no plano gratuito e faz consultoria, esse recurso sozinho costuma justificar o upgrade.
O erro clássico: um projeto pra tudo
O padrão da maioria dos consultores e freelancers é criar um projeto chamado "Trabalho" ou "Clientes" e jogar tudo lá dentro. Às vezes a pessoa até cria pastas ou usa nomes de arquivo tipo cliente-a-spec.pdf pra manter a separação na própria cabeça.
Não funciona.
Primeiro: o Claude lê todos os arquivos do projeto a cada mensagem. Você paga contexto por cinquenta documentos que não têm nada a ver toda vez que pergunta algo sobre um cliente.
Segundo: a voz e as instruções vazam. Se o Cliente A quer inglês formal, o Cliente B quer espanhol informal e o Cliente C quer português profissional, um único bloco de instruções não serve pros três. Você acaba negociando com o prompt toda vez, o que joga fora o motivo de ter um projeto.
Terceiro: você perde a capacidade de passar o trabalho adiante. Se eu precisar deixar um consultor júnior usar o Claude Project de um cliente específico, consigo convidar só pra esse projeto, sem expor as informações de todos os outros clientes.
Um projeto por cliente. Não por linha de serviço. Por cliente.
Passo a passo: um projeto de consultoria de verdade
No ano passado peguei uma consultoria pra uma empresa de e-commerce que precisava reconstruir o pipeline de conteúdo de SEO. A entrega acabou sendo a automação que está no meu portfólio: fluxos no n8n, integração com o Google Search Console, rascunhos estruturados no WordPress com revisão humana. Isso foi o que eu construí pra eles.
Mas, separado disso, dentro da minha conta do Claude, eu tinha um projeto chamado mais ou menos Cliente: [Ecommerce] - SEO Pipeline, que eu usava pra pensar sobre o trabalho. O pipeline de produção usa o Claude pela API. Isso aqui era outra coisa: o meu ambiente de trabalho como consultor.
O arquivo de instruções
Curto. Meia página, no máximo. Era mais ou menos assim:
Cliente é uma empresa de e-commerce operando em um segmento XXXX.
Stack principal: WordPress X.YZ + WooCommerce X.YZ, n8n para automação, Google Search Console para dados.
Meu papel: tech lead externo. Eu escrevo recomendações, decisões de arquitetura e planos de implementação. Eu não
escrevo texto de marketing para eles.
Voz: direta, técnica, supõe um leitor de engenharia. Siga o tom dos documentos de referência do projeto.
Quando eu pedir código, use PHP (WordPress) ou JavaScript (fluxos do n8n) por padrão. Pergunte antes de usar outra linguagem.
Quando eu fizer perguntas estratégicas, questione se a pergunta estiver mal formulada. Não responda no automático; pergunte se eu estiver indo contra os objetivos do projeto.
Sinalize incerteza. Se uma decisão depende de informação que não está na base de conhecimento, diga isso antes de chutar.
É isso. Nada de lista com vinte regras. Nada de prompt de personalidade. Nada de teatro do tipo "aja como um consultor sênior". Só o contexto que o Claude não tem como saber sem alguém contar.
A linha do questione é a que quase ninguém coloca e a que mais rende. O padrão do Claude é responder o que você perguntou. Isso é um problema de praticamente todos os modelos de IA até hoje. Em consultoria, às vezes o que você perguntou é a pergunta errada, e você quer um modelo que te diga isso.
A base de conhecimento
Poucos arquivos. Nunca mais de dez por cliente ou projeto.
1. Briefing do projeto. Um documento de uma ou duas páginas que eu escrevo no começo de todo trabalho. O que o cliente quer, do que ele precisa de verdade (quase sempre é outra coisa), o que está no escopo, o que está fora dele de propósito e quais são os critérios de sucesso. É o arquivo mais importante do projeto. É ele que mantém o Claude (e eu) no trilho quando a conversa começa a desviar.
2. Inventário da stack. Um arquivo de texto puro com todas as tecnologias do cliente. Não é diagrama. É lista. WordPress 6.5 / WooCommerce 8.2 / n8n auto-hospedado na Hetzner / Google Search Console / Mailchimp / Stripe. Quando eu pergunto ao Claude como resolver um problema, ele não sugere um plugin de Shopify, porque sabe que o site não é Shopify.
3. Log de decisões. Um documento que vai crescendo e que eu atualizo depois de toda conversa importante. Entradas curtas. Decidido usar n8n em vez de Make porque o cliente já tem n8n auto-hospedado e Make seria um centro de custo novo. (2026-02-14) Isso impede o Claude de rediscutir decisões que eu já tomei, e me impede de rediscutir também.
4. Notas do estado atual. O que existe hoje no sistema do cliente. O que está quebrado. O que funciona. O que já foi tentado antes de mim. Isso envelhece rápido, então vale ter a rotina de atualizar toda semana.
5. Amostra da voz do cliente (quando faz sentido). Nos trabalhos em que eu escrevo conteúdo ou documentação pro cliente, dois ou três textos dele, pra que o resultado saia com a voz dele e não com a minha. Em trabalho puramente técnico, eu pulo esse.
6. Arquivo de restrições. O que o cliente não pode ou não quer fazer. "Nada de assinatura mensal de SaaS." "Tem que funcionar dentro do admin do WordPress que já existe, sem painel separado." "Nenhuma chamada de LLM que mande dado pessoal de cliente pra serviço externo." São as regras que moldam toda recomendação, e sem elas o Claude vai sugerir, todo feliz, soluções que o cliente já recusou.
É isso. A base de conhecimento inteira do projeto. Seis arquivos, cada um com menos de cinco páginas. Se você tiver isso bem organizado, já está à frente de muita gente da área.
Como fica na prática
Numa terça de manhã, eu abro o projeto e pergunto algo como: "O cliente quer adicionar meta descriptions por produto geradas por IA. Eles perguntaram sobre o ChatGPT. O que eu devo propor?"
A resposta do Claude não é genérica. Ele já sabe que:
- A stack é WordPress + WooCommerce (então a integração passa por um plugin ou por um fluxo no n8n, e não por uma ferramenta avulsa)
- O n8n é auto-hospedado (então o custo por chamada de API pesa mais que preço por usuário)
- O arquivo de restrições proíbe mandar dado de produto pra serviço externo (então a recomendação leva em conta onde os dados ficam)
- O log de decisões mostra que já escolhemos o Claude via API da Anthropic pra outra parte do pipeline (então propor outro provedor agora fragmentaria a stack)
- O briefing diz que os critérios de sucesso incluem revisão humana de toda descrição gerada (então qualquer proposta precisa de uma fila de revisão)
Recebo em uns cinco segundos uma resposta que eu levaria meia hora pra rascunhar do zero, e não preciso reexplicar o projeto pra conseguir. Esse é o valor de um Project bem feito.
Manutenção: onde a coisa pode desandar
Montar um projeto leva uma hora. Manter ele útil leva dez minutos por semana.
Toda sexta, no fim do expediente, pra cada projeto de cliente ativo, eu faço quatro coisas:
- Peço ao Claude um resumo de tudo o que foi feito e atualizo as notas do estado atual com o que mudou na semana
- Acrescento entradas novas no log de decisões (se houve decisão)
- Tiro os arquivos que deixaram de ser relevantes
- Ajusto as instruções do projeto (se precisar)
Se eu pulo isso por um mês, o projeto começa a mentir pro Claude. E aí o tempo que eu gasto lembrando o Claude das últimas decisões e do trabalho já feito só aumenta.
Trate os arquivos do projeto como documento de trabalho, e não como um upload que você faz e esquece.
Quando o projeto acaba
Quando um projeto termina, eu não apago. Arquivo, o que na prática quer dizer tirar da minha lista de Claude Projects e guardar os arquivos numa pasta no meu computador, com nome e data.
Dois motivos. Primeiro: cliente volta, e quando volta eu quero recarregar o contexto em uns cinco minutos, e não reconstruir tudo de memória. Segundo: o briefing e o log de decisões viram material de referência valioso pra projetos parecidos no futuro. Quando outro cliente pergunta sobre conteúdo de SEO com ajuda de IA, eu reaproveito a estrutura do trabalho anterior (não os dados específicos do cliente) como esqueleto do projeto novo.
Aproveito pra dizer uma coisa óbvia que ninguém diz: não suba num Claude Project nada que você não aceitaria ver processado por um terceiro. A Anthropic tem boas práticas de privacidade, mas a regra em consultoria é a mesma de qualquer ferramenta na nuvem. Se o cliente assinou um NDA que proíbe processamento de dados por terceiros, respeite e ache outro caminho.
Se você tiver estrutura pra isso, é melhor usar um LLM local pra analisar os dados do que quebrar o contrato.
O checklist rápido
Se você é consultor ou freelancer e quer montar isso amanhã:
- Um projeto por cliente ativo, com nome claro
- Seis arquivos por projeto, e não quarenta: briefing, inventário da stack, log de decisões, estado atual, amostra de voz (se fizer sentido), restrições
- Instruções com menos de meia página, incluindo uma linha pedindo pro Claude questionar pergunta ruim
- Dez minutos de manutenção por projeto por semana
- Arquivar no fim do trabalho, e não apagar
Faça isso e o custo de trocar de contexto cai de "começar todo chat explicando de novo quem é esse cliente" pra "abrir o projeto, fazer a pergunta e receber uma resposta que já conhece o terreno".
Leitura relacionada nesta série
Este é o terceiro artigo de uma série curta sobre usar o Claude em trabalho de produção. Os dois primeiros:
Claude, Honestamente: O que Realmente Muda Quando Você o Usa em Produção: a visão geral, incluindo onde o Claude ganha, onde não ganha, e o argumento de que o contexto importa mais que o modelo.
Como Fazer o Claude Escrever na Sua Voz (Sem Quebrar Isso): o texto sobre calibração de voz, que na verdade é uma aplicação específica do mesmo padrão de Projects descrito aqui.
Se você quiser ajuda pra montar isso
Se você toca uma consultoria ou trabalha como freelancer e o seu uso de IA está um caos (contexto espalhado em vários chats, voz inconsistente entre entregas, todo cliente novo começando do zero), essa arrumação costuma levar meio dia: organizar o contexto dos clientes atuais em projetos bem montados, um pouco de calibração de voz, e o trabalho de integração voltado ao cliente que precise acontecer à parte.
Me conta quantos clientes ativos você está equilibrando, ou escreve pra me@phalkmin.me, e eu digo se o Claude Projects resolve ou se o problema está em outro ponto do seu processo.
E se você for montar sozinho: não comece com todos os clientes de uma vez. Escolha o trabalho mais bagunçado, monte o projeto desse cliente, use por uma semana e depois replique o padrão nos outros. Tentar migrar oito clientes numa tarde é o jeito certo de terminar com oito projetos pela metade e nenhum sistema funcionando.
Um projeto, uma semana. Depois você expande.