Spec Kit vs OpenSpec: qual combina com o seu fluxo de código com IA

Spec Kit e OpenSpec são ferramentas de código aberto com licença MIT que miram o mesmo problema: quando os requisitos existem só no histórico do chat, o resultado de um assistente de código de IA é difícil de prever; por isso a especificação é escrita e humano e IA chegam a um acordo antes de qualquer código. Eles diferem no peso do processo, na forma de organizar as especificações e na cadeia de ferramentas.

Nossa posição primeiro

O fluxo de trabalho do próprio HagiCode é baseado no OpenSpec, então temos um viés. Os fatos abaixo vêm da documentação oficial dos dois projetos, verificada em 2026-10-26, e o que for opinião nossa está identificado como tal. Os dois projetos evoluem rápido; leia a documentação mais recente de cada um antes de escolher.

O que está sendo comparado

• Spec Kit: do GitHub. A linha de comando é specify (o pacote Python specify-cli); veja Como instalar o Spec Kit para instalação e uso.
• OpenSpec: da Fission AI. A linha de comando é openspec (o pacote npm @fission-ai/openspec); veja a Introdução ao OpenSpec.

Principais diferenças

Dimensão	Spec Kit	OpenSpec
Ambiente de execução	Python 3.11+, instalado com uv ou pipx	Node.js 20.19.0+, instalado com npm ou Homebrew
Comando de instalação	uv tool install specify-cli	npm install -g @fission-ai/openspec@latest
Inicialização	specify init my-project --integration claude	openspec init dentro do projeto
Prefixo dos comandos	/speckit-*	/opsx:* (/opsx-* em alguns assistentes, $openspec-* no Codex)
Fluxo principal	constitution → specify → clarify → plan → checklist → tasks → analyze → implement → converge; o caminho mais curto é specify → plan → tasks → implement → converge	O perfil padrão tem propose, explore, apply, update, sync e archive; o perfil expandido acrescenta new, continue, ff, verify e outros
Artefatos por funcionalidade	spec.md, plan.md, tasks.md, além de checklists e resultados de análise	Uma pasta de mudança com proposal.md, specs/, design.md e tasks.md
Como as especificações são organizadas	Uma especificação completa escrita em torno de uma única funcionalidade	Construído em torno de especificações delta: ADDED e MODIFIED descrevem a mudança e são mescladas às especificações duradouras ao arquivar
Extensibilidade	Extensões e presets; entre as oficiais estão bug e assess	Schemas personalizados e schemas da comunidade
Vários repositórios	Não encontramos suporte dedicado a vários repositórios no fluxo principal da documentação oficial	O Stores (beta) mantém o planejamento em um repositório próprio e o compartilha entre repositórios de código
Assistentes com suporte	A documentação oficial lista dezenas de integrações	A documentação oficial diz que são mais de 30 ferramentas
Licença	MIT	MIT

Peso do processo: a diferença mais citada

O README do OpenSpec resume o Spec Kit como completo, porém pesado, com portões de fase rígidos, muito Markdown e uma configuração em Python, e se posiciona como mais leve, permitindo revisar qualquer artefato a qualquer momento. Essa é a descrição do próprio OpenSpec.

Para ser justo: o início rápido do próprio Spec Kit apresenta um caminho mais curto de cinco etapas em que constitution, clarify, checklist e analyze são opcionais, e o perfil expandido do OpenSpec também tem bastante comando. A diferença real não é a quantidade de comandos, e sim a postura padrão. O Spec Kit se parece mais com um pipeline que vai da especificação à implementação e converge no final, enquanto o OpenSpec enfatiza que cada mudança é uma pasta independente que pode ser editada a qualquer momento.

Escolha por cenário

As orientações abaixo são um julgamento nosso, não uma conclusão oficial de nenhum dos projetos.

Sua situação	Melhor opção	Por quê
Um projeto novo, com vontade de um fluxo completo da especificação à implementação	Spec Kit	Um fluxo completo, uma constitution que orienta todo o projeto e o converge para fechar o ciclo em relação à especificação
Muito código existente, com mudanças pequenas a cada vez	OpenSpec	As especificações delta descrevem só o que muda, sem precisar reescrever uma especificação completa das funcionalidades existentes
Uma equipe majoritariamente Python e habituada ao uv	Spec Kit	O método de instalação combina com a stack
Uma equipe majoritariamente Node.js	OpenSpec	Um único comando npm instala
Uma funcionalidade mexe em vários repositórios	OpenSpec	O Stores pode manter o plano em um repositório compartilhado; note que ainda está em beta
Você quer muitas extensões prontas (correção de bugs, avaliação de ideias)	Spec Kit	O site oficial lista mais extensões e presets
Os requisitos mudam com frequência e você quer editar especificações e planos a qualquer momento	OpenSpec	Os artefatos não têm fases rígidas, então dá para voltar e editar

Orientações para decidir

1. Olhe a sua stack e os seus hábitos antes das funcionalidades. As duas se sobrepõem bastante em capacidade, e o atrito de um ambiente incompatível costuma pesar mais.
2. Rode cada uma na mesma funcionalidade pequena. Escolha um requisito que leve meio dia e percorra o fluxo completo com cada uma. Isso é mais confiável do que ler dez artigos de comparação.
3. Não instale as duas no mesmo projeto. As duas ferramentas geram comandos e diretórios no projeto, e misturá-las bagunça a lista de comandos do seu assistente.
4. Avalie por três pontos: se escrever a especificação realmente reduziu o retrabalho, se o seu assistente de IA tem suporte oficial e se a equipe está disposta a manter esses arquivos Markdown.

Como o HagiCode faz

Usamos o OpenSpec há bastante tempo e construímos em torno dele o gerenciamento de especificações em vários repositórios e a escolha de um Agent por etapa, descritos nestes dois artigos: Otimizando a eficácia de cada etapa do OpenSpec com diferentes Agentes: resumo da prática do HagiCode e O que é MonoSpecs: por que é uma atualização e extensão do OpenSpec. Essa é a nossa escolha e não significa que seja melhor para todas as equipes. Se o Spec Kit combina mais com a sua, ele funciona igualmente bem com os Agent CLI que o HagiCode suporta, como Claude Code e Codex; veja Instalação dos AI Agent CLI para a preparação.

Caminho recomendado

• Para experimentar rápido: escolha a que combina com a sua stack, instale e percorra só o caminho mais curto em uma funcionalidade pequena.
• Para comparar com seriedade: siga o ponto 2 acima com as duas e decida por “quantidade de retrabalho” e “aceitação da equipe”.
• Para se aprofundar: leia Como instalar o Spec Kit e a Introdução ao OpenSpec.