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.
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 the agents drive in their own context windows — so none of it eats the session you are working in.
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 every source file and test links itself 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 — driven by agents in their own context windows, so none of it eats the session you are working in.
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, 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.
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 artifacts start linking themselves. 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.