🧩 Skill de domínio vs skill de processo
Há duas famílias de skill. A de domínio codifica conhecimento sobre uma coisa: vercel-react-best-practices, supabase-postgres, stripe-best-practices. A de processo codifica COMO o agente pensa e trabalha — independente do assunto. É a diferença entre "o que saber sobre React" e "como debugar qualquer coisa".
📚 Skill de domínio
- ›Responde "o que sei sobre X"
- ›Dispara quando o tema X aparece
- ›Envelhece com o domínio (versão do framework)
- ›Ex.:
frontend-design,neon-postgres
🧠 Skill de processo
- ›Responde "COMO trabalhar/pensar"
- ›Dispara por tipo de tarefa, não por tema
- ›Atemporal — vale em qualquer linguagem/projeto
- ›Ex.:
test-driven-development,systematic-debugging
💡 Por que processo escala melhor
Uma skill de domínio serve quem mexe com aquele domínio. Uma skill de processo serve qualquer um que codifique. Por isso test-driven-development chega a 107k installs (obra/superpowers): TDD vale em Python, Go, Rust ou TypeScript igual. Processo tem mercado total maior — e é o que falta no agente por padrão.
🧪 test-driven-development (107k)
A skill de processo mais instalada do nicho de Testing: test-driven-development, 107k installs, do repo obra/superpowers. Ela não ensina uma lib de testes — ela força uma ordem de trabalho: escrever o teste que falha ANTES de escrever a implementação. Isso muda radicalmente o comportamento do agente.
O que muda no comportamento do agente
- →Sem a skill: o agente escreve a implementação e talvez testes depois, otimistas demais.
- →Com a skill: ele primeiro escreve um teste que falha de verdade, confirma o vermelho, só então implementa o mínimo para passar.
- →Resultado: cada feature nasce com cobertura real, e o "passa nos testes" deixa de ser teatro.
Quando usar
Sempre que for implementar uma feature ou corrigir um bug com critério de aceite claro. Não use para protótipo descartável ou exploração ("vou só ver se a API responde"). O ganho aparece quando o output precisa ser verificável.
🦸 A família superpowers
O repo obra/superpowers popularizou a ideia de empacotar processos de engenharia como skills disparáveis. É uma constelação de process skills que se invocam entre si. As quatro pilares:
brainstorming
Muda: antes de qualquer criação, o agente explora intenção, requisitos e design em vez de partir pro código. Quando: features novas, componentes, mudanças de comportamento — antes de tocar em arquivo.
systematic-debugging
Muda: em vez de chutar correções, o agente reproduz, isola, forma hipótese e testa uma por vez. Quando: qualquer bug, falha de teste ou comportamento inesperado, ANTES de propor o fix.
writing-plans
Muda: transforma um spec em plano de passos verificáveis antes da implementação. Quando: tarefa multi-step com requisitos definidos — vira o roteiro que outra sessão executa.
verification-before-completion
Muda: proíbe declarar "pronto/funciona" sem rodar o comando de verificação e ver o output. Quando: antes de afirmar conclusão, commitar ou abrir PR — evidência antes de asserção.
💡 Skills que chamam skills
A graça do superpowers é a composição: writing-plans aponta para brainstorming, que aponta para verification-before-completion. Cada uma é atômica (uma responsabilidade), mas juntas formam um fluxo de trabalho disciplinado. É o oposto da skill "tudo-sobre-X" de 800 linhas.
⚖️ Process skill: rígida vs flexível
Nem toda skill de processo se escreve igual. Existe um espectro entre a rígida (um procedimento exato, passo a passo, que não admite desvio) e a flexível (princípios e heurísticas que o agente adapta ao contexto). Escolher errado no espectro é um anti-padrão sutil.
🔒 Rígida (procedimento)
Sequência fixa que deve ser seguida à risca. Ex.: o ciclo red-green-refactor do TDD, ou um checklist de deploy.
- ✓Boa quando pular um passo é caro/perigoso
- ✓Resultado reproduzível e auditável
- ✗Ruim se o contexto varia muito
🌊 Flexível (heurística)
Princípios que o agente pondera. Ex.: o brainstorming ("explore intenção primeiro"), guidelines de design.
- ✓Boa quando cada caso é diferente
- ✓Generaliza além dos exemplos
- ✗Ruim se você precisa de garantia de execução
o sinal no texto da skill:
# RÍGIDA — verbos imperativos sequenciais, ordem importa 1. Escreva o teste. 2. Confirme que falha. 3. Implemente o mínimo. # FLEXÍVEL — princípio + porquê, o agente decide o como "Antes de criar, explore a intenção real: o usuário quer X ou quer resolver Y? Pergunte o que falta antes de assumir."
💡 A regra prática
Se errar o passo causa dano (deploy quebrado, dado perdido), vá de rígida. Se o valor está no julgamento (design, priorização, debug exploratório), vá de flexível e explique o porquê — lembrando que MUSTs em maiúscula numa skill flexível geram overfit.
❤️ Por que essas são amadas
As process skills aparecem desproporcionalmente no topo dos installs porque resolvem uma dor que toda pessoa que usa um agente tem, todo dia, em todo projeto. Três razões concretas:
Corrigem o comportamento padrão preguiçoso
Sem instrução, o agente tende a pular testes, chutar fixes e declarar "pronto" cedo demais. Essas skills impõem rigor onde ele falta por default.
Mercado total enorme
Servem qualquer linguagem e qualquer projeto. Uma skill de Postgres só interessa a quem usa Postgres; "como debugar" interessa a todo mundo.
Efeito composto e confiável
Aplicadas em todo trabalho, o ganho se acumula: menos retrabalho, menos "achei que funcionava". O usuário sente a diferença na primeira semana.
O contraste com Testing&QA como grupo
Curioso: o grupo Testing&QA tem 1.339 skills mas só 0,60M installs somados — média baixa. Ainda assim test-driven-development sozinha faz 107k. A lição: dentro de um grupo morno, uma skill de processo bem feita rompe a média porque ataca o comportamento, não só a ferramenta.
🧠 Roube esses padrões pra sua skill
Você não precisa publicar a próxima superpowers — basta aplicar os padrões dela na sua skill de processo. O checklist do que torna uma process skill amada:
✗ Process skill fraca
- ✗Mistura processo com conhecimento de domínio
- ✗Trigger preso a uma tecnologia específica
- ✗Lista de MUSTs sem explicar o porquê
- ✗Tenta cobrir 5 processos numa skill só
✓ Process skill amada
- ✓Um processo, uma responsabilidade (atômica)
- ✓Dispara por tipo de tarefa, agnóstica de stack
- ✓Explica o porquê; rígida só onde precisa
- ✓Compõe com outras process skills
💡 Ponte pro próximo módulo
Agora você sabe que tipo de skill vale a pena criar. No 5.4 a gente vai do conceito ao concreto: o checklist de decisão antes de criar, como estruturar o repo e os comandos exatos pra publicar e aparecer no skills.sh.
✅ Resumo do Módulo
Próximo:
Módulo 5.4 — 🛠️ Como Criar: Da Decisão ao Publish. O checklist de decisão, a estrutura de repo e os comandos exatos pra ir ao ar.