Claude Projects para Consultores: Um Projeto Por Cliente, Não Um Para Tudo

Tenho atualmente oito Claude Projects ativos. Um para ajudar com minha escrita, um para desenvolvimento do WP-AutoInsight, um para meu portfólio e cinco para engajamentos ativos com clientes. Nenhum deles compartilha arquivos. Nenhum deles compartilha instruções. Cada um está configurado para que, quando o abro numa segunda-feira de manhã, Claude já saiba quem é o cliente, qual stack eles usam, quais decisões já tomei sobre o problema e que tipo de resultado espero. Às vezes, até o estilo em que Claude me responde é diferente. Quer dizer, por que não posso ter Claude com personalidade?

Antes de trabalhar desse jeito, nem usava projects; trabalhava como a maioria das pessoas no ChatGPT gratuito: várias conversas, arquivos espalhados por tudo, contexto faltando o tempo todo, e eu constantemente precisava calibrar Claude para que soubesse do que estávamos falando. Era pior que inútil. Claude puxava a voz errada para o cliente errado, citava um stack que pertencia a outra pessoa ou produzia código em um framework que o cliente atual não usava. Eu estava usando como a maioria dos consultores usa: como um histórico de chat glorificado.

Este post é sobre como realmente usar Claude Projects se você é freelancer ou consultor trabalhando com vários clientes. É bem simples: um projeto por cliente, com arquivos específicos e instruções específicas, tratado como infraestrutura de trabalho que você mantém da mesma forma que mantém um repositório de código.

Vou caminhar por um engajamento real do começo ao fim para você ver o que pertence a cada arquivo e por quê.

O que um Claude Project realmente é

Um Project é um espaço de trabalho independente dentro da sua conta Claude. Ele tem três coisas que a maioria das pessoas ignora:

Uma base de conhecimento onde você faz upload de documentos de referência. Claude lê esses antes de cada resposta naquele projeto.

Instruções customizadas que se aplicam a todo chat dentro do projeto. Não por mensagem. Todo chat, automaticamente.

Uma janela de contexto de 200K, compartilhada entre a base de conhecimento e a conversa em si. Isso é aproximadamente 500 páginas de texto, o que parece muito até você tentar encaixar o codebase de um cliente, seu guia de marca, seus últimos três planos trimestrais e dois meses de histórico de conversa nela.

Projects estão disponíveis em planos Pro e Team. Se você ainda está no gratuito, esse recurso sozinho é geralmente a razão para fazer upgrade se você faz trabalho de consultoria.

O anti-padrão: um projeto para tudo

A abordagem padrão para a maioria dos consultores e freelancers é criar um projeto chamado "Work" ou "Clients" e despejar tudo nele. Talvez eles adicionem pastas ou usem nomes como client-a-spec.pdf para manter as coisas separadas em suas próprias mentes.

Isso simplesmente não funciona.

Primeiro, Claude lê todos os arquivos do projeto em cada mensagem. Você está pagando um custo de contexto por cinquenta documentos irrelevantes toda vez que faz uma pergunta sobre um cliente.

Segundo, voz e instruções vazam. Se Cliente A quer inglês formal e Cliente B quer espanhol informal, e Cliente C quer português brasileiro profissional, um bloco de instruções único não consegue servir a todos. Você termina hedgeando no prompt toda vez, o que derrota o propósito inteiro de ter um projeto.

Terceiro, você perde a capacidade de delegar trabalho. Se eu precisar deixar um consultor júnior usar o Claude Project para um cliente específico, posso convidá-lo para aquele projeto sem expor informações de todos os outros clientes.

Um projeto por cliente. Não por linha de serviço. Por Cliente.

O passo a passo: um engajamento de consultoria real

Ano passado peguei um engajamento de consultoria com uma empresa de e-commerce que precisava reconstruir seu pipeline de conteúdo SEO. O entregável acabou sendo o pipeline de automação que você pode ver no meu portfólio - workflows n8n, integração Google Search Console, rascunhos WordPress estruturados com revisão humana. Isso é o que construí para eles.

Mas separadamente, dentro da minha própria conta Claude, eu tinha um projeto chamado algo como Client: [Ecommerce] - SEO Pipeline que eu usava para pensar sobre o engajamento. O pipeline de produção usa Claude via API. Isso era uma coisa diferente: meu ambiente de trabalho como consultor.

O arquivo de instruções

Mantido curto. Meia página, no máximo. Este parecia mais ou menos assim:

Cliente é uma empresa de e-commerce operando no segmento XXXX.

Stack primária: WordPress X.YZ + WooCommerce X.YZ, n8n para automação, Google Search Console para dados.

Meu papel: tech lead externo. Escrevo recomendações, decisões de arquitetura e planos de implementação. Não 
escrevo copy de marketing para eles.

Voz: direto, técnico, assume um leitor com background em engenharia. Corresponda ao registro dos documentos de referência do projeto.

Quando peço código, use PHP (WordPress) ou JavaScript (n8n workflows) por padrão. Pergunte antes de usar uma linguagem diferente.

Quando faço perguntas estratégicas, questione se a pergunta está mal formulada. Não apenas responda automaticamente, faça perguntas se estou indo contra os objetivos do projeto.

Sinalize incerteza. Se uma decisão depende de informações não na base de conhecimento, diga isso antes de chutar.

É isso. Sem lista de vinte pontos de regras. Sem prompts de personalidade. Sem "aja como um consultor sênior" roleplay. Apenas o contexto que Claude não consegue saber sem ser informado.

A linha questione é a que a maioria das pessoas não inclui e a que mais compensa. O padrão do Claude é responder o que você perguntou. Isso é um problema com praticamente todos os modelos de IA até agora. Para trabalho de consultoria, o que você pergunta às vezes é a coisa errada a perguntar, e você quer um modelo que diga isso.

A base de conhecimento

Mantenha um número baixo de arquivos. Nunca mais de dez para qualquer cliente/projeto.

1. Brief de engajamento. Um documento de uma a duas páginas que escrevo no início de cada engajamento. O que o cliente quer, o que ele realmente precisa (geralmente diferente), o que está no escopo, o que está explicitamente fora do escopo e quais são os critérios de sucesso. Este é o arquivo mais importante do projeto. É o que mantém Claude (e eu) ancorado quando uma conversa desvia.

2. Inventário de stack. Um arquivo de texto plano listando cada tecnologia no stack do cliente. Não um diagrama. Uma lista. WordPress 6.5 / WooCommerce 8.2 / n8n auto-hospedado na Hetzner / Google Search Console / Mailchimp / Stripe. Quando peço a Claude como resolver um problema, ela não sugere um plugin Shopify, porque sabe que não é um site Shopify.

3. Log de decisões. Um documento em execução que atualizo após cada conversa substancial. Entradas curtas. Decidido usar n8n em vez de Make porque cliente já tem n8n auto-hospedado e Make seria um novo centro de custo. (2026-02-14) Isso previne Claude de relitigar decisões que já tomei e me previne de relitigar também.

4. Notas de estado atual. O que existe agora no sistema do cliente. O que está quebrado. O que está funcionando. O que foi tentado antes de mim. Isso pode ficar desatualizado rápido, então mantenha uma rotina de atualizar a cada semana.

5. Amostra de voz do cliente (quando relevante). Para engajamentos onde estou escrevendo conteúdo ou documentação para o cliente, duas ou três peças de sua escrita existente para que o resultado combine com sua voz em vez da minha. Para engajamentos de pura tech, pulo isso.

6. Arquivo de restrições. Coisas que o cliente não pode ou não fará. "Sem subscrições SaaS mensais." "Deve funcionar dentro do admin WordPress existente, sem dashboards separados." "Sem chamadas LLM que enviem PII de clientes para serviços externos." Essas são as regras que moldam cada recomendação, e sem elas, Claude alegremente sugerirá soluções que o cliente já descartou.

É isso. Toda a base de conhecimento do projeto. Seis arquivos, cada um com menos de cinco páginas. Se você tiver isso bem organizado, já está no topo de outros profissionais.

Como isso funciona na prática

Numa terça de manhã, abro o projeto e pergunto algo como: "O cliente quer adicionar meta descrições de produtos geradas por IA. Perguntaram sobre ChatGPT. O que devo propor?"

A resposta do Claude não é genérica. Ele já sabe:

O stack é WordPress + WooCommerce (então o caminho de integração é um plugin ou workflow n8n, não uma ferramenta standalone)
n8n é auto-hospedado (então custo por chamada de API importa mais que preço por assento)
O arquivo de restrições descarta enviar dados de produtos para serviços externos (então a recomendação considera residência de dados)
O log de decisões mostra que já escolhemos Claude via Anthropic API para outra parte do pipeline (então propor um provedor diferente agora fragmentaria o stack)
O brief de engajamento diz que os critérios de sucesso incluem revisão humana de cada descrição gerada (então qualquer proposta precisa de uma fila de revisão)

Recebo uma resposta em talvez cinco segundos que levaria meia hora para eu rascunhar do zero, e não preciso re-explicar o engajamento para obtê-la. Esse é o valor de Projects feito direito.

Manutenção: onde as coisas podem dar errado

Configurar um projeto leva uma hora. Mantê-lo útil leva dez minutos por semana.

Toda sexta no final do meu dia de trabalho, para cada projeto de cliente ativo, faço quatro coisas:

Peço a Claude para criar um resumo de todo trabalho feito e atualizo as notas de estado atual com o que mudou essa semana
Adiciono novas entradas ao log de decisões (se houver decisões tomadas)
Removo arquivos que não são mais relevantes
Atualizo as instruções de memória do projeto (se necessário)

Se pulo isso por um mês, o projeto começa a mentir para Claude. Então, o tempo que preciso para manter lembrando Claude das últimas decisões e trabalho já feito fica maior.

Trate os arquivos do projeto como um documento de trabalho, não como um upload configurado e esquecido.

Quando projetos terminam

Quando um projeto termina, não deleto. Arquivo-o, que, na prática, significa remover da minha lista de Claude Projects mas manter os arquivos numa pasta local, nomeada e datada.

Duas razões: Primeiro, clientes voltam, e quando voltam, quero recarregar o contexto em uns cinco minutos em vez de reconstruí-lo da memória. Segundo, o brief do projeto e log de decisões são material de referência valioso para projetos futuros similares. Quando outro cliente pergunta sobre conteúdo SEO assistido por IA, posso puxar a estrutura do engajamento anterior (não os dados específicos do cliente) como estrutura para o novo projeto.

Isso também é um bom lugar para dizer algo óbvio que ninguém diz: não faça upload pra um Claude Project de nada que você não se sentiria confortável tendo processado por terceiros. Anthropic tem boas práticas de privacidade, mas a regra para trabalho de consultoria é a mesma que para qualquer ferramenta cloud — se o cliente assinou um NDA que proíbe processamento por terceiros de seus dados, respeite isso e ache uma abordagem diferente.

Se você tem recursos para isso, é melhor usar um LLM local para analisar os dados do que quebrar o contrato.

O checklist rápido

Se você é consultor ou freelancer e quer configurar isso amanhã:

Um projeto por cliente ativo, nomeado claramente
Seis arquivos por projeto, não quarenta: brief de engajamento, inventário de stack, log de decisões, estado atual, amostra de voz (se relevante), restrições
Arquivo de instruções com menos de meia página, incluindo uma linha que diz a Claude para questionar perguntas ruins
Dez minutos de manutenção por projeto por semana
Archive no final do engajamento, não delete

Faça isso e seu custo de context-switching cai de "comece todo chat re-explicando quem é isso" para "abra o projeto, faça a pergunta, receba uma resposta que já conhece o terreno."

Leitura relacionada nesta série

Este é o terceiro artigo numa série curta sobre usar Claude em trabalho em produção. Os dois primeiros:

Claude, Honestamente: O Que Realmente Muda Quando Você o Usa em Produção — a visão geral, incluindo onde Claude ganha, onde não, e o argumento que contexto importa mais que o modelo.

Como Fazer Claude Escrever na Sua Voz (Sem Quebrar Ela) — o artigo sobre calibração de voz, que é realmente uma aplicação específica do mesmo padrão de Projects descrito aqui.

Se você quer ajuda configurando isso

Se você está rodando uma prática de consultoria ou freelance e sua ferramenta de IA é caótica (contexto espalhado por chats, voz inconsistente entre entregas, cada novo engajamento de cliente começando do zero), isso é o tipo de coisa que eu corrijo como parte do trabalho de tech lead embarcado. É geralmente meio dia de estruturação do seu contexto de cliente existente em projetos adequados, mais algum trabalho de calibração de voz, mais seja lá qual integração voltada ao cliente que precisa acontecer separadamente.

Me alcance em me@phalkmin.me ou através do formulário de contato. Me diga quantos clientes ativos você tem e como você gerencia atualmente contexto através deles. Te digo se Claude Projects vai resolver, ou se o problema está em outro lugar no seu processo.

E se você está configurando sozinho: não comece com todos seus clientes de uma vez. Escolha o engajamento mais caótico, construa um projeto para aquele cliente, use por uma semana, e então replique o padrão para os outros. Tentar migrar oito engajamentos numa tarde é como você termina com oito projetos meio-feitos e nenhum sistema funcionando.

Um projeto, uma semana. Depois expanda.

Claude Projects para Consultores: Um Projeto Por Cliente, Não Um Para Tudo