Superpowers: 311 mil estrelas para uma metodologia em Markdown

O repositório com mais estrelas na lista de tendências do GitHub desta semana não é um modelo, nem uma framework, nem a isca open source de uma startup. É uma pasta de ficheiros Markdown que diz ao seu agente de programação como se comportar.

O Superpowers, de Jesse Vincent, está à volta das 311 mil estrelas, com cerca de 5.900 ganhas na última semana. A descrição do próprio: uma metodologia completa de desenvolvimento de software para os seus agentes de programação, assente num conjunto de skills combináveis mais algumas instruções iniciais que garantem que o agente realmente as usa.

Trezentas mil estrelas por uma metodologia é uma coisa estranha de observar. Ou a maior coorte de programadores de uma década decidiu, ao mesmo tempo, que quer processo, ou o botão da estrela passou a ser um marcador para «tenho de pensar nisto mais tarde». Provavelmente as duas coisas. Mas a coisa em si merece ser levada a sério, porque é a resposta mais opinativa que alguém publicou à pergunta sobre o que um agente deve fazer antes de escrever código.

O primeiro passo é não começar

O fluxo, como o README o descreve, é este. Assim que o agente percebe que se está a construir algo, não salta para a escrita de código. Recua e pergunta o que se está realmente a tentar fazer.

Depois de arrancar uma especificação da conversa, mostra-a em blocos suficientemente curtos para serem lidos. Não uma parede de requisitos. Blocos. Depois do aval, produz um plano de implementação detalhado o suficiente, nas palavras do README, para que «um engenheiro júnior entusiasmado, com mau gosto, nenhum critério, nenhum contexto do projeto e aversão a testes» o consiga seguir.

Essa frase é a melhor coisa do repositório. É também uma descrição precisa daquilo que um LLM é num dia mau, e escrever o plano para esse leitor é uma disciplina que a maioria dos engenheiros salta porque assume que o leitor partilha o seu contexto.

Depois, quando se dá luz verde, lança desenvolvimento conduzido por subagentes: os agentes percorrem cada tarefa, inspecionam e revêem o próprio trabalho, e continuam. O README afirma que não é invulgar o agente trabalhar de forma autónoma durante um par de horas sem se desviar do plano.

O que vem lá dentro

Umas quinze skills, agrupadas por função.

Os testes têm uma entrada, e é a que interessa: test-driven-development, o ciclo vermelho-verde-refatorar, com um documento de referência sobre anti-padrões de teste. A depuração tem systematic-debugging, um processo de causa-raiz em quatro fases com técnicas de rastreio, defesa em profundidade e espera baseada em condições, mais verification-before-completion, cujo único trabalho é impedir o agente de declarar vitória sobre algo que não está corrigido.

A colaboração é onde está o peso real: brainstorming para extrair a intenção, writing-plans, executing-plans, dispatching-parallel-agents, pedir e receber revisão de código, using-git-worktrees, finishing-a-development-branch e subagent-driven-development com a sua revisão em duas etapas — primeiro o cumprimento da especificação, depois a qualidade do código.

Duas meta-skills fecham o círculo: writing-skills, para criar novas, e using-superpowers, a introdução que leva o modelo a carregar o sistema no início de uma conversa. Como as skills disparam automaticamente, a teoria é que não é preciso lembrar-se de nada disto. O agente simplesmente tem.

Instalar, por arnês, dezasseis vezes

É esta a parte que mostra o quanto o mercado de ferramentas para agentes está fragmentado. O Superpowers traz instruções para Claude Code, Antigravity, a aplicação e a CLI do Codex, Cursor, Devin CLI, Factory Droid, Gemini CLI, GitHub Copilot CLI, Grok Build, Kimi Code, OpenCode, Pi, Qwen Code, Hermes e Muse.

Claude Code, pelo marketplace oficial:

/plugin install superpowers@claude-plugins-official

Ou pelo marketplace do próprio Vincent:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

Cursor, na conversa do agente: /add-plugin superpowers. Gemini CLI: gemini extensions install https://github.com/obra/superpowers. Copilot CLI: registar o marketplace e depois copilot plugin install superpowers@superpowers-marketplace. Antigravity: agy plugin install https://github.com/obra/superpowers. Devin: devin plugins install obra/superpowers. Factory Droid: registar e instalar. A aplicação e a CLI do Codex passam ambas pelo marketplace oficial de plugins.

Quem usa mais do que um arnês instala em separado para cada um. O que significa que as mesmas doze skills existem como doze cópias sem caminho de atualização partilhado, e o conselho do README para atualizar é «depende um pouco do agente de programação, mas muitas vezes é automático». Não é uma crítica a este projeto. É o estado atual do ecossistema, e ver um repositório de metodologia a lidar com isso é genuinamente informativo.

A política de contribuições é a pista

Enterrado na secção de contribuições: em geral não aceitam contribuições de skills novas, as atualizações de skills têm de funcionar em todos os agentes suportados, e não aceitam PRs escritos por agentes que corrijam problemas abertos por outra pessoa, a menos que um maintainer os tenha pedido, mesmo quando se bate no mesmo problema.

Vale a pena pensar para que serve essa última regra. O modo de falha óbvio para um repositório destes é ficar soterrado em skills plausíveis geradas pelos próprios agentes que as skills deviam governar. Vincent viu-o chegar e antecipou-se, ao custo de parecer pouco simpático.

Tem também uma implicação mais subtil. Se o seu agente consegue gerar uma skill para qualquer coisa, o recurso escasso deixa de ser a skill e passa a ser o critério sobre quais valem a pena. Esse critério é o que o repositório está realmente a vender, e não está aberto a pull requests.

Onde a metodologia parte

Quatro coisas, por ordem de quantas vezes as vi morder.

O processo não corrige o gosto. Um plano executado na perfeição para uma funcionalidade mal concebida produz uma versão bem testada da coisa errada. A skill de brainstorming ajuda ao perguntar o que se quer, mas não vai dizer que a ideia é sem graça.

Economia de tokens. Especificação, revisão em blocos, plano, distribuição por subagentes, revisão em duas etapas por tarefa, verificação antes da conclusão. Numa tarefa pequena isto é uma quantidade espetacular de sobrecarga. A metodologia foi desenhada para trabalho medido em dias, e vai parecer absurda numa correção de uma linha.

Os planos derivam. Duas horas de trabalho autónomo contra um plano escrito no minuto zero correm bem quando o plano estava certo. Quando a terceira tarefa revela que a segunda assentava num pressuposto errado, ficam duas horas de trabalho confiante na direção errada, e a revisão é a única coisa entre si e um diff muito grande.

E a honesta: skills são prompts, e prompts são sugestões. Tudo aqui depende de o modelo escolher seguir a skill em vez de outras cinco coisas que também sabe. É por isso que using-superpowers existe como arranque — é um prompt cujo trabalho é fazer carregar outros prompts.

Para quem é isto

Se entrega código de que outras pessoas dependem, e já viu um agente marcar com confiança como concluído algo que não estava, este é um conjunto razoável de grades e custa um comando para experimentar. Comece por test-driven-development e verification-before-completion e ignore o resto durante uma semana. São essas duas que mais mudam o comportamento.

Se está a fazer protótipos, ignore. A metodologia está otimizada para não entregar lixo, o que é um objetivo diferente de descobrir se a ideia funciona.

Trezentas mil estrelas não são um veredicto sobre a metodologia. São um veredicto sobre o momento: muita gente tem agora agentes que escrevem código mais depressa do que conseguem supervisionar, e procura algo que torne a supervisão mais barata. O Superpowers é uma resposta. O facto de ser feito de Markdown é a parte mais interessante.