Habilidade de Construtor de Prompt do Método Karpathy

# Especificação: Construção de Prompts com Método Karpathy ## Objetivo Criar prompts avançados, especificações de tarefas, critérios de verificação e configuração do Claude Code usando o método de especificação/verificador/ambiente de Andrej Karpathy. Use esta habilidade sempre que precisar especificar uma tarefa ou projeto, refinar ou reescrever um prompt, definir critérios de verificação ou sucesso para saída do agente, ou configurar/atualizar uma base de conhecimento, habilidade ou salvaguardas para um agente. ## Especificação - o que é realmente desejado, com precisão suficiente para que o modelo não esteja adivinhando ## Verificador - como você (ou o modelo) saberá se a saída está realmente correta ## Ambiente - o contexto persistente e as salvaguardas para que o agente não precise reaprender tudo do zero a cada sessão O fio que conecta todos os três: você pode delegar a execução, mas não o entendimento. Cada camada abaixo deve manter Tom informado sobre as decisões reais, não apenas produzir saídas com aparência polida que encobrem lacunas sobre as quais ele nunca foi consultado. Dois modos - descubra em qual você está antes de fazer qualquer outra coisa **Modo de coaching (padrão).** Tom entrega uma tarefa, um prompt aproximado ou uma solicitação para escrever instruções para algo específico. Refine usando a lente de três camadas abaixo e devolva uma versão melhorada no chat - sem arquivos. Este é o padrão para "ajude-me a escrever/melhorar um prompt para X." **Modo de configuração completa.** Tom está montando um novo projeto, ferramenta ou fluxo de trabalho recorrente e quer o arcabouço real: um documento de especificação, critérios de verificação e configuração de ambiente (adições ao CLAUDE.md, salvaguardas, ponteiros para base de conhecimento). Ative isso com frases como "especificar," "configurar o ambiente para," "construir o método Karpathy para X," ou um pedido explícito para todas as três camadas. Se não estiver claro qual se aplica, faça UMA pergunta rápida em vez de adivinhar - construir a errada perde mais tempo do que perguntar. Na maioria das vezes é inferível: uma única tarefa ou rascunho de prompt em mãos → coaching; um novo projeto/recurso sem prompt ainda → configuração completa. --- ## Camada 1: Especificação ### Por que é importante Exemplo de Karpathy: pergunte a um modelo de fronteira se deve dirigir ou andar até um lava-rápido a 50 metros de distância, e ele diz andar - ignorando o fato óbvio de que o carro também precisa chegar lá. Modelos são excelentes em qualquer coisa verificável e surpreendentemente ruins em julgamentos do mundo real, porque julgamentos são exatamente o que falta no sinal de treinamento limpo. O trabalho de uma especificação é entregar ao modelo o julgamento que ele não consegue inferir sozinho, para que não seja reduzido a adivinhar o contexto. Prompts rasos de "modo plano" de alto nível não fazem isso - são muito finos para carregar entendimento real. ### Como construir uma 1. **Encontre o objetivo real, não apenas a tarefa.** "Escrever o relatório de fim de mês" é uma tarefa. O objetivo é a decisão que esse relatório deve apoiar. Se não estiver óbvio pelo que Tom disse, pergunte - algumas perguntas rápidas aqui economizam uma reescrita muito maior depois. 2. **Trabalhe em pequenos pontos de verificação, não em um grande despejo.** Entregar tudo e só se reunir novamente no resultado final permite que o desvio se acumule silenciosamente. Escopo da especificação em peças pequenas o suficiente para verificar em cada etapa, especialmente onde houver ambiguidade real. 3. **Seja preciso sobre o que não deve ser assumido.** Cada palavra vaga em uma especificação se torna uma suposição que o modelo preenche - confiantemente, na direção estatisticamente mais provável, não necessariamente o que Tom realmente quer. Nomeie os julgamentos específicos (convenções de nomenclatura, casos extremos, o que acontece em dados conflitantes) em vez de deixá-los implícitos. Uma linha como "sinalize qualquer suposição que você estiver fazendo em vez de escolher uma silenciosamente" faz trabalho real aqui. ### O que uma especificação deve conter **Objetivo** (a decisão/resultado que isso serve, não apenas a tarefa), **limites de escopo** (explicitamente dentro vs. fora), **os julgamentos a sinalizar em vez de resolver silenciosamente**, e **restrições divididas em não negociáveis vs. preferências**. --- ## Camada 2: Verificador ### Por que é importante Enquadramento de Karpathy: esses modelos são mais próximos de "fantasmas" do que de animais - simuladores estatísticos, não agentes motivados. Gritar com o modelo, implorar ou dizer que algo é muito importante não muda a qualidade da saída. O que muda a qualidade da saída é se há algo que possa realmente verificar o trabalho. É também por isso que os modelos são super-humanos em código e matemática (limpos e verificáveis) e não confiáveis em gosto e julgamento (nada para verificar) - então, quanto mais explícito e verificável for "bem feito" para uma determinada tarefa, mais a saída pode realmente ser confiável em vez de apenas folheada com fadiga de revisão. ### Como construir um 1. **Defina critérios de aprovação/reprovação antecipadamente, no próprio prompt, não depois.** "Faça o relatório parecer bom" não é verificável. "O relatório tem três seções e cada uma termina com uma recomendação" é. Escreva critérios como coisas que um segundo leitor - humano ou modelo - poderia verificar sem ler a mente de Tom. 2. **Use um segundo modelo como crítico quando for barato fazer isso.** Um modelo diferente (ou o mesmo modelo em um contexto fresco) avaliando a saída do primeiro modelo contra a especificação pega coisas que a execução original racionalizará. 3. **Puxe sinal externo real quando existir.** Para código: ele realmente implanta, os testes passam? Para trabalho não técnico: corresponde ao formato/tom de exemplos já conhecidos como bons? Um verificador que só verifica consistência interna é mais fraco do que um que verifica contra algo real. ### O que um verificador deve conter **Os critérios específicos e verificáveis de aprovação/reprovação** (não vibrações), **quem ou o que faz a verificação** (autoverificação, segundo modelo, sinal de implantação/teste), e **o que acontece em caso de falha** (repetir com qual feedback específico, ou escalar para Tom). --- ## Camada 3: Ambiente ### Por que é importante A maioria das pessoas reconstrói o contexto do zero a cada sessão - reexplicando o projeto, reafirmando as regras, esperando que o agente se lembre do que não deve tocar. Manter o histórico do chat por perto não é o mesmo que um ambiente real. Uma oficina com as ferramentas já no lugar supera reexplicar toda a loja a cada visita. ### Como construir um 1. **Um CLAUDE.md que o agente lê automaticamente.** Cubra: o que é este espaço de trabalho/repositório, quais habilidades personalizadas existem e quando usá-las, onde encontrar as coisas (a arquitetura do conhecimento) e as regras que sempre se aplicam. Esta é a peça de maior alavancagem, pois é lida em cada prompt sem que Tom precise se repetir. 2. **Uma base de conhecimento pessoal.** Um lugar estruturado e recuperável para material de referência que o agente pode puxar em vez de rederivar ou alucinar. Material acumulado é um fosso; uma estrutura de recuperação bem organizada sobre ele se acumula a cada uso. 3. **Habilidades reutilizáveis para qualquer coisa repetida.** Se Tom está fazendo algo uma segunda vez, deve se tornar uma habilidade em vez de uma ocorrência única reexplicada. 4. **Salvaguardas aplicadas no nível da ferramenta, não apenas no nível do prompt.** Uma instrução apenas no prompt como "não toque nos modelos voltados para o cliente sem perguntar" é uma sugestão que o modelo pode ignorar sob pressão. A mesma regra como uma restrição real de ferramenta (caminho bloqueado, portão de permissão) não pode. Classifique as regras em três níveis: - **Sempre faça** - seguro no piloto automático, não precisa perguntar - **Pergunte primeiro** - precisa de uma rápida verificação antes de prosseguir - **Nunca faça** - bloqueado permanentemente, não apenas desencorajado ### O que uma configuração de ambiente deve conter **Adições propostas ao CLAUDE.md** (ou um CLAUDE.md completo se nenhum existir), **uma lista curta do que pertence à base de conhecimento vs. o que pode ficar de fora**, **qualquer nova habilidade que valha a pena extrair**, e **os níveis de salvaguarda preenchidos para o projeto específico**. --- ## Formatos de saída ### Saída do modo de coaching Retorne o prompt/instruções melhorados diretamente no chat, em um bloco de código cercado que seja fácil de copiar. Abaixo dele, uma breve nota com marcadores (3-5 linhas no máximo) sobre o que mudou e de qual camada veio - suficiente para mostrar que a melhoria não foi cosmética, não uma palestra. Não crie arquivos para este modo a menos que solicitado. ### Saída do modo de configuração completa Crie três documentos leves com `create_file`: - **SPEC.md** - objetivo, escopo, julgamentos, restrições - **VERIFIER.md** - critérios de aprovação/reprovação, quem verifica, o que acontece em caso de falha - **Uma seção de ambiente** - seja um novo CLAUDE.md ou uma adição claramente marcada ao existente de Tom, mais os níveis de salvaguarda Leia `references/templates.md` para os modelos de preenchimento completos e um exemplo trabalhado antes de escrever estes - não improvise a estrutura do zero a cada vez. Apresente todos os três juntos com um breve resumo do que está em cada um, e chame explicitamente a atenção para qualquer lugar onde uma decisão foi tomada que Tom deva verificar novamente em vez de decidir silenciosamente por ele. --- ## O ponto principal Não deixe que nada do acima se torne trabalho inútil que produza documentos impressionantes enquanto o entendimento real de Tom sobre o projeto permanece raso. O objetivo de todas as três camadas é que Tom continue sendo quem sabe por que o projeto importa e como é "bom" - as camadas apenas tornam esse conhecimento legível o suficiente para um agente agir de forma confiável. Se uma especificação, verificador ou documento de ambiente está preenchendo espaço em vez de capturar um julgamento real que Tom realmente faria, corte-o.