Pular para o conteúdo
Ferramentas

Skills não adicionam capacidade. Elas tiram atalho.

Li as quatorze skills que uso no Claude Code procurando novos poderes. Quase todas fazem o contrário — proíbem o caminho curto que a gente pega quando está com pressa.

Afonso Henrique4 min de leitura

Abri as skills que tenho instaladas esperando encontrar capacidade nova. Coisas que o agente não sabia fazer e agora sabe.

Não é isso que elas são. Das quatorze do pacote que uso, quase nenhuma acrescenta poder. Elas proíbem atalho — e proíbem em tom de lei, não de sugestão.

Quatro leis, escritas em maiúsculas

A skill de desenvolvimento guiado por testes abre assim:

NENHUM CÓDIGO DE PRODUÇÃO SEM UM TESTE FALHANDO ANTES

E o princípio embaixo dela: "se você não viu o teste falhar, não sabe se ele testa a coisa certa". Escreveu código antes do teste? A instrução é apagar. Não guardar como referência, não adaptar, não olhar.

A de depuração:

NENHUMA CORREÇÃO SEM INVESTIGAR A CAUSA RAIZ PRIMEIRO

Com uma frase que vale emoldurar: "correção de sintoma é fracasso".

A de verificação:

NENHUMA AFIRMAÇÃO DE CONCLUSÃO SEM EVIDÊNCIA FRESCA

Se você não rodou o comando nesta mensagem, não pode dizer que passa. Ela traz uma tabela do que cada afirmação exige — "testes passam" exige a saída do comando com zero falhas, não a execução anterior nem "deveria passar".

E a de receber revisão de código proíbe, textualmente, responder "você tem toda razão". A justificativa é boa: revisão pede avaliação técnica, não performance emocional. Concordar rápido é uma forma de não ler.

Por que o tom é tão absolutista

Isso me incomodou na primeira leitura. Regra sem exceção costuma ser regra mal pensada.

Mas repare no que essas skills antecipam. A de testes diz: "pensando em pular só desta vez? Pare. Isso é racionalização." A de depuração lista quando você mais vai querer pular — sob pressão de tempo, quando a correção parece óbvia, quando o gerente quer agora.

Elas não estão descrevendo o processo. Estão nomeando a desculpa antes de você usá-la.

Faz sentido para um modelo de linguagem, que é ótimo em construir justificativa plausível para o caminho curto. E faz um sentido desconfortável para gente também, porque a lista de desculpas é exatamente a nossa.

O que isso tem de novo — e o que não tem

Nada ali é descoberta. Investigar antes de corrigir, ver o teste falhar, provar antes de declarar pronto: isso é engenharia de sempre, do tipo que se aprende apanhando e se abandona no primeiro prazo apertado.

O que mudou é que virou texto executável. A disciplina saiu da cabeça de quem tem experiência e virou arquivo versionado, revisável em pull request, aplicado igual às três da manhã e às três da tarde.

É o argumento da lista de checagem, que a medicina e a aviação resolveram décadas atrás: o problema nunca foi ninguém saber o passo. Foi o passo depender de alguém lembrar dele no pior momento possível.

A prova está na skill que eu mesmo escrevi

Tenho uma skill própria, para os meus projetos em produção. Fui reler o que escrevi nela.

Não tem nenhuma capacidade nova. Ela diz para ler o código análogo antes de escrever a primeira linha. Diz para não propor tecnologia nova nem abstração elaborada. Diz que, se a solução parece sofisticada demais para o problema, o sinal é de que está errada. Diz para não mexer direto no banco.

Escrevi uma lista de proibições sem perceber que era isso que estava fazendo. São as regras que eu já sigo — e que eu sabia que abandonaria sob pressão se não estivessem escritas em algum lugar que me interrompesse.

Onde eu discordo

A rigidez tem custo, e vale dizer qual.

Uma skill que diz "sempre" vai estar errada em algum caso. E um agente que segue a letra da regra faz a coisa errada com confiança — que é pior do que fazer errado com dúvida, porque ninguém revisa o que parece resolvido.

O julgamento de quando a regra não se aplica continua fora do arquivo. Ele não cabe em markdown. Isso não invalida as skills; delimita o que elas são. Elas não substituem experiência — elas impedem que a experiência seja desligada por cansaço ou prazo.

O que eu tirei disso

Se você usa agente e quer melhorar o resultado, o instinto é procurar prompt melhor ou modelo maior.

O ganho maior está no lugar mais chato: escrever as suas regras. Não as genéricas — as suas. O que nunca deve ser feito neste código. O que já deu errado antes e por quê. Onde a pressa costuma cobrar caro.

Vale para o agente. Acontece que também vale para você.

  • claude code
  • skills
  • disciplina
  • processo