Skip to content
/

IBM IaC Spec Kit

iac-spec-kit · IBM/iac-spec-kit · ★ 64 · last commit 2026-03-02

Adapts SDD methodology to IaC by separating generic infrastructure specifications from cloud-specific implementation plans, enabling multi-cloud comparison and team readability.

Best whenInfrastructure specs should use generic vocabulary (managed database, object storage) not cloud-specific terms — the plan stage translates to provider specif…
vs seeds
spec-kit(GitHub Spec Kit), sharing its 9-command + template architecture and Python CLI binary. The unique contribution is domai…
Primitive shape 9 total
Commands 9
00

Summary

IBM IaC Spec Kit — Summary

IBM IaC Spec Kit (v0.0.7) is a specialization of GitHub's Spec Kit methodology adapted for Infrastructure as Code workflows with Terraform and cloud providers. It ships a Python CLI (iac-specify), 9 slash commands (all .iac.* prefixed), IaC-centric templates (spec, plan, tasks, principles, agent file), and multi-cloud support (AWS, Azure, GCP, IBM Cloud, Oracle Cloud). Its key insight is separating generic infrastructure requirements ("what you need") from cloud-specific implementation ("how to build it with specific services") — the spec stage uses generic terms, the plan stage maps them to provider-specific resources. IBM contributed this as an open-source experiment exploring whether SDD improves IaC quality, with explicit acknowledgment that it's a fork of GitHub's Spec Kit. Compared to seeds, IaC Spec Kit is structurally identical to spec-kit (9 commands, corresponding templates, CLI binary) but narrows the problem domain to infrastructure, adds cloud-provider agnosticism as a design principle, and removes lifecycle hooks in favor of a simpler command surface.

01

Overview

IBM IaC Spec Kit — Overview

Origin

IBM contributed IaC Spec Kit as an open experiment on GitHub (IBM/iac-spec-kit). v0.0.7, Python-based. Explicitly a specialized fork of GitHub's Spec Kit. 64 stars, IBM organizational contributor. Last committed March 2026.

Philosophy

SDD applied specifically to infrastructure:

"Specification-Driven Development (SDD) is an emerging methodology where detailed specifications are created before code. The specification becomes your single source of truth, guiding AI agents to generate implementation plans and production-ready code."

Key principles for infrastructure:

  1. Generic first: Specs use generic infrastructure terms ("managed database"), not cloud-specific ("AWS RDS")
  2. Cloud-agnostic specs: The same spec can be planned for multiple clouds by re-running /iac.plan with different providers
  3. Terraform-adjacent: Templates geared toward Terraform but work with any IaC tool
  4. AI-guided: Cloud-specific expert knowledge is delegated to AI (configure MCP servers for cloud docs)

Infrastructure-Specific Command Namespace

All commands use .iac prefix: /iac.principles, /iac.specify, /iac.plan, /iac.tasks, /iac.implement, /iac.enrichplan, /iac.clarify, /iac.analyze, /iac.checklist.

Experimental Nature

From README:

"IaC Spec Kit is an experimental project exploring how Specification-Driven Development can improve infrastructure as code workflows."

IBM frames this as exploration, not a production-ready tool. The IDEAS.md file in the repo collects potential future directions.

Acknowledgment

"IaC Spec Kit is a specialized implementation of the GitHub Spec Kit toolkit, adapted for Infrastructure as Code workflows with Terraform and cloud providers."

02

Architecture

IBM IaC Spec Kit — Architecture

Distribution

  • Type: Python CLI + template bundle
  • Install: uv tool install iac-specify-cli --from git+https://github.com/ibm/iac-spec-kit.git
  • Language: Python 3.11+
  • Version analyzed: 0.0.7

Installation

uv tool install iac-specify-cli --from git+https://github.com/ibm/iac-spec-kit.git
iac-specify init PROJECT_NAME

One-time

uvx --from git+https://github.com/ibm/iac-spec-kit.git iac-specify init PROJECT_NAME

Directory Tree (post-init)

project/
├── specs/
│   └── 1-production-vpc/        # numbered branches
│       ├── spec.md               # Infrastructure specification
│       ├── plan.md               # Architecture plan (cloud-specific)
│       ├── tasks.md              # Implementation task list
│       └── .workflow-state.json  # Optional progress state
├── principles.md                 # Infrastructure governance principles
├── AGENTS.md                     # Agent context file
└── [AI tool command directories]
    └── commands/
        ├── iac.specify.md
        ├── iac.plan.md
        ├── iac.tasks.md
        ├── iac.implement.md
        ├── iac.enrichplan.md
        ├── iac.clarify.md
        ├── iac.analyze.md
        ├── iac.checklist.md
        └── iac.principles.md

Required Runtime

  • Python 3.11+
  • uv (for installation)
  • Git

Target AI Tools

Multiple — the /iac.* commands are deployed for Claude Code, Cursor, and GitHub Copilot. The template system supports any AI tool with slash commands.

Scripts

scripts/
├── bash/create-new-feature.sh   # Creates numbered branch + spec directory
└── powershell/create-new-feature.ps1

The iac.specify command calls these scripts to create numbered infrastructure branches and spec directories.

03

Components

IBM IaC Spec Kit — Components

Commands (9 slash commands, all .iac.* prefixed)

Command Purpose
/iac.principles Define infrastructure governance principles
/iac.specify Create infrastructure specification from natural language
/iac.plan Generate cloud-specific architecture plan
/iac.tasks Break plan into Terraform/IaC implementation tasks
/iac.implement Execute implementation tasks
/iac.enrichplan Deep enrichment: Well-Architected Framework analysis, module specs, quickstart
/iac.clarify Clarify ambiguous infrastructure requirements
/iac.analyze Analyze existing infrastructure
/iac.checklist Generate infrastructure checklist

CLI Binary (iac-specify)

Subcommand Purpose
iac-specify init <PROJECT_NAME> Initialize IaC project with spec directory and templates
iac-specify check Validate project setup

Skills

None.

Subagents

None.

Hooks

None. No lifecycle hooks.

MCP Servers

None bundled. README recommends configuring cloud provider MCP servers (e.g., AWS docs, IBM Cloud) for better implementation guidance.

Scripts

2 scripts:

  • scripts/bash/create-new-feature.sh — creates numbered branches + spec directories
  • scripts/powershell/create-new-feature.ps1 — Windows equivalent

Templates

5 template files:

  • templates/spec-template.md — infrastructure specification template
  • templates/plan-template.md — architecture plan template
  • templates/tasks-template.md — task list template
  • templates/principles-template.md — infrastructure principles template
  • templates/agent-file-template.md — AGENTS.md template
  • templates/checklist-template.md — infrastructure checklist template
  • templates/vscode-settings.json — VS Code configuration

State Files

  • specs/<N>-<name>/spec.md
  • specs/<N>-<name>/plan.md
  • specs/<N>-<name>/tasks.md
  • principles.md
05

Prompts

IBM IaC Spec Kit — Prompts

Prompt 1: /iac.specify — Infrastructure Specification Creation

Source: templates/commands/iac.specify.md

Technique: Script-backed initialization with AI content generation. The command first calls a shell script to create the numbered directory/branch, then AI generates the spec content.

---
description: Create or update the infrastructure specification from a natural language 
infrastructure description.
scripts:
  sh: scripts/bash/create-new-feature.sh --json "{ARGS}"
  ps: scripts/powershell/create-new-feature.ps1 -Json "{ARGS}"
---

## Outline

Given that infrastructure description, do this:

1. **Generate a concise short name** (2-4 words) for the branch:
   - Use action-noun format (e.g., "deploy-vpc", "configure-database")
   - Preserve technical terms (VPC, RDS, K8s, etc.)
   - Examples: "Deploy production VPC" → "production-vpc"

2. **Check for existing branches before creating new one**:
   - git fetch --all --prune
   - Check remote branches, local branches, AND specs directories
   - Find highest existing number N → use N+1 for new branch

3. Run the script with calculated number and short-name

Notable technique: AI generates the branch name from the natural language description using action-noun format — the spec structure (numbered directory) is computed deterministically, the naming is AI-generated. Script runs only once per component.


Prompt 2: /iac.enrichplan — Deep Infrastructure Enrichment

Source: templates/commands/iac.enrichplan.md (inferred from README)

Technique: Comprehensive research enrichment — multiple analysis passes generating:

  1. Well-Architected Framework analysis (reliability, security, cost, performance, sustainability)
  2. Curated module specifications
  3. Detailed architecture documentation
  4. Provisioning quickstart guide

This is a depth-over-speed command: the README notes it generates "deep research" and is suitable for "quality-critical or complex projects."


Prompt 3: Generic vs. Specific Framing

Source: templates/commands/iac.specify.md (inference from README philosophy section)

Technique: Explicit two-stage framing — spec stage uses generic infrastructure vocabulary, plan stage uses cloud-specific vocabulary.

From README:

/iac.specify "I need a managed database with automated backups and encryption"
→ spec.md uses: "managed database", "encryption at rest", "automated backup"
   (no cloud-specific terms)

/iac.plan "Deploy in AWS us-east-1"
→ plan.md translates: "managed database" → "Amazon RDS for MySQL"
   "encryption at rest" → "AWS KMS with RDS encryption"
   "automated backup" → "RDS automated backups with 7-day retention"

This two-stage generic→specific translation is the framework's defining workflow contribution.

09

Uniqueness

IBM IaC Spec Kit — Uniqueness & Positioning

differs_from_seeds

IaC Spec Kit explicitly self-identifies as a specialization of spec-kit (GitHub's Spec Kit), and structurally mirrors it: CLI binary + 9 commands + corresponding templates. The key divergence is domain specificity: where spec-kit targets general software, IaC Spec Kit targets infrastructure as code, adding infrastructure governance principles, cloud-agnostic spec vocabulary (generic → cloud-specific translation in plan phase), and Terraform-centric tasks. Unlike spec-kit's 18 lifecycle hooks, IaC Spec Kit has none — a regression in automation for the benefit of simplicity. The generic-to-specific translation pattern (spec uses "managed database", plan translates to "AWS RDS") is the framework's unique architectural contribution — not present in any of the 11 seeds.

Positioning

IaC Spec Kit occupies a unique vertical niche: SDD for infrastructure teams. It's the only framework in this batch (and likely across the full 350+ catalog) that addresses multi-cloud infrastructure specification. The "specify once, plan for multiple clouds" capability enables cloud comparison workflows not possible in any other framework.

Distinctive Opinion

Generic infrastructure specifications should be decoupled from cloud-specific plans. Writing a spec that says "managed database" rather than "AWS RDS" enables cloud portability, team education (members unfamiliar with specific clouds can read the spec), and cost comparison across providers.

Observable Failure Modes

  1. CLI-heavy setup: Requires uv, git installation — not a one-liner for non-Python teams.
  2. No hooks: Unlike the original spec-kit's 18 hooks, IaC Spec Kit has none — no automated lifecycle enforcement.
  3. Experimental: IBM's README explicitly calls this "experimental" — not production-validated.
  4. Narrow audience: Only useful for teams doing IaC with Terraform or similar.

Explicit Antipatterns

None documented.

Cross-References

Explicitly forks GitHub Spec Kit. Acknowledges the source in README.

04

Workflow

IBM IaC Spec Kit — Workflow

Phases

Phase Command Artifact
0. Principles /iac.principles principles.md (governance, security, cost standards)
1. Specify /iac.specify <description> specs/<N>-<name>/spec.md (generic requirements)
2. Plan /iac.plan <cloud-provider> specs/<N>-<name>/plan.md (cloud-specific architecture)
2a. Enrich (optional) /iac.enrichplan Deep research, WAF analysis, module specs, quickstart
3. Tasks /iac.tasks specs/<N>-<name>/tasks.md (Terraform implementation tasks)
4. Implement /iac.implement Terraform/IaC code

Phase-to-Artifact Map

Phase Artifact
Principles principles.md
Specify specs/<N>-<name>/spec.md (generic: "managed database", not "AWS RDS")
Plan specs/<N>-<name>/plan.md (specific: maps generic to "AWS RDS", "Azure DB", etc.)
Tasks specs/<N>-<name>/tasks.md
Implement Terraform configurations

Cloud Agnosticism Workflow

The key workflow innovation: the SAME spec can be planned for different clouds:

/iac.specify "I need a managed database with automated backups"
/iac.plan "Use AWS RDS for MySQL"
# Later, for another environment:
/iac.plan "Use Azure Database for MySQL"

Both plans derive from the same generic spec. Teams can compare cloud options before committing.

Branch Numbering

The /iac.specify command calls create-new-feature.sh to create numbered branches (1-production-vpc, 2-managed-database). Numbers are auto-incremented from existing branches/directories.

Approval Gates

None mandated. User reads each artifact before proceeding. No automated gates.

Spec Format

Markdown. Generic infrastructure terms (no cloud specifics in spec stage).

Execution Mode

One-shot per phase. Sequential: principles → specify → plan → (optional: enrichplan) → tasks → implement.

06

Memory Context

IBM IaC Spec Kit — Memory & Context

State Storage

File-based under specs/:

File Purpose
specs/<N>-<name>/spec.md Generic infrastructure specification
specs/<N>-<name>/plan.md Cloud-specific architecture plan
specs/<N>-<name>/tasks.md Implementation task list
principles.md Infrastructure governance principles
AGENTS.md Agent context file

Memory Type

File-based.

Persistence Scope

Project-level.

Cross-Session Handoff

Simple file reads. No special resumption mechanism. AGENTS.md provides context loading instructions for agents.

Branch Numbering as Memory

The numbered branch structure (1-production-vpc, 2-managed-database) serves as an implicit progress index — the next number is always higher than the current highest, preventing collisions in multi-developer environments.

Compaction

Not applicable.

None.

07

Orchestration

IBM IaC Spec Kit — Orchestration

Multi-Agent

No. Single agent sequential workflow.

Orchestration Pattern

Sequential: principles → specify → plan → tasks → implement.

Isolation Mechanism

Git branches (via the create-new-feature.sh script which creates a branch per infrastructure component). Not git worktrees — different branches.

Multi-Model

No.

Execution Mode

One-shot per command. Sequential workflow with manual phase transitions.

Prompt Chaining

Yes. Spec → Plan (spec is input to plan); Plan → Tasks; Tasks → Implement.

Auto-Validators

None.

Hooks

None.

Git Automation

Partial. create-new-feature.sh creates branches automatically. No auto-commits, PRs, or merges.

Crash Recovery

No explicit mechanism. Files are durable; resumption requires re-reading the spec files.

From README:

"Configure MCP servers in advance" — recommends setting up cloud provider documentation MCP servers (AWS, IBM Cloud, etc.) before running /iac.plan so the AI has access to current service documentation.

This is an implicit multi-tool integration: the framework doesn't ship MCP servers but is designed to work best with externally configured cloud documentation MCP servers.

08

Ui Cli Surface

IBM IaC Spec Kit — UI & CLI Surface

Dedicated CLI Binary

Exists: Yes
Name: iac-specify
Is thin wrapper: No — Python CLI with project initialization logic
Install: uv tool install iac-specify-cli --from git+https://github.com/ibm/iac-spec-kit.git

CLI Subcommands

Subcommand Purpose
iac-specify init <PROJECT_NAME> Initialize IaC project (creates directory structure + templates)
iac-specify check Validate project setup

Local UI

Exists: No

IDE Integration

Commands deployed for Claude Code, Cursor, GitHub Copilot. VS Code settings template included (templates/vscode-settings.json).

Observability

None beyond the spec files.

  • Add search MCP capabilities (web search for latest cloud provider docs)
  • Configure cloud provider documentation MCP servers
  • Start fresh sessions between commands (recommendation to prevent context bleed)

Related frameworks

same archetype · same primary tool · same memory type

OpenHarness ★ 13k

Open-source Python agent runtime providing complete harness infrastructure: tools, memory, governance, swarm coordination, and…

Trae Agent ★ 12k

Research-friendly open-source CLI coding agent by ByteDance, designed for academic ablation studies and modular LLM provider…

Sweep AI ★ 7.7k

Autonomous GitHub bot that converts issues to pull requests using a sequential multi-agent pipeline.

Agent Governance Toolkit (microsoft) ★ 2.3k

Enterprise-grade AI agent governance: YAML policy enforcement, 12-vector prompt injection defense, zero-trust identity,…

TDD Guard ★ 2.1k

Mechanically enforces the Red-Green-Refactor TDD cycle by blocking file writes that violate TDD principles via a PreToolUse hook…

Agentic Coding Flywheel Setup (ACFS) ★ 1.5k

Take a complete beginner from laptop to three AI coding agents running on a VPS in 30 minutes via an idempotent manifest-driven…