seika139/review-pr

<!-- codex-profile-generated-from-prompt: prompts/review-pr.md -->

review-pr

この skill は Claude command /review-pr から変換した Codex 用 command skill です。

Codex での呼び出し

Codex CLI では /review-pr ではなく、$review-pr または /skills からこの skill を呼び出してください。 引数は $review-pr の後ろに自然文として続けます。

$review-pr <arguments>

元 prompt 内の $ARGUMENTS や slash command 表記は、$review-pr の後ろに書かれた引数として解釈してください。 Claude 専用の allowed-tools メタデータや ! command interpolation は Codex では自動適用されないため、必要な情報は通常の shell command で確認してください。

元 prompt

Review Pull Request

以下の手順でプルリクエストをレビューしてください。

1. プルリクエストの概要を把握する
2. プルリクエストの内容確認
3. プロンプトファイルの内容確認
4. ユニットテスト
5. 動作確認
6. コミット内容のレビュー

プルリクエストの概要を把握する

以下のコマンドを使用して、プルリクエストの概要を把握します。ARGUMENT はプルリクエスト番号または URL を指定します。

gh pr view $ARGUMENT

プルリクエストの説明に「デザインドキュメント」に関する記載がある場合は、対応するデザインドキュメントを必ず確認してください。 説明にある Issue や Pull Request のリンクを確認し、さらにそれらから派生する関連 Issue や Pull Request も確認してください。

プルリクエストの内容確認

以下のコマンドを使用して、対象プルリクエストの内容を確認します。ARGUMENT はプルリクエスト番号または URL を指定します。

gh pr diff $ARGUMENT

プロンプトファイルの内容確認

プロンプトファイルAGENTS.mdの内容を確認します。

ユニットテスト

プルリクエストの変更内容と関連するユニットテストが存在する場合は適切なユニットテストを実行し、すべてのテストが成功することを確認してください。

ユニットテスト実行前に現在のブランチがプルリクエストのブランチに切り替わっていることを確認してください。 git status コマンドで現在のプロジェクト内に変更がないことを確認してください。

ユニットテストを実行する際には直接 composer.json や package.json を実行するのではなく、Makefile, mise.toml といったタスクランナー、あるいはドキュメントに記載されている docker コマンドがある場合はそれを優先してください。

ユニットテストを実行するのに加えて、ユニットテストがソースコードの変更内容に対して十分なカバレッジを持っていることを確認してください。

動作確認

プルリクエストの変更内容に基づいて、必要な動作確認を実施してください。 動作確認の手順がプルリクエストの説明に記載されている場合は、その手順に従ってください。

コミット内容のレビュー

以上の確認項目をもとにレビューを実施し、修正が必要であるかどうかの判断をしてください。 修正が必要ならば修正計画・コメント内容を考案します。

コメント内容のレビューについて

差分にコメントアウトによる説明が含まれている場合は、その内容が適切であるかを確認してください。 既存のコメントアウトについてはレビューの対象外です。

まず、そのコメントアウトがコードの理解に役立つかどうかを評価します。

記載すべきコメント

• 非自明なロジックの補足
• 複雑なアルゴリズムの意図
• 設計上の方針に関する決定・説明
• その実装を選んだ背景や他の選択肢を避けた理由
• 特定のアルゴリズムや処理方式を使う根拠
• TODO や FIXME による改善予定や未解決の課題
• パフォーマンス上の懸念点
• バグが発生しやすい部分や将来的に変更が必要になりそうな箇所
• 外部サービスやライブラリに依存している点

削除すべきコメント

• 単純にソースコードの実行内容を説明するだけのコメントアウト
• 更新されにくく、コードと不一致になりがちな説明
• 自明な関数や変数の意味（命名を改善すべき）

それ以外に、コメントの誤字脱字や文法の誤り、表現の曖昧さ、助詞の使い方なども指摘してください。

フレームワークとしての役割

プロジェクトがフレームワークとしての役割を持つかどうかを確認します。 プロジェクトが他の開発者に利用されることを目的としている場合、フレームワークとしての役割を持つと判断します。

判別ができない場合は、プロンプトで以下の質問をしてください。

このプロジェクトはフレームワークとしての役割を持ちますか？[y/n]

プロジェクトがフレームワークとしての役割を持つ場合、特に以下の点に注意してレビューを行ってください。

• 拡張性: フレームワークは他の開発者が利用することを前提としているため、拡張性が高い設計になっているかを確認します。
• 一貫性: フレームワーク内での命名規則やコードスタイルが一貫しているかを確認します。
• コメントの質: フレームワークは他の開発者が利用することを前提としているため、コメントが十分に記載されているかを確認します。
  • 利用者が内部実装を追わなくてもいいようにエッジケースや意図を明示するコメントが含まれていることを確認します。

レビュー終了後にやること

レビュー時に新しくチェックアウトしたブランチを削除します。 新しくチェックアウトしていない場合は削除しなくて良いです。