/bakeoff

name: bakeoff
argument-hint: "<request — a decision, idea, comparison, or 'what if'>"
description: >
  Turn one decision into a judged tournament of solutions, then pick the best. Given a problem,
  design choice, or a suggestion you want cross-verified, it generates diverse candidate solutions,
  auto-derives the evaluation dimensions for THAT problem (so you don't have to know what to score
  on), judges every candidate with independent scorers, and returns the winner plus a ranked top-N
  shortlist with a score matrix and rationale. It auto-infers the request shape — idea · improvement ·
  comparison · proposal ("what if we do X") · problem-solving · scoping — from your bare prompt, with
  no flags. Reach for it whenever there are several defensible
  approaches, the call is costly to reverse, and you can't easily say why one option wins — even if
  the user doesn't say "compare" or "decide": "what's the best way to structure X", "which
  approach/library/database/design should I pick", "compare these two plans", "is the AI's
  suggestion actually good, or is there something better", "help me decide X vs Y vs Z",
  architecture / approach / refactor / migration / tool-selection calls, or any stakes-bearing
  "which should I…". Distinct from `evaluate` (which scores ONE artifact against a rubric) — reach
  for bakeoff when you need to CHOOSE among several options or generate them. NOT for tasks a
  test, type-check, or lint settles (bug fixes, mechanical refactors, formatting, "write a function
  that does X"), and NOT for evaluating a single existing thing with no alternatives (that's
  `evaluate`) — a tournament of one is wasted effort.

Bakeoff

You turn *"which of these should I do?"* into a defensible answer. You **generate** diverse candidate solutions, **auto-derive** the criteria that matter for this specific problem, **judge** the candidates independently, and **select** the winner (plus a top-N shortlist) — with the reason each one won or lost.

Two problems this solves at once: you stop hand-running the role-agents/judges/synthesis loop, and you stop having to know the evaluation dimensions yourself — the rubric is built for *this* problem, grounded in real facts when the decision needs it (see *Grounding*), not a generic checklist.

When to use it (all three must hold)

1. **Wide solution space** — several genuinely defensible approaches, not one obvious answer. 2. **Costly to reverse** — a wrong call is expensive to unwind. 3. **Unclear criteria** — you can't easily say *why* one option beats another.

If a test, type-check, or lint settles it, don't run a tournament — answer directly.

**Any request *shape* qualifies** — a comparison ("X vs Y"), an improvement ("best way to X"), an idea ("what should we build"), a proposal ("what if we do X / should we add X"), a problem ("how do we handle this"), or a scoping call ("minimal X before launch"). You infer the shape (Step 1); the user need not phrase it as a "decision." **The three-part gate above still governs** — broaden what you *recognize*, never lower *when to fire* (a low-stakes or single-obvious-answer "which/how" is still a direct answer, not a tournament).

**Rationalizations (when you're tempted to skip it).** These are the excuses that precede a bad, hard-to-reverse call — each is a reason to *run* the tournament, not skip it:

| The excuse | The reality | |-----------|-------------| | "I already know the best option." | Then a `--lean` run confirms it cheaply — and if it doesn't, you just dodged a costly wrong call. Confidence isn't evidence. | | "Just pick the popular / default one." | Popularity isn't fit *for this problem*; the auto-derived rubric tests fit, and the adversarial pass catches the case where the obvious pick is actually wrong (see the worked example — both judges picked the runner-up). | | "Generating rivals is wasted effort." | Diversity is the lever selection exploits; one option iterated is exactly the mush this avoids. | | "There's no time." | `--lean` is ~3 candidates / 1 judge / minutes. The wrong architecture, library, or migration costs far more than one lean run. |

Design principles (why it's built this way)

• **Select, then graft.** Diverse candidates + judge-based *selection* is the core — it exploits

variance a naive average would waste. But synthesis is a *first-class* follow-up, not a grudging afterthought: when the top two are strong on *different* dimensions, graft the runner-up's best element into the winner and keep it **only if it re-scores above the best single candidate** (the guard). In practice the graft wins or sharpens the pick as often as it's discarded.

• **Diversity is the biggest lever.** Candidate generators get **distinct, problem-specific roles**;

a homogeneous set of candidates makes the whole exercise pointless.

• **Independent judges, mechanically reconciled** — not a free debate (debate can amplify bias).

Two judges score independently; scores are merged by the deterministic reconciler.

• **Kill position bias** — each judge sees the candidates in a different shuffled order, referenced

by stable IDs (mechanics in Step 4).

• **Adversarially verify the leader** — before committing, one agent actively tries to *refute* the

top candidate. A plausible-but-wrong winner should not survive.

Grounding (conditional, silent)

A tournament is only as good as the facts under it. **When the decision depends on reality, ground it — silently, with whatever fitting read-only tools this environment offers.** Use what's available; don't hard-code tool names, and reach for `ToolSearch` if a needed capability looks deferred:

• **External facts** — a library / tool / version, or current best practice → a live web or

docs-search tool.

• **This codebase** — "how should *we*…", "refactor *our*…" → read the actual files + whatever project

search exists; else `grep`/read directly. In a repo, **default to reading the code** — the decisive fact (a si