Madness

Madness — the front door

This is the one entry point you can reach for when you don't want to think about which of the dozens of skills is the right one. You say what you're trying to do; madness figures out the correct starting skill, confirms if it's about to launch something heavy, and hands you off into it.

Why this exists

The toolkit under-triggers. With dozens of skills loaded every session, descriptions blur and the model often answers a request directly instead of reaching for the skill that would do it better. The usual workaround is to type orchestrator as a panic button — but orchestrator is a multi-agent build entry point (contracts, role agents, QA gates). On anything that isn't a parallel build it either spins up machinery you don't need or bounces you with "this isn't a multi-agent build." So the crutch works, but it's the wrong shape.

madness is the right-shaped crutch: a hair-trigger router whose only job is to land you in the correct front door and get out of the way. Type /madness, or ask "where do I even start with this," and it routes.

The prime directive: route, then hand off

Pick the right starting skill, launch it, and stop. madness is not a meta-orchestrator and must never become the work. It does not write the code, draft the plan, or run the loop itself — it identifies which skill does that and invokes it. The moment the target skill is running, madness is done. If you find yourself doing the task instead of dispatching it, you've drifted; route and hand off.

This is the deliberate counterpart to skill-explorer, which names a skill but will not invoke it. madness is the active version: it names and launches. See "madness vs skill-explorer" below for when to use which.

How a dispatch goes

1. Get the intent. If invoked as /madness <task>, the argument is the intent. If invoked bare (/madness with nothing after it), or the intent is too vague to route confidently, show the menu (below) and ask — one question, then route. Don't guess at a heavy route from a one-word prompt.

2. Classify to a front door. Match the intent against the entry-point map below. Route to the front door, not the leaf skill — orchestrator, plan-builder, and loop-controller each do their own internal routing, so handing off to them is enough. For the long tail the map doesn't cover, lean on skill-explorer's references/routing-table.md (the full intent->skill table) rather than reinventing it here.

3. Decide cheap or expensive. See the confirm gate below. This decides whether you launch immediately or check first.

4. Announce, then launch. State the pick in one line — "This is a multi-agent build -> launching orchestrator." For an expensive route, end that line with a question and wait ("...that spins up a team and runs autonomously — go?"). For a cheap route, just invoke. Use the Skill tool (or the skill's trigger phrase) to actually fire it — naming it without invoking is skill-explorer's job, not this one.

5. Hand off and get out of the way. Once the target skill is active, let it drive. Don't narrate over it or duplicate its work.

The entry-point map

Route intent -> front door. Each front door owns the deeper routing from there. Targets marked Claude-Code-native (feature-dev:feature-dev, frontend-design:frontend-design, orchestrator, the loops, the role agents) exist only on Claude Code; on any other host, route to the nearest portable skill in the same row instead.

The load budget: one skill, or none

Route to one skill. Pushy descriptions mean any request touching a shared term ("deploy", "review") makes several skills look plausible — but plausible-on-topic is not the test. Ask which decision is actually unresolved and route to the skill that resolves it (the "By unresolved decision" index in skill-explorer/references/routing-table.md keys on exactly this). Add a second skill only when the request genuinely contains two distinct open concerns — a sequenced handoff like plan-builder -> orchestrator is one route with a next step, not a second pick. An accepted token-saver offer (the confirm-gate question below) also doesn't count against the budget: a user-consented use-pxpipe side-launch is run infrastructure, not a second routing pick.

And "no skill" is a legal outcome. When no decision a skill resolves is open, say so plainly and stop — a wrong-but-plausible launch costs more than "nothing here needs a skill; closest miss is X, and here's the gap." If it looks like a genuinely new pattern, point at skill-writer.

The confirm gate: cheap goes, expensive confirms

The split exists so a reflexive /madness can never silently spend an hour or spawn a swarm. Judge by blast radius, not by category label.

Expensive — confirm with a one-line "...go?" first. Anything that spawns multiple agents, runs autonomously on its own loop or schedule, kicks off a full multi-component build, or is awkward to unwind: orchestrator, every loops/* skill (via loop-controller), large plan-builder->orchestrator handoffs that proceed straight into building, anything that pushes commits or opens PRs without you in the seat.

Cheap — just launch. Single-skill, read-mostly, fast, and easy to walk back: skill-explorer, a single role skill, ui-brief, mermaid-charts, contract-author, repo-deep-dive, a git-* helper. Confirming these only adds a turn of friction for no safety gain.

When unsure which side a route falls on, treat it as expensive and ask. The cost of one needless confirm is a sentence; the cost of an unwanted swarm is real.

The token-saver question (rides the expensive confirm)

This question only applies on Anthropic hosts (Claude Code / Claude API), where use-pxpipe can sit in front of the model. On any other host — DeepSeek, Hermes, any non-Anthropic model — skip it entirely and go straight to the route.

The runs madness gates as expensive — swarms, autonomous loops, full builds — are exactly the long, token-heavy sessions where the pxpipe proxy pays (it cuts input tokens roughly in half to a third by imaging re-sent bulk; see use-pxpipe). So when an expensive route confirms, fold one extra question into the same line: "enable the token-saver proxy for this run?" Once per session — a decline holds; don't re-ask on the next route.

Know when not to ask, so the courtesy never becomes a nag:

• Cheap or short routes — the proxy's own profitability gate passes small sessions through anyway, so the question is pure friction.
• Byte-exact-critical work — runs where history would be the sole copy of secrets, hashes, or exact numbers have the wrong loss profile for imaging.
• Already answered — the proxy is already wired (ANTHROPIC_BASE_URL points at it) or the user declined earlier this session.
• Model not on the allowlist — if the session's model isn't allowed per model-adaptation's Image-proxy model allowlist, the proxy would pass requests through uncompressed; there's nothing to offer.

Suggest-only, never auto-enable. On a yes, launch use-pxpipe to do the wiring (the allowlist check and cache-warm verification are its job), then continue into the route. madness never sets the env var itself — that would be doing the work instead of routing it.

No args or vague intent -> the menu

If you can't route confidently, don't pick at random — show the lay of the land and ask which door. Keep it to the front doors, not the whole library:

Where do you want to go?
  • Build something — multi-agent (orchestrator) or one feature (feature-dev)
  • Plan it first — turn research/PRD/goal into a build plan (plan-builder)
  • Run a loop — work until tests pass / coverage / a contract holds (loop-controller)
  • Design a UI — brief first, then build (ui-brief)
  • The skills themselves — find / create / audit / sync (skill-explorer, skill-writer, ...)
  • Just browsing — "what do I have / which one for X" (skill-explorer)

Then route the answer through the normal flow (classify -> cost -> launch).

madness vs skill-explorer

They are deliberately the two halves of one idea:

• skill-explorer answers "what do I have / what's it called / which one fits" and stops at the name. Passive. Use it to browse and decide.
• madness takes the intent and launches the right front door. Active. Use it to actually get moving.

So if the user is clearly just orienting ("what skills do I have for testing?"), hand to skill-explorer — that's its job, and madness shouldn't take it over. If the user wants to do the thing ("set up the tests and run them till green"), madness routes and launches.

When NOT to use madness

• The user already named the skill they want ("use ui-brief for the dashboard") — just run that skill; routing through madness is a pointless hop.
• The user is mid-task inside an active skill and asks a domain question — let the running skill handle it.
• The request is a clean, unambiguous match for one skill's own triggers ("write the OpenAPI contract", "commit this") — those skills should fire directly. madness is for routing confusion and cold starts, not for adding a hop in front of triggers that already work.

Host awareness — this skill works on every host

madness runs on Claude Code, Hermes, DeepSeek, and any other harness that loads skills. The routing logic is host-agnostic; only the set of available target skills changes. "Not Claude Code" is never a reason to skip routing.

The one host-specific step: route to skills that actually exist here. The skills available in this session are listed in your context — check that list before you name a target. Some front doors in the map below are Claude-Code-native (orchestrator's Agent Teams, every loops/* skill, the role agents, and the workflows bound to the Artifact tool or ~/.claude config). On a host where those aren't present or don't run, route to the closest portable skill — the git, planning, docs, review, debugging, and contract workflows work everywhere — and name the gap in one line. Never answer "this is Claude Code only"; pick the nearest live route.

Anti-patterns