Zensu is a plugin for Claude Code. It makes sure every change is reviewed from five angles before the agent can finish — and that next week's session still knows what your product is.
Claude Code writes code quickly. What it will not do on its own is stop itself, prove the work, or remember your product tomorrow.
There is no new workflow to learn. You keep prompting the way you already do — the difference is what happens after you stop typing.
The moment the agent tries to end its turn, five reviewers fan out in parallel — one perspective each. Their findings get merged, a second pass catches what the panel missed, and fixes run until it comes back clean. You never request this, and you can’t forget it.
Features, user journeys, security classification and release gates live outside the chat window. Close the session, come back next week, start a fresh context — the agent picks up what the product already is instead of re-reading the code and guessing.
Changes have to be declared before they happen, shell tricks that route around the editor are blocked, and secrets get caught before they leave the machine. Anything that slips a gate lands in a ledger you can read afterwards.
All three run on a typed zensu command line the agents drive
in their own context windows — so none of it eats the session you are
working in.
You describe what you want and approve the plan. Everything below happens without another prompt from you.
Plain language, the way you already work. Claude drafts a plan and waits for you.
You approve the plan and pick how much structure you want. That is the last decision you have to make.
The feature gets built and filed under an ID. 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.
Feature status flips, release readiness updates, the session is on record. There is no status update left for you to write — and next week's session starts from all of it.
Five beats, one prompt from you. Two commands to get there.
Agents, skills and hooks register themselves. The first command that needs an account 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 plugin install zensu --scope project Same plugin, installed once for your whole machine.
# Anywhere on your machine
claude plugin marketplace add MKITConsulting/zensu-claude-code
claude plugin install zensu --scope user Running it in CI, or updating later? Both are one command each — see the README.
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.
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.
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 use it with no Zensu account at all. The activity journal records tool usage and feature context — never your code.
FSL-1.1-Apache-2.0, source-available. Works without a Zensu account — and auto-links artifacts when connected.