Zensu keeps your product — features, specs, security, release state — in one record outside the chat. This plugin lets Claude Code implement against that record, runs five reviewers before the agent can say done, and files the evidence back. The board updates itself.
Follow one feature through planning, implementation, review and live verification. See how Zensu connects the work — and where you stay in control.
Turn a request into a plan with acceptance criteria you can check.
Review the change, fix concrete findings and verify the running feature.
Autopilot prepares a pull request. You control review, merge and deployment.
Writing code is only one part of shipping a feature. You also need a clear plan, meaningful checks, and a review you can act on. Zensu brings those steps into Claude Code, so an idea can move through a consistent delivery workflow.
On screen: A feature moves through Plan, Build, Review, Verify and Ready PR.
Imagine your team needs a CSV export for filtered orders, you describe the outcome in plain English. Export the orders currently shown, include the right columns, and respect access permissions. Zensu helps turn that request into a plan with concrete acceptance criteria.
On screen: A fictional Orders app filters a date range. The plan lists three checks: keep the date filter, export the specified columns and respect permissions.
Before implementation begins, you review the plan. For an end-to-end run, choose Autopilot. After that planning gate, it works through building, reviewing, fixing, and verifying the feature, aiming for a pull request that is ready for your review.
On screen: You approve the plan. Autopilot moves through Build, Review, Fix, Verify and a pull request ready for your review.
During implementation, Claude works in your repository and follows its existing conventions. Zensu uses a flexible implementation mode by default. If your project calls for strict test-driven development, you can opt into a failing test-first, red-to-green cycle.
On screen: Code is written within the existing repository. Strict test-driven development is an optional failing-test-first, red-to-green cycle.
Specialist reviewers examine the change from different angles. Correctness, design and security. Findings must point to actual files and lines and are checked against the source before they drive fixes. An independent judge checks for blind spots.
On screen: Review findings identify source files and lines. An independent judge looks for blind spots.
In our example, a reviewer spots that the export ignores the selected date filter. That identifies a specific gap between the requested behaviour and the implementation. The workflow applies a fix and reviews the resulting change.
On screen: The export originally ignores the date filter. The fix passes the filter to the order lookup, then the change is reviewed again.
And live verification exercises the running feature against the acceptance criteria. Select a date range, export the orders, and inspect the downloaded file. Do the rows match the filter? Are the columns correct? Are access permissions enforced? The report records what actually happened, including anything that remains unresolved.
On screen: The filtered export contains the expected rows and columns. An unauthorized request receives a 403 response. A report shows the evidence for each acceptance criterion.
When the checks pass, the result is a pull request with implementation and verification evidence. Autopilot stops there. You retain control over the final review, merge and deployment.
On screen: The pull request contains implementation, review and verification evidence. Autopilot stops; final review, merge and deployment remain human decisions.
Zensu also supports the bigger picture. Starting fresh? Bootstrap turns a vision document into tracked features. Working with an existing product, Ghost Scan discovers what is already built. With the optional Zensu tracking layer, features connect to source files, tests, documentation, journeys, security profiles, and a dashboard your team can follow.
On screen: Bootstrap starts from a vision document; Ghost Scan discovers an existing product. Optional tracking connects features with source files, tests, documentation, journeys and security profiles.
You do not need a Zensu account for the core implementation workflow and review chain. Start with one change, or connect product tracking when you need it. Less manual coordination, clearer evidence, a more understandable path from request to reviewed code.
On screen: The core workflow works without a Zensu account. Product tracking can be connected when needed.
Claude Code writes code quickly. But your product — what exists, why, for whom, how careful to be — lives nowhere the agent can see, and nothing it ships gets checked.
There is no new workflow to learn. You keep prompting the way you already do — the difference is where your product lives and what happens after you stop typing.
Features start life in Zensu — drafted from a vision doc, imported from an existing repo, or shaped in the browser by whoever owns the product. You say “implement ZEN-42”; the plugin pulls the spec behind it — user journeys, acceptance criteria, security classification — and walks the implementation along the product's own pipeline.
As the agent works, source files, tests and docs get linked to the feature, status moves along the lifecycle, and release readiness recomputes. Your PO watches it move on app.zensu.dev without asking — and there is no status update left for you to write.
Before the agent can end its turn, five reviewers run in parallel and their findings get fixed. A completeness audit checks the build really ran and every promised file really changed. And a feature does not reach released until the release gate clears — security, tests, docs. You never request any of it, and you can’t forget it.
All three run on a typed zensu command line instead of a tool surface loaded into your session, and the read-heavy scans fan out to subagents in their own context windows.
Whoever owns the product shapes the feature. You approve one plan. Everything below happens without another prompt from you.
Your PO drafts ZEN-042 in the browser — user journeys, a security level, the tier it ships in. No code yet, just the product. Solo? Draft it yourself, in the app or straight from the terminal.
The plugin pulls the record — what to build, which journeys it touches, how careful to be — and drafts a plan. You approve it. That is the last decision you have to make.
The feature gets built, and the workflow links every source file and test to ZEN-042 as it lands. Before any of it counts as finished, an audit checks that the build really ran and that every file the plan promised really changed — no credit for work that did not happen.
As the agent tries to wrap up, five reviewers run in parallel — one perspective each. Findings get merged, a second pass looks for what they all missed, and fixes run until it comes back clean.
Status moved to implemented, release readiness recomputed, the session is on record. Your PO already watched it move — there is no status update left for you to write, and next week's session starts from all of it.
Five beats, one approval from you. Two commands to get there.
Agents, skills and hooks register themselves, and everything runs standalone right away. The first command that needs a workspace opens a browser — no API key, no config file to write.
Hooks fire for this repo and nothing else — the safe way to try it.
# Inside your repo
claude plugin marketplace add MKITConsulting/zensu-claude-code
CLAUDE_CODE_PLUGIN_PREFER_HTTPS=1 claude plugin install zensu --scope projectSame plugin, installed once for your whole machine.
# Anywhere on your machine
claude plugin marketplace add MKITConsulting/zensu-claude-code
claude plugin install zensu --scope userRunning it in CI, or updating later? Both are one command each — see the README.
Claude Code clones plugins over SSH by default, so the recommended command forces HTTPS. If the machine-wide install stops with a host key or publickey error, put CLAUDE_CODE_PLUGIN_PREFER_HTTPS=1 in front of it too.
The short version is everything above. This is what is actually in the box — the README carries the full reference.
Every stage of the lifecycle has a typed entry point, from /zensu:bootstrap on an existing repo to /zensu:autopilot on a whole feature. In practice you will use two or three of them — the hooks chain the rest.
Feature tracking, user journeys, tiers, roadmaps, wiki pages, security analysis and ghost scans all run on a typed zensu command line that returns structured data instead of loading a tool surface into your session, and the read-heavy scans fan out to subagents in their own context windows.
Off by default: implement directly, audits and the review chain still run. Turn it on and no implementation edit is possible until a failing test has been recorded first — enforced by the harness, not by asking the model nicely.
Changes have to be declared before they happen, secrets get caught before they leave the machine, and an opt-in gate blocks shell tricks that route around the editor. Anything that slips a gate lands in a ledger you can read afterwards.
One driver behind the PR skills detects the forge from your remote, then opens, reviews and fixes pull or merge requests on whichever one you use.
Source-available under FSL-1.1-Apache-2.0, and each release turns Apache 2.0 after two years. Point it at your own endpoint, or run it with no account at all — connect a workspace later and the workflow starts linking your artifacts to it. The activity journal records tool usage and feature context — never your code.
FSL-1.1-Apache-2.0, source-available. Runs standalone today — connect a Zensu workspace and the whole loop lights up. Workspaces are in closed beta.