使用方法
- 复制安装命令,在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物,并对照来源检查输出。
npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill best-of-n-solving开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况,不等于独立质量或安全测试。
按源仓库内容呈现,保留标题、案例、代码、表格、链接以及原文引用的演示图片。
Best-of-N Problem Solving
Use this skill when facing a hard problem with multiple possible approaches — complex refactors, tricky bugs, performance optimization, or architectural decisions where you're not sure which strategy will work best.
How It Works
Cursor's best-of-n-runner subagent type creates isolated git worktrees — each attempt gets its own branch and working directory. Multiple approaches run in parallel without interfering with each other. You compare the results and pick the winner.
Steps
- Identify the approaches — before launching, define 2-3 distinct strategies. For example, if optimizing a slow database query:
- Approach A: Add a composite index and rewrite the query
- Approach B: Denormalize the schema with a materialized view
- Approach C: Add application-level caching with Redis
- Launch parallel runners — use the Task tool with
subagent_type: "best-of-n-runner"for each approach. Launch them all in a single message so they run concurrently:
Task 1: { subagent_type: "best-of-n-runner", prompt: "Approach A: ..." }
Task 2: { subagent_type: "best-of-n-runner", prompt: "Approach B: ..." }
Task 3: { subagent_type: "best-of-n-runner", prompt: "Approach C: ..." }Each runner gets its own branch and worktree. Include clear success criteria in the prompt (e.g., "run the tests and report if they pass", "measure the query time").
- Compare results — when all runners complete, evaluate:
- Which approach passes all tests?
- Which has the cleanest implementation?
- Which has the best performance characteristics?
- Which is easiest to maintain long-term?
- Merge the winner — check out the winning branch and merge it, or cherry-pick specific commits. Clean up the other worktree branches.
When to Use This
- A bug that could have multiple root causes
- A refactor where you're choosing between patterns (e.g., composition vs. inheritance)
- Performance optimization with multiple strategies
- Trying different libraries or approaches for the same feature
- Any situation where "just try it" is faster than analyzing
Notes
- Each runner is fully isolated — they can't see each other's changes.
- Keep prompts specific: include the file paths, the problem statement, and clear success criteria.
- For simpler problems, this is overkill — just use a single agent.
- The branches are real git branches, so you can inspect them manually if needed.



