@ionivetech/mugiwara 0.5.4 → 0.6.0

package/content/skills/mugiwara-ship/SKILL.md

@@ -46,7 +46,7 @@ Run every item and record evidence; a checkbox ticked without output is a failed
 1. Verdict is GO or NO-GO. No "GO with caveats", no "almost".
 2. Every checklist item cites evidence: command output, file, or commit.
 3. A critical finding at any stage → NO-GO. Non-critical findings → list them, decide ship-with-tracking or fix-first, and record which.
-4. Write the verdict and evidence to `.mugiwara/results/`.
+4. Write the verdict and evidence to `.mugiwara/results/<mission>/06-closure.md`.
 
 ## Cleanup (after the terminal step)
 
@@ -57,14 +57,15 @@ consumed intermediates. Never touch anything outside `.mugiwara/`.
 
 - `config`
 - `plans/YYYY-MM-DD-<mission>.md` — the clean plan doc
-- `results/YYYY-MM-DD-<mission>-closure.md` — closure report
-- `results/YYYY-MM-DD-<mission>-pr-verdict.md` — PR material
+- `results/<mission>/06-closure.md` — closure report
+- `results/<mission>/07-pr-verdict.md` — PR material
 - `logs/lessons.md` and any cross-mission state (`backup/`, `manifest.json`)
 
 **DELETE** (consumed or superseded):
 
+- `results/<mission>/01-execution.md` … `05-healing.md`, `todos.md` — wave artifacts, consumed after closure
 - `spec/YYYY-MM-DD-<mission>.md` — consumed by planning
-- `results/` wave reports — todos, audits, quality/gate/healing reports
+- `.mugiwara/continue.md` — consumed once the mission is closed (delete by exact name, never a `handoff*` glob)
 - `review/` and `issues/` per-mission findings
 - `logs/YYYY-MM-DD-<mission>.md` and mode-flip logs
 

package/content/skills/mugiwara-workflow/SKILL.md

@@ -8,114 +8,111 @@ description: Use at start of any non-trivial mission — Luffy triage gateway, f
 ## Skip when
 
 - Lane 0 direct work: typo, rename, or single-file fix under 20 LOC.
-- User explicitly declined the harness for this request.
+- User explicitly declined the harness for this request (`mugiwara off` — Luffy acknowledges, records it in the decision log, and the crew stands down).
 
-The Straw Hat harness: Wave 0 triage + Waves 1-9, with an optional adversarial pass at Wave 4.5. Waves are phases of the mission, not files — Nami writes them into the plan doc, Zoro executes them. The main thread runs the harness and embodies each crew role inline (Execution model below); the harness always starts through Luffy unless the user summons a crew member directly.
+## Pipeline
 
-## Execution model (every harness)
-
-**Inline by default.** The main/primary agent runs the pipeline and plays each crew role itself using that member's skill. Every wave's work is performed in the main conversation so the user sees the process live — no hidden subagent jumps, no click-to-expand. The crew members are personas + skills the main thread embodies, not mandatory dispatch targets.
+```
+  Triage → Brainstorm → Plan → Execute
+  Luffy     Usopp        Nami    Zoro
+    0         1            2       3
+    ↓                                       ↑ heal loop (max 3)
+  Audit → Quality → Gates → Review → Heal → Closure
+  Chopper Sanji    Franky  Robin∥Jinbe Brook Luffy
+    4       5        6        7          8      9
+                        ↑ Wave 4.5 (optional)
+                        Skeptic — adversarial verify
+```
 
-**Visible wave transitions.** Every wave opens with a main-thread banner `## Wave N — <crew> (<skill>)` and closes with the handoff line `→ Wave N+1 — <crew>` (Wave 9: `→ closure`). No wave starts without its banner; the conversation names who runs now and who takes over next so the user always sees the chain live.
+Waves are phases, not files. The plan doc defines them. The harness runs inline.
 
-**Auto-activation.** Any non-trivial request fires the harness without the user asking. Check first, before exploring or answering: if the request could benefit from the crew, start Wave 0 triage. The user does not need to invoke `using-mugiwara` explicitly — the workflow starts itself.
+| # | Wave | Crew | Skill | Delivers |
+|---|------|------|-------|----------|
+| 0 | Triage | Luffy | `orchestration` | 5-way class + lane |
+| 1 | Brainstorm | Usopp | `brainstorm` | options + recommendation |
+| 2 | Planning | Nami | `planning` | task plan + acceptance |
+| 3 | Execute | Zoro | `execution` | implemented + evidence |
+| 4 | Audit | Chopper | `checkpoint` | re-verified + ledger |
+| 4.5 | Verify | Skeptic | `claim-audit` | adversarial check (optional) |
+| 5 | Quality | Sanji | `quality` | lint + format + test |
+| 6 | Gates | Franky | `gates` | coverage + build + DoD |
+| 7 | Review | Robin∥Jinbe | `review`+`security` | findings (parallel) |
+| 8 | Heal | Brook | `healing` | fixes → back to Wave 4 |
+| 9 | Close | Luffy | `orchestration` | push + PR verdict |
 
-**Checkpoint-report presentation.** The banner marks a stage boundary; no wave passes silently. At each boundary the owning crew reports inline — one compact per-crew report: what ran, the result, the evidence pointer. No narration of every tool call. Each wave closes with a short progress summary (done / in-flight / blocked + next handoff). On failure or risk, PAUSE: report the problem and get a continue / retry / escalate decision before proceeding.
+## Execution model
 
-1. For each wave, the main thread loads the owning crew member's skill (e.g. `mugiwara-checkpoint` for Wave 4) and performs that role inline: triage, planning, execution, audit, quality, gates, review, closure — all in the main thread.
-2. Dispatch a subagent ONLY when the work is genuinely parallel or background: an independent `[PARALLEL]` task batch (Zoro's WORKER subagents, Wave 3), parallel fixes (Brook, Wave 8), or a long-running check that would stall the conversation. Subagent results return to the main thread as a report; the main thread summarizes the outcome inline with evidence pointers.
-3. Crew members NEVER dispatch another crew member. A crew role that must split work returns the split plan to the main thread, which spawns the workers.
-4. Escalation = "blocked" + ledger row returned to the main thread, which routes it to Luffy/Brook. Never a nested crew dispatch.
+**Inline by default.** Main thread embodies each crew role using that crew's skill. Every wave runs in the main conversation.
 
-Why: crew-inside-crew nesting hides work behind subagent expansion and bloats context. Inline roles keep every wave visible as it happens. Subagents exist to parallelize, not to hide. In any harness — Claude Code, opencode, Codex, Cursor, Gemini — subagent internals sit behind a click; the only way the user sees the process is to run it in the main conversation.
+**One role at a time.** The main thread embodies ONE crew role per response — completes that role's report, then moves to the next. Never role-bleeds two personas into one response; never starts the next role before the current one returns its output.
 
-## Workspace layout
+**Banners.** Waves open with `==================== WAVE N - CREW (SKILL) ====================` and close with `→ Wave N+1 — Crew`.
 
-Every mission creates and works inside `.mugiwara/` at the repo root:
+**Subagents only for parallelism.** `[PARALLEL]` task batches, parallel review, parallel heal workers. Crew members never dispatch crew members.
 
-```
-.mugiwara/
-├── config         # runtime mode config: mode/branch/commit/pr key=value (gitignored; project overrides global)
-├── state.json     # computed mission state at every wave boundary (scripts/savepoint.sh)
-├── spec/          # brainstorm output: YYYY-MM-DD-<mission>.md
-├── plans/         # plan doc: YYYY-MM-DD-<mission>.md — CLEAN, Nami-only, source of truth from Wave 2
-├── results/       # wave results: audit/quality/gate reports, todos, closure report
-├── reports/       # human-readable mission reports: YYYY-MM-DD-<mission>.md
-├── review/        # review + security findings
-├── issues/        # blocker log: YYYY-MM-DD-<mission>-blockers.md
-└── logs/          # Luffy's decision + check-in log: YYYY-MM-DD-<mission>.md (deleted at cleanup)
-```
+**Compact output.** Do not stream tool calls. After each batch: one status table. Full logs → `.mugiwara/results/<mission>/01-execution.md`.
 
-The plan doc stays clean: it holds ONLY Nami's execution plan (waves, tasks,
-criteria, risks). Who did what, route decisions, and check-in verdicts go to
-`logs/`; the closure report goes to `results/`. Nothing non-plan pollutes the plan doc.
+**Mode flips.** `/mugiwara mode <guided|semi|auto>` applies from the next wave, never mid-wave. If a flip arrives mid-wave, say so — "recorded, applies from Wave N+1" — never apply silently, never ignore.
 
-The owning agent creates the folder it needs on first write. No mission artifacts go outside `.mugiwara/`.
+## Workspace
 
-## Resume
+Full layout: `references/workspace-layout.md`.
 
-At session start, after context loss, or on any "where were we?" — embody `resume-coordinator` inline (mugiwara-resume) BEFORE Wave 0 triage. Rebuild the picture from disk (plan, todos, trace, blockers) and report the resume point. Resume before any wave; never start over. Disk state is truth.
+## Wave 0 — Triage (always first)
 
-## Wave 0 — Luffy Triage (always first)
+Luffy classifies every request 8 ways:
 
-Front door: embody `using-mugiwara` inline (the router) — it routes to the right crew member and records the route. For a full triage embody `luffy-orchestrator` inline. NEVER start directly with brainstorming or planning. Luffy classifies every request 5 ways (Trivial / Explicit / Exploratory / Open-ended / Ambiguous) and routes: Trivial and Explicit → Wave 2 directly; Exploratory, Open-ended, and Ambiguous → Wave 1 brainstorm first. Alongside the class, Luffy sizes the mission and picks a lane (0 Direct / 1 Lean / 2 Standard / 3 Full / 4 Spike) — small work skips the pipeline, sensitive work never sneaks through the lean path. The user may summon any crew member directly — Luffy still records the route.
+| Class | Signal | Route |
+|-------|--------|-------|
+| Trivial | obvious, single file | → Wave 2 |
+| Explicit | clear spec exists | → Wave 2 (still sizes the lane from the spec's file list) |
+| Exploratory | needs research | → Wave 1 |
+| Open-ended | broad, undefined | → Wave 1 |
+| Ambiguous | unclear scope | → Wave 1 |
+| Answer | question, no file change | answer directly, no mission |
+| Refuse | deploy / migration / key rotation / merge | decline at Wave 0, offer branch handoff |
+| Hotfix | production broken | Lane 1, gates deferred with owner |
 
-Alongside triage, read the mode config per mode config: `.mugiwara/config` (project) then `~/.mugiwara/config` (global); a key missing from both = `guided`. Lazy-create the project config on first WRITE only, never auto-create on read.
+Precedence: class decides whether there is work; lane decides how much process — class first, lane second.
 
-## Waves
+Lane: 0=Direct (<20 LOC), 1=Lean (1-2 files), 2=Standard (3-8 files), 3=Full (9+ or sensitive), 4=Spike. Record route in `.mugiwara/logs/`.
 
-| Wave | Owner | Skill | Output |
-|------|-------|-------|--------|
-| 0 Triage | Luffy | mugiwara-orchestration | route decision + reason |
-| 1 Brainstorm | Usopp | mugiwara-brainstorm | refined direction, options, recommendation |
-| 2 Planning | Nami | mugiwara-planning | plan doc: waves/tasks/criteria, parallel markers |
-| 3 Execution | Zoro | mugiwara-execution | implemented tasks with evidence |
-| 4 Checkpoint | Chopper | mugiwara-checkpoint | audit report + failure ledger |
-| 4.5 Adversarial | Skeptic | mugiwara-claim-audit | findings report + failure ledger |
-| 5 Quality | Sanji | mugiwara-quality | formatter/linter/test results |
-| 6 Gates | Franky | mugiwara-gates | coverage + build verdict |
-| 7 Review | Robin ∥ Jinbe | mugiwara-review + mugiwara-security | severity-tagged findings |
-| 8 Healing | Brook | mugiwara-healing | fixes, then loop back to Wave 4 |
-| 9 Closure | Luffy | mugiwara-orchestration | closure report + push mission branch + PR verdict file handed to user, who opens the PR (terminal gate in every mode) |
+## Session handoff
 
-Wave 4.5 is optional — Luffy invokes Skeptic after Chopper on high-stakes missions (verdicts, plans, reviews), or parallel to Wave 7 review when he calls for it. Skip means recorded without a pass.
+At session end (step limit, crash, or manual stop) the crew writes `.mugiwara/continue.md` before the final text response: mission, sub_mission, wave, tasks, next_action (exact files + commands), next_session_prompt. Owner: orchestrator (captain); writer: the agent ending the wave. Next session starts with `/mugiwara continue` — no re-explanation. `auto` mode continues across sessions via continue.md: one command per session, no re-explanation. state.json proves what is done; continue.md says what is next — verify next_action against state.json, escalate contradictions.
 
-## Blockers
+## Blocker protocol
 
-Any agent that hits a blocker APPENDS a row to `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md`:
-
-`| <wave> | <task> | <symptom> | <attempted> | <help-needed> |`
-
-Never silently work around a blocker. Brook reads this ledger at Wave 8 to decide what to heal; Luffy reviews it at every check-in.
+Blocked agent appends to `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md`:
+```
+| wave | task | symptom | attempted | help-needed |
+```
+Brook reads this at Wave 8. Never silently work around a blocker.
 
-## Cleanup
+## Cleanup (Wave 9)
 
-At closure (Wave 9), after the terminal step, run cleanup per `mugiwara-ship`: delete consumed intermediates — superseded results, review, issues, the decision log in `logs/`, and consumed spec. Keep the plan doc, closure report, PR verdict, mission report, `config`, `state.json`, and cross-mission state (`logs/lessons.md`, `backup/`, `manifest.json`). List candidates before deleting.
+Delete consumed: `results/<mission>/01-execution.md`…`05-healing.md` + `todos.md`, `logs/` (except `logs/lessons.md`), `spec/`, `review/`, `issues/`. Keep: `results/<mission>/06-closure.md`, `results/<mission>/07-pr-verdict.md`, `plans/`, `reports/`, `config`, `state.json`, `logs/lessons.md`. Full layout: `references/workspace-layout.md`.
 
 ## Rules
 
-1. Evidence over claims: no wave passes on assertion. The owning agent runs the checks and shows output.
-2. No wave skipped without the reason recorded in the decision log (`.mugiwara/logs/`) — name the wave, owner, and reason at the moment of omission.
-3. Heal loop is bounded: Wave 8 → Wave 4, max 3 cycles. After that, escalate to the human with full history.
-4. Any agent may consult Luffy mid-flight (embody `luffy-orchestrator` inline) for decisions and escalations.
-5. Wave 7 runs Robin and Jinbe in parallel over the same diff.
-6. The plan doc is the single source of truth from Wave 2 onward.
-7. Frontend tasks in Wave 3 must apply `mugiwara-frontend`.
-8. On session start or context loss — resume via `resume-coordinator` before any wave; never start over.
-9. Push branch + hand verdict file to the user, who opens the PR; crew never merges, never deploys.
+1. Evidence over claims — run checks, show output.
+2. No wave skipped without reason recorded in logs.
+3. Heal loop: max 3 cycles, then escalate.
+4. Wave 7: Robin and Jinbe parallel over same diff.
+5. Plan doc is source of truth from Wave 2.
+6. Resume via `resume-coordinator` before any wave — never restart.
+7. Push branch + hand verdict to user; crew never merges or deploys.
 
 ## Iron Law
 
-EVIDENCE OVER CLAIMS. No wave passes on assertion — the owning agent runs the checks and shows output. "Done", "passes", and "fixed" must be proved by running the check command in the same turn; no stale results, no guesses, no worker's word for it.
+EVIDENCE OVER CLAIMS. "Done" = command re-run, output captured, evidence fresh.
 
 ## Red flags
 
-- A wave passes on a spoken claim with no command output.
-- Heal loop beyond 3 cycles with the same failure still open.
-- Wave skipped with no reason recorded in the decision log.
-- Execution before triage (Wave 0).
-- Mission artifacts outside `.mugiwara/`.
-- Wave order drifts (e.g. quality before checkpoint).
-- Blocker worked around silently with no ledger row.
+- Wave passes on spoken claim, no command output.
+- Execution before triage (Wave 0 skipped).
+- Blocker worked around silently.
+- Heal loop past 3 cycles with same failure.
+- Plan doc polluted with logs/decisions.
 
-All mean: stop, diagnose with Chopper's ledger, decide continue/retry/escalate.
+→ Stop, diagnose, escalate.

package/content/skills/mugiwara-workflow/references/workspace-layout.md

@@ -0,0 +1,50 @@
+# Workspace layout
+
+Every mission creates and works inside `.mugiwara/` at the repo root.
+
+```
+.mugiwara/
+├── config              → runtime mode config (gitignored; project overrides global)
+├── state.json          → computed mission state at every wave boundary (scripts/savepoint.sh)
+├── spec/               → brainstorm output: YYYY-MM-DD-<mission>.md
+├── plans/              → plan doc: YYYY-MM-DD-<mission>.md — CLEAN, Nami-only, source of truth from Wave 2
+├── results/            → per-mission folder: results/<mission>/ holds every wave artifact
+│   └── <mission>/
+│       ├── 01-execution.md   → wave 3: task table + evidence
+│       ├── 02-audit.md       → wave 4: checkpoint report
+│       ├── 03-quality.md     → wave 5: quality report
+│       ├── 04-gates.md       → wave 6: gate verdict
+│       ├── 05-healing.md     → wave 8: healing report (only when heal ran)
+│       ├── 06-closure.md     → wave 9: closure summary (KEEP at cleanup)
+│       ├── 07-pr-verdict.md  → wave 9: PR material (KEEP at cleanup)
+│       └── todos.md          → execution checkbox list
+├── reports/            → mission report (aggregate): YYYY-MM-DD-<mission>.md — one-file summary of all waves
+├── review/             → review + security findings
+├── issues/             → blocker log: YYYY-MM-DD-<mission>-blockers.md
+└── logs/               → Luffy's decision + check-in log: YYYY-MM-DD-<mission>.md (deleted at cleanup)
+```
+
+Naming rule: every artifact inside `results/<mission>/` uses the SAME mission
+name, no date prefix — the folder is the grouping, numbered by wave order
+(`01-`, `02-`, …). Unnumbered support files may sit alongside the numbered
+ones (`todos.md`, `resume.md`, `eval.md`, evidence logs) and are not part of
+the waves table. `reports/` and `logs/` and `plans/` files carry the
+`YYYY-MM-DD-` date prefix because they are cross-mission folders; `results/`
+does not, because each mission owns its folder.
+
+The plan doc stays clean: it holds ONLY the execution plan (waves, tasks,
+criteria, risks). Who did what, route decisions, and check-in verdicts go to
+`logs/`; the closure report goes to `results/<mission>/06-closure.md`. Nothing
+non-plan pollutes the plan doc.
+
+The owning agent creates the folder it needs on first write. No mission
+artifacts go outside `.mugiwara/`.
+
+## Cleanup (Wave 9)
+
+Delete consumed: `results/<mission>/01-execution.md` through
+`05-healing.md` and `todos.md` (wave artifacts), `logs/`, `spec/`, `review/`,
+`issues/`. Keep: `results/<mission>/06-closure.md`,
+`results/<mission>/07-pr-verdict.md`, `plans/`, `reports/`, `config`,
+`state.json`, `lessons.md` (cross-mission state: `logs/lessons.md`, `backup/`,
+`manifest.json`). List candidates before deleting.

package/content/skills/using-mugiwara/SKILL.md

@@ -1,20 +1,18 @@
 ---
 name: using-mugiwara
-description: Use at session start or on any task — explains how the crew works, classifies missions, routes to the right specialist. Front door to the Straw Hat crew.
+description: How Mugiwara works — crew overview, pipeline summary. Documentation reference. Trigger: "how does mugiwara work", "what is mugiwara", "which crew member", "crew overview", "mugiwara how".
 ---
-
-# Using Mugiwara (Front Door)
+# Using Mugiwara (Reference)
 
 ## Skip when
 
-- Lane 0 direct work: typo, rename, or single-file fix under 20 LOC.
-- User explicitly declined the crew for this request.
+- `mugiwara-orchestration` is the gatekeeper — it auto-loads for task routing and classification. This skill is a documentation reference only.
 
-Mugiwara is a governed engineering team in your coding agent. 14 specialists — triage, brainstorm, plan, execute, audit, quality, gates, review, security, heal — with evidence at every step and cost tracking. Runs inline in the main conversation.
+Mugiwara is a governed engineering team in your coding agent. 11 specialists — triage, brainstorm, plan, execute, audit, quality, gates, review, security, heal — with evidence at every step and cost tracking. Runs inline in the main conversation.
 
 ## How it works
 
-1. The crew auto-activates for non-trivial requests. You do NOT need to call `using-mugiwara` at session start — it's an optional router.
+1. `mugiwara-orchestration` auto-loads as gatekeeper for every task — classify, route, check-in, close.
 2. The pipeline: Luffy triage → Usopp brainstorm → Nami plan → Zoro execute → Chopper audit → Sanji quality → Franky gates → Robin/Jinbe review → Brook heal → Luffy closure.
 3. Every wave runs inline in the main thread. Subagents only for [PARALLEL] task batches.
 4. Evidence over claims — no wave passes on assertion. Checks must be re-run.
@@ -35,18 +33,9 @@ Mugiwara is a governed engineering team in your coding agent. 14 specialists —
 | Robin | Reviewer — breaking-change map (read-only) |
 | Jinbe | Security — STRIDE, OWASP, secret scan (read-only) |
 | Brook | Healer — reads ledger, fixes failures |
-| Skeptic | Adversarial verifier (read-only) |
 | Resume | Continuity — rebuild from state.json |
 
-## What to do
-
-1. If the user asks how mugiwara works — summarize in 3 lines.
-2. If the user gives a task — classify: Trivial / Explicit / Exploratory / Open-ended / Ambiguous.
-3. Route:
-   - Clear, small → Nami (plan) or Zoro (execute).
-   - Vague, needs direction → Usopp (brainstorm).
-   - Anything else → Luffy (full triage + check-ins).
-   - Review → Robin. Security → Jinbe. Audit → Chopper. Heal → Brook.
-4. Record the route in `.mugiwara/logs/`.
-
+For task routing and classification, `mugiwara-orchestration` auto-loads as gatekeeper.
+This skill is documentation — load manually with `/using-mugiwara` or similar trigger phrases.
 Full pipeline: see skills/mugiwara-workflow.
+First time? Run `/mugiwara onboard` for guided setup. See `content/agents/onboarding-guide.md`.