unified-review

統合レビューオーケストレーション

コードベースの分析とコンテキストに基づいて、適切なレビュースキルをインテリジェントに選択して実行します。

クイックスタート

# Auto-detect and run appropriate reviews
/full-review

# Focus on specific areas
/full-review api          # API surface review
/full-review architecture # Architecture review
/full-review bugs         # Bug hunting
/full-review tests        # Test suite review
/full-review all          # Run all applicable skills

検証： テストがパスすることを確認するには、pytest -v を実行します。

使用する場面

• コードレビュー全体を開始するとき
• 複数の領域にまたがる変更をレビューするとき
• レビュースキルをインテリジェントに選択する必要があるとき
• 複数のレビュータイプから統合レポートを作成したいとき
• 主要な機能ブランチをマージする前

使用しない場面

• レビュータイプが特定されている場合
  • bug-review を使用します
• Test-review
• アーキテクチャのみに焦点を当てる場合は、 architecture-review を使用します
• レビュータイプが特定されている場合
  • bug-review を使用します

レビュースキル選択マトリックス

コードベースのパターン	レビュースキル	トリガー
Rust ファイル（*.rs、Cargo.toml）	rust-review, bug-review, api-review	Rust プロジェクトを検出
API の変更（openapi.yaml、routes/）	api-review, architecture-review	パブリック API の対象範囲
テストファイル（test_*.py、*_test.go）	test-review, bug-review	テストインフラストラクチャ
Makefile／ビルドシステム	makefile-review, architecture-review	ビルドの複雑さ
数学的アルゴリズム	math-review, bug-review	数値計算
アーキテクチャ文書／ADR	architecture-review, api-review	システム設計
一般的なコード品質	bug-review, test-review	デフォルトのレビュー
実装後の監査	imbue:justify	追加／削除比率が高い場合、テストの変更、新しい抽象化

ワークフロー

1. リポジトリのコンテキストを分析する

• 拡張子とマニフェストから主要な言語を検出します
• git のステータスと差分を分析し、変更範囲を把握します
• プロジェクト構造（モノレポ、マイクロサービス、ライブラリ）を特定します
• ビルドシステム、テストフレームワーク、ドキュメントを検出します

2. レビュースキルを選択する

# Detection logic
if has_rust_files():
    schedule_skill("rust-review")
if has_api_changes():
    schedule_skill("api-review")
if has_test_files():
    schedule_skill("test-review")
if has_makefiles():
    schedule_skill("makefile-review")
if has_math_code():
    schedule_skill("math-review")
if has_architecture_changes():
    schedule_skill("architecture-review")
# Default
schedule_skill("bug-review")

検証： テストがパスすることを確認するには、pytest -v を実行します。

3. レビューを実行する

選択したスキルを Agent ツールで並列に呼び出します。 スキル名とエージェントの種類の対応は次のとおりです。

スキル名	エージェントの種類	備考
bug-review	pensive:code-reviewer	バグ、API、テストを対象とします
api-review	pensive:code-reviewer	同じエージェントで、API に重点を置きます
test-review	pensive:code-reviewer	同じエージェントで、テストに重点を置きます
architecture-review	pensive:architecture-reviewer	ADR への準拠を確認します
rust-review	pensive:rust-auditor	Rust 固有です
code-refinement	pensive:code-refiner	重複、品質を対象とします
math-review	general-purpose	プロンプト：Skill(pensive:math-review) を呼び出します
makefile-review	general-purpose	プロンプト：Skill(pensive:makefile-review) を呼び出します
shell-review	general-purpose	プロンプト：Skill(pensive:shell-review) を呼び出します

サブエージェントの分離（必須）。 ある観点が次の観点の読み方に影響してはなりません。分離する方法は 2 つありますが、2 つ目はユーザーが求めた場合にのみ実行します。

方法	分離を保つ方法
Agent ツール	選択したすべてのエージェントを 1 回の並列呼び出しで起動し、すべてのエージェントが返答するまで結果を読みません。最初の結果を読むと、その後の統合がその内容に引き寄せられ、後続の結果が独立して判断されなくなります。すべてを収集してから、一度だけ統合します
/pensive:unified-review ワークフロー（workflows/unified-review.js）	スクリプトが結果を保持します。スクリプトは推論主体ではないため、ある段階の結果を読む前に別の段階に影響されることはなく、各段階の間で結果を共有しても、誰かのコンテキストに入り込むことはありません。検証も、最も遅い観点を待たずに、各観点ごとに開始します

作業前に対象の観点が決まっており、各指摘に対して反証による確認が必要な場合は、ワークフローを優先します。担当エージェントを最初の観点の結果に応じて変更する必要がある場合、またはワークフローを依頼されていない場合は、Agent ツールを使用します。ワークフローが依頼なしに開始されることはありません。

サブエージェントは、セッションの権限モードにかかわらず acceptEdits で実行されるため、同梱スクリプトのプロンプトは読み取りに限定されています。また、ファイルシステムにはアクセスできないため、返されるのは反証を経て残った主張であり、作業の証拠ではありません。指摘に基づいて行動する前に、再現してください。

ルール：

• スキル名をエージェントの種類として使用しないでください（例：pensive:math-review はエージェントではありません）
• pensive:code-reviewer が複数の領域を担当する場合は、対象範囲をまとめて 1 回だけ呼び出してください
• 専用エージェントのないスキルには general-purpose を使用し、Skill ツールを呼び出すよう指示してください
• すべてのエージェントで、一貫した証拠の記録を維持してください
• TodoWrite で進捗を追跡してください

4. 指摘を統合する

• 各領域の指摘を統合します
• 領域を横断するパターンを特定します
• 影響度と作業量に基づいて優先順位を付けます
• 統一された対応計画を作成します

バックログ項目の遅延記録： バックログに振り分けられた指摘（今回のレビュー対象外、またはチームが対応を先送りしたもの）は、レビューを重ねる間に失われないよう保持してください。 バックログに割り当てた指摘ごとに、次を実行します。

python3 scripts/deferred_capture.py \
  --title "<finding title>" \
  --source review \
  --context "Review dimension: <dimension>. <finding description>"

<dimension> の値は、その指摘が見つかったレビュー用スキルと一致させてください（例：bug-review、api-review、architecture-review）。 これは対応計画の確定後、ユーザーへの確認なしで自動的に実行されます。

レビューモード

自動検出（デフォルト）

コードベースの分析に基づき、スキルを自動的に選択します。

集中モード

特定のレビュー領域を実行します。

• /full-review api → api-review のみ
• /full-review architecture → architecture-review のみ
• /full-review bugs → bug-review のみ
• /full-review tests → test-review のみ

フルレビューモード

該当するレビュー用スキルをすべて実行します。

• /full-review all → 検出されたスキルをすべて実行

品質ゲート

各レビューでは、次を実施する必要があります。

1. 適切なコンテキストを確立する
2. 選択したスキルをすべて正常に実行する
3. 証拠とともに指摘を記録する
4. 影響度に基づいて推奨事項の優先順位を付ける
5. 担当者を明記した対応計画を作成する

成果物

エグゼクティブサマリー

• コードベース全体の健全性評価
• 早急な対応が必要な重大な問題
• レビュー頻度に関する推奨事項

ドメイン別レポート

• API サーフェスの分析と一貫性
• ADR とのアーキテクチャの整合性
• テストカバレッジの不足と改善策
• バグ分析とセキュリティ上の調査結果
• パフォーマンスと保守性に関する推奨事項

統合アクションプラン

• 優先順位を付けた修正タスク
• ドメイン間の依存関係
• 担当者と目標日
• フォローアップレビューのスケジュール

モジュール型アーキテクチャ

すべてのレビュー スキルは、段階的に読み込むハブ＆スポーク型アーキテクチャを採用しています。

• 各スキルに modules/ があります：ドメイン固有の詳細を必要に応じて読み込みます
• プラグイン間の依存関係：imbue:proof-of-work、imbue:diff-analysis/modules/risk-assessment-framework

これにより、機能を損なうことなく、対象を絞ったレビューでのトークン使用量を50～70％削減できます。

終了基準

• 選択したすべてのレビュースキルを実行済みである
• 調査結果を集約し、優先順位を付けている
• 担当者を明記したアクションプランを作成している
• 構造化された出力形式に従って証拠を記録している

補助モジュール

• レビュー ワークフローのコア - すべての pensive レビューに共通する標準的な5段階のワークフローパターン
• 出力形式のテンプレート - 指摘事項、重大度、アクション項目のテンプレート
• 品質チェックリストのパターン - レビュー前、分析、証拠、成果物のチェックリスト

トラブルシューティング

よくある問題

自動検出で適切なレビュースキルを特定できない場合は、モードを明示的に指定してください（例：/full-review だけでなく /full-review rust を指定します）。統合に失敗する場合は、TodoWrite のログにアクセスできること、および各スキルによって証拠ファイルが正しく書き込まれていることを確認してください。