best-of-n
Generate a small set of independent candidate solutions, judge them against one explicit rubric, and return the strongest verified result.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Generate a small set of independent candidate solutions, judge them against one explicit rubric, and return the strongest verified result.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Structured code review for bugs, regressions, tests, and standards. Use before PRs or when asked for review; report-only by default, with explicit local apply available for user-directed fix workflows.
Document a recently solved problem as a durable repo learning, or capture project vocabulary in CONCEPTS.md. Use when capturing a learning after work.
Sweep configured feedback sources (Slack, GitHub Issues; email experimental) for new items: acknowledge at source, analyze recordings, verify fixes merged to main, and emit an `lfg`-ready plan. First run sets up sources; supports mode:headless for scheduled runs.
Multi-perspective academic paper review with dynamic reviewer personas. Simulates 5 independent reviewers (EIC + 3 peer reviewers + Devil's Advocate) with field-specific expertise. Supports full review, re-review (verification), quick assessment, methodology focus, Socratic guided, and calibration modes. Triggers on: review paper, peer review, manuscript review, referee report, review my paper, critique paper, simulate review, editorial review, calibrate reviewer, reviewer calibration, measure reviewer accuracy, 審查論文, 論文審查, 模擬審查, 同儕審查, 幫我審這篇, 以審查人角度評估, 審查者校準, 논문 심사, 동료 심사, 모의 심사, 심사자 관점에서 평가, 심사자 보정.
Read-only correctness review with actionable findings first, tight file/line evidence, severity, and a concise residual-risk summary.
Exercise the real app/API/CLI and collect observable evidence; tests alone do not count as end-to-end verification.
| 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"} |
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.
N from 2 to 4. Default to 3. More candidates need a concrete reason.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.
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:
Do not ask candidates to vote for themselves. Do not silently merge incompatible approaches into a new unreviewed solution.
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.