/omh-adversarial-consensus

name: "omh-adversarial-consensus"
description: "[omh] Technical proposal facing adversarial scrutiny: independent perspectives attack a proposal, then distill into a bundle a separate planner consumes. Use when the user says: adversarial-consensus, adversarial planning, adversarial plan review, red team this plan, red-team this plan, red team the proposal, multi-perspective review, multiple perspectives."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, planning]
    category: planning
    phase: adversarial-consensus
    role: planner
    quality_tier: reviewed-plan-gated

Adversarial Consensus

This is a Hermes-native `adversarial-consensus` workflow skill.

Why This Exists

`adversarial-consensus` exists because agreement reached by perspectives that read each other is not review — it is convergence. Independent findings, an attack round nobody is allowed to defend against, and a distillation that may only subtract produce objections a single planning pass never surfaces, and the mandatory handoff keeps that bundle from being mistaken for the plan.

Do Not Use When

• The user wants the plan itself, with options, acceptance criteria, and verification commands; use `ralplan`, which this workflow feeds.
• The request is still too ambiguous to state the proposal being attacked; use `deep-interview` first.
• The user wants completed code reviewed for defects rather than a proposal attacked before it is built; use `code-review`.
• The user wants hostile runtime scenarios against a built change; use `ultraqa`.
• One perspective would do: a small local change with no contested decision does not earn three rounds.

Examples

Good example:

• Prompt: $adversarial-consensus we plan to move session state into Redis before the launch — attack it from every angle before I write the plan.
• Expected behavior: Name the roster and their distinct angles, take blind findings from each, run one attack-only round, resolve each objection to defend/refine/concede, distill only into the four buckets, and hand the bundle to `ralplan` as planning input.
• Why: The decision is contested and pre-plan, which is exactly where independent objections are worth more than one planner's confidence.

Bad example:

• Prompt: $adversarial-consensus give me the migration plan with the steps and the rollout order.
• Expected behavior: Produce the distilled bundle and hand it to `ralplan`; the steps and rollout order are the planner's output, not this workflow's.
• Why: The bundle is INPUT to planning. Emitting a plan here skips the reviewed-plan gate and turns the buckets into a task list.

Completion Checklist

• The roster is named with 3-5 distinct angles, and no two seats argue the same one.
• Round-one findings were produced blind, and any perspective that could not be kept blind is named as a broken-independence caveat instead of being presented as independent.
• Every cross-attack objection targets another perspective's finding, and no perspective defended itself in that round.
• Every objection carries exactly one verdict — defended, refined, or conceded — and conceded findings are struck, not softened.
• The bundle contains only Hard Constraints, Decisions, Risks, Open Questions, every line traces to a surviving finding, and nothing new was added at distillation.
• The closing message states that the bundle is input, names the follow-on planning workflow, and claims no plan, acceptance, implementation, or verification evidence.

Recovery Notes

• If the proposal under review cannot be stated in one paragraph, route back to `deep-interview` before opening round one.
• If independence was broken — a perspective saw another's findings, or the same seat produced two angles — say so, re-run that perspective on a restated problem, and mark the round's independence as caveated rather than silently continuing.
• If a round produces no objections at all, treat that as a roster defect rather than consensus: state which angle is missing and add or replace a seat before distilling.
• If distillation would need a fifth bucket, the extra content is a plan trying to escape; move it to the planner handoff instead of widening the bucket set.

Workflow Lane

• Current lane: **Intent -> plan** (`oh-my-hermes`, `meta-router`, `deep-interview`, `context`, `plan`, `ralplan`, `adversarial-consensus`, `codebase-onboarding`, `+8 more`) - clarify, plan, ship, or loop goals.
• If intent belongs to another lane, hand back to `oh-my-hermes` or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: `omh-routing/references/skill-common-rail.md`.

Use When

Use when a proposal, plan, or direction needs independent perspectives to attack it before a plan is written, and the distilled result is meant as input to planning rather than as the plan.

Strong routing signals: `adversarial-consensus`, `$adversarial-consensus`, `adversarial planning`, `adversarial plan review`, `red team this plan`, `red-team this plan`, `red team the proposal`, `multi-perspective review`, `multiple perspectives`, `independent perspectives`, `attack this proposal`, `poke holes in this`, `hyperplan`, `敵対的レビュー`, `多角的レビュー`, `レッドチームレビュー`, `この計画に反論`, `穴を探して`, `적대적 검토`, `다관점 검토`, `여러 관점에서 검토`, `레드팀 검토`, `이 계획 반박`, `허점 찾아`, `对抗式评审`, `多视角评审`, `红队评审`, `反驳这个方案`, `找出漏洞`

Catalog Metadata

Category: `planning` Phase: `adversarial-consensus` Hermes role: `planner` Quality tier: `reviewed-plan-gated` Reasoning demand: `standard`

Quality bar:

• Name the roster before round one: 3-5 perspectives, each with a stated angle that no other seat covers. The suggested roster is skeptic, validator, researcher, architect, creative; substitute a domain seat when the problem needs one, but two seats arguing the same angle is a duplicate, not a perspective.
• Run the rounds in order — independent findings; cross-attack; defend, refine, or concede — and state which round is active in every message, because the independen