reviewing-code について
コントリビューターやエージェントレビュアー向けのコードレビュー用スキルです。プロジェクトの方針や互換性を重視し、具体的で実行可能なフィードバックを促します。
主な機能
- 01変更とプロジェクト目標の整合性確認
- 02依存関係のバージョン互換性確認
- 03API設計と使いやすさのレビュー
- 04コンテキスト、テスト、境界条件の確認
- 05具体的で敬意ある提案
活用シーン
- 01プルリクエストとプロジェクト方針の照合
- 02依存関係更新による回帰の確認
- 03APIや命名上の問題の特定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/reviewing-codeを入力して読み込まれたか確認します。
詳細
コードレビュー
基本方針
コードレビューは、健全なコードベースを維持しながら、コントリビューターの成功を支援します。PR には、価値をもたらすことを示す責任があります。あなたの役割は、実行可能なフィードバックを通じて、その実現を支援することです。
重要：完璧に書かれた PR であっても、望まれていない機能を追加するものであれば、却下する必要があります。コードは、コードベースを意図した方向に前進させるものでなければなりません。却下する場合は、プロジェクトの目標に沿うための明確な指針を示してください。
高い基準を保ちながら、親しみやすく歓迎する姿勢で接してください。うまく機能している点も指摘してください。コードに改善が必要な場合は、なぜ改善が必要なのか、どう修正すればよいのかを具体的に伝えてください。
注目すべき点
コードベースを適切に前進させる変更ですか？
望まれていない機能のために書かれた完璧なコードであっても、却下すべきです。
依存関係のバージョン互換性
PR で依存関係の新しいバージョンに合わせてコードを変更する場合（例：上流で削除されたパラメーターを削除する、新しい API を使う）：
pyproject.tomlのバージョン指定が変更と一致している必要があります。 変更によって、これまで指定されていた最小バージョンとの互換性が失われる場合は、最小バージョンを引き上げる必要があります。そうしないと、古いバージョンを使うユーザーにリグレッションが発生します。- 古いバージョンとの後方互換性を維持する場合、コードで両方のバージョンに対応する必要があります（例：try/except、バージョンチェック）。古い API の使用箇所を削除するだけでバージョン指定を引き上げないのは、常に誤りです。古いバージョンを使うユーザーに、気づかれないまま問題が発生します。
- ロックファイル（
uv.lock）の変更は、PR の目的に必要な範囲に限定してください。 ty の互換性問題を修正する PR に、uv sync --upgradeの実行によって生じた、無関係な依存関係のバージョン引き上げ（anthropic、google-auth など）も含めるべきではありません。こうした変更はノイズとなり、差分のレビューを難しくします。
API の設計と命名
混乱を招くパターンや、慣用的でないコードを見つけてください。
- デフォルト値と矛盾するパラメーター値
- ミュータブルなデフォルト引数
- 将来の読者を混乱させる不明瞭な命名
- コードベースのほかの部分と一貫しないパターン
具体的な改善点
一般的な指摘ではなく、実行可能なフィードバックを提供してください。
ユーザーにとっての使いやすさ
ユーザーの視点から API を考えてください。直感的に使えますか？習得にはどのくらいかかりますか？
エージェントレビュー担当者向け
- 全体の背景を読む：レビューの前に、関連ファイル、テスト、ドキュメントを確認します
- 確立されたパターンと照らし合わせる：コードベースの規約との一貫性を確認します
- 機能に関する主張を検証する：コードが主張していることだけでなく、実際に何をするのかを理解します
- エッジケースを考慮する：エラー条件や境界のケースを検討します
避けるべきこと
- 具体性のない一般的なフィードバック
- 起こりそうにない仮定上の問題
- 強い理由のない、構成上の選択への細かな指摘
- PR の説明にすでに書かれている内容の要約
- 星による評価や過剰な絵文字
- 機能に問題がない場合の、スタイルの好みを巡る議論
- 解決策を示さずに変更を求めること
- プロジェクトの規約よりも個人的なコーディングスタイルを重視すること
口調
- 良い判断を認めます：「この API 設計はすっきりしています」
- 率直でありながら、敬意を持って伝えます
- 影響を説明します：「これはユーザーを混乱させます。なぜなら……」
- 誰かがこのコードを今後ずっと保守していくことを忘れないでください
判断の枠組み
承認する前に、次の点を確認してください。
- この PR は、明示された目的を達成していますか？
- その目的は、コードベースが進むべき方向に沿っていますか？
- このコードを自分で保守することに抵抗はありませんか？
- 主張だけでなく、実際の動作を理解していますか？
- この変更は技術的負債を生み出しますか？
改善が必要な箇所がある場合は、具体的で実行可能なフィードバックを通じて、改善を支援してください。間違った問題を解決しようとしている場合は、そのことを明確に伝えてください。
コメントの例
良いコメント：
| 代わりに | こう書く |
|---|---|
| "テストを追加する" | "handle_timeout メソッドでは、timeout=0 となる境界ケースのテストが必要です" |
| "この API は分かりにくい" | "パラメーター名の data は曖昧です。MCP の仕様に合わせて message_content にすることを検討してください" |
| "改善の余地がある" | "この方法でも動作しますが、循環依存が発生します。検証処理を utils/validators.py に移すことを検討してください" |
チェックリスト
承認する前に、以下を確認してください。
- 必須の開発ワークフローの手順（uv sync、prek、pytest）がすべて完了している
- 変更がリポジトリのパターンや規約に沿っている
- API の変更が文書化され、可能な場合は後方互換性が保たれている
- エラー処理がプロジェクトのパターン（具体的な例外型）に従っている
- テストで新機能と境界ケースが網羅されている
- 変更によってコードベースが意図した方向に進んでいる