The Enso Method Get started

OpenSpec · Fission AI (lead maintainer Tabish Bidiwale) · as of September 30, 2026

OpenSpec never makes you write the whole spec, only the diff

A spec usually describes a feature you’re about to build. OpenSpec’s describes what your system does today, and every change is a small, reviewable edit to it. That’s why it works on code nobody ever documented.

This guide is written by EnsoDynamics, which makes the Enso Method. We compare our method with others as fairly as we can, and we recommend another method when it fits you better.

Two philosophies at a glance

OpenSpec

Keep a light, living spec of what the system does now, and agree each change as a small diff to it before any code is written.

The Enso Method

Define the whole body of work before the build, keep its documents current, and keep building while the people who decide confirm the open questions.

Where they differ

  • One change at a time The whole body of work up front OpenSpec sits at the “One change at a time” end; the Enso Method sits at the “The whole body of work up front” end.
  • The developer at the keyboard decides Someone who isn’t at the keyboard decides OpenSpec sits at the “The developer at the keyboard decides” end; the Enso Method sits at the “Someone who isn’t at the keyboard decides” end.
  • Stops and asks Decides, records it, keeps going OpenSpec sits toward “Stops and asks”; the Enso Method sits at the “Decides, records it, keeps going” end.
  • Passing tests are enough Every requirement proven against real systems OpenSpec sits toward “Passing tests are enough”; the Enso Method sits at the “Every requirement proven against real systems” end.

What they share

  • Specs serve one change Specs live as long as the system OpenSpec sits at the “Specs live as long as the system” end; the Enso Method sits at the “Specs live as long as the system” end.
  • Starts from a prompt Intent written down first OpenSpec sits at the “Intent written down first” end; the Enso Method sits at the “Intent written down first” end.

Neither end of a line is the right one. Every comparison uses the same lines, so you can compare across methods.

Specs are what’s true; changes are diffs

“Specs are the source of truth — they describe how your system currently behaves.” That line from OpenSpec’s concepts guide is the whole method in one sentence.

If the spec describes the system as it is, a change can’t be a fresh document. It has to be an edit: requirements ADDED, MODIFIED or REMOVED against the spec that’s already there. While the work is in flight, those deltas sit in their own folder, where you can review them or run two changes side by side. When the work is done, they merge in, and the spec describes the new reality.

The payoff comes on existing systems. “You do not document your whole codebase to start. You write specs only for what you’re about to change.” Your first change writes your first spec. The rest stays unwritten until you touch it, on purpose: specs for code nobody is changing, the guide warns, “go stale, because nothing forces them to track reality.”

Propose, review, apply, archive

  1. Explore (optional). A thinking partner that reads your code and weighs options with you. It never writes code.
  2. Propose. One command drafts the change: proposal.md (why), delta specs (requirements with WHEN/THEN scenarios), design.md when the change needs one, and tasks.md. Then it stops, even if you asked it to build.
  3. Review. You read the plan while it’s still words, and edit it or ask for changes.
  4. Apply. The agent works through the tasks, ticking each off, and pauses when a task needs more than the spec says.
  5. Archive. The deltas merge into the main specs in openspec/specs/, and the change folder moves to a dated archive.

The guide for existing projects describes the result: “Your specs now describe exactly the part of the system that change touched, and nothing more. That’s correct.”

Built for changing code that already exists

OpenSpec fits a developer or team making a steady stream of changes to a running product, who wants a current record of what it does. On a team, the change folder rides the same pull request as the code, so reviewers read the intent before the diff.

It asks little up front: openspec init, then a short plan before each change (“Plain truth: OpenSpec adds a step”). It leaves it to you to keep each change focused and to archive it when it’s done. It suits you less if you want a whole product planned before the build, or an agent that runs for hours unattended. And for a one-line fix, by its own account, “the ceremony may not pay off.”

Where the Enso Method made a different call

Both keep a written description of the system that outlives each change, and neither back-fills it: OpenSpec warns that specs for untouched code go stale, and the Enso Method’s design standard says a description of existing code “only goes stale.” They part ways on three things.

How far ahead you write it down

OpenSpec

One change at a time, each with “one intent you can say in a sentence.” The spec grows as changes land.

The Enso Method

The whole body of work comes first: a PRD and technical design, cut into session-sized phases.

Choose by situation: for a stream of changes to a running product, OpenSpec asks less up front. For work someone needs to see whole before it’s built, the Enso Method fits.

Who answers the open questions

OpenSpec

You do. When an ambiguity would change scope, behavior or acceptance criteria, the agent asks before writing the plan, and mid-build it pauses rather than guess.

The Enso Method

The agent researches, picks its best answer and keeps building. Business questions become written assumptions with a confidence level, for the people who decide to confirm later.

Choose by situation: if the decisions are yours, asking in the chat is quickest. If they belong to someone who isn’t at the keyboard, the Enso Method is built for that.

What counts as done

OpenSpec

Each task names how it will be verified, and an optional verify step checks the code against the specs. It “does not block archiving — it surfaces the gaps and leaves the call to you.”

The Enso Method

Each acceptance criterion needs a test that would fail if the behavior were wrong, run against real systems where they exist.

Choose by situation: OpenSpec stays light and leaves proof to your CI and your reviewers. The Enso Method spends time and tokens to make proof part of finishing.

Where OpenSpec shines

  • One answer to “what does this software do?” That’s OpenSpec’s own phrase for its specs: each capability has one spec of its current behavior. The Enso Method has a real gap here: its documents are organized by piece of work, so today’s behavior of one feature can be spread across several PRDs.
  • Starting on legacy code costs nothing. There is nothing to back-fill before the first change, which is what Thoughtworks’ Technology Radar singled out.
  • Requirements you can diff. Reviewers see exactly which requirements a change adds, modifies or removes before they read any code, and a validator rejects malformed ones.
  • It runs almost anywhere. It supports more than 30 coding assistants; the Enso Method is written for Claude Code and Codex.

How the Enso Method differs, and why

OpenSpec specifies one change at a time and folds each one into a living description of what the system does now, with you answering the questions that matter as the plan is drawn up. The Enso Method defines the whole body of work first, in a PRD and technical design it keeps current, and keeps building on recorded assumptions while the people who decide confirm them. It counts work as finished only when every acceptance criterion is proven, against real systems wherever they exist.

How the Enso Method works Compare all the methods

Get started

OpenSpec is free and open source (MIT). It needs Node.js 20.19 or later, installs with npm or Homebrew, and sets itself up in your project with openspec init; the instructions are in the README at github.com/Fission-AI/OpenSpec.