Fui checar o tal "65% para 94%" do Claude
Está circulando um arquivo de skill inspirado no Andrej Karpathy com uma promessa de precisão grande colada nele. Fui no repositório. Não existe benchmark nenhum. Mas a ideia por baixo é a coisa mais útil que eu mudei em como eu escrevo prompt.
- #claude-code
- #skills
- #evals
Tem um print rodando por aí: instale esse arquivo de skill e o Claude Code sai de 65% pra 94% de precisão. É um número bonito. Tem cara de evidência. Então eu abri o repositório que o print aponta.
Não tem benchmark lá. Nenhum eval, nenhum conjunto de teste, nenhuma metodologia, nenhuma porcentagem. O repositório é um conjunto de diretrizes de código tirado das observações públicas do Andrej Karpathy sobre como modelos de linguagem erram programando — coisa boa, mas declaradamente não medida. O número foi colado em algum ponto entre o repositório e o seu feed.
Eu gasto um parágrafo nisso porque o reflexo importa mais que o arquivo. Qualquer promessa de precisão sobre um agente que não diz em qual conjunto de tarefas foi medida é opinião com roupa de dado — e o nosso mercado está afogado nisso agora. Clique no link antes de instalar.
O que tem lá de verdade — e é bom
Tirando o número, sobram quatro princípios, e eles valem seu tempo:
- Pensar antes de codar — explicitar a suposição silenciosa em vez de adivinhar.
- Simplicidade primeiro — a menor coisa que funciona.
- Mudança cirúrgica — mexer só no que a tarefa exige.
- Execução guiada por objetivo — definir critérios de sucesso verificáveis.
O quarto é a parede que sustenta a casa, e o próprio repositório explica por quê: modelos de linguagem são excepcionalmente bons em ficar em loop até bater um objetivo específico. Dê o critério e ele vai moer até chegar lá.
Isso encaixa com uma coisa que eu vejo direto como EM. Quase todo resultado ruim do Claude não é falha de capacidade — é falha de especificação. Eu disse o que fazer em vez de dizer como é "pronto", e depois me surpreendi que ele parou num lugar que eu não queria.
Instrução x critério de sucesso
A reescrita que mudou mais coisa pra mim:
# instrução — o Claude decide quando acabou
Refatore o módulo de auth pra usar a nova API de sessão.
# critério de sucesso — a linha de chegada não é interpretação dele
Refatore o módulo de auth pra nova API de sessão.
Pronto significa: todo call site compila, `pnpm test auth` sai com 0,
e nenhum arquivo fora de src/auth/ foi modificado.
Mesma tarefa. A segunda dá ao Claude uma régua pra ele mesmo conferir, então ele continua em vez de te entregar uma migração pela metade que "parece certa". E te dá um jeito rápido de saber quando ele está blefando.
Se você for transformar isso numa skill, saiba o que uma skill custa
A documentação é clara sobre quando a skill é o container certo: crie uma quando você fica colando a mesma lista de checagem no chat, ou quando uma seção do seu CLAUDE.md deixou de ser um fato e virou um procedimento. E a economia é o ponto — o corpo de uma skill só carrega quando ela é usada, então material de referência longo custa quase nada até você precisar. É o oposto do CLAUDE.md, que carrega inteiro, em toda sessão.
O formato é mínimo — .claude/skills/<nome>/SKILL.md, com dois campos no frontmatter:
---
name: goal-check
description: Turn a vague task into verifiable success criteria before writing code
---
Antes de editar qualquer coisa, reescreva a tarefa como:
- Um estado final mensurável (resultado de teste, exit code, contagem de arquivos)
- O comando que prova isso
- O que NÃO pode mudar no caminho
Depois confirme os critérios comigo antes de começar.
O description não é enfeite — é por ele que o Claude decide se carrega a skill ou não. Escreva como condição de gatilho, não como resumo. E repare: em skill pessoal ou de projeto, o comando vem do nome da pasta (/goal-check), não do campo name.
Teste em você mesmo em vez de confiar no print
A versão honesta do que aquele post viral deveria ter dito é: experimente e meça. Você não precisa de um laboratório, precisa de disciplina.
- Pegue cinco tarefas reais do seu próprio backlog — não exercício de brinquedo.
- Rode sem a
skill. Anote, pra cada uma: precisou de correção sua? Os testes passaram na primeira tentativa? - Instale a
skill. Rode cinco tarefas equivalentes do mesmo jeito. - Compare a quantidade de correções.
Isso te dá um número sobre o seu repositório, que é o único número que deveria mudar o seu setup. O meu foi pra direção certa — o suficiente pra eu manter o hábito dos critérios e descartar o resto do arquivo. No seu caso pode ser diferente, e é exatamente esse o ponto.
Faça isso hoje
Pegue o último prompt que você deu pro Claude Code e que voltou quase certo. Reescreva com uma linha "Pronto significa:" contendo um comando e um exit code. Rode de novo. Essa comparação vai te ensinar mais do que qualquer porcentagem que você não mediu.
Fontes
Continue lendo
Mais guias parecidos com este.
Claude Skills: pare de reensinar a mesma tarefa
Se você fica colando as mesmas instruções no Claude toda semana, está fazendo na mão um trabalho que uma Skill deveria fazer por você. Vou te mostrar quando vale escrever uma Skill e quando é exagero.
Os comandos do Claude Code que você pula são todos o mesmo
São mais de 60 comandos embutidos. Quase todo mundo usa quatro. Organize os que faltam pelo que eles realmente fazem e aparece um padrão — quase todos existem pra administrar um único recurso, e é justamente ele que estraga suas sessões longas.
Suas regras expiram na compactação. Veja exatamente quais.
Quando uma sessão longa compacta, parte das suas instruções volta do disco e parte simplesmente não volta. A separação está documentada e quase ninguém conhece — é por isso que o Claude "esquece suas regras" depois de três horas.