The Enso Method: AI software development, done deliberately

The problem

Writing code is no longer the slow part.

Getting the requirements right is. Most AI workflows speed up the part that was already fast, and leave the three places real projects stall.

01

The build stalls on questions.

The agent stops to ask. The person who can answer is in a meeting, or in another time zone. By the time the answer arrives, the session has lost its context.

02

The spec rots after the first build.

A feature ships, the next change goes straight into the code, and the document that described the system now describes something else. The next session guesses.

03

“Done” means the agent said so.

Green tests against mocks and a summary that sounds finished. Nobody can say which requirement is actually proven.

The method

Six ideas, one discipline.

The skills are how the method runs. These are what it believes, and they hold whichever skill is doing the work.

一
The documents are the source of truth.

Every change amends the PRD and the technical design first, then gets built from that amendment. When the code and the PRD disagree, the PRD wins, so each new session starts from what was decided, not from guesses about the code.
二
Assumptions are green lights.

When a business question comes up, the agent researches it, proposes an answer, records it with its confidence, and keeps building. Stakeholders confirm or correct it on their own schedule. Nothing waits.
三
Research, don’t ask.

Technical questions are answered against the real code, data and APIs. Only genuine business decisions go to people, and they arrive as proposals, never as open questions.
四
Say what you want, not what to do.

Describe the outcome. The method turns it into acceptance criteria, a design and a plan, so the AI can tell you when your first idea is the wrong place to solve the problem.
五
Every phase ships.

Large work is cut into thin vertical slices, each sized to one AI session and verifiable on its own. When a phase turns out bigger than planned, it splits again.
六
Done means done.

Every acceptance criterion is backed by evidence from tests against real systems. Sessions end with the work finished, not with a list of caveats or promises of work that could be done now.

How it works

From idea to production, in one continuous line.

Each step is a skill your agent runs. Each one hands the next a document it can trust, and none of them stops to ask what the documents already answer.

Decide what to build

Roadmap prd-roadmap
Cuts an idea too big for one PRD into an ordered roadmap of PRDs, each ending in something that ships.
Requirements prd-writing-standards
A PRD in business language, with testable acceptance criteria and an explicit out of scope.
Design technical-design-writing-standards
Architecture, interfaces, data models and integration points, held to your house standards.
Refinement autonomous-requirements-refinement
Pass after pass, finds every gap, researches the answers and folds them into the documents. Checkpointed, so it resumes instead of restarting.

Build it in slices

Phasing phase-split
Cuts the work into independently shippable phases, each sized to one AI session.
Build implement-from-requirements
Loads every document, sizes the work, builds one phase and tests it against real resources. No one has to say which files to read.
Continue continuation-prompt
Hands the next phase to a fresh session that knows exactly which PRD and phase it serves.

Prove it works

Review deliverable-review
A fresh-eyes agent re-reads every changed file and traces each requirement to the output.
Harden test-hardening
Maps every acceptance criterion to evidence and upgrades mocks to real sandbox resources.
Ship production-hardening-audit
Before go-live, checks the service can be deployed, recovered and monitored, ranked by blast radius.

Change requests become a diff, not a detour.

When the business changes its mind mid-project, nobody patches the code directly. The requirements are amended and committed on their own, and the build works from that diff. The change is reviewable, the documents stay current, and nothing already built is re-derived.

1Amend the PRD and design
2Commit the amendment alone
3Build from the diff

The assumptions register

Stakeholders answer proposals, not questions.

Reacting to a proposed answer takes a stakeholder seconds. Answering an open question takes days. So the Enso Method never sends a list of questions. It writes each open business decision as a specific, plain-English assumption with the evidence behind it, a confidence level, the impact if it’s wrong, and a one-move way to confirm or correct it.

The build proceeds on it. When the replies come back, the answers flow into the PRD and the design, and anything already built on a corrected answer is flagged for rework.

< 60%Ask, with a proposed answer

60–94%Proceed and record an assumption

95%+Just do it

Example entry

RET-004

Can a refund go to store credit after 30 days?

Proposed answer: Yes. After 30 days, refunds go to store credit only, never back to the original card.
Why we think so: The published returns policy says “store credit after 30 days,” and 214 of the last 220 late refunds in the order history went to store credit.

Confidence 80% If wrong Refund routing changes in one place

Session-sized phases

Sized for the session you’re in, not the sprint you’re planning.

Each phase is a thin vertical slice with a handful of machine-verifiable acceptance criteria, built, tested and closed in a single AI session. The agent sizes the work itself and never stops to ask whether to split.

When a phase turns out bigger than planned, it splits again: 2 becomes 2a and 2b. Follow-up work found along the way is filed into the phase that will build it, so nothing important lives only in a chat that’s about to close.

PRD · Customer returns

Phase 1 · Return request intakeClosed
Phase 2 · Refund routingSplit
- 2a · Card refundsClosed
- 2b · Store creditBuilding
Phase 3 · Returns dashboardPlanned

Evidence, not claims

Finished means proven.

Fresh-eyes review

A separate agent re-reads every changed file from disk and traces each requirement to what was built. When the code and the PRD disagree, the PRD is right, and the review never trims a requirement to match the code.

Test hardening

Every acceptance criterion gets credible evidence. Mocks are converted to real sandbox resources, weak assertions become exact ones, and no test is added unless it can name the failure it would catch.

No loose ends

Everything a session notices is dismissed, done now, or filed where the next session will find it. The wrap-up says what landed, not a list of caveats for you to sort out.

“A mock proves your code handles the response you wrote, not the response the real system returns.”
From the test-hardening skill

Who it’s for

Built for software you build for someone else.

Most AI workflows assume the developer is also the product owner. The Enso Method is for when the person who decides isn’t in the chat: a client, a business owner, a department head. The software has to be right for them, and stay right for years.

Engineering leaders

Give the whole team one method it can run, and documents anyone can read, instead of a dozen personal prompting styles.

Consultants and agencies

Keep a dozen builds moving at once while clients answer on their own schedule, and hand over systems that come with their own requirements and design.

Teams on legacy systems

Recover the business rules from code nobody fully understands, have the business validate them, and start modernizing from documents instead of guesses.

Why ensō

One stroke. The circle closes.

An ensō is a circle drawn in a single brushstroke in Zen calligraphy. There is no going back over the line, and it is finished when the circle closes. That is the discipline the method asks of every session: decide deliberately, move without hesitation, and close the loop before you call it done.

How it compares

Great tools. A different job.

The leading AI development methods, from spec-driven toolkits like GitHub Spec Kit to skill libraries like Superpowers, are excellent at what they set out to do, usually helping one developer ship one branch. The Enso Method is built for a system with stakeholders, over years. Here is where that shows.

Swipe the table sideways to see every column.

The Enso Method compared with Superpowers, the BMAD Method, GitHub Spec Kit, OpenSpec and other AI development methods
Method	Known for	Requirements stay current after the build	Business decisions reach stakeholders without stalling the build	Every criterion proven against real systems	Recovers business rules from existing code
The Enso Method	Intentional systems, built for someone else	Built in	Built in	Built in	Built in
Superpowers	Test-first rigor	Not a focus	Not a focus	Partly	Not a focus
Matt Pocock’s skills	Design interviews	Not a focus	Not a focus	Not a focus	Not a focus
agent-skills (Addy Osmani)	Engineering checklists	Partly	Not a focus	Not a focus	Not a focus
GSD	Fresh-context execution	Not a focus	Not a focus	Partly	Partly
Compound Engineering	A learning loop	Not a focus	Not a focus	Partly	Not a focus
BMAD Method	Agile team roles	Partly	Not a focus	Partly	Not a focus
AWS AI-DLC	Enterprise approval gates	Not a focus	Not a focus	Partly	Partly
HumanLayer QRSPI	Context engineering	Not a focus	Not a focus	Partly	Not a focus
GitHub Spec Kit	Spec-first features	Not a focus	Not a focus	Not a focus	Not a focus
OpenSpec	Change-based specs	Partly	Not a focus	Not a focus	Not a focus

Built in Partly Not a focus Based on each project’s published skills and documentation, September 2026.

Get started

Three steps to your first phase.

Install the skills
Terminal
```
git clone https://github.com/EnsoDynamics/enso-method.git
./enso-method/setup-skills.sh
```
Links every skill into Claude Code and Codex. Safe to run again whenever the skills update.
Write the PRD

In your agent, run /prd-writing-standards and describe what you want in your own words. Talk it through; the messy version is better than a tidy instruction.
Refine, then build

Run /autonomous-requirements-refinement, then /implement-from-requirements. It sizes the work, splits it if it must, and builds the first phase in the same session.

View on GitHub

Who’s behind it

Forged on real production work.

The Enso Method is created and maintained by Doug Kerwin, author of The Enterprise Vibe Coding Playbook, at EnsoDynamics. Every rule in it exists because a real client project needed it, and it is refined every day on production systems.

Work with EnsoDynamics →

Questions

Frequently asked.

What is the Enso Method?: The Enso Method is an open-source software development methodology packaged as more than 30 agent skills for Claude Code and OpenAI Codex. It takes work from idea to production through a PRD, a technical design, autonomous refinement, session-sized phases, implementation, review and test hardening, with the requirements documents, not the AI’s memory, as the source of truth.
Which AI coding agents does it work with?: Claude Code and OpenAI Codex. The skills follow the open Agent Skills format, a folder with a SKILL.md file, and one setup script links them into both.
Do I have to answer the agent’s questions while it builds?: Rarely. Technical questions are researched against your code, data and APIs. A business question the agent is 60 to 94 percent sure about becomes a written assumption your stakeholders confirm or correct later, while the build continues. Only below 60 percent does it stop, and then it asks with a proposed answer.
Does it work on an existing codebase?: Yes. The document-an-existing-system skill recovers the business rules from code with little or no documentation, gets them validated by the business, and writes the PRD and an as-built technical design, so new work starts from documents instead of guesses.
How is it different from spec-driven tools like Spec Kit?: Spec-driven tools usually write a spec for each feature and then leave it behind. In the Enso Method the PRD and technical design stay current: every change amends them first and is built from that amendment. It adds an assumptions register for stakeholders, phases sized to one AI session, and evidence against real systems for every acceptance criterion.
What does “ensō” mean?: An ensō is a circle drawn in a single brushstroke in Zen calligraphy. It is complete when the circle closes, which is the idea behind the method’s rule that every session ends with no loose ends.

Intentional software, built at AI speed.