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@latestVerify the installation:
BASH
openspec --versionWorkflow 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 withproposal.md, the directoryspecs/,design.mdandtasks.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: trueThe 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.mdWith 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-drivenNow 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-deleteThe 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-storage5.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 statusDrift 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
fiPre-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: falseSpec-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.py5.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 tareaIntegration 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 AccountMulti-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 PR6. 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.jsonAgent-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:
- OpenSpec: https://github.com/Fission-AI/OpenSpec
- spec-gen (clay-good): available via npm as a companion tool
:wq!
Comments