OpenSpec or spec-kit? Two tools for spec-driven development — and why I chose OpenSpec

Spec-driven development is no longer just a discipline: it now has its tooling. Two open-source projects stand out — spec-kit, from GitHub, and OpenSpec. I looked at both; here’s an honest comparison, and why I chose OpenSpec.

Two tools, one principle

Both share the core of SDD: the specification before the code, versioned Markdown artifacts. The difference is in the lifecycle and in what persists.

• spec-kit runs a guided path — Spec → Plan → Tasks → Implement — with templates, a CLI and prompts, designed around AI coding agents (thirty-plus integrations, no lock-in). Great for kicking off a feature with an agent, batteries included.
• OpenSpec works in changes — propose → apply → archive — where archived specs merge into a durable source of truth (specs/). Plain Markdown and a CLI, presuming no particular agent.

Why OpenSpec, for me

• Ease of use. Immediate to pick up, low ceremony: you write an intent, implement it, archive it. The tool gets out of the way of the work.
• Tool-agnostic. Versioned Markdown and a CLI, tied to no particular agent or IDE — where spec-kit, itself multi-agent, is still built for agents, OpenSpec presumes none. I keep my freedom of tool and of model, consistent with what I say about SDD: the spec outlives the models.
• Archiving and sync. Each archived change syncs its spec into the source of truth. It’s not starter scaffolding you throw away: it’s the product’s memory, growing with every increment.
• Progressive. You can introduce it on an existing product that never used it — one change at a time, no big bang, no restructuring. Adoption happens at your pace.

That’s exactly the profile I need: a quiet companion for products that live over the long run, not just for the kickoff.

Sources

• OpenSpec — openspec.dev
• spec-kit (GitHub) — github.com/github/spec-kit