Open source agent skills for Claude Code and Codex
The Enso Method is a way of building production software with AI coding agents, and the skills that carry it out. It starts with the requirements: you say what you want in plain language, the open questions get answered up front, and then the agents build it while your attention goes elsewhere.
Tell AI what you want, not what to do.
The problem
AI writes most of the code now, and it usually starts the same way: a sentence or two in the chat, then whatever comes back. Sometimes the guesses are good. When they aren’t, you get software that runs, but that nobody meant to build.
“Add refunds to checkout” leaves the real questions open. Partial refunds? Store credit? What if the payment provider is down? The agent answers each one itself, without telling you, and you find out later which answers were wrong.
Then the corrections start: do this, now fix that, no, not like that. You’re telling it what to do instead of what you want, so you can’t step away, and the agent never sees the whole picture.
A month later something breaks, and someone asks what it was supposed to do. The code can’t say, and neither can the next AI session. Without the intent written down, a fix is just another guess.
The fix isn’t a better prompt. It’s doing the thinking before the build: requirements your stakeholders can read, a design, and every open question answered or written down as an assumption. Then the agent builds straight through, phase after phase, and your attention goes back to the decisions only you can make.
The method
The skills are how the method runs. These are what it believes, and they hold whichever skill is doing the work.
Work starts from a PRD and a technical design, and a meaningful change amends them before it is built. Small fixes will still happen straight in the code, as they always do, but the intent stays written down, so each new session starts from what was decided rather than guesses about the code.
When a business question comes up, the agent researches it, proposes an answer, writes it into the assumptions document with its confidence, and keeps building. Stakeholders confirm or correct it on their own schedule. Nothing waits.
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.
Describe the outcome, not the steps. The method turns it into acceptance criteria, a design and a plan, so the agent works from intent instead of a stream of instructions, and can tell you when your first idea is the wrong place to solve the problem.
No agent can build a whole system in one go, so large work is cut along natural seams into thin vertical slices, each small enough for one AI session and working on its own. When a phase turns out bigger than planned, it splits again.
Before work is called finished, each acceptance criterion in the PRD is checked against a test that exercises it, against real systems wherever they exist, and that would fail if the behavior were wrong. Once the last phase closes, the whole PRD is audited again, first that every criterion was built, then that its tests prove it. Finished means every acceptance criterion is proven, not that the agent says it’s done.
How it works
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.
requirements-intake
Turns raw material, like long meeting transcripts or a prior attempt’s documents, into one record of what stakeholders decided, in their own words.
initiative-breakdown
Cuts an initiative, an idea too big for one PRD, into PRDs that each end in something that ships.
prd-writing-standards
A PRD in business language, with testable acceptance criteria and an explicit out of scope.
autonomous-prd-refinement
Reviews and fixes the draft in rounds until nothing found would change what gets built, so your review goes on the decisions.
technical-design-writing-standards
Architecture, interfaces, data models and integration points, held to your house standards.
review-technical-design
Checks the draft against the real code and your standards, fixes what it finds, and lists the sections worth your time.
autonomous-design-refinement
Pass after pass, finds every gap, researches the answers and folds them into the documents. Checkpointed, so it resumes instead of restarting.
phase-split
Cuts the work into independently shippable phases, each sized to one AI session.
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.
continuation-prompt
Hands the next phase to a fresh session that knows exactly which PRD and phase it serves.
deliverable-review
A fresh-eyes agent re-reads every changed file and traces each requirement to the output.
test-hardening
Maps every acceptance criterion to evidence and upgrades mocks to real sandbox resources.
pre-commit-validation
Checks the change before it’s committed: only this work’s files, no secrets, and nothing another session committed in the meantime.
refactor-pass
After the commit, restructures the new code if it left things worse. Usually it didn’t.
delivery-audit
After the last phase, checks that every acceptance criterion was built, and turns anything missing into a phase to build.
test-audit
Then checks that the tests prove every criterion, breaking the code on purpose to see which tests notice, and fills the gaps.
The assumptions register
Before anything is built, the agent lists the questions it would have if it were building this today, and researches each one against the real code, data and APIs. What research can’t settle reaches a stakeholder as a proposal, never a bare question.
assumptions.mdAnything it’s at least 95% sure of, it just decides, so you’re never buried in questions it could settle itself. An assumption is a green light, not a blocker: the build starts on it right away, and if the answer comes back no, it goes into the requirements and that piece is rebuilt.
autonomous-design-refinement finds every question the PRD and the technical
design don’t already answer, then researches them in one long session, folding each answer back into
the requirements, so it’s all sorted out before the build starts.
implementation-readiness-check runs the same check once, for you to review.
RET-004
The build
Once the requirements are ready, phase-split cuts the work into phases, each big enough to
matter and small enough for one Claude Code or Codex session to finish reliably. A large PRD often becomes
a dozen of them.
Point your agent at each phase with implement-from-requirements, and it builds, tests and
closes it. The decisions were made before the build began, so nobody has to sit in the chat making them.
If a phase turns out bigger than planned, it splits again, 2 into 2a and 2b, without stopping to ask.
When the last phase closes, a delivery audit checks that every criterion was built and adds phases for
anything missing, before the test audit proves them.
docs/prds/customer-returns/
Phases from phase-split
Kiln · optional
Kiln runs every phase for you. Each gets a fresh session, and Git confirms it landed before the next one starts. You come back to a pull request, or to the one phase that genuinely needs you.
npm install -g @ensodynamics/kiln
Free and open source. Runs on your own machine with Claude Code or Codex.
That’s the short version.
See how it checks each phase, when it needs you, and the full overview.
Built into the skills
Eight rules written into the skills, so nobody has to type them into the chat. Each one names the skill that carries it.
implementation-lifecycle
Before it edits a file the plan didn’t call for, it has to name the acceptance criterion that needs the edit. “While I’m here” doesn’t count. When an edit nobody asked for starts breaking things downstream, it undoes that edit instead of fixing everything after it.
continuation-prompt implement-from-requirements
Each phase starts in a fresh session that loads the PRD, design and phase document itself. Before a handoff, anything the next session needs is written into those documents, so nothing important lives only in a chat that’s about to end.
implementation-lifecycle engineering-principles
An assumption lets the build continue, never an action that can’t be undone. Charging money, deleting data and writing to production wait for a person, however confident the agent is. It builds in dev and sandbox, and reads production only when nothing else can answer the question.
assumptions-document-writing
When new evidence contradicts something a stakeholder already decided, the agent reopens the question under its original entry, with their ruling and the evidence side by side. It never edits their decision to match, and a test that checks it stays red until they rule again.
review-technical-design
A design written by AI reads confident whether or not it’s right. A senior review sketches its own design first, checks the claims the design rests on against the real code and infrastructure, fixes what it can prove wrong, and points you to the decisions that most need your judgment.
engineering-principles
One line in your repo’s agent instructions names your team’s engineering standards, and they load alongside the method’s own principles. On stack, style, naming, configuration and deployment, your standards win.
engineering-principles
When a fix needs a new lock, queue, retry or special mode, it first asks why the system needs one. It ships the safe fix and writes the deeper design question into the technical design, instead of quietly piling on machinery.
engineering-principles
A failing test is understood before anything changes, never forced green by weakening an assertion, skipping the test or hardcoding the answer. And when data or configuration is missing, the code fails loudly instead of quietly running on a default.
Evidence, not claims
An agent saying it’s done doesn’t count. These skills check the work before a phase is called finished, and again once the whole PRD is.
deliverable-review
A separate agent re-reads every changed file from disk and traces each requirement to what was built. When the new work falls short of the PRD, the work gets fixed; 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.
delivery-audit test-audit
Once the last phase closes, one audit checks that every acceptance criterion was actually built and adds phases for anything missing. A second breaks the code on purpose, watches which tests notice, and keeps fixing until every criterion is proven. Both take the criteria from the PRD, not from the agent that wrote the code.
implementation-lifecycle
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.
Who it’s for
Most AI methods are written for a solo builder who is developer and product owner at once. That works for a side project. On client and company work, the decisions belong to someone else, a client, a business owner, a department head, and their time is scarce. The Enso Method keeps the build moving on proposals they can confirm or correct later, and leaves them documents they can actually read.
Give the whole team one method it can run, and documents anyone can read, instead of a dozen personal prompting styles.
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.
Write the requirements for the part that’s changing, and a design of just the difference: what is kept, what is reused, what is switched off, and which behavior must not change.
Why ensō
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
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. Most tackle the same problem; they differ in what they believe: who decides, how far ahead to plan, and what proves the work is done. Here is where the Enso Method stands.
Swipe the table sideways to see every column.
| Method | Known for | Changes amend the requirements first | Business decisions reach stakeholders without stalling the build | Every acceptance criterion proven against real systems |
|---|---|---|---|---|
| The Enso Method | Intentional systems, built for someone else | Built in | Built in | Built in |
| Superpowers | Test-first rigor | Not a focus | Not a focus | Partly |
| Matt Pocock’s skills | Design interviews | Not a focus | Not a focus | Not a focus |
| agent-skills (Addy Osmani) | Engineering checklists | Partly | Not a focus | Not a focus |
| GSD | Fresh-context execution | Not a focus | Not a focus | Partly |
| Compound Engineering | A learning loop | Not a focus | Not a focus | Partly |
| BMAD Method | Agile team roles | Partly | Not a focus | Partly |
| AWS AI-DLC | Enterprise approval gates | Not a focus | Not a focus | Partly |
| HumanLayer QRSPI | Context engineering | Not a focus | Not a focus | Partly |
| GitHub Spec Kit | Spec-first features | Not a focus | Not a focus | Not a focus |
| OpenSpec | Change-based specs | Partly | Not a focus | Not a focus |
| pstack | Verified parallel agents | Not a focus | Not a focus | Partly |
| Agentic Coding Flywheel | Multi-model plans, agent swarms | Not a focus | Not a focus | Partly |
Built in Partly Not a focus Based on each project’s published skills and documentation, September and October 2026.
What each method believes, and where the Enso Method chose differently →
Get started
In Claude Code and Codex the skills install as a plugin, which names each one
enso-method:<skill> so none can clash with skills from anywhere else.
New to plugins? See how they work in
Claude Code and
Codex. Other agents get plain copies through the
skills CLI. To work from a clone of the repo, see the
setup guide.
Or let your agent do it. Tell it
Install the Enso Method from github.com/EnsoDynamics/enso-method
and it follows the steps for agents,
installing the plugin for Claude Code and Codex both when you have both.
claude plugin marketplace add EnsoDynamics/enso-method
claude plugin install enso-method@enso-methodcodex plugin marketplace add EnsoDynamics/enso-method
codex plugin add enso-method@enso-methodnpx skills add EnsoDynamics/enso-method -gThe Enso Method is continually improved. Update regularly to keep your skills current.
Claude Code auto-update: run /plugin → Marketplaces → enso-method → Enable auto-update.
claude plugin marketplace update enso-method
claude plugin update enso-method@enso-methodcodex plugin marketplace upgrade enso-methodnpx skills update -gRestart Claude Code after a manual update to load the latest skills.
Start a new Codex chat after updating to load the latest skills.
Restart your agent if it does not pick up the updated skills.
Marketplace not found? Run the install commands above.
Previously installed with the skills CLI? Remove those copies before installing the plugin to avoid duplicate skills.
In your agent, run /prd-writing-standards (in Codex, pick it from the $ menu)
and describe what you want in your own words. Talk it through; the messy version is better than a tidy
instruction. Then /autonomous-prd-refinement reviews and fixes it in rounds, ready for
your review.
Run /technical-design-writing-standards to design how it will be built. A senior review
checks and fixes the draft and lists the sections worth your time. Then
/autonomous-design-refinement
researches the open questions in both documents and folds the answers in. It also prepares a
stakeholder review package for you to share.
Run /phase-split to size and plan the work, then /implement-from-requirements
to build, review and test. Work that fits one session stays whole.
A dozen phases? Kiln runs them all, one after another, while you do something else.
Questions