skanehira/workflow-review

/review - コードレビューコマンド

ローカルのgit変更を自動検出し、5つの観点からコードレビューを実施します。

使い方

/review          # すべての変更をレビュー
/review --staged # ステージ済み変更のみ

---

[1/5] 変更検出

引数の解析

引数: $ARGUMENTS
- --staged: ステージ済み変更のみ
- --all または 空: すべての変更

gitリポジトリ確認

Bashツールで以下を実行してgitリポジトリか確認:

git rev-parse --git-dir 2>/dev/null

gitリポジトリでない場合: 「このディレクトリはgitリポジトリではありません。/reviewはgitリポジトリ内で実行してください。」と表示して終了。

変更ファイル取得

Bashツールで以下を実行:

git status --porcelain

差分取得

$ARGUMENTSが--stagedの場合:

git diff --staged

それ以外の場合:

git diff
git diff --staged

変更がない場合

変更が0件の場合: 「レビュー対象の変更がありません。」と表示して終了。

変更サマリー表示

検出された変更:
- [ファイルパス] ([変更種別: 修正/新規/削除])
- ...

合計: N ファイル

---

[2/5] コンテキスト収集

変更ファイルの読み込み

各変更ファイルについてReadツールで内容を読み込む。

テストファイルの検索

Globツールで言語に応じたパターンを検索し、変更ファイルに対応するテストを特定:

言語別テストファイルパターン

| 言語 | パターン | 配置 | | ---------------- | -------------------------------------------- | ----------------------------------------------- | | Go | *_test.go | 同一ディレクトリ | | Rust | tests/**/*.rs, モジュール内 #[cfg(test)] | 統合テストは tests/、単体テストはモジュール内 | | TypeScript/React | *.test.ts, *.test.tsx, __tests__/** | 同一ディレクトリまたは __tests__/ | | Lua | *_test.lua, *_spec.lua, test_*.lua | 同一ディレクトリ |

検索パターン

• **/*_test.go (Go)
• **/tests/**/*.rs (Rust統合テスト)
• **/*.test.* (TypeScript/React)
• **/*_test.* (Lua, 汎用)
• **/*_spec.* (Lua, 汎用)
• **/__tests__/** (React)

対応関係の例

| 言語 | 実装ファイル | テストファイル | | ---------- | --------------- | ------------------------------------------------------------------------ | | Go | handler.go | handler_test.go（同一ディレクトリ） | | Rust | src/user.rs | src/user.rs 内の #[cfg(test)] mod tests、または tests/user_test.rs | | TypeScript | LoginForm.tsx | LoginForm.test.tsx（同一ディレクトリ） | | Lua | foo.lua | foo_test.lua, foo_spec.lua, test_foo.lua |

関連ファイルの特定

変更ファイルに関連するすべての処理を把握するため、以下の手順で依存関係を追跡:

1. インポート/依存関係の解析: 言語に応じたインポート文をGrepで抽出: | 言語 | パターン | | ---------- | ------------------------------------ | | Go | import "...", import (...) | | Rust | use ..., mod ..., extern crate | | TypeScript | import ... from, require(...) |

   • インポート元のファイルをReadで読み込み
   • 変更が影響を与える可能性のあるファイルを特定

2. 逆依存関係の追跡:

   • 変更ファイルをインポートしている他のファイルをGrepで検索
   • 変更による影響範囲を把握

3. 呼び出し関係の追跡:

   • 変更された関数/クラス名をGrepで検索
   • 呼び出し元のファイルを特定し、影響範囲を確認

4. 同一モジュール内のファイル:

   [変更ファイルのディレクトリ]/**/*
   

プロジェクトパターンの確認

Grepツールで以下を検索:

• 類似の関数定義パターン
• インポート/require文
• 既存のテストパターン
• 変更されたAPIを使用している箇所

プロジェクトルールファイルの読み込み

以下のファイルが存在する場合、Readツールで読み込んでおく：

1. CLAUDE.md（プロジェクトルート）

   • コーディング規約
   • 禁止パターン
   • 推奨アプローチ

2. docs/DESIGN.md

   • 設計方針
   • アーキテクチャ原則

3. .claude/rules/（ディレクトリ内のすべてのファイル）

   • プロジェクト固有のルール

---

[3/5] レビュー実施

必須レビュー観点

以下の6観点は必須で常にレビューを実施する：

1. TDD/テスト品質 - テストの有無、カバレッジ、テストファースト準拠
2. コード品質 - 可読性、命名、複雑度、重複、凝集度、結合度
3. セキュリティ - 脆弱性、認証/認可、入力検証
4. アーキテクチャ - 設計パターン、依存関係、責務分離
5. プロジェクトルール - CLAUDE.md, DESIGN.md, .claude/rules準拠
6. パフォーマンス - 実行速度、メモリ使用量、アルゴリズム効率

追加レビュー観点の確認

AskUserQuestionツールで追加のレビュー観点を確認する：

AskUserQuestion({
  questions: [
    {
      question: "必須観点（TDD/テスト品質、コード品質、セキュリティ、アーキテクチャ、プロジェクトルール、パフォーマンス）に加えて、追加でレビューしたい観点はありますか？",
      header: "追加観点",
      options: [
        { label: "追加なし", description: "必須観点のみでレビュー（推奨）" }
      ],
      multiSelect: false
    }
  ]
})

「Other」選択時の処理:

• ユーザーが入力したカスタム観点でレビューを実施
• 例: 「国際化対応」「ドキュメント」など
• カスタム観点の場合、その観点に関連するチェック項目を動的に生成

レビュー実施

必須観点 + 選択された追加観点について以下のチェックを実施する。

3.1 TDD/テスト品質

チェック項目:

| 項目 | 重要度 | 確認内容 | | ---------------- | -------- | ------------------------------------------------------------------------ | | テストの存在 | Critical | 新規コードに対応するテストファイルが存在するか | | テストカバレッジ | Warning | 主要関数がテストされているか、エッジケース・エラーケースのテストがあるか | | テスト品質 | Critical | テスト名が動作を説明しているか、AAAパターンに従っているか |

言語別テスト品質基準（詳細は writing-tests スキルを参照）:

| 言語 | 命名規則 | 構造 | | ---------- | ------------------------------ | -------------------- | | Go | Test関数_should結果_when条件 | Table-Driven Tests | | Rust | 関数_returns結果_when条件 | #[test], rstest | | TypeScript | describe + it | AAA, Testing Library |

判定基準:

• テストファイルが存在しない新規コード → Critical
• テストはあるがカバレッジ不足 → Warning
• テスト名が不明確、AAAパターン未準拠 → Critical

3.2 コード品質

チェック項目:

| 項目 | 重要度 | 確認内容 | | ------------ | ------- | ---------------------------------------------------------------------------------------------------- | | 可読性 | Warning | 関数/変数名が意図を表現しているか、関数の長さ（目安: 50行以内）、ネストの深さ（目安: 3レベル以内） | | 命名規則 | Info | プロジェクトの既存命名規則に従っているか | | 重複 | Warning | 同一/類似コードが複数箇所にないか | | コメント | Info | 複雑なロジックに「なぜ」を説明するコメントがあるか | | 不要コメント | Warning | 処理を翻訳しただけの無意味なコメントがないか（例: i++; // iをインクリメント） | | 型安全性 | Warning | 適切な型定義、型ガードがあるか | | 凝集度 | Warning | モジュール/クラス/関数が単一の目的に集中しているか（機能的凝集が理想） | | 結合度 | Warning | モジュール間の依存が最小限か、データ結合やメッセージ結合になっているか（内容結合・共通結合は避ける） |

判定基準:

• 関数が50行以上 → Warning（分割推奨）
• 同一コードが3箇所以上重複 → Warning
• マジックナンバー使用 → Info
• 処理を翻訳しただけのコメント → Warning（削除推奨）
• 低凝集（1つの関数/クラスに複数の無関係な責務） → Warning
• 高結合（グローバル変数への依存、内部実装への直接アクセス） → Warning

3.3 セキュリティ

チェック項目:

| 項目 | 重要度 | 確認内容 | | ---------------- | -------- | ------------------------------------------------------- | | シークレット管理 | Critical | ハードコードされたパスワード、APIキー、トークンがないか | | 入力検証 | Critical | ユーザー入力のバリデーションがあるか | | 認証/認可 | Warning | 適切なアクセス制御があるか | | インジェクション | Warning | SQL、コマンド、XSSの脆弱性がないか |

検索パターン:

| カテゴリ | パターン | | ---------------------- | ------------------------------------------------------------ | | 秘密情報 | password, secret, api_key, token | | トークンプレフィックス | ghp_, sk-, aws_, AKIA | | 危険な関数（共通） | eval(, exec(, system( | | 危険な関数（Go） | os.Exec, exec.Command, sql.Query（プレースホルダなし） | | 危険な関数（Rust） | std::process::Command, unsafe { |

判定基準:

• ハードコードされた秘密情報 → Critical
• 未検証のユーザー入力 → Critical
• eval/exec使用 → Warning

3.4 アーキテクチャ

チェック項目:

| 項目 | 重要度 | 確認内容 | | ---------------------- | ------- | --------------------------------------------------------------------- | | 責務分離 | Warning | 単一責任原則に従っているか、1ファイル/1関数が単一の責務を持っているか | | 既存パターンとの一貫性 | Warning | プロジェクトの既存パターンと一貫しているか | | 依存関係 | Info | 依存の方向が適切か（具象→抽象） | | Tidy First | Warning | 構造変更と機能変更が混在していないか |

判定基準:

• 循環依存 → Warning
• 既存パターンからの逸脱 → Info
• 構造変更と機能変更の混在 → Warning

3.5 プロジェクトルール準拠

チェック項目:

| 項目 | 重要度 | 確認内容 | | ----------------- | -------- | ------------------------------------------------------------ | | CLAUDE.md準拠 | Critical | コーディング規約、禁止パターン、推奨アプローチに従っているか | | DESIGN.md準拠 | Warning | 設計方針、アーキテクチャ原則に沿った実装か | | .claude/rules準拠 | Warning | プロジェクト固有のルールに違反していないか |

確認手順:

1. コンテキスト収集で読み込んだルールファイルを参照
2. 変更コードがルールに違反していないかチェック
3. 違反がある場合は具体的なルールと違反箇所を報告

判定基準:

• CLAUDE.mdの必須ルール違反 → Critical
• DESIGN.mdの設計方針からの逸脱 → Warning
• .claude/rulesのルール違反 → Warning
• ルールファイルが存在しない場合 → スキップ

3.6 パフォーマンス

チェック項目:

| 項目 | 重要度 | 確認内容 | | ---------------- | -------- | ----------------------------------------------- | | アルゴリズム効率 | Critical | O(n²)以上の計算量、不要なループのネスト | | メモリ使用量 | Warning | 大量データの保持、メモリリーク、不要なコピー | | I/O効率 | Warning | N+1問題、不要なAPI/DBアクセス、バッチ処理の欠如 | | キャッシュ活用 | Info | 繰り返し計算の結果キャッシュ、メモ化の活用 | | 非同期処理 | Warning | ブロッキング処理、並列化可能な処理の直列実行 |

確認手順:

1. ループや再帰処理の計算量を分析
2. データ構造の選択が適切かチェック
3. I/O操作のパターンを確認（N+1、バッチ処理）
4. 非同期処理やキャッシュの活用状況を確認

判定基準:

• O(n²)以上の計算量が大規模データに適用される → Critical
• N+1問題やメモリリークの可能性 → Critical
• キャッシュ活用の余地がある → Warning
• パフォーマンス影響が軽微な場合 → スキップ

---

[4/5] レビュー結果表示

サマリーテーブル

# Code Review Report

## Summary
| 観点                 | Critical | Warning | Info  |
|----------------------|----------|---------|-------|
| TDD/テスト品質       | X        | X       | X     |
| コード品質           | X        | X       | X     |
| セキュリティ         | X        | X       | X     |
| アーキテクチャ       | X        | X       | X     |
| プロジェクトルール   | X        | X       | X     |
| **合計**             | **X**    | **X**   | **X** |

Critical Issues (存在する場合)

各Critical Issueについて以下の形式で表示:

### [観点] 問題タイトル
**ファイル**: `パス:行番号`
**問題**: 問題の説明
**推奨対応**: 対応方法

Warnings (存在する場合)

各Warningについて以下の形式で表示:

### [観点] 問題タイトル
**ファイル**: `パス:行番号`
**問題**: 問題の説明
**推奨対応**: 対応方法

Info (存在する場合)

各Infoについて以下の形式で表示:

### [観点] 提案タイトル
**ファイル**: `パス:行番号`
**提案**: 改善提案

---

[5/5] 改善提案と対話

ユーザー選択

レビュー結果を表示した後、AskUserQuestionツールを使用してユーザーに次のアクションを確認:

AskUserQuestion({
  questions: [
    {
      question: "レビューでX件のCritical Issue、Y件のWarningが検出されました。\n\nどのように進めますか？",
      header: "レビュー結果",
      options: [
        {
          label: "Critical Issueをすべて修正",
          description: "最優先で対応すべき問題の修正コードを表示"
        },
        {
          label: "すべての問題を修正",
          description: "Critical + Warning の修正コードをまとめて表示"
        },
        {
          label: "特定の問題のみ修正",
          description: "修正したい問題を個別に選択"
        },
        {
          label: "レビュー完了",
          description: "修正せずにレビューを終了"
        }
      ],
      multiSelect: false
    }
  ]
})

修正コード提示

「Critical Issueをすべて修正」「すべての問題を修正」「特定の問題のみ修正」選択時:

各問題について以下の形式で修正案を提示:

## 修正コード提案

### [観点] 問題タイトル

**現在のコード** (`ファイルパス:行番号`):
```言語
現在のコード
```

**修正案**:
```言語
修正後のコード
```

**変更理由**: 変更の根拠を説明
```

### 修正対象の選択

**「特定の問題のみ修正」選択時**:

検出された各指摘を選択肢として表示し、修正したい問題を直接選択させる（複数選択可）:

```javascript
AskUserQuestion({
  questions: [
    {
      question: "修正したい問題を選択してください（複数選択可）",
      header: "修正対象",
      options: [
        { label: "すべて修正", description: "検出されたすべての問題を修正" },
        { label: "[Critical] ハードコードされたAPIキー", description: "セキュリティ: config.lua:45" },
        { label: "[Critical] テストファイルが存在しない", description: "TDD: github-pr-reviewer.lua" },
        { label: "[Warning] 関数が長すぎる", description: "コード品質: utils.lua:120-180 (60行)" }
      ],
      multiSelect: true
    }
  ]
})
```

**注意**:
- AskUserQuestionのoptionsは最大4件のため、「すべて修正」+ 重要度順に上位3件を表示
- 残りの指摘を修正したい場合は「Other」で追加指定可能

選択された問題の修正コードを提示し、承認を得てから修正を適用。

---

重要な注意事項

MUST Rules準拠

• TDD準拠チェック: テストファーストアプローチの確認
• Tidy Firstチェック: 構造変更と機能変更の分離確認
• 不確実性への対応: 仮定を立てず、不明点は明確に報告

レビュー対象外

• バイナリファイル
• 自動生成ファイル（node_modules/, .git/等）
• ロックファイル（package-lock.json, Cargo.lock等）
• 設定ファイル（.gitignore, .editorconfig等）

エラーハンドリング

• gitリポジトリでない場合は明確なエラーメッセージを表示して終了
• ファイル読み込みエラーは該当ファイルをスキップして続行
• 100ファイル以上の変更がある場合は「--stagedオプションで対象を絞ることを推奨」と警告を表示