OpenSpec es un marco de desarrollo impulsado por especificaciones (SDD) diseñado para mantener a los asistentes de programación con IA alineados con los requisitos previstos por los humanos. En lugar de instruir a un agente directamente, un desarrollador redacta especificaciones en Markdown plano —requisitos con escenarios concretos— y luego ejecuta comandos slash que guían al asistente para que explore la base de código, proponga un plan, implemente tareas y verifique el resultado respecto a la especificación. El proyecto, publicado por Fission-AI bajo una licencia MIT (versión actual v1.13.0), reporta 68 000 estrellas de GitHub y aproximadamente 265 000 desarrolladores mensuales.
La vista general del marco OpenSpec en openspec.dev presenta la identidad de marca del proyecto e indicadores de adopción, correspondientes a la introducción del marco SDD, su enfoque Markdown plano y los 68 000 estrellas de GitHub y los 265 000 desarrolladores mensuales reportados
El flujo de trabajo se centra en cinco comandos: /opsx:explore asigna un problema antes de comprometerse con un plan; /opsx:propone genera proposal.md, specs/, design.md y tasks.md; /opsx:apply implementa las tareas; /opsx:verify verifica el código respecto a la especificación; y /opsx:archive cierra los cambios completados. Las especificaciones son deliberadamente Markdown plano, sin sintaxis personalizada, y el marco incluye perfiles para Claude Code, Codex, Cursor, GitHub Copilot, Gemini CLI y alrededor de 30 herramientas adicionales.
Imagen OpenGraph de GitHub para el repositorio Fission-AI/OpenSpec que muestra la descripción del proyecto como un marco de desarrollo impulsado por especificaciones para asistentes de programación con IA, alineado con el flujo de trabajo de cinco comandos explorar-proponer-aplicar-verificar-archivar y los 30+ perfiles de herramientas compatibles discutidos en este párrafo
Una función más reciente, «Stores», se encuentra en beta y pretende resolver un problema entre equipos: un equipo de plataforma posee requisitos compartidos en un repositorio dedicado, y los equipos de producto los consultan en modo de solo lectura desde sus propios flujos de trabajo con agentes de programación. La idea es que las especificaciones se conviertan en un artefacto de git de primera clase en lugar de una wiki en constante deriva.
Vista previa del panel desde el repositorio OpenSpec que muestra el espacio de trabajo de gestión de especificaciones, ilustrando el tipo de interfaz que da soporte a la función beta «Stores» para compartir especificaciones entre equipos discutida en este párrafo
Sin embargo, la discusión aportada plantea una preocupación sobre la durabilidad. Un usuario con experiencia reporta que, tras seis a nueve meses en dos proyectos en solitario, las especificaciones se desviaron tanto del código real que abandonó la capa de especificación por completo, conservando únicamente el proceso de propuesta-revisión-implementación-revisión. Esto refleja una observación más amplia: en bases de código de larga duración y con múltiples desarrolladores, la degradación de las especificaciones puede superar el beneficio de la planificación. La documentación del proyecto no incluye puntos de referencia independientes ni mediciones de deriva, por lo que las afirmaciones cuantitativas (especificaciones por segundo, número de estrellas) deben leerse como señales de adopción autoinformadas y no como datos de eficacia verificados. La función «Stores» también se encuentra aún en beta, y su fiabilidad en el mundo real a escala no está aún establecida por las fuentes aportadas.