Onde mora a disciplina: o que Spec Kit, OpenSpec e Superpowers estão realmente vendendo

Três ferramentas concentravam boa parte da discussão sobre engenharia assistida por agentes em 21 de outubro de 2026. O GitHub Spec Kit estava na versão v1.2.2, com 142.278 estrelas; o OpenSpec, da Fission-AI, na v1.14.3, com 72.646; e o Superpowers, de Jesse Vincent, na v7.0.0, com 303.035. Os três projetos usam licença MIT e receberam atualizações entre 10 e 19/10. A proposta comum é reduzir o risco de código gerado por agentes que seja difícil de manter — mas cada um organiza o trabalho de um jeito.

A comparação por listas de recursos, sem considerar o modo de trabalho, não ajuda na decisão de adoção: as ferramentas não respondem à mesma pergunta.

flowchart TD
    subgraph SK["GitHub Spec Kit: Disciplina como Documento"]
        direction TB
        SK_Const["Constituição & Diretrizes"] --> SK_Spec["Especificação da Feature"]
        SK_Spec --> SK_Plan["Plano & Tarefas"]
        SK_Plan --> SK_Code["Código no Repositório"]
        SK_Note["Controle: arquivos Markdown estáticos por entrega"]
    end

    subgraph OS["OpenSpec: Disciplina como Memória Viva"]
        direction TB
        OS_Delta["Proposta Delta (+ / ~ / -)"] --> OS_Spec["Atualização da Spec Viva"]
        OS_Spec --> OS_Code["Código no Repositório"]
        OS_Delta -.->|"Trilha de auditoria"| OS_Arch[("archive/")]
        OS_Note["Controle: contrato de domínio atualizado"]
    end

    subgraph SP["Superpowers: Disciplina como Comportamento"]
        direction TB
        SP_Rules["Módulos de Instrução & Skills"] --> SP_Agents["Subagentes em Git Worktrees"]
        SP_Agents --> SP_Code["Histórico de Commits no Git"]
        SP_Note["Controle: regras antirrecuo e TDD em sessão"]
    end

Essa tabela resume a tese deste artigo: disciplina de engenharia depende de onde as decisões ficam registradas e como são verificadas. O formato escolhido define que tipo de erro será detectado, por quem e em que momento — além do trabalho que a equipe assume depois da entrega. Esse custo operacional, mais do que a lista de recursos, ajuda a decidir se a ferramenta cabe na rotina depois dos primeiros meses.

O posicionamento público também ajuda a entender o mercado. Na seção de comparação do README, o OpenSpec descreve o Spec Kit como mais abrangente, porém mais pesado e rígido, com muitos arquivos Markdown e configuração em Python; apresenta o OpenSpec como uma alternativa mais leve e iterativa. Sobre o Kiro, aponta dependência do ambiente de desenvolvimento da AWS e de modelos Claude (README, seção de comparação). Essa é a leitura do próprio projeto, não uma avaliação independente. Nas documentações e notas de versão do Superpowers consultadas, não encontramos comparação nominal com ferramentas de especificação — sinal de que o projeto atua em outro eixo.

Spec Kit: a disciplina como documento

O Spec Kit se apresenta como um conjunto de código aberto que fornece processos estruturados, modelos reutilizáveis e resultados documentados para agentes de código (README). A orientação é executar os comandos um de cada vez na conversa com o agente e revisar cada resultado antes de avançar. O fluxo completo é /speckit.constitution → /speckit.specify → /speckit.clarify → /speckit.plan → /speckit.checklist → /speckit.tasks → /speckit.analyze → /speckit.implement → /speckit.converge. A documentação classifica clarify, checklist e analyze como etapas opcionais de controle de qualidade e mantém um caminho mais curto (specify → plan → tasks → implement → converge) para entregas menores (referência).

A estrutura dos arquivos mostra onde fica o registro. Cada funcionalidade ganha um diretório specs/NNN-nome/ com spec.md, plan.md, tasks.md e artefatos derivados do planejamento (research.md, data-model.md, contracts/, quickstart.md). O projeto também mantém uma constituição comum em .specify/memory/constitution.md, consultada nas etapas de planejamento, análise e convergência. O modelo de plano inclui verificações de simplicidade e de prevenção a abstrações desnecessárias. Entre os princípios documentados estão começar cada funcionalidade como uma biblioteca independente e escrever os testes antes da implementação — diretrizes que ampliam o controle, mas também exigem tempo de especificação e validação (spec-driven.md).

Um ponto importante para estimar a adoção é o papel da CLI. specify init monta de forma determinística a estrutura inicial do projeto: baixa e prepara arquivos de comando e instruções para o agente escolhido, além de copiar modelos, scripts e arquivos de memória. Há opções para usar a estrutura compartilhada sem agente (none) ou uma integração genérica (generic). A CLI não chama um modelo; a execução fica a cargo das instruções em Markdown. Alguns arquivos são extensos — checklist.md tem 21,8 KB, clarify.md 19,0 KB e specify.md 18,0 KB (conteúdo do repositório) — e orientam o agente a criar diretórios, preencher modelos, executar ganchos e produzir os artefatos.

A aposta metodológica está declarada no documento de filosofia: ao contrário de abordagens que tratam a distância entre especificação e implementação como inevitável, o SDD busca reduzi-la ao transformar especificações e planos em instruções executáveis (spec-driven.md). É a formulação mais forte de uma abordagem centrada em artefatos. A consequência operacional é direta: a especificação passa a exigir manutenção para continuar representando o sistema.

O projeto também documenta o que não automatiza. O guia de adoção em projetos existentes e evolução de especificações informa que não há um comando central para reconciliar automaticamente spec.md, plan.md e tasks.md; /speckit.analyze aponta inconsistências, mas não altera os arquivos. Depois da entrega, o time escolhe entre manter o fluxo adiante, atualizar uma especificação viva ou reconstruir a especificação a partir do código — nenhum desses modelos é obrigatório. A página de histórico da versão 1.0 também esclarece que o número da versão, por si só, não representa uma garantia de estabilidade (histórico do projeto). Portanto, o Spec Kit estrutura a produção dos artefatos, mas deixa a política de manutenção a cargo da equipe.

OpenSpec: a especificação como memória operacional

O OpenSpec parte de outro diagnóstico: requisitos perdem continuidade quando ficam apenas no histórico da conversa. Sua proposta é manter especificações versionadas no repositório. Em openspec/, specs/ descreve como o sistema funciona hoje; changes/ concentra propostas em andamento, cada uma com proposal.md, design.md, tasks.md e especificações incrementais (conceitos).

O delta é o mecanismo central. Uma mudança não reescreve toda a especificação: declara requisitos a adicionar (ADDED), alterar (MODIFIED) ou remover (REMOVED). Ao arquivar a proposta, o sistema incorpora as adições, substitui requisitos alterados pelo título correspondente e remove os que foram marcados para exclusão. A pasta vai para changes/archive/YYYY-MM-DD-<nome>/ e permanece como trilha de auditoria. Assim, cada decisão de engenharia fica ligada a uma proposta versionada.

A especificação usa Markdown, RFC 2119 e cenários estruturados em condição, ação e resultado. A documentação a define como contrato de comportamento, não como plano de implementação (docs/concepts.md). O rigor é progressivo: mudanças simples podem usar o modo Lite; mudanças de contrato, migração, segurança ou alto custo de retrabalho justificam a especificação completa. Também há uma separação operacional: o CLI (openspec list, validate, archive, status, instructions) executa operações determinísticas, enquanto comandos como /opsx:propose, /opsx:apply e /opsx:archive orientam o agente. A documentação de uso dedica uma página a explicar essa distinção, que costuma confundir novos usuários (docs/how-commands-work.md). O contrato de integração com agentes registra formatos JSON, códigos de saída e diagnósticos; openspec init gera instruções e arquivos de comando para mais de 30 ferramentas.

A orientação para projetos já existentes é evitar documentar de antemão todo o código que não será alterado. Segundo o projeto, essas especificações tendem a ficar desatualizadas porque não há um processo que obrigue a sincronizá-las com o sistema; mudanças reais devem conduzir a atualização da documentação (existing-projects).

Essa escolha reduz o custo de documentar o que não está em uso, mas também define um limite: partes do sistema que nunca entram em uma proposta podem ficar sem revisão. A atualização depende de a equipe reconhecer essa necessidade e incluí-la no trabalho.

Superpowers: a disciplina como comportamento

O Superpowers não cria uma especificação para cada funcionalidade. Ele fornece instruções de trabalho organizadas em 15 módulos e orientações iniciais para que o agente as use (README). Não há CLI: as instruções em Markdown são carregadas no contexto. A ativação combina descrições dos módulos expostas pelo ambiente de desenvolvimento e a inclusão de using-superpowers no início da sessão. O projeto declara suporte a 16 ambientes, entre eles Claude Code, Codex, OpenCode, Cursor, Gemini, Pi, Antigravity e Hermes; a forma de ativação varia conforme os recursos de cada ambiente.

A cadeia começa com levantamento de requisitos em conversa, seguido por um documento de design em docs/superpowers/specs/. Um agente que não participou da elaboração revisa esse documento e aponta dúvidas antes da criação do plano em docs/superpowers/plans/. O plano deve referenciar o design e dividir o trabalho em ações com resultados verificáveis (skills/writing-plans/SKILL.md). A execução recomendada usa uma área de trabalho isolada, agentes diferentes por tarefa, revisão por etapa e um limite de cinco rodadas de correção; a equipe verifica o resultado antes de decidir como integrar as mudanças. O fluxo é rigoroso, mas também exige mais interações e coordenação.

Duas coisas nesse design não têm equivalente nas outras ferramentas e valem atenção de quem avalia processo, não artefato.

Uma característica do método é antecipar desvios previsíveis do agente. Na versão 7.0.0, 12 dos 15 módulos incluem listas de alertas que associam justificativas comuns ao comportamento esperado. O projeto relata que, ao remover esse tipo de orientação do módulo de desenvolvimento orientado por testes (TDD) na versão 6.2.0, o desempenho em testes internos caiu de 8/10 para 5/10; a orientação foi restaurada (notas de versão). É uma evidência útil de que a redação das instruções pode alterar o comportamento, mas vem de avaliações internas do próprio projeto.

Outra decisão é não manter o plano como documento permanente: depois da execução, o espaço de trabalho do plano é removido e o histórico do Git passa a ser o registro durável (skills/executing-plans/SKILL.md). Como consequência, o método não mantém especificações vivas, identificadores de requisitos ou uma matriz de rastreabilidade. O README inclui uma orientação específica para investigar módulos de instrução acionados fora de hora ou não acionados quando deveriam.

Nesse modelo, o controle depende do que acontece durante a sessão. A exigência de evidência recente antes de declarar sucesso é forte; em contrapartida, o processo não deixa por si só uma especificação viva que permita auditar, meses depois, se o sistema continua alinhado ao que foi decidido.

O custo que a equipe assume

Três relatos independentes ajudam a dimensionar custos diferentes: revisão de documentos, uso de tokens e manutenção da memória do sistema.

Especificação: parte do esforço migra para a revisão documental. Colin Eberhardt, CTO da Scott Logic, reimplementou uma funcionalidade real com o Spec Kit e registrou 33 minutos e 30 segundos de execução do agente, 689 linhas de código, 2.577 linhas de Markdown e três horas e meia de revisão. Na avaliação dele, o tempo adicional de leitura e revisão reduziu a produtividade em relação ao fluxo sem SDD. Também apontou conteúdo duplicado e especificações com justificativas frágeis (relato). Birgitta Böckeler, da Thoughtworks, descreveu artefatos extensos e repetitivos que exigiam revisão trabalhosa; observou também que o agente nem sempre seguia todas as instruções, apesar dos modelos e listas de verificação (análise). São avaliações individuais, não uma avaliação comparativa controlada, mas mostram que documentar mais não elimina a necessidade de revisar o resultado.

xychart-beta
    title "Distribuição do Tempo na Entrega com SDD (Colin Eberhardt / Scott Logic)"
    x-axis ["Execução do Agente", "Revisão Humana de Documentos"]
    y-axis "Tempo em minutos" 0 --> 250
    bar [33.5, 210]

Processo: o custo pode aparecer no uso de tokens e no tempo de interação. Em uma discussão do projeto, um usuário relatou que uma tarefa consumiu 70 mil tokens de execução e mais 57 mil na revisão sem Superpowers; ao repetir com o método, o consumo chegou a 900 mil tokens, com resultado semelhante (discussão #1953). É um relato individual. Já as notas da versão 6.0.0 apresentam uma avaliação interna segundo a qual Claude Code e Codex produziram resultados de qualidade semelhante cerca de duas vezes mais rápido e com aproximadamente 50% menos tokens. O próprio projeto ressalva que esses números não se aplicam a todos os ambientes e tipos de trabalho (notas de versão); não localizamos avaliação comparativa independente publicada.

Especificação incremental: o custo está em manter a memória útil. Em uma discussão no Hacker News de 16–17/09/2026, usuários relataram que especificações de longa duração perdem utilidade, embora o processo de proposta ajude a orientar agentes durante uma mudança complexa. Outros descreveram aumento de esforço para cada alteração; o mantenedor reconheceu que especificações sem curadoria podem ficar difíceis de ler (discussão). São experiências distintas, mas apontam para uma mesma necessidade de operação: definir quem revisa a especificação e quando ela deve ser atualizada.

Os relatos não demonstram que os mecanismos falham; mostram o trabalho que eles não eliminam. Para avaliar custo total, a equipe deve perguntar que atividade de revisão ou manutenção será transferida para as pessoas. O Spec Kit aumenta a revisão documental; o OpenSpec exige curadoria da especificação ao longo do tempo; o Superpowers demanda interação e acompanhamento do processo. Nenhuma abordagem elimina o custo — ela o distribui de forma diferente.

A transferência real de trabalho: Nenhuma abordagem elimina o esforço humano; elas apenas transferem a carga de lugar. O Spec Kit transfere para a leitura e revisão de arquivos Markdown; o OpenSpec para a curadoria contínua da especificação viva; o Superpowers para a supervisão em tempo real e o consumo de tokens na sessão.

Há ainda um custo pouco considerado na adoção: acompanhar mudanças de versão. O OpenSpec publicou 54 versões em cerca de 13 meses. Na versão 1.0.0, removeu comandos antigos e deixou de gerar arquivos de instrução específicos para cada ferramenta (CHANGELOG). O Spec Kit publicou 21 versões entre a 1.0.0, em 21/08/2026, e a 1.2.2, em 19/10/2026; sua documentação não promete congelamento da interface. O Superpowers documentou 45 versões em 12 meses e retirou, depois restaurou, o suporte ao Gemini CLI em versões consecutivas; o projeto reconheceu que a remoção havia sido prematura (RELEASE-NOTES). A equipe que adota qualquer uma das três precisa prever atualização e compatibilidade, sem contar com um contrato de estabilidade.

Uma lacuna comum: verificar se o código continua atendendo à especificação

Esta seção separa o que as ferramentas automatizam do que continua sob responsabilidade da equipe.

As três ferramentas ajudam a produzir especificações e a conduzir agentes, mas nenhuma verifica de forma determinística se o código continua em conformidade com a especificação. Essa distinção aparece nas próprias documentações.

No Spec Kit, /speckit.analyze funciona em modo somente leitura e aponta inconsistências entre artefatos. /speckit.converge só pode acrescentar uma seção de convergência ao tasks.md; não compara versões nem acompanha mudanças ao longo do tempo (converge.md). A avaliação sobre o estado atual do código é feita pelo modelo e não é apresentada como garantia formal. A reconciliação depois da entrega continua sendo uma convenção da equipe; verificações mais rígidas aparecem em extensões de terceiros, que o próprio README não trata como auditadas ou endossadas pelo projeto.

No OpenSpec, openspec validate faz uma verificação estrutural — inclusive confere se um requisito marcado como MODIFIED corresponde a um requisito existente —, mas não valida o comportamento do sistema (docs/cli.md). /opsx:verify é uma avaliação heurística feita pelo agente, com níveis de severidade, e não impede o arquivamento; o archive apenas avisa sobre tarefas incompletas (docs/commands.md). A documentação de personalização esclarece que o projeto verifica a presença dos artefatos, enquanto controles adicionais precisam ser implementados pela equipe na integração contínua (CI) ou por ganchos de execução (docs/customization.md).

No Superpowers, a exigência de evidência recente antes de declarar conclusão é mais forte durante a sessão (verification-before-completion). Ainda assim, trata-se de verificar testes executados, não a conformidade com uma especificação persistente. O método é aplicado por instruções em Markdown: elas aumentam a chance de o agente seguir o processo, mas não garantem esse comportamento. O projeto mantém inclusive uma rotina de diagnóstico para investigar instruções que não foram acionadas como esperado.

Outra lacuna é governança: definir responsáveis por requisitos, aprovações, métricas e orçamento de mudança. Nenhuma das três ferramentas entrega esse modelo completo. O OpenSpec mantém desde 18/08/2026 uma proposta para declarar a responsabilidade dos agentes e direcionar especificações e tarefas (discussão #1693). No Spec Kit, modelos prontos e extensões de terceiros atendem a alguns papéis regulatórios (README). O Superpowers exige evidências de avaliação para determinadas mudanças relacionadas a conformidade, segundo o guia de contribuição, e suas notas de versão registram uma taxa de rejeição de solicitações de alteração de 94% (AGENTS.md; RELEASE-NOTES).

Escolher entre as três é decidir quais riscos e custos a equipe quer controlar primeiro: implementar sem requisitos claros, trabalhar sem um processo consistente ou manter documentos que deixam de refletir o sistema. Spec Kit e OpenSpec priorizam o registro dos requisitos; Superpowers prioriza a condução do trabalho. Nenhum deles, isoladamente, comprova meses depois que o sistema em produção ainda corresponde ao que foi especificado.

Como avaliar a adoção na sua operação

O que se segue é uma recomendação de projeto, não um resultado medido pelas fontes acima.

Para selecionar uma abordagem, a pergunta prática é: que controles a equipe consegue aplicar de forma verificável? Um controle automatizado que interrompe a integração contínua oferece uma garantia diferente de uma lista de verificação interpretada pelo modelo. A partir das lacunas observadas, uma operação de engenharia assistida por agentes precisa considerar quatro camadas; as ferramentas analisadas cobrem, no melhor dos casos, as três primeiras:

1. Modelagem do domínio: limites explícitos e decisões de arquitetura registradas (ADR). Spec Kit pode produzir parte disso durante o planejamento; OpenSpec organiza especificações por domínio em specs/.
2. Gestão do contexto do agente: definir o que o agente lê, em que ordem, com qual orçamento de tokens e o que fica fora da tarefa. O OpenSpec chega mais perto de tratar esse contexto como contrato, com regras por artefato em config.yaml e uma interface JSON documentada.
3. Execução e revisão: dividir o trabalho em tarefas pequenas, com resultado verificável; isolar a execução; e fazer uma pessoa ou agente diferente revisar o que foi produzido. O Superpowers cobre essa camada com mais detalhe, por meio do processo descrito em seus módulos de instrução.
4. Verificação e governança: estabelecer critérios testáveis entre requisitos e código, controles que interrompam a integração contínua quando necessário, testes que comprovem a capacidade de detectar regressões e responsáveis por requisitos e mudanças. Nenhuma das três entrega essa camada completa; é ela que protege o valor do investimento nas demais.

flowchart TD
    subgraph L4["Camada 4: Verificação & Governança"]
        direction TB
        L4_Desc["Gates de CI, conformidade spec↔código e rastreabilidade durável"]
        L4_Gap["⚠️ LACUNA COMUM: Não automatizada por nenhuma das três ferramentas"]
    end

    subgraph L3["Camada 3: Execução & Revisão"]
        L3_Desc["Subagentes isolados em worktrees, TDD e regras antirrecuo em sessão"]
        L3_Cov["Foco: Superpowers"]
    end

    subgraph L2["Camada 2: Gestão de Contexto do Agente"]
        L2_Desc["Contratos de contexto por tarefa, interfaces JSON e orçamento de tokens"]
        L2_Cov["Foco: OpenSpec"]
    end

    subgraph L1["Camada 1: Modelagem do Domínio"]
        L1_Desc["Bounded contexts, ADRs, constituição e requisitos da entrega"]
        L1_Cov["Foco: Spec Kit e OpenSpec"]
    end

    L1 --> L2 --> L3 --> L4

A ilusão da substituição direta: Combinar ferramentas resolve a modelagem (L1), o contexto (L2) e a condução da sessão (L3), mas não fecha a Camada 4. O que protege o investimento no longo prazo não é a quantidade de Markdown acumulado, mas a existência de testes e gates determinísticos no pipeline capazes de provar que o código em produção continua respeitando o que foi especificado.

Por essa diferença, as três não são substitutas diretas: é possível combiná-las e ainda assim não ter a quarta camada. A decisão não é apenas entre especificação e processo. Especificação sem atualização pode virar documento obsoleto; processo sem registro dificulta auditoria posterior. O que falta é evidência durável e verificável de conformidade, construída nos testes e controles do ciclo de entrega. É uma questão de engenharia e governança, não apenas de escolher uma ferramenta.

Notas de método

Este artigo é uma análise documental. Não executamos as três ferramentas sobre um caso comum; por isso, não medimos o custo de uso em uma operação própria nem recomendamos uma delas para um cenário específico. Uma comparação prática desse tipo exigiria um teste controlado separado.

O estado citado é de 21/10/2026: estrelas, versões e notas de versão vieram da API e das páginas dos repositórios consultadas no mesmo dia; números de estrelas flutuam rápido e são um indicador indireto de adoção, não de qualidade. Todos os comportamentos descritos do Superpowers foram lidos diretamente nos arquivos da v7.0.0 instalada (módulos de instrução, RELEASE-NOTES.md, AGENTS.md e README), não em resumos de terceiros.

Três cuidados de fonte se aplicam a este artigo: (1) os relatos da Scott Logic, da Thoughtworks, do Hacker News e da discussão #1953 são experiências individuais e datadas; servem para ilustrar custos humanos, não como métricas comparáveis; (2) os números de desempenho do Superpowers vêm da avaliação da própria equipe (superpowers-evals), que ressalva diferenças entre ambientes e tipos de trabalho; não localizamos avaliação comparativa independente; (3) há serviços de terceiros que usam o nome OpenSpec e endereços semelhantes, como openspec.dev; um serviço que oferece um servidor MCP não vinculado ao projeto da Fission-AI foi excluído como fonte sobre a ferramenta analisada.

Onde este texto afirma “não encontrei”, significa que procuramos nas fontes primárias e não achamos, e isso não prova ausência. Onde é leitura nossa, dissemos.

A imagem de abertura foi gerada por IA (Gemini) e repete, em três painéis, a tese do texto: cada ferramenta ocupa a coluna que a tabela acima lhe dá. Ela ilustra o argumento; não é registro de execução das ferramentas nem captura de tela de nenhuma delas.