OpenSpec: rápido y simple
Continuando con la exploración de herramientas que implementan SDD dentro de nuestro flujo de trabajo, hoy hablaremos un poco sobre OpenSpec. Creado por TabishB y lanzado por primera vez en septiembre de 2025, cuenta con alrededor de 3.4k forks y 48k estrellas en GitHub, siendo uno de los frameworks más relevantes actualmente.
Su estructura es mucho más simple que la del spec-kit de GitHub que vimos antes, con el objetivo de ser menos burocrática, más rápida y con más entregables. Al iniciar una spec con /opsx:propose, notarás que todos los archivos generados son más cortos y la información está organizada en documentos separados.
De un solo paso, se crea básicamente todo el proceso hasta la implementación:
proposal.mddesign.mdtasks.md- carpetas con user stories
El proposal explica lo que se cambiará o agregará y el impacto de esos cambios. El design muestra información como gestión de estado, trade-offs, estructura de UI, modelos y aspectos arquitectónicos. El tasks, como su nombre indica, divide el trabajo en múltiples tareas.
Las carpetas son user stories que expresan qué resolver dada una situación específica. Cuando X ocurra, Y debería ocurrir. Esto ayuda al agente a entender mejor el contexto y lo que debe suceder durante la implementación.
Después de eso, puedes editar archivos directamente o usar /opsx:explore para indicar cambios o correcciones. Si no se necesita nada más, simplemente ejecuta /opsx:apply para implementar todo lo documentado. ¡Extremadamente rápido!
Una vez completado, usa /archive para archivar en una carpeta archive y mantener la implementación documentada. En la documentación más reciente, este flujo aparece como /opsx:archive.
Problemas
OpenSpec es uno de mis kits favoritos y el que más uso. Es muy rápido, fácil de usar y te permite mantener todo bien estructurado y documentado. El problema comienza cuando necesitas algo más grande.
Ser menos burocrático deja espacio para menos documentación, más ambigüedades y menos explicaciones. Para tareas más grandes y complejas, puede no ser tan adecuado.
Creo que funciona mejor cuando los requisitos son simples, flexibles y el proyecto es pequeño. El GitHub Spec Kit es más recomendable para el camino opuesto.
