사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill best-of-n-solving시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
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.
