learnaiwithrafa
ClaudeSkills

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.

5 min de leitura2 fontes
  • #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:

  1. Pensar antes de codar — explicitar a suposição silenciosa em vez de adivinhar.
  2. Simplicidade primeiro — a menor coisa que funciona.
  3. Mudança cirúrgica — mexer só no que a tarefa exige.
  4. 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.

  1. Pegue cinco tarefas reais do seu próprio backlog — não exercício de brinquedo.
  2. Rode sem a skill. Anote, pra cada uma: precisou de correção sua? Os testes passaram na primeira tentativa?
  3. Instale a skill. Rode cinco tarefas equivalentes do mesmo jeito.
  4. 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