GitHub Spec Kit vs Kiro vs Fluxos de Trabalho 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 sepultá-los em cerimônias excessivas.

GitHub Spec Kit, AWS Kiro e fluxos de trabalho personalizados do Claude Code implementam todos a mesma ideia geral — requisitos, design, tarefas, implementação, validação — mas fazem trocas em relação à portabilidade, à profundidade de integração e à quantidade de processo que impõem.

Se você precisa primeiro dos conceitos, leia O que é Desenvolvimento Orientado por Especificação? e o guia neutro a ferramentas do Fluxo de Trabalho de Desenvolvimento Orientado por Especificação no cluster de documentação de Arquitetura de Aplicativos. Esta comparação está localizada no hub de Ferramentas de IA para Desenvolvedores, junto com 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 apenas um exercício teórico em algum momento no final de 2025. Cada grande fornecedor de IA para codificação agora entrega alguma versão do ciclo especificar-planejar-implementar, e uma lista crescente de ferramentas independentes compete com base na quantidade de estrutura que adicionam ao redor desse ciclo.

A comparação que importa não é “qual ferramenta vence”. É profundidade de processo versus portabilidade. Kiro é integrado. Spec Kit é portátil. Fluxos de trabalho do Claude Code são modificáveis (hackáveis). Especificações ruins pioram todos os agentes, independentemente de qual wrapper você escolha. Boas especificações atravessam ferramentas.

Como Comparar Configurações de SDD

Antes de escolher uma ferramenta, nomeie o que você está otimizando. A mesma funcionalidade pode parecer fácil em uma configuração e burocrática em outra, dependendo do tamanho da equipe, da idade da base de código e de quanto controle (review) 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 elas estão ligadas a um único IDE, a uma única nuvem ou a um formato proprietário?

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

Qualidade da especificação – A ferramenta ajuda você a escrever requisitos e critérios de aceite precisos, ou ela gera principalmente 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 tarefas com cinquenta itens?

Pontos de controle de revisão – Existem portas humanas naturais entre especificar, planejar, tarefas e implementar? SDD sem revisão é apenas codificação por vibe mais lenta.

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

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

Dependência (Lock-in) – O que você perde se trocar de editor, modelos ou fornecedores de nuvem em seis meses?

GitHub Spec Kit

GitHub Spec Kit é um toolkit de CLI de código aberto que estrutura um ciclo orientado por especificação no seu repositório e entrega a execução a qualquer agente de codificação que você já use. O CLI specify cria modelos, comandos de barra e uma estrutura de pastas convencional. Os comandos típicos seguem uma sequência constituição-especificar-esclarecer-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 do agente. 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 commita 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.

As desvantagens 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 funcionalidades multi-sessão, mas parece pesado para um pequeno ajuste em CLI. Threads no Hacker News regularmente comparam essa sobrecarga com a cerimônia do waterfall. O Spec Kit também é mais fraco se você quer 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 por IA preferido e querem um andaime SDD padronizado por cima. Ele é especialmente forte para funcionalidades greenfield, empresas multi-agente e qualquer pessoa que se recusa a depender de um editor específico.

AWS Kiro

Kiro é o IDE orientado por especificação da AWS, construído sobre um fork do VS Code / Code OSS. Enquanto o Spec Kit traz o SDD para o seu stack existente, o Kiro assume que o SDD merece um ambiente feito sob medida. 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 entrega Agent Hooks, automações orientadas a eventos que podem atualizar testes, documentos ou artefatos relacionados quando a implementação muda. Esse ciclo bidirecional é algo que o Spec Kit não oferece nativamente — as especificações do Spec Kit permanecem estáticas até que um humano as atualize.

Os custos são a profundidade de integrada 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. O Kiro também tem bordas á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 de 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 hoje no VS Code e ama sua configuração atual, o Kiro pede uma troca maior do que o Spec Kit.

Comandos Personalizados e Skills do Claude Code

O Claude Code não entrega um único produto oficial de SDD da forma como o Spec Kit ou o Kiro fazem. Se você é novo na ferramenta em si, comece com o [guia de instalação e configuração do Claude Code](https://www.glukhov.org/pt/ai-devtools/claude-code/ “Instalação e configuração do Claude Code para Ollama, llama.cpp, preços”}) para configuração, permissões e backends locais. O próprio padrão de SDD vive em comandos personalizados, skills e modelos de markdown locais ao repositório que os desenvolvedores mantêm. A Anthropic integrou os antigos arquivos .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 mais modificável (hackável). Você pode portar um layout de três arquivos estilo Kiro, espelhar as fases do Spec Kit com comandos de barra, 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 busca skills quando a tarefa coincide. Essa revelação progressiva mantém sessões focadas sem carregar uma constituição completa em cada prompt.

A desvantagem é a disciplina. Nada força você através de portas de esclarecimento ou revisão, a menos que você construa essas portas você mesmo. 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 o prompting estrutural quando a skill parecia lenta. O SDD no 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.

Para uma implementação séria, leia [Claude Skills e SKILL.md para Desenvolvedores](https://www.glukhov.org/pt/ai-devtools/claude-code/claude-skills-for-developers/ “Claude Skills e SKILL.md para Desenvolvedores”}) e codifique suas fases como skills com pontos de controle de revisão explícitos. O SDD no Claude Code é a escolha certa quando você já vive no Claude Code, quer flexibilidade máxima e manterá o fluxo de trabalho você mesmo. Para a etapa de porta de revisão especificamente, [subagentes do Claude Code](https://www.glukhov.org/pt/ai-devtools/claude-code/claude-code-subagents/ “Como os subagentes do Claude Code funcionam: contexto isolado, roteamento de modelos, configuração .claude/agents, o fluxo Explore-Plan-Execute e erros a evitar.”}) 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 Stack de Skills DIY

Se montar manualmente aquela stack de skills soa exatamente como o problema de disciplina que a tabela acima alerta, Superpowers vale a pena uma olhada. É um pacote de skills de código aberto — brainstorming, escrita de planos, desenvolvimento dirigido por subagentes, desenvolvimento orientado a testes, solicitação de revisão de código e um punhado de skills de apoio — 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 têm a intenção de 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 o ciclo de cinco fases coberto no Fluxo de Trabalho de Desenvolvimento Orientado por Especificação dos Requisitos ao Código: o brainstorming refina uma ideia rascunhada em um documento de design revisado, a escrita de planos o divide em pequenas tarefas verificáveis, o desenvolvimento dirigido por subagentes despacha um subagente novo por tarefa com uma revisão de duas etapas, e o desenvolvimento orientado a testes impõe um rigoroso vermelho-verde-refatorar antes que qualquer coisa seja considerada pronta. Essa última parte é mais rígida 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.

Diferente de uma skill local ao repositório que você escreve você mesmo, o Superpowers não é exclusivo do Claude Code. Ele entrega manifests de plugins para Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI, Devin, Factory Droid e vários outros agentes, então a mesma metodologia segue você entre diferentes suportes (harnesses) 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 ciclo opinado 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 o prompting estrutural porque nada força as portas de revisão. É um encaixe 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 nas 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 um uso de materialmente menor de tokens para tarefas comparáveis, ao custo de menos estrutura antecipada. 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. Veja o [introdução do OpenSpec](https://www.glukhov.org/pt/ai-devtools/openspec/ “Introdução ao OpenSpec: Instalação, Fluxo de Trabalho e Armadilhas Comuns”}) para os passos de instalação, o ciclo explorar-propor-aplicar-arquivar e as armadilhas que aparecem mais frequentemente no Reddit.

BMAD-METHOD (comunidade) empurra na direção oposta — fluxos de trabalho multi-agente, baseados em papéis, que simulam personas de dono de 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 a maior dependência de produto do grupo.

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

gstack vai um passo além da camada de especificação: ele envolve o agente de codificação em uma equipe virtual de engenharia completa — revisão de produto, revisão de arquitetura e design, QA de navegador, auditorias de segurança e a cadeia de liberação/deploy — para que a especificação seja um dos vários estágios impostos em vez da espinha dorsal. Ele roda no Claude Code e em outros nove agentes, e o guia cobre como deixar o Spec Kit (ou OpenSpec) possuir a espinha dorsal do planejamento enquanto o gstack fornece as camadas que uma ferramenta de especificação não impõe.

O padrão através de 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. Alinhe o peso da ferramenta ao tamanho da tarefa, não ao 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, pequenas funcionalidades. Comece com skills do Claude Code ou OpenSpec. Escreva um bloco de requisitos curto, 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 suas próprias portas de revisão. Instale o Superpowers em vez de escrever uma skill personalizada do zero. Você abre mão de alguma ajuste específico do projeto em troca de um ciclo imposto de brainstorm-planejar-implementar-revisar que não depende da sua disciplina naquele dia.

Desenvolvedor solo, funcionalidade 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 ajuda da IDE.

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

Equipe empresarial, nativa da 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 regulamentado. 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 portas 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 estrutura mais pesada para funcionalidades transversais.

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

Equipes experimentando com orquestração multi-agente devem também olhar para [Oh My OpenCode Agents](https://www.glukhov.org/pt/ai-devtools/opencode/oh-my-opencode-agents/ “Oh My OpenCode Agents”}) para padrões de dividir papéis entre agentes — complementar a artefatos de SDD, não um substituto para eles. Se a sua equipe executa um agente terminal-first em vez de um integrado a um IDE, o [guia prático do OpenCode CLI](https://www.glukhov.org/pt/ai-devtools/opencode/opencode-cli-in-practice/ “Um guia prático para OpenCode a partir da linha de comando: opencode run, scripting, automação CI, agentes, permissões, modelos locais e modos de falha reais.”}) mostra a versão mais leve, em nível de prompt, da mesma disciplina de planejar-antes-de-implementar — útil quando uma árvore completa do Spec Kit é mais cerimônia do que a tarefa merece.

Tabela de Decisão Prática

O Que Realmente Determina o Sucesso

A escolha da ferramenta importa menos do que a qualidade dos artefatos. Um arquivo de requisitos do Kiro com critérios de aceite vagos produzirá a mesma divergência 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 atravessam todas as configurações são chatas e eficazes. Mantenha especificações pequenas o suficiente para serem revisadas em uma única sentada. Escreva não-objetivos explicitamente. Divida tarefas em diferenciais (diffs) que um humano possa ler. Valide contra critérios de aceite antes da mesclagem. Atualize a especificação quando a implementação descobrir um caminho melhor.

Se você ainda está escolhendo entre SDD e prompting não estruturado para uma dada funcionalidade, leia Desenvolvimento Orientado por Especificação vs Codificação por Vibe. A comparação de ferramentas neste artigo só importa depois que você decidiu que a funcionalidade merece uma especificação.

Especificações ruins pioram todos os agentes. Boas especificações atravessam ferramentas.

Conclusão

GitHub Spec Kit, Kiro e 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 ao agente no seu repositório. O Kiro otimiza para um IDE nativo de especificação guiado com agentes baseados em AWS. As skills do Claude Code otimizam para fluxos de trabalho modificáveis e leves que só têm sucesso quando você as mantém.

Escolha a configuração mais rasa que ainda remova ambiguidade para a funcionalidade em questão. Adicione estrutura quando a dor de coordenação aparecer, e não quando um post de blog lhe diz para isso. Os desenvolvedores que obtêm valor do SDD em 2026 não são os que têm a toolchain mais elaborada. São os que escrevem especificações que valem a implementação — e depois deixam a ferramenta que escolheram executar contra elas.

Links Úteis

• Documentação do GitHub Spec Kit – referência oficial do fluxo de trabalho do Spec Kit
• Introdução ao Superpowers: 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
• gstack: Um Stack Opinado de Engenharia de Software com IA – a opção de equipe virtual de engenharia completa, e como ele se combina com Spec Kit, OpenSpec e Superpowers
• Martin Fowler sobre ferramentas de SDD – análise de Kiro, Spec Kit e Tessl