mcpField
C
cross-critique

cross-critique

github.com/warpdotdevエージェントワークフロー63621.9k 回インストール1 週間前に更新
リポジトリ

cross-critique について

複数のサブエージェントが出した独立案を相互に批評させるスキルです。論点のある判断を統合する前に、前提やトレードオフ、失敗要因を洗い出します。

主な機能

  1. 01提案を回覧して相互批評
  2. 02各案の長所と短所を収集
  3. 03提案者に見直しの有無を確認
  4. 04批評を踏まえて案を順位付け

活用シーン

  1. 01異なるアーキテクチャ案の比較
  2. 02意見が分かれたコードレビューの検討
  3. 03競合する根本原因の仮説評価

インストール

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

$npx skills add https://github.com/warpdotdev/common-skills --skill cross-critique

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

詳細

クロス批評

複数のサブエージェントが、同じ意見の分かれる問いについて独立して提案や見解を出した後に、第 2 ラウンドを行うためのスキルです。自分で各レポートを統合するのではなく、各提案をほかの執筆者に回して、長所と短所を批評してもらい、その結果得られた、より豊かな分析を統合します。

重要な理由

独立した提案(異なるモデル、異なる視点)を作成すると、各執筆者はその問いについて深い背景知識を得ます。調査を行った執筆者のほうが、あなたより詳しいこともよくあります。レポートだけをすぐに統合しようとすると、あなたがボトルネックになり、自分が気づいたトレードオフしか確認できません。

執筆者同士に批評を依頼するのは、助言を求めるときの優れたリーダーのやり方です。異なる視点を持つ人を集め、互いの論拠の穴を指摘してもらうことで、どの一人にも、あなた自身にも生み出せないほど、はるかに全体像を把握できます。執筆者は、あなたも元の提案者も指摘していなかった失敗モード、隠れた前提、トレードオフを明らかにしてくれます。

使用するタイミング

判断が意見の分かれるもの、つまり独立したエージェントが実質的に異なる提案を出した場合や、妥当なアプローチが複数あるほど主観的な場合に、クロス批評を使います。適している例:

  • アーキテクチャや設計のトレードオフ。
  • レビュアーの結論が分かれたコードレビュー。
  • バグの根本原因に関する競合する仮説。
  • 唯一の正解がないコード構造や API の形状に関する判断。

提案がすでにほぼ一致している場合や、直接検証できる客観的な答えがある場合は、使う必要はありません。批評には時間とトークンがかかり、その価値は本質的な意見の違いを解消することにあります。この範囲内であれば、気兼ねなく使ってください。深刻な問題である必要はなく、解決する価値のある実質的な相違があれば十分です。

前提条件:まず独立した提案が必要です

このスキルは第 2 ラウンドです。すでに N 件の独立した提案があることを前提としています。まだない場合は、次の方法で用意します。

  • 判断を重視する問いには、council スキルを使って作成します(同じ問いに対する、モデルの異なるサブエージェント)。
  • 調査を重視する問いには、並列のサブエージェントを起動して作成します(research スキルを参照)。
  • または、すでに集めた独立したサブエージェントの提案を任意の方法で使います。

重要なのは、第 1 ラウンドを独立して行うことです。第 1 ラウンド中に執筆者同士の成果を見せないでください。そうしないと、第 2 ラウンドを有益なものにする多様性が損なわれます。

実施方法

1. 提案を集める

各執筆者の提案を集めます。全文ではなく、中心となる推奨事項とその根拠に絞り、簡潔にまとめます。提案 A、B、C のように中立的なラベルを付け、可能であれば執筆者を匿名にすると、最も自信に満ちた表現をしたモデルに流されるバイアスを減らせます。

2. 提案を回覧し、構成に沿った批評を依頼する

第 1 ラウンドと同じサブエージェントを再利用し、新しいものを起動しないでください。同じサブエージェントなら、背景知識を保ったまま、内容を理解したうえで批評できます。各執筆者には、自分以外の提案を送り、次の点を尋ねます。

  • 各代替案について、長所(正しい点、自分のアプローチより優れている点)と短所(リスク、境界事例、隠れたコスト、誤った前提)。
  • 代替案を見たうえで、自分の推奨事項を変更するかどうか、またその理由。
  • 最終的な順位または推奨事項と、確信度。

各代替案について、長所と短所の両方を必ず挙げるよう求めてください。競合する案の長所も認める誠実な批評は、自分の提案を反射的に擁護するよりも、はるかに有益です。

3. 統合する

ここで、自分で全体をまとめます。投票数ではなく、根拠の質に基づいて批評を比較してください。最終回答では、次の点を盛り込んでください。

  • 推奨案を最初に示します。
  • 互いの成果を確認した後に、著者同士の見解がどこで一致したかを記します。第2ラウンドでの意見の一致は、強い判断材料になります。
  • 各選択肢に対して挙げられた、最も鋭い短所を明らかにします。
  • 推奨案が、判断基準に照らした批評に最も耐える理由を説明します。
  • 残る意見の相違、確信度、重要な未確認事項を挙げます。

最終回答のテンプレート

タスクの内容に応じて別の形式が適切な場合を除き、次の形式を使用してください。

## Recommendation
[One or two sentences with the decision.]

## How the critiques shifted things
- [Where authors converged or changed their minds after seeing alternatives]
- [The strongest objection raised, and whether it's decisive]

## Why this option wins
- [Reason grounded in the critiques]

## Remaining risks and unknowns
- [Open question or caveat]

実務上の注意

  • 元のタスクで変更が明示的に求められている場合を除き、批評ラウンドでは読み取り専用を維持してください。
  • ユーザーから求められない限り、ユーザー向けの要約で内部サブエージェント ID を明かさないでください。
  • 批評が不十分、または裏付けが弱い場合は、その著者に対象を絞った追加質問を送り、単に却下しないでください。

コメント