Deixe sua IA ler o dever de casa dos laboratórios de fronteira: como extrair as melhores práticas dos prompts de sistema

Deixe sua IA ler o dever de casa dos laboratórios de fronteira: como extrair as melhores práticas dos prompts de sistema comerciais

Você já se perguntou como a Anthropic, OpenAI, Google e xAI instruem seus modelos? Existe um repositório público que torna possível ler os prompts de sistema que orientam produtos com milhões de usuários — e um método de dois passes para transformar esse conhecimento em melhorias reais para seus próprios agentes.

O autor do blog 3K1O, Keith Larson, compartilhou seu método depois que alguém perguntou como ele organiza seus agentes e skills. A resposta honesta: ele não inventou nada — leu como as pessoas com telemetria real fazem e copiou. O que torna isso útil é o como, não o quê.

O repositório

github.com/elder-plinius/CL4R1T4S

É uma coleção de prompts de sistema — os arquivos de instrução que ficam por baixo dos produtos comerciais de IA. Anthropic, OpenAI, xAI, Google, Mistral, Moonshot, mais os agentes de código: Cursor, Windsurf, Devin, Cline, Replit, Bolt, v0, Factory’s Droid, Manus. Cerca de 3,7 MB de texto. Gratuito.

O motivo pelo qual isso importa mais do que a maioria do conteúdo sobre engenharia de prompts: esses arquivos são estruturais. Cada regra estranha e hiperespecífica neles é quase certamente cicatriz de uma falha real que alguém precisou corrigir. Quando o prompt de um fornecedor diz que uma ferramenta “pode salvar células markdown como ‘raw’, não tente mudar, está tudo bem”, essa frase existe porque modelos ficavam tentando corrigir e desperdiçavam turnos.

Você não pode comprar esse tipo de ciclo de feedback. Mas pode ler.

O jeito errado de usar

Abrir um arquivo, admirar, colar grandes blocos no seu próprio CLAUDE.md ou arquivo de instruções. Larson tentou uma versão disso no início — e é ruim por três motivos:

• A maioria não se aplica a você. Uma fração enorme de qualquer prompt de sistema comercial é superfície de produto — affordances de UI, boilerplate legal, política de recusa, schemas de ferramentas que você não tem. Nada disso transfere.
• Contradições se acumulam silenciosamente. Dois fornecedores resolvem o mesmo problema de forma diferente, ambas razoáveis. Cole as duas e você entregou ao modelo um cara ou coroa. Ele não vai avisar — só vai ser inconsistente de maneiras que você vai diagnosticar erroneamente por semanas.
• Tamanho não é o objetivo. Um prompt curto pode produzir comportamento excelente. Prompts longos só se justificam quando estão direcionando muitas ferramentas. Um arquivo construído corrigindo falhas que você realmente observou permanece enxuto; um construído imaginando falhas incha.

O método que funciona: dois passes

Primeiro passe — extrair. Aponte um agente para o prompt de um fornecedor com uma restrição rígida: relate apenas padrões que são implementáveis na camada de configuração do usuário. Arquivos de instrução, arquivos de skill, descrições de ferramentas, hooks, definições de subagentes. Se precisa de acesso de fornecedor, está fora do escopo.

Segundo passe — refutar. Esta é a parte que as pessoas pulam. Não entregue o primeiro passe a um segundo agente e pergunte “está certo?”. Um agente instruído a confirmar vai confirmar — é a maneira mais confiável de obter uma revisão inútil.

Em vez disso, instrua um agente novo, sem conhecimento da saída do primeiro, com uma hipótese para falsear: “a conclusão conveniente é que este arquivo não contém nada de novo. Trate isso como uma afirmação a ser refutada.” Depois diga exatamente onde as extrações falham de forma confiável — espaço negativo, fronteiras de turno, precedência entre regras conflitantes, semântica de falha definida, mecânicas enterradas em descrições de ferramentas em vez de prosa de política.

Nas execuções de Larson, passes adversariais de segundo estágio adicionam aproximadamente um terço a mais de conteúdo do que o primeiro passe encontrou. Mesmo arquivo fonte, mesmo modelo. A única variável é se o agente foi instruído a concordar ou a atacar.

Uma regra adicional que importa: conceda o resultado nulo explicitamente. Diga ao revisor que “nada encontrado” é uma resposta legítima e valiosa. Caso contrário, ele preenche — porque voltar de mãos vazias parece fracasso, e modelos são tão propensos a parecer ocupados quanto pessoas.

A auditoria que dói

Extrair é a metade divertida. A metade que realmente muda comportamento é auditar o que você já tem contra o que aprendeu. Larson verificou suas 26 skills com uma técnica que considera a de maior alavancagem em todo o corpus: a descrição de uma skill é um roteador, não documentação. Ela deve responder “quando isso deve ser acionado?” — nunca “o que é isso?”. E a parte que todo mundo esquece é a metade negativa: toda skill precisa de um quando NÃO me usar explícito, mais um ponteiro para a skill irmã que deve ser usada em vez dela.

O resultado da auditoria: 7 das 26 skills não tinham gatilho negativo algum. E cada uma das sete falhas estava nas skills que ele havia classificado como “principalmente ruído, não vale o diff”. As skills de uso diário já estavam limpas.

Além disso, várias das variantes esquecidas tinham descrições que abriam com linguagem quase idêntica — mesmo verbo, mesmo assunto, diferindo apenas em um qualificador enterrado no final da frase. Para ele, eram ferramentas obviamente diferentes. Para um roteador lendo descrições, eram a mesma ferramenta listada várias vezes.

A lição: as skills que você usa todo dia se auto-corrigem, porque você percebe quando disparam errado. As que você escreveu uma vez e esqueceu são onde está o problema. Audite aquelas com as quais você menos se preocupa.

Mantenha uma lista de rejeitados

Vale a pena documentar o que você escolheu não adotar e por quê. A lista de Larson inclui: sempre terminar o trabalho com um pull request (bom para workflow de repositório, errado para operações locais), uma-ferramenta-por-turno estrito (muito lento quando leituras paralelas são seguras) e a instrução de um agente para comentar cada linha de código gerado (ativamente prejudicial).

Uma lista de padrões rejeitados é tão valiosa quanto uma de adotados. Seis meses depois, ela impede você de re-litigar uma decisão que já tomou com cuidado e mantém a próxima passagem de extração honesta.

Como começar

1. Clone o repositório. Leia um arquivo do início ao fim — comece com um agente de código como Cursor ou Devin, já que são os mais próximos de como a maioria das pessoas usa IA.
2. Peça ao seu assistente para extrair, limitado a coisas que você pode implementar sozinho.
3. Abra uma sessão nova e peça para atacar a extração. Contexto diferente, brief adversário, permissão para não encontrar nada.
4. Audite sua configuração atual contra o que sobreviveu. Pergunte especificamente o que você fez de errado, não o que fez certo.
5. Mude uma coisa. Teste contra uso real. Depois a próxima.

As técnicas são sobre como escrever instruções para um modelo. Elas não se importam se o domínio é Kubernetes ou couve.