mcpField
T
total-review

total-review

github.com/davidondrejテスト・品質4.2k47 回インストール今日更新
リポジトリ

total-review について

5つの指定モデルを別々のCloudroomスレッドで動かし、コードレビュー結果をまとめるスキルです。詳細なレビュー向けで、全レビュー担当者の利用可能性とフル権限モードが必要です。

主な機能

  1. 015つのレビューを並列実行
  2. 02モデルと推論レベルの固定
  3. 03フル権限での実行
  4. 04各担当への独立した依頼
  5. 05問題の重複排除と集約

活用シーン

  1. 01マージ前のコード変更レビュー
  2. 02複数レビュー担当者の指摘比較
  3. 03統合された不具合一覧の作成

インストール

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

$npx skills add https://github.com/davidondrej/skills --skill total-review

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

同梱ファイルagents/openai.yaml

詳細

Total Review

Anthropic と OpenAI の最も優れた 2 つのモデルに加え、Meta の Muse Wonder を含む 5 人のレビュアーを、それぞれ別の Cloudroom スレッドで実行します。全員、最高の推論レベルとフル権限モード（ハーネスの最大権限）を使用します。モデル、推論レベル、権限モードを入れ替えたり、下げたりしないでください。いずれかが利用できない場合は、停止してユーザーに伝えてください。

権限

必ず --permission-mode full を指定して起動してください。これは Claude Code の権限バイパス（--dangerously-skip-permissions）と、Codex の YOLO モード（承認なし、danger-full-access サンドボックス）に相当します。子スレッドの権限は親スレッドを超えられないため、このスレッドがフルモードでない場合は停止してユーザーに伝えてください。

レビュアー

  • Fable 5.1: --provider claude-code --model claude-fable-5-1
  • Opus 5.5 (1M): --provider claude-code --model 'claude-opus-5-5[1m]'
  • GPT-6 Astra: --provider codex --model gpt-6-astra
  • GPT-6.1 Sol: --provider codex --model gpt-6.1-sol
  • Muse Wonder: --provider pi --model openrouter/meta/muse-wonder（Pi ハーネス、OpenRouter）。Muse で max を利用できるのは OpenRouter のみです。vercel-ai-gateway 経由では絶対に使用しないでください。

1. 起動

  1. 各モデルの supportedReasoningEfforts に max が含まれていることを、room-cli provider models claude-code --json、room-cli provider models codex --json、room-cli provider models pi --json で確認します。
  2. 5 つすべてを並列に、それぞれ 1 つのスレッドで、レビュアーフラグに加えて --reasoning-level max --permission-mode full --title "Total review: <model>" を指定して起動します。
    • ローカルスレッド: room-cli thread spawn --parent-self --project "<project ID>" --environment <env ID from room-cli status --json>
    • クラウドスレッド: cloudroom thread spawn（cloudroom thread --help を参照）。
    • フォールバックのみ: bb thread spawn（/bb-cli を参照）。
  3. thread show で、各スレッドが正しいモデルを指定の推論レベルと full 権限モードで実行していることを確認します。

2. 依頼内容

5 人全員に同じ中立的な依頼を送ります。対象範囲、パス、意図する動作、差分／ベースリビジョンを伝えてください。

関連コードとテストも含めて、シニア開発者として徹底的にレビューするよう依頼します。レビューのみを行い、ファイルは変更しないでください。重大または深刻な問題について、ファイルと行番号、修正案、マージ可否を報告するよう依頼します。検証済みの指摘と推測は分けてください。平易な英語で報告するよう依頼します。

疑わしいバグをほのめかしたり、他のレビュアーに言及したり、あるレビュアーの出力を別のレビュアーと共有したりしないでください。

3. 収集

各スレッドで thread wait を実行してから、thread output を実行します。アイドル状態、タイムアウト、キューに入った再試行は完了ではありません。レビューに失敗したレビュアーがいれば報告してください。部分的な出力をレビュー結果として提示してはいけません。

4. 統合と報告

5 件すべての報告を全文読みます。重複を除きます。実際のバグとリスクだけを残し、スタイル上の好み、理論上のエッジケース、問題ではないものは除外します。複数のレビュアーが同意しているからといって、問題が実在するとは限りません。

ユーザーには次の内容を提示します。

  • 各問題について、内容と場所を 1 行で示した番号付きリスト。
  • 発見者を示すタグ [fable]、[opus]、[astra]、[sol]、[muse]。報告数が多い順に並べます。
  • 除外した指摘の数を 1 行で示します。
  • 「この修正を承認しますか。それともリストを調整しますか？」と尋ねます。

全文の報告は、ユーザーから求められた場合に限り共有します。

5. 修正して出荷

ユーザーの承認後に限り、承認された問題を修正してから、標準の出荷ワークフローでコミットとプッシュを行います。

コメント

Markdown 対応