enso-method plugin
Agent skills for Claude Code and Codex that record business assumptions with evidence and confidence, and preserve requirements as the source of truth.
How to install the enso-method plugin
Run both commands inside Claude Code. The first adds the marketplace once; the second installs the plugin.
/plugin marketplace add EnsoDynamics/enso-method
/plugin install enso-method@enso-methodWhat's inside enso-method
26 parts read from the plugin's own files.
Skills 26
Claude loads it when the task matches- assumptions-document-feedback
Process stakeholder feedback on assumptions documents — incorporate corrections, validations, partial answers and pushback (a doubt or question is researched and the assumption restated to meet it, never pasted in as the answer) while keeping the project moving forward. Checks every requested change against the whole initiative as it stood before the feedback, then sorts it into a fix or a new ask; once the PRD's build has started, fixes go into its phase plan and new asks, apart from minor ones, into one follow-on PRD, so a build in progress finishes on the scope it started with. Finishes every change in each PRD it reaches, including each PRD that consumes a changed contract, and gives each amended PRD one fresh check instead of rerunning its refinement. Use for every stakeholder answer to an assumption, however it arrives (a returned review, an email, meeting notes, a ruling given in chat), even one recorded in passing during a build.
- assumptions-document-writing
Standards for writing assumptions documents — every entry sorted by what would settle it (a build choice goes to the technical design, a fact research could not reach is a labelled technical assumption, only what the business wants is a business assumption), specific implementable statements, plain English, confidence levels, and stakeholder validation format. Use to draft a register, add a new entry, re-sort the entries a register already holds, or make a change an agent came up with. A stakeholder's answer to an assumption entry, however it arrives (a returned review, an email, a ruling given in chat), goes through assumptions-document-feedback instead, which applies these format rules.
- autonomous-design-refinement
Multi-pass workflow that refines PRD, Technical Design, and Assumptions documents to implementation-ready state, run after review-technical-design (and the user's own read of the design, when the user wants one) and before phase-split; the design-stage counterpart of autonomous-prd-refinement, which refines a draft PRD before any design exists — small ranked batches, each answer folded into the documents as soon as it is known, progress checkpointed to an on-disk state file so an interrupted run resumes instead of restarting.
- autonomous-prd-refinement
Research-and-review loop that takes a drafted PRD, with its assumptions and mockups, to a state with no Medium or High finding left, run after prd-writing-standards and before the user's recommended review and the technical design — every open business assumption researched before each full round, full deliverable-review rounds until none finds a High, cheaper delta rounds over each round's fixes until none finds a Medium or High, then a final full round; mockups reviewed as design references, facts verified once, progress checkpointed to an on-disk state file so an interrupted run resumes instead of restarting.
- continuation-prompt
Produce the copy-paste prompt that starts the next chat. Line one is a short chat name; then the lineage block (the PRD and phase this chat serves, or an honest "no lineage found"); then the skill to use, the goal, where to work, pointers into the governing documents, and the single first action. Before writing the prompt it moves every fact the repo should own out of the prompt and into the governing document, so the prompt stays a pointer. Use whenever the user asks for "a prompt for a new chat", "the prompt to continue this", "hand this off to a fresh session", or when any skill reaches the point of handing work to a fresh chat (phase-split, implement-from-requirements wrap-up). NOT for a "context package", or anything that passes information back to a chat that is already running. Re-run it to regenerate a prompt that came out wrong. At the end of a track it produces no prompt and says so. Ships a UserPromptSubmit hook that turns that first line into the session title.
- deliverable-review
Verify completed work accomplishes what was intended — fresh-eyes sub-agent re-reads output files, traces requirements, checks for gaps and omissions, and reports findings rated High, Medium or Low for the main agent to fix; supports cheaper delta rounds when a caller reviews the same work repeatedly.
- delivery-audit
Independent check, once every planned phase of a PRD is closed, that each acceptance criterion is actually built — every required part present and reachable from the entry point a user or calling system would use, not logic nothing calls. Sub-agents read the criteria from the PRD themselves and trace each one through the code, in fresh rounds until one finds no new gap; the main agent confirms every gap, and checks its siblings, before acting on it. It writes no code. Gaps become completion phases at the end of the plan, each marked at its top as added by the delivery audit, which implement-from-requirements builds like any other phase; test-audit follows once nothing is left to build. Use when the last phase of a split PRD closes, when implement-from-requirements hands off to it, or when the user asks whether a finished PRD or phase delivered everything it promised. Not the review inside a build (deliverable-review), not a test audit, and never for work without written acceptance criteria.
- engineering-principles
The engineering principles the Enso Method depends on — no silent fallbacks, the testing evidence standard (every acceptance criterion proved at the boundary it is about), never hacking a failing test green, questioning the first correct fix, production data (dev and sandbox first, read-only and only where allowed), git safety when several sessions share one clone, bounded and visible scheduled jobs, and the judgment calls for ambiguous moments (finish what you started, don't dismiss failures, source of truth, scope follows intent, investigate before removing). Also defines how a project plugs in its own house engineering standards. Load for any code change, test work, error-handling decision, or ambiguity mid-implementation.
- implement-from-discovery
Implement a fix or improvement identified during research, investigation, or development, or raised in a bug report — not from a PRD authored ahead of time. Verifies alignment with the affected component's PRD/Technical Design, applies the technical-vs-business confidence gate, records the change in the requirements before any code (nothing, an amendment, or a change PRD it writes itself, decided by the skill and never handed back), then implements, tests, commits, runs the refactor pass, and pushes a feature branch.
- implement-from-requirements
Default implementation skill — load full PRD and Technical Design context, size the work for a single AI session, split it into phases if too large (via phase-split, without stopping to ask) and carry on with the first leaf phase in the same chat, then implement, test, run deliverable review, harden the tests, commit, run the refactor pass, and push a feature branch. The "go build it" skill that runs after the requirements are ready.
- implementation-lifecycle
The umbrella skill for the implementation methodology — how PRDs, technical designs, assumptions, and phase documents work together, plus the No Loose Ends session discipline every implementation session runs under. Covers the assumptions philosophy, confidence thresholds, decision flow, the materiality gate that keeps discoveries from becoming scope, the disposition rule for loose ends, the no-hollow-promises rule, the lineage gate, session markers, the done-means-done completion standard, and acceptable terminal states. Loaded automatically when implementing features, resolving gaps, or working from PRDs/technical designs. Also invoke whenever the user mentions loose ends — "make sure there are no loose ends," "tie up the loose ends," "disposition everything" — that discipline lives here. Reload it to get a drifting session back on track. Invoke it whenever the user says "stay on topic," "stop going on side quests," "only fix what's in scope," or "we don't have time for that."
- implementation-readiness-check
Pre-implementation validation gate — surface gaps and unclear assumptions before writing code, with proposed answers, confidence levels, and impact assessments.
- initiative-breakdown
Cut an initiative, an idea bigger than one PRD — a brief, a context package, a pile of design notes, or a draft PRD that outgrew itself — into an ordered list of right-sized planned PRDs, each one finishing with something that can be promoted to production. Consolidates the input documents (whatever they are called) into one initiative brief that stays whole, renames and moves it to docs/initiatives/{name}/, writes beside it the initiative's PRD list (the ordered list people read) and the PRD contracts (each PRD's scope, owned contracts and seams, for the sessions that write and design the PRDs), and hands off to prd-writing-standards for the first planned PRD. Decides the cut itself and does not stop to ask. Does not write PRDs, technical designs, or phase documents. The planning step above phase-split. Use when the user says "this is too big for one PRD", "break this into PRDs", "break down this initiative", or hands over a large brief to turn into requirements.
- investigate-question
Thorough deep-dive investigation of a single question — read code, query data, test APIs, search stakeholders' raw material and the market, and explore to answer the question or significantly refine a proposed answer with updated confidence. Use for technical questions and for researching a business assumption.
- phase-split
Decide whether a PRD, or any phase of one, is too large to implement in a single AI session and, if so, split it into independently verifiable phases. Decides the cut itself and proceeds without stopping for confirmation. Produces one lightweight phase document per phase at every depth (phase 2, phase 2a, phase 2a1), all flat in the PRD directory, referencing the PRD and the single technical design without duplicating them. The planning step between requirements-ready and implementation — it does not write code.
- prd-writing-standards
Write or check a PRD (Product Requirements Document), the requirements a technical design is then built from. Skimmable — clear business context and testable outcomes without implementation details, invented responsibilities, or step-by-step instructions. Use when the user describes something to build and no PRD exists yet, or to bring an existing PRD up to this standard.
- pre-commit-validation
Commit-boundary validation ("git police") — verify the staged changeset is clean, coherent, and safe on a shared multi-session workstation. Expected-changeset staging hygiene, secrets scan, diff sanity, concurrent-commit detection, and committing on the local branch (never building on the remote and pushing around it). Loaded by the implement skills at commit time, before presenting or creating any commit.
- refactor-pass
Post-commit step of the implementation chain — judge whether the work just implemented warrants refactoring and, when it does, perform the refactoring in the same invocation: structure-only changes, tests stay green, committed as its own refactor(scope) commit unless the user's instructions say not to. Strongly decline-biased; the most common outcome is a one-line "no refactor warranted" with zero artifacts. Runs only on a committed feature baseline — run by the implement chain after the feature commit and before any push, or standalone against a named commit and its requirements. An action skill — when refactoring is warranted it does the refactoring, not a report about it.
- requirements-intake
First step when the material handed over is raw — meeting transcripts, long email or chat threads, earlier AI sessions, notes, documents or code from a prior attempt, or a large mixed pile of them. Brings the stakeholders' own material, and any prototype or earlier code, into a quarantined source-material/ folder with every file marked as unvetted reference, and leaves the rest of the pile out. Then reads all of it, separates what the business stakeholders actually decided from discussion, exploration and text no stakeholder said or chose, keeps the latest position on each topic, and writes one requirements intake record built on the stakeholders' own words, quoted, with every source cited. The PRD (prd-writing-standards) or the initiative breakdown is then written from that record instead of the pile. Skip it for a written brief or an email or two.
- review-technical-design
Senior review that revises a freshly drafted technical design in place, between technical-design-writing-standards and autonomous-design-refinement — an independent would-I-build-it-this-way architecture pass, load-bearing claims verified against the real codebase and infrastructure (read-only), data-model changes tested against the current ecosystem and future evolution, and the house engineering standards applied. Fixes every gap and false claim, swaps a working choice only for a verified defect from a closed list, never overrides a settled decision or adds scope, commits the revision, and reports what changed and which sections are worth a person's reading. Runs in a fresh context once the draft is committed; skips itself for a design that follows an established pattern. A design someone else owns, such as a pull request, gets the report without edits. Not for writing designs or reviewing code.
- stakeholder-review-package
Create or refresh a self-contained HTML stakeholder review package from a PRD, its assumptions and mockups. Combines selected business requirements with every open business assumption and contextual screens, so people can respond in one place; technical assumptions stay with the build team. The review is a derived human-facing document, never an implementation specification.
- technical-design-writing-standards
Standards and process for writing technical design documents — architecture decisions, interfaces, data models, and integration points, including designs for changes to an existing system. Use to write a design from a refined PRD, or to check one; the draft is committed and handed to review-technical-design, then autonomous-design-refinement. Not implementation instructions.
- test-audit
Independent audit, once a phase or a whole PRD is finished, of how well its tests prove each acceptance criterion, then fixing what it finds. Grades every criterion's evidence Missing, Weak, Adequate or Strong by one question (would the suite notice if this broke?), breaks the code on purpose to see which tests notice, and writes the map to test-audit.md in the PRD directory. The audit chat ends there unless the gaps are few; fixing chats then fill the gaps in a fixed order, missing before weak, until every criterion is at least Adequate or the user accepts what remains. Each chat takes a batch of rows it can hold and hands the rest on through that file, with no phase documents for test work. It assumes the suite already passes and runs no suite of its own; its capped red checks run only the test aimed at what they break. Use when a phase or PRD closes, after delivery-audit at the close of a split PRD, or when the user asks to audit the tests of a finished phase or PRD, check them against its acceptance crite
- test-hardening
Final pre-commit pass that strengthens the tests for the work just implemented — verify every acceptance criterion has credible test evidence, upgrade weak or mock-reliant tests to prove real behavior, add what's missing, and leave the full suite green. Bounded strictly by the acceptance criteria of the work being hardened — it never grows tests for behavior outside them. Runs after deliverable-review as the third step of the implement → review → harden chain. An action skill, not an audit — it improves the tests rather than producing a report.
- using-the-enso-method
Where to start and what comes next in the Enso Method — which skill runs at each stage, in what order, and where the user's review is recommended. Use when the user asks to use the Enso Method, asks "where do I start" or "what's next", or hands over requirements, an idea or a brief without naming a skill. A map only; each skill it names owns its own procedure.
- wall-clock-awareness
Measure and reduce waiting time in implementation, tests, builds, CI and delayed acceptance. Identify genuine blockers, trigger equivalent interval work early when cadence is not itself under test, prepare long prerequisites, and continue authorized independent work without risky shortcuts or weakened proof. Preserve one owner for deferred checks and shared writes. Keep active CI and deployment waits in the turn; use a verified scheduled continuation only for unavoidable elapsed-time windows after useful work is exhausted. Use when repeated runs take minutes, a phase is waiting, or the user questions elapsed time. Loaded by engineering-principles and implementation skills.
Using enso-method in Claude Code
Skills need no command. Claude reads them when your request matches what they describe.
Update, turn off or remove
- Update the plugin (shell)
- claude plugin update enso-method@enso-method
- Refresh the marketplace
- /plugin marketplace update enso-method
- Turn it off for now
- /plugin disable enso-method@enso-method
- Remove it
- /plugin uninstall enso-method@enso-method
Skills in enso-method
- assumptions-document-writingEnsoDynamics/enso-method
Standards for writing assumptions documents — every entry sorted by what would settle it (a build choice goes to the technical design, a fact research could not reach is a labelled technical assumption, only what the business wants is a business assumption), specific implementable statements, plain English, confidence levels, and stakeholder validation format. Use to draft a register, add a new entry, re-sort the entries a register already holds, or make a change an agent came up with. A stakeholder's answer to an assumption entry, however it arrives (a returned review, an email, a ruling given in chat), goes through assumptions-document-feedback instead, which applies these format rules.
2 files7stars - continuation-promptEnsoDynamics/enso-method
Produce the copy-paste prompt that starts the next chat. Line one is a short chat name; then the lineage block (the PRD and phase this chat serves, or an honest "no lineage found"); then the skill to use, the goal, where to work, pointers into the governing documents, and the single first action. Before writing the prompt it moves every fact the repo should own out of the prompt and into the governing document, so the prompt stays a pointer. Use whenever the user asks for "a prompt for a new chat", "the prompt to continue this", "hand this off to a fresh session", or when any skill reaches the point of handing work to a fresh chat (phase-split, implement-from-requirements wrap-up). NOT for a "context package", or anything that passes information back to a chat that is already running. Re-run it to regenerate a prompt that came out wrong. At the end of a track it produces no prompt and says so. Ships a UserPromptSubmit hook that turns that first line into the session title.
2 files7stars - stakeholder-review-packageEnsoDynamics/enso-method
Create or refresh a self-contained HTML stakeholder review package from a PRD, its assumptions and mockups. Combines selected business requirements with every open business assumption and contextual screens, so people can respond in one place; technical assumptions stay with the build team. The review is a derived human-facing document, never an implementation specification.
5 files7stars - assumptions-document-feedbackEnsoDynamics/enso-method
Process stakeholder feedback on assumptions documents — incorporate corrections, validations, partial answers and pushback (a doubt or question is researched and the assumption restated to meet it, never pasted in as the answer) while keeping the project moving forward. Checks every requested change against the whole initiative as it stood before the feedback, then sorts it into a fix or a new ask; once the PRD's build has started, fixes go into its phase plan and new asks, apart from minor ones, into one follow-on PRD, so a build in progress finishes on the scope it started with. Finishes every change in each PRD it reaches, including each PRD that consumes a changed contract, and gives each amended PRD one fresh check instead of rerunning its refinement. Use for every stakeholder answer to an assumption, however it arrives (a returned review, an email, meeting notes, a ruling given in chat), even one recorded in passing during a build.
7stars - autonomous-design-refinementEnsoDynamics/enso-method
Multi-pass workflow that refines PRD, Technical Design, and Assumptions documents to implementation-ready state, run after review-technical-design (and the user's own read of the design, when the user wants one) and before phase-split; the design-stage counterpart of autonomous-prd-refinement, which refines a draft PRD before any design exists — small ranked batches, each answer folded into the documents as soon as it is known, progress checkpointed to an on-disk state file so an interrupted run resumes instead of restarting.
7stars - autonomous-prd-refinementEnsoDynamics/enso-method
Research-and-review loop that takes a drafted PRD, with its assumptions and mockups, to a state with no Medium or High finding left, run after prd-writing-standards and before the user's recommended review and the technical design — every open business assumption researched before each full round, full deliverable-review rounds until none finds a High, cheaper delta rounds over each round's fixes until none finds a Medium or High, then a final full round; mockups reviewed as design references, facts verified once, progress checkpointed to an on-disk state file so an interrupted run resumes instead of restarting.
7stars - deliverable-reviewEnsoDynamics/enso-method
Verify completed work accomplishes what was intended — fresh-eyes sub-agent re-reads output files, traces requirements, checks for gaps and omissions, and reports findings rated High, Medium or Low for the main agent to fix; supports cheaper delta rounds when a caller reviews the same work repeatedly.
7stars - delivery-auditEnsoDynamics/enso-method
Independent check, once every planned phase of a PRD is closed, that each acceptance criterion is actually built — every required part present and reachable from the entry point a user or calling system would use, not logic nothing calls. Sub-agents read the criteria from the PRD themselves and trace each one through the code, in fresh rounds until one finds no new gap; the main agent confirms every gap, and checks its siblings, before acting on it. It writes no code. Gaps become completion phases at the end of the plan, each marked at its top as added by the delivery audit, which implement-from-requirements builds like any other phase; test-audit follows once nothing is left to build. Use when the last phase of a split PRD closes, when implement-from-requirements hands off to it, or when the user asks whether a finished PRD or phase delivered everything it promised. Not the review inside a build (deliverable-review), not a test audit, and never for work without written acceptance criteria.
7stars - engineering-principlesEnsoDynamics/enso-method
The engineering principles the Enso Method depends on — no silent fallbacks, the testing evidence standard (every acceptance criterion proved at the boundary it is about), never hacking a failing test green, questioning the first correct fix, production data (dev and sandbox first, read-only and only where allowed), git safety when several sessions share one clone, bounded and visible scheduled jobs, and the judgment calls for ambiguous moments (finish what you started, don't dismiss failures, source of truth, scope follows intent, investigate before removing). Also defines how a project plugs in its own house engineering standards. Load for any code change, test work, error-handling decision, or ambiguity mid-implementation.
7stars - implement-from-discoveryEnsoDynamics/enso-method
Implement a fix or improvement identified during research, investigation, or development, or raised in a bug report — not from a PRD authored ahead of time. Verifies alignment with the affected component's PRD/Technical Design, applies the technical-vs-business confidence gate, records the change in the requirements before any code (nothing, an amendment, or a change PRD it writes itself, decided by the skill and never handed back), then implements, tests, commits, runs the refactor pass, and pushes a feature branch.
7stars - implement-from-requirementsEnsoDynamics/enso-method
Default implementation skill — load full PRD and Technical Design context, size the work for a single AI session, split it into phases if too large (via phase-split, without stopping to ask) and carry on with the first leaf phase in the same chat, then implement, test, run deliverable review, harden the tests, commit, run the refactor pass, and push a feature branch. The "go build it" skill that runs after the requirements are ready.
7stars - implementation-lifecycleEnsoDynamics/enso-method
The umbrella skill for the implementation methodology — how PRDs, technical designs, assumptions, and phase documents work together, plus the No Loose Ends session discipline every implementation session runs under. Covers the assumptions philosophy, confidence thresholds, decision flow, the materiality gate that keeps discoveries from becoming scope, the disposition rule for loose ends, the no-hollow-promises rule, the lineage gate, session markers, the done-means-done completion standard, and acceptable terminal states. Loaded automatically when implementing features, resolving gaps, or working from PRDs/technical designs. Also invoke whenever the user mentions loose ends — "make sure there are no loose ends," "tie up the loose ends," "disposition everything" — that discipline lives here. Reload it to get a drifting session back on track. Invoke it whenever the user says "stay on topic," "stop going on side quests," "only fix what's in scope," or "we don't have time for that."
7stars - implementation-readiness-checkEnsoDynamics/enso-method
Pre-implementation validation gate — surface gaps and unclear assumptions before writing code, with proposed answers, confidence levels, and impact assessments.
7stars - initiative-breakdownEnsoDynamics/enso-method
Cut an initiative, an idea bigger than one PRD — a brief, a context package, a pile of design notes, or a draft PRD that outgrew itself — into an ordered list of right-sized planned PRDs, each one finishing with something that can be promoted to production. Consolidates the input documents (whatever they are called) into one initiative brief that stays whole, renames and moves it to docs/initiatives/{name}/, writes beside it the initiative's PRD list (the ordered list people read) and the PRD contracts (each PRD's scope, owned contracts and seams, for the sessions that write and design the PRDs), and hands off to prd-writing-standards for the first planned PRD. Decides the cut itself and does not stop to ask. Does not write PRDs, technical designs, or phase documents. The planning step above phase-split. Use when the user says "this is too big for one PRD", "break this into PRDs", "break down this initiative", or hands over a large brief to turn into requirements.
7stars - investigate-questionEnsoDynamics/enso-method
Thorough deep-dive investigation of a single question — read code, query data, test APIs, search stakeholders' raw material and the market, and explore to answer the question or significantly refine a proposed answer with updated confidence. Use for technical questions and for researching a business assumption.
7stars - phase-splitEnsoDynamics/enso-method
Decide whether a PRD, or any phase of one, is too large to implement in a single AI session and, if so, split it into independently verifiable phases. Decides the cut itself and proceeds without stopping for confirmation. Produces one lightweight phase document per phase at every depth (phase 2, phase 2a, phase 2a1), all flat in the PRD directory, referencing the PRD and the single technical design without duplicating them. The planning step between requirements-ready and implementation — it does not write code.
7stars - prd-writing-standardsEnsoDynamics/enso-method
Write or check a PRD (Product Requirements Document), the requirements a technical design is then built from. Skimmable — clear business context and testable outcomes without implementation details, invented responsibilities, or step-by-step instructions. Use when the user describes something to build and no PRD exists yet, or to bring an existing PRD up to this standard.
7stars - pre-commit-validationEnsoDynamics/enso-method
Commit-boundary validation ("git police") — verify the staged changeset is clean, coherent, and safe on a shared multi-session workstation. Expected-changeset staging hygiene, secrets scan, diff sanity, concurrent-commit detection, and committing on the local branch (never building on the remote and pushing around it). Loaded by the implement skills at commit time, before presenting or creating any commit.
7stars - refactor-passEnsoDynamics/enso-method
Post-commit step of the implementation chain — judge whether the work just implemented warrants refactoring and, when it does, perform the refactoring in the same invocation: structure-only changes, tests stay green, committed as its own refactor(scope) commit unless the user's instructions say not to. Strongly decline-biased; the most common outcome is a one-line "no refactor warranted" with zero artifacts. Runs only on a committed feature baseline — run by the implement chain after the feature commit and before any push, or standalone against a named commit and its requirements. An action skill — when refactoring is warranted it does the refactoring, not a report about it.
7stars - requirements-intakeEnsoDynamics/enso-method
First step when the material handed over is raw — meeting transcripts, long email or chat threads, earlier AI sessions, notes, documents or code from a prior attempt, or a large mixed pile of them. Brings the stakeholders' own material, and any prototype or earlier code, into a quarantined source-material/ folder with every file marked as unvetted reference, and leaves the rest of the pile out. Then reads all of it, separates what the business stakeholders actually decided from discussion, exploration and text no stakeholder said or chose, keeps the latest position on each topic, and writes one requirements intake record built on the stakeholders' own words, quoted, with every source cited. The PRD (prd-writing-standards) or the initiative breakdown is then written from that record instead of the pile. Skip it for a written brief or an email or two.
7stars - review-technical-designEnsoDynamics/enso-method
Senior review that revises a freshly drafted technical design in place, between technical-design-writing-standards and autonomous-design-refinement — an independent would-I-build-it-this-way architecture pass, load-bearing claims verified against the real codebase and infrastructure (read-only), data-model changes tested against the current ecosystem and future evolution, and the house engineering standards applied. Fixes every gap and false claim, swaps a working choice only for a verified defect from a closed list, never overrides a settled decision or adds scope, commits the revision, and reports what changed and which sections are worth a person's reading. Runs in a fresh context once the draft is committed; skips itself for a design that follows an established pattern. A design someone else owns, such as a pull request, gets the report without edits. Not for writing designs or reviewing code.
7stars - technical-design-writing-standardsEnsoDynamics/enso-method
Standards and process for writing technical design documents — architecture decisions, interfaces, data models, and integration points, including designs for changes to an existing system. Use to write a design from a refined PRD, or to check one; the draft is committed and handed to review-technical-design, then autonomous-design-refinement. Not implementation instructions.
7stars - test-auditEnsoDynamics/enso-method
Independent audit, once a phase or a whole PRD is finished, of how well its tests prove each acceptance criterion, then fixing what it finds. Grades every criterion's evidence Missing, Weak, Adequate or Strong by one question (would the suite notice if this broke?), breaks the code on purpose to see which tests notice, and writes the map to test-audit.md in the PRD directory. The audit chat ends there unless the gaps are few; fixing chats then fill the gaps in a fixed order, missing before weak, until every criterion is at least Adequate or the user accepts what remains. Each chat takes a batch of rows it can hold and hands the rest on through that file, with no phase documents for test work. It assumes the suite already passes and runs no suite of its own; its capped red checks run only the test aimed at what they break. Use when a phase or PRD closes, after delivery-audit at the close of a split PRD, or when the user asks to audit the tests of a finished phase or PRD, check them against its acceptance crite
7stars - test-hardeningEnsoDynamics/enso-method
Final pre-commit pass that strengthens the tests for the work just implemented — verify every acceptance criterion has credible test evidence, upgrade weak or mock-reliant tests to prove real behavior, add what's missing, and leave the full suite green. Bounded strictly by the acceptance criteria of the work being hardened — it never grows tests for behavior outside them. Runs after deliverable-review as the third step of the implement → review → harden chain. An action skill, not an audit — it improves the tests rather than producing a report.
7stars - using-the-enso-methodEnsoDynamics/enso-method
Where to start and what comes next in the Enso Method — which skill runs at each stage, in what order, and where the user's review is recommended. Use when the user asks to use the Enso Method, asks "where do I start" or "what's next", or hands over requirements, an idea or a brief without naming a skill. A map only; each skill it names owns its own procedure.
7stars - wall-clock-awarenessEnsoDynamics/enso-method
Measure and reduce waiting time in implementation, tests, builds, CI and delayed acceptance. Identify genuine blockers, trigger equivalent interval work early when cadence is not itself under test, prepare long prerequisites, and continue authorized independent work without risky shortcuts or weakened proof. Preserve one owner for deferred checks and shared writes. Keep active CI and deployment waits in the turn; use a verified scheduled continuation only for unavoidable elapsed-time windows after useful work is exhausted. Use when repeated runs take minutes, a phase is waiting, or the user questions elapsed time. Loaded by engineering-principles and implementation skills.
7stars
enso-method plugin questions
How do I install the enso-method plugin?
In Claude Code run /plugin marketplace add EnsoDynamics/enso-method, then /plugin install enso-method@enso-method.
What does the enso-method plugin include?
enso-method bundles 26 skills.
How do I update or remove the enso-method plugin?
Update it with claude plugin update enso-method@enso-method in your shell, or from the Installed tab of /plugin. Remove it with /plugin uninstall enso-method@enso-method.
What license is the enso-method plugin under?
MIT, as stated in the plugin's manifest.