Code Reviewer

このスキルは、ローカル開発とリモート Pull Request の両方に対して、プロフェッショナルで徹底的なコードレビューを実施するよう agent をガイドします。

Workflow

1. レビュー対象の決定

• リモート PR: ユーザーが PR 番号または URL (例: "Review PR #123") を提供した場合、そのリモート PR を対象にします。
• ローカル変更: 特定の PR が指定されていない場合、またはユーザーが「my changes をレビューして」と要求した場合、現在のローカルファイルシステムの状態 (staged および unstaged 変更) を対象にします。

2. 準備

リモート PR の場合:

1. Checkout: GitHub CLI を使用して PR をチェックアウトします。

   gh pr checkout <PR_NUMBER>
   

2. Preflight: プロジェクトの標準検証スイートを実行して、自動化された失敗を早期に検出します。

   npm run preflight
   

3. Context: PR の説明と既存のコメントを読んで、目的と履歴を理解します。

ローカル変更の場合:

1. 変更内容の確認:
   • ステータス確認: git status
   • diff の確認: git diff (working tree) および/または git diff --staged (staged)。
2. Preflight (オプション): 変更が大幅である場合、レビュー前に npm run preflight を実行したいかユーザーに確認します。

3. 深掘り分析

以下の柱に基づいてコード変更を分析します:

• 正確性: コードは、バグや論理エラーなしに、その目的を達成しているか?
• 保守性: コードはクリーンで、よく構成され、将来的に理解しやすく、修正しやすいか? コードの明確性、モジュール性、確立された設計パターンへの準拠などの要因を考慮してください。
• 可読性: コードはよくコメントされており (必要な場合)、プロジェクトのコーディングスタイルガイドラインに従ってフォーマットされているか?
• 効率性: 明らかなパフォーマンスのボトルネックまたは変更によって導入されたリソースの非効率性はないか?
• セキュリティ: 潜在的なセキュリティ脆弱性またはセキュアでないコーディング慣行はないか?
• エッジケースとエラーハンドリング: コードはエッジケースと潜在的なエラーを適切に処理しているか?
• テスト可能性: 新しい、または変更されたコードは、テストで適切にカバーされているか (preflight チェックが成功した場合でも)? カバレッジまたはロバスト性を向上させるであろう追加のテストケースを提案してください。

4. フィードバックの提供

構成

• Summary: レビューの高レベル概要。
• Findings:
  • Critical: バグ、セキュリティ問題、または破壊的な変更。
  • Improvements: より良いコード品質またはパフォーマンスに関する提案。
  • Nitpicks: フォーマットまたはマイナーなスタイルの問題 (オプション)。
• Conclusion: 明確な推奨事項 (Approved / Request Changes)。

トーン

• 建設的で、プロフェッショナルで、フレンドリーであることを心がけます。
• 変更がなぜ要求されているのか*を説明してください。
• 承認の場合、貢献の具体的な価値を認めてください。

5. クリーンアップ (リモート PR のみ)

• レビューの後、ユーザーがデフォルトブランチ (例: main または master) に戻したいかどうかを確認します。