code-reviewer

コードレビュー担当

このスキルでは、ローカル開発とリモートのプルリクエストの両方で、専門的かつ徹底したコードレビューを実施する方法をエージェントに案内します。

ワークフロー

1. レビュー対象の特定

• リモート PR：ユーザーが PR 番号または URL（例：「PR #123 をレビューしてください」）を指定した場合、そのリモート PR を対象にします。
• ローカルの変更：特定の PR が指定されていない場合、または「自分の変更をレビューしてください」と依頼された場合は、現在のローカルファイルシステムの状態（ステージ済みおよび未ステージの変更）を対象にします。

2. 準備

リモート PR の場合：

1. チェックアウト：GitHub CLI を使って PR をチェックアウトします。

   gh pr checkout <PR_NUMBER>
   

2. 事前確認：プロジェクト標準の検証スイートを実行し、自動チェックの失敗を早期に検出します。

   npm run preflight
   

3. コンテキスト：PR の説明と既存のコメントを読み、目的と経緯を把握します。

ローカルの変更の場合：

1. 変更の確認：
   • ステータスを確認します：git status
   • 差分を読みます：git diff（作業ツリー）および／または git diff --staged（ステージ済み）。
2. 事前確認（任意）：変更が大規模な場合は、レビューの前に npm run preflight を実行するかユーザーに確認します。

3. 詳細な分析

以下の観点に基づいてコード変更を分析します。

• 正確性：コードはバグや論理エラーを起こすことなく、意図された目的を達成していますか？
• 保守性：コードは整理され、適切に構造化されており、将来の理解や変更が容易ですか？コードの明瞭さ、モジュール性、確立された設計パターンへの準拠などを考慮します。
• 可読性：必要な箇所に適切なコメントがあり、プロジェクトのコーディングスタイルガイドラインに沿って一貫した形式になっていますか？
• 効率性：変更によって明らかなパフォーマンス上のボトルネックやリソースの非効率性が生じていませんか？
• セキュリティ：潜在的なセキュリティ脆弱性や安全でないコーディング手法はありませんか？
• エッジケースとエラー処理：エッジケースや潜在的なエラーが適切に処理されていますか？
• テスト可能性：新規または変更されたコードは、十分なテストでカバーされていますか（事前確認に合格した場合も含みます）？カバレッジや堅牢性を高める追加のテストケースを提案します。

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

構成

• 概要：レビューの全体像を簡潔に示します。
• 指摘事項：
  • 重大：バグ、セキュリティ上の問題、または破壊的変更。
  • 改善点：コード品質やパフォーマンスを向上させる提案。
  • 軽微な指摘：書式や細かなスタイル上の問題（任意）。
• 結論：明確な推奨事項（承認／変更を要求）。

トーン

• 建設的で、プロフェッショナルかつ親しみやすい表現にします。
• 変更を求める理由を説明します。
• 承認する場合は、貢献の具体的な価値を認めます。

5. クリーンアップ（リモート PR のみ）

• レビュー後、デフォルトブランチ（例：main または master）に戻るかユーザーに確認します。