1. Introduccion: El problema que resuelve OpenSpec
Agentes IA sin especificaciones = caos controlado
Si has trabajado con agentes de codificacion IA (Claude Code, OpenCode, Cursor, Copilot Agent) en proyectos de Platform Engineering, probablemente hayas experimentado el siguiente patron: le pides al agente que cree un modulo Terraform para un Storage Account, y el resultado compila, pasa
terraform validate, pero no tiene soft-delete, no usa Private Endpoint, y la replicacion es LRS en vez de GRS. El agente escribio codigo correcto para una especificacion que nunca existio.Este es el gap entre la intencion y la implementacion. Cuando un humano describe un cambio en lenguaje natural, hay una perdida de informacion inherente. El agente interpreta, asume, y genera. Sin un contrato intermedio que defina que se va a construir antes de escribir como, el resultado es impredecible.
En Platform Engineering, donde un cambio mal especificado puede provocar una caida en produccion, drift de infraestructura o una brecha de seguridad, este gap es inaceptable. Necesitas una capa de especificacion entre la peticion humana y la ejecucion del agente. Eso es exactamente lo que resuelve OpenSpec.
2. Que es OpenSpec
Definicion y filosofia
OpenSpec es un framework de Spec-Driven Development (SDD) creado por Fission-AI (41.8k estrellas en GitHub). Agrega una capa ligera de especificacion para que humanos y agentes IA acuerden que construir antes de que se escriba una sola linea de codigo.
La filosofia central es: fluido, no rigido; iterativo, no waterfall. OpenSpec no te obliga a escribir documentos de 50 paginas antes de empezar. En su lugar, propone un ciclo rapido de
propose → apply → archive donde cada cambio tiene su propia carpeta con propuesta, especificaciones, diseno y tareas.Diferenciacion: OpenSpec vs Spec Kit vs Kiro
Caracteristica |
OpenSpec (Fission-AI) |
Spec Kit (GitHub) |
Kiro (AWS) |
|---|---|---|---|
Enfoque |
SDD agnositco (25+ herramientas) |
Copilot-centric |
IDE propio de AWS |
Compatibilidad |
Claude Code, Copilot, Cursor, OpenCode, Cline, Vibe... |
GitHub Copilot |
Kiro IDE |
Workflow |
Slash commands (/opsx:propose, /opsx:apply) |
spec-kit generate |
Steering (requirements → design → tasks) |
Esquemas |
spec-driven, minimalist, event-driven |
Fijo |
Fijo (steering) |
Open Source |
Si |
Si |
No (propietario) |
Reverse engineering |
spec-gen (companion tool) |
No |
No |
3. Arquitectura y Componentes Clave
Instalacion de la CLI
OpenSpec se distribuye como paquete npm global:
BASH
npm install -g @fission-ai/openspec@latestVerifica la instalacion:
BASH
openspec --versionCiclo de vida del workflow: propose, apply, archive
El flujo de OpenSpec se basa en tres comandos slash que puedes invocar desde cualquier agente IA compatible:
/opsx:propose: Crea una nueva propuesta de cambio. El agente genera una carpeta conproposal.md, el directoriospecs/,design.mdytasks.md./opsx:apply: Ejecuta las tareas definidas en la spec, generando el codigo real./opsx:archive: Mueve la spec completada al archivo historico para referencia futura.
Estructura de directorios de OpenSpec
Cada cambio gestionado por OpenSpec obtiene su propia carpeta dentro del directorio de especificaciones:
CODE
mi-plataforma/
├── .openspec/
│ ├── config.yaml # Configuracion del proyecto
│ ├── active/ # Cambios en curso
│ │ └── add-storage-module/
│ │ ├── proposal.md # Que se va a construir y por que
│ │ ├── specs/ # Especificaciones tecnicas detalladas
│ │ │ └── storage-account.md
│ │ ├── design.md # Decisiones de diseno
│ │ └── tasks.md # Lista de tareas atomicas
│ └── archive/ # Cambios completados (historial)
│ └── 2026-04-15-vpc-module/
│ ├── proposal.md
│ ├── specs/
│ ├── design.md
│ └── tasks.md
├── terraform/
└── k8s/Esta estructura garantiza trazabilidad completa. Cada cambio tiene su contexto, sus decisiones y su historial. En un equipo de Platform Engineering, esto permite auditar quien propuso que, cuando y por que.
Sistema de esquemas
OpenSpec ofrece tres esquemas predefinidos que determinan la profundidad de las especificaciones generadas:
- spec-driven (por defecto): Genera specs completas con proposal, design, tasks y archivos de especificacion individuales. Ideal para cambios de infraestructura critica.
- minimalist: Solo genera proposal.md y tasks.md. Para cambios menores o hotfixes donde la ceremonia completa no aporta valor.
- event-driven: Orientado a sistemas basados en eventos. Genera specs con diagramas de flujo de eventos y contratos de mensajes.
Anatomia de config.yaml
El archivo
config.yaml en .openspec/ define el comportamiento del framework para tu proyecto:YAML
# .openspec/config.yaml
project:
name: "acme-platform"
description: "Plataforma multi-tenant sobre Azure con Terraform y ArgoCD"
schema: spec-driven # spec-driven | minimalist | event-driven
paths:
active: ".openspec/active"
archive: ".openspec/archive"
specs: "specs"
conventions:
naming: kebab-case # Nombres de carpetas de cambios
language: es # Idioma de las specs generadas
require_design: true # Forzar design.md en cada cambio
require_tasks: true # Forzar tasks.md con lista atomica
validation:
max_tasks_per_spec: 15 # Evitar specs demasiado grandes
require_acceptance_criteria: trueEl campo schema es el mas critico. Para Platform Engineering recomiendo
spec-driven siempre que el cambio afecte infraestructura en produccion, y minimalist para cambios en documentacion o scripts auxiliares.4. Casos de Uso en Platform Engineering
Gobernanza de cambios en IaC (Terraform)
Cuando un ingeniero necesita agregar un modulo Terraform, el flujo con OpenSpec fuerza una especificacion antes de la generacion:
MARKDOWN
# .openspec/active/add-storage-module/proposal.md
## Propuesta: Modulo Storage Account Azure
### Contexto
El equipo de datos necesita un Storage Account con blob containers
para el pipeline de ingest. Actualmente se crean manualmente.
### Requisitos
- Replicacion GRS (geo-redundant)
- Soft-delete habilitado (30 dias)
- Private Endpoint en la subnet de datos
- Tags obligatorios: Owner, Project, Environment, CostCenter
- HTTPS-only, TLS 1.2 minimo
### Criterios de aceptacion
- [ ] terraform validate pasa sin errores
- [ ] terraform plan no muestra "forces replacement"
- [ ] Cumple security-baseline.mdCon esta propuesta como contrato, el agente IA genera codigo que cumple los requisitos exactos. Si falta algo, se detecta en la revision de la spec, no despues de un
terraform apply en produccion.GitOps workflows con validacion de specs
En un flujo GitOps, los Pull Requests que modifican infraestructura pueden requerir que exista una spec aprobada antes de hacer merge. Esto se implementa con un check en CI que verifica la presencia del directorio
.openspec/active/ correspondiente al cambio.Cambios multi-tenant en plataformas
Cuando gestionas una plataforma que sirve a multiples equipos, cada cambio estructural necesita documentar su impacto en todos los tenants. La spec de OpenSpec incluye secciones de impacto que fuerzan al autor (humano o IA) a considerar efectos colaterales antes de implementar.
Developer Experience: onboarding con specs
El directorio
.openspec/archive/ se convierte en una base de conocimiento viviente. Un nuevo ingeniero puede leer las specs archivadas para entender por que la infraestructura tiene la forma que tiene, que alternativas se evaluaron y que decisiones se tomaron.CI/CD: deteccion de drift con spec-gen
spec-gen (por clay-good) es la herramienta companion de OpenSpec para ingenieria inversa. Analiza tu codebase existente, genera specs a partir del codigo actual, y detecta drift entre las specs documentadas y la implementacion real. Soporta 9 proveedores LLM y ofrece un servidor MCP para integracion con agentes.
5. Guia de Implementacion Progresiva
5.1 Nivel Basico: Init y primer flujo
Inicializa OpenSpec en tu proyecto existente:
BASH
# Navega a la raiz de tu proyecto
cd ~/projects/acme-platform
# Inicializa OpenSpec con el esquema por defecto (spec-driven)
openspec init
# Resultado:
# Created .openspec/config.yaml
# Created .openspec/active/
# Created .openspec/archive/
# OpenSpec initialized with schema: spec-drivenAhora abre tu agente IA preferido (OpenCode, Claude Code, Cursor...) y ejecuta el primer slash command:
CODE
/opsx:propose Crear modulo Terraform para Azure Storage Account con Private Endpoint y soft-deleteEl agente generara la estructura completa en
.openspec/active/crear-modulo-terraform-storage/. Revisa el proposal.md y las specs generadas. Si todo es correcto:CODE
# Ejecuta las tareas definidas en la spec
/opsx:apply crear-modulo-terraform-storage
# Una vez completado y validado, archiva
/opsx:archive crear-modulo-terraform-storage5.2 Nivel Intermedio: Integracion con toolchain
spec-gen: ingenieria inversa de specs
Si ya tienes un codebase existente sin specs, spec-gen puede analizar tu codigo y generar especificaciones retroactivas:
BASH
# Instalar spec-gen
npm install -g spec-gen
# Analizar el codebase existente
spec-gen analyze ./terraform/modules/
# Generar specs a partir del codigo actual
spec-gen generate --output .openspec/archive/baseline/
# Resultado:
# Analyzed 12 Terraform modules
# Generated 12 spec files in .openspec/archive/baseline/specs/
# Generated design.md with architectural decisions
# Generated tasks.md with current implementation statusDeteccion de drift en CI con GitHub Actions
Integra spec-gen en tu pipeline de CI para detectar cuando el codigo ha divergido de las especificaciones documentadas:
YAML
# .github/workflows/spec-drift.yaml
name: Spec Drift Detection
on:
pull_request:
paths:
- 'terraform/**'
- 'k8s/**'
jobs:
spec-drift:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Node.js
uses: actions/setup-node@v4
with:
node-version: '20'
- name: Install spec-gen
run: npm install -g spec-gen
- name: Detect spec drift
run: |
spec-gen analyze ./terraform/modules/ --compare .openspec/archive/baseline/
if [ $? -ne 0 ]; then
echo "::error::Spec drift detected. Run 'spec-gen analyze' locally and update specs."
exit 1
fi
- name: Verify active spec exists for changes
run: |
CHANGED_MODULES=$(git diff --name-only origin/main -- terraform/ | head -20)
if [ -n "$CHANGED_MODULES" ] && [ -z "$(ls .openspec/active/ 2>/dev/null)" ]; then
echo "::error::Terraform changes detected without an active OpenSpec proposal."
echo "Run '/opsx:propose' before making infrastructure changes."
exit 1
fiPre-commit hooks
Agrega un hook de pre-commit que verifique la existencia de specs para cambios de infraestructura:
YAML
# .pre-commit-config.yaml
repos:
- repo: local
hooks:
- id: openspec-check
name: Verify OpenSpec proposal exists
entry: bash -c 'if git diff --cached --name-only | grep -q "terraform/\|k8s/"; then ls .openspec/active/*/proposal.md >/dev/null 2>&1 || (echo "ERROR: No active OpenSpec proposal found for IaC changes. Run /opsx:propose first." && exit 1); fi'
language: system
pass_filenames: falseTests spec-driven
spec-gen puede generar tests a partir de las especificaciones. Los criterios de aceptacion de
proposal.md se convierten en assertions verificables:BASH
# Generar tests a partir de la spec activa
spec-gen test --spec .openspec/active/add-storage-module/
# Resultado: genera tests que validan los criterios de aceptacion
# - test_storage_replication_is_grs.py
# - test_storage_soft_delete_enabled.py
# - test_storage_private_endpoint.py
# - test_storage_tls_minimum.py5.3 Nivel Avanzado: Orquestacion enterprise
Esquemas personalizados
Para Platform Engineering, puedes crear un esquema personalizado que incluya secciones especificas para tu organizacion:
YAML
# .openspec/config.yaml - esquema personalizado
schema: custom
custom_schema:
proposal:
required_sections:
- context
- requirements
- security_impact # Seccion obligatoria para Platform Eng
- tenant_impact # Impacto en tenants de la plataforma
- cost_estimation # Estimacion de costes cloud
- acceptance_criteria
- rollback_plan # Plan de rollback obligatorio
specs:
templates:
- terraform-module.md
- k8s-manifest.md
- network-policy.md
design:
required_sections:
- architecture_decision
- alternatives_evaluated
- security_review
- compliance_checklist # GDPR, SOC2, ISO27001
tasks:
max_items: 15
require_estimation: true # Cada tarea con estimacion de tiempo
require_owner: true # Asignar responsable por tareaIntegracion con MCP server (spec-gen)
spec-gen incluye un servidor MCP (Model Context Protocol) que permite a los agentes IA consultar specs de forma programatica. Esto es especialmente util para flujos multi-agente donde un agente orquestador necesita leer la spec antes de delegar trabajo:
JSON
// Configuracion MCP para OpenCode/Claude Code
// .mcp.json o mcp_servers en config
{
"mcpServers": {
"spec-gen": {
"command": "spec-gen",
"args": ["mcp-server"],
"env": {
"SPEC_ROOT": ".openspec",
"LLM_PROVIDER": "anthropic"
}
}
}
}Con el servidor MCP activo, el agente puede invocar herramientas como
spec-gen:analyze, spec-gen:drift y spec-gen:generate directamente durante una sesion de trabajo.Workflow de decisiones (ADR tracking)
El archivo
design.md de cada spec funciona como un Architecture Decision Record (ADR) ligero. En el directorio archive/, acumulas un historial de decisiones arquitectonicas consultable:MARKDOWN
# .openspec/active/add-storage-module/design.md
## Decision: Usar Private Endpoint en vez de Service Endpoint
### Contexto
Azure ofrece dos mecanismos de conectividad privada para Storage:
Service Endpoints (gratuitos, subnet-level) y Private Endpoints
(coste por hora, IP privada dedicada).
### Decision
Private Endpoint.
### Justificacion
- Service Endpoints no proporcionan IP privada (el trafico sale por backbone Azure pero la resolucion DNS sigue siendo publica)
- Private Endpoint permite DNS resolution privada end-to-end
- Requerido por la politica de seguridad SOC2-CC6.1
### Alternativas descartadas
- Service Endpoint: no cumple requisito de DNS privado
- VNet Integration: no disponible para Storage AccountTrabajo paralelo multi-agente con worktrees
Cuando multiples agentes trabajan en paralelo sobre la misma plataforma, cada uno opera sobre su propia spec activa. Combinado con
git worktree, puedes tener agentes trabajando simultaneamente sin conflictos:BASH
# Agente 1: trabajando en el modulo de storage
git worktree add ../platform-storage feature/add-storage-module
cd ../platform-storage
# /opsx:apply add-storage-module
# Agente 2: trabajando en network policies (en paralelo)
git worktree add ../platform-network feature/update-network-policies
cd ../platform-network
# /opsx:apply update-network-policies
# Cada agente tiene su propia spec activa y su propio worktree
# Sin conflictos de merge hasta el PR6. Mejores Practicas y Anti-patrones
Practica correcta |
Anti-patron |
|---|---|
Una spec por cambio logico |
Meter 10 cambios en una sola spec |
Revisar proposal.md antes de /opsx:apply |
Ejecutar /opsx:apply sin leer la propuesta |
Usar schema spec-driven para IaC critica |
Usar minimalist para cambios de produccion |
Archivar specs completadas (/opsx:archive) |
Borrar specs o dejarlas en active/ indefinidamente |
Definir criterios de aceptacion verificables |
Criterios vagos como "que funcione bien" |
Integrar drift detection en CI |
Confiar en que los specs se mantienen actualizados solos |
Documentar decisiones en design.md (ADR) |
Tomar decisiones de arquitectura en Slack/verbal |
Limitar tasks.md a 15 tareas maximo |
Specs con 50+ tareas (senal de que necesitas dividir) |
Usar spec-gen para baseline de codebases existentes |
Escribir specs manualmente para codigo legacy |
7. Integracion con el Ecosistema OpenCode
OpenSpec como skill de OpenCode
OpenSpec aparece como skill disponible en el ecosistema de OpenCode. Puedes instalarlo como un skill que el agente carga automaticamente cuando detecta un directorio
.openspec/ en tu proyecto:JSON
// .opencode/skills/openspec-sdd.json
{
"name": "openspec-sdd",
"trigger": "opsx",
"description": "Activa el flujo Spec-Driven Development con OpenSpec",
"instruction": "Al detectar el directorio .openspec/ o recibir el trigger 'opsx':\n1. Lee .openspec/config.yaml para entender el esquema activo\n2. Si el usuario pide un cambio de infraestructura, SIEMPRE ejecuta /opsx:propose primero\n3. NO generes codigo hasta que la spec este revisada y aprobada\n4. Usa /opsx:apply solo despues de confirmacion explicita\n5. Archiva con /opsx:archive al completar",
"context_files": [".openspec/config.yaml"]
}Instalacion de skills desde repositorios
Los skills de OpenSpec estan disponibles en los repositorios de la comunidad de OpenCode. Puedes referenciar OpenSpec desde la lista curada awesome-opencode e instalarlo como cualquier otro skill:
BASH
# Clonar el skill a tu directorio de skills
mkdir -p .opencode/skills/
curl -o .opencode/skills/openspec-sdd.json \
https://raw.githubusercontent.com/awesome-opencode/awesome-opencode/main/skills/openspec-sdd.jsonAgent-guard: validacion pre-ejecucion
La combinacion de OpenSpec con un agente orquestador de OpenCode crea un patron de agent-guard donde el agente no puede ejecutar cambios de infraestructura sin una spec activa aprobada. Esto se configura en el prompt del orquestador:
JSON
{
"agent": {
"nv-orchestrator": {
"mode": "primary",
"model": "claude-3-5-sonnet-20241022",
"prompt": "REGLA CRITICA: Si el usuario pide un cambio en terraform/ o k8s/, verifica que exista un directorio en .openspec/active/ con una proposal.md aprobada. Si NO existe, ejecuta /opsx:propose primero. NUNCA delegues a nv-code sin una spec activa. Esta regla no tiene excepciones.",
"constraints": {
"require_active_spec_for": ["terraform/**", "k8s/**", "helm/**"]
}
}
}
}Este patron convierte la especificacion en un gate obligatorio antes de cualquier cambio de infraestructura, eliminando el riesgo de que un agente escriba codigo sin contrato previo.
8. Conclusion: cuando adoptarlo, cuando no
Adopta OpenSpec cuando:
- Tu equipo usa agentes IA para generar IaC (Terraform, Pulumi, CloudFormation) y necesitas gobernanza sobre lo que generan.
- Trabajas en una plataforma multi-tenant donde un cambio mal especificado impacta a multiples equipos.
- Necesitas trazabilidad de decisiones arquitectonicas (compliance, auditorias SOC2/ISO27001).
- Quieres onboarding rapido: los nuevos ingenieros leen
.openspec/archive/y entienden el por que de cada componente. - Tu CI necesita detectar drift entre lo documentado y lo implementado.
No adoptes OpenSpec cuando:
- Tu proyecto es un prototipo o MVP donde la velocidad de iteracion es mas importante que la gobernanza.
- Trabajas solo y no necesitas coordinacion entre humanos y agentes.
- Tu equipo no usa agentes IA en el flujo de desarrollo (OpenSpec es especificamente para el gap humano-agente).
- Ya tienes un sistema de specs maduro (RFCs internos, ADRs con tooling propio) que funciona bien.
OpenSpec no reemplaza tus procesos existentes de code review o change management. Los complementa al agregar una capa de especificacion temprana que reduce el ruido en los PRs y asegura que el agente IA y el ingeniero humano estan alineados antes de escribir la primera linea de codigo.
Repositorios de referencia:
- OpenSpec: https://github.com/Fission-AI/OpenSpec
- spec-gen (clay-good): disponible via npm como companion tool
:wq!
Comentarios