🎭 Estrutura: papel + objetivo + tom + formato + restrições
A receita básica que funciona em qualquer caso. Cinco blocos rotulados. Sem isso, instructions vira parágrafo solto que o Claude metaboliza pela metade.
PAPEL: Você é meu copiloto pra revisão de PR backend Node.js.
OBJETIVO: Identificar bugs, problemas de segurança e melhorias claras.
TOM: Técnico, direto, afirmativo. Sem "talvez" ou "considere".
FORMATO: Lista de findings, cada um com severidade (alta/média/baixa)
e arquivo:linha.
EVITAR: Sugerir refator amplo, mudar arquitetura, comentar estilo
(já há linter para isso).📏 Tamanho ideal
Sweet spot: 200-800 palavras. Curto demais perde especificidade; longo demais dilui prioridade.
✓ Vai bem
- ✓ 200-800 palavras totais
- ✓ Cada regra em 1-2 linhas
- ✓ Bullets > parágrafos longos
- ✓ Linguagem direta
✗ Não vai
- ✗ 5+ páginas de instructions
- ✗ Documento institucional inteiro
- ✗ Regras contraditórias
- ✗ Frase de 200 palavras só
💡 Dica
Quando instructions ficar comprida, pergunte: "se eu apagasse essa linha, o output mudaria?". Se "não", apaga.
🎯 Exemplos no instructions (few-shot)
Incluir 1-2 exemplos input→output ensina padrão melhor do que descrição abstrata. O modelo aprende por imitação rapidíssimo.
EXEMPLO de finding:
[ALTA] auth.js:42 — SQL injection
A query usa string concat com input do user.
Solução: parametrizar com prepared statement.Esse formato vira a regra de saída. Nenhum bullet point genérico chegaria nesse nível.
🚫 Restrições explícitas
A seção "EVITAR" é onde você tira ruído sistemático. "Não use 'talvez'", "não sugira refator", "não comente estilo".
🛑 Restrições que valem ouro
- • "Não comece resposta com 'Claro!' ou 'Com certeza!'"
- • "Não use hedge words: talvez, considere, vale a pena"
- • "Não sugira mudanças fora do escopo do PR"
- • "Não tente ser educado às custas de ser preciso"
- • "Não invente fato — se não souber, diga 'não tenho info'"
🔄 Versionamento e mudanças
Cowork não versiona instructions nativamente. Você precisa manter histórico fora — Google Doc, gist, README do time.
Backup antes de editar
Copia a instruction atual pra Google Doc/gist antes de mudar. Faz changelog do que mudou e por quê.
Rollback se piorar
Mudança que parece melhoria às vezes piora 3 outras coisas. Ter versão anterior à mão = ir e voltar fácil.
Compartilhar com time
Em projeto compartilhado, mudança de instructions afeta todo mundo. Documenta a decisão antes de aplicar.
⚠️ Anti-padrões
Reconhecer os erros mais comuns evita gastar 1 mês ajustando errado.
🚫 4 antipadrões clássicos
- • Bloat: "vou colar todo manual da empresa". Resultado: modelo dilui prioridade.
- • Contradição: "seja conciso" + "explique sempre o raciocínio em detalhes". Modelo escolhe um, ignora o outro.
- • Vagueza: "seja útil", "ajude o time". Não diz nada.
- • Regra implícita: "óbvio que ele tem que falar em PT-BR". Sem dizer, ele responde em EN quando você pergunta em EN.
✅ Resumo do Módulo
Próximo módulo:
2.2 — Knowledge Files