showdown
Showdown
A showdown pits contenders (skills, prompts, agent setups) against identical briefs and lets blind judges score them round by round. The contender is the only variable: model, effort, seed, context, tools and time stay equal. The result is an observed outcome for this sample, never a ranking.
Run it on Team Up's Swarm: its coverage shape for the audit and its race shape with a declared rank all rule for the fight, where Showdown's blind judges produce the ranking. Choose judges through Team Up's selection policy. Showdown's own rubric, judging contract and report replace Swarm's aggregation and in-chat report. Team Up owns roles, models, effort and dispatch; Showdown owns the card, the evidence and the verdict.
Work in a scratch folder. The subject project stays untouched: contenders refine copies. Recommendations the user put out of scope stay out of every brief and the report.
1. Audit the contenders
Read every instruction file of every contender before designing a round: entry file, every reference, manifests, and a listing of scripts and binaries with what they enforce. A skim produces wrong scores; an earlier verdict that missed a bundled mode is exactly the failure this step prevents. Record composition: when a contender bundles another source, its manifest names it, and that mode competes as that source.
When the reading is large, split it as a Swarm coverage run, one slice per contender or file group. Each shard reads one file at a time with a file-read tool or in chunks of at most 200 lines, and writes a rule inventory: a ledger of every file with its line count and the lines read, rules per round with path:LINE, refusals and scope limits, and process obligations. Batched shell dumps truncate silently. Under Swarm's aggregation, a shard that cannot confirm every line is respawned once; a second miss is a gap you close yourself before scoring.
Done when every file of every contender appears in a ledger as read to its last line.