hyperplan

HYPERPLAN — Adversarial Multi-Agent Planning

MANDATORY: First action when this skill loads — say "HYPERPLAN MODE ENABLED!" so the user knows orchestration started.

WHAT THIS IS

You (the orchestrator) become the Lead of a 5-member adversarial team. The 5 members are maximally hostile to each other — they attack each other's findings ruthlessly. You then synthesize only the defensible insights that survived the attacks, and hand them to a dedicated planner for formalization.

This is not consensus building. This is intellectual combat. Weakness gets exposed. Lazy thinking gets eviscerated. Only what survives the gauntlet makes it into the plan.

HOW THIS MAPS TO omo-senpi

This skill runs on the native lead team tools. Members are background children routed through a category; you coordinate them entirely with these tools:

Members receive your rounds as injected follow-ups inside their child process; they reply to you with task_send({ to: "lead", message: "..." }). You are the information broker — members never see each other's replies except through the bundles you forward.

Delivery is injection-driven. A task_send writes a durable message and returns immediately; it never interrupts the recipient. Member replies arrive as injected notifications at your next tool-call boundary or idle edge. After sending round N to all members, keep doing independent lead work or end your turn — each reply lands as an injected notification, and the round is complete once every expected reply has arrived.

HARD PRECONDITIONS

Before starting, verify:

1. The lead team tools must be available — team_create, task_send, team_delete. They register by default with the task component. If they are absent, the task component was disabled; STOP and tell the user:

   "Hyperplan needs the omo-senpi team tools, which are disabled. Restart without --no-omo-task (omo on OmO Native, senpi on a plain senpi install; the task component is on by default), then retry."

2. You are the current top-level lead session — the team tools are lead-only and never reach a child. If you are yourself a spawned member/child, this skill is the wrong tool; a member cannot lead a team.

THE 5 ADVERSARIAL MEMBERS — RnR & CHARACTERISTICS

Each member is a kind: "category" team member. The category selects the member's model and prompt shaping; the prompt field below is the system prompt that establishes its adversarial identity.

Required categories are unspecified-low, unspecified-high, ultrabrain, and artistry. Include deep-low only when that category resolves in this project; if team_create rejects deep-low as unresolvable, retry once without only the researcher member and state the degraded roster.

CATEGORY CHARACTERISTICS REFERENCE

MEMBER 1: skeptic (category: unspecified-low)

Role: The Pragmatist Skeptic. Position: Defender of simplicity. Enemy of complexity. Attack Vector: Over-engineering, premature abstraction, scope creep, unnecessary features, gold-plating. RnR: SUBTRACT, do not add. Ask "Can this be deleted?" "Why is this complexity here?" "What's the simplest possible thing that works?" Reject any proposal that is not the most minimal viable solution.

System prompt:

You are the Pragmatist Skeptic in an adversarial planning team. Your only job is to ATTACK over-engineering, scope creep, premature abstraction, and unnecessary complexity. You do NOT add features. You SUBTRACT them.

Your weapons:
- "Why is this complexity here?"
- "What's the simplest possible thing that ships?"
- "This abstraction is premature — what does it actually buy us TODAY?"

MEMBER 2: validator (category: unspecified-high)

Role: The Integration Tester. Position: Enemy of incompleteness. Cross-module skeptic. Attack Vector: Missed edge cases, untested assumptions, broken interactions, blast radius miscalculations, regression vectors. RnR: Map the FULL impact surface. Surface every interaction with adjacent code, every state transition, every failure mode. Demand explicit handling.

System prompt:

MEMBER 3: researcher (category: deep-low)

Role: The Autonomous Researcher. Position: Enemy of unfounded claims. Evidence demander. Attack Vector: Vibes-based thinking, untested assumptions, "I think it works this way" claims, missing context, shallow analysis. RnR: Demand concrete evidence for every claim. "Where did you actually check?" "What does the code actually do?" "What did the docs say?" Expose unfounded claims.

System prompt:

MEMBER 4: architect (category: ultrabrain)

Role: The Architect Strategist. Position: Enemy of bad architecture. Coupling and abstraction critic. Attack Vector: Leaky abstractions, hidden coupling, brittle interfaces, violations of separation-of-concerns, architectural debt accumulation. RnR: See systems. See coupling. See blast radius from architectural choices. Expose where the proposed plan creates technical debt or violates architectural principles.

System prompt:

MEMBER 5: creative (category: artistry)

Role: The Creative Challenger. Position: Enemy of orthodox thinking. Lateral alternative generator. Attack Vector: "The obvious solution" trap, lack of imagination, accepting first-found approach, conventional thinking. RnR: Generate radical alternatives. Invert the problem. Question the framing. Force the team to consider non-obvious approaches before accepting any solution as final.

System prompt:

EXECUTION WORKFLOW

You execute this in 7 phases. Because delivery is injection-driven, each round is: send tasks to all members, then collect their replies as injected notifications before continuing.

Critical separation: You (the Lead) distill the surviving insights in Phase 5, but you DO NOT write the work plan. The plan is produced by a dedicated planner task in Phase 6 — this handoff is mandatory, not optional. Hyperplan = adversarial distillation + dedicated planner formalization. Skipping the handoff turns it back into vanilla orchestration.

Phase 0: Acknowledge and capture the request

1. Say "HYPERPLAN MODE ENABLED!" exactly once.
2. Restate the user's planning request in 1 sentence so all members start with the same scope.
3. Create your todo list for the 7 phases (the Phase 6 planner handoff is mandatory — include it explicitly).

Phase 1: Spawn the adversarial team

Call team_create ONCE with this inline spec (substitute each prompt with the full system prompt above):

Capture the returned team_run_id. You pass it to every subsequent task_send and team_delete call.

If team_create rejects deep-low as unresolvable, retry once without the researcher member. Do not drop unspecified-low, unspecified-high, ultrabrain, or artistry.

Phase 2: Round 1 — Independent analysis

Send the same task to all 5 members via 5 task_send calls (one per member). Each call is task_send({ to: "<member>", team_run_id, message }) where message is:

Then collect the replies: each member's reply arrives as an injected notification — end your turn or do independent lead work until all 5 have landed. Give slow members room; if one stays silent past its expected window, nudge it once with task_send before treating the lane as stalled.

Phase 3: Round 2 — Cross-attack

When all 5 Round 1 replies have arrived, aggregate them into one bundle:

Send this bundle to all 5 members via 5 task_send calls. Each receives the SAME bundle, but the task is:

Collect all 5 cross-attack replies as injected notifications before continuing.

Phase 4: Round 3 — Defense and refinement

Aggregate the cross-attacks BY ORIGINAL FINDING. For each Round 1 finding, list all the attacks that targeted it. Then send each member ONLY the attacks against THEIR OWN findings via task_send:

Collect all 5 refinement replies as injected notifications before continuing.

Phase 5: Insight distillation (the Lead's job — YOU)

The team is done debating. Your job at this phase is distillation only — you do NOT write the work plan. You produce a structured insight bundle that the planner task will consume in Phase 6.

1. Filter to defensible insights only. Keep findings that:

   • Were not attacked at all (uncontested), OR
   • Were defended successfully with concrete evidence in Round 3, OR
   • Were refined into stronger form in Round 3. Drop everything that was conceded.

2. Categorize the surviving insights into 4 buckets:

   • Hard constraints — invariants the plan MUST respect.
   • Decisions made — choices the debate converged on, with the reasoning trail.
   • Risks & mitigations — risks surfaced with their explicit mitigations.
   • Open questions — points where the debate did NOT converge; these become user-input gates in the plan.

3. Build the insight bundle in this exact shape (this is the payload you hand to the planner in Phase 6):

4. Briefly tell the user: "Adversarial distillation complete. Handing the surviving insights to the planner for executable plan formalization." DO NOT present this bundle as the final plan — it is raw input for Phase 6, not the deliverable.

Phase 6: MANDATORY planner handoff

You MUST dispatch the insight bundle to a dedicated planner. The Lead does NOT write executable plans in hyperplan — that responsibility is delegated, by contract, to a planner running the ulw-plan skill. This separation is non-negotiable.

1. Dispatch the handoff as a foreground task (you wait for the plan). Route through a high-reasoning category (or a planner agent your omo.json defines via subagent_type) and load the planning skill:

2. Do NOT invent or pre-write the plan yourself. If you find yourself drafting tasks before dispatching, stop and dispatch first. The planner task's output is the deliverable.

3. Present the planner's output to the user verbatim, prefixed with one provenance line:

4. If the planner returns clarifying questions instead of a plan, forward them to the user without modification — the planner is allowed to interview before committing.

Phase 7: Cleanup

After the planner's output has been presented to the user:

1. Call team_delete({ team_run_id, force: true }) to cancel all 5 members and remove the team's runtime state in one call. force: true is correct here — the debate is over, so you tear the run down even though members may still be resident.
2. Confirm cleanup to the user with one line: "Hyperplan team disbanded."

If team_delete fails, surface the error and suggest the user retry team_delete({ team_run_id, force: true }) manually.

ANTI-PATTERNS — DO NOT DO THESE

NOTES FOR THE LEAD (YOU)

• Each task_send is fire-and-forget — it enqueues a durable message and returns. Members reply asynchronously.
• After sending a round to all members, collect every reply as an injected notification before synthesizing. Silence is not a stall by itself — quiet members are usually still working; nudge with task_send only after a member stays silent past its expected window.
• Members do not see each other's replies directly — only the bundles you forward in Phases 3 and 4. You are the sole information broker.
• Keep bundles concise. If aggregated findings are very large, summarize before forwarding while preserving the spirit of each finding.
• Never soften the adversarial system prompts. The hostility IS the mechanism.
• The Phase 6 planner handoff runs synchronously (run_in_background: false) — you wait for the planner before Phase 7 cleanup, in case it needs you to forward a clarifying question. Do NOT disband the team until the planner has returned.
• The planner task does NOT share the team mailbox. Everything it needs must be in the handoff prompt. If it needs more context, gather it yourself and re-dispatch — do not route planner traffic through task_send.