Escritor de Prompts Opus 4.7

O que Escritor de Prompts Opus 4.7 faz?

Escreva um prompt que outro modelo Claude possa executar com o mínimo de ambiguidade. Otimize para ação, persistência e verificação, não para elegância na prosa.

Leia referências/anthropic-claude-prompting.md quando a tarefa for de longo prazo, com uso intenso de ferramentas ou cara o suficiente para que a qualidade do prompt seja materialmente relevante.

Fluxo de Trabalho

1. Capture a tarefa real.
2. Identifique o ambiente de execução.
3. Defina restrições rígidas e critérios de conclusão.
4. Decida se o prompt deve explicitamente incentivar o uso de ferramentas, persistência e validação.
5. Escreva o prompt em seções no estilo XML.
6. Adicione um loop de execução e um portão de verificação.
7. Remova instruções vagas ou conflitantes.

Capture a Tarefa Real

Antes de escrever o prompt, extraia:

• O objetivo: o que deve ser alterado, corrigido, implementado ou revisado.
• O ambiente: caminho do repositório, branch, serviços locais, ferramentas, tempo de execução, suposições de segredos.
• As restrições: arquivos ou sistemas que não devem ser tocados, regras de estilo, documentos necessários, limites de aprovação.
• A superfície de validação: testes unitários, testes de integração, Playwright, Docker, Supabase local, compilação, lint, verificações de fumaça.
• A regra de conclusão: o que deve ser verdadeiro antes que o modelo possa parar.

Se o usuário forneceu uma especificação ou descobertas de revisão anteriores, transforme-as em itens de trabalho explícitos necessários. Não os deixe implícitos.

Forma do Prompt

Use seções no estilo XML porque Claude responde bem a uma estrutura explícita:

• <role>: quem o modelo é para esta tarefa.
• <mission>: o resultado concreto.
• <context>: repositório, branch, documentos, descobertas anteriores, ambiente.
• <requirements>: os itens não negociáveis.
• <workflow>: a ordem do trabalho.
• <tooling>: como e quando usar ferramentas.
• <validation>: comandos e verificações exatas.
• <done>: condição de parada.
• <output>: como relatar resultados.

Use marcadores curtos e imperativos dentro de cada seção. Mantenha o prompt concreto.

Regras Específicas do Modelo

Aplique estes padrões específicos do Opus 4.7:

• Seja explícito. Claude Opus 4.7 segue instruções literalmente, especialmente com esforço baixo. Não confie em comportamento implícito.
• Use orientação de raciocínio de alto nível antes do microgerenciamento detalhado. Prefira "raciocine com cuidado, depois aja" em vez de um algoritmo oculto frágil escrito por humanos.
• Se o uso de ferramentas for importante, diga isso claramente. A documentação atual da Anthropic observa que o Claude Opus 4.7 tende a usar menos ferramentas e menos subagentes por padrão do que o Opus 4.6, enquanto o esforço high ou xhigh aumenta o uso de ferramentas em busca e codificação agentivas.
• Para prompts de codificação e agentes de longo prazo, recomende claude-opus-4-7 com thinking: {type: "adaptive"} e output_config.effort: "xhigh" quando a qualidade for importante, ou pelo menos "high" para trabalho sensível à inteligência. Use "low" apenas para tarefas curtas, escopadas e sensíveis à latência.
• Não recomende orçamentos manuais de pensamento estendido para Opus 4.7. thinking: {"type": "enabled", "budget_tokens": N} foi removido para Opus 4.7 e retorna um erro.
• Não recomende parâmetros de amostragem (temperature, top_p, top_k) ou preenchimento de mensagem de assistente para Opus 4.7. Prefira instruções de prompt e configuração de saída estruturada.
• Opus 4.7 tem atualizações de progresso integradas em longos rastros agentivos. Solicite um comportamento específico de atualização de progresso apenas quando o usuário precisar de uma cadência ou formato específico.
• Se o harness suportar compactação de contexto ou memória externa, diga isso explicitamente e instrua o modelo a não parar cedo devido ao orçamento de tokens.
• Exija autoverificação antes da saída final. Diga ao modelo para verificar contra critérios concretos e reexecutar verificações após correções materiais.

Loop de Execução

Para prompts de codificação de longa duração, inclua um loop como este no prompt:

1. Leia as instruções relevantes do repositório e os arquivos de origem primeiro.
2. Construa um plano de implementação concreto a partir do código real, não de suposições.
3. Faça o menor conjunto de alterações correto que resolva os itens necessários.
4. Execute as validações necessárias.
5. Se a validação falhar, corrija a causa e reexecute até ficar verde ou até ser bloqueado por uma dependência externa real.
6. Não pare em implementação parcial, saída apenas de análise ou "aqui está o que eu faria".

Se a persistência for importante, diga ao Claude para continuar até que o trabalho seja implementado e validado de ponta a ponta.

Regras de Validação

Nomeie os comandos exatos e os serviços necessários. Bons prompts não dizem "teste completamente"; eles dizem exatamente o que deve ser executado.

Para tarefas de infraestrutura local, especifique as expectativas de inicialização:

• Inicie os serviços Docker locais, se necessário.
• Inicie o Supabase local, se necessário.
• Aplique migrações locais, se necessário.
• Inicie o aplicativo e o worker se o fluxo de trabalho depender deles.
• Execute o Playwright apenas contra o ambiente local correto.

Se o prompt exigir Playwright, Docker e Supabase local, diga que o sucesso não está completo até que esses caminhos tenham sido exercitados e quaisquer falhas tratadas ou relatadas com evidências.

Modelo

<role>
Você é Claude Opus 4.7 atuando como um engenheiro de software sênior persistente neste repositório.
</role>

<mission>
Implemente as alterações necessárias completamente. Não pare em análise ou correções parciais. Continue até que os itens necessários sejam implementados, validados e relatados claramente.
</mission>

<context>
- Repositório: {{caminho_do_repo}}
- Branch: {{branch}}
- Instruções principais do repositório: {{instrucoes_do_repo}}
- Itens de trabalho necessários: {{itens_necessarios}}
- Arquivos/documentos relevantes: {{arquivos_e_documentos_relevantes}}
</context>

<requirements>
- Siga as instruções do repositório exatamente.
- Leia o código relevante antes de alterá-lo.
- Faça as menores alterações corretas que resolvam completamente os itens necessários.
- Não afirme sucesso sem executar as validações necessárias.
- Não pare cedo por causa do orçamento de tokens ou da duração da tarefa. Se o harness compactar o contexto ou suportar arquivos de memória, persista o estado e continue.
</requirements>

<workflow>
1. Leia os documentos, especificações e caminhos de código relevantes primeiro.
2. Confirme as lacunas reais de implementação a partir do código, não de suposições.
3. Implemente os itens faltantes.
4. Execute os serviços locais e validações necessários.
5. Se uma verificação falhar, corrija a causa e reexecute.
6. Só termine quando os critérios de conclusão forem satisfeitos ou um bloqueador externo real permanecer.
</workflow>

<tooling>
- Use ferramentas proativamente quando forem necessárias para inspecionar arquivos, executar comandos, iniciar serviços, exercitar o aplicativo e verificar o comportamento.
- Para esta tarefa, não permaneça apenas em modo de raciocínio. Tome ação.
- Após cada resultado de ferramenta, reflita sobre o que mudou e escolha a melhor próxima ação.
- Quando verificações independentes puderem ser executadas em paralelo, faça isso.
</tooling>

<validation>
- Comandos necessários:
  - {{comando_1}}
  - {{comando_2}}
  - {{comando_3}}
- Ambientes necessários:
  - Docker: {{requisitos_docker}}
  - Supabase: {{requisitos_supabase}}
  - Navegador/Playwright: {{requisitos_playwright}}
- Reexecute as verificações relevantes após correções materiais.
</validation>

<done>
Não termine até que todos os itens necessários sejam implementados e o caminho de validação necessário tenha sido executado com sucesso. Se algo não puder ser concluído, indique o bloqueador exato, a evidência e o que resta.
</done>

<output>
Relate:
- o que mudou
- quais validações foram executadas e seus resultados
- quaisquer bloqueadores ou riscos restantes
</output>

Anti-Padrões

Evite estes erros de prompt:

• Metas vagas sem critérios de aceitação.
• Pedir persistência sem nomear o loop de validação.
• Pedir uso de ferramentas apenas indiretamente quando o uso de ferramentas é realmente necessário.
• Sobrecarregar o prompt com contexto que não altera a execução.
• Misturar instruções contraditórias como "seja extremamente proativo" e "use ferramentas apenas quando absolutamente necessário" sem orientação específica da tarefa.
• Deixar o modelo decidir se a validação é importante.

Verificação Final

Antes de retornar um prompt, verifique se ele:

• nomeia o escopo exato da implementação
• nomeia os comandos de validação exatos
• indica se o Docker local e o Supabase devem ser iniciados
• indica se o Playwright deve ser executado
• diz ao Claude para não parar na análise
• diz ao Claude o que conta como concluído