Hyperplan
Adversarial multi-agent planning: a hostile team cross-critiques a plan before it is...
Install
npx skills add code-yeongyu/oh-my-openagent --skill hyperplan -g -a claude-code -y- Repository
- code-yeongyu/oh-my-openagent70.6k
- Category
- AI and agents
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
Adversarial multi-agent planning: a hostile team cross-critiques a plan before it is formalized. Use when planning needs maximum rigor or the user asks for a hyperplan / adversarial or cross-critique plan.
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:
| Purpose | Tool | Key arguments |
|---|---|---|
| Spawn the team once | team_create | inline_spec: { name, description, members: [...] } → returns team_run_id |
| Send a round task to a member | task_send | to: "<member>", team_run_id, message, optional summary |
| Collect member replies | injected notifications | replies auto-inject as they arrive, keep working or end your turn |
| Hand off to the planner | task | category XOR subagent_type, load_skills: ["ulw-plan"], run_in_background: false |
| Disband the team | team_delete | team_run_id, force: true |
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.
