Mugiwara

Your AI agent already writes the code. Mugiwara makes it reviewable.

A crew of 12 specialists with roles and evidence at every step. The process sizes itself to the work: a typo costs nothing, an auth migration gets all nine stages and a security review. No runtime, no API keys, no servers. Markdown your agent knows how to read.

Works on 12 platforms, including Claude Code and opencode.

The problem

An AI agent can write 400 lines in five minutes. It says "tests pass" and leaves nothing you can open, read, or attach to a PR. Review becomes a formality, and a formality launders the change through a human name.

What you get back

Every mission closes with one file your reviewer reads:

# Mission: invitation-accepted-flow
2026-09-03 · you · branch `feature/invitation-flow` · lane **full** · mode guided

## Verdict
**GO** — all gates passed. 1 finding deferred with an owner.

## What changed
11 files, +340 / -82.
Sensitive paths touched: `src/auth/invitation.ts`, `migrations/004.sql`

## Gates
| Gate | Verdict | Evidence |
|---|---|---|
| Checkpoint (Flow 4) | PASS | `flows/02-audit.md` |
| Quality (Flow 5) | PASS | `flows/03-quality.md` |
| Coverage (Flow 6) | PASS | new 94% / modified 87% |
| Security (Flow 7) | PASS | STRIDE, 0 high -> `review/security.md` |

## Cost
Used **8,781** of 12,000 tokens (73%). Lane `lean`. 1 heal cycle.

Generated from fixture test/fixtures/report-sample.md — 2026-09-03.

Without Mugiwara

Agent: Done: refactored auth, all tests pass.

You: ...which tests? Did anything touch the token check?

Agent: (the context is gone)

With Mugiwara

One file per PR: files changed, gates passed with evidence locations, decisions made, plus what was not verified.

The process fits the work

The lane is computed from git diff, never guessed, and it only ever rises.

What is Mugiwara? (30 seconds)

AI agents are fast. They are also unverified: no audit trail, no review, no "who checked this?" when something breaks.

Mugiwara wraps your agent in a Straw Hat crew of named roles (Luffy, Nami, Zoro, Chopper, …) with a ruled pipeline, evidence at every gate, and a cost governor keeping spend visible and bounded.

Three things it does for you:

It runs inline in your chat.

→ Why mugiwara vs asking unaided

Quick start (5 minutes)

Add the plugin, then ask something non-trivial:

# opencode: add to opencode.json, then restart
{ "plugin": ["@ionivetech/mugiwara"] }

# Claude Code
/plugin marketplace add ionivetech/mugiwara && /plugin install mugiwara

# Any platform via npm
npx @ionivetech/mugiwara@latest install --target all --yes

First run writes .mugiwara/config. Then ask, in chat or /mugiwara <request>, never @agent:

> add role-based access control: admin, editor, viewer
> audit the auth middleware for security gaps
> review the last PR for breaking changes
> split this feature across the team: payment gateway, ledger, fraud

You ask; the crew routes. A Standard-lane mission ends with test-first commits, an audit report, a security review, and a PR summary, visible at every step.

→ Full walkthrough

How it works (the short version)

Four ideas explain almost everything:

1. The crew pipeline

A mission runs as flow stages, each owned by one crew member: triage, brainstorm, plan, execute, audit, quality, gates, review, heal, closure. Plans record a preflight baseline (bun test, tsc --noEmit) before executing.

→ Full pipeline · The crew

2. Lanes: process sizes itself

Work is sized to the diff. A typo gets no pipeline; an auth migration gets all nine stages.

→ Lanes

3. Modes: how much you participate

guided (approve every step), semi (approve the plan, then auto), auto (full autonomy within your scope).

→ Modes

4. Cost Governor: what is safe to spend

Per-lane budgets, a live slop governor that flags wasted cost and attributes it to the crew member that caused it, and a mugiwara cost ledger. Four host capabilities ride alongside, named for the job with the native name in brackets: terse-output [anti-stuff], minimal-diff [just-enough], waste-guard [anti-slop], scan-format [have-adhd]. They ship with the host, not here.

→ Cost model

Adaptive execution

Control mode, execution posture, and Cost Governor stay independent. The crew picks the posture from evidence at each flow boundary. Inline is the default.

→ Adaptive execution

What Mugiwara does

→ all features: Every feature

Team collaboration

Built for a team sharing one repo. Identity is (mission, member), never branch, so parallel work never collides. Solo by default (team=off); the first shared mission flips it on at Flow 0.

/mugiwara continue                      # list every in-flight mission for YOU
/mugiwara continue payment-gateway      # solo → resume; team → list members
/mugiwara continue payment-gateway patty # resume exactly patty's work
mugiwara status                         # computed per-mission position

Auto mode runs your member scope only: your sub-mission ships alone.

→ Multi-actor reference · Adoption guide

When not to use Mugiwara

• Throwaway prototype you will delete tonight: skip the crew; the trail outlives the code otherwise.
• Unattended multi-hour runs with nobody watching chat: the crew runs inline so you can interrupt it; use a batch runner instead.
• Solo script with no reviewer, no PR, no future reader: the trail has no audience, so it is pure overhead.
• Harnesses without agent dispatch (Gemini, Codex, tier 3): you get the workflow and the trail, not enforced role boundaries.

Configuration

Switch mode any time: say mugiwara mode <guided|semi|auto> in session.

Project config (.mugiwara/config) overrides global (~/.mugiwara/config). Commented optionals (features=, team=, sign=, enforce=, scope, budgets, investigation limits) stay off until set.

→ All config keys

Quick reference

Install

/plugin marketplace add ionivetech/mugiwara && /plugin install mugiwara

npx @ionivetech/mugiwara@latest install --target <id> --yes   # windsurf, cline, kilo, codex

Compact (tier-3) targets install stub pointers, not full bodies; each install page names its side. See the harness matrix.

CLI

mugiwara install                              # wizard (interactive)
mugiwara install --target all --yes           # non-interactive
mugiwara update --target <id> --yes           # overwrite to latest
mugiwara uninstall                            # remove installed files
mugiwara list [--check]                       # show / health-check installations
mugiwara status                               # computed mission state
mugiwara continue [mission] [member]          # resume / list in-flight (read-only)
mugiwara cost [--mission <id>] [--json]       # cost ledger, avoided work, live slop
mugiwara features explain|list                # which skills load, and why
mugiwara archive <mission>                    # fold the trail into report.md
mugiwara clean [--all] [--before <date>]      # batch-archive closed missions
mugiwara blame <path>                         # provenance on the last commit touching path
mugiwara handoff <mission>                    # engineer-to-engineer handoff report
mugiwara sign <mission> [--verify]            # optional report attestation
mugiwara reset --keep-logs                    # wipe state, keep lessons

Docs

Start here: Getting started · What mugiwara replaces

Concepts: Workflow · Lanes · Modes · Git strategy · Config · Cost · Audit trail · Security · Provenance · Policy as code · Closure tools · Permissions · Memory

Crew: Agents · Skills · Adaptive execution

Reference: Adoption guide · Glossary · Harness matrix · Compliance matrix

Install: Overview · Claude · opencode · Gemini · Codex · Copilot · Cursor · Antigravity · Kimi · Pi · CLI targets

Runbooks: Solo mission · Team mission · Joining mid-mission · Resume after crash · Monorepo · Signing · Policy · Troubleshooting

What is measured, and what is not

Numbers here are produced by bun run gate. Nothing in this table is an estimate.

License

MIT. Copyright (c) 2026 ionivetech.