14 de septiembre de 2026 · Por YasKad
Fission-AI/OpenSpec

OpenSpec: la capa de especificaciones ligera que obliga a acordar qué construir antes de escribir código

Fission-AI/OpenSpec · 70.314★ · 4.813 forks

OpenSpec es una capa de especificaciones ligera que obliga al desarrollador y a su asistente de código a acordar, por escrito, qué se va a construir antes de escribir una sola línea de código. Es la principal alternativa «ligera» al enfoque spec-driven dentro de un ecosistema de herramientas que creció rápidamente a partir de 2025.

Nota de desambiguación: el repositorio se llama OpenSpec (con mayúscula) en GitHub; la fila de la cola usa openspec. Existe al menos un proyecto no relacionado con el mismo nombre (un explorador OpenAPI/Swagger en openspec.vercel.app), pero el repositorio documentado aquí es Fission-AI/OpenSpec.

Una impactante ilustración tecnológica cyberpunk de un centro de comando de desarrollo en modo oscuro para un framework ligero de codificación con IA guiado por especificaciones, en el centro un pipeline holográfico brillante fluye de izquierda a derecha con cinco etapas etiquetadas: explore, propose, apply, sync, y archive, alrededor del pipeline flotan documentos Markdown translúcidos, mostrando bloques de texto estructurados limpios, escenarios de requisitos, listas de verificación de tareas, y secciones delta marcadas con ADDED, MODIFIED, y REMOVED, una silueta de desarrollador humano y una interfaz abstracta de asistente de IA se enfrentan, alineadas por un contrato luminoso compartido entre ellas, el fondo es una interfaz de carbón oscuro profundo con ventanas de terminal tenues, carpetas de repositorio, líneas de rama git, y gráficos de código sutiles, acentos neón cian, azul eléctrico, magenta suave, y ámbar pulsan por la composición, el ambiente es preciso, futurista, y profesional, con una sensación de acuerdo antes del código, ultra-detallado, resolución 8K, iluminación cinematográfica, modo oscuro, estética cyberpunk/tech, hologramas limpios de inspiración vectorial, imagen de portada editorial de alta gama

Qué es OpenSpec

OpenSpec es un framework de desarrollo guiado por especificaciones (SDD, por sus siglas en inglés) para asistentes de programación con IA. No es un modelo, un IDE ni un servidor: es un CLI de Node.js que genera archivos Markdown dentro del propio proyecto, más un conjunto de habilidades y comandos a cuchara (/opsx:*) que el asistente de IA ejecuta en el chat.

Su propósito es mover el acuerdo sobre los requisitos fuera del historial de chat. Cuando los requisitos viven solo en una conversación, el asistente llena los vacíos con suposiciones y el error se descubre después de que el código ya existe. OpenSpec introduce un contrato verificable: cada cambio se planifica en una carpeta con propuesta, especificaciones delta, diseño y lista de tareas; el humano revisa el plan antes de que se implemente nada, y al archivar el cambio, las especificaciones se convierten en la descripción del comportamiento actual del sistema.

El propio README resume la filosofía en cinco líneas: fluido, no rígido; iterativo, no en cascada; fácil, no complejo; pensado para brownfield, no solo para proyectos nuevos; y escalable de proyectos personales a empresas.

El origen

El repositorio fue creado el 5 de agosto de 2025 por la organización Fission-AI en GitHub. Los mantenedores declarados en MAINTAINERS.md son Tabish Bidiwale (TabishB), mantenedor principal, y Clay Good (clay-good), mantenedor, con Hari Krishnan (harikrishnan83) como asesor técnico. El sitio oficial, openspec.dev, lleva la marca «© 2026 Fission», lo que indica que el proyecto está respaldado por la empresa Fission.

El color narrativo que ofrecen las fuentes consultadas es modesto: no hay un post de lanzamiento viral con anécdota, a diferencia de otras herramientas del mismo nicho. La trayectoria documentada es la de un proyecto que maduró de forma constante: nació como experimental en agosto de 2025, pasó a estable con v1.0.0 el 26 de enero de 2026 (un rediseño completo del flujo alrededor de un sistema de acciones basado en artefactos, con cambios rompedores), y desde entonces ha lanzado versiones casi semanales. El autor principal del proyecto, Tabish Bidiwale, publicó un vídeo de lanzamiento y mantiene el perfil @0xTab en X, que el README enlaza para novedades.

Filosofía y principios

El README y la documentación declaran los siguientes principios, verificables en el propio código del flujo: acordar antes de construir (el asistente y el humano se alinean sobre las especificaciones antes de escribir código; el error es barato en el plan, caro en la implementación); fluido, no en fases rígidas (cualquier artefacto —propuesta, specs, diseño, tareas— puede editarse en cualquier momento; no hay puertas de fase que bloqueen el avance); markdown plano, sin sintaxis especial (las especificaciones son requisitos con escenarios SHALL/MUST + GIVEN/WHEN/THEN, legibles por humanos y verificables por el CLI); y neutralidad de herramienta (funciona con más de 30 asistentes de IA instalando el formato de habilidades o comandos que cada uno usa, en vez de obligar a un solo entorno).

Un visual conceptual de un ecosistema de asistentes de IA neutral en cuanto a herramienta, centrado en un hub de especificaciones compartido, en el medio, un núcleo de especificación brillante al estilo OpenSpec emite documentos estructurados y escenarios de requisitos, a su alrededor, numerosas interfaces de asistentes de codificación de IA orbitan en un espacio oscuro: paneles de chat, barras laterales de IDE, clientes de terminal, servidores de herramientas MCP, plugins de editor, y espacios de trabajo de agentes, cada satélite tiene un color neón distinto pero se conecta a través del mismo contrato central, mostrando compatibilidad entre muchas herramientas en lugar de un entorno cerrado, delgadas líneas de datos conectan el hub con más de 30 iconos de asistentes, representando integración amplia, el fondo incluye fragmentos de código sutiles, paletas de comandos, y insignias de repositorio, ultra-detallado, resolución 8K, modo oscuro, estética cyberpunk/tech, acentos neón, orquestación de alta tecnología, ilustración profesional limpia

Brownfield-first: no se documenta la aplicación completa de antemano; se escribe una especificación solo para lo que cada cambio toca, y las specs crecen con el trabajo real.

Una escena de arquitectura de software brownfield-first mostrando una base de código legacy existente representada como un denso paisaje urbano oscuro tipo placa de circuito, la mayor parte de la ciudad está apagada, estable, y tenuemente iluminada, pero un distrito específico está resaltado con contornos neón brillantes donde se está planificando un nuevo cambio, flotando sobre el área resaltada hay tarjetas de especificación ligeras, listas de tareas, y notas de diseño, enfatizando que solo se especifican las partes tocadas, pequeñas sondas de asistente de IA inspeccionan los módulos relevantes sin revisar todo el sistema, la composición comunica trabajo de especificación iterativo e incremental dentro de proyectos del mundo real en lugar de perfección greenfield, modo oscuro, estética cyberpunk/tech, ultra-detallado, resolución 8K, acentos neón, profundidad cinematográfica, metáfora visual futurista limpia

Un concepto central es la especificación delta: cada cambio declara solo lo que modifica (secciones ADDED, MODIFIED, REMOVED) en vez de reescribir toda la spec, y al archivar, esas deltas se fusionan en la spec principal. El cambio archivado queda en openspec/changes/archive/ como historia auditable.

Una ilustración conceptual de especificaciones delta fusionándose en una especificación de sistema principal, a la izquierda, una carpeta de cambio emite pequeños fragmentos de documento brillantes etiquetados ADDED, MODIFIED, y REMOVED, en el centro, un embudo de fusión luminoso combina estos fragmentos en un documento de especificación canónico más grande, a la derecha, la especificación actualizada brilla como la única fuente de verdad, mientras la carpeta de cambio completada se archiva en una pila histórica con marca de tiempo, el lenguaje visual usa páginas Markdown en capas, colores semánticos de diff, y conectores neón delgados, la escena transmite historia auditable, evolución incremental, y documentación limpia, fondo oscuro con cuadrículas de plano sutiles, iconos de repositorio, y nodos tenues de commit git, ultra-detallado, resolución 8K, modo oscuro, estética cyberpunk/tech, acentos neón cian y magenta, ilustración editorial precisa

Cómo funciona

El flujo básico documentado (perfil core, por defecto):

/opsx:explore ──► /opsx:propose ──► /opsx:apply ──► /opsx:sync ──► /opsx:archive
   (opcional)
  1. /opsx:explore (opcional): un «compañero de reflexión» sin compromiso que lee la base de código, sopesa opciones y convierte una idea borrosa en un plan concreto, sin crear todavía ningún artefacto.
  2. /opsx:propose <nombre>: crea openspec/changes/<nombre>/ con proposal.md (el porqué y el alcance), specs/ (deltas con requisitos y escenarios), design.md (el cómo técnico) y tasks.md (checklist de implementación). El humano revisa el plan.
  3. /opsx:apply: el agente implementa las tareas; si el diseño necesita ajustes, los artefactos se editan y se continúa.
  4. /opsx:sync (opcional): fusiona las deltas en las specs principales antes de archivar, útil en cambios largos.
  5. /opsx:archive: aplica las deltas a la spec principal y mueve el cambio a changes/archive/AAAA-MM-DD-<nombre>/.

Una detallada escena de terminal en modo oscuro mostrando un asistente de codificación de IA interactuando con un flujo de trabajo de especificación, una interfaz de línea de comandos elegante muestra comandos como /opsx:explore, /opsx:propose, /opsx:apply, /opsx:sync, y /opsx:archive en texto monoespaciado nítido, a la derecha, una carpeta de proyecto generada se despliega en un árbol holográfico: openspec/changes/change-name/ contiene proposal.md, specs/, design.md, y tasks.md, cada archivo brilla con un acento neón diferente: proposal en cian, specs en azul, design en violeta, tasks en ámbar, pequeñas marcas de verificación holográficas y marcadores de diff aparecen junto a los elementos de tarea, el entorno es un espacio de trabajo de desarrollador oscuro con líneas de cuadrícula suaves, pestañas de terminal flotantes, y metadatos de repositorio sutiles, ultra-detallado, resolución 8K, estética cyberpunk/tech, modo oscuro, acentos neón, diseño de interfaz futurista limpio

Hay un perfil expandido (new, continue, ff, verify, bulk-archive, onboard) que se activa con openspec config profile. El CLI de terminal complementa el chat con openspec list, openspec show <change> [--diff], openspec validate [--report findings], openspec status --all, openspec view (panel interactivo) y openspec feedback.

Además, desde la beta, OpenSpec ofrece Stores: un repositorio independiente dedicado solo a planificación, con la misma forma openspec/ (specs y changes) que se comparte con git push como cualquier otro repo. Resuelve el caso de un equipo donde una función toca tres repositorios, o donde un equipo de plataforma posee los requisitos y los equipos de producto los consumen de solo lectura. openspec store setup <nombre> y openspec new change <id> --store <nombre> son los comandos de arranque.

Una ilustración futurista de un repositorio de planificación compartido llamado Store, un holograma de repositorio independiente flota sobre un entorno de desarrollador oscuro, conteniendo solo carpetas specs/ y changes/, sin código fuente de aplicación dentro, múltiples estaciones de trabajo de equipo de producto y nodos de repositorio se conectan al Store a través de líneas brillantes de git push y pull, un escenario muestra una sola función abarcando tres repositorios, con el Store central coordinando el plan, mientras los nodos del equipo de plataforma y del equipo de producto acceden a la misma especificación en modos de solo lectura o editables, el visual es preciso y orientado a sistemas, con grafos de repositorio, líneas de rama, insignias de permisos, y tarjetas de documento sincronizadas, modo oscuro, estética cyberpunk/tech, ultra-detallado, resolución 8K, acentos neón azul y cian, estilo tecnológico editorial limpio

El ecosistema

Repositorios de la organización Fission-AI

Fission-AI/OpenSpec: el proyecto principal (este informe). Fission-AI/PR-QUEST: una forma más interactiva de revisar solicitudes de cambios; 25 estrellas (16 de octubre de 2025).

El producto comercial asociado, documentado en el blog oficial, es el OpenSpec Cloud Agent (acceso anticipado el 28 de agosto de 2026): una capa siempre activa que compara pull requests con los requisitos de los repositorios conectados, detecta «deriva» entre código y specs citando la línea exacta de ambos, y puede abrir PRs correctivos. Una actualización del 11 de septiembre de 2026 indica que las inscripciones nuevas del programa de acceso anticipado están pausadas mientras evalúan el producto con los equipos participantes.

Una sala de control de revisión de código cyberpunk mostrando un agente de nube siempre activo comparando pull requests contra especificaciones de repositorio, a la izquierda, un diff de pull request brilla con líneas de código cambiadas, a la derecha, el documento de especificación correspondiente muestra escenarios de requisitos y declaraciones normativas, en el centro, una interfaz de detección de deriva de IA dibuja líneas de conexión rojas y ámbar brillantes entre el comportamiento del código no coincidente y las expectativas de la spec, resaltando la línea exacta en ambos documentos, un pull request correctivo se genera abajo como una pequeña rama brillante, la atmósfera es vigilante, precisa, y automatizada, como un centinela de aseguramiento de calidad vigilando código y requisitos en tiempo real, modo oscuro, ultra-detallado, resolución 8K, estética cyberpunk/tech, acentos neón, visual de ingeniería de software de alta gama

Herramientas de la comunidad

UIs y visualizadores (catalogados en speclib/awesome-openspec, 73 estrellas): ToruAI/openspec-ui (kanban en tiempo real, 31 estrellas), oioi555/openspec-webui (interfaz web interactiva, 14 estrellas), jixoai/openspecui (interfaz web con modo en vivo y exportación estática, 113 estrellas), y otros como fselich/dossier, MusicAdam/openspec-viewer, sflueckiger/specboard, dansreis/speclens, spekhq/spek.

Integraciones y plugins de editores/agentes: Lumiaqian/openspec-mcp (servidor MCP con panel kanban), johnnyblabs/intellij-openspec (plugin de IntelliJ), Octane0411/opencode-plugin-openspec (160 estrellas, plugin de OpenCode con modo «architect»), fastknifes/openflow (180 estrellas, combina OpenSpec y Superpowers), y extensiones para Copilot, VS Code/Cursor, Zed, Emacs y Neovim.

Flujos híbridos y esquemas comunitarios: JiangWay/openspec-schemas (222 estrellas, incluye superpowers-bridge), intent-driven-dev/openspec-schemas (94 estrellas), MageByte-Zero/spec-superflow (798 estrellas, fusión con Superpowers), rihebty/flow-kit (400 estrellas), SYZ-Coder/superpowers-openspec-team-skills (193 estrellas), sudokar/openspec-plus (190 estrellas), wenqingyu/ralphy-openspec (182 estrellas).

Ingeniería inversa y guías: clay-good/OpenLore (304 estrellas, antes spec-gen, del propio mantenedor Clay Good, genera especificaciones a partir de código existente), ForceInjection/OpenSpec-practise (614 estrellas), sohaha/studyzy-OpenSpec-cn (96 estrellas), y más guías comunitarias en chino.

Un mapa de ecosistema vibrante de herramientas comunitarias que rodean un framework de especificación central, la composición se asemeja a una constelación digital oscura: un nodo central emite especificaciones Markdown estructuradas, mientras nodos circundantes representan UIs, visualizadores, plugins, esquemas, runbooks, y flujos de trabajo híbridos, algunos nodos muestran tableros kanban, interfaces web, extensiones de editor, servidores MCP, bucles de revisión adversarial, retrospectivas basadas en evidencia, y habilidades de equipo multi-agente, los recuentos de estrellas e insignias de repositorio aparecen como chips brillantes sutiles, pero el énfasis está en un ecosistema abierto próspero, el estilo visual es denso pero organizado, con caminos de conexión neón, paneles flotantes, y una sensación de rápido crecimiento comunitario, modo oscuro, estética cyberpunk/tech, ultra-detallado, resolución 8K, acentos neón cian, magenta, y violeta

Estado oficial / semioficial

OpenSpec no es un componente de un marketplace de un gran vendor: es un paquete npm independiente (@fission-ai/openspec) bajo licencia MIT, mantenido por Fission-AI. Hay tres señales de estatus verificables: estable desde v1.0.0 (26 de enero de 2026, con la transición «de experimental a estable»); adopción de facto en el nicho SDD (los hilos de Hacker News muestran a OpenSpec nombrado junto con Spec Kit, Superpowers y Kiro en discusiones sobre desarrollo guiado por especificaciones); y producto comercial asociado (el OpenSpec Cloud Agent indica una intención de negocio más allá del OSS).

En la práctica, OpenSpec funciona como la opción ligera y multi-herramienta del estándar de facto «escribir specs antes que código», compitiendo de frente con github/spec-kit (oficial de GitHub) y Kiro (AWS), como el propio README compara.

Guía rápida de uso

Instalación y primer arranque

Prerrequisito: Node.js 20.19.0 o superior.

npm install -g @fission-ai/openspec@latest   # también pnpm add -g / bun add -g / yarn global add
openspec --version                            # verificar
cd tu-proyecto
openspec init                                 # interactivo: elige las herramientas de IA que usas

Opciones no interactivas: openspec init --tools claude,cursor, --tools all, --tools none, --profile core. Con Nix: nix run github:Fission-AI/OpenSpec -- init.

Al finalizar, openspec init crea la estructura openspec/ (con specs/, changes/ y config.yaml), escribe las habilidades y comandos para cada herramienta elegida, e imprime una línea «Getting started» con la ortografía exacta del comando para tu herramienta. Lo que esperar en el primer arranque: dos pasos de terminal y luego todo se hace en el chat del asistente. No existe un «modo interactivo» separado; el comando a cuchara es la entrada a OpenSpec.

Flujos de trabajo habituales

  • Para proponer una función que ya tienes clara: en el chat del asistente, ejecuta /opsx:propose add-dark-mode; se crea openspec/changes/add-dark-mode/ con proposal.md, specs/, design.md y tasks.md. Revisa el plan antes de continuar.
  • Para pensar una idea borrosa antes de comprometerte: ejecuta /opsx:explore, explica el problema, y el agente explora el código, hace preguntas y propone un alcance; al terminar, transfiere a /opsx:propose.
  • Para implementar: ejecuta /opsx:apply; el agente trabaja el checklist y marca cada tarea. Si te quedas sin contexto, abre una sesión nueva y vuelve a ejecutar /opsx:apply: lee los artefactos y reanuda desde la primera tarea sin marcar.
  • Para revisar y validar desde terminal: openspec list (cambios activos), openspec show <cambio> --diff (solo las líneas que cambian), openspec validate <cambio> (valida el formato de las specs). Al terminar, /opsx:archive fusiona las deltas en openspec/specs/ y archiva el cambio.

Configuración esencial

  1. openspec/config.yaml: la clave context: inyecta texto en cada solicitud de planificación; es el lugar para declarar tu stack tecnológico y convenciones.
  2. Perfil de comandos (openspec config profile): core (por defecto) o el perfil expandido (añade new, continue, ff, verify, bulk-archive, onboard).
  3. Idioma de artefactos: openspec init --language <language> genera las specs en otro idioma (los encabezados y las palabras SHALL/MUST se mantienen en inglés).
  4. Telemetría: encendida por defecto (solo nombres de comando y versión; desactivada automáticamente en CI). Opt-out: openspec config set telemetry.enabled false.
  5. Stores (beta): openspec store setup <nombre> para planificación multi-repo.

Trampas frecuentes y soluciones

  • Escribir /opsx:propose en la terminal: el error más común documentado. Los comandos openspec ... corren en terminal; los comandos /opsx:... se escriben en el chat del asistente.
  • La sintaxis no coincide con tu herramienta: /opsx:propose es /opsx-propose en Cursor y GitHub Copilot, @opsx-propose en Amazon Q, $openspec-propose en Codex, y /skill:openspec-propose en Kimi Code. Usa siempre la forma impresa por openspec init.
  • Comando que no aparece: normalmente los archivos no están instalados. openspec update solo refresca archivos existentes; si nunca corriste openspec init, ejecútalo y reinicia el asistente.
  • Versión vieja en la PATH: tras actualizar el paquete, si openspec --version muestra una versión anterior, hay una copia anterior enmascarando la nueva en la PATH.
  • Editar código a mano y desincronizar la spec: archivar convierte tus specs en el registro de la verdad; antes de archivar, reconcilia. /opsx:verify y openspec show --diff ayudan a ver las discrepancias.
  • Yarn 2+ no tiene global: instala con npm, pnpm o bun en su lugar.

Integraciones y migración

La carpeta openspec/ se debe commitear como código fuente. Para CI: openspec validate --archived verifica que todos los cambios archivados tengan todas las tareas de tasks.md marcadas; openspec validate --report findings emite un informe solo de hallazgos para pipelines. openspec init --copilot-cloud genera archivos para que el agente de código de GitHub use el CLI. El servidor comunitario Lumiaqian/openspec-mcp expone el CLI como herramientas MCP. Para migrar desde versiones anteriores a 1.0, los comandos antiguos fueron eliminados; ejecuta openspec init para actualizar — los cambios activos, archivados y las specs se conservan.

Métricas actuales

Medición: 14 de septiembre de 2026, API de GitHub y registro npm.

MétricaValor
Estrellas68.216
Bifurcaciones4.689
Incidencias abiertas indicadas por la API283
Commits (rama main, aproximado)≈843
Lenguaje principalTypeScript
LicenciaMIT
Creación5 de agosto de 2025
Último push14 de septiembre de 2026
Última publicaciónv1.13.0, 9 de septiembre de 2026
Descargas npm (semana)378.332
Descargas npm (mes)1.768.196

Los principales contribuidores, por contribuciones: TabishB (518), clay-good (125), openspec-release-bot[bot] (23), github-actions[bot] (20) y dependabot[bot] (16). Caveats: open_issues_count puede incluir solicitudes de cambios abiertas; el conteo de commits es aproximado; y watchers_count de la respuesta de repositorio replica el campo de estrellas, por lo que no se reporta por separado.

Recepción de la comunidad

La evidencia recuperada muestra entusiasmo consistente pero también objeciones concretas y repetidas.

En el hilo 47419539 («Get Shit Done», 17 de marzo de 2026), recroad escribió: «I use openspec and love it. I’m doing 5-7x with close to 100% of code AI generated, and shipping to production multiple times a day. I work on a large sass app with hundreds of customers». gbrindisi añadió: «I like openspec, it lets you tune the workflow to your liking and doesn’t get in the way». En 46692578 («Ask HN: Do you have any evidence that agentic coding works?», 20 de enero de 2026), recroad volvió a citar OpenSpec: «Works pretty great for me… Easily 5x speed minimum». En 48774782 («Superpowers 6», 3 de julio de 2026), wejick escribió: «SDD with openspec hit the right balance for me».

La crítica más articulada aparece en el gran hilo 47994012 («Specsmaxxing», 287 puntos y 295 comentarios, 3 de mayo de 2026). jochem9, que lo usaba «desde hace unos meses», advirtió que «cuando una spec cambia, la IA necesita encontrar el código relevante para cambiarlo… en una base de código grande es muy fácil perder algo». alasano fue más duro: «disfruto el formato de OpenSpec, pero creo que mantener las specs principales no vale la pena. He dejado de hacerlo por completo… Cuando haces el proceso de sync, sigue desviándose hasta que tienes duplicación y contradicciones entre specs». gnatolf, en 47019109 («Breaking the spell of vibe coding», 14 de febrero de 2026), formuló la objeción de escala: «En cuanto el proyecto crece a un tamaño relevante de complejidad, mantener las specs es tan difícil como el problema que resuelve».

El desarrollador Dan Clarke publicó una review el 8 de mayo de 2026 tras un mes de uso: lo eligió porque Spec Kit le resultó «un poco pesado», resalta el modo explore como característica clave, pero matiza que en su experiencia «no es realmente spec-driven… las specs son un artefacto del flujo, no el punto de partida».

Comparación con proyectos similares

PropuestaCoincidencia verificableDiferencia verificable
github/spec-kit (136.644 estrellas, Python)Kit oficial de GitHub para SDD con CLI, plantillas e integraciones.El README de OpenSpec lo describe como «exhaustivo pero pesado: puertas de fase rígidas, mucho Markdown, configuración en Python».
Kiro (AWS)IDE agéntico de AWS que convierte lenguaje natural en specs estructuradas.El README: «poderoso pero quedas atado a su IDE y limitado a modelos Claude»; OpenSpec funciona con las 30+ herramientas existentes.
obra/superpowersDisciplina de proceso para agentes de código, con habilidades compuestas.Superpowers impone la metodología de ejecución (TDD, revisión, worktrees); OpenSpec gobierna el acuerdo previo sobre requisitos. La comunidad los combina vía schemas.
bmad-code-org/BMAD-METHODMetodología ágil guiada por IA que usa specs formales como fuente única de verdad.Enfoque de equipo con roles y artefactos formales; OpenSpec es más ligero y personalizable vía schemas.

La comparación más útil no es por popularidad: Spec Kit es el proyecto con más estrellas del nicho (136k frente a 68k de OpenSpec), pero el README y los comentarios de la comunidad posicionan a OpenSpec como la opción cuando se quiere ligereza, libertad de iteración y portabilidad entre asistentes, en vez de un kit prescriptivo.

Cómo contribuir

CONTRIBUTING.md documenta un proceso de cuatro pasos, notable por aplicar el propio flujo del proyecto a sí mismo: abrir una discusión o un issue primero (todo cambio empieza ahí; «PRs sin un issue enlazado o una discusión previa pueden cerrarse»); decidir si necesita una propuesta de cambio (un fix va directo a PR; una nueva funcionalidad requiere primero una propuesta OpenSpec aprobada); hacer el cambio (Node 20.19+ y pnpm; pnpm install, pnpm build, pnpm test, pnpm exec tsc --noEmit, pnpm lint); y abrir el PR (título como commit convencional, enlazar el issue, y si un agente de código escribió el código, declarar cuál).

Casos de uso

  • Desarrolladores individuales que trabajan con Claude Code, Codex, Cursor, Gemini CLI u otro de los 30+ asistentes pueden reemplazar el flujo de «prompt vago → código inesperado» por explore → propose → apply → archive.
  • Equipos multi-repo (plataforma + producto) pueden usar Stores (beta) para que un equipo posea los requisitos en un repositorio de planificación compartido, eliminando el wiki desincronizado.
  • Equipos que temen la deriva spec↔código pueden activar openspec validate --archived y --report findings como hooks de pre-commit/CI, y evaluar el Cloud Agent para detección de deriva en PRs.
  • Proyectos brownfield grandes se benefician del diseño brownfield-first, con clay-good/OpenLore para generar specs iniciales a partir del código existente.
  • Equipos que ya usan Superpowers u otro framework de disciplina pueden combinar ambos vía los schemas comunitarios (superpowers-bridge, spec-superflow, openflow), manteniendo la gobernanza de artefactos de OpenSpec y la ejecución disciplinada del otro.
  • Equipos que desean portabilidad encuentran valor en la neutralidad de herramienta: el mismo flujo de specs funciona en más de 30 asistentes.

Recursos


Nota: este artículo combina el README y la documentación oficial (docs/), MAINTAINERS.md y CONTRIBUTING.md, las notas de versión, el blog oficial de openspec.dev, la API de GitHub, el registro npm, la lista speclib/awesome-openspec y hilos de Hacker News consultados el 14 de septiembre de 2026. Las cifras cambian con el tiempo.

Comentarios