Inicio Linux & Systems Networks & Infrastructure Cybersecurity Cloud & DevOps SIEM & Monitoring DFIR & Threat Intel Development & Other Todas las categorias Herramientas

OpenSpec: Spec-Driven Development para Platform Engineering con Agentes IA

OpenSpec: Spec-Driven Development para Platform Engineering con Agentes IA

Tabla de contenidos

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@latest
Verifica la instalacion:
BASH
openspec --version

Ciclo 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 con proposal.md, el directorio specs/, design.md y tasks.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: true
El 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.md
Con 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-driven
Ahora 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-delete
El 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-storage

5.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 status

Deteccion 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
          fi

Pre-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: false

Tests 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.py

5.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 tarea

Integracion 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 Account

Trabajo 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 PR

6. 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.json

Agent-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:

:wq!

Comentarios