Spec tools plan the next change. DurableSpec keeps the whole picture.
GitHub Spec Kit, OpenSpec and Kiro are the best-known spec tools for AI coding. Each is built around a unit of work: a feature or a change, specified, planned and built. DurableSpec is built around the system itself: one spec of record for what it is for, how it is shaped and why, kept accurate on every commit, by every person and every agent.
| DurableSpec | GitHub Spec Kit | OpenSpec | Kiro | |
|---|---|---|---|---|
| Built around | The whole system, across every change | A feature: specify, plan, tasks, implement | A change: propose, apply, archive | A feature spec: requirements, design, tasks |
| What the spec holds | Purpose and customers, architecture, conventions, and the decisions behind them | Per feature: requirements, a technical plan, a task list; plus a project constitution | Required behavior by domain, as requirements with scenarios | Per feature: requirements in EARS notation, a design, tasks; plus steering files for product, stack and structure |
| Where the “why” lives | Numbered decision records in one place, never edited, replaced explicitly, citable across repos | In each feature’s plan | In each change’s design notes, archived by date when the change is done | In each feature’s design, and in the steering files |
| When the spec moves | At every commit, under a rule whose default answer is “no change” | When the workflow runs for a feature | When a change is archived | When you work through a spec, or ask Kiro to update it |
| Code changed outside the workflow | Every design document names the code it governs, so any changed file traces to its document | Checked against the spec only for the feature in progress | Not tracked; specs change only through archived changes | Updated when someone asks |
| Architecture diagrams | C4 System Context and Container diagrams of the whole system, in Mermaid, redrawn in the commit that changes them | Whatever each feature’s plan includes | Whatever each change’s design notes include | Whatever each feature’s design includes |
| Who it’s written for | People first, engineers and business owners alike, then every agent | The agent doing the work | The agent and reviewers of a change | The agent in the Kiro IDE |
| Works with | Any agent: plain Markdown, AGENTS.md and Agent Skills; no runtime | About 30 agents, through a Python installer | 30+ tools, through a Node.js installer | Kiro’s own IDE and CLI |
| License | Apache 2.0 | MIT | MIT | Commercial |
Compiled October 2026 from each project’s own documentation. These tools change quickly; corrections are welcome at info@pikelabs.ai.
Three problems a spec per change doesn’t solve.
- The reasons get buried. Six months on, someone asks why billing stores amounts in their original currency. With a spec per change, the answer is in an archived folder for a change nobody remembers. In DurableSpec it is decision record 12, in one place, until a later record replaces it.
- The spec drifts. A hotfix, a refactor, an agent session that skipped the workflow: real codebases change outside any process. DurableSpec checks at every commit, and because each document names the code it governs, a change that should have moved the spec is visible.
- Nobody reads it. A pile of feature specs answers “what was built in sprint 14.” DurableSpec answers “what is this system and why,” in a few short documents that a new engineer, a product owner or tomorrow’s agent can read in minutes.
Use the right tool for the job, or both.
Spec Kit, OpenSpec and Kiro are better at planning new work: a proposal with tasks and testable behavior scenarios is a good way to steer an agent through a feature before any code exists. They are also more widely adopted. DurableSpec doesn’t replace that. It holds what those changes add up to: the standing architecture and the decisions behind it.
Plan the change with the tool you like. Keep the picture in DurableSpec.