Zensu keeps your product — features, specs, security, release state — in one record outside the chat. This plugin lets Kiro implement against that record test-first: on the CLI that lock is a hard gate, and five reviewers run before the agent can say done. Same plugin for the IDE and the CLI.
Kiro writes code fast. Whether the test comes first, whether anyone checks the result, and where your product lives afterwards — that normally comes down to you remembering.
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.
Start a task and the agent is locked into red before green: write a test, watch it fail, and only then touch production code. On the Kiro CLI that lock is a real gate — a write that skips the failing test is denied outright and the reason goes straight back to the model. In the IDE the same discipline runs as steering.
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 agent pulls the spec behind it — user journeys, acceptance criteria, security classification — and builds against the record instead of guessing from the prompt.
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.
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.
Kiro ships as an IDE and as a CLI, and Zensu installs into both from one repo. They do not enforce the same way, though — and that difference is worth knowing before you pick.
Want the guarantees to actually hold? Use the CLI. Want to stay in the editor? Use the IDE and treat the disciplines as strong defaults rather than locks. Both share the same settings, so you can run one repo through either.
Skills, agents 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.
Install the script, then make zensu the default agent so the gates are armed for every session.
# Clone, install, arm the agent
git clone https://github.com/MKITConsulting/zensu-kiro
cd zensu-kiro && bash install.sh
kiro-cli agent set-default zensuPowers panel → Add power from GitHub. One onboarding run wires the skills and agents in.
# From the Power checkout directory
bash install.sh --scope user --no-defaultRe-running the installer is safe — it never overwrites a file you edited. For CI, headless runs and updating, see theREADME.
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-pr-team-review on a pull request. In practice you will use two or three of them — the hooks chain the rest.
The agents drive a typed zensu command line from their own context windows rather than loading a tool surface into yours. Feature tracking, security analysis, journeys, tiers, roadmaps, wiki pages and ghost scans all run there.
Same disciplines, same review chain, same config schema, same CLI as the Claude Code port, so a team can run both without learning two systems. The honest difference: there the hard gates hold on every session, here they hold on the CLI and steer in the IDE.
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 on both Kiro hosts, standalone today — connect a Zensu workspace and the whole loop lights up. Workspaces are in closed beta.