Superpowers vale a pena em tarefa pequena? Quando o processo pesa mais do que ajuda

Você pede um ajuste de duas linhas e recebe design validado, branch nova, plano quebrado em tarefas e ciclo RED-GREEN-REFACTOR inteiro em cima de uma flag

Aí o que levaria três minutos vira meia hora de cerimônia, e a sensação é de estar servindo o processo em vez de ser servido por ele

O Superpowers é o framework de skills e metodologia de desenvolvimento criado por Jesse Vincent (o obra do GitHub) junto com a equipe da Prime Radiant

E a pergunta deste post não é se ele é bom

A pergunta é OUTRA: quando o processo inteiro cabe na tarefa que tu tem na mão, e quando ele é peso morto

A boa notícia é que a resposta já mora dentro do próprio framework. A versão 6.3.0, lançada em 12 de agosto de 2026 e a maior desde a 6.0, fez a skill de brainstorming classificar o pedido em três caminhos: spike, bounded e architectural

Bora destrinchar cada um?

Spike, bounded e architectural: o que cada caminho exige de você

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Os três caminhos não são níveis de "esforço" no chute

Cada um responde uma pergunta diferente, entrega uma coisa diferente e cobra uma cerimônia diferente de você

Uma nota que vale ouro e passa despercebida: se não há fluxo existente pra alterar, a tarefa não é bounded

Parece detalhe, mas é o erro de classificação mais comum. "É só um endpoint" em um subsistema que ainda não existe não é bounded, é architectural disfarçado 😀

E tem uma coisa que NÃO muda em caminho nenhum: o gate de aprovação. A cerimônia escala com a tarefa, tarefa pequena pula o ritual dos dois documentos, mas a aprovação do humano antes de começar a implementar nunca é pulada

As seções de explorar abordagens em diante são profundidade do caminho architectural. No bounded elas simplesmente não entram

Sinais de que vale seguir o fluxo inteiro

Tem trabalho em que a cerimônia paga por si em poucas horas

Os sinais são bem concretos:

• Projeto novo ou subsistema novo, onde não existe fluxo anterior pra ler e as decisões de encaixe ainda estão em aberto
• Mudança que reorganiza como as peças se encaixam, não que altera o comportamento de uma delas
• Trabalho longo que precisa sobreviver a troca de contexto, seja porque você vai parar no meio, seja porque quem continua não é você

Quando esses sinais aparecem, cada skill da esteira tem um trabalho claro:

• using-git-worktrees entra DEPOIS do design aprovado, cria o workspace isolado em uma branch nova, roda o setup do projeto e verifica um baseline de testes limpo antes de qualquer implementação
• writing-plans quebra o trabalho em tarefas de 2 a 5 minutos cada, com caminhos de arquivo exatos, código completo e passo de verificação
• executing-plans despacha um subagente fresco por tarefa, com revisão de conformidade com a spec e depois revisão de qualidade de código (ou execução em lotes com checkpoints humanos)
• test-driven-development segura o ciclo: RED escreve o teste e assiste falhar, GREEN escreve o código mínimo e assiste passar, REFACTOR limpa mantendo tudo verde
• requesting-code-review revisa o trabalho concluído contra o plano, e finishing-a-development-branch verifica os testes, apresenta as opções (merge, PR, manter, descartar) e limpa o worktree

Repara no desenho: subagente fresco por tarefa existe justamente porque contexto longo apodrece

É a mesma discussão de o que delegar ao agente e o que precisa passar pela sua mão, só que aplicada dentro de uma única feature

A 6.2.0, de 23 de julho de 2026, empurrou isso mais longe: o workspace do subagent driven development passou a exigir o arquivo de plano e resolver um diretório por plano em .superpowers/sdd/<plan-basename>/, e conflitos não catastróficos passaram a receber uma decisão registrada em vez de travar o controlador

Ou seja, o fluxo inteiro é feito pra trabalho que dura. Se o teu trabalho dura, ele rende

Sinais de que o processo está pesando mais do que ajudando

Agora o outro lado, que é onde a dor aparece

Os sinais também são concretos:

• É uma flag, um endpoint pequeno ou uma correção em um arquivo, com o fluxo já existindo no repositório
• É uma pergunta de viabilidade, do tipo "dá pra fazer?", cuja saída é uma resposta e não código pra manter
• O código que vai sair dali vai ser jogado fora de qualquer jeito

E o custo do excesso não é abstrato, se liga:

Ritual de dois documentos pra alterar uma linha é tempo puro, porque o caminho bounded resolve a mesma coisa com um design de poucos parágrafos no próprio chat

Worktree isolado, branch nova, setup do projeto e baseline de testes limpo pra um ajuste que some em minutos é infraestrutura demais pro tamanho da entrega

E o RED-GREEN-REFACTOR aplicado a uma sonda é o mais doído: a skill trata código escrito antes de existir um teste falhando como descartável, ele é deletado e refeito

Faz todo sentido em código que vai viver no repo

Em uma sonda que já ia pro lixo, você está pagando o preço de disciplina de produção por algo que morre na próxima hora, sacou?

Mas tome cuidado com a conclusão fácil aqui

O remédio não é abandonar o framework nem sair pedindo pra pular etapa. O remédio é acertar a classificação na ENTRADA: dizer o que é a tarefa, se existe fluxo pra alterar e o que você espera receber no fim (uma resposta ou código pra manter)

Caminho errado escolhido lá no começo é o que gera cerimônia demais, não a existência das skills

Veredito: escolher o caminho é a decisão, não usar ou não usar

O detalhe que fecha a conta é o ratchet de mão única

Quando o agente encontra complexidade escondida no meio do trabalho, ele para, avisa e sobe de nível. Nenhum caminho é rebaixado no meio da tarefa

Isso muda completamente a matemática do erro

Errar pra baixo é recuperável: você começa em bounded, a complexidade aparece, o caminho sobe e a vida segue

Errar pra cima custa tempo e não tem volta: entrou em architectural, o ritual completo roda até o fim, e você não vai rebaixar no meio pra economizar

Então a régua prática é: na dúvida, comece no caminho mais leve que ainda descreve a tarefa com honestidade

Sobre custo, o próprio autor afirma no anúncio da versão 6 (de junho de 2026) que os builds ficaram até 50% mais rápidos e até 60% mais baratos em tokens, junto com o suporte ampliado pra além do Claude Code, com skills reescritas pra serem agnósticas de modelo e de harness

É afirmação dele, não medição nossa, e vale ler como tal

Pra quem compensa o fluxo completo: quem constrói coisa nova, mexe em estrutura ou toca trabalho que precisa sobreviver a interrupção

Pra quem não compensa: quem passa o dia em ajuste delimitado e em sondas de viabilidade, e aí bounded e spike já entregam o gate de aprovação sem o resto do ritual

A lógica é a mesma de quando o Claude Fable 5 compensa: a ferramenta não é cara nem barata em abstrato, ela é cara ou barata PRA AQUELA tarefa

Conclusão

A régua cabe em uma frase: o Superpowers não se decide no sim ou não, se decide no caminho, e a pergunta de entrada é se existe fluxo no repositório pra alterar e se a saída é uma resposta ou código pra manter

Se tu quer sair testando isso na prática, o próximo passo é curto:

1. Adicione o marketplace do projeto no Claude Code

/plugin marketplace add obra/superpowers-marketplace

2. Instale o plugin

/plugin install superpowers@superpowers-marketplace

O erro comum deste passo é rodar a instalação sem ter adicionado o marketplace antes: o nome depois do @ é justamente o marketplace do passo anterior

3. Leia as skills direto na fonte, em github.com/obra/superpowers-skills, pra ver o que cada caminho realmente exige antes de confiar no resumo de qualquer um (inclusive no meu 🙂)

4. Classifique a PRÓXIMA tarefa antes de pedir qualquer código: spike, bounded ou architectural

Esse quarto passo é o que muda o resultado. O resto é consequência

E se você usa outro harness, a 6.3.0 também trouxe suporte first class ao Devin CLI, com instalação via devin plugins install obra/superpowers e manifesto em .devin-plugin/plugin.json, que descobre as skills no diretório skills/ ao lado

Até o próximo post!