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.
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