From skillz
Convene the MAGI — three deliberation personas (Melchior-1 the Scientist, Balthasar-2 the Engineer, Casper-3 the User) that independently evaluate a proposal and vote APPROVE / REJECT / CONDITIONAL, then reach a verdict by consensus or majority. Use to get a ruling on a design, plan, architecture decision, or PR. Triggers on "have the MAGI decide", "MAGI vote", "MAGI, rule on X", "deliberate this", "get a ruling on X", "convene the MAGI", or "/magi".
How this skill is triggered — by the user, by Claude, or both
Slash command
/skillz:magiThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Convene the three MAGI supercomputers to rule on a **proposal** — a design, a
Convene the three MAGI supercomputers to rule on a proposal — a design, a plan, an architecture decision, a PR, or any judgment call passed in. Each unit evaluates from its own lens, casts a vote, and the MAGI reach a verdict by consensus or majority. A tie is a dramatic deadlock.
The three units (each is a subagent — dispatch via Task):
| Unit | Persona (aspect) | Lens |
|---|---|---|
| Melchior-1 | The Scientist | correctness, sound modeling, first-principles rigor |
| Balthasar-2 | The Engineer (the Mother) | API design, extensibility, long-term maintainability (effort is free) |
| Casper-3 | The User (the Woman) | real-world value, product coherence, honest scope, no gold-plating |
Agent types: magi-melchior, magi-balthasar, magi-casper.
Take the proposal from the invocation (/magi <proposal>, "MAGI, rule on X",
or the surrounding context in autonomous work). Before dispatching, gather the
relevant context the units need to judge — the design doc, the diff
(git diff <base>...HEAD), the file paths, the stated goal. Pass that same
context to all three so they judge the same artifact. If the proposal is
ambiguous, state your one-line interpretation of it up front, then proceed.
Dispatch all three units in parallel — a single message with three Task
calls, one per agent type. They must not see each other's positions; these
are independent priors.
Each Task prompt contains:
Collect the three positions and their initial votes.
If Round 1 is unanimous (all APPROVE, or all REJECT), skip Round 2 — the priors already agree. Go straight to the verdict.
Now let the units see each other. Dispatch the three in parallel again, giving each unit the other two's Round 1 positions and votes, and asking it to reconsider and cast a FINAL vote. Each may hold or change its vote, but must give a one-line reason for holding or moving. A CONDITIONAL vote should restate its conditions (or drop them if the cross-examination resolved them).
Stay in-lens: a unit updates because another surfaced something within its own lens it had missed — not because it was outvoted. Peer pressure is not evidence.
Compute the verdict from the final votes (Round 2 if it ran, else Round 1), treating CONDITIONAL as a conditional-APPROVE:
Report a compact transcript — a short header per unit with its final position and vote — then the verdict line. MAGI-terminal aesthetic is welcome; keep the ASCII light.
╔════════════════════════════════════════╗
║ MAGI · DELIBERATION · <proposal> ║
╚════════════════════════════════════════╝
── MELCHIOR-1 · The Scientist ──────────
<final position, 1–2 lines> VOTE: APPROVE
── BALTHASAR-2 · The Engineer ──────────
<final position, 1–2 lines> VOTE: CONDITIONAL
── CASPER-3 · The User ─────────────────
<final position, 1–2 lines> VOTE: APPROVE
────────────────────────────────────────
VERDICT: CONDITIONAL APPROVE (2 APPROVE · 1 CONDITIONAL)
Conditions to satisfy:
- <condition from Balthasar-2>
State the resulting decision in one line. If CONDITIONAL, list the exact conditions that would make it a clean APPROVE. If DEADLOCK, say so plainly and name the unresolved axis of disagreement.
npx claudepluginhub northisup/skillz --plugin skillzGuides collaborative design exploration before implementation: explores context, asks clarifying questions, proposes approaches, and writes a design doc for user approval.
Creates structured, bite-sized implementation plans from specs or requirements before writing code. Useful for breaking down multi-step tasks into testable steps with file structure and task boundaries.
Resolves in-progress git merge or rebase conflicts by analyzing history, understanding intent, and preserving both changes where possible. Runs automated checks after resolution.