GitHub Spec Kit vs Kiro vs Fluxos de Trabalho SDD do Claude Code

Desenvolvedores que comparam configurações de Desenvolvimento Orientado por Especificação (SDD) em 2026 geralmente não perguntam qual modelo é o mais inteligente. Eles perguntam qual fluxo de trabalho manterá um agente de IA alinhado sem soterrar a equipe em burocracia.

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

Se você precisa dos conceitos primeiro, 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 de Arquitetura de Aplicação. Esta comparação está no hub de Ferramentas de Desenvolvimento com IA ao lado de revisões de assistentes e guias de fluxo de trabalho. Ela aborda as três configurações sobre as quais os desenvolvedores mais debatem no Hacker News e em fóruns estilo Reddit, além das alternativas mais leves e mais pesadas que orbitam ao seu redor.

O SDD Está se Tornando uma Categoria de Ferramentas

O Desenvolvimento Orientado por Especificação (SDD) deixou de ser um exercício teórico em meados de 2025. Cada grande fornecedor de IA para codificação agora lança alguma versão de especificar-planejar-implementar, e uma lista crescente de ferramentas independentes compete em quanto estrutura elas 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 hackeáveis. Especificações ruins tornam todo agente pior, independentemente do wrapper que você escolher. Especificações boas viajam entre 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 quanta revisão você precisa.

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

Fricção de configuração – Quanto tempo leva de “quero experimentar SDD” para um loop funcional de especificar-planejar-tarefas? Scaffolding de CLI, instalação de IDE ou criar seus próprios comandos de barra斜 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 rodar em paralelo? Ela resiste a explosões de listas de cinquenta itens?

Pontos de verificação de revisão – Existem gates humanos naturais entre especificar, planejar, tarefas e implementar? SDD sem revisão é apenas vibe coding mais lento.

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 a arquitetura porque nunca veem a intenção revisada por trás de escolhas anteriores.

Colaboração em equipe – Múltiplas 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 cloud em seis meses?

GitHub Spec Kit

GitHub Spec Kit é um toolkit CLI de código aberto que faz scaffolding de um loop orientado por especificação em seu repositório e entrega a execução para o agente de codificação que você já usa. O CLI specify dropa templates, comandos de barra斜 e um layout de pastas convencional. Comandos típicos seguem uma sequência constituição-especificar-esclarecer-planejar-tarefas-implementar, com uma etapa explícita de esclarecer para resolver ambiguidades antes que o trabalho de arquitetura comece.

A vantagem definidora do Spec Kit é a independência de agente. Os docs oficiais o posicionam como 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, comita-as como código e troca o executor sem reescrever o processo. Isso faz do 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 compensa em funcionalidades multi-sessão, mas parece pesado para um pequeno ajuste de CLI. Threads do Hacker News regularmente comparam essa sobrecarga à cerimônia de waterfall. O Spec Kit também é mais fraco se você quiser um IDE totalmente integrado onde especificações, tarefas e implementação vivam em uma superfície guiada. Ele camada processo sobre 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 SDD padrão por cima. Ele é especialmente forte para funcionalidades greenfield, shops multi-agente e qualquer um que recuse lock-in de editor.

AWS Kiro

Kiro é o IDE orientado por especificação da AWS, construído sobre um fork do VS Code / Code OSS. Onde o Spec Kit traz SDD para 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 agentes escrevam código de produção.

A experiência guiada é o principal argumento 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 um CLI separado. O Kiro também entrega Agent Hooks, automações acionadas por eventos que podem atualizar testes, docs 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 profundidade de integration trocada por portabilidade. O Kiro roda dentro de seu editor, usa modelos backed pelo AWS Bedrock e cobra através de um modelo de preço baseado em créditos com planos em camadas. Equipes enterprise já na infraestrutura da AWS frequentemente acham isso aceitável. Desenvolvedores solo e equipes com múltiplos editores talvez não. O Kiro também tem arestas ásperas típicas de um IDE mais novo — compatibilidade de extensões, surpresas de fluxo de trabalho e a usual pergunta “eu realmente preciso de outro editor?”.

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

Claude Code Comandos Personalizados e Skills

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

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

A desvantagem é disciplina. Nada te força a passar por gates de esclarecer ou revisar a menos que você construa esses gates você mesmo. Threads do Reddit e Hacker News sobre “desenvolvimento orientado por especificação dentro do Claude Code” estão cheios de desenvolvedores que copiaram a skill de alguém, rodaram uma vez e voltaram para prompting não estruturado quando a skill parecia lenta. O SDD do Claude Code funciona quando você trata skills como código — versionado, revisado e mantido — não como um download de prompt de uso único.

Para uma implementação séria, leia Claude Skills e SKILL.md para Desenvolvedores e codifique suas fases como skills com checkpoints 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 você mesmo.

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 reportam uso de tokens materialmente menor para tarefas comparáveis, à custa 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.

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

Tessl trata a especificação como a fonte literal de 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 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. Eles valem a pena observar se você quer templates sem adotar o toolchain completo do GitHub.

O padrão em 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 quanto 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 minimalista e um checkpoint de revisão. Não instale uma árvore completa do Spec Kit para uma mudança de cinquenta linhas.

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

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

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

Ambiente regulado. Kiro ou Spec Kit mais sua própria checklist de validação — não apenas skills do Claude Code a menos que você codifique gates de compliance explicitamente. Tooling não substitui trilhas de auditoria. Ele apenas torna mais fácil produzi-las.

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 bugfix parecerá waterfall. Reserve estrutura mais pesada para funcionalidades cross-cutting.

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

Equipes experimentando com orquestração multi-agente também devem olhar para Oh My OpenCode Agents para padrões em dividir papéis entre agentes — complementar a artefatos SDD, não uma substituição para eles.

Tabela de Decisão Prática

O Que Determina Realmente 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 drift que um prompt do Claude Code descuidado. Um plano do Spec Kit que lista cinquenta tarefas redundantes parecerá waterfall independentemente de qual agente o implementa.

As práticas que viajam através de cada configuração são entediantes e eficazes. Mantenha especificações pequenas o suficiente para revisar em uma sentada. Escreva não-objetivos explicitamente. Divida tarefas em diffs que um humano possa ler. Valide contra critérios de aceitação antes do merge. 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 Vibe Coding. A comparação de ferramentas neste artigo só importa uma vez que você decidiu que a funcionalidade merece uma especificação.

Especificações ruins tornam todo agente pior. Especificações boas viajam entre ferramentas.

Conclusão

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

Escolha o setup mais raso que ainda remova ambiguidade para a funcionalidade em questão. Adicione estrutura quando a dor de coordenação aparecer, não quando um post de blog lhe disser para fazer isso. Os desenvolvedores que obtêm valor do SDD em 2026 não são aqueles com o toolchain mais elaborado. Eles são aqueles que escrevem especificações que valem a pena implementar — e então deixam qualquer ferramenta que escolheram executar contra elas.

Links Úteis

• Documentação do GitHub Spec Kit – referência oficial do fluxo de trabalho do Spec Kit
• Martin Fowler sobre ferramentas SDD – análise de Kiro, Spec Kit e Tessl