mcpField
B
best-of-n-solving

best-of-n-solving

github.com/spencerpaulyエージェントワークフロー868430 回インストール13 週間前に更新
リポジトリ

best-of-n-solving について

複雑な問題に対し、分離された Git worktree で異なる解決策を並行して試す Cursor スキルです。コーディングエージェントはテストや実装品質などの基準で結果を比較し、採用案を選べます。

主な機能

  1. 01異なる解決策の策定
  2. 02worktree での並行実行
  3. 03基準に沿った結果の比較
  4. 04選択した結果のマージまたは cherry-pick

活用シーン

  1. 01難しいバグの複数の修正案を検討
  2. 02リファクタリングや最適化手法の比較
  3. 03アーキテクチャの選択肢を並行評価

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/spencerpauly/awesome-cursor-skills --skill best-of-n-solving

インストール後、Claude Code で/best-of-n-solvingを入力して読み込まれたか確認します。

詳細

Best-of-N 問題解決

複数のアプローチが考えられる難しい問題に直面したときに、このスキルを使います。複雑なリファクタリング、厄介なバグ、パフォーマンスの最適化、またはどの戦略が最適か判断できないアーキテクチャ上の決定などが該当します。

仕組み

Cursor の best-of-n-runner サブエージェントタイプは、独立した Git ワークツリーを作成します。それぞれの試行に専用のブランチと作業ディレクトリが割り当てられます。複数のアプローチを互いに干渉させずに並行して実行できます。結果を比較して、最適なものを選びます。

手順

  1. アプローチを特定する — 起動する前に、異なる戦略を 2~3 個定義します。たとえば、遅いデータベースクエリを最適化する場合は、次のようにします。

    • アプローチ A:複合インデックスを追加してクエリを書き換える
    • アプローチ B:マテリアライズドビューを使ってスキーマを非正規化する
    • アプローチ C:Redis を使ってアプリケーションレベルのキャッシュを追加する
  2. ランナーを並行して起動する — Task ツールで、それぞれのアプローチに対して subagent_type: "best-of-n-runner" を使用します。すべてを 1 つのメッセージで起動し、並行して実行されるようにします。

    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: ..." }
    

    各ランナーには専用のブランチとワークツリーが割り当てられます。プロンプトには、明確な成功基準を含めてください(例:「テストを実行して、合格したか報告する」「クエリの実行時間を測定する」)。

  3. 結果を比較する — すべてのランナーが完了したら、次の点を評価します。

    • どのアプローチがすべてのテストに合格するか?
    • どの実装が最もすっきりしているか?
    • どのアプローチが最も優れたパフォーマンス特性を持つか?
    • 長期的に見て、どのアプローチが最も保守しやすいか?
  4. 最適なものをマージする — 最適なブランチに切り替えてマージするか、特定のコミットをチェリーピックします。ほかのワークツリーブランチはクリーンアップします。

どのような場合に使うか

  • 根本原因が複数考えられるバグ
  • パターン(例:コンポジションと継承)の選択を伴うリファクタリング
  • 複数の戦略が考えられるパフォーマンスの最適化
  • 同じ機能に対して、異なるライブラリやアプローチを試す場合
  • 分析するよりも「まず試してみる」ほうが速いあらゆる状況

メモ

  • 各ランナーは完全に独立しているため、互いの変更を参照できません。
  • プロンプトは具体的にしてください。ファイルパス、問題の説明、明確な成功基準を含めます。
  • より単純な問題では、これは過剰です。その場合は単一のエージェントを使ってください。
  • ブランチは実際の Git ブランチなので、必要に応じて手動で確認できます。

コメント