Review do OpenSpec: meu novo daily driver para AI coding

Review do OpenSpec: meu novo daily driver para AI coding

A primeira vez que executei openspec apply em um projeto real, afastei-me para reabastecer meu café e esqueci dele. Duas horas e dezessete minutos depois, voltei a um painel funcional, um conjunto de testes aprovado e uma pasta changes/ cheia de descontos que explicavam — com um nível de detalhe que eu nunca teria escrito à mão — exatamente o que tinha acabado de ser construído e por quê.

Essa não é a parte impressionante. A parte impressionante é o que aconteceu na manhã seguinte, quando precisei adicionar um segundo recurso. Não abri o código. Abri a pasta de especificações. Eu li três pequenos arquivos de redução. E eu sabia, com uma espécie de clareza que normalmente só obtenho após uma semana de carregamento de contexto, exatamente onde o novo recurso deveria se conectar e o que tocaria.

Foi nesse momento que entendi o que o OpenSpec AI coding framework está realmente fazendo - e por que acho que é a primeira ferramenta spec-driven que sobrevive ao contato com meu fluxo de trabalho real.

Estou executando-o como meu driver diário há duas semanas em três projetos: uma ferramenta de administração Laravel que estou refatorando para um cliente, um projeto paralelo Next.js que comecei do zero e uma base de código Python existente que herdei e que tem aproximadamente a higiene da documentação de uma nota de refém. OpenSpec conquistou seu lugar em todos os três. Mas não pelos motivos listados nas páginas de marketing.

Este é o detalhamento completo - o que é OpenSpec, onde ele se encontra no cenário AI coding framework, os comandos exatos que executo e os lugares honestos onde ele não ajuda. Se você já gastou horas assistindo uma sessão Claude Code gerar código em uma especificação que estava errada desde o início, as próximas 4.000 palavras parecerão pessoais.

As três categorias de estruturas de AI coding (e por que isso é importante)

Antes que OpenSpec faça sentido, você precisa do mapa do território em que ele vive. Cometi esse erro na primeira vez que o avaliei - comparei-o com ferramentas que ele nunca tentou vencer e quase o descartei pelos motivos errados.

Existem três categorias distintas de AI coding frameworks enviadas em 2026 e elas resolvem problemas diferentes:

Essas categorias não competem frente a frente. Eles empilham.

Uma pilha de produção real se parece mais com: OpenSpec escreve a especificação, Obra Superpowers impõe TDD durante a construção, BMAD orquestra o pipeline multi-agent que envia PRs enquanto você dorme. O mesmo problema de três ângulos. Diferentes camadas da mesma máquina.

Onde a maioria dos artigos "spec-driven vs autônomo" erram é tratá-los como alternativas. Eles não são. Eles são níveis. E OpenSpec é a camada inferior – aquela que decide no que as outras duas camadas trabalharão.

É por isso que acertar essa camada é mais importante do que as camadas acima dela. Uma habilidade perfeita de aplicação de TDD não salvará você se a especificação aplicada estiver errada no primeiro dia. Um pipeline autônomo que envia 40 PRs em um sprint simplesmente enviará 40 PRs errados. A qualidade das especificações é o ponto de estrangulamento upstream. Todo o resto amplifica qualquer decisão tomada ali – para melhor ou para pior.

Portanto, a questão não é "OpenSpec ou BMAD?" A questão é "OpenSpec é bom o suficiente para ser a fonte da verdade em que tudo o que está a jusante confia?" Foi isso que entrei para testar.

O que OpenSpec realmente é

OpenSpec é uma estrutura de desenvolvimento spec-driven de código aberto, enviada como o pacote npm @fission-ai/openspec e mantida pela Fission-AI. Ele é executado em qualquer projeto como uma camada fina sobre seu assistente de AI coding - Claude Code, Cursor, Codex, Windsurf, Continue, GitHub Copilot, Amazon Q e cerca de vinte outros, de acordo com o documento de ferramentas suportadas.

A ideia central é brutal em sua simplicidade. A especificação é o artefato. O código é o destino da compilação. Cada recurso reside em um arquivo markdown em seu repositório antes que uma única linha de código seja escrita, e esse arquivo se torna o contrato contra o qual os assistentes AI são executados.

Três coisas sobre essa ideia são mais importantes do que a ideia em si.

Primeiro, as especificações estão no seu repositório. Não em um painel SaaS. Não em um documento Notion que muda no momento em que alguém clica em "enviar". Em uma pasta openspec/, no git, com diffs você pode revisar nos PRs como qualquer outra alteração de código. Essa é a parte que a maioria das equipes subestima até precisar reconstruir o que um recurso deveria fazer seis meses depois. Com OpenSpec, você git log atende às especificações.

Segundo, as especificações são deltas. OpenSpec inventou algo que não vi bem feito em nenhum outro framework: a proposta não é um documento novo, é uma mudança em relação às especificações existentes. Cada proposta marca explicitamente adições, modificações e remoções. Quando a mudança for enviada, os deltas serão mesclados na especificação mestre. Esta é a mágica do brownfield - é como o OpenSpec permanece utilizável em bases de código legadas, em vez de forçá-lo a criar um aplicativo de 200.000 linhas para usá-lo.

Terceiro, o fluxo de trabalho é fluido, não em cascata. O enquadramento oficial do Fission-AI é "fluido, não rígido, iterativo, não em cascata" - e depois de duas semanas posso confirmar que isso não é marketing. Você pode entrar no fluxo de trabalho em qualquer fase, pode voltar quando a implementação revelar algo que a especificação perdeu e pode executar archive para confirmar uma alteração parcial e iniciar uma nova. Parece menos um processo e mais um caderno que reforça a estrutura.

A comparação mais clara é o Kit de especificações do GitHub. Eu testei ambos. O Spec Kit é mais pesado - suas especificações rodam em torno de 800 linhas por recurso de acordo com o trabalho de comparação publicado pelo Hashrocket, contra cerca de 250 do OpenSpec. O Spec Kit trata cada recurso como seu próprio arquivo independente. OpenSpec se consolida em uma única fonte viva de verdade que muda com o tempo. Para um recurso empresarial limpo e greenfield com portas de revisão formais, a produção mais pesada do Spec Kit é justificada. Para tudo o mais que faço - refatorações, projetos paralelos, trabalho de cliente de agência - a pegada mais leve do OpenSpec vence porque a especificação é algo que realmente relerei.

Essa é a camada filosófica. Veja como é a execução na prática.

Instalando OpenSpec e a experiência de primeira execução

A configuração é um comando. Não "um comando depois de instalar três dependências". Um comando.

npm install -g @fission-ai/openspec
cd your-project
openspec init

O nó 20.19.0 ou superior é necessário. O comando init pergunta qual assistente AI você está usando - eu escolhi Claude Code no projeto Laravel, Cursor no Next.js, Codex na base de código Python - e ele grava as ligações de comando de barra apropriadas na configuração do seu projeto para que o assistente saiba como invocar OpenSpec.

Foi aí que percebi a primeira coisa que me fez confiar na ferramenta. Em uma nova inicialização, OpenSpec não coloca você na frente de um documento em branco e diz “boa sorte”. Ele executa uma habilidade de integração que orienta você em sua primeira proposta de forma interativa. Ele pergunta o que você está construindo. Ele pergunta quem é o usuário. Ele pergunta quais são os critérios de sucesso. Ele faz isso no markdown que fica no seu repositório, então o primeiro artefato que você tem não é um tutorial - é o início de uma especificação real para um recurso real.

Compare isso com minha experiência começando com o Spec Kit. A integração do Spec Kit pressupõe que você já conhece o modelo de quatro fases (/specify, /plan, /tasks, /implement) e leva você direto para a etapa /specify. Se você nunca usou o desenvolvimento spec-driven antes, você escreve uma especificação com formato errado e descobre três comandos mais tarde, quando /tasks produz um absurdo.

A integração do OpenSpec é a diferença entre aprender lendo e aprender fazendo a coisa certa na primeira vez. É um pequeno detalhe. É também por isso que recomendei o OpenSpec a dois amigos que nunca haviam tocado no desenvolvimento do spec-driven antes.

A Referência de Comandos: O que cada um faz e quando eu uso

OpenSpec é fornecido com um conjunto de comandos base e um conjunto de comandos expandido chamado opsx, que você aceita por meio de openspec config profile. Estou usando o perfil expandido porque quero todas as ferramentas que o framework oferece. Aqui está a tabela completa, com o que eu realmente uso cada uma delas na produção:

| /openspec:apply | Implementar as tarefas definidas na proposta | A fase de construção - funciona aproximadamente 2 horas de forma autônoma, 3-4 horas com minhas interrupções | | /opsx:verify | Valide a implementação em relação às especificações, incluindo verificações visuais da IU por meio da integração do Chrome | Migrações de sistema de design, recursos com muita interface de usuário | | /openspec:archive | Mesclar os deltas de mudança na especificação mestre, comprometer a fonte viva da verdade | Todos os recursos enviados, sem exceções | | /opsx:bulk-archive | Arquivar várias alterações concluídas em uma única passagem | Fim de um sprint quando eu envio de 3 a 5 recursos | | /opsx:sync | Sincronize a pasta master specs com o que realmente está na base de código | Quando suspeito de desvio entre código e especificação | | /opsx:onboard | Execute novamente a habilidade de integração interativa | Trazendo um colega de equipe ou um novo projeto para o fluxo de trabalho OpenSpec |

A lista completa de comandos está no documento de comandos OpenSpec oficial, e a referência de perfil expandida está no documento opsx. O que não está nos documentos é a ordem em que os executo ou quais eu pulo – e essa é a próxima seção.

O fluxo de trabalho que eu realmente executo

Aqui está a sequência exata que segui ao enviar um recurso de "linha do tempo de atividade do usuário" para a ferramenta de administração do Laravel na semana passada. A coisa toda levou cerca de quatro horas de relógio de parede, das quais talvez quarenta minutos fui eu e o resto foi OpenSpec trabalhando em segundo plano.

Etapa 1: explore antes de propor

O primeiro comando que executo em qualquer alteração acima de "trivial" é /opsx:explore. Este é o recurso mais subestimado na estrutura e é a única coisa que o OpenSpec faz que o GitHub Spec Kit se recusa explicitamente a fazer.

O design do Spec Kit pressupõe que você entre no /specify já sabendo o que deseja construir. Essa suposição está errada cerca de 70% das vezes na minha experiência. O que normalmente tenho é uma ideia confusa, três restrições das quais me lembro parcialmente e um palpite de que há uma complicação que ainda não descobri. Se eu escrever uma especificação a partir desse estado, a especificação estará errada e descobrirei quatro etapas depois.

/opsx:explore me dá uma fase para errar em voz alta. O agente me faz perguntas esclarecedoras. Ele investiga a base de código. Revela ambigüidades que eu não sabia que existiam. No recurso de cronograma de atividades, a exploração detectou três coisas que eu teria perdido se tivesse pulado direto para uma proposta: a tabela de log de auditoria existente tinha uma ambigüidade de coluna que teria causado colisões de consulta, duas de minhas "ações do usuário" eram na verdade dois eventos diferentes que eu estava mentalmente colapsando, e o requisito da UI implicava um componente em tempo real que eu não tinha orçado.

São cerca de dois dias de retrabalho que a exploração evitou em quinze minutos.

Para ser sincero, quase nunca usei /opsx:explore nos primeiros três dias. Parecia uma sobrecarga. Então tentei em um refatorador que revelou ter uma dependência oculta em uma camada de cache obsoleta e não o pulei desde então. O padrão que internalizei: se não consigo explicar a mudança em uma frase sem qualificações, executo explore primeiro.

Etapa 2: propor, continuar ou avançar

Depois que a exploração dissipa a névoa, executo um dos três comandos, dependendo do tamanho da alteração:

• /openspec:propose para alterações pequenas e bem definidas, nas quais desejo que tudo seja gerado em uma única passagem.
• /opsx:continue para mudanças maiores, quero dividir em fatias verticais - primeiro a proposta, depois as especificações e depois as tarefas, com uma porta de revisão entre cada uma.
• /opsx:ff quando a exploração foi completa e eu quero que OpenSpec avance rapidamente pelas etapas restantes da proposta/spec/tasks sem me fazer clicar em cada portão.

A saída de qualquer um deles é a mesma: uma pasta changes/[change-name]/ contendo proposal.md (o porquê e o quê), design.md (o como, incluindo o design do sistema), um ou mais arquivos em specs/ (os cenários funcionais que atuam como o contrato) e tasks.md (a divisão do trabalho que o assistente executará).

Este é o momento do fluxo de trabalho em que a especificação deixa de ser minha e passa a ser da equipe. Mesmo que a equipe seja só eu. A proposta pode ser revisada em um PR. O design.md captura as decisões arquitetônicas em uma linguagem que um futuro pode entender. A pasta specs/ é a parte que o assistente AI tratará como contrato durante a implementação - e, principalmente, é a parte que sobrevive à mudança e se funde na especificação mestre no arquivo.

Uma observação sobre o que torna as especificações do OpenSpec diferentes. Cada especificação descreve cenários funcionais - narrativas de estilo dadas/when/then que descrevem o comportamento. Não detalhes de implementação. Não "o controlador chama o repositório". Comportamento. Esta é a forma que sobrevive às alterações da base de código. Quando eu refatorar a camada de persistência daqui a seis meses, a especificação ainda estará correta porque a especificação nunca foi sobre como a camada de persistência funcionava. Era sobre o que o usuário via e poderia fazer.

Etapa 3: Aplicar (ou: Como parei de assistir a compilação)

/openspec:apply é o comando que cria o recurso. É aqui que reside a maior parte do tempo de execução - cerca de duas horas de trabalho autônomo no recurso de linha do tempo de atividades, três a quatro horas quando estou interrompendo para esclarecer as coisas no meio da construção.

O que tive que aprender aqui é quando interromper e quando ir embora. Meu primeiro instinto foi cuidar da fase de aplicação como eu cuido de uma sessão Claude Code - ler cada comparação, aprovar cada alteração de arquivo, questionar cada decisão. Esse instinto está errado com OpenSpec. A especificação já codificou minhas decisões. A fase de aplicação consiste apenas na execução do contrato. Se eu quiser interromper para “fazer uma escolha diferente”, o movimento certo é quase sempre interromper a inscrição, voltar à proposta, corrigir as especificações e reaplicar.

Depois de internalizar isso, comecei a deixar a fase de aplicação em segundo plano enquanto trabalhava em outra coisa. Guia aberta, terminal visível, mas não estou olhando para ele. A primeira vez que fiz isso foi desconfortável. Na quinta vez, foi o padrão normal. Na décima vez, me peguei enviando dois recursos em paralelo executando apply em dois terminais em duas propostas diferentes.

Este é o momento que mudou meu modelo mental de AI coding. O gargalo deixou de ser a execução. Tornou-se qualidade de especificação. O que significa que meu tempo começou a ser destinado à parte do trabalho que realmente requer julgamento humano, e o resto foi transferido para o agente.

Etapa 4: verificar (o recurso assassino subestimado)

/opsx:verify é o comando sobre o qual ninguém fala e foi aquele que tornou OpenSpec insubstituível no projeto paralelo Next.js.

O projeto Next.js envolveu a migração de um sistema de design antigo para um novo – mesmos componentes, novos tokens, nova escala de espaçamento, nova tipografia. Esta é uma classe de trabalho de pesadelo para as ferramentas de AI coding porque o código pode ser tecnicamente correto e visualmente completamente errado. Um botão pode ser renderizado. Um botão também pode ser renderizado no tamanho errado, na fonte errada, com o raio da borda errado e passar em todos os testes que você escreveu.

/opsx:verify vem com uma integração de extensão do Chrome que faz verificações de fidelidade visual em relação às especificações. Ele carrega a página, captura o estado renderizado e o compara com a intenção de design codificada na especificação. Na migração do sistema de design, foram detectadas sete regressões visuais que o conjunto de testes não percebeu. Inconsistências de espaçamento. Peso de fonte incorreto em uma variante de título. Um componente que herdou uma margem do sistema antigo e estava transbordando de sua célula de grade em determinados pontos de interrupção.

Este é o recurso que não existe em nenhum outro AI coding framework que testei. O Spec Kit não tem isso. O BMAD não tem. Obra Superpowers pode garantir que você escreveu testes, mas não pode dizer que o teste foi aprovado enquanto a página parece errada. Para trabalhos pesados ​​de UI, especialmente migrações de sistemas de design, /opsx:verify é a diferença entre enviar e enviar corretamente.

A advertência honesta: não é mágica. A extensão do Chrome precisa do seu servidor de desenvolvimento em execução. As verificações visuais são tão boas quanto a intenção do design que você codificou nas especificações. E não consegue detectar bugs de interação – apenas problemas de renderização estática. Mas para a classe de bugs que ele detecta, nada mais o faz.

Etapa 5: Arquivar (o truque da documentação viva)

Esta é a etapa que quase pulei na primeira semana. É também a etapa que é silenciosamente a mais importante.

/openspec:archive pega a alteração que você acabou de enviar e mescla seus deltas na pasta mestre specs/. A proposta é movida para um diretório changes/archive/. A especificação mestre — a fonte viva da verdade — integra as novas funcionalidades, aplica as modificações e remove as remoções.

O resultado é que, após cada recurso enviado, seu repositório contém uma descrição atual, precisa e legível por máquina de como todo o sistema se comporta. Não é um README desatualizado. Não é uma página do Confluence que não seja tocada há dezoito meses. O estado atual real.

Testei o que isso significa seis dias depois de usar o OpenSpec, pedindo ao Claude Code para adicionar um novo recurso ao projeto Laravel - sem fornecer nenhum contexto. Eu disse: "leia openspec/specs/ e proponha uma mudança que adicione X." Ele leu as especificações. Ele propôs uma mudança que identificava corretamente dois recursos existentes com os quais seria necessário interagir. Ele fez isso sem nenhuma solicitação minha sobre a arquitetura da base de código, porque a arquitetura já estava nas especificações.

Esta é a primeira vez que vejo a "documentação viva" ser realmente uma parte de suporte de um fluxo de trabalho de AI coding, em vez de algo interessante. Na maioria dos projetos, você gasta os primeiros cinco minutos de cada sessão Claude Code recarregando o contexto. Com OpenSpec, o contexto é carregado sozinho.

Se archive parecer uma sobrecarga, posso prometer que não é. Ignorar o arquivo é como os projetos spec-driven apodrecem. Todas as equipes com quem conversei que abandonaram o desenvolvimento do spec-driven fizeram isso porque suas especificações divergiram do código. O arquivo é a disciplina que evita o desvio. Trate-o como parte do "recurso concluído", não como uma etapa opcional de limpeza.

Onde OpenSpec fica aquém (a seção honesta)

Estou há duas semanas e sou fã, mas um fã que executou isso em três projetos com formatos bem diferentes. É aqui que isso não ajuda.

Pequenas alterações. Se a alteração for "corrigir este erro de digitação" ou "renomear esta variável", o fluxo de trabalho OpenSpec estará sobrecarregado. Não faça uma proposta para uma solução de uma linha. A estrutura não finge o contrário - Fission-AI recomenda explicitamente contra isso - mas observei recém-chegados forçarem cada mudança no fluxo da proposta e acabarem com uma pasta changes/ que parece um cemitério de PRs triviais. Use OpenSpec para coisas que se beneficiam ao serem pensadas. Pule para coisas que não funcionam.

Sessões de codificação individuais em que você realmente não sabe o que quer. Se você estiver no modo puro de exploração — esboçando, prototipando, jogando código na parede — a fase de proposta irá atrasá-lo. O padrão certo aqui é codificar primeiro e, depois de saber o que construiu, escreva a especificação retroativamente e archive como a primeira proposta. OpenSpec está bem com esse fluxo. Mas tentar especificar algo que você ainda não projetou é o pior dos dois mundos.

O tempo de execução de aplicação de duas horas é real. A maioria das execuções de aplicação fica na faixa de 90 a 180 minutos para recursos não triviais. Se você precisa de um recurso enviado em vinte minutos, o OpenSpec não é a ferramenta certa. Isso não é uma falha — a qualidade da especificação é o que torna a fase de aplicação confiável, e essa qualidade leva tempo para ser codificada e executada. Mas gerencie suas expectativas. OpenSpec é uma ferramenta para envio certo, não rápido.

A integração do Brownfield tem arestas. Na base de código herdada do Python, minha primeira tentativa de apresentar o OpenSpec resultou em uma especificação mestre com cerca de 40% de precisão em relação ao código real. A estrutura estava tentando inferir especificações de código que não tinha nenhum princípio orientador, e as inferências eram necessariamente confusas. A correção estava executando o /opsx:onboard corretamente, demorando para escrever a especificação mestre manualmente para os fluxos principais e depois usando OpenSpec para novas alterações. Se você esperar colocar OpenSpec em uma base de código herdada e fazer com que ele entenda a base de código até sexta-feira, você ficará desapontado. Planeje uma semana de integração real.

A comunidade é pequena. Comparado à presença do GitHub da BMAD ou ao apoio empresarial do Spec Kit, o OpenSpec é o ecossistema menor. Os documentos são bons. A cadência de lançamento é saudável. Mas ainda não existe uma grande quantidade de tutoriais, plug-ins ou integrações de terceiros. Se precisar de algo que o framework não faz nativamente, você mesmo escreverá. Para mim, tudo bem - prefiro uma ferramenta pequena e focada do que uma grande e inchada - mas vale a pena conhecer.

Onde OpenSpec cabe na minha pilha agora

Depois de duas semanas, OpenSpec fica no topo do meu fluxo de trabalho de AI coding - acima de Claude Code, acima das habilidades do agente que executo, acima das notas de planejamento que costumava manter em Obsidian. É a primeira coisa que toco em uma mudança não trivial e a última coisa que toco ao enviá-la.

A pilha completa fica assim:

1. OpenSpec escreve e mantém as especificações — o contrato para o que está sendo construído
2. Claude Code com Obra Superpowers executa a especificação com aplicação de TDD durante a fase de aplicação
3. Revisão padrão do git captura o que o TDD perdeu
4. Arquivar bloqueia a mudança na especificação viva, pronta para a próxima iteração

Cada ferramenta faz o que é melhor. OpenSpec não tenta impor o TDD – esse é o trabalho dos Superpoderes. Superpowers não tenta gerenciar as especificações – esse é o trabalho do OpenSpec. Claude Code não tenta lembrar de tudo o que foi construído – esse é o trabalho do master spec.

Essa separação de preocupações é o que faz a pilha realmente escalar. Quando algo quebra, eu sei qual camada depurar. Quando quero atualizar uma peça, posso trocá-la sem reconstruir as outras. A composição é a vitória.

Você deve usar OpenSpec?

Três perguntas para responder honestamente:

Vocês enviam recursos que exigem mais de duas horas de trabalho concentrado? Se sim, o OpenSpec se paga pelo segundo recurso. Se você estiver enviando apenas micromudanças, ignore.

Você já voltou a um projeto depois de duas semanas e precisou recarregar o contexto? Se sim, a especificação viva vai economizar horas todos os meses. Se seus projetos estão todos atuais e sua memória está perfeita, o valor é menor.

Você confia mais em seu assistente AI quando ele tem um contrato claro para executar? Se sim, OpenSpec é a camada de contrato. Se você preferir apenas conversar com o assistente e orientar passo a passo, o fluxo da proposta parecerá um atrito.

Respondi sim a todos os três, e OpenSpec foi a adição mais importante ao meu fluxo de trabalho desde que comecei a usar o Claude Code. Não porque faça algo dramaticamente melhor do que as alternativas, mas porque torna todas as outras ferramentas da minha pilha mais confiáveis. A especificação é o ponto de estrangulamento upstream. OpenSpec limpou o ponto de estrangulamento.

Perguntas frequentes

Para que é usado o OpenSpec?

OpenSpec é uma estrutura de desenvolvimento spec-driven para assistentes de AI coding. Você escreve uma especificação de redução de um recurso e a estrutura se coordena com seu assistente AI (Claude Code, Cursor, Codex e mais de 20 outros) para implementar a especificação, validar o resultado e mesclar a mudança em uma fonte viva de verdade. Ele é usado mais intensamente para recursos de médio a grande porte em bases de código brownfield, onde a qualidade das especificações tem valor agregado.

Qual a diferença entre o OpenSpec e o kit de especificações GitHub?

O OpenSpec consolida as especificações em um único documento vivo com alterações baseadas em delta, enquanto o Spec Kit mantém arquivos de especificações separados por recurso. OpenSpec produz especificações mais leves (cerca de 250 linhas versus 800 do Spec Kit), suporta nativamente bases de código brownfield e oferece um fluxo de trabalho iterativo com a fase /opsx:explore. O modelo de quatro fases mais pesado do Spec Kit se adapta melhor ao trabalho empresarial formal e greenfield. Para uma análise mais profunda, consulte "O que OpenSpec realmente é" acima.

OpenSpec funciona com Claude Code?

Sim - Claude Code é um dos mais de 20 assistentes de AI coding suportados. Durante openspec init, você seleciona Claude Code como seu assistente e OpenSpec grava as ligações de comando de barra correspondentes em seu projeto. Cursor, Codex, Windsurf, Continue, GitHub Copilot, Amazon Q, Gemini CLI e outros também são totalmente suportados.

Quanto tempo leva uma execução de aplicação do OpenSpec?

Uma execução típica do openspec apply atinge a faixa de 90 a 180 minutos para recursos não triviais quando executada de forma autônoma. Adicionar pontos de verificação humanos e esclarecimentos no meio da construção estende isso para 3-4 horas de relógio de parede. Na maior parte do tempo, o assistente AI está funcionando, sem esperar – você pode deixá-lo funcionando em segundo plano enquanto trabalha em outra coisa.

O OpenSpec pode substituir BMAD ou Obra Superpowers?

Não, e você não deve tentar fazer isso. OpenSpec é uma estrutura spec-driven. BMAD é um orquestrador de pipeline autônomo. Obra Superpowers é uma camada de aplicação SDLC. Eles resolvem problemas diferentes e se empilham bem: OpenSpec escreve as especificações, Superpowers impõe TDD durante a construção, BMAD orquestra pipelines com vários recursos. Para uma análise completa dessas três categorias, consulte a tabela de comparação no início deste artigo.

Vamos trabalhar juntos

Procurando construir sistemas AI, automatizar fluxos de trabalho ou dimensionar sua infraestrutura tecnológica? Eu adoraria ajudar.

• Fiverr (compilações e integrações personalizadas): fiverr.com/s/EgxYmWD
• Portfólio: mejba.me
• Ramlit Limited (soluções empresariais): ramlit.com
• ColorPark (design e marca): colorpark.io
• xCyberSecurity (serviços de segurança): xcybersecurity.io