Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add CoriChui/bakeoff --skill bakeoffgit clone --depth 1 https://github.com/CoriChui/bakeoffWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/corichui/bakeoff/bakeoff)<a href="https://agentmods.dev/skills/corichui/bakeoff/bakeoff"><img src="https://agentmods.dev/badge/skills/corichui/bakeoff/bakeoff/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/corichui/bakeoff/bakeoff"><img src="https://agentmods.dev/badge/skills/corichui/bakeoff/bakeoff.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00330 | $0.08063 |
| Opus 5.5 | $0.00132 | $0.03225 |
| Sonnet 5.5 | $0.00066 | $0.01613 |
| Haiku 4.5 | $0.00033 | $0.00806 |
Grade A, and why
bakeoff scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 454 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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)
- Wide solution space — several genuinely defensible approaches, not one obvious answer.
- Costly to reverse — a wrong call is expensive to unwind.
- 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. |
What ships with it
5 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 454 lines · 330 tokens per session scan A bd7c1f116f07
bakeoff is a skill published in the GitHub repository CoriChui/bakeoff (10 stars, last pushed 3mo ago), licensed MIT. It adds 330 tokens to every session and 8,063 once invoked, about $0.0013 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
yolo-brief
Use to record a new feature in a YOLO repo, or to cancel one. Writes workspace/features/ /brief.md with a goal and checkable success criteria, taken from an approved design spec when one exists. Triggers on "track this as a feature", "write a brief for X", "track it from that spec", "yolo brief", "cancel the X…
yolo-next
Use when the user asks what to work on next, what to pick up, or what to prioritize in a YOLO repo. Ranks the backlog from derived status, dependencies, stalled work, open issues and code TODOs, and recommends the top 3 with reasons. Read-only. Triggers on "what next", "what should I work on", "what should I pick up"…
yolo-status
Use when the user asks where things stand, what's in progress, what's landed, or "where was I" in a YOLO repo. Derives every feature's status from git and the briefs; nothing is read from a stored status field.
yolo-verify
Use to check a feature branch against its brief's successcriteria and record the result. Writes verification.md and, on a full pass, commits it with the YOLO-Verified trailer. Triggers on "verify this feature", "does it meet the criteria", "yolo verify".
yolo-init
Use when setting up YOLO in a repo for the first time, or repairing the setup. Creates workspace/features/ and workspace/config.yaml. Triggers on "set up YOLO here", "init yolo", "yolo init".
premortem
A short premortem planning session that asks what could make a plan fail before work begins. It examines a plan from several viewpoints, suggests responses, and records the discussion in the project documentation.