The Enso Method Get started

How it works

Decide once. Build and prove every phase.

One piece of work, from an idea to tested software in production. Every step is a skill your agent runs, and each one writes down what it decided, so the next step, and the next session, starts from the documents instead of a chat history.

Swipe the diagram sideways to see all of it.

The Enso Method, from idea to shipped phases Deciding what to build runs once per PRD: requirements, a technical design, then a refinement loop that finds gaps, researches them and folds the answers in until nothing is left to guess. That leaves the PRD, the design and the assumptions in one folder; the assumptions go to stakeholders without holding up the build. The work is then cut into phases. Each phase is built, reviewed, hardened and committed in one session, then the next phase starts in a fresh session, until the last one ships. Decide what to buildONCE PER PRD Idea or a brief Roadmap prd-roadmap too big for one PRD Requirements prd-writing-standards Design technical-design-writing-standards Refinement autonomous-requirements-refinement find gaps research fold in repeat until nothing is left to guess docs/prds/customer-returns/ customer-returns-prd.md technical-design.md assumptions.md writes writes sharpens both, adds assumptions Stakeholders confirm or correct later; the build doesn’t wait Build and provePHASE BY PHASE ready to build Phasing phase-split each phase, one session prove Build implement-from-requirements reads every document Review deliverable-review auto Harden test-hardening auto Commit pre-commit-validation next phase in a fresh session, until the last one ships · continuation-prompt
Deciding happens once per PRD and leaves everything in one folder. Each phase is then built, reviewed, hardened and committed in its own session. Review and hardening happen inside every phase, not once at the end.

One piece of work, start to finish.

Follow a customer returns feature through the method. Steps 1 to 4 happen once for the PRD; steps 5 to 9 repeat for every phase.

Decide what to build

Once per PRD

  1. Describe it

    prd-writing-standards

    Talk the work through in your own words; the messy version is better than a tidy instruction. The agent writes a PRD in business language: why the work matters, what it must do as testable acceptance criteria, and what is out of scope. It’s the document your stakeholders read.

    Writes customer-returns-prd.md

    An idea too big for one PRD goes through prd-roadmap first, which cuts it into an ordered roadmap of PRDs, each ending in something that ships.

  2. Design it

    technical-design-writing-standards

    The agent reads the code and writes the technical design: architecture, interfaces, data models and integration points, held to your team’s engineering standards. On an existing system it describes only the difference: what is kept, reused or switched off, and which behavior must not change.

    Writes technical-design.md

    When the design makes a hard-to-reverse decision, such as a new service or a schema change, review-technical-design gives it a senior review first and tells you which sections to read yourself.

  3. Refine it

    autonomous-requirements-refinement

    The agent asks what it would need to know if it were building this today, then answers each question itself: technical ones against the real code, data and APIs, business ones with the best evidence it can find. Each answer goes into the PRD and design as soon as it’s known, and the loop repeats until nothing is left to guess. It saves its progress as it goes, so an interrupted run picks up where it stopped.

    Writes assumptions.md

    A business question it can’t settle at 95% confidence becomes an assumption: a proposed answer with its evidence and confidence, for stakeholders to confirm or correct. How assumptions work

Build and prove each phase

Split once, then one session per phase

  1. Split it

    phase-split

    Cuts the work into phases, each shippable on its own and small enough for one AI session to finish reliably. A large PRD often becomes a dozen. You rarely run it yourself: the build calls it when the work is too big for one session.

    Writes phase-1-return-intake.md, phase-2-…

  2. Build the phase

    implement-from-requirements

    Loads the PRD, the design, the assumptions and the phase document, then builds the phase and tests it against real resources wherever they exist. If the phase turns out bigger than planned, it splits again, 2 into 2a and 2b, without stopping to ask.

  3. Review it

    deliverable-review Runs automatically

    A separate agent with fresh eyes re-reads every changed file from disk and traces each requirement to what was built. A shortfall is fixed in the code; the review never trims a requirement to match it.

  4. Harden the tests

    test-hardening Runs automatically

    Every acceptance criterion in the phase gets a test that would fail if the behavior were wrong. Mocks become real sandbox resources and weak assertions become exact ones. It stays inside the phase’s acceptance criteria, so it can’t grow the scope.

  5. Commit it

    pre-commit-validation

    Marks the phase closed, stages only this work’s files, and checks them: no secrets, a diff that matches the work, and nothing another session committed in the meantime. Then it hands you the commit message to review and commit, or commits itself if you’ve told it to.

  6. Hand off the next phase

    continuation-prompt

    Writes the prompt that starts the next phase in a fresh session: the PRD and phase it serves, the skill to run and the first action. Anything the next session needs to know goes into the phase document first, so nothing depends on what the old chat remembered.

    In Codex, phase-chain can carry an approved plan through the remaining phases, one fresh task each, without you starting each one.

Where you come in.

The agent does the research and the building. Your part is the decisions only you can make, and none of them requires sitting in the chat while it works.

  1. At the start

    Describe the work

    The PRD conversation is where your judgment goes in. Say what you want and why; the agent turns it into acceptance criteria you can check.

  2. Before the build

    Read the documents

    The PRD is written for people, not agents. Run implementation-readiness-check to see every open question and its proposed answer before anything is built.

  3. Any time

    Answer the assumptions

    Stakeholders confirm or correct each assumption on their own schedule. assumptions-document-feedback folds their answers in, and a correction is rebuilt from the amended requirements.

  4. After each phase

    Review the commit

    Each phase ends tested, reviewed and staged, with a commit message for you to check. Anything the session noticed along the way was fixed, dismissed, or written down where the next session will find it.

The rest of the kit.

The main line above runs on ten skills. These eleven do the rest. Skills load by name and description, so most of them start on their own when the agent needs them.

Checks and research

review-technical-design
A senior-engineer review of a design that makes hard-to-reverse decisions, checked against the real code, with a short list of what you should read yourself.
implementation-readiness-check
One pass over the PRD and design that lists every open question, with a proposed answer, a confidence level and the impact if it’s wrong, for you to review.
investigate-question
Takes one question to an answer by reading the code, querying the data and calling the APIs, and reports how confident it is.

Assumptions

assumptions-document-writing
How a business assumption is written: a specific answer in plain English, its evidence, its confidence, and a place to confirm or correct it.
assumptions-document-feedback
Folds stakeholders’ confirmations, corrections and partial answers back into the documents, and keeps the work moving.

Off the main line

implement-from-discovery
Builds a fix found mid-work or raised in a bug report, after checking it against the PRD and design of the part it changes.
refactor-pass
After a phase is committed, judges whether the new code needs restructuring and, if it does, refactors it with the tests still green. Usually it doesn’t.
phase-chain
Codex only: carries an approved plan through its phases, one fresh task each, committing and starting the next task as it goes.

Always on

implementation-lifecycle
The rules every build session runs under: how the documents fit together, the confidence thresholds, and no loose ends at the close.
engineering-principles
No silent fallbacks, every acceptance criterion proved by a test that would catch it breaking, no forcing a failing test green, and how your own engineering standards plug in.
wall-clock-awareness
Cuts the time spent waiting on tests, builds and CI, without weakening what they prove.

Try it on your next piece of work.

One command installs every skill for Claude Code and Codex. Then run /prd-writing-standards and describe what you want.

Terminal 
npx skills add EnsoDynamics/enso-method -g
View on GitHub Compare other methods