@ionivetech/mugiwara 0.4.0 → 0.5.1

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

@@ -1,59 +0,0 @@
----
-name: mugiwara-observability
-description: Use when instrumenting, tracing, or debugging how the mugiwara crew ran a mission - structured logs, OTel-compatible trace spans per wave/agent/tool, session correlation, and reading the traces to find where time and errors went.
----
-
-# Observability (Trace the Crew)
-
-## Skip when
-
-- Lane 0 direct work: no waves, no dispatches, nothing to trace.
-- User explicitly declined tracing for this mission.
-
-Make every mission replayable: one trace file, one line per dispatch, so you can see who ran what, how long, and where it failed.
-
-## Trace log
-
-Per mission, maintain `.mugiwara/results/YYYY-MM-DD-<mission>-trace.md` (fall back to the repo's log convention if `.mugiwara/` is absent). Append one entry per wave and per agent dispatch:
-
-- `event`: wave | agent | tool called | start/end time | duration ms | outcome (pass/fail/blocked) | evidence pointer | error excerpt.
-
-## Structured log lines
-
-Each event is one parseable line, ISO timestamps, no PII:
-
-```
-2026-08-10T09:14:02Z [wave:3][agent:zoro][tool:subagent][ms:1240][ok] task-2.1 helper theme
-2026-08-10T09:16:40Z [wave:3][agent:brook][tool:test][ms:9800][fail] e2e auth regressed — see .mugiwara/issues/2026-08-10-mission-blockers.md:7
-```
-
-Always include outcome; an event without an outcome is noise, not a trace.
-
-## OTel-aware enrichment
-
-If the host agent supports OTel GenAI spans, map each entry: `gen_ai.agent.*` for dispatches, `gen_ai.tool.*` for tool calls, span duration = entry duration; propagate trace context (`traceparent`) via MCP `_meta` when the tool is an MCP server. Recommend Langfuse or LangSmith as the viewer for spans/agent graphs. The FILE trace stays the source of truth — OTel is optional enrichment, never a replacement.
-
-## Session correlation
-
-Every entry carries the mission id `YYYY-MM-DD-<mission>` (same name as the plan doc). The id threads through trace, blockers ledger, and results so a full run can be replayed even after context compaction — grep the id across `.mugiwara/` to reconstruct the whole mission.
-
-## Reading traces to debug
-
-- Time: sort spans by duration — the longest spans are the wave/agent/tool to fix or parallelize.
-- Errors: cluster `fail`/`blocked` entries by agent/task — repeated failure at one spot is a plan or skill bug, not a one-off.
-- Utilization: which agents ran vs. never dispatched (over/under-use), heal-loop cost = sum of `[heal]` wave spans.
-- Fix the plan/skill, not the symptom: the trace tells you where, the plan tells you why.
-
-## End-of-mission summary
-
-Close the trace file with a mini report: total duration, waves run, agents used, failures, heal cycles, longest span. This is the closure evidence for the ship gate.
-
-## Red flags
-
-- Events without timestamps, duration, or outcome.
-- Entries missing the mission id.
-- PII in log lines.
-- Trace file absent at closure while waves ran.
-- Heal cycles with no trace of which failure they retried.
-
-All mean: the run is not reconstructable. Stop and record before moving on.

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

@@ -1,65 +0,0 @@
----
-name: mugiwara-writing-skills
-description: Use when authoring a new mugiwara skill or revising an existing one. Enforces the skill anatomy (name/description 20-500 chars, when-to-use, process, rationalizations, red flags, verification), the 120-line body ceiling, and progressive disclosure of detail into a references/ file. Meta-skill: governs the other skills.
----
-
-# Writing Mugiwara Skills
-
-## Skip when
-
-- Not authoring or revising a mugiwara skill — plain application code change.
-- Skill change is a one-line description fix with no anatomy impact.
-
-A skill is a process workflow the agent runs on cue, not a reference guide. If it reads like a wiki page, it fails. The description decides when the skill loads; the body decides what happens next. Both must justify their size.
-
-## Skill anatomy
-
-Every skill is a single `SKILL.md` at `content/skills/<name>/`, plus an optional `references/` folder for pulled-out detail. The name is the directory name; the validator checks that exact match.
-
-| Part | Requirement |
-|------|-------------|
-| name | equals the directory name, `mugiwara-<domain>` |
-| description | one "Use when..." sentence, 20-500 chars, loads the right skill and rejects the wrong ones |
-| body | `# title` + sections below, 120 lines max |
-| references/ | overflow detail, linked from the body |
-
-## When to use
-
-Use this skill the moment you start authoring a new skill file or restructuring an existing one. Skip it only for edits so small they cannot touch anatomy, limits, or wording.
-
-## Process
-
-1. **Confirm the niche.** Grep `content/skills/` for overlap; a new skill must not duplicate an existing one. Name it `mugiwara-<domain>`.
-2. **Write the description first.** One "Use when..." sentence naming the trigger, the behavior, and the boundary of what the skill is not for. Target 60-120 chars; the 500-char cap is a ceiling, not a goal.
-3. **Draft the body as a workflow.** Concrete numbered steps the agent executes, in order, with decisions and branches embedded. Name the skills it reads or dispatches. Use tables for excusable patterns and quick comparisons.
-4. **Cut to the ceiling.** Body must end at 120 lines or fewer. Section-by-section trim: merge subsections, kill throat-clearing, convert prose to tables. `ponytail` and `caveman` instincts apply — the body is command output, not a report.
-5. **Disclose progressively.** If a section exceeds roughly 15-20 lines, move it to `references/<topic>.md`, drop a one-line pointer in the body, and keep the pointer actionable (what to read and why).
-6. **Check the anatomy list.** Each required section present, in order: title, When to use, Process, Rationalizations, Red flags, Verification.
-7. **Validate.** Run `bun scripts/validate-content.ts --check content/skills/<name>/SKILL.md` and leave it exiting 0.
-
-## Rationalizations
-
-| Excuse | Rebuttal |
-|--------|----------|
-| "It's a guide, not a checklist" | A skill the agent cannot execute is decoration. Rewrite every paragraph as a step or a criterion. |
-| "The detail is essential" | Then move it to `references/` and keep the body a decision tree, not a dump. |
-| "More lines mean more coverage" | 120 lines enforce focus. Cover the decision, not the encyclopedia. |
-| "Long description catches more triggers" | A description that matches everything loads on nothing specific and trains the agent to ignore the skill. |
-| "Patterns are the same everywhere, I'll mirror another skill's text" | Wording must be original. Mirror the shape, never the sentences. |
-| "It's fine for now, I'll validate later" | Validation is the last step of the write, not a follow-up task. |
-
-## Red flags
-
-- Body over 120 lines or a description outside 20-500 chars.
-- No "Use when..." trigger sentence, or a description that names no boundary.
-- A section that reads as a lecture instead of steps the agent can run.
-- Required sections missing or out of order.
-- Text copied from another skill, superpowers, or agent-skills.
-- A `references/` file that is unreferenced, or a body so crammed it needed none.
-- An unvalidated file reported as done.
-
-Any of these: revise the skill, re-run validation, and confirm both before reporting.
-
-## Verification
-
-Evidence of a complete skill: the file passes `--check` with exit 0; `wc -l` on the body is at or under 120; the description triggers only its intended cases; every required section is present and original; and any overflow sits in a linked `references/` file.

package/evals/cases/negative-secrets-typo.json

@@ -1,12 +0,0 @@
-{
-  "name": "negative-secrets-typo",
-  "skill": "mugiwara-git",
-  "type": "negative",
-  "task": "Fix a typo in a comment in src/index.ts (one word). This is a trivial change.",
-  "rubric": [
-    "does NOT rank mugiwara-security first (no trust boundary crossed)",
-    "does NOT rank mugiwara-systematic-debugging first (cause known)",
-    "treats it as lane 0 direct work"
-  ],
-  "expect_lane": "direct"
-}

package/evals/cases/negative-security-docs-change.json

@@ -1,12 +0,0 @@
-{
-  "name": "negative-security-docs-change",
-  "skill": "mugiwara-git",
-  "type": "negative",
-  "task": "Update the README to fix a broken link. No code, no config, no data flow changes.",
-  "rubric": [
-    "does NOT rank mugiwara-security first (docs-only, no trust boundary)",
-    "does NOT rank mugiwara-test-driven-development first (no production code)",
-    "does NOT rank mugiwara-gates first (no code changed)"
-  ],
-  "expect_lane": "direct"
-}

package/evals/cases/routing-typo.json

@@ -1,13 +0,0 @@
-{
-  "name": "routing-typo",
-  "skill": "mugiwara-git",
-  "task": "Fix a typo in a comment in src/index.ts (one word).",
-  "rubric": [
-    "treats it as lane 0 direct work",
-    "makes the one-line change without brainstorm or plan",
-    "does not invoke the crew pipeline",
-    "commits with a conventional commit message"
-  ],
-  "lane": "0",
-  "expect_lane": "direct"
-}