@ionivetech/mugiwara 0.4.0 → 0.5.1

package/content/skills/mugiwara-execution/references/worked-example.md

@@ -0,0 +1,88 @@
+# Worked Example — Full TDD Task
+
+One task, from failing test to green commit, with real output.
+
+## The plan task
+
+```
+Task 3: extract formatDate to shared utils
+Files: src/utils/format.ts, src/utils/format.test.ts
+Size: S
+Steps:
+  [ ] Write failing test for formatDate export
+  [ ] Implement formatDate
+  [ ] Refactor callers to use shared function
+  [ ] Commit
+Acceptance: npm test -- src/utils/format.test.ts passes
+```
+
+## Step 1: Write failing test (RED)
+
+```ts
+// src/utils/format.test.ts
+import { formatDate } from './format';
+
+describe('formatDate', () => {
+  it('formats ISO date to locale string', () => {
+    const result = formatDate('2026-08-11T12:00:00Z');
+    expect(result).toBe('Aug 11, 2026');
+  });
+
+  it('returns "—" for null input', () => {
+    expect(formatDate(null)).toBe('—');
+  });
+});
+```
+
+```
+$ npm test -- src/utils/format.test.ts
+FAIL  src/utils/format.test.ts
+  ● formatDate › formats ISO date to locale string
+    TypeError: (0, format_1.formatDate) is not a function
+```
+
+## Step 2: Implement minimum (GREEN)
+
+```ts
+// src/utils/format.ts — add:
+export function formatDate(iso: string | null): string {
+  if (!iso) return '—';
+  return new Date(iso).toLocaleDateString('en-US', {
+    year: 'numeric', month: 'short', day: 'numeric',
+  });
+}
+```
+
+```
+$ npm test -- src/utils/format.test.ts
+PASS  src/utils/format.test.ts
+  ✓ formats ISO date to locale string
+  ✓ returns "—" for null input
+```
+
+## Step 3: Refactor callers
+
+```ts
+// Before: src/components/Invoice.tsx
+const date = new Date(invoice.createdAt).toLocaleDateString('en-US', {...});
+
+// After:
+import { formatDate } from '@/utils/format';
+const date = formatDate(invoice.createdAt);
+```
+
+## Step 4: Commit
+
+```
+$ git add src/utils/format.ts src/utils/format.test.ts src/components/Invoice.tsx
+$ git commit -m "feat: extract formatDate to shared utils
+
+Test-first: wrote failing test, implemented, refactored callers."
+```
+
+## What this teaches
+
+1. Test fails **for the right reason** (function doesn't exist), not a typo.
+2. Minimum implementation passes the test — no gold-plating.
+3. Refactor while green — callers use the shared function.
+4. One commit per logical task — not one per micro-step.

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

@@ -1,6 +1,6 @@
 ---
 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, component architecture, state management, responsive behavior, and WCAG 2.1 AA baked in; bans generic AI-slop patterns and rationalizations. Framework-agnostic.
+description: Use for frontend UI component, CSS styling, responsive layout, a11y/accessible — matching repo standards, design-system extraction, WCAG 2.1 AA. Bans AI-slop patterns.
 ---
 
 # Frontend (Anti-Slop)
@@ -12,6 +12,10 @@ description: Use for any frontend implementation or redesign task - converting F
 
 Interfaces built under this skill must not look templated.
 
+## Source-backed code
+
+Framework code from docs, not memory — `references/source-grounding.md`.
+
 ## Existing repo standard first
 
 Match the repo's standard before writing anything new; reuse its components and patterns. Greenfield with no UI: skip to design-system extraction.
@@ -100,25 +104,20 @@ Add stable `data-testid` to interactive elements per the repo's testing conventi
 
 ## Red flags
 
-- "I'll match the repo later" — the repo standard is the first step, not cleanup.
-- "It's accessible enough" — the a11y checklist is all-or-nothing.
-- "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.
-- "New screen, new components" — primitives are the default; bespoke is the exception.
-- "Global store for everything" — local state first; lift only what is shared.
+- "It's client-side, so no security review" — client is public by definition.
+- "New screen, new components" — primitives are default; bespoke is exception.
+- "Global store for everything" — local state first; lift only what's shared.
 
 ## 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. |
-| "It's just a landing page." / "It's a one-off component." | Still verified for responsive and a11y; still follows the design system's tokens and patterns. |
-| "Good enough." / "It looks right." | Not done until compared against the reference with deltas listed, at every breakpoint. |
-| "Everyone ships this card row." | Popularity is not design; if it's on the slop list, it stays banned. |
+| "The brief calls for a hero trio." | A brief calling for slop is a constraint, not a license. |
+| "It's just a landing page." | Still verified for responsive and a11y at every breakpoint. |
+| "Good enough." | Not done until compared against the reference with deltas listed. |
+| "Everyone ships this card row." | Popularity is not design; banned stays banned. |
 | "Tokens later." | Tokens extracted before markup, or the layout gets rebuilt. |
 | "Our repo is messy, I'll use my own style." | Match the repo standard first, then propose raising it. |
-| "The user won't use a keyboard." / "Context for everything." | Every interaction keyboard-operable; server state belongs at a data layer, not a global store. |
-| "It's a quick prop, no new component." | 3+ boolean props is the boundary — split the component. |
 
-If the rationalization wins, name it in the report as a known delta — not as silence.
+If a rationalization wins, name it in the report as a known delta — not as silence.

package/content/skills/mugiwara-frontend/references/design-tokens.md

@@ -0,0 +1,25 @@
+# Design Tokens
+
+Extract from the stack's design system before writing markup. No tokens extracted = no markup written.
+
+## Token categories
+
+| Category | Examples | Naming convention |
+|----------|----------|-------------------|
+| Spacing scale | 4, 8, 12, 16, 24, 32, 48, 64 | `space-xs` through `space-3xl` |
+| Type scale | 12, 14, 16, 18, 24, 32, 48 | `text-sm` through `text-display` |
+| Palette | surface, text, border, accent | `surface-muted`, `text-primary`, `border-default` — semantic, not color names |
+| Radii | 2, 4, 8, 12, round | `radius-sm` through `radius-full` |
+| Shadows | elevation levels | `shadow-sm` through `shadow-xl` |
+| Motion | duration, easing | `duration-fast`, `ease-in-out` |
+
+## Where to store
+
+- Tailwind: `tailwind.config.ts` extend theme
+- MUI: `createTheme()` 
+- CSS: CSS custom properties on `:root`
+- Wherever the repo already keeps tokens — don't invent a second system
+
+## Naming rule
+
+Semantic names, not visual: `surface-muted` not `gray-100`, `text-danger` not `red-500`. The name tells you what it IS, not what it LOOKS LIKE. This survives a palette change without renaming.

package/content/skills/mugiwara-frontend/references/slop-catalog.md

@@ -0,0 +1,19 @@
+# AI Slop Catalog
+
+Banned default patterns. If the brief genuinely calls for one, execute it well — but the default is: don't.
+
+## The list
+
+| Pattern | Why banned | What to do instead |
+|---------|-----------|-------------------|
+| Centered hero trio | Headline + subtitle + two buttons, dead center, gradient text | Layout from the design system; hero sections follow repo patterns |
+| Row of 3-4 feature cards | Icon-circle + title + two lines, all identical | Vary layouts; not every section is a card row |
+| Purple/indigo gradient | Everything is gradient, everywhere | Use the design system's palette; gradient is for emphasis, not identity |
+| Glassmorphism everywhere | Frosted glass effect on every surface | Glass is one effect among many; use sparingly on overlays/modals |
+| Emoji as icons | 🚀 ⚡ 🔥 🎯 instead of proper icon library | Use the repo's icon library; emoji only where user-facing text already uses them |
+| Placeholder content | "Lorem ipsum" where real copy exists | Pull real copy from the reference or leave marked with `TODO: copy` |
+| Stock hero illustrations | Generic blob-people or isometric cubes | Use the repo's illustration style or omit; a missing image is better than a wrong one |
+
+## When it IS acceptable
+
+If the design brief calls for it (Figma shows a hero trio), implement it faithfully. The ban is on the **default**, not on the request. A brief that specifies a pattern is not slop — it's a requirement.

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

@@ -1,6 +1,6 @@
 ---
 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.
+description: Use after quality checks — coverage thresholds, build exit 0, Definition of Done. Binary verdicts with evidence, no negotiation.
 ---
 
 # Gates (Franky)
@@ -15,12 +15,12 @@ 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.
+2. **Read thresholds from config.** Read `.mugiwara/config` (project) then `~/.mugiwara/config` (global) for `coverage_new` and `coverage_modified`. Defaults: new files >= 90%, modified files >= 80%. A missing key or a key set to `0` means "no threshold for this category." 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.
 
 ## User-AC coverage override (per `mugiwara-testcases`)
 
-When user acceptance criteria are declared, the coverage thresholds (90/80) apply only to unit-level new/modified code; the user-AC verdict governs ship-readiness. An e2e user suite that adds ~0% coverage is not a gate failure. The user-AC verdict must come from the quality wave evidence — user suites actually run — never asserted.
+When user acceptance criteria are declared, config coverage thresholds apply only to unit-level new/modified code; the user-AC verdict governs ship-readiness.
 
 ## Build gate
 
@@ -32,7 +32,7 @@ Position: after quality checks, before the final gates below. Optional — it ru
 
 ## Definition of Done standing gate
 
-A fixed cross-project bar, distinct from per-task acceptance criteria. Verdict PASS only when all hold:
+A fixed cross-project bar, distinct from per-task acceptance criteria. Full definitions: `references/definition-of-done.md`. Verdict PASS only when all hold:
 
 - Correctness — the work does what the plan specifies.
 - Quality — lint/format/unit checks clean, configs unweakened.

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

@@ -1,6 +1,6 @@
 ---
 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.
+description: Use for commits, splitting, or git history debugging — atomic commits, save-points, style detection, bisect.
 ---
 
 # Git Discipline (Zoro, Brook)

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

@@ -1,6 +1,6 @@
 ---
 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.
+description: Use when earlier waves produced failures, broken things to fix — reads blocker ledger, stop-the-line triage, root-cause fixes, prove-it before fixing. Max 3 cycles.
 ---
 
 # Healing (Brook)
@@ -57,15 +57,42 @@ Before fixing a bug: write the failing test that reproduces it, watch it fail, t
 
 ## Worker subagents
 
-Brook runs inline; the only dispatches are disposable WORKER subagents for genuinely parallel work. Three named workers:
+Brook runs inline for triage + ledger reading. Parallel fixes use disposable WORKER subagents.
 
-- **reviewer-worker** — adversarial diff review of Brook's fixes from a fresh context (per `mugiwara-review`).
-- **security-worker** — security pass over the fixes (per `mugiwara-security`).
-- **re-run-check worker** — independently re-runs the failed checks and returns raw evidence (command output, exit codes), so the re-verify is not Brook re-confirming its own fix.
+### Heal workers (parallel fixes)
 
-Flow: Brook aggregates worker findings → applies minimal root-cause fixes (triage matrix + Rules above) → dispatches a re-run-check worker to re-verify.
+After triage, group ledger rows that are **independent** (different files, no shared function/interface) for parallel healing:
 
-Workers are NOT crew members — disposable subagents, one narrow job, results return as a report. The crew itself always runs inline in the main thread, never Task-dispatched.
+```
+Ledger: 4 rows
+├─ Row 1: T3 settings POST guard missing     → src/routes/settings.ts
+├─ Row 2: T5 formatDate locale bug           → src/utils/format.ts
+├─ Row 3: review minor: error msg wording    → src/middleware/rbac.ts
+├─ Row 4: coverage: add test for edge case   → src/routes/users.test.ts
+
+Group 1 [PARALLEL]: Row 1 (settings.ts) + Row 2 (format.ts) + Row 4 (users.test.ts)
+                     → 3 files, no shared surface → 3 heal workers parallel
+Group 2 [SEQUENTIAL]: Row 3 (rbac.ts)
+                       → shares interface with Row 1 (middleware) → after Group 1
+```
+
+Each heal worker receives a prompt with 5 fields:
+- **FAILURE** — ledger row verbatim (wave, task, symptom, attempted)
+- **ROOT CAUSE** — Brook's triage result: where the bug is, why it happened
+- **FIX** — what to change, which file, which function
+- **MUST DO** — Prove-It: write regression test, watch it fail, implement fix, watch it pass, commit
+- **MUST NOT** — files outside scope, drive-by refactor, delete/weaken tests
+
+### Validation workers (verify)
+
+After all heal workers complete, dispatch validation workers in parallel:
+- **reviewer-worker** — adversarial diff review from fresh context (per `mugiwara-review`)
+- **security-worker** — security pass over fixes (per `mugiwara-security`)
+- **re-run-check worker** — independently re-runs failed checks, returns raw evidence
+
+Flow: Brook triage + grouping → dispatch heal workers parallel → aggregate results → dispatch validation workers → update ledger → back to Wave 4.
+
+Workers are NOT crew members — disposable subagents, one narrow job per worker. Crew runs inline in main thread.
 
 ## Output
 

package/content/skills/mugiwara-healing/references/failure-taxonomy.md

@@ -0,0 +1,23 @@
+# Failure Taxonomy
+
+Classification for healing triage. Matches Brook's triage matrix.
+
+## Categories
+
+| Category | Signal | Action |
+|----------|--------|--------|
+| **test-fail** | Test, lint, or build command fails with specific error | Reproduce → localize → reduce → fix root cause + guard test |
+| **missing-impl** | Acceptance criterion unverifiable, artifact absent | Check if task was skipped; if not, implement the missing piece |
+| **parallel-conflict** | Two tasks modified the same file concurrently | Serialize, merge the changes, re-verify |
+| **env** | Failure reproduced only in specific environment | Mark env, do not patch code. Note for rerun. Must be proven on clean checkout |
+| **regression** | Previously passing check now fails | git bisect to find breaking commit, fix root cause |
+| **type-error** | TypeScript/mypy/pyright fails on changed code | Fix at root cause, grep all callers, re-run typecheck |
+| **flaky** | Intermittent failure, random seed | Identify race condition or timing dependency. Retry N times. Mark flaky only after proving non-determinism |
+
+## Proven-env rule
+
+A failure classified `env` must be reproducible on a clean checkout in the same environment OR must fail only on one OS/CI. "Probably env" is not proof — it stays as code failure until proven otherwise.
+
+## Escalation
+
+After 3 heal cycles on the same failure → stop. Escalate to human with full repro, attempted fixes, and root-cause hypothesis.

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

@@ -1,6 +1,6 @@
 ---
 name: mugiwara-lessons
-description: Use at mission end or before starting work in a repo the crew has worked in before - read and write the accumulated lessons ledger so each mission stands on the previous ones.
+description: Use at mission start/end — cross-mission lessons ledger. Read past lessons at triage, capture new ones at closure. Append-only.
 ---
 
 # Lessons (Mission Memory)

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

@@ -1,6 +1,6 @@
 ---
 name: mugiwara-orchestration
-description: Use to triage a new mission at the gateway, classify requests 5 ways, coordinate wave transitions, answer inter-agent escalations, split work, and close a mission. Captain behavior - triage, check-ins, decisions, closure. Never implements code.
+description: Use to triage a new mission — 5-way classify, coordinate waves, lane sizing, check-ins, closure. Captain; never implements code.
 ---
 
 # Orchestration (Luffy)
@@ -18,7 +18,7 @@ The plan doc (`.mugiwara/plans/YYYY-MM-DD-<mission>.md`) is Nami's clean executi
 
 ## Mode read (Wave 0)
 
-Read the runtime mode via `mugiwara-mode` at Wave 0: `.mugiwara/config` (project) then `~/.mugiwara/config` (global); a key missing from both = `guided`. Record the active mode in the decision log. Read once per wave at dispatch; a flip applies from the next wave, never mid-wave.
+Read the runtime mode via mode config at Wave 0: `.mugiwara/config` (project) then `~/.mugiwara/config` (global); a key missing from both = `guided`. Record the active mode in the decision log. Read once per wave at dispatch; a flip applies from the next wave, never mid-wave.
 
 Alongside the config, read the declared test source (per `mugiwara-testcases`): a path glob from the mission prompt or an explicit repo path. Record it in the decision log like the mode config. No source declared → no user tests for the mission.
 
@@ -57,7 +57,7 @@ After every wave AND at the end of each execution batch, verify:
 3. Heal-loop counters within bounds (max 3 cycles).
 4. Blocker ledger `.mugiwara/issues/YYYY-MM-DD-<mission>-blockers.md` reviewed; every row has an owner or a path forward.
 
-By mode (per `mugiwara-mode`): `guided` checks in with the user as today; `semi`/`auto` write the check-in verdicts to the decision log without pausing the pipeline.
+By mode (per mode config): `guided` checks in with the user as today; `semi`/`auto` write the check-in verdicts to the decision log without pausing the pipeline.
 
 On drift: stop, diagnose with Chopper's ledger, decide continue / retry / escalate to human.
 
@@ -79,7 +79,7 @@ Recognize the in-session phrase `mugiwara mode <guided|semi|auto>`: write the pr
 
 ## Closure (Wave 9)
 
-Gate — every task's acceptance criteria verified, every gate passed, findings resolved or explicitly deferred with an owner, blocker ledger reviewed, unused intermediate markdown files deleted. Write the closure report to `.mugiwara/results/YYYY-MM-DD-<mission>-closure.md`: mission summary, per-wave outcomes, deferred items, lessons learned. The plan doc stays untouched.
+Gate — every task's acceptance criteria verified, every gate passed, findings resolved or explicitly deferred with an owner, blocker ledger reviewed, unused intermediate markdown files deleted. Run `scripts/savepoint.sh <mission>` to write final state, then `scripts/mission-report.sh <mission>` to generate the mission report at `.mugiwara/reports/<mission>.md`. Write the closure summary to `.mugiwara/results/YYYY-MM-DD-<mission>-closure.md`. The plan doc stays untouched.
 
 ### Detailed closure summary (mandatory, inline)
 
@@ -93,7 +93,7 @@ Present a detailed summary to the user — never a one-liner:
 - Deferred items + owner.
 - Next steps — PR material pointer, anything the user must do.
 
-### Terminal step (every mode, per `mugiwara-mode`)
+### Terminal step (every mode, per mode config)
 
 Save-point commit → push the mission branch (per the config `branch` key, default `feature/{type}-{issue}-{slug}`) with plain `git push -u origin <branch>` → write `.mugiwara/results/YYYY-MM-DD-<mission>-pr-verdict.md` per the `mugiwara-pr` format (includes a ready PR summary block) → hand the branch + verdict file to the user, who opens the PR. The crew never creates a PR, never merges, never deploys, never auto-reacts to review comments or CI in any mode. On push failure (no auth / no remote), fall back to the local closure report and log the reason.
 

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

@@ -1,6 +1,6 @@
 ---
 name: mugiwara-planning
-description: Use when turning an approved idea or spec into an execution plan. Classifies mission size, interviews first, scans full context, writes scaled Quick/Standard/Full plans with the unified task template, parallel-proof waves, per-task acceptance, and risk/rollback.
+description: Use for turning an approved spec into an implementation plan — interview-first, full context scan, scaled Quick/Standard/Full plans, parallel-proof waves.
 ---
 
 # Planning (Nami)
@@ -24,7 +24,7 @@ Classify the mission by size first — after Luffy's route — then write the pl
 
 Batch ALL blocking ambiguities into ONE question round before writing. If a major decision appears mid-plan, stop and ask then — never assume silently. Unanswered question goes back to Luffy, never forward to Zoro. Read the mission spec at `.mugiwara/spec/YYYY-MM-DD-<mission>.md` (the Wave 0/1 bridge); if none exists, return to Luffy for the spec bridge or brainstorm — never plan from an empty spec, that is fiction.
 
-## Mode (per `mugiwara-mode`)
+## Mode (per mode config)
 
 - `guided`: batch ONE question round, wait for answers, then present the plan for an explicit user GO — current behavior.
 - `semi`: self-answer non-blocking ambiguities + log them in the decision log; still present the plan for user GO.

package/content/skills/mugiwara-planning/references/anti-patterns.md

@@ -0,0 +1,17 @@
+# Planning Anti-Patterns
+
+Patterns that fail the quality bar. Every one means: fix the plan before handoff.
+
+| Anti-pattern | Why it fails | Fix |
+|-------------|-------------|-----|
+| "TBD" in a step | Leaves executor guessing | Fill in the exact command or file path |
+| "add appropriate error handling" | Vague, uncheckable | Specify: "wrap in try/catch, log with context, return 500" |
+| "similar to Task N" | Assumes executor has context | Write the full task out |
+| No file paths | Executor invents paths | Name exact files: create/modify `src/auth/login.ts` |
+| "works correctly" acceptance | Unverifiable | Command: `npm test -- auth/login.test.ts` |
+| `[PARALLEL]` without proof | Race conditions | State disjoint files + no shared interface in wave header |
+| Missing `depends-on` edge | Execution order wrong | `depends-on: Task M (file: src/types.ts)` |
+| No Break point on 8+ file task | Unreviewable commit | Split into 2 tasks at natural seam |
+| Gold-plating | Speculative features | Cut to minimum that satisfies acceptance |
+| No rollback on high-risk task | Can't undo if it fails | Add: "revert commit X, re-deploy" |
+| "Executor will figure it out" | Fiction — wave stalls or ships wrong | Write the plan so a zero-context engineer can execute |

package/content/skills/mugiwara-planning/references/plan-template.md

@@ -0,0 +1,46 @@
+# Plan Template
+
+Scaled plan skeleton. Nami picks Quick/Standard/Full based on mission size.
+
+## Quick (1 task, ≤2 files)
+
+```markdown
+# <mission> — <goal>
+
+## Key decisions
+<why this approach>
+
+## Waves
+
+| Wave | Focus | Tasks | Gate |
+|------|-------|-------|------|
+| 3 | <what> | T1 | <command-verifiable exit check> |
+
+## Task index
+
+| # | Task | Files | Size | Depends-on | Acceptance |
+|---|------|-------|------|------------|------------|
+| T1 | <title> | <paths> | S | — | <one-line check> |
+
+## Detail: T1 — <title>
+- Files: <exact paths>
+- Steps: [ ] <test → impl → verify>
+- Acceptance: <command>
+- Risk: none
+```
+
+## Standard (1 wave, 2-8 tasks)
+
+Add: Architecture overview, Context scan, Implementation graph, Acceptance per task.
+
+## Full (multi-wave, parallel, risk)
+
+Add all of Standard + Key decisions, Project structure, Risk & rollback, Definition of Done.
+
+## Anti-patterns to avoid
+
+- "TBD" or "add appropriate error handling" in a step.
+- No file paths, or Acceptance like "works correctly" (uncheckable).
+- `[PARALLEL]` without file- AND interface-disjoint proof.
+- High-risk task with no rollback plan.
+- Vague plan expecting the executor to figure it out.

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

@@ -1,6 +1,6 @@
 ---
 name: mugiwara-pr
-description: Use at closure to push the mission branch and prepare the PR material - one provider-agnostic verdict file with a ready-to-paste PR summary block. Plain git push, no gh CLI, no PR creation, no auto-reaction to review comments or CI in any mode.
+description: Use at closure to push branch + prepare PR material — plain git push, verdict file with ready PR summary. Never creates PR, merges, or deploys.
 ---
 
 # PR Handoff (CI/CD Loop)

package/content/skills/{mugiwara-test-driven-development → mugiwara-proof-order}/SKILL.md

@@ -1,6 +1,6 @@
 ---
-name: mugiwara-test-driven-development
-description: Use when writing code during execution - RED-GREEN-REFACTOR discipline, proof-of-when over proof-of-exists, test pyramid shape, one test = one behavior, assert real behavior over mocks, refactor while green. Referenced by zoro-execution; complements mugiwara-testcases (user AC intake) - this is the executor's TDD contract.
+name: mugiwara-proof-order
+description: Use when writing code — TDD, RED-GREEN-REFACTOR, test-driven. Proof value from WHEN the test runs, not that it exists. One test = one behavior.
 ---
 
 # Test-Driven Development

package/content/skills/mugiwara-proof-order/references/proof-order-examples.md

@@ -0,0 +1,62 @@
+# Proof Order Examples
+
+The test's proof value comes from WHEN it runs, not that it exists.
+
+## Why order matters
+
+```
+❌ Write implementation → Write test → Test passes immediately
+   The test never demonstrated it could catch the bug.
+   You cannot prove the test is testing the right thing.
+
+✅ Write test (red) → Watch it fail → Write implementation → Test passes (green)
+   The red phase proves the test catches the absence of the feature.
+   The green phase proves the feature satisfies the test.
+```
+
+## Example: password validation
+
+```ts
+// RED — test first, watch it fail
+describe('validatePassword', () => {
+  it('rejects passwords shorter than 8 characters', () => {
+    expect(validatePassword('short')).toBe(false);
+  });
+});
+
+// FAIL: validatePassword is not defined
+
+// GREEN — minimal impl
+function validatePassword(pw: string): boolean {
+  return pw.length >= 8;
+}
+
+// REFACTOR — while green
+function validatePassword(pw: string): boolean {
+  if (pw.length < 8) return false;
+  if (!/[A-Z]/.test(pw)) return false;
+  if (!/[0-9]/.test(pw)) return false;
+  return true;
+}
+```
+
+## Anti-pattern: test after implementation
+
+```ts
+// Code already written, then test added later:
+function formatCurrency(amount: number): string {
+  return `$${amount.toFixed(2)}`;
+}
+
+// Test passes immediately — proves nothing:
+it('formats currency', () => {
+  expect(formatCurrency(10)).toBe('$10.00'); // green on first run
+});
+```
+
+The fix: comment out the implementation, watch the test fail, then uncomment.
+If the test still passes with implementation removed, the test is wrong.
+
+## Rule
+
+A test that passes on first run has proven nothing. Discard the implementation and redo test-first, or comment it out and prove the test actually fails before restoring.

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

@@ -1,6 +1,6 @@
 ---
 name: mugiwara-quality
-description: Use after checkpoint passes to run code quality checks - formatter, linter, unit tests, and with recorded user consent integration tests. Detects the project's real tooling first, never weakens configs to pass.
+description: Use after checkpoint passes — formatter, linter, eslint, prettier, lint, format, unit tests, test suite. Discovers project tooling, never weakens configs.
 ---
 
 # Quality (Sanji)
@@ -41,9 +41,9 @@ Optional, never default-on. Trigger ONLY when BOTH hold:
 - Repo has e2e setup — any of `playwright.config.*`, `cypress.config.*`, `e2e/` dir, `test:e2e` npm script.
 - Changed/staged files match e2e patterns — `e2e/**`, `*.e2e.*`, `specs/**`.
 
-When triggered, consent by mode (per `mugiwara-mode` invariant): `guided`/`semi` ask first — run now / skip / run manually later; `auto` runs only provably-isolated e2e (in-memory / local / tooling-proven isolation). Otherwise skip-and-log: record the skip reason (no setup, no matching files, no consent) in the report. The e2e gate never blocks silently and never blocks a pass — a skip is logged, not a failure.
+When triggered, consent by mode (per mode config invariant): `guided`/`semi` ask first — run now / skip / run manually later; `auto` runs only provably-isolated e2e (in-memory / local / tooling-proven isolation). Otherwise skip-and-log: record the skip reason (no setup, no matching files, no consent) in the report. The e2e gate never blocks silently and never blocks a pass — a skip is logged, not a failure.
 
-## Mode + consent (per `mugiwara-mode`)
+## Mode + consent (per mode config)
 
 Consent is an invariant, not a mode knob. State-mutating tests against NON-isolated / shared state (real DB writes, network, browsers) ALWAYS require explicit user consent in ALL modes. Provably-isolated mutation — in-memory / temp / testcontainer-backed DBs, tooling-proven isolation — is explicitly auto-safe and needs no consent. `auto` runs only provably-isolated tests automatically (unit-level, or tooling-proven isolation such as in-memory / local DB). `guided`/`semi`: integration tests keep the existing ask-first rule — run automatically now / skip / run manually later. Record every consent answer in the report.