leandrocfe-skills

Skills Para Engenheiros De Verdade

Skills de agente que o Matt Pocock usa todo dia para fazer engenharia de verdade — não vibe coding.

Desenvolver aplicações reais é difícil. Abordagens como GSD, BMAD e Spec-Kit tentam ajudar tomando conta do processo. Mas ao fazer isso, tiram seu controle e dificultam resolver bugs no próprio processo.

Estas skills são pequenas, fáceis de adaptar e componíveis. Funcionam com qualquer modelo. São baseadas em décadas de experiência de engenharia. Hackeie. Torne suas. Aproveite.

Quickstart (setup de 30 segundos)

1. Rode o installer do skills.sh:

npx skills@latest add leandrocfe/skills

2. Escolha as skills que quer, e em quais coding agents instalar. Garanta que selecionou /setup-leandrocfe-skills.

3. Rode /setup-leandrocfe-skills no seu agente. Ele vai:

   • Perguntar qual issue tracker você quer usar (GitHub, Linear ou arquivos locais)
   • Perguntar quais labels você aplica em tickets quando triagem (/triage usa labels)
   • Perguntar onde você quer salvar os docs que criamos

4. Pronto — você está apto.

Por Que Estas Skills Existem

O Matt Pocock construiu estas skills como forma de corrigir failure modes comuns que ele vê com Claude Code, Codex e outros coding agents.

#1: O Agente Não Fez O Que Eu Quero

"Ninguém sabe exatamente o que quer"

David Thomas & Andrew Hunt, The Pragmatic Programmer

O Problema. O failure mode mais comum no desenvolvimento de software é desalinhamento. Você acha que o dev sabe o que você quer. Aí você vê o que ele construiu — e percebe que ele não te entendeu nada.

É o mesmo na era da IA. Existe um gap de comunicação entre você e o agente. A correção para isso é uma sessão de sabatina — fazer o agente te perguntar coisas detalhadas sobre o que você está construindo.

A Correção é usar:

• /grill-me — para usos não-código
• /grill-with-docs — igual ao /grill-me, mas com extras (veja abaixo)

São algumas das skills mais populares do Matt Pocock. Te ajudam a alinhar com o agente antes de começar, e a pensar fundo sobre a mudança que você está fazendo. Use-as toda vez que quiser fazer uma mudança.

#2: O Agente É Verboso Demais

Com uma ubiquitous language, as conversas entre devs e as expressões no código derivam do mesmo domain model.

Eric Evans, Domain-Driven-Design

O Problema: No começo de um projeto, devs e as pessoas para quem estão construindo o software (os domain experts) geralmente falam línguas diferentes.

Matt Pocock sentiu a mesma tensão com seus agentes. Agentes geralmente são jogados num projeto e devem se virar com o jargão. Aí usam 20 palavras quando 1 bastava.

A Correção é uma linguagem compartilhada. É um documento que ajuda agentes a decodificar o jargão usado no projeto.

Isso está embutido em /grill-with-docs. É uma sessão de sabatina, mas que te ajuda a construir uma linguagem compartilhada com a IA e a documentar decisões difíceis de explicar em ADRs.

É difícil explicar o quanto isso é poderoso. Pode ser a única técnica mais legal deste repo. Experimente e veja.

[!TIP] Uma linguagem compartilhada tem muitos outros benefícios além de reduzir verbosidade:

• Variáveis, funções e arquivos são nomeados de forma consistente, usando a linguagem compartilhada
• Como consequência, a codebase fica mais fácil de navegar pelo agente
• O agente também gasta menos tokens pensando, porque tem acesso a uma linguagem mais concisa

#3: O Código Não Funciona

"Sempre dê passos pequenos e deliberados. A taxa de feedback é o seu speed limit. Nunca pegue uma task grande demais."

David Thomas & Andrew Hunt, The Pragmatic Programmer

O Problema: Digamos que você e o agente estão alinhados sobre o que construir. O que acontece quando o agente ainda assim produz porcaria?