Home Linux & Systems Cybersecurity Cloud & DevOps Networks & Infrastructure SIEM & Monitoring DFIR & Threat Intel Development & Other All categories Projects About Tools

OpenSpec: Spec-Driven Development for Platform Engineering with AI Agents

Leer en espanol
OpenSpec: Spec-Driven Development for Platform Engineering with AI Agents

Table of contents

AI agents without specifications = controlled chaos If you have worked with AI coding agents (Claude Code, OpenCode, Cursor, Copilot Agent) in p ===

1. Introduction: The problem that OpenSpec solves

AI agents without specifications = controlled chaos

If you've worked with AI coding agents (Claude Code, OpenCode, Cursor, Copilot Agent) on Platform Engineering projects, you've probably experienced the following pattern: you ask the agent to create a Terraform module for a Storage Account, and the result compiles, passes terraform validate, but it does not have soft-delete, it does not use Private Endpoint, and the replication is LRS instead of GRS. The agent wrote correct code for a specification that never existed.
This is the gap between intention and implementation. When a human describes a change in natural language, there is an inherent loss of information. The agent interprets, assumes, and generates. Without an intermediate contract that defines that will be built before writing as, the result is unpredictable.
In Platform Engineering, where a misspecified change can cause a drop in production, infrastructure drift or a security breach, this gap is unacceptable. You need a layer of specification between the human request and the agent's execution. That's exactly what it solves OpenSpec.

2. What is OpenSpec

Definition and philosophy

OpenSpec It is a framework Spec-Driven Development (SDD) created by Fission-AI (41.8k stars on GitHub). Adds a light layer of specification for humans and AI agents to agree on what to build before that a single line of code is written.
The central philosophy is: fluid, not rigid; iterative, not waterfall. OpenSpec doesn't force you to write 50-page documents before you start. Instead, it proposes a rapid cycle of propose → apply → archive where each change has its own folder with proposal, specifications, design and tasks.

Differentiation: OpenSpec vs Spec Kit vs Kiro

Feature
OpenSpec (Fission-AI)
Spec Kit (GitHub)
Kiro (AWS)
Approach
SDD agnositco (25+ tools)
Copilot-centric
AWS own IDE
Compatibility
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)
Schemes
spec-driven, minimalist, event-driven
Fixed
Fixed (steering)
Open Source
Yeah
Yeah
No (owner)
reverse engineering
spec-gen (companion tool)
No
No

3. Architecture and Key Components

Installing the CLI

OpenSpec is distributed as a global npm package:
BASH
npm install -g @fission-ai/openspec@latest
Verify the installation:
BASH
openspec --version

Workflow lifecycle: propose, apply, archive

The OpenSpec flow is based on three slash commands that you can invoke from any compatible AI agent:
  • /opsx:propose: Create a new change proposal. The agent generates a folder with proposal.md, the directory specs/, design.md and tasks.md.
  • /opsx:apply: Executes the tasks defined in the spec, generating the actual code.
  • /opsx:archive: Moves the completed spec to the history file for future reference.

OpenSpec directory structure

Each change managed by OpenSpec gets its own folder within the specifications directory:
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/
This structure guarantees complete traceability. Each change has its context, its decisions and its history. In a Platform Engineering team, this allows us to audit who proposed what, when and why.

Outline system

OpenSpec offers three predefined schemes that determine the depth of the generated specifications:
  • spec-driven (default): Generates complete specs with proposal, design, tasks and individual specification files. Ideal for critical infrastructure changes.
  • minimalist: Only generate proposal.md and tasks.md. For minor changes or hotfixes where the complete ceremony does not add value.
  • event-driven: Oriented to event-based systems. Generate specs with event flowcharts and message contracts.

Anatomy of config.yaml

The file config.yaml in .openspec/ define the behavior of the framework for your project:
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
The field schema It is the most critical. For Platform Engineering I recommend spec-driven whenever the change affects infrastructure in production, and minimalist for changes in documentation or auxiliary scripts.

4. Use Cases in Platform Engineering

IaC Change Governance (Terraform)

When an engineer needs to add a Terraform module, the OpenSpec flow forces a specification before generation:
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
With this proposal as a contract, the AI ​​agent generates code that meets the exact requirements. If something is missing, it is detected in the spec review, not after a terraform apply in production.

GitOps workflows with spec validation

In a GitOps flow, Pull Requests that modify infrastructure may require an approved spec to exist before merging. This is implemented with a check in CI that verifies the presence of the directory .openspec/active/ corresponding to the change.

Multi-tenant platform changes

When you manage a platform that serves multiple teams, each structural change needs to document its impact on all tenants. The OpenSpec spec includes impact sections that force the author (human or AI) to consider side effects before implementing.

Developer Experience: onboarding with specs

The directory .openspec/archive/ it becomes a living knowledge base. A new engineer can read the archived specs to understand why the infrastructure is the way it is, what alternatives were evaluated, and what decisions were made.

CI/CD: drift detection with spec-gen

spec-gen (by clay-good) is OpenSpec's companion tool for reverse engineering. Analyze your existing codebase, generate specs from the current code, and detect drift between the documented specs and the actual implementation. Supports 9 LLM providers and offers an MCP server for integration with agents.

5. Progressive Implementation Guide

5.1 Basic Level: Init and first flow

Initialize OpenSpec in your existing project:
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
Now open your preferred AI agent (OpenCode, Claude Code, Cursor...) and run the first slash command:
CODE
/opsx:propose Crear modulo Terraform para Azure Storage Account con Private Endpoint y soft-delete
The agent will generate the complete structure in .openspec/active/crear-modulo-terraform-storage/. Check the proposal.md and the generated specs. If everything is correct:
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 Intermediate Level: Integration with toolchain

spec-gen: reverse engineering of specs

If you already have an existing codebase without specs, spec-gen can analyze your code and generate retroactive specifications:
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

Drift detection in CI with GitHub Actions

Integrate spec-gen into your CI pipeline to detect when code has diverged from documented specifications:
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

Add a pre-commit hook that checks for the existence of specs for infrastructure changes:
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

Spec-driven tests

spec-gen can generate tests from specifications. The acceptance criteria of proposal.md They become verifiable assertions:
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 Advanced Level: Enterprise Orchestration

Custom schemes

For Platform Engineering, you can create a custom outline that includes sections specific to your organization:
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

Integration with MCP server (spec-gen)

spec-gen includes an MCP (Model Context Protocol) server that allows AI agents to programmatically query specs. This is especially useful for multi-agent flows where an orchestrating agent needs to read the spec before delegating work:
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"
      }
    }
  }
}
With the MCP server active, the agent can invoke tools such as spec-gen:analyze, spec-gen:drift and spec-gen:generate directly during a work session.

Decision workflow (ADR tracking)

The file design.md of each spec works as a lightweight Architecture Decision Record (ADR). in the directory archive/, you accumulate a searchable history of architectural decisions:
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

Multi-agent parallel work with worktrees

When multiple agents work in parallel on the same platform, each one operates on its own active spec. Combined with git worktree, you can have agents working simultaneously without conflicts:
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. Best Practices and Anti-patterns

Correct practice
Anti-pattern
A spec per logical change
Put 10 changes in a single spec
Check proposal.md before /opsx:apply
Run /opsx:apply without reading the proposal
Using schema spec-driven for critical IaC
Use minimalist for production changes
Archive completed specs (/opsx:archive)
Delete specs or leave them active/indefinitely
Define verifiable acceptance criteria
Vague criteria such as "it works well"
Integrate drift detection into CI
Trust that the specs keep themselves up to date
Document decisions in design.md (ADR)
Make architectural decisions in Slack/verbal
Limit tasks.md to 15 tasks maximum
Specs with 50+ tasks (sign that you need to split)
Use spec-gen to baseline existing codebases
Manually writing specs for legacy code

7. Integration with the OpenCode Ecosystem

OpenSpec as an OpenCode skill

OpenSpec appears as a skill available in the OpenCode ecosystem. You can install it as a skill that the agent automatically loads when it detects a directory .openspec/ in your project:
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"]
}

Installation of skills from repositories

OpenSpec skills are available in the OpenCode community repositories. You can reference OpenSpec from the curated list awesome-opencode and install it like any other 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: pre-execution validation

Combining OpenSpec with an OpenCode orchestrator agent creates a pattern of agent-guard where the agent cannot execute infrastructure changes without an approved active spec. This is configured at the orchestrator prompt:
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/**"]
      }
    }
  }
}
This pattern converts the specification into a mandatory gate before any infrastructure change, eliminating the risk of an agent writing code without a prior contract.

8. Conclusion: when to adopt it, when not

Adopt OpenSpec when:
  • Your team uses AI agents to generate IaC (Terraform, Pulumi, CloudFormation) and you need governance over what they generate.
  • You work on a multi-tenant platform where a misspecified change impacts multiple teams.
  • You need traceability of architectural decisions (compliance, SOC2/ISO27001 audits).
  • You want fast onboarding: new engineers read .openspec/archive/ and they understand the reason for each component.
  • Your CI needs to detect drift between what is documented and what is implemented.
Don't adopt OpenSpec when:
  • Your project is a prototype or MVP where iteration speed is more important than governance.
  • You work alone and do not need coordination between humans and agents.
  • Your team does not use AI agents in the development flow (OpenSpec is specifically for the human-agent gap).
  • You already have a mature spec system (internal RFCs, ADRs with your own tooling) that works well.
OpenSpec does not replace your existing code review or change management processes. It complements them by adding an early specification layer that reduces noise in the PRs and ensures that the AI ​​agent and the human engineer are aligned. before to write the first line of code.
Reference repositories:

:wq!

Comments