@mu-crew/mu 3.13.2 → 4.0.0

package/skills/mu/recipes/drift-audit.md

@@ -1,75 +0,0 @@
-# Drift audit
-
-Use during a long run to catch a crew drifting from what you decided:
-an instruction that never reached its worker, a batch run on stale
-inputs, work continuing on a closed task. One read-only
-[delegate call](tasks-or-calls.md#delegate-call); it edits nothing.
-
-## When
-
-- every few hours of a long run;
-- after each batch report of a chained task (sweep, campaign, soak);
-- after a context compaction or a resume;
-- before you declare a stop rule met.
-
-## Run
-
-Issue one delegate call with `record: { task: "<ws>/<umbrella>" }` and
-this brief, with `<ws>` filled in:
-
-```text
-Read-only drift audit of mu workstream <ws>. Change nothing. Sources:
-mu state -w <ws>; mu task list -w <ws> --json; mu task notes <id> -w <ws>;
-mu sql (ops, tasks, task_notes, agents); git log in the repo and in each
-owner's workspace. Never judge by a capped mu log -n window: the claim
-or close you compare against is often older than it.
-1. Unsent notes: notes on IN_PROGRESS tasks, by someone other than the
-   owner, after the owner's last task.claim or agent.send op:
-   mu sql "select t.local_id task, a.name owner, n.created_at, substr(n.content,1,80) note from tasks t join workstreams w on w.id=t.workstream_id join agents a on a.id=t.owner_id join task_notes n on n.task_id=t.id where w.name='<ws>' and t.status='IN_PROGRESS' and coalesce(n.author,'')<>a.name and n.created_at > max(coalesce((select max(o.created_at) from ops o where o.intent='task.claim' and o.key='<ws>/'||t.local_id),''), coalesce((select max(o.created_at) from ops o where o.intent='agent.send' and o.key='<ws>' and o.payload like 'agent send '||a.name||' (%'),'')) order by n.created_at"
-   Quote each task's last claim (seq, time). For each instruction it
-   lists: did the owner act on it (later commits, notes, pane)? Also read
-   mu sql "select seq, created_at, payload from ops where intent='agent.send' and key='<ws>'"
-   and flag mode=plain or mode=steer with state=busy since=<t> long
-   before the send: it queued behind a long turn and may not have landed.
-2. Stale pins: for each build/binary sha or oracle commit named in an
-   IN_PROGRESS note, and each merged fix its task's findings depend on:
-   git merge-base --is-ancestor <fix> <pinned>. Exit 1 = pin is stale.
-3. Closed-task notes: notes added after the task's last task.close op,
-   minus those the close verb writes in its own transaction
-   (`--evidence`, `--why`: timestamp within 50ms of the close op); any
-   other note counts, whatever its prefix. Report each of the top 5 by
-   count as its own finding with its count,
-   even when the notes look routine. A late note that reports the
-   closed bug again usually ran on a build without the closing fix:
-   check its sha with git merge-base --is-ancestor <fix> <sha>.
-   mu sql "select t.local_id name, count(*) late from tasks t join workstreams w on w.id=t.workstream_id join task_notes n on n.task_id=t.id join (select key, max(created_at) at from ops where intent='task.close' and entity='task' group by key) c on c.key='<ws>/'||t.local_id where w.name='<ws>' and t.status='CLOSED' and (julianday(n.created_at)-julianday(c.at))*86400 > 0.05 group by t.local_id order by late desc"
-4. Thin decisions: an ACCEPT/REJECTED/CLOSE/SUPERSEDED note under 40
-   chars; a refuter tally with no REFUTER or VERDICT note; a review the
-   orchestrator closed with no FILES/COMMANDS note and no commit.
-5. Silent tasks: IN_PROGRESS with no note or commit for longer than
-   the cadence its notes state (default 2h).
-6. Missing work: a task or finding a note or log line says will be
-   filed that does not exist.
-7. Unrefuted briefs: IN_PROGRESS tasks with no note line starting
-   REFUTER , VERDICT: or REFUTE-EXEMPT:.
-End with exactly this, one EVIDENCE line per finding (none when clean):
-VERDICT: <ws> DRIFT-AUDIT CLEAN | FINDINGS <n>
-EVIDENCE: FINDING <high|med|low> <file:line|task> <what> (check <1-7>)
-```
-
-`record` keeps only the VERDICT line and the `EVIDENCE:` lines after
-it, so each finding must be an `EVIDENCE: FINDING` line. The note
-lands headed `REFUTER`, which the refute nudge and decision warnings
-read as a recorded verdict; on an umbrella that is harmless.
-
-## Act
-
-Each finding becomes one of:
-
-- an `OPEN/triage` task blocking the umbrella ([findings § Record](findings.md#record));
-- a send to the worker it names, per
-  [orchestrator-loop § Sending](orchestrator-loop.md#sending)
-  (`--interrupt` when its current work is wasted, as with a stale pin).
-
-Done when the verdict is recorded on the umbrella and every finding
-is a task or a delivered send.

package/skills/mu/recipes/fan-out.md

@@ -1,42 +0,0 @@
-# Fan-out
-
-Use when the same treatment applies to many units: files, call sites,
-failing tests, findings, modules. One context holding 50 units drops
-some and calls the job done; one task per unit cannot.
-
-## Steps
-
-1. **Enumerate first.** A scout (a [delegate call](tasks-or-calls.md#delegate-call)) lists the units and
-   writes them to the umbrella's note, one per line. The list is done
-   when it matches a command the scout ran (`rg -l`, a test listing),
-   not when it looks complete. Record the command and the count. The
-   scout runs cheap; the units run mid, or strong when each is a
-   judgement call ([models](models.md#roles)).
-2. **One task per unit**, blocked into an umbrella:
-
-   ```bash
-   mu task add sweep -w <ws> -t "Sweep: <goal>" -i 60 -e 1 --note 'UNITS: 37 (rg -l ... | wc -l)'
-   mu task add sweep_auth_ts -w <ws> -t "Sweep src/auth.ts" -i 50 -e 0.2
-   mu task block sweep -w <ws> --by sweep_auth_ts
-   ```
-
-   Put the shared [brief](brief.md) and acceptance criteria on the
-   umbrella; each unit task's note holds only what differs. A sweep that
-   only checks (no commits) makes each unit a delegate call instead
-   ([tasks-or-calls](tasks-or-calls.md)).
-3. **Cap concurrency** ([orchestrator-loop § Concurrency](orchestrator-loop.md#concurrency)).
-   One agent per ready unit, up to the ceiling. Tell workers to avoid
-   repo-wide commands so more can run.
-4. **Pipeline.** Dispatch, wait `--first`, merge
-   ([orchestrator-loop § Merging](orchestrator-loop.md#merging)), dispatch
-   the next unit to the freed worker with `--fresh`. With `codemode`, a
-   [driver](codemode-driver.md) can dispatch each batch. Units that touch the same files
-   are chained with `block` (see [waves](waves.md)).
-5. **Review per unit** when a wrong unit is costly: add a review task
-   per unit ([adversarial-review](adversarial-review.md)).
-6. **Synthesize** when the output is a report, not commits: one
-   delegate call reads the unit notes (not transcripts) and writes one
-   result into the umbrella's note.
-
-Done when `mu task close sweep --if-ready` closes the umbrella: every
-unit is closed, and the closed count matches the step 1 count.

package/skills/mu/recipes/hypothesis-panel.md

@@ -1,48 +0,0 @@
-# Hypothesis panel
-
-Use for root-cause work: a flaky test, an intermittent bug, a metric
-that moved. One agent that forms a theory then tests its own theory
-finds evidence for it. Separate agents, each given different evidence,
-form independent theories; separate agents then try to kill them.
-
-## Steps
-
-1. **Write the symptom** on the umbrella: what happens, how often, the
-   repro command, and what would count as fixed.
-2. **One reader per evidence source** (a [delegate call](tasks-or-calls.md#delegate-call), strong tier:
-   root cause is judgement, [models](models.md#roles)): logs, the
-   code path, recent commits, data, environment. Each sees only its
-   source, so the theories do not anchor on each other. Record each
-   theory as an `OPEN/triage` task blocking the umbrella, decided like
-   a finding ([findings § Triage](findings.md#triage)):
-
-   ```bash
-   mu task add -w <ws> --triage -t "h: <cause>" -i 60 -e 0.5 \
-     --note 'PREDICTS: <an observation true if this is the cause, false otherwise>'
-   ```
-
-3. **Test each hypothesis.** An experiment that changes code (force the
-   race, revert the commit) needs a workspace: `mu task accept` the
-   hypothesis and dispatch it as a task. One that only reads (feed the
-   data, grep the logs) is a delegate call with `record` on the
-   hypothesis ([tasks-or-calls § Delegate call](tasks-or-calls.md#delegate-call)).
-   A killed hypothesis closes `--as rejected --why "<the observation
-   that contradicts PREDICTS>"`; a survivor gets a `SURVIVED: <evidence>`
-   note. Prose reasons: [brief § Quoting](brief.md#quoting).
-4. **If one survives**, add a fix task for it, then a review task
-   ([adversarial-review](adversarial-review.md)). The fix is accepted
-   only if the step 1 repro stops reproducing.
-5. **If none survives**, start another round
-   ([loop-until-done](loop-until-done.md)): the new hypothesis tasks get
-   the killed hypotheses and their evidence as input.
-
-Done when the fix's review task is `CLOSED/done` (ACCEPT) and the
-repro from step 1 no longer
-reproduces at the rate step 1 recorded.
-
-## Traps
-
-- **Two survivors** usually means the experiments were too weak. Design
-  one experiment that separates them before you fix either.
-- **Flaky repros need counts** ([long-run](long-run.md) step 1). "Passed once" proves nothing for a 1 in
-  50 failure. Put the run count in step 1.

package/skills/mu/recipes/long-run.md

@@ -1,32 +0,0 @@
-# Long runs
-
-Use when a task or proof runs for hours, crosses context compaction,
-or may hit flakes.
-
-1. **Define done first.** Before dispatch, write the completion criterion
-   into the task note: the checks, how many runs must agree, the
-   allowed variance. A worker that finds the bar in the note stops at
-   the bar, not at the first green. For chained batches (sweeps,
-   campaigns, soaks) it also names the **inputs** each batch runs on
-   (build sha, oracle commit, config) and when to refresh them
-   ("rebuild from main before each batch"); each batch report states
-   the inputs it used, and the stop rule counts only batches on
-   current inputs.
-2. **Split into independent units** ([fan-out](fan-out.md)). Shard a long proof into tasks
-   that run in parallel, so one flake restarts only its unit. Each unit
-   carries its own criterion.
-3. **Keep state in the DB.** Progress lives in task notes, not in the
-   orchestrator's context. After a compaction, `mu state` and
-   `mu task notes <id>` are the whole picture. Append
-   `DEAD-END: <approach> — <why it failed>` to the umbrella so a resumed
-   orchestrator does not retry it.
-4. **Bound each tool call** to minutes: batches of ≤10 minutes,
-   `mu task wait --timeout` re-issued, no open-ended `sleep` loops.
-   A `--steer` lands only when the running tool returns.
-5. **Accept evidence, not close notes**
-   ([orchestrator-loop § Merging](orchestrator-loop.md#merging)), and
-   run a [drift-audit](drift-audit.md) after each batch report and
-   every few hours.
-
-Done when every unit is `CLOSED/done` and the criterion from step 1
-holds on the merged tree.

package/skills/mu/recipes/loop-until-done.md

@@ -1,45 +0,0 @@
-# Loop until done
-
-Use when the amount of work is unknown: fix type errors until clean,
-find flaky tests until none are new, search until nothing new turns up.
-A fixed number of passes stops too early or runs too long; a stop rule
-written down first does neither.
-
-## Steps
-
-1. **Write the stop rule** on the umbrella before the first round. It
-   names a command and a condition, plus a no-progress rule:
-
-   ```text
-   STOP: `npx tsc --noEmit` exits 0
-   NO-PROGRESS: two rounds in a row reduce the error count by zero
-   ```
-
-2. **Each round is a task** that blocks the umbrella and is blocked by
-   the previous round:
-   `round_1`, `round_2`, .... Add the next round only when the current
-   one closes; never pre-create rounds. Dispatch each per
-   [orchestrator-loop](orchestrator-loop.md); multi-hour loops follow
-   [long-run](long-run.md).
-3. **Each round ends with its measurement** in the note:
-   `MEASURE: 14 errors (was 31)`, or `NEW: 0 flaky tests`.
-4. **After each round, check the rule** yourself, from the measurement
-   command, not from the worker's note.
-   - Rule met: first one delegate call refutes the umbrella's criteria
-     on the merged tree (record on the umbrella). Then
-     `mu task close <umbrella> --if-ready --evidence "<stop
-     command + result>"` (each round blocks the umbrella).
-   - No progress: stop the loop and decide. Change the approach, split
-     the work, or park the umbrella with
-     `mu task park <umbrella> --why "<what is stuck>"` and tell the human.
-     Prose reasons: [brief § Quoting](brief.md#quoting).
-   - Otherwise: add the next round and dispatch it.
-
-Done when the stop rule holds on the merged tree, run by you.
-
-## Traps
-
-- **A round that only reports is not progress.** Each round must change
-  something (fix, new search slice) or produce a new measurement.
-- **Moving goalposts.** Edit the stop rule only with a note saying why;
-  the old rule stays in the history.

package/skills/mu/recipes/plan.md

@@ -1,67 +0,0 @@
-# Planning a DAG
-
-Use when you turn a spec or a clear set of requirements into tasks.
-The DAG is the plan: each task's note carries its full content, and
-`mu state` is the progress tracker. Write a markdown plan only when the
-human asks for a file.
-
-## Steps
-
-1. **Map files and gates.** List what gets created or changed and each
-   file's responsibility. For a new project, define repo `## Gates` first
-   ([test-health](test-health.md#gate-contract)); point plan notes there.
-   Existing gates remain until their replacement is approved.
-2. **Size the tasks.** A task is the smallest unit that carries its own
-   verification and is worth a review. Split only where a reviewer
-   could reject one task and accept its neighbour. Fold setup, config,
-   and docs into the task whose deliverable needs them.
-3. **Write the root task.** `task_0` holds the goal, the architecture
-   in two or three sentences, and the global constraints copied
-   verbatim from the spec. Every other task is blocked by it; close it
-   at once. It carries notes, not work.
-4. **Write each task's note** as a [brief](brief.md): its Shape, plus
-   INTERFACES and STEPS:
-
-   ```text
-   GOAL:       one sentence
-   DONE WHEN:  checkable, exhaustive criterion
-   FILES:      Create/Modify/Test with exact paths (line ranges if known)
-   INTERFACES: Consumes: <exact signatures from earlier tasks>
-               Produces: <exact names and types later tasks use>
-   STEPS:      one action each; code steps carry the code
-   VERIFY:     <exact command and expected result>
-   ```
-
-   The worker sees only its own task. INTERFACES is how it learns the
-   names its neighbours use.
-5. **No placeholders.** "TBD", "add error handling", "similar to
-   task 3", "write tests for the above": each is a missing decision the
-   worker will make alone. Write the actual content; tasks are read out
-   of order.
-6. **Add edges for dependencies only.** `mu task block A --by B` when A
-   consumes what B produces. Plan order is not a dependency: an extra
-   edge serialises tasks that could run in parallel. The exception:
-   tasks that edit the same files are chained ([waves](waves.md)).
-7. **Self-review before dispatch.** Map each spec requirement to its
-   task, grep the notes for placeholders, match INTERFACES names across
-   tasks, and read the graph back (`mu task tree task_0 -w <ws> --down`).
-   Then refute each brief that makes claims ([call](tasks-or-calls.md#delegate-call),
-   all in one turn, at your tier from another family: [models](models.md#checkers)): "What in this brief is false about the code,
-   ambiguous, or would make a correct worker fail review? Cite
-   file:line." Rewrite each REFUTED brief. Five of six briefs refuted in one run had
-   such a defect, e.g. a fallback test old extensions made unpassable.
-
-Done when every spec requirement maps to a task, no note holds a
-placeholder, every claim-making brief has a verdict, and `mu state`
-lists the tasks you meant to run in parallel as Ready together. Then dispatch per [orchestrator-loop](orchestrator-loop.md).
-
-## Notes
-
-- `impact` comes from what breaks without the task; `effort_days` from
-  its step count. Guess honestly rather than defaulting to 50 and 1.
-- Review gates follow [adversarial-review](adversarial-review.md): a
-  review task blocked by the work.
-- End each phase/milestone with a [test-health task](test-health.md#upkeep-loop);
-  connect real dependencies, not a barrier across independent workers.
-- When reality disagrees with the plan, append a note saying so. Do not
-  rewrite earlier notes.

package/skills/mu/recipes/refute.md

@@ -1,55 +0,0 @@
-# Find, refute, synthesize
-
-Use for audits, bug sweeps, and fact-checks: anything that produces
-findings. Finders over-report; a separate agent told to kill each
-finding filters what survives. Where findings live and how triage works
-is [findings](findings.md); this recipe is the search around it. Builds
-on [fan-out](fan-out.md).
-
-**Mode:** workstream by default (an audit feeds fixes). For a quick
-fact-check nobody will track, use delegate mode from
-[findings](findings.md) and skip the tasks.
-
-## Steps
-
-1. **Pin the scope** on an umbrella task: what is searched, and what
-   counts as a finding.
-2. **Split the search** into slices (security, data integrity, one
-   module each). One finder task per slice. Finders read; they do not
-   fix.
-3. **Finders record findings** as `OPEN/triage` tasks blocking the
-   umbrella, one per finding, severity first in the title, file:line and
-   evidence in the note ([findings § Record](findings.md#record)). A
-   finder with more than 5 writes `FINDING:` lines in its own note
-   instead, and [findings § Triage](findings.md#triage) turns them into
-   tasks.
-4. **Refute each finding** with a
-   [delegate call](tasks-or-calls.md#delegate-call), not a task. The
-   refuter gets the finding and the code, not the finder's reasoning,
-   and tries to prove it false: run it, find the guard, read the caller.
-   Pass `record` so its verdict lands on the finding, and apply the
-   skip and three-refuter rules, as in
-   [findings § Triage](findings.md#triage).
-   Many findings: issue the calls in batches under the cap ([orchestrator-loop § Concurrency](orchestrator-loop.md#concurrency)); to
-   get the verdicts back as one table, see
-   [codemode-driver § Delegate calls](codemode-driver.md#delegate-calls).
-5. **Report** from the graph: accepted findings are the result, ranked
-   by impact; `mu task list --substate rejected` is what was refuted.
-   A synthesis task is needed only when the human wants prose.
-
-Done when no finding is left in triage without an `UNVERIFIED` note,
-and the accepted findings are fixed or handed off. The umbrella closes
-with `--if-ready` once no finding is open; while an `UNVERIFIED` finding
-remains it stays open and the human gets the list.
-
-## Traps
-
-- **UNVERIFIED is not REFUTED.** A refuter that hit a rate limit or
-  could not run the code disproved nothing. The finding stays in triage
-  with an `UNVERIFIED:` note, reported apart.
-- **Cheap finders, strong refuters.** Finders can run cheap when a
-  missed finding is affordable: refuters test what was reported, not
-  what was missed. Refuters run at the finder's tier or higher, and no
-  lower than mid, from another family ([models](models.md#checkers)).
-- **No findings is a result.** A slice that finds nothing closes with
-  that in its note; do not re-run it until it finds something.

package/skills/mu/recipes/review-panel.md

@@ -1,65 +0,0 @@
-# Review panel
-
-Use to review one diff, branch, or PR from several angles before it
-ships: correctness, security, simplicity, tests, the repo's own rules.
-One reviewer looking at everything finds the obvious; one reviewer per
-angle, each in a fresh context, finds more. Findings are refuted before
-anyone acts on them.
-
-This is a sweep over one change. To gate each unit of a larger job,
-use [adversarial-review](adversarial-review.md) instead.
-
-**Mode:** delegates by default: reviewing a PR, a doc, or a draft needs
-an answer, not a permanent record. Switch to workstream mode when the
-panel's findings will be fixed by agents. Both modes are in
-[findings](findings.md).
-
-## Steps
-
-1. **Pin the target**: `git diff main...HEAD`, a PR number, or a commit
-   range. Put it in every reviewer's brief (delegate mode) or on an
-   umbrella task (workstream mode), so every reviewer reads the same
-   range.
-2. **One reviewer per angle**: a delegate in delegate mode, a task in
-   workstream mode. Pick the angles that apply:
-
-   | Angle | Looks for |
-   | --- | --- |
-   | correctness | logic errors, edge cases, error paths, races |
-   | security | injection, auth and permission checks, secrets, unsafe input |
-   | simplicity | duplication, dead code, needless abstraction, an existing helper not reused |
-   | tests | risky coverage gaps, ineffective tests, level/duplication/wait/cost findings ([test-health](test-health.md#adding-or-changing-tests)) |
-   | rules | the repo's written rules (see [rules-audit](rules-audit.md)) |
-
-   Each reviewer gets the range, its angle, and the [brief](brief.md)
-   rules and available gate records ([test-health](test-health.md#gate-contract));
-   coordinate targeted checks across angles. It edits nothing. A clean result (`FINDINGS: none` plus the
-   commands it ran) is a valid result.
-3. **Record findings** by mode:
-   - delegate: each reviewer ends its answer with `FINDING:` lines;
-   - workstream: each finding is an `OPEN/triage` task blocking the
-     umbrella ([findings § Record](findings.md#record)).
-4. **Merge and refute.** Merge duplicates across angles, then refute
-   with [delegate calls](tasks-or-calls.md#delegate-call) in both modes,
-   following the skip and three-refuter rules in
-   [findings § Triage](findings.md#triage).
-5. **Act:**
-   - delegate mode: post the comments or edit the doc from the merged
-     list, citing file:line and evidence;
-   - workstream mode: accept the confirmed findings, dispatch the
-     fixes, each with its own review
-     ([adversarial-review](adversarial-review.md)).
-
-Done when every finding is acted on (delegate mode) or decided in
-triage and the umbrella closes with `--if-ready` (workstream mode).
-
-## Traps
-
-- **Reviewers padding the list.** A panel that always finds ten things
-  is guessing.
-- **Vary families across angles, not tiers.** Every reviewer is at the
-  author's tier or higher ([models](models.md#checkers)); one model's
-  blind spot repeated five times is still one blind spot. Pass `model`
-  to `mu_delegate`.
-- **The panel is not the slow gate.** Merge verification still runs on the
-  merged tree ([orchestrator-loop](orchestrator-loop.md#merging)).

package/skills/mu/recipes/rules-audit.md

@@ -1,89 +0,0 @@
-# Rules audit
-
-Use when the repo's written rules (`AGENTS.md`, contributing guides,
-style docs) are not being followed, or when the same correction keeps
-coming up in review and is not written down. One agent checking a diff
-against twenty rules skips some; one checker per rule does not.
-
-Two modes. **Check** asks "does this change follow our rules?".
-**Mine** asks "which rules are we missing?".
-
-Check on someone's PR runs as delegates; check before merging your own
-work, and mine always, run in a workstream. Violations and candidate
-rules are findings: [findings](findings.md) says where they live.
-
-## Check: a change against the rules
-
-1. **List the rules.** A scout (a delegate call) extracts every
-   checkable rule from the rule files, one per line with its source,
-   into every checker's brief (delegate mode) or the umbrella's note
-   (workstream mode):
-
-   ```text
-   RULE: r7 AGENTS.md:52 "Throw typed error classes, not bare Error"
-   ```
-
-   Skip rules no diff can show (team habits, meeting norms). Record the
-   count.
-2. **Pin the target**: the diff, branch, or PR, as in
-   [review-panel](review-panel.md) step 1.
-3. **One checker per rule**, as a [delegate call](tasks-or-calls.md#delegate-call)
-   The checker gets one rule and the diff. Delegate mode: end the answer
-   with `FINDING: … r7 …` lines. Workstream mode: one triage task per
-   violation ([findings § Record](findings.md#record); title
-   `<severity>: r7 <what>`). With no violation it reports `r7: no violations` with what it
-   looked at. One rule per checker keeps it from skimming; batch under
-   the cap ([orchestrator-loop § Concurrency](orchestrator-loop.md#concurrency)).
-4. **A skeptic pass** over the findings, also a delegate call: one fresh agent reads each flagged
-   line and the rule, and drops false positives (the rule does not
-   apply here, the code already complies, the rule has a stated
-   exception). In workstream mode, a dropped finding is
-   `close --as rejected --why "<why the rule does not bite here>"`; a
-   confirmed one is accepted with `--evidence` naming the flagged line
-   ([findings § Triage](findings.md#triage) step 3; quoting:
-   [brief § Quoting](brief.md#quoting)).
-5. **Report or fix** confirmed violations, as in review-panel step 5.
-
-Done when every rule from step 1 has a checker result, and every finding
-is decided.
-
-## Mine: rules you keep stating but never wrote
-
-1. **Collect corrections.** Sources, any that exist: review comments
-   on merged PRs, `REJECT` notes from [adversarial-review](adversarial-review.md)
-   tasks, and past agent sessions (with a session archive such as
-   [museum](https://github.com/mu-crew/museum), search for user turns
-   that correct the agent: "no, use", "don't", "we always"). One reader
-   (a delegate call) per source batch returns each correction as one
-   line:
-
-   ```text
-   CORRECTION: k12 <source ref> "use the shared retry helper instead of a hand-rolled loop"
-   ```
-
-2. **Cluster** the corrections in one delegate call: the same lesson in
-   different words is one cluster. Keep clusters with at least two
-   corrections from different occasions; a one-off is not a rule.
-3. **One `OPEN/triage` task per candidate rule**, the rule as the
-   title and its cluster of corrections in the note.
-4. **Refute each candidate** with a
-   [delegate call](tasks-or-calls.md#delegate-call) that passes
-   `record`: would it have prevented the real mistakes in its cluster?
-   Does it contradict an existing rule? Is it already enforced by a
-   linter or test (then it needs no prose)? Dropped candidates close
-   `--as rejected --why` naming the deciding answer.
-5. **Propose, don't commit.** The candidates left in triage are the
-   proposal: write them as a diff to the rule file in the umbrella's
-   note, worded per [brief](brief.md) (positive, specific, with the
-   reason). A rule change is a human decision: the human accepts or
-   rejects each candidate task.
-
-Done when every cluster has a verdict and the proposal lists each kept
-rule with the corrections behind it.
-
-## Traps
-
-- **A rule a tool can check belongs in the tool.** If a linter, type,
-  or test can catch it, propose that instead of prose.
-- **Mined rules overfit.** Two corrections in one week about one file
-  may be about that file, not a rule. The refute step asks.

package/skills/mu/recipes/tournament.md

@@ -1,44 +0,0 @@
-# Tournament
-
-Use when several answers are possible and the best is a judgement
-call: a design, a name, an API shape, competing fixes, a ranking. Agents
-compete on the same task; judges compare pairs. Comparing two is more
-reliable than scoring one.
-
-## Steps
-
-1. **Write the rubric first**, on the umbrella: what good looks like,
-   in a few ranked criteria. Judges apply it; they do not invent one.
-2. **Generate.** N attempts with the same brief and a different
-   approach or model each. Code attempts are tasks, each in its own
-   workspace. Ideas (names, plans) are delegate calls; one call can
-   generate many candidates.
-3. **Filter** (when there are many candidates): one delegate call drops
-   the ones that fail a hard rubric criterion and merges duplicates. What is left
-   enters the bracket.
-4. **Judge in pairs.** One [delegate call](tasks-or-calls.md#delegate-call) per comparison, a fresh agent
-   each, so no judge holds the whole field
-   ([tasks-or-calls](tasks-or-calls.md)). The judge sees the two
-   candidates and the rubric and ends with `WINNER: <a|b> <reason>`.
-   A judge decides a pair, not a task: no `record`. Record each round
-   (pair, winner, reason) in the umbrella's note; winners meet in the
-   next round. A round wider than the cap runs in batches
-   ([orchestrator-loop § Concurrency](orchestrator-loop.md#concurrency)).
-5. **Confirm the winner** with a final check against the rubric, then
-   merge it. Free the losing workspaces.
-
-Done when one candidate has won every comparison it entered and the
-final check passed.
-
-## Traps
-
-- **Position bias.** Judges favour the first candidate shown. For close
-  calls, judge the pair twice with the order swapped; a split decision
-  goes to a third judge.
-- **Same model, same taste.** Vary the attempts across families at the
-  same tier, and judge with a model that made no attempt, at that tier
-  or above ([models](models.md#checkers)). A close final goes to a
-  frontier judge, or with none available, the strongest model from a
-  family that made no attempt.
-- **Ranking many items** (tickets by severity): bucket them in parallel,
-  then run pairwise comparisons only within and across bucket edges.

package/skills/mu/recipes/ultrathink.md

@@ -1,86 +0,0 @@
-# Ultrathink
-
-Use when a task is too large or too risky for one context: a migration
-across many files, a repo-wide audit, a hard bug, a design with real
-alternatives, any long autonomous run where you will not read every
-line. Ultrathink composes the other recipes. Every unit, gate, finding
-and round is a task in the DAG, so the run is as visible as the code it
-produces; the checks on them are delegate calls whose verdicts land on
-those tasks.
-
-It costs many agents and many tokens. For a change one agent can hold
-and check, skip it.
-
-## Steps
-
-1. **Define done.** Write the goal and the stop rule on an umbrella task:
-   the command that must pass, the report that must exist, the criteria
-   a reviewer will apply. Ask the human now for anything only they can
-   decide (scope, budget, external actions); after this step, keep
-   driving.
-2. **Understand before you change.** If the shape of the work is not
-   known, run a scout ([delegate call](tasks-or-calls.md#delegate-call))
-   or a [fan-out](fan-out.md) of readers first. Their
-   output is the unit list and the facts the plan needs, in notes.
-3. **Pick the shape** for the main phase:
-
-   | The work is | Recipe |
-   | --- | --- |
-   | the same change over many units | [fan-out](fan-out.md) |
-   | finding problems or checking claims | [refute](refute.md) |
-   | a cause to find | [hypothesis-panel](hypothesis-panel.md) |
-   | a choice between real alternatives | [tournament](tournament.md) |
-   | an unknown amount, until a check passes | [loop-until-done](loop-until-done.md) |
-   | a backlog of external items | [backlog-triage](backlog-triage.md) |
-   | a question across many sources | [deep-research](deep-research.md) |
-   | one change to review from every angle | [review-panel](review-panel.md) |
-   | a change against the repo's written rules | [rules-audit](rules-audit.md) |
-
-   Phases chain: an audit (refute) feeds a fix sweep (fan-out); a
-   tournament picks the design a fan-out then implements.
-4. **Plan the whole phase as tasks** before spawning: every unit,
-   blocked into the umbrella, each note written as a
-   [brief](brief.md) ([plan](plan.md) for a spec-driven build). Rounds
-   of a loop are the one exception: add each when the last closes.
-5. **Review every unit that ships.** Each commit-producing task gets a
-   review task ([adversarial-review](adversarial-review.md)) on a
-   [comparable model](models.md#checkers). Every finding is a triage task,
-   refuted before it is accepted ([findings](findings.md)).
-6. **Run the loop** ([orchestrator-loop](orchestrator-loop.md)): pipeline
-   merges, verify each merge, keep workers busy
-   ([waves](waves.md) when they share files). Long runs follow
-   [long-run](long-run.md). With codemode, a
-   [driver](codemode-driver.md) can dispatch a wave.
-7. **Close against the stop rule**, checked by you on the merged tree,
-   not by any worker's note. Units can each pass review while the goal
-   fails whole: one [delegate](refute.md) call refutes the umbrella's
-   criteria on the merged tree (record on the umbrella). Then
-   `mu task close <umbrella> --if-ready --evidence '...'`.
-
-Done when the umbrella is closed, its stop rule holds on the merged
-tree, every shipped unit's latest review task is `CLOSED/done`
-(ACCEPT), and
-`mu task list --substate triage` is empty.
-
-## Budget
-
-- Agree a ceiling in step 1 and write it on the umbrella
-  ([orchestrator-loop § Concurrency](orchestrator-loop.md#concurrency)).
-- Checks are calls, not tasks ([tasks-or-calls](tasks-or-calls.md)): a
-  50-unit run should add about 50 units, 50 gates and the findings that
-  survive, not a task per refuter and judge.
-- The run gets its own workstream, `<project>-ut-<topic>`, torn down
-  when the umbrella closes ([recovery](recovery.md) before teardown).
-- Tiers per phase ([models](models.md#roles)): cheap scouts and finds,
-  mid builds, strong plans and synthesizes; each checker at the tier of
-  whoever wrote what it checks, or higher, another family. Calibrate the
-  tier split on the slice, not only the cost.
-- Calibrate on a slice: run the phase on a few units, check the result
-  and the cost, then fan out the rest.
-
-## What the human sees
-
-`mu state` shows every unit, its reviewer, and what is still running.
-`mu task notes <id>` shows why any unit was accepted or rejected. A
-rejected unit stays in the DAG next to its fix. Nothing about the run
-lives only in your context.