review-merge-readiness

コードレビューの依頼（構造化レビュー：要件との整合性＋本番環境への準備状況）

目標：コードレビューをランダムなコメントではなく、再現可能なプロセスにします。

基本原則：早めに、頻繁にレビューします。

レビューが必須となるタイミング

必須：

• 重要な機能を完了した後
• workflow-execute-plans の各バッチが終了した後（デフォルトでは1バッチあたり3タスク）
• main ブランチにマージする前

任意ですが有用：

• 行き詰まったとき（新たな視点を得るため）
• 大規模なリファクタリングの前（まずベースラインを確立するため）
• 複雑なバグの修正後（新たなリグレッションがないことを確認するため）

開始方法（最低限必要な情報）

1) レビュー範囲を決める（git SHA）

BASE_SHA には、「計画／タスクを開始する前のベースライン」を使用することを推奨します。

# Common approach: use main as baseline
BASE_SHA=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD master)
HEAD_SHA=$(git rev-parse HEAD)

小規模なタスクで直近のコミットだけをレビューする場合：

BASE_SHA=$(git rev-parse HEAD~1)
HEAD_SHA=$(git rev-parse HEAD)

2) レビューの根拠を準備する（計画／要件）

レビューには次の情報が必要です。

• WHAT_WAS_IMPLEMENTED：今回完了した内容（箇条書きで1～3項目）
• PLAN_OR_REQUIREMENTS：該当する計画の抜粋、または要件ドキュメントのパス（例：run_dir/03-plans/features/<feature_slug>-plan.md）

3) diff を取得する（根拠）

git diff --stat "$BASE_SHA..$HEAD_SHA"
git diff "$BASE_SHA..$HEAD_SHA"

レビューの実施方法（いずれかを選択）

方法 A：サブエージェントによるレビュー（システムがサポートしている場合）

テンプレート review-merge-readiness/code-reviewer.md を使用し、プレースホルダーを入力して実行します。

方法 B：セルフレビュー（サブエージェントなしで実施可能）

テンプレートのチェックリストに沿って各項目を確認し、同じ構造の結果（強み＋重要度別の問題点＋判定）を出力します。

レビュー結果の形式（構造化必須）

結果には次の項目を含める必要があります。

• Strengths：具体的な長所（1つ以上）
• Issues：重要度別に分類します。
  • Critical (Must Fix)：セキュリティ／データ損失／機能上のバグ／本番環境のインシデントにつながる問題
  • Important (Should Fix)：明らかに不適切なアーキテクチャ／エラーハンドリングの欠如／テスト不足／要件との不整合
  • Minor (Nice to Have)：スタイル／小規模な最適化／ドキュメントの改善
• Assessment：マージ可能かどうか（可能／不可／修正後に可能）＋技術的な根拠を1～2文

各 Issue には次の内容を含める必要があります。

• 場所：file:line
• 問題の内容
• 重要である理由
• 修正方法（最小限の変更案を提示）

他のレビュースキルとの関係

• review-clean-code：主に「保守性／コードのクリーンさ」に焦点を当てており、コードの不自然な点を深く調査するのに適しています。
• review-react-best-practices：主に React/Next.js のパフォーマンスパターン（ウォーターフォール／バンドル／再レンダリング）に焦点を当てています。diff が React UI、データ取得、またはパフォーマンスに影響しやすい箇所に関わる場合に使用します。
• このスキル：主に「要件との整合性／本番環境への準備状況／マージの判定」に焦点を当てた、結論重視のレビューです。

「マージできるか」という判定だけが必要な場合は、このスキルを使用します。 コードの健全性を深く確認したい場合は、review-clean-code も併せて使用します。