The Enso Method Get started

Matt Pocock’s skills · Matt Pocock · as of September 30, 2026

Matt Pocock’s most popular skill writes no code. It interviews you.

Its premise is that the commonest way software goes wrong is a builder who misunderstood you. So before anything is built, you’re questioned until every branch of the design is settled, and everything after that is small enough to pick up, change or leave out.

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

Matt Pocock’s skills

No framework: small skills you can make your own, and a relentless interview so every decision stays yours.

The Enso Method

Have the agent draft the answers, send the business ones to the people who own them, and keep the requirements true for the life of the system.

Where they differ

  • The developer at the keyboard decides Someone who isn’t at the keyboard decides Matt Pocock’s skills 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 Matt Pocock’s skills sits at the “Stops and asks” end; the Enso Method sits at the “Decides, records it, keeps going” end.
  • Specs serve one change Specs live as long as the system Matt Pocock’s skills sits toward “Specs serve one change”; the Enso Method sits at the “Specs live as long as the system” end.
  • One change at a time The whole body of work up front Matt Pocock’s skills sits toward “One change at a time”; the Enso Method sits at the “The whole body of work up front” end.

What they share

  • Built for new systems Built for existing systems Matt Pocock’s skills sits in the middle; the Enso Method sits in the middle.
  • Builds what is asked Challenges what to build Matt Pocock’s skills sits toward “Builds what is asked”; the Enso Method sits toward “Builds what is asked”.

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

Facts are the agent’s job. Decisions are yours.

“Finding facts is your job, never the user’s,” Matt Pocock’s grilling skill tells the agent. “The decisions are the user’s: put each to them and wait.”

That split is the heart of the method. Its README’s case starts from The Pragmatic Programmer: “No-one knows exactly what they want.” So the agent reads the code and looks things up itself, then questions you in rounds, each question with its recommended answer, “until every branch of the design tree is resolved.” It acts only once you confirm you understand each other.

The second idea is an absence. The README contrasts these skills with approaches that “try to help by owning the process” and so “take away your control and make bugs in the process hard to resolve.” Its own are “small, easy to adapt, and composable”: “Hack around with them. Make them your own.”

Grill, slice, build, look back

  1. Grill. /grill-with-docs interviews you about the change, writing each agreed term into GLOSSARY.md (CONTEXT.md before 1.3) and the rare hard-to-reverse decision into an architecture decision record (ADR). A question that talk can’t settle goes to a throwaway /prototype.
  2. Spec and slice, if the build needs more than one session. /to-spec writes the conversation up as a spec on your issue tracker, after agreeing the “seams” where it will be tested; /to-tickets cuts it into “tracer bullet” slices through every layer, each naming its blockers.
  3. Build. /implement takes one ticket per fresh session: test-first at the agreed seams, a two-part /code-review (your standards; the spec), a commit. /implement-spec, arriving in version 1.3, runs them in parallel.
  4. Look back. /retro, also arriving in 1.3, proposes checks and coding standards from what went wrong.

“Forty-six questions across four rounds is an ordinary session,” say the docs.

Built for developers who want every call to be theirs

It fits a developer, alone or in a small team, who decides what gets built, wants to make each design call, and cares how the code is shaped: someone who’d rather pick up tools than adopt a process.

It asks for your thinking, and says so. Of its largest planning skill: “the amount of thinking wayfinder demands from you is not a defect but most of what it is for.” A non-trivial ticket can pass 100,000 tokens. Setup is one command per repo.

It suits you less if whoever decides can’t sit through the interview, which is why the interview has no asynchronous version: “a grilling session that nobody answers has produced the agent’s opinion rather than yours.”

Where the Enso Method made a different call

Both start from the same worry: whatever you leave unsaid, the agent fills in for you. Both look facts up rather than ask, and both build in thin slices sized to one session. They part ways on three things.

Who makes the calls

Matt Pocock’s skills

You do, down to where the tests go. The agent finds facts and recommends; you decide. Knowledge someone else holds arrives through a questionnaire you send them.

The Enso Method

The agent drafts an answer to every open question and makes the technical calls. Business questions go to their owners as assumptions, with a confidence level, while the build continues.

Choose by situation: if you decide and want every call to be yours, Pocock’s way. If the deciders aren’t at the keyboard, or you’d rather review proposals than answer rounds, the Enso Method.

What outlives the build

Matt Pocock’s skills

The spec is a snapshot: “Treat it as throwaway once the work ships.” The glossary and ADRs last.

The Enso Method

The requirements and design stay the source of truth, amended before every change.

Choose by situation: Pocock’s way keeps documents light. The Enso Method costs upkeep, and the next change starts from what was decided.

A toolkit or a method

Matt Pocock’s skills

You type each step and can adapt any skill. Even the router, /ask-matt, “recommends and stops.”

The Enso Method

Each phase is built, reviewed and test-hardened in one run, ending in a prompt for the next phase’s fresh session.

Choose by situation: to own and tune your process, Pocock’s way. To have it carry each phase while you’re elsewhere, the Enso Method.

Where Matt Pocock’s skills shine

  • An interview worth sitting through. Rounds of questions, each with a recommended answer, and a project glossary built as you go: possibly “the single coolest technique in this repo,” says the README. The Enso Method keeps no glossary.
  • Code that stays easy to change. Tests at agreed seams, and /improve-codebase-architecture surveys the codebase for “deepening opportunities.” The Enso Method’s refactor pass looks at one recent piece of work.
  • Each session improves the next. /retro proposes checks and standards from a session’s mistakes. The Enso Method has no such step.
  • Hard bugs without guessing. No theory until one command reproduces the bug. The Enso Method has no debugging procedure.

How the Enso Method differs, and why

Matt Pocock’s skills are for the developer who wants every decision to be their own: an interview draws each one out of you, and small skills you can adapt carry it into code. The Enso Method has the agent draft the answers instead, sending business questions to the people who own them as assumptions while the build continues, and it keeps the requirements current for the life of the system.

How the Enso Method works Compare all the methods

Get started

Matt Pocock’s skills are free and open source (MIT). In Claude Code: claude plugins install mattpocock-skills. To get editable copies, on any agent: npx skills@latest add mattpocock/skills. Then run /setup-matt-pocock-skills once per repo; the README at github.com/mattpocock/skills has the details.