Checklist de Configuração de Projeto: Instruções, Arquivos e Escopo
Uma rápida revisão antes de criar um novo Projeto, para que ele comece útil em vez de precisar de uma reconstrução algumas semanas depois.
Como Usar Este Checklist
- Percorra-o antes de criar o Projeto, não depois - escopo e nomeação são muito mais fáceis de acertar desde o início.
- Trate os itens de escopo como um portão: se você não conseguir respondê-los claramente, as instruções e os arquivos que se seguem serão mais difíceis de acertar.
- Releia este checklist algumas semanas após a configuração para verificar se o uso real do Projeto ainda corresponde ao que você planejou.
- Tudo bem começar com algo menor do que este checklist implica e adicionar profundidade mais tarde - o objetivo é um ponto de partida claro, não um perfeito.
Escopo (1-6)
- Nomeie o propósito único e específico do Projeto. Escreva uma frase descrevendo para que ele serve - "redigir respostas de suporte de faturamento", não "coisas de cliente".
- Confirme se o público é estável. As pessoas ou o contexto para os quais a saída se destina devem permanecer consistentes na maioria das conversas neste Projeto.
- Confirme se as regras são estáveis. As restrições e o tom que se aplicam devem ser válidos para quase todas as conversas que você espera ter aqui.
- Verifique se isso se sobrepõe a um Projeto existente. Se outro Projeto já cobre este público e conjunto de regras, uma nova conversa lá pode ser melhor do que um novo Projeto.
- Decida se isso é realmente um caso único. Se você não espera repetir esse tipo de tarefa, pule o Projeto e use um chat simples em vez disso.
- Escolha um nome específico e descritivo. Nomeie o Projeto de acordo com seu propósito, não uma categoria ampla, para que seu escopo permaneça óbvio mais tarde.
Instruções Personalizadas (7-13)
- Declare explicitamente o público. Para quem é esta saída, e o que eles já sabem ou não sabem?
- Liste o que Claude deve sempre fazer. Comportamentos concretos e verificáveis - formato, comprimento, estrutura, elementos necessários.
- Liste o que Claude nunca deve fazer. Restrições rígidas são mais importantes do que orientações gerais de tom, e são fáceis de esquecer sem anotá-las.
- Defina o tom em termos específicos. "Caloroso e direto" é mais útil do que "profissional".
- Evite frases vagas e inexequíveis. Substitua "seja conciso" por um limite real, como uma contagem de palavras ou seções.
- Mantenha as instruções para um único propósito coerente. Se você estiver cobrindo duas tarefas diferentes, divida-as em dois Projetos em vez de um bloco de instruções mais longo.
- Planeje testar antes de confiar nele. Observe que você executará algumas conversas realistas após salvar, não apenas relerá as instruções para si mesmo.
Arquivos de Conhecimento (14-19)
- Identifique em quais fatos ou terminologia este Projeto realmente depende. Apenas os arquivos que respondem a uma necessidade real e recorrente pertencem aqui.
- Comece com um ou dois arquivos, não com tudo o que você tem. Adicione mais apenas quando lacunas reais aparecerem em conversas de teste.
- Verifique se cada arquivo está atualizado. Um arquivo desatualizado produz respostas confiantemente erradas, já que Claude não tem como saber que está desatualizado.
- Verifique se há sobreposição ou contradição entre os arquivos. Dois arquivos com números diferentes para a mesma coisa produzirão respostas inconsistentes.
- Prefira arquivos curtos e com propósito específico a documentos longos e gerais. Uma referência de uma página é melhor do que um documento de 40 páginas com a parte útil enterrada dentro.
- Confirme o tamanho e a contagem de arquivos em relação aos limites do seu plano. Verifique os limites atuais de conhecimento do Projeto nas configurações em vez de assumir um número fixo.
Verificação (20-22)
- Execute uma conversa de teste realista. Pergunte algo que o Projeto claramente deve ser capaz de lidar bem e verifique se a resposta reflete suas instruções e arquivos.
- Execute uma conversa de teste de caso extremo. Pergunte algo próximo à fronteira do escopo declarado do Projeto, pois os casos extremos são onde a configuração vaga falha primeiro.
- Anote qualquer coisa que não funcionou e corrija a linha específica. Rastreie uma resposta errada de volta à instrução ou arquivo que deveria tê-la capturado, em vez de adicionar orientação geral por cima.
Aplicando o Checklist em Ordem
Trabalhe no Escopo (1-6) antes de escrever uma única instrução. Um Projeto com escopo incerto produz instruções que hesitam e arquivos que se aplicam apenas parcialmente, não importa quão cuidadosamente você os escreva depois.
Instruções Personalizadas (7-13) e Arquivos de Conhecimento (14-19) podem ser feitos em qualquer ordem, mas as instruções geralmente são mais rápidas de acertar primeiro, pois não exigem a coleta de material de origem.
Verificação (20-22) não é um polimento opcional - é a etapa que realmente diz se a configuração funcionou, e é muito mais barato detectar uma lacuna agora do que depois de uma semana confiando em respostas inconsistentes.
FAQs
Preciso completar todos os itens antes de usar um novo Projeto?
Os itens de escopo (1-6) valem a pena ser definidos primeiro, pois moldam tudo o que vem depois. Instruções e arquivos podem ser construídos incrementalmente à medida que necessidades reais aparecem, em vez de tudo de uma vez.
Qual é o item mais importante desta lista?
Nomear o propósito específico do Projeto (item 1). Quase todos os problemas posteriores, instruções hesitantes, arquivos irrelevantes, rastreiam um propósito pouco claro ou excessivamente amplo.
Como sei se duas tarefas pertencem a um Projeto ou a dois?
Verifique se o público e as regras são os mesmos para ambos (itens 2-3). Se divergirem, projetos separados geralmente produzem resultados mais consistentes do que um projeto mais amplo.
Devo enviar todos os arquivos relevantes que encontrar imediatamente?
Não. Comece com um ou dois arquivos que respondam a uma necessidade clara e recorrente (item 15) e adicione mais apenas quando lacunas reais aparecerem em conversas de teste.
E se minhas instruções personalizadas ainda parecerem muito longas depois de seguir este checklist?
Instruções longas não são automaticamente um problema, mas verifique se elas cobrem mais de um propósito (item 12). Instruções que hesitam em vários públicos geralmente são um problema de escopo, não de comprimento.
Por que o checklist enfatiza o teste no final?
Instruções e arquivos que leem bem no papel ainda podem falhar na prática. Testar (itens 20-22) é o que realmente confirma se a configuração funciona, e é muito mais barato detectar lacunas aqui do que depois de confiar no Projeto para trabalho real.
O que devo fazer se uma conversa de teste der uma resposta errada ou genérica?
Rastreie-a até a instrução ou arquivo específico que deveria tê-la evitado e corrija essa linha diretamente (item 22), em vez de adicionar uma instrução geral por cima que pode não abordar a causa raiz.
É aceitável pular completamente a seção de arquivos de conhecimento?
Sim. Alguns Projetos dependem apenas de tom e regras de comportamento, não de fatos específicos, e não precisam de nenhum arquivo enviado. Pule as seções 14-19 se nada no propósito do seu Projeto depender de material de referência.
Com que frequência devo executar este checklist novamente para um Projeto existente?
Não há uma programação fixa, mas vale a pena revisitar sempre que as instruções do Projeto começarem a precisar de exceções frequentes, ou sempre que seu uso real parecer ter se desviado de seu propósito original.
Posso usar este checklist para um Projeto que já criei?
Sim. Ele funciona como uma ferramenta de revisão para um Projeto existente tão bem quanto um guia de configuração para um novo - percorra-o e anote onde a configuração atual falha.
Qual é o risco de pular os itens de escopo e ir direto para as instruções?
Instruções escritas sem um escopo claro tendem a hesitar, tentando cobrir mais terreno do que um único propósito coerente deveria, o que produz respostas menos consistentes mais tarde.
Relacionados
- Configurando um Projeto com Instruções Personalizadas - um guia completo da seção de instruções deste checklist.
- Enviando Arquivos de Conhecimento para um Projeto - um guia completo da seção de arquivos deste checklist.
- O que Torna um Bom Projeto: Escopo e Contexto Compartilhado - o raciocínio por trás dos itens de escopo.
- Melhores Práticas de Projetos e Artefatos - hábitos contínuos depois que um Projeto está configurado e funcionando.
Versões de Stack: Escrito contra a linha de modelos Claude atual em ~junho de 2026 - Claude Fable 5, Claude Opus 4.8, Claude Sonnet 5 (o padrão) e Claude Haiku 4.5. Nomes de modelos, preços e recursos do produto mudam rapidamente - verifique os detalhes atuais em platform.claude.com/docs antes de confiar neles.