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.
Follow one feature through Kiro's test-first implementation and review chain. See how CLI hard gates and IDE steering differ, then check the result and prepare the handoff.
Turn a request into a plan with acceptance criteria you can check.
Review the change, fix concrete findings and verify the running feature.
Prepare the pull request with evidence. You control final 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 Kiro, so an idea can move through a consistent delivery workflow.
On screen: A feature moves through planning, building, review, verification and a pull request.
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 covers the date filter, expected columns and access permissions.
Before implementation begins, you review the plan. Start the implementation and review workflow with Zensu TDD. After that, work through building, reviewing, fixing, and checking the acceptance criteria. Keep the plan and evidence together, then prepare a pull request for your team's review.
On screen: You approve the plan and start /zensu-tdd. Work through implementation, review, fixes and acceptance checks, then prepare the pull request.
During implementation, Kiro works in your repository and follows its existing conventions. Zensu uses strict test-driven development by default. Start with a failing test first, then work through the red-to-green cycle. On Kiro CLI, an armed workflow can block edits that skip the required test evidence. In the IDE, the same discipline is provided as steering. Vanilla mode is available when you choose it.
On screen: Strict TDD is the default. Kiro CLI has hard gates in an armed workflow; the IDE provides steering. Vanilla mode is an explicit option.
Five specialist reviewers examine the change from different angles, including correctness, design, and security. Findings must point to actual files and lines, and are checked against the source before they drive fixes. A consolidating reviewer brings the findings together. A final self-review closes the review chain.
On screen: Five specialist perspectives feed a consolidating reviewer. Source-backed findings and a final self-review close the chain.
In our example, a reviewer spots that the export ignores the selected date filter. That identifies a specific gap between the requested behavior and the implementation. The workflow applies a fix and reviews the resulting change.
On screen: The export initially ignores the date filter. The fix passes the filter to the order lookup, then the change is reviewed again.
Next, exercise 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? Record what actually happened in the report, including anything that remains unresolved.
On screen: The downloaded CSV contains the expected rows and columns. An unauthorized request receives 403. An acceptance report records the outcomes.
After the checks pass, prepare a pull request with implementation and verification evidence. The reviewed change is ready for your team's decision. You retain control over the final review, merge, and deployment.
On screen: The pull request carries implementation, review and verification evidence. Final review, merge and deployment remain your 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; Ghost Scan discovers existing features. Optional tracking connects features to their evidence.
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 needs no Zensu account. Product tracking is optional. Start with /zensu-tdd and visit zensu.dev/kiro.
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 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-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 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 on both Kiro hosts, standalone today — connect a Zensu workspace and the whole loop lights up. Workspaces are in closed beta.