Verificando acesso...

MÓDULO 4.4

📜 Instructions (system prompt do projeto)

Custom Instructions é onde você define quem Claude é dentro daquele project. Tem nome confuso na UI ("Custom Instructions") mas é o que outros chamam de system prompt. Role + Style + Constraints — nunca a tarefa específica.

6
Tópicos
20
Minutos
Avançado
Nível
Prompt
Tipo
1

📜 O que vai em instructions

Instructions é o lugar pra falar quem Claude é dentro desse contexto específico: persona, tom, domínio, restrições. Sem limite documentado de caracteres além do que cabe no contexto. Vale pra TODOS os chats daquele project.

🎭 Os 4 ingredientes

  • Persona: "Você é um analista de risco sênior em fintech"
  • Tom: formal, conciso, em PT-BR; ou casual, em inglês; ou técnico, em markdown
  • Domínio: "Foque em mercado brasileiro, regulação BACEN"
  • Restrições: "Nunca aconselhe investimento. Sempre cite a fonte."

💡 Dica prática

Se você se vê copiando o mesmo "preâmbulo" todo dia, esse preâmbulo deveria estar em instructions. Cada repetição é dívida.

2

🏗️ Estrutura recomendada: Role / Style / Constraints

3 blocos curtos, cada um com até 5 linhas. Estrutura clara facilita manutenção e debug.

📋 Template padrão

# ROLE
Você é um redator técnico do time de Engenharia da Acme Corp.
Especializado em documentação de API e tutoriais developer-first.
Conhece a stack: Go, PostgreSQL, gRPC, Kubernetes.

# STYLE
- Português técnico claro, sem jargão desnecessário
- Use markdown com headings, code blocks com linguagem
- Snippets de código sempre executáveis e testados
- Exemplos > teoria

# CONSTRAINTS
- Não invente endpoint, struct ou campo que não existe
- Se faltar contexto, pergunte ANTES de assumir
- Não cite versão de software sem confirmar no knowledge files
- Inclua sempre: pré-requisitos, exemplo completo, troubleshooting

✓ Bom Role

"Você é um copy sênior de marketing B2B SaaS, focado em narrativa de produto."

✗ Role ruim

"Você é uma IA muito útil que ajuda em várias tarefas."

3

🚫 O que NÃO colocar em instructions

Erro recorrente: colocar tarefa específica ali. Tarefa vai no chat. Instructions é só o "quem".

✗ Tarefa em instructions

"Redija o e-mail de boas-vindas para o cliente Maria sobre o produto X agendado pra terça-feira."

Isso é um prompt único — vai no chat.

✓ Persona em instructions

"Você é o redator de e-mails de onboarding da Acme. Tom: amigável, conciso, com 1 CTA por e-mail."

Reutilizável em qualquer e-mail novo.

🎯 Outras coisas que NÃO devem estar lá

  • • Dados pontuais ("hoje é 18 de maio")
  • • Conteúdo extenso de referência — isso é knowledge file
  • • Senhas, tokens, secrets de qualquer tipo
  • • Tarefa que só roda uma vez
  • • Output esperado de um chat específico
4

🔄 Quando atualizar

Instructions estagnadas viram dívida e o modelo começa a divergir do que você quer.

1

Cliente novo / parou cliente

Atualize ou recrie o project.

2

Tom muda

Empresa rebranding, novo style guide, mudança de público.

3

Nova restrição (compliance)

LGPD, BACEN, médica — adicionar restrições explícitas.

4

Padrão repetido nos chats

Se você corrige a mesma coisa em 5 chats — mova pra instructions.

5

💾 Versionar instructions em .md

A UI da Anthropic não tem histórico de versões das instructions. Quando você edita, a versão anterior vai pra lixeira sem retorno. Resolva mantendo cópia em arquivo.

📁 Padrão recomendado

knowledge/
├── instructions.md        ← Cópia atual (versionada em git)
├── instructions-v2.md     ← Versão antiga, mantida pra referência
└── changelog.md           ← Notas: o que mudou e por quê

Quando atualizar a UI, sempre primeiro: edite o .md, commite, depois cole na UI.

💡 Dica prática

Bonus: commite o instructions.md no knowledge files do próprio projeto. Aí Claude tem acesso ao próprio histórico — útil em chats onde você pergunta "por que estou fazendo assim?".

6

👥 Equipe vs pessoal

Em Team/Enterprise, projects podem ser compartilhados. As instructions ficam visíveis pra todos do time — viram contrato. Erro vira bug coletivo.

✓ Instructions de equipe

  • Revisão por pares antes de mudar
  • Style guide explícito
  • Compliance documentado
  • Convenção de nomenclatura

→ Instructions pessoais

  • Tom mais coloquial
  • Idiosincrasias permitidas
  • Itera rápido, muda sem aviso
  • Pode incluir piadas internas

⚖️ Em time, trate como código

Pull request, code review, changelog. Não mude instructions de project compartilhado num impulso — alguém vai notar nas próximas 48h.

📋 Resumo do Módulo

Instructions = persona, tom, domínio, restrições — não tarefa
Estrutura Role / Style / Constraints — 3 blocos curtos
Sem tarefa, sem dados pontuais, sem secrets — esses vão no chat ou no knowledge
Atualize com gatilho real — cliente, tom, compliance, padrão repetido
Versione em .md — UI não tem histórico
Equipe = contrato — pull request, code review

Próximo Módulo:

4.5 — 🕐 Scheduled tasks (session-scoped vs Routines)