A domain-neutral Agent Skill that creates or evaluates independent candidates, pressure-tests each one, and uses blind rubric-based judging to select the strongest option.
- architecture and implementation proposals
- product, UX, and process designs
- research plans and written deliverables
- tool, library, service, or vendor comparisons
- migration, operations, and project strategies
- any substantial best-of-N decision with comparable artifacts
Skip it for factual lookups, trivial preferences, or decisions where the evidence is too incomplete to judge responsibly.
| 1. Prepare | 2. Compete | 3. Decide |
|---|---|---|
| Freeze one brief, rubric, and evidence policy | Build or normalize isolated candidates, then review each equally | Remove team identities, score against the frozen rubric, and publish the audit trail |
git clone https://github.com/alextverdyy/tournament-judge.git tournament-judge
mkdir -p .claude/skills
cp -R tournament-judge .claude/skills/tournament-judgeThis example uses Claude Code. Codex, OpenCode, Cursor, Prime Agent, and global install paths are listed in the setup guide.
Then ask:
Use tournament-judge to produce three independent approaches for this task. Freeze a rubric first, review each approach twice, judge anonymized finalists, and return the winner with the full scorecard.
Your agent may auto-load the skill from its description. You can also explicitly ask it to read tournament-judge/SKILL.md.
flowchart LR
accTitle: Tournament workflow
accDescr: A frozen brief feeds three isolated candidates. Each receives adversarial review before anonymization, blind judging, and a final report.
B["Frozen brief<br/>and rubric"] --> A[Candidate A]
B --> C[Candidate B]
B --> D[Candidate C]
A --> R1[Adversarial review]
C --> R2[Adversarial review]
D --> R3[Adversarial review]
R1 --> X[Anonymize]
R2 --> X
R3 --> X
X --> J[Blind judge]
J --> W[Winner and report]
classDef brief fill:#172554,stroke:#38bdf8,color:#fff;
classDef candidate fill:#312e81,stroke:#a78bfa,color:#fff;
classDef review fill:#064e3b,stroke:#34d399,color:#fff;
classDef judge fill:#0f172a,stroke:#f472b6,color:#fff;
classDef winner fill:#78350f,stroke:#fbbf24,color:#fff;
class B brief;
class A,C,D candidate;
class R1,R2,R3 review;
class X,J judge;
class W winner;
| Path | Purpose |
|---|---|
SKILL.md |
Skill entry point and invariant rules |
modules/ |
Intake, rubric, orchestration, judging, and reporting procedures |
prompts/ |
Candidate, reviewer, and judge role prompts |
templates/ |
Brief, candidate dossier, rubric, and final report forms |
docs/ |
Setup, usage, modules, and companion-skill guides |
examples/ |
Ready-to-copy tournament requests |
assets/ |
Accessible SVG identity and workflow illustrations |
- Installation and setup
- How to use it
- Modules and customization
- Recommended companion skills
- Example requests
- Rubrics are fixed before candidate generation.
- Candidates receive equal inputs and review budgets.
- Teams remain isolated before judging.
- Judges see anonymized finalists, not debate performance.
- Hard-constraint failures remain visible.
- Scores include reasons and evidence gaps.
- A final report explains why the winner won and why the others lost.
These guarantees are procedural, not magical. A single-context runtime cannot provide perfect independence, and anonymization cannot remove authorship clues intrinsic to an artifact. The report must disclose those limitations.
MIT