GitHub Spec Kit vs Kiro vs Workflows SDD do Claude Code

Desenvolvedores que comparam configurações de Desenvolvimento Orientado por Especificação (Spec-Driven Development) em 2026 geralmente não estão perguntando qual modelo é o mais inteligente. Eles estão perguntando qual fluxo de trabalho manterá um agente de IA alinhado sem sotrá-los em cerimônias burocráticas.

O GitHub Spec Kit, o AWS Kiro e os fluxos de trabalho personalizados do Claude Code implementam todos a mesma ideia ampla — requisitos, design, tarefas, implementação, validação — mas fazem trade-offs em portabilidade, profundidade de integração e na quantidade de processo que impõem.

Se você precisa primeiro dos conceitos, leia O que é Desenvolvimento Orientado por Especificação? e o guia neutro em relação a ferramentas Fluxo de Trabalho de Desenvolvimento Orientado por Especificação no cluster de documentação Arquitetura de Aplicativos. Esta comparação está no hub Ferramentas de Desenvolvimento com IA ao lado de avaliações de assistentes e guias de fluxo de trabalho.

SDD Está se Tornando uma Categoria de Ferramentas

O Desenvolvimento Orientado por Especificação deixou de ser um exercício de papel em algum momento no final de 2025. Todos os principais fornecedores de codificação com IA agora fornecem alguma versão de especificar-planejar-implementar, e uma lista crescente de ferramentas independentes compete em quanta estrutura elas adicionam em torno desse ciclo.

A comparação que importa não é “qual ferramenta vence”. É profundidade de processo versus portabilidade. O Kiro é integrado. O Spec Kit é portátil. Os fluxos de trabalho do Claude Code são modificáveis. Especificações ruins tornam todos os agentes piores, independentemente de qual wrapper você escolher. Boas especificações viajam entre ferramentas.

Como Comparar Configurações de SDD

Antes de escolher uma ferramenta, nomeie o que você está otimizando. O mesmo recurso pode parecer descomplicado em uma configuração e burocrático em outra, dependendo do tamanho da equipe, da idade da base de código e de quanta revisão você precisa.

Portabilidade – As especificações podem viver como markdown simples no seu repositório e funcionar com o agente que você preferir no próximo trimestre? Ou estão atreladas a um único IDE, nuvem ou formato proprietário?

Atrito de configuração – Quanto tempo leva de “quero tentar SDD” até um loop funcional de especificar-planejar-tarefas? Scaffolding de CLI, instalação de IDE ou criação dos próprios comandos slash têm energias de ativação diferentes.

Qualidade da especificação – A ferramenta ajuda você a escrever requisitos e critérios de aceitação precisos, ou ela apenas gera documentos longos? Estrutura é útil. Volume não é.

Execução de tarefas – Como a ferramenta divide o trabalho em fatias revisáveis? As tarefas podem ser executadas em paralelo? Ela resiste a explosões de listas de tarefas com cinquenta itens?

Pontos de controle de revisão – Há portões humanos naturais entre especificar, planejar, tarefas e implementar? SDD sem revisão é apenas codificação por intuição mais lenta.

Ancoragem no repositório – O fluxo de trabalho lê as convenções do projeto, registros de decisão, ADRs, AGENTS.md e o código existente antes de planejar? Agentes sem ancoragem reinventam a arquitetura porque nunca veem a intenção revisada por trás das escolhas anteriores.

Colaboração em equipe – Várias pessoas podem revisar os mesmos artefatos de especificação em pull requests? Você pode misturar agentes sem reescrever o processo?

Lock-in – O que você perde se trocar editores, modelos ou fornecedores de nuvem em seis meses?

GitHub Spec Kit

O GitHub Spec Kit é um toolkit de CLI de código aberto que cria um loop orientado por especificação no seu repositório e entrega a execução a qualquer agente de codificação que você já use. A CLI specify insere modelos, comandos slash e um layout de pasta convencional. Os comandos típicos seguem uma sequência de constituição-especificar-clarificar-planejar-tarefas-implementar, com uma etapa explícita de esclarecimento para resolver ambiguidades antes que o trabalho de arquitetura comece.

A vantagem definidora do Spec Kit é a independência de agentes. Os documentos oficiais o posicionam como uma ferramenta que funciona com Claude Code, GitHub Copilot, Cursor, Gemini CLI, Codex e dezenas de outros agentes. Você escreve especificações uma vez em markdown, as comita como código e troca o executor sem reescrever o processo. Isso torna o Spec Kit a recomendação padrão para equipes que querem SDD sem apostar em um único fornecedor.

Os trade-offs são reais. O Spec Kit pode produzir uma grande árvore de artefatos — constituição, especificação, plano, tarefas, contratos — o que se paga em recursos multi-sessão, mas parece pesado para um pequeno ajuste em uma CLI. Threads no Hacker News regularmente comparam essa sobrecarga com a cerimônia do waterfall (cascata). O Spec Kit também é mais fraco se você quiser um IDE totalmente integrado onde especificações, tarefas e implementação vivem em uma única superfície guiada. Ele adiciona processo sobre o seu editor existente em vez de substituí-lo.

O Spec Kit se encaixa em equipes que já têm um assistente de codificação com IA preferido e querem um scaffold de SDD padronizado por cima. É especialmente forte para recursos greenfield, ambientes multiagente e qualquer pessoa que se recuse a aceitar lock-in de editor.

AWS Kiro

O Kiro é o IDE orientado por especificação da AWS, construído sobre um fork do VS Code / Code OSS. Onde o Spec Kit traz o SDD para o seu stack existente, o Kiro assume que o SDD merece um ambiente construído para o propósito. Um prompt gera artefatos estruturados — tipicamente requirements.md em notação estilo EARS, design.md e um tasks.md sequenciado por dependências — antes que os agentes escrevam código de produção.

A experiência guiada é o principal ponto de venda do Kiro. Requisitos, design e tarefas são objetos de UI de primeira classe ao lado do seu código, não arquivos que você gerencia através de uma CLI separada. O Kiro também fornece Agent Hooks, automações orientadas por eventos que podem atualizar testes, documentos ou artefatos relacionados quando a implementação muda. Esse loop bidirecional é algo que o Spec Kit não fornece nativamente — as especificações do Spec Kit permanecem estáticas até que um humano as atualize.

Os custos são a profundidade de integração trocada por portabilidade. O Kiro roda dentro do seu editor, usa modelos baseados em AWS Bedrock e cobra através de um modelo de preços baseado em créditos com planos em camadas. Equipes empresariais já na infraestrutura da AWS frequentemente acham isso aceitável. Desenvolvedores solo e equipes multi-editor podem não achar. O Kiro também tem arestas ásperas típicas de um IDE mais novo — compatibilidade de extensões, surpresas no fluxo de trabalho e a usual pergunta “eu realmente preciso de outro editor?”.

O Kiro se encaixa em desenvolvedores que querem a experiência de SDD mais guiada e estão confortáveis adotando um IDE nativo em especificação. É uma opção forte para equipes empresariais, ambientes pesados em AWS e qualquer pessoa migrando do Amazon Q Developer que quer disciplina de especificação sem montar a toolchain manualmente. Se você vive no VS Code padrão hoje e ama seu setup atual, o Kiro pede uma troca maior do que o Spec Kit.

Comandos e Skills Personalizados do Claude Code

O Claude Code não fornece um único produto oficial de SDD da forma como o Spec Kit ou o Kiro fazem. Se você é novo na própria ferramenta, comece com o guia de instalação e configuração do Claude Code para setup, permissões e backends locais. O padrão de SDD em si vive em comandos personalizados, skills e modelos de markdown locais no repositório que os desenvolvedores mantêm. A Anthropic integrou os arquivos antigos .claude/commands/*.md no mecanismo de Skills, então o padrão durável é um SKILL.md (ou equivalente) que define sua lista de verificação de especificar-planejar-implementar, carregado sob demanda.

Esta abordagem é a mais leve e modificável. Você pode portar um layout de três arquivos estilo Kiro, espelhar as fases do Spec Kit com comandos slash ou inventar um fluxo de trabalho mínimo que se encaixe em um repositório. O Claude Code lê CLAUDE.md para contexto de projeto sempre ativo e puxa skills quando a tarefa corresponde. Essa divulgação progressiva mantém as sessões focadas sem carregar uma constituição completa em cada prompt.

A desvantagem é a disciplina. Nada o força a passar por portões de esclarecimento ou revisão, a menos que você construa esses portões por conta própria. Threads no Reddit e Hacker News sobre “desenvolvimento orientado por especificação dentro do Claude Code” estão cheias de desenvolvedores que copiaram a skill de outra pessoa, a executaram uma vez e voltaram para a promptagem não estruturada quando a skill pareceu lenta. O SDD do Claude Code funciona quando você trata skills como código — versionado, revisado e mantido — e não como um download de prompt de uma vez só.

Para uma implementação séria, leia Claude Skills e SKILL.md para Desenvolvedores e codifique suas fases como skills com pontos de controle de revisão explícitos. O SDD do Claude Code é a escolha certa quando você já vive no Claude Code, quer flexibilidade máxima e manterá o fluxo de trabalho por conta própria. Para a etapa de portão de revisão especificamente, subagentes do Claude Code podem executar uma passagem de revisão independente, com contexto isolado, no código gerado antes de você mesclar uma tarefa — um substituto leve para o papel de verificação que os Agent Hooks do Kiro fornecem nativamente.

Superpowers: Uma Versão Empacotada da Pilha de Skills DIY

Se criar essa pilha de skills manualmente parece exatamente o problema de disciplina sobre o qual a tabela acima alerta, Superpowers vale a pena olhar. É um pacote de skills de código aberto — brainstorming, writing-plans, subagent-driven-development, test-driven-development, requesting-code-review e um punhado de skills de suporte — distribuído como um plugin instalável em vez de algo que você escreve do zero. Ele ataca diretamente a limitação de que “a qualidade depende inteiramente da disciplina do autor”: as skills são acionadas automaticamente e são destinadas a serem fluxo de trabalho obrigatório, não sugestões opcionais que o agente pode pular.

O fluxo de trabalho que ele impõe mapeia de perto para o loop de cinco fases coberto no Fluxo de Trabalho de Desenvolvimento Orientado por Especificação de Requisitos para Código: o brainstorming refina uma ideia rascunhada em um documento de design revisado, o writing-plans o divide em pequenas tarefas verificáveis, o subagent-driven-development despacha um subagente novo por tarefa com uma revisão de dois estágios, e o test-driven-development impõe um rigoroso red-green-refactor antes que qualquer coisa seja considerada feita. Essa última parte é mais estrita do que a maioria das skills de SDD do Claude Code se preocupam em ser — o Superpowers explicitamente apaga código escrito antes que um teste falho existisse para ele.

Ao contrário de uma skill local no repositório que você escreve, o Superpowers não é exclusivo do Claude Code. Ele fornece manifestos de plugin para Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid e vários outros agentes, para que a mesma metodologia o siga entre frameworks em vez de viver em uma única pasta .claude/skills/. Isso o torna um meio-termo entre criar sua própria skill do Claude Code e adotar uma ferramenta mais pesada e específica de IDE como o Kiro: você obtém um loop opinativo e imposto sem abrir mão do seu editor ou se comprometer com o formato de especificação de um único fornecedor.

O Superpowers se encaixa em desenvolvedores que gostam da abordagem de skills do Claude Code em princípio, mas continuam deslizando de volta para a promptagem não estruturada porque nada força os portões de revisão. É um ajuste mais fraco se você já tem uma skill de SDD específica do projeto ajustada ao seu stack — nesse caso, você está trocando uma pequena quantidade de personalização por uma maior quantidade de cerimônia imposta.

BMAD, OpenSpec e Outros Fluxos de Trabalho

Nem toda equipe quer a árvore de artefatos do Spec Kit ou o IDE do Kiro. Duas alternativas aparecem constantemente em comparações de 2026.

OpenSpec (Fission AI) adota uma abordagem centrada em mudanças com menos arquivos gerados do que o Spec Kit. Benchmarks da comunidade relatam uso de tokens materialmente menor para tarefas comparáveis, ao custo de menos estrutura preliminar. O OpenSpec tende a vencer quando você está modificando uma base de código existente e quer especificações revisáveis sem uma fase de planejamento de 800 linhas. Ele compete com o Spec Kit em portabilidade mais do que com o Kiro em integração de IDE.

BMAD-METHOD (comunidade) empurra na direção oposta — fluxos de trabalho multiagente, baseados em papéis, que simulam personas de dono do produto, arquiteto, desenvolvedor e revisor. O BMAD pode ser poderoso em grandes esforços greenfield onde a separação explícita de papéis ajuda. Ele também é pesado. Equipes frequentemente relatam que a cerimônia só se paga quando a dor de coordenação já é aguda.

Tessl trata a especificação como a fonte literal do código gerado, marcando a saída como derivada e desencorajando edições manuais. Essa é a postura mais forte de “especificação como fonte” entre as ferramentas mainstream, mas o Tessl permanece em beta e carrega o maior lock-in de produto do grupo.

Spec Kitty e outros scaffolds da comunidade ficam entre o OpenSpec e o Spec Kit em peso. Valem a pena ser observados se você quer modelos sem adotar a toolchain completa do GitHub.

O padrão entre todos eles é o mesmo. Mais processo ajuda quando a ambiguidade é cara. Mais processo prejudica quando a velocidade de feedback importa mais do que o alinhamento. Combine o peso da ferramenta com o tamanho da tarefa, não com o hype.

Qual Configuração de SDD Você Deve Usar?

Não há um vencedor universal. A configuração certa depende de quem você é, o que você está construindo e quanta estrutura você realmente manterá.

Desenvolvedor solo, base de código existente, recursos pequenos. Comece com skills do Claude Code ou OpenSpec. Escreva um bloco curto de requisitos, uma lista de tarefas mínima e um ponto de controle de revisão. Não instale uma árvore completa do Spec Kit para uma mudança de cinquenta linhas.

Quer a abordagem de skills do Claude Code, mas continua pulando seus próprios portões de revisão. Instale o Superpowers em vez de escrever uma skill personalizada do zero. Você abre mão de alguns ajustes específicos do projeto em troca de um loop imposto de brainstorm-planejar-implementar-revisar que não depende da sua disciplina naquele dia.

Desenvolvedor solo, recurso greenfield, múltiplas sessões. Spec Kit ou uma skill de SDD do Claude Code bem mantida. Você precisa de artefatos duráveis mais do que de mão na roda de IDE.

Equipe pequena, editores misturados. Spec Kit. Especificações em markdown simples no Git, revisadas em pull requests, executadas por aquele agente que cada desenvolvedor preferir.

Equipe empresarial, nativa AWS, pressão de conformidade. Kiro. Artefatos guiados, rastreabilidade de requisitos e hooks que mantêm documentos e testes mais próximos da implementação.

Ambiente regulado. Kiro ou Spec Kit mais sua própria lista de verificação de validação — não apenas skills do Claude Code, a menos que você codifique portões de conformidade explicitamente. Ferramentas não substituem trilhas de auditoria. Elas apenas as tornam mais fáceis de produzir.

Base de código existente, mudança brownfield. OpenSpec ou um fluxo de trabalho leve do Claude Code. A cerimônia completa do Spec Kit em cada correção de bug parecerá waterfall. Reserve estruturas mais pesadas para recursos transversais.

Produto greenfield, muitos agentes. Spec Kit. Portabilidade importa mais do que polimento de IDE quando Copilot, Claude Code e Cursor podem todos tocar no mesmo repositório.

Equipes experimentando orquestração multiagente também devem olhar para Oh My OpenCode Agents para padrões de divisão de papéis entre agentes — complementar a artefatos de SDD, não um substituto para eles.

Tabela de Decisão Prática

O Que Realmente Determina o Sucesso

A escolha da ferramenta importa menos do que a qualidade do artefato. Um arquivo de requisitos do Kiro com critérios de aceitação vagos produzirá o mesmo desvio do que um prompt descuidado do Claude Code. Um plano do Spec Kit que lista cinquenta tarefas redundantes parecerá waterfall, independentemente de qual agente o implemente.

As práticas que viajam entre todas as configurações são chatas e efetivas. Mantenha as especificações pequenas o suficiente para serem revisadas em uma sentada. Escreva não-objetivos explicitamente. Divida tarefas em diffs que um humano pode ler. Valide contra critérios de aceitação antes da mesclagem. Atualize a especificação quando a implementação descobrir um caminho melhor.

Se você ainda está escolhendo entre SDD e promptagem não estruturada para um recurso específico, leia Desenvolvimento Orientado por Especificação vs Codificação por Intuição. A comparação de ferramentas neste artigo só importa depois que você tiver decidido que o recurso merece uma especificação.

Especificações ruins tornam todos os agentes piores. Boas especificações viajam entre ferramentas.

Conclusão

O GitHub Spec Kit, o Kiro e os fluxos de trabalho do Claude Code são três respostas à mesma pergunta — como manter agentes de IA alinhados entre sessões — com apostas diferentes em portabilidade versus integração. O Spec Kit otimiza para markdown agnóstico de agentes no seu repositório. O Kiro otimiza para um IDE nativo em especificação guiado com agentes baseados em AWS. As skills do Claude Code otimizam para fluxos de trabalho leves e modificáveis que só têm sucesso quando você as mantém.

Escolha a configuração mais rasa que ainda remova a ambiguidade para o recurso em questão. Adicione estrutura quando a dor de coordenação aparecer, e não quando um post de blog disser para você. Os desenvolvedores que obtêm valor do SDD em 2026 não são aqueles com a toolchain mais elaborada. São aqueles que escrevem especificações dignas de implementação — e então deixam aquela ferramenta que escolheram executar contra elas.

Links Úteis

• Documentação do GitHub Spec Kit – referência oficial do fluxo de trabalho do Spec Kit
• Superpowers Quickstart: Instalação, Fluxo de Trabalho e Teste – pacote de skills de código aberto que impõe uma metodologia de brainstorm para TDD entre Claude Code, Cursor, Codex e outros agentes
• Martin Fowler sobre ferramentas de SDD – análise do Kiro, Spec Kit e Tessl