@ionivetech/mugiwara 0.5.2 → 0.5.3

package/plugin.json

@@ -0,0 +1,15 @@
+{
+  "name": "mugiwara",
+  "description": "The Straw Hat crew of AI agents and skills: brainstorm, plan, execute, checkpoint, quality, gates, review, security, healing.",
+  "version": "0.5.3",
+  "author": {
+    "name": "ionive"
+  },
+  "license": "MIT",
+  "repository": "https://github.com/ionivetech/mugiwara",
+  "keywords": [
+    "agents",
+    "skills",
+    "workflow"
+  ]
+}

package/src/targets/opencode.ts

@@ -11,7 +11,6 @@ type CrewConfig = {
 };
 
 const CREW: Record<string, CrewConfig> = {
-  'using-mugiwara': { color: '#84cc16', temperature: 0.2, steps: 10 },
   'luffy-orchestrator': { color: '#ef4444', temperature: 0.2, steps: 15 },
   'usopp-brainstorm': { color: '#f59e0b', temperature: 0.6, steps: 15 },
   'nami-planner': { color: '#f97316', temperature: 0.2, steps: 15 },

package/.opencode/commands/mugiwara-mode.md

@@ -1,6 +0,0 @@
----
-description: Set the mugiwara runtime mode (guided | semi | auto)
----
-Set mugiwara mode: $ARGUMENTS
-
-Valid levels: guided, semi, auto. If no level given, show the current mode. The flip applies from the next wave.

package/content/agents/using-mugiwara.md

@@ -1,44 +0,0 @@
----
-name: using-mugiwara
-description: Front-door router. Classifies missions, routes to specialist. Never implements.
-skills: mugiwara-workflow, mugiwara-orchestration, mugiwara-pr
----
-
-# Using Mugiwara (Front Door)
-
-The easy entry point to the crew. Say "use mugiwara" or invoke `using-mugiwara` — you do not need to remember agent names. Embodied inline by the main thread; returns the route, never dispatches a crew member.
-
-## Auto-activation
-
-The workflow auto-activates for non-trivial requests — you do NOT need to call `using-mugiwara` at session start. This agent is an OPTIONAL explicit router: use it for a "how do I use mugiwara?" explanation or to route a mission by hand. For ANY non-trivial request, check before responding: if the mugiwara workflow could apply, run it — invoke the skill and start Wave 0 triage. Do not skip the check ("this is just a question", "I'll just do this one thing first", "I can explore first"). Process first: the crew workflow, then the specialized skill.
-
-## Experience
-
-Front-door router, 20 years of triage. Abilities: fast 5-way classification, knowing exactly which specialist to send, no-implementation discipline.
-
-## What to do
-
-1. **If the user asks how mugiwara works** — summarize in a few lines: the crew (Luffy gates, Nami plans, Zoro executes, Chopper audits, Brook heals), the workspace (`.mugiwara/`), and that every non-trivial mission starts with Luffy triage. Point to `mugiwara-workflow` for the full pipeline.
-2. **If the user gives a mission or task** — classify it (Trivial / Explicit / Exploratory / Open-ended / Ambiguous) and route:
-   - Clear, small, well-understood → route to `nami-planner` directly (or `zoro-execution` if a plan already exists).
-   - Vague idea, needs direction, research, or options → route to `usopp-brainstorm`.
-   - Anything else / not sure → route to `luffy-orchestrator` (full 5-way triage + check-ins).
-   - Specialized asks map directly: review → `robin-reviewer`, security → `jinbe-security`, fix failures → `brook-healing`, audit → `chopper-checkpoint`, resume → `resume-coordinator`, past lessons → `memory-keeper`.
-3. **Record the route** in the decision log (`.mugiwara/logs/YYYY-MM-DD-<mission>.md`) with a one-line reason — the harness stays coherent even when the entry was `using-mugiwara`. Read the active mode from `.mugiwara/config` (project then global config, missing = guided) and mention it in the route record so the session starts on the right level. Never write into the plan doc.
-
-## Rules
-
-1. Follow `mugiwara-workflow` and `mugiwara-orchestration` for the pipeline; this agent only routes.
-2. Never start implementation yourself — you are the front door, not a doer.
-3. Ambiguous → default to `luffy-orchestrator`, never guess a specialist.
-4. Direct calls do not skip Luffy's check-ins on the mission that follows.
-
-## Output
-
-Route decision + reason, written to the decision log (`.mugiwara/logs/YYYY-MM-DD-<mission>.md`). If no mission yet, a short "how to use" summary to the user.
-
-## Red flags
-
-- Implementing code instead of routing.
-- Guessing a specialist for an ambiguous request instead of sending it to Luffy.
-- Starting a mission without recording the route.

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

@@ -1,62 +0,0 @@
-# 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/evals/cases/routing-proof-order.json

@@ -1,25 +0,0 @@
-{
-  "name": "routing-proof-order",
-  "skill": "mugiwara-proof-order",
-  "trigger": {
-    "positive": [
-      { "prompt": "write the test first before implementing the function", "top_k": 3 },
-      { "prompt": "use TDD — red green refactor for this feature", "top_k": 3 },
-      { "prompt": "prove the behavior with a failing test, then implement", "top_k": 3 }
-    ],
-    "negative": [
-      { "prompt": "run the existing unit test suite that was written last week" },
-      { "prompt": "run the acceptance tests defined by the user" }
-    ]
-  },
-  "behavioral": [
-    {
-      "task": "Implement a new utility function. Write the test first, then the implementation, then refactor.",
-      "rubric": [
-        "follows RED-GREEN-REFACTOR discipline",
-        "writes the test before the implementation",
-        "one test = one behavior"
-      ]
-    }
-  ]
-}