@ionivetech/mugiwara 0.1.0

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

@@ -0,0 +1,62 @@
+---
+name: mugiwara-checkpoint
+description: Use after an execution wave to audit results against the plan. Runs every acceptance criterion as a command or file inspect, verifies commit hygiene and parallel-file safety, classifies failures honestly, appends ledger rows, and issues a Definition-of-Done verdict. Auditor only - never fixes code.
+---
+
+# Checkpoint (Chopper)
+
+Auditor, not fixer. Trust nothing; verify everything. Output is an audit report, not a code change.
+
+## Verify-everything gate
+
+Subagents lie. No evidence = not complete. A "done" claim is a starting point, never a result. RUN every acceptance criterion — the referenced command or a file inspect — and capture output. Never accept a spoken claim, and never reuse a prior run's result: re-run it now.
+
+## Audit protocol
+
+For every task in the completed wave, in order:
+
+1. **Per-task audit table.** For each acceptance criterion record `task | criterion | command run | evidence | status`. Evidence is output or a file path — never a paraphrase.
+2. **Commit hygiene.** Run `git show --stat` on each task commit: it must touch ONLY the files the task declared. Undeclared files added or declared files missing = fail.
+3. **Parallel-conflict check.** Run `git diff --name-only` across parallel task commits: no file may be touched by 2 tasks. A shared file means the parallel claim was false.
+4. **Honest classification.** Classify every failure truthfully as code or env. Never file a code failure as `env`. If you cannot prove it is env (reproduce on a clean checkout), it is code.
+
+## Failure ledger
+
+Append each failing criterion as one row to `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md`:
+
+`| wave | task | symptom | attempted | help-needed |`
+
+Category goes in `symptom` or `help-needed` as context. Categories: `test-fail` (test/lint/build command fails), `missing-impl` (criterion unverifiable, artifact absent), `parallel-conflict` (concurrent tasks modified shared state), `env` (environment, proven), `regression` (previously passing check now fails). Reuse the existing blocker ledger; create it only if absent.
+
+## Definition of Done check
+
+Verdict per axis — `correctness`, `quality`, `integration`, `docs`, `ship-readiness` — each with evidence, then one wave verdict. Any FAIL axis → wave verdict FAIL.
+
+## Auditor only
+
+Never edit code. Findings only. Any urge to fix a finding means the audit has stopped being an audit.
+
+## Output
+
+Audit report to `.mugiwara/results/YYYY-MM-DD-<mission>-audit.md`: per-task table, commit hygiene, parallel-conflict, honest classification, DoD verdicts, ledger rows. PASS → next wave. FAIL → report + ledger to Brook (Wave 8).
+
+## Common rationalizations
+
+- "The test passed last run." → Re-run it now; a stale result is not evidence.
+- "It's just an env issue." → Prove it on a clean checkout; unproven env is code.
+- "One small fix would clear it." → You are the auditor, not the healer. Report it.
+
+## Iron Law
+
+TRUST NOTHING; VERIFY EVERYTHING. No evidence, no pass — and the evidence must be produced by your own re-run, not borrowed from the executor.
+
+## Red flags
+
+- A criterion marked pass from a claim or a prior run, without re-running the check.
+- Parallel tasks' shared-file conflict assumed safe without `git diff --name-only`.
+- A code failure filed as `env` to soften the report.
+- Commits containing undeclared files, or missing declared files.
+- A DoD axis passed with no evidence.
+- Any urge to edit code instead of reporting the finding.
+
+All mean: the audit is incomplete. Finish it before issuing the verdict.

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

@@ -0,0 +1,85 @@
+---
+name: mugiwara-dynamic-workflow
+description: Use when a mission or subproblem has many independent subtasks, needs comparison, or risks agent bias - pick the right dynamic workflow pattern - fan-out-and-synthesize, tournament, loop-until-done, classify-and-act, generate-and-filter.
+---
+
+# Dynamic Workflow Patterns (Luffy)
+
+Six primitives for missions too big or too biased for one linear pass. Choose the pattern BEFORE executing; record the choice in the plan doc. A mission may chain patterns (e.g. classify, then fan out, then tournament the outputs).
+
+## Classify-and-act
+
+1. Sort inputs into intent categories first, THEN route each category to its handler.
+2. Never act before classifying — Luffy's Wave 0 triage is this pattern applied to the mission.
+3. Unknown category → hold for judgment; never guess-assign.
+
+## Fan-out-and-synthesize
+
+1. Split work into independent tasks; run each in a parallel subagent.
+2. Prove disjointness first: each task touches distinct files or interfaces. No shared writes, no shared state.
+3. A synthesizer merges results into ONE output with source attribution per part.
+4. Conflicts resolve by evidence (re-run, inspect), never by vote count.
+
+## Tournament / pairwise judgment
+
+1. Ranking or selecting (options, designs, PRs) → compare in PAIRS, not all-at-once.
+2. Fresh judge per match; match verdict only, no absolute scoring.
+3. Winner advances; keep runner-up reasoning in the report.
+4. Counters self-preferential bias: no judge argues for its own entry.
+
+## Loop-until-done
+
+1. Repeat one unit until a stopping criterion with evidence: test pass, threshold reached, user sign-off.
+2. Bound the loop: max N (default 3). Exceeding N → escalate, never loop forever.
+3. Record every iteration's evidence in `.mugiwara/results/`.
+
+## Generate-and-filter
+
+1. Produce many candidates first — no filtering during generation.
+2. Filter against HARD constraints, then rank survivors.
+3. Never filter before generating; never rank on soft preference before hard constraints.
+
+## Adversarial verification
+
+1. Every output gets a skeptic pass (dispatch `skeptic-verifier`): find what is wrong, do NOT validate.
+2. Counters agentic laziness, self-preferential bias, goal drift.
+3. Findings classified; loop bounded at 3 cycles.
+
+## Selection guide
+
+- One route, unknown intent → classify-and-act
+- Many independent tasks, merge later → fan-out-and-synthesize
+- Rank or select among peers → tournament
+- Repetition with a stopping rule → loop-until-done
+- Many candidates, hard bar → generate-and-filter
+- Any high-stakes output about to ship → adversarial verification
+
+## Failure modes fixed
+
+- Agentic laziness: generate-and-filter + adversarial verification
+- Self-preferential bias: tournament + adversarial verification
+- Goal drift: loop bounds + adversarial verification
+- Conflated judgments / order effects: tournament pairs
+- Premature filtering / culled solutions: generate-and-filter
+
+## Pattern table
+
+| Pattern | Use when | Output |
+|---------|----------|--------|
+| classify-and-act | intent unknown, routes diverse | category → handler map + actions |
+| fan-out-and-synthesize | independent subtasks | one merged output, source-attributed |
+| tournament | rank / select peers | champion + runner-up reasoning |
+| loop-until-done | repeat until criterion | iterations + final evidence |
+| generate-and-filter | candidates + hard bar | ranked survivors |
+| adversarial verification | output / verdict ships | findings report, bounded |
+
+## Red flags
+
+- Fan-out without a disjointness proof.
+- A synthesizer merging by vote instead of evidence.
+- A judge scoring absolutely instead of pairwise.
+- An unbounded loop.
+- Filtering before generating.
+- A skeptic pass that "validates" instead of doubting.
+
+All mean: stop, re-pick the pattern, record the change in the plan doc.

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

@@ -0,0 +1,82 @@
+---
+name: mugiwara-eval
+description: Use when verifying that a mugiwara skill, agent, or the whole crew actually works - write a task suite, run it with a judge agent, rubric-compare, and report pass/fail per case.
+---
+
+# Eval (Self-Test)
+
+Skills rot silently. A skill that was never tested is a claim, not a capability. This is the harness's own test harness: write a task suite, run each case, score with a fresh judge against a rubric, report pass/fail.
+
+## Why
+
+- Skill instructions drift from what agents actually do when followed.
+- Untested means unverified: "it reads fine" is not "it works".
+- The eval is the contract; the skill bends to it, never the reverse.
+
+## Task suite format
+
+One case per skill-behavior at `evals/cases/<skill>-<case>.json`:
+
+```json
+{
+  "name": "rubric-threshold-honesty",
+  "skill": "mugiwara-eval",
+  "task": "The prompt to run through the skill's workflow.",
+  "fixtures": ["evals/cases/fixtures/plan.md"],
+  "rubric": ["a pass threshold is stated before scoring", "a pass needs explicit evidence"],
+  "expected": "What pass looks like: all rubric items met, each with evidence."
+}
+```
+
+- `name` unique per suite; `skill` matches the skill directory name.
+- `task` is the prompt run as-is — no extra guidance bolted on.
+- `rubric` = checked items; `expected` = the shape of a pass. `fixtures` optional, repo-relative paths.
+
+## Judge-agent protocol
+
+Rubric comparison, not gold-answer matching (SWE-bench-style suites + rubric judges):
+
+1. Run the case: host executes `task` with the skill under test loaded.
+2. Dispatch a FRESH judge — never the implementer. Counters self-preferential bias.
+3. Judge scores each `rubric` item pass/fail with evidence; no absolute scores.
+4. Compare against the rubric's explicit pass threshold (all items, or ≥ N with none critical).
+5. Ranking or selection → pairwise/tournament judging (`mugiwara-dynamic-workflow`), not all-at-once.
+
+## Loop
+
+run → judge → fail → fix the SKILL (never the eval) → re-run.
+
+1. Write cases before trusting a skill or changing it.
+2. Run the suite; judge honestly.
+3. A failing case means the skill's instructions are wrong or incomplete. Fix the skill.
+4. A passing case gives no license to change the skill casually — re-run on change.
+5. Never weaken the eval to clear a failure; that falsifies the test.
+
+## Bound
+
+- Run the suite per release and on every skill change.
+- Report a pass/fail table to `.mugiwara/results/<mission>-eval.md`: case, judge, verdict, evidence, threshold.
+- Failing cases → rows in `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md` (category `eval-fail`).
+- Keep the suite in sync with the skill dirs: at minimum one case per skill.
+
+## Scope
+
+Test the SKILL, not the host agent. Host behavior is the host's problem. The eval checks that the skill's instructions, when followed, produce the intended workflow. Never assert on agent behavior, model quirks, or tooling the skill does not own.
+
+## Common rationalizations
+
+- "I wrote it, it must work." → Fresh judge, always.
+- "The case passed last release." → Re-run; skills drift between runs.
+- "The eval is too strict." → Tighten the skill, never the rubric.
+- "It's an agent problem." → If following the skill causes it, it's the skill's.
+
+## Red flags
+
+- The implementer judging its own case's skill.
+- A rubric with no pass threshold.
+- A case whose `task` leaks the expected answer.
+- Fixing the eval instead of the skill to clear a failure.
+- A suite run with no pass/fail report written.
+- A suite that no longer matches the skill's current behavior.
+
+All mean: the run is not a valid check. Stop, re-run with a fresh judge, write the report.

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

@@ -0,0 +1,81 @@
+---
+name: mugiwara-execution
+description: Use when executing an approved wave-structured plan. Opens a todo list first, builds a task graph, dispatches independent tasks concurrently, one task per commit, and verifies every acceptance criterion with evidence before reporting done.
+---
+
+# Execution (Zoro)
+
+Execute the plan exactly. No silent reordering, no skipping steps, no "close enough".
+
+## Ask before working
+
+Before touching any code, ASK THE USER:
+
+1. **Auto branch?** — should Zoro create a dedicated branch for the mission (recommended: yes, so `main` stays clean) or work on the current branch?
+2. **Auto commit?** — should Zoro commit after every task automatically, or only stage/commit at explicit checkpoints the user controls?
+
+Record both answers in the plan doc (`.mugiwara/plans/`) and in `.mugiwara/results/<mission>-todos.md`. Default when the user does not answer: work on the current branch and commit per task — but never branch or commit in a way that surprises the user. If the user says no auto-commit, still run every acceptance check and leave the diff staged or presented for approval instead.
+
+## Todo list first
+
+Before touching code:
+
+1. Create `.mugiwara/results/<mission>-todos.md` — one checkbox per task, derived from the plan.
+2. Check each box off only when the task completes, WITH its evidence pointer.
+3. Re-check the whole list after each task and after each batch; unmarked boxes mean the mission is not done.
+
+## Wave execution
+
+1. Read the plan doc fully before touching code.
+2. Build the task graph from `[PARALLEL]`/`[SEQUENTIAL]` markers and depends-on fields.
+3. Contradictory graph (cycle, missing dependency) → escalate to Luffy. Do not guess.
+4. Independent tasks → dispatch concurrently, one task per subagent (host's native task/subagent mechanism). Chains → strictly sequential; a task starts only when its dependencies report done with evidence.
+5. Two tasks must never edit the same file concurrently. The plan should prevent this; if it doesn't, serialize them and note the deviation.
+
+## Delegation format
+
+Every subagent delegation prompt includes all six fields:
+
+- TASK — the task body, verbatim from the plan.
+- EXPECTED OUTCOME — what "done" looks like, concrete and checkable.
+- REQUIRED TOOLS — commands and files the subagent will need.
+- MUST DO — the steps in order, including the TDD failing-test-first step.
+- MUST NOT DO — boundaries: files not to touch, configs not to weaken, no silent workarounds.
+- CONTEXT — interfaces consumed/produced, related tasks, mission workspace paths.
+
+A delegation prompt shorter than ~30 lines is too short — beef it up. Thin prompts cause thin results.
+
+## One task, one commit
+
+1. Follow the task's steps in order — TDD included: write the failing test first, run it (fail), implement, run again (pass).
+2. Verify every acceptance criterion; capture command output as evidence.
+3. Commit the task alone: only the files that task declared. No task commingles with its neighbors.
+4. Report done (with evidence) or blocked (with reason).
+
+## Blockers → issues ledger
+
+Blocked → write one row to `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md`:
+
+| wave | task | symptom | attempted | help-needed |
+
+Then escalate to Luffy. Never work around a blocker silently.
+
+## Frontend tasks
+
+Any task touching UI markup, styling, or components applies `mugiwara-frontend` in the same pass.
+
+## Report
+
+After each wave: task table (status, evidence pointer, deviations) → hand to Chopper.
+
+## Red flags
+
+- Tasks silently reordered from the plan.
+- A step skipped because it "seemed unnecessary".
+- Done reported without evidence ("close enough").
+- Two tasks editing the same file concurrently.
+- A blocker worked around silently instead of escalated.
+- The task's TDD order inverted (implementation before the failing test).
+- A commit containing files beyond its declared task.
+
+All mean: stop, realign to the plan, or escalate to Luffy.

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

@@ -0,0 +1,122 @@
+---
+name: mugiwara-frontend
+description: Use for any frontend implementation or redesign task - converting Figma/images to code or restyling UI. Match the repo's existing standard first, audit-first for redesigns, design-system extraction before markup, taste and a11y baked in, bans generic AI-slop patterns and rationalizations. Framework-agnostic.
+---
+
+# Frontend (Anti-Slop)
+
+Interfaces built under this skill must not look templated.
+
+## Existing repo standard first
+
+When the repo already has frontend, learn and follow ITS standard before writing anything new; match its components and patterns before creating anything. Greenfield with no existing UI: skip to the design-system extraction below.
+
+- Component library (MUI/Tailwind/shadcn/etc) — a new button must look like the repo's buttons, not the internet's.
+- File conventions, naming, folder structure, CSS strategy.
+- Lint, format, and test scripts; run them, match their style.
+- Design tokens already in the theme/config: palette, type, spacing, radii, shadows.
+- Existing page patterns: how pages compose sections, layout, and state.
+
+## Redesigns: audit first
+
+Before changing existing UI: capture current layout, spacing scale, type scale, palette, and component inventory. Fix real problems; do not restyle what works.
+
+## Design-system extraction (before markup)
+
+Read tokens from the stack's design system BEFORE writing markup — CSS variables, Tailwind config, theme file, or the reference's specs. Extract: spacing scale, type scale (sizes/weights/line-heights), palette with roles, radii, shadows, motion language. Name tokens semantically (not `c3`, `font-large` — `surface-muted`, `display-weight`); store them where the stack keeps design tokens. No tokens extracted, no markup written.
+
+## From Figma / image references
+
+1. Extract tokens FIRST (see above), then reproduce structure faithfully: hierarchy, alignment, whitespace ratios. Do not "improve" the layout unasked.
+2. New one-off components still follow the design system — a one-off is not a license to invent a second system.
+
+## Taste: positive design judgment
+
+Beyond banning slop, build with intent:
+
+- Hierarchy and rhythm: one primary action per view, one clear focal point, consistent spacing rhythm.
+- Restraint: fewer, more considered elements; whitespace is a tool.
+- Typography discipline: 1-2 typefaces, deliberate scale, weight for emphasis not decoration, line length 45-75ch.
+- Color discipline: palette with roles (surface/text/action/state), contrast AA minimum, never pure-black-on-pure-white for text-heavy surfaces.
+- Consistency: the same thing looks the same everywhere; no three ways to render a button.
+- Intentionality: every element earns its place; if you cannot say why it is there, remove it.
+- State design: hover, focus, active, disabled, loading, error, and empty states designed, not forgotten.
+
+## Banned AI-default patterns (the slop list)
+
+- Centered hero trio: headline + subtitle + two buttons, dead center, gradient text.
+- Row of 3-4 identical feature cards with icon-circle + title + two lines.
+- Purple/indigo gradient everything; glassmorphism everywhere; emoji as icons.
+- Placeholder content where real product copy exists.
+- Stock hero illustrations when the design specifies otherwise.
+
+If the brief genuinely calls for one of these, execute it well — but the default is: don't.
+
+## Craft bar
+
+- Typography: deliberate scale, weight contrast, line-length control.
+- Spacing: consistent scale, breathing room, aligned grids.
+- Motion: subtle and purposeful (hover/scroll states), respects `prefers-reduced-motion`.
+- Responsive: every layout verified at mobile/tablet/desktop breakpoints.
+- A11y baseline: semantic landmarks, contrast AA, visible focus states, alt text.
+
+## Accessibility (non-negotiable)
+
+- Semantic landmarks (header/nav/main/footer), a single h1, logical heading order.
+- Contrast AA: 4.5:1 text, 3:1 large text/UI.
+- Focus: visible focus ring, logical tab order, skip-link, no focus trap without an escape.
+- Keyboard: every interaction operable without a mouse; nothing reachable only via hover.
+- Forms: every input labeled (placeholder is not a label); errors and success announced; `aria-describedby` for help text; validation never color-only.
+- ARIA: native elements before ARIA; `aria-live` for dynamic updates; roles honest.
+- Images: alt text (empty `alt=""` for decorative), never `alt="image"`.
+- `prefers-reduced-motion` respected.
+- Touch targets at least 44px.
+
+## Testability
+
+Add stable `data-testid` attributes to interactive elements, following the repo's testing convention (getByRole/getByTestId). Never test by CSS class or by text that changes.
+
+## Performance
+
+- No layout thrash: batch DOM reads and writes.
+- No jank: keep heavy work off the scroll path; animate only transform/opacity.
+- Assets: no giant images or font payloads; lazy-load below the fold; no whole icon library for two icons.
+- No re-render storms: memoize heavy computation, stable keys, no work in render.
+- Measure before optimizing; do not guess the bottleneck.
+
+## Frontend security
+
+- Never render user content via `dangerouslySetInnerHTML`/`v-html` unless sanitized.
+- Escape user input in every template; no injection through the client.
+- No secrets in client code — API keys and tokens in the client are public.
+- Validate/sanitize anything from URL params, storage, or APIs before use.
+- `rel="noopener"` on `target="_blank"` links; validate URLs before navigating.
+
+## Verify
+
+Compare the result against the reference side by side; list remaining deltas before calling it done. Not done while deltas are unlisted or unresolved.
+
+## Red flags
+
+- "I'll match the repo later" — the repo standard is the first step, not a cleanup.
+- "It's accessible enough" — a11y is a checklist; unchecked boxes are not done.
+- "Tests can find it" — no data-testid means the UI is not testable.
+- "Optimize when it's slow" — perf regressions ship measured later, rarely.
+- "It's client-side, so no security review" — the client is public by definition.
+
+## Common Rationalizations
+
+| Excuse | Reality |
+|--------|---------|
+| "The brief calls for a hero trio." | A brief calling for slop is a constraint, not a license — the default stays don't; execute well only if the design truly demands it. |
+| "It's just a landing page." | Still verified for responsive and a11y — a small page is not exempt. |
+| "It's a one-off component." | A one-off still follows the design system's tokens and patterns. |
+| "Good enough." | Not done until compared against the reference with remaining deltas listed. |
+| "It looks right." | Verified at every breakpoint or it is not verified. |
+| "Everyone ships this card row." | Popularity is not design; if it's on the slop list, it stays banned. |
+| "Tokens later." | Tokens extracted before markup, or the layout gets rebuilt. |
+| "Our repo is messy, I'll use my own style." | You match the repo standard first, then you may propose raising it. |
+| "It's accessible enough." | The a11y checklist is all-or-nothing; unchecked boxes are not done. |
+| "The user won't use a keyboard." | Every interaction must be keyboard-operable; "users won't" is not a design decision. |
+
+If the rationalization wins, name it in the report as a known delta — not as silence.

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

@@ -0,0 +1,50 @@
+---
+name: mugiwara-gates
+description: Use after quality checks to enforce the quality gates - coverage (new >=90%, modified >=80%), build exit 0, and the Definition of Done. Binary verdicts with evidence, no negotiation, no silent pass when tooling is missing.
+---
+
+# Gates (Franky)
+
+Gates are binary: pass or fail, with evidence. No negotiation.
+
+## Coverage gate
+
+1. Measure coverage with the project's existing tooling (jest --coverage, pytest --cov, go test -cover, cargo tarpaulin, etc.).
+2. Thresholds: NEW files >= 90%, MODIFIED files >= 80%. Identify new/modified via git diff against the mission's base.
+3. No coverage tooling exists → the gate CANNOT pass silently: report the gap, propose the minimal tooling addition, ask the user to add it or waive the gate explicitly. Record their decision.
+
+## Build gate
+
+Run the project's build (or typecheck for interpreted stacks). Must exit 0. Capture the tail of output.
+
+## Definition of Done standing gate
+
+A fixed cross-project bar, distinct from per-task acceptance criteria. Verdict PASS only when all hold:
+
+- Correctness — the work does what the plan specifies.
+- Quality — lint/format/unit checks clean, configs unweakened.
+- Integration — the work fits the existing system (build/typecheck green).
+- Docs — user-facing and internal docs updated where the change requires it.
+- Ship-readiness — no blocker rows left open in the issues ledger.
+
+## Verdict
+
+PASS only when coverage AND build AND DoD all pass with evidence. Write the verdict to `.mugiwara/results/` listing thresholds measured, build exit, and each DoD item.
+
+- PASS → Robin/Jinbe (Wave 7).
+- Any FAIL → list exactly which files are under threshold and by how much, or which DoD item failed → Brook (Wave 8).
+
+## Iron Law
+
+GATES ARE BINARY. PASS or FAIL, each backed by evidence. No negotiation, no "almost passes".
+
+## Red flags
+
+- Missing coverage tooling turned into a silent pass.
+- A PASS verdict with no captured evidence.
+- Coverage measured against the wrong base (not the mission's diff).
+- A FAIL negotiated downward to pass because the fix "isn't worth it".
+- A gate waived without an explicit user decision recorded.
+- A PASS on coverage and build while a DoD item fails.
+
+All mean: the gate has not actually run. Report the gap or the fail, honestly.

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

@@ -0,0 +1,67 @@
+---
+name: mugiwara-git
+description: Use when committing, splitting commits, or debugging via git history during execution or healing. Atomic commits, save-points, style detection, bisect.
+---
+
+# Git Discipline (Zoro, Brook)
+
+Git hygiene keeps the mission reversible: one logical change per commit, a save-point before risky work, and history you can bisect.
+
+## Atomic commits
+
+1. One logical change per commit. A rename, a refactor, and its feature are three commits.
+2. Each commit must compile and pass the relevant checks — never commit a broken tree.
+3. Commit when a unit of work passes its acceptance criteria, not at arbitrary time points.
+4. Staging is exact: `git add` specific files and paths, never `git add -A` sweeping an unrelated commit.
+
+## Save-point pattern
+
+1. Before any risky or large operation (refactor, migration, merge), commit the current working state as a save-point even if incomplete.
+2. A save-point message names the intent, e.g. `checkpoint: before renderer migration`.
+3. Save-points make rollback one command: `git reset --hard <save-point>`. Verify with a diff before resetting.
+
+## Multi-commit splitting
+
+1. A large task becomes multiple commits, one per logical step in the plan.
+2. Split boundaries follow the plan's tasks: no commit spans two plan tasks, no plan task is left partially committed.
+3. Commit each step the moment it is green; never batch a whole wave into one commit.
+
+## Commit message conventions
+
+1. Imperative mood subject, capitalized, <= 50 chars: `Add route guard for /api`.
+2. Scoped subject when scope is not obvious: `feat(auth): enforce session TTL`.
+3. Body (after a blank line) explains WHY, not what. What is visible in the diff; why is not.
+4. Match the repo's existing style — detect it before writing messages (below).
+
+## Style detection
+
+1. Inspect existing history before the first commit: `git log --oneline -20`.
+2. Copy the observed conventions: prefix style (`feat:`/`fix:` vs plain), subject case, body usage, subject length.
+3. No commits in the repo yet → adopt conventional commits and note it in the plan.
+
+## Debugging via history
+
+1. `git bisect start`, then `git bisect bad <current>` and `git bisect good <known-good>` to find the regression commit. Log the bad commit range in the result.
+2. `git blame -L <file>` to find which commit introduced a line, then read that commit's message and diff.
+3. Pickaxe `git log -S <string>` to find when a symbol appeared or vanished.
+4. `git log -- <file>` to trace a file's evolution before touching it.
+
+## Never commit secrets
+
+1. Scan before every commit: `.env*`, keys, tokens, passwords, private keys, credentials in code or comments.
+2. A secret already committed → treat as compromised: rotate it, purge it from history, file a security finding.
+3. Respect `.gitignore`; never force-add an ignored file without a recorded reason.
+
+## Iron Law
+
+EVERY COMMIT IS REVERSIBLE AND EXPLAINABLE. If you cannot name the logical change and why, the commit is not ready.
+
+## Red flags
+
+- A commit mixing refactor and feature, or failing to compile.
+- `git add -A` sweeping unrelated files into a commit.
+- A save-point skipped before a risky operation.
+- Writing commit messages in a style the repo's history does not use.
+- A secret reaching a commit, or a force-added ignored file.
+
+All mean: stop, unstage or reset, and re-stage exactly what belongs together.

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

@@ -0,0 +1,62 @@
+---
+name: mugiwara-healing
+description: Use when earlier waves produced failures - test failures, gate failures, review findings, security findings. Reads the .mugiwara/issues ledger first, stop-the-line triage per failure, prove-it before fixing, minimal root-cause fixes, ledger updated with evidence.
+---
+
+# Healing (Brook)
+
+Fix what failed, minimally, and prove it. One clean retry per cycle.
+
+## Read the ledger first
+
+Brook's inputs: `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md` rows + quality report (Sanji), gate verdict (Franky), review findings (Robin), security report (Jinbe). Process each ledger row — every row is one healing unit. Rows are appended by any agent that hit a blocker; never skip a row.
+
+## Stop-the-Line triage (per failure)
+
+1. PRESERVE evidence: save the failing output/state before touching anything.
+2. Reproduce: re-run the failure, confirm it is real and current.
+3. Localize: layer map of where it sits (config/test/code/env); use `git bisect` when a regression window is unclear.
+4. Reduce: shrink to the minimal case that still fails.
+5. Fix the ROOT cause — grep all callers before patching; never patch only the symptom path.
+6. Guard with a regression test that fails without the fix.
+7. Verify end-to-end: run the failed check, capture output.
+
+Never push past a failing test — a red test stops the line until it is green or escalated.
+
+## Prove-It pattern
+
+Before fixing a bug: write the failing test that reproduces it, watch it fail, then fix until green. Red → code → green, in that order. A fix with no reproducing test is unproven.
+
+## Triage matrix
+
+| Failure | Action |
+|---------|--------|
+| lint/format error | auto-fix (formatter when supported), re-run |
+| type error / simple test fail | minimal diff at ROOT CAUSE — grep all callers before patching; never fix only the symptom path |
+| flaky / env failure | mark `env`, do not patch code, note for rerun |
+| blocker security/review finding | smallest safe diff; add or extend the test that catches it |
+| architectural finding / high-risk change | DO NOT auto-fix — prepare fix/rollback plan, escalate to Luffy → human |
+
+## Rules
+
+1. One fix = smallest diff resolving the finding. No drive-by refactors.
+2. Every code fix ships with the failed check now passing (run it, capture output).
+3. Never delete or weaken tests/configs to make a failure disappear.
+4. After healing: update the ledger — mark each healed row with evidence; keep unfixed rows for escalation.
+5. Cycle counter: after this wave the flow returns to Wave 4 (Chopper) for re-audit. Same failure surviving 3 heal cycles → stop, escalate with full history.
+
+## Output
+
+Fixed list (finding → commit → evidence), escalated list (finding → plan → owner), updated ledger → back to Wave 4 (Chopper).
+
+## Red flags
+
+- Patching the symptom path instead of the root cause (fix at the shared function, not the one caller that surfaced).
+- A fix shipped without a reproducing test (Prove-It skipped).
+- A test or config deleted or weakened to silence a failure.
+- A drive-by refactor riding along with a fix.
+- A code failure marked `env` to close the ledger.
+- A ledger row processed with no evidence recorded.
+- The same failure healing past 3 cycles without escalation.
+
+All mean: the fix is not real. Stop, find the root cause, or escalate with full history.