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:
- Rode o installer do skills.sh:
npx skills@latest add leandrocfe/skills-
Escolha as skills que quer, e em quais coding agents instalar. Garanta que selecionou
/setup-leandrocfe-skills. -
Rode
/setup-leandrocfe-skillsno 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 (
/triageusa labels) - Perguntar onde você quer salvar os docs que criamos
-
Pronto — você está apto.
O Matt Pocock construiu estas skills como forma de corrigir failure modes comuns que ele vê com Claude Code, Codex e outros coding agents.
"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, atualizaCONTEXT.mde 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.
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
"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?
É hora de olhar seus feedback loops. Sem feedback de como o código que ele produz roda de verdade, o agente vai voar cego.
A Correção: Você precisa do trio usual de feedback loops: tipos estáticos, acesso ao browser e testes automatizados.
Para testes automatizados, um loop red-green-refactor é crítico. Aí o agente escreve um teste que falha primeiro, depois conserta o teste. Isso dá ao agente um nível consistente de feedback que resulta em código bem melhor.
O Matt criou uma skill /tdd que você pluga em qualquer projeto. Ela incentiva red-green-refactor e dá ao agente bastante orientação sobre o que é teste bom e ruim.
Para debug, Matt também criou uma skill /diagnosing-bugs que embrulha as melhores práticas de debugging num loop disciplinado, gated fase a fase.
"Invista no design do sistema todo dia."
Kent Beck, Extreme Programming Explained
"Os melhores módulos são deep. Permitem que muita funcionalidade seja acessada através de uma interface simples."
John Ousterhout, A Philosophy Of Software Design
O Problema: A maioria dos apps construídos com agentes é complexa e difícil de mudar. Como agentes podem acelerar radicalmente coding, eles também aceleram entropia de software. Codebases ficam mais complexas a uma taxa sem precedentes.
A Correção é uma abordagem radicalmente nova ao desenvolvimento powered-by-AI: importar com o design do código.
Isso está embutido em cada camada destas skills:
/to-specte sabatina sobre quais módulos você está tocando antes de criar uma spec/improve-codebase-architectureescaneia uma codebase em busca de oportunidades de deepening e te entrega os candidatos. Recomendo rodar na sua codebase a cada poucos dias. É um levantamento, não um resgate: numa codebase genuinamente antiga ele vai achar candidatos reais, mas não vai desembolar o mud por você.
Fundamentos de engenharia de software importam mais que nunca. Estas skills são o melhor esforço do Matt para condensar esses fundamentos em práticas repetíveis, para te ajudar a entregar os melhores apps da sua carreira. Aproveite.
Estas se dividem em um eixo — quem pode invocá-las. User-invoked skills são alcançáveis apenas quando você as digita (ex: /grill-me); o trabalho delas é orquestrar. Model-invoked skills podem ser invocadas por você ou alcançadas automaticamente pelo agent quando a task encaixa; elas contêm a disciplina reutilizável. Uma user-invoked skill pode invocar model-invoked skills, mas nunca outra user-invoked.
Skills que uso todo dia para trabalho com código.
User-invoked
- ask-matt — Pergunte qual skill ou fluxo encaixa na sua situação. Um router sobre as skills deste repo.
- grill-with-docs — Sessão de sabatina que também constrói o domain model do projeto, afiando terminologia e atualizando
CONTEXT.mde ADRs inline. - triage — Move issues e PRs externos através de uma máquina de estados de triage roles.
- improve-codebase-architecture — Escaneia uma codebase em busca de oportunidades de deepening, apresenta como relatório HTML visual e depois sabatina a escolhida.
- setup-leandrocfe-skills — Configura este repo para as engineering skills (issue tracker, triage labels, domain doc layout). Rode uma vez por repo antes de usar as outras engineering skills.
- to-spec — Transforma a conversa atual em uma spec e publica no issue tracker. Sem entrevista — só sintetiza o que você já discutiu.
- to-tickets — Quebra qualquer plano, spec ou conversa em tickets tracer-bullet, cada um declarando suas blocking edges — texto num arquivo local, ou links de blocking nativos num tracker de verdade.
- wayfinder — Planeja um pedaço enorme de trabalho — maior do que uma sessão de agent segura — como um mapa compartilhado de decision tickets no issue tracker, resolvidos um por vez até o caminho até o destino ficar claro.
- implement — Implementa um pedaço de trabalho a partir de uma spec ou conjunto de tickets, conduzindo
/tdde fechando com/code-review.
Model-invoked
- prototype — Constrói um protótipo descartável para responder a uma pergunta de design: um único arquivo HTML compartilhável para perguntas de estado/business logic, ou várias variações radicalmente diferentes de UI alternáveis numa rota só.
- diagnosing-bugs — Loop disciplinado de diagnóstico para bugs difíceis e regressões de performance: construir um feedback loop que fica red neste bug → minimizar → hipotetizar → instrumentar → corrigir → testar regressão.
- research — Investiga uma pergunta contra fontes primárias de alta confiança e registra os achados como um Markdown citado no repo, rodando como background agent.
- tdd — Test-driven development com o loop red → green. Constrói features ou corrige bugs uma vertical slice por vez, em seams pré-acordados.
- domain-modeling — Constrói e afia ativamente o modelo de domínio de um projeto — desafia termos contra o glossário, stress-testa com cenários de edge-case e atualiza
CONTEXT.mde ADRs inline. - codebase-design — Disciplina e vocabulário compartilhados para projetar deep modules: muito comportamento atrás de uma interface pequena, colocado em um seam limpo, testável através da interface.
- code-review — Revisão em dois eixos do diff desde um ponto fixo: Standards (segue os padrões do repo, mais uma baseline de code smells do Fowler?) e Spec (implementa fielmente a issue/spec de origem?), rodando como sub-agents paralelos.
- resolving-merge-conflicts — Resolve um merge ou rebase em andamento com conflitos, hunk por hunk, por intenção rastreada à fonte primária de cada lado, e finaliza a operação — nunca
--abort. - wizard — Gera um wizard bash interativo que conduz um humano por passos que só ele pode executar: provisionar infraestrutura, configurar credenciais ou secrets de CI, percorrer um dashboard de terceiros desconhecido, ou rodar uma migração/cutover pontual.
Ferramentas gerais de workflow, não específicas de código.
User-invoked
- grill-me — Seja sabatinado sem dó sobre um plano ou design até cada ramo da design tree estar resolvido.
- handoff — Compacta a conversa atual em documento de handoff para outro agent continuar o trabalho.
- teach — Ensine um novo skill ou conceito ao usuário em múltiplas sessões, usando o diretório atual como workspace de ensino stateful.
- to-questionnaire — Transforma uma decisão que você não responde sozinho num questionário Markdown para a pessoa que responde — preenchido async, ou junto numa reunião. Ela te grilla sobre o envio (para quem é, o que você precisa de volta), não sobre o assunto.
- wait-what — Dispare no momento em que uma mensagem não pega. O agent a repropõe com o contexto que faltava, em português simples, usando o vocabulário do seu
CONTEXT.md.
Model-invoked
- grilling — Entrevista o usuário sem dó sobre um plano, decisão ou ideia até cada ramo da design tree estar resolvido. A primitiva de entrevista reutilizável por trás de
grill-me,grill-with-docs,triage,wayfindereimprove-codebase-architecture. - writing-for-agents — Escrever documentos que agents consomem: skills, AGENTS.md/CLAUDE.md, e qualquer doc que um agent alcance por um pointer.
Ferramentas que mantenho por perto mas raramente uso.
- git-guardrails-claude-code — Configura hooks do Claude Code para bloquear comandos git perigosos (push, reset --hard, clean, etc.) antes que executem.
- migrate-to-shoehorn — Migra arquivos de teste de type assertions
aspara @total-typescript/shoehorn. - scaffold-exercises — Cria estruturas de diretório de exercícios com seções, problems, solutions e explainers.
- setup-pre-commit — Configura hooks pre-commit com Husky, lint-staged, Prettier, type checking e testes.
Este projeto é uma adaptação não-oficial em português do Brasil das skills criadas por Matt Pocock. Estrutura, fluxo, filosofia e comportamento das skills foram preservados — linguagem e exemplos foram adaptados ao contexto brasileiro.
Repositório original: https://github.com/mattpocock/skills
Newsletter do Matt: https://www.aihero.dev/s/skills-newsletter
Todo o crédito de design, intenção e conteúdo original vai para o Matt Pocock.