| name | best-of-n |
| description | Generate a small set of independent candidate solutions, judge them against one explicit rubric, and return the strongest verified result. |
| metadata | {"short-description":"Compare independent candidates"} |
Best of N
Use this skill when a consequential design, implementation, explanation, or
debugging task has several plausible solutions and comparison is worth the
extra model work. Do not use it for a tiny change or when the user has already
chosen the approach.
Set The Tournament
- Define one task, one evidence packet, and one explicit scoring rubric before
launching candidates. Include correctness, fit to the request, simplicity,
risk, and verification.
- Choose
N from 2 to 4. Default to 3. More candidates need a concrete reason.
- Give every candidate the same task and rubric. Add only a candidate number;
do not steer candidates toward different conclusions unless diversity is an
explicit part of the request.
Generate Independently
Start the candidates as parallel background agent workers. For proposals,
reviews, or research, keep them read-only:
{
"action": "start",
"name": "candidate_1",
"prompt": "Produce candidate 1 for the task below. Return the proposal, evidence, risks, and rubric self-score. Do not edit files.\n\n<TASK AND RUBRIC>",
"type": "general",
"model_strength": "same",
"write_authority": "read_only"
}
Launch the remaining candidates with the same contract, then use agent wait
or completion events to collect every result. Do not show one candidate another
candidate's answer before generation finishes.
When candidates must implement code, give each one worktree: true,
write_authority: "worktree_write", and the same bounded write_roots or
exact_files. Never run parallel writers in the parent checkout.
Judge Once
Use one read-only reviewer worker, or the parent when the result is small, to
score all candidates against the original rubric. The judge must:
- cite evidence from each candidate rather than vote by style;
- reject candidates that violate authority, scope, or verification gates;
- name the winner and the decisive reasons;
- identify useful pieces worth combining, if any;
- say when the candidates are tied or all fail.
Do not ask candidates to vote for themselves. Do not silently merge incompatible
approaches into a new unreviewed solution.
Integrate And Verify
For proposal-only work, return the winning answer with a compact score summary.
For code work, inspect the winning worktree diff, integrate it through the
normal parent workflow, and run the repository's real checks. Candidate
self-reports and judge scores are not final verification.
Stop early when one candidate reveals a hard constraint that invalidates the
tournament. Report the negative result rather than spending the remaining
budget to manufacture variety.