OpenSpec: rápido e simples
Continuando no processo de experimentar ferramentas que implementam SDD, dentro do nosso workflow, hoje iremos falar um pouco sobre OpenSpec. Criado por TabishB, com sua primeira release em setembro de 2025, possui 3.4k de forks e 48 mil estrelas no GitHub, sendo um dos frameworks mais relevantes do momento.
Sua estrutura é bem mais simples do que vimos anteriormente com o do GitHub, com o objetivo de ser menos burocrático, mais rápido e com mais entregas. Ao inicializar uma spec com /opsx:propose, podemos notar que todos os arquivos criados são mais curtos, com a informação organizada em documentos diferentes.
De uma só vez, é criado basicamente todo o processo até antes da implementação:
proposal.mddesign.mdtasks.md- pastas com user stories
O proposal diz o que será alterado, adicionado e o impacto que terá as mudanças. O design mostra informações como gerenciamento de estado, trade-off, estrutura de UI, modelos e aspectos arquiteturais. O tasks, como o nome diz, mostra o processo quebrado em várias tasks.
Quanto às pastas, são user stories que exprimem a ideia do que resolver dado uma determinada situação. Quando x acontecer, y deve acontecer. Isso ajuda o agente a entender melhor o contexto daquela implementação e o que deve ocorrer no processo.
Depois disso, podemos livremente alterar diretamente os arquivos ou usar /opsx:explore dizendo algo para alterar ou corrigir. Caso não seja necessário, é simplesmente partir para o /opsx:apply para implementar tudo o que foi documentado. Extremamente rápido!
Depois de completado, podemos usar /archive para arquivar em uma pasta archive e deixar a implementação documentada. Na documentação mais recente, esse fluxo aparece como /opsx:archive.
Problemas
OpenSpec é um dos meus kits preferidos, e o que eu mais uso. Ele é muito rápido, fácil de usar e você consegue deixar tudo bem estruturado e documentado. O problema começa quando você precisa de algo maior.
Ser menos burocrático faz com que ele dê mais brechas para ser algo menos documentado, menos ambíguo e menos explicado. Para tarefas mais complexas e maiores, pode não ser tão interessante.
Acredito que ele funciona melhor em momentos onde os requisitos são mais simples, flexíveis e o projeto é menor. O GitHub Spec Kit é mais recomendado no caminho oposto.
