コードレビュースキル

ワークフロー

進捗に合わせてチェックを入れてください：

進捗:
- [ ] ステップ1: 派生元のコミットハッシュを取得
- [ ] ステップ2: 最終的な変更差分を取得
- [ ] ステップ3: コミット履歴を取得
- [ ] ステップ4: 外部ライブラリの情報を取得
- [ ] ステップ5: コードレビューを開始する
- [ ] ステップ6: コードレビュー結果のセルフレビュー

ステップ 1: 派生元のコミットハッシュを取得

以下のコマンドを実行する。 BASE_BRANCH：ユーザーが指示したベースブランチ。指示がない場合は main を対象とする。

git merge-base <BASE_BRANCH> HEAD

ステップ 2: 最終的な変更差分を取得

以下のコマンドを実行する

git diff 派生元のコミットハッシュ

ステップ 3: コミット履歴を取得

以下のコマンドを実行する

git log -p 派生元のコミットハッシュ..HEAD

ステップ 4: 外部ライブラリの情報を取得

ステップ 2 に外部ライブラリの API や設定ファイルが含まれていた場合、外部ライブラリの情報を取得する。

• 変更差分に含まれているライブラリと APIや設定ファイルの一覧を作成する 例:

  • nextjs
    • Link
    • next.config.ts
  • valibot
    • string
    • object

• それぞれのライブラリの対象 API の情報を取得する

ステップ 5: コードレビューを開始する

ステップ 2、ステップ 3 で取得した情報をもとにレビューを開始する。

• 最終的な変更差分がどのような意図や経緯で作成されたのかコミット履歴をもとに把握する
• 下記のレビュー観点・フォーマットに従ってレビューを行う

ステップ 6: コードレビュー結果のセルフレビュー

コードレビュー結果のセルフレビューと修正を３セット行い、レビューを完璧なものに仕上げる。 ただし、フォーマットの変更は行わないこと

レビューフォーマット

レビュー結果は以下のフォーマットに従って出力する。

# コードレビュー結果

## <重要度(eg: 🟥 高, 🟨 中, 🟩 低)>：️【<指摘のタイトル>】*繰り返し*

### 🎯 対象箇所

#### <ファイルパス(eg:apps/web/app/page.tsx)> - <行番号範囲(eg:L1-L30)>*繰り返し*

> <対象コード>

### 💬 指摘内容

<指摘内容>

### 🧠 指摘の判断理由

<ベストプラクティスや出典があればそれも記載>

### 📝 修正案

#### <修正案の名前>*繰り返し*

<修正案の内容>

##### ⤴️ メリット

<修正案のメリット>

##### ⤵️ デメリット

<修正案のデメリット>

##### ⚖️ トレードオフ

<修正案のトレードオフ>

レビュー観点

• 要件・仕様
• セキュリティ
• 保守性・可読性
• パフォーマンス
• テスタビリティ
• UX・a11y
• ベストプラクティス
• コードベースの統一性
• プロジェクトのコーディング規約
  • CLAUDE.md
  • ../../../.serena/memories フォルダ内の各ファイル

重要度基準

• 🟩 低: 見送り可能
• 🟨 中: 対応望ましいが議論余地あり
• 🟥 高: マージブロック対象

注意事項

• 代替案とトレードオフを常に含める
• 意図不明な場合は明示し考察を記載
• 関連コードを適時読み込む
• 重要度順に並び替える