omh-adversarial-consensus
[omh] Hermes Adversarial Consensus workflow: 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.
Оригинален текст · няма потвърден превод на българскиПърво прочетете инструкцията.
Файлът се зарежда от посочения източник само по ваше действие. Можете да го прочетете тук, да го копирате или да го запазите като .md.
GitHub хранилище- Звезди на репото
- 2881
- Лиценз
- MIT
- Последна проверка на записа
- 22.09.2026 г.
Добавете в своя инструмент.
Командата отваря избора на skills от репозитория. Прочетете файла и условията на автора преди изпълнение.
npx skills add rlaope/oh-my-hermesСтраницата копира текст. Не инсталира и не изпълнява нищо на устройството ви.
Откъс от SKILL.md
Началото на файла на автора, без превод.
Adversarial Consensus
This is an OMH adversarial-consensus workflow skill, projected for Agent Skills hosts (Claude Code, Codex, Cursor, opencode, OpenClaw, pi).
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
ulw-plan, which this workflow feeds. - The request is still too ambiguous to state the proposal being attacked; use
ulw-interviewfirst. - The user wants completed code reviewed for defects rather than a proposal attacked before it is built; use
omh-code-review. - The user wants hostile runtime scenarios against a built change; use
ulw-qa. - 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
ralplanas 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.