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.

Se quiser acompanhar as mudanças destas skills e qualquer uma nova que ele criar, pode se juntar a ~60.000 outros devs na newsletter dele:

Inscreva-se na Newsletter

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, GitLab, Linear ou arquivos locais)
   • Perguntar quais labels você aplica em tickets quando faz triage (/triage usa labels)
   • Perguntar se PRs externos devem ser uma superfície de request para /triage
   • 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 constrói o domain model, atualiza CONTEXT.md e ADRs

São algumas das skills mais populares. 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 sentiu a mesma tensão com seus agents. 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.

Exemplo

Aqui um exemplo de CONTEXT.md, do repo course-video-manager do Matt. Qual é mais fácil de ler?

• ANTES: "Tem um problema quando uma lesson dentro de uma section de um course é tornada 'real' (i.e. ganha um lugar no file system)"
• DEPOIS: "Tem um problema com o materialization cascade"

Essa concisão paga dividendo sessão após sessão.

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

É difícil explicar o quanto isso é poderoso. Pode ser uma das técnicas mais legais 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