Skills minimalistas: as 5 de Matt Pocock para o Claude Code

Boa parte das coleções de skills mais conhecidas pro Claude Code, tipo Superpowers, Agent OS e GSD, funciona como um sistema fechado. Fase 1, fase 2, fase 3, tudo em sequência obrigatória. Isso trava o usuário, não dá pra rodar só uma parte isolada, e se algo falha numa fase intermediária é preciso refazer tudo de novo. O problema mais profundo, nem é a travação em si, é que esse tipo de processo engessado reduz a autonomia do modelo.

Boris Cherny, criador do Claude Code, comentou numa entrevista que mais de 80% das instruções internas do Claude Code foram removidas com o tempo, porque a maioria existia só pra corrigir erros que os modelos antigos cometiam. Com os modelos de fronteira esse problema diminuiu bastante, eles já acertam mais sozinhos, então dar mais autonomia tende a gerar resultado melhor do que um processo excessivamente engessado.

É por isso que as skills minimalistas de Matt Pocock chamam atenção. Cada uma faz uma coisa só, com pouquíssima instrução, dando direção sem sufocar a criatividade do modelo na forma de resolver o problema. São 5 skills, usadas em sequência num fluxo de trabalho, mas cada uma funciona isolada se precisar.

1. A skill de entrevista

A primeira skill faz perguntas detalhadas sobre a ideia do projeto até preencher as lacunas de contexto que o próprio usuário não tinha pensado. Em um sistema de agendamento, por exemplo, ela pergunta coisas como: o cliente pode cancelar sozinho ou precisa ligar? Duas pessoas podem ser atendidas no mesmo horário? Tem multa por cancelamento de última hora?

Ela funciona em rodadas, por etapas do projeto, primeiro tudo sobre login, depois tudo sobre agendamento, depois checkout, sem misturar perguntas de áreas diferentes. Considero essa skill mais importante do que escrever um bom prompt, porque ela identifica lacunas que nem o usuário sabia que existiam.

A limitação é que o resultado da entrevista fica só na memória de curto prazo da conversa, se perde se a sessão terminar. É pra resolver isso que existe a próxima skill.

2. A skill de especificação

Essa skill pega a conversa da entrevista e transforma num documento de decisões, não um documento técnico com código, só decisões. Esse ponto é importante, se o documento incluísse código, o modelo tenderia a só copiar aquele trecho depois em vez de analisar o projeto real na hora de construir.

O documento também registra o que foi explicitamente recusado ou descartado, pra evitar que a mesma sugestão rejeitada volte à tona mais pra frente.

3. A skill de divisão em tarefas

Com o documento de decisões em mãos, essa skill quebra o trabalho em tarefas organizadas por funcionalidade, tudo de login primeiro, depois tudo de agendamento, depois checkout, em vez de dividir por camada técnica, tipo todos os bancos de dados primeiro e depois todas as telas.

A vantagem de dividir por funcionalidade é que cada tarefa fechada já é testável de ponta a ponta. Dividir por camada técnica atrasa muito a possibilidade de testar algo funcionando de fato. Um exemplo real, um projeto dividido por camada teve 26 tarefas, cerca de 20 rodadas do agente por tarefa, e cerca de três quartos disso foi retrabalho.

4. A skill de implementação com critério

Antes de escrever código, essa skill define o critério de sucesso, os testes, e só depois constrói o código pra atender esse critério. Isso inverte a ordem mais comum, que seria construir primeiro e documentar o critério depois, o que tende a criar testes viciados, que só confirmam o que já foi feito em vez de validar de verdade.

É uma aplicação de TDD, desenvolvimento orientado a testes, mas com instrução mínima, confiando na capacidade do modelo de aplicar isso bem sozinho.

5. A skill de revisão externa

A última skill roda numa sessão nova, separada da sessão que construiu o código, justamente pra evitar o viés de quem construiu revisar o próprio trabalho. Ela verifica duas coisas separadas: se o código está bem construído tecnicamente, e se o que foi construído realmente corresponde ao que foi combinado no documento de decisões da skill 2.

Essa skill é inspirada em conceitos do livro Refactoring, de Martin Fowler, de 1999, um clássico da engenharia de software. Um exemplo prático do tipo de problema que ela resolve é o shotgun surgery, cirurgia de espingarda, quando uma mudança simples, mudar a cor de um botão, por exemplo, deveria ser replicada em vários arquivos diferentes, mas algum lugar acaba esquecido, gerando inconsistência que pode causar bug ou conflito depois.

Clareza vale mais do que capacidade técnica

Por muito tempo, o que limitava um projeto feito com IA era a capacidade do próprio modelo. Daí a necessidade de prompts cada vez mais elaborados e processos pra compensar os erros que ele cometia. Hoje, com os modelos de fronteira, o modelo já entrega bem sozinho, então o que mais faz diferença passa a ser a clareza de quem está construindo: ter bem definido o que se quer, ter isso registrado, dividido em partes testáveis e revisado de forma imparcial.

Um dado curioso reforça essa ideia, a skill de entrevista, a primeira dessa lista, é a mais baixada de toda a coleção de Matt Pocock, com mais de 500 mil instalações, mesmo sem escrever nenhuma linha de código, só fazendo perguntas. Isso diz bastante sobre o que realmente move o resultado final, clareza sobre o que construir pesa mais do que a capacidade técnica do modelo.