CoriChui/bakeoff

bakeoff

When your agent uses it

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.

What it loads into context

Token counts are estimates. Scripts run separately; they are not counted as reference context.

# 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.