code-review

リソース

scripts/
  validate-code-review.sh
references/
  review-patterns.md

コードレビュー品質スキル

このスキルでは、GoodVibes の高精度ツールを使って、徹底したエンタープライズレベルのコードレビューを行う方法を説明します。体系的なコードレビューによって、問題を早期に発見し、一貫性を確保し、セキュリティとパフォーマンスを検証するとともに、コードベース全体で高い品質基準を維持できます。

このスキルを使うタイミング

次の場合にこのスキルを読み込んでください：

• プルリクエストまたはマージリクエストをレビューするとき
• コード品質の監査を実施するとき
• 実装のセキュリティとパフォーマンスを検証するとき
• アーキテクチャパターンへの準拠を確認するとき
• テストカバレッジと品質を評価するとき
• アクセシビリティへの準拠を評価するとき
• 開発者に構造化されたフィードバックを提供するとき

トリガーとなるフレーズ：「このコードをレビューして」「PR を確認して」「品質監査」「セキュリティレビュー」「パフォーマンスレビュー」「実装を検証して」。

基本的なワークフロー

フェーズ 1：変更点の把握 — 変更内容を理解する

レビューを始める前に、何が、なぜ変更されたのか、影響範囲はどこまでかを把握します。

ステップ 1.1：変更の背景を収集する

discover を使って、変更されたファイルをすべて特定し、変更の種類を把握します。

discover:
  queries:
    - id: changed_files
      type: glob
      patterns: ["src/**/*"]  # List changed files for review
    - id: new_files
      type: glob
      patterns: ["**/*"]
    - id: test_files
      type: glob
      patterns: ["**/*.test.ts", "**/*.test.tsx", "**/*.spec.ts", "**/*.spec.tsx"]
  verbosity: files_only

git から抽出する情報：

precision_exec:
  commands:
    - cmd: "git diff --name-only HEAD~1..HEAD"
  verbosity: minimal

ここから分かること：

• 変更セットで修正されたすべてのファイル
• 新規ファイル、変更されたファイル、削除されたファイル
• テストファイルが含まれているか（または不足しているか）
• 変更の範囲（フロントエンド、バックエンド、フルスタック）

ステップ 1.2：変更されたコードを分析する

precision_read を使って、実際の変更内容を調べます。

precision_read:
  files:
    - path: "src/api/user-routes.ts"  # Example changed file
      extract: content
    - path: "src/components/UserProfile.tsx"
      extract: content
  output:
    max_per_item: 200
  verbosity: standard

差分のコンテキストを取得する：

precision_exec:
  commands:
    - cmd: "git diff HEAD~1..HEAD -- src/api/user-routes.ts"
  verbosity: standard

ステップ 1.3：関連コードを見つける

discover を使って、変更されたシンボルのインポート、エクスポート、使用箇所を見つけます。

discover:
  queries:
    - id: function_exports
      type: grep
      pattern: "export (function|const|class) (createUser|updateUser|deleteUser)"
      glob: "**/*.{ts,tsx,js,jsx}"
    - id: usage_sites
      type: grep
      pattern: "(createUser|updateUser|deleteUser)\\("
      glob: "**/*.{ts,tsx,js,jsx}"
    - id: related_tests
      type: grep
      pattern: "(createUser|updateUser|deleteUser)"
      glob: "**/*.test.{ts,tsx}"
  verbosity: locations

ここから分かること：

• 変更された関数が使われている場所
• 潜在的な破壊的変更
• 変更されたコードのテストカバレッジ
• コードベース全体への波及効果

フェーズ 2：セキュリティレビュー

セキュリティ上の問題は重大であり、レビューで必ず発見する必要があります。

ステップ 2.1：一般的な脆弱性を確認する

discover を使って、セキュリティ上のアンチパターンを見つけます。

discover:
  queries:
    # SQL Injection
    - id: sql_injection
      type: grep
      pattern: '(query|execute|sql).*[`$].*\$\{'
      glob: "**/*.{ts,tsx,js,jsx}"
    # XSS vulnerabilities
    - id: dangerous_html
      type: grep
      pattern: "(dangerouslySetInnerHTML|innerHTML|outerHTML)"
      glob: "**/*.{ts,tsx,jsx}"
    # Hardcoded secrets
    - id: hardcoded_secrets
      type: grep
      pattern: '(password|secret|api[_-]?key|token)\s*=\s*["''][^"'']+["'']'
      glob: "**/*.{ts,tsx,js,jsx,json}"
    # Missing authentication
    - id: unauthed_routes
      type: grep
      pattern: "export (async )?function (GET|POST|PUT|DELETE|PATCH)"
      glob: "src/app/api/**/*.ts"
  verbosity: locations

確認すべき重大なパターン：

パターン	重大度	重要な理由
SQL インジェクション	重大	攻撃者によるデータベースの読み取りや変更を許してしまう
XSS 脆弱性	重大	スクリプトの注入やセッションの乗っ取りを許してしまう
ハードコードされたシークレット	重大	ソースコード内で認証情報が露出する
認証チェックの欠落	重大	保護されたリソースが露出する
安全でないデシリアライズ	重大	リモートコード実行につながる
CORS の設定ミス	高	未許可のオリジンを許してしまう
弱いパスワード規則	高	アカウントの侵害につながる
入力検証の欠落	高	データ破損やインジェクションにつながる

ステップ 2.2：入力処理を検証する

すべての外部入力を検証する必要があります。

discover:
  queries:
    # Check for validation schemas
    - id: zod_schemas
      type: grep
      pattern: "z\\.(object|string|number|array|enum)"
      glob: "**/*.{ts,tsx}"
    # Check for direct request.json() without validation
    - id: unvalidated_input
      type: grep
      pattern: "(await request\\.json\\(\\)|req\\.body)(?!.*safeParse)"
      glob: "src/app/api/**/*.ts"
    # Check for SQL parameterization
    - id: parameterized_queries
      type: grep
      pattern: "(db\\.(query|execute)|prisma\\.|sql`)"
      glob: "**/*.{ts,js}"
  verbosity: locations

検証に関するベストプラクティス：

• すべての API ルートで Zod、Joi、または同等のツールを使って入力を検証する
• すべてのデータベースクエリでパラメーター化クエリ（Prisma、プリペアドステートメント）を使う
• ファイルのアップロード時にコンテンツタイプとサイズを検証する
• URL とリダイレクト先を許可リストと照合して検証する

ステップ 2.3：認証と認可を確認する

保護されたリソースへのアクセスに認証が必要であることを確認します。

discover:
  queries:
    # Find auth middleware usage
    - id: auth_middleware
      type: grep
      pattern: "(getServerSession|auth\\(\\)|requireAuth|withAuth)"
      glob: "src/app/api/**/*.ts"
    # Find resource ownership checks
    - id: ownership_checks
      type: grep
      pattern: "(userId|authorId|ownerId)\s*===\s*(session|user|currentUser)"
      glob: "**/*.{ts,tsx}"
    # Find RBAC checks
    - id: rbac_checks
      type: grep
      pattern: "(role|permission|can)\s*===\s*"
      glob: "**/*.{ts,tsx}"
  verbosity: locations

重要な確認事項：

• 保護された API ルートで認証ミドルウェアを呼び出している
• ユーザーが自身のリソースのみ変更できる（所有権の確認）
• 管理者限定の操作で管理者ロールを確認している
• JWT を適切なシークレットで検証している
• セッショントークンがローテーションされ、有効期限が設定されている

フェーズ 3：パフォーマンスレビュー

パフォーマンスの問題は、ユーザー体験を損ない、スケーラビリティのコストを増大させます。

ステップ 3.1：N+1 クエリを確認する

N+1 クエリは、データベースのパフォーマンスを最も損なう要因です。

discover:
  queries:
    # Find loops with database calls
    - id: n_plus_one
      type: grep
      pattern: "(for|forEach|map).*await.*(prisma|db|query|find)"
      glob: "**/*.{ts,tsx,js,jsx}"
    # Find Prisma include usage
    - id: prisma_includes
      type: grep
      pattern: "(findMany|findUnique|findFirst).*include:"
      glob: "**/*.{ts,js}"
  verbosity: locations

修正方法：

• include を使って関連レコードを先行読み込みする（Prisma）
• バッチ読み込みに結合または SELECT IN を使う
• GraphQL に DataLoader を実装する
• 頻繁にアクセスされるデータをキャッシュする

ステップ 3.2：不要な再レンダリングを確認する

React の再レンダリングの問題は、フロントエンドのパフォーマンスを低下させます。

discover:
  queries:
    # Find inline object/array creation in JSX
    - id: inline_objects
      type: grep
      pattern: "(onClick|onChange|style)=\\{\\{|=\\{\\["
      glob: "**/*.{tsx,jsx}"
    # Find missing useMemo/useCallback
    - id: missing_memoization
      type: grep
      pattern: "(map|filter|reduce)\\("
      glob: "**/*.{tsx,jsx}"
    # Find useEffect without dependencies
    - id: missing_deps
      type: grep
      pattern: "useEffect\\([^)]+\\)\\s*$"
      glob: "**/*.{tsx,jsx}"
  verbosity: locations

よくある問題：

アンチパターン	修正方法
props にインラインオブジェクトを指定	定数に切り出すか、useMemo を使う
props にインライン関数を指定	useCallback でラップする
key のない大きなリスト	安定した key prop を追加する
useEffect の依存配列が不足	使用するすべての変数を依存配列に追加する
Context によってすべてが再レンダリングされる	Context を分割するか、状態管理ツールを使う

ステップ 3.3：データベースのインデックスを確認する

インデックスがないと、クエリが遅くなります。

precision_read:
  files:
    - path: "prisma/schema.prisma"
      extract: content
  output:
    max_per_item: 500
  verbosity: standard

次の項目にインデックスがあることを確認します：

• 外部キー（userId、postId など）
• 頻繁にフィルタリングされるフィールド（status、createdAt、published）
• WHERE 句で使用されるフィールド
• 複数の列を使うクエリ向けの複合インデックス

フェーズ 4：コード品質レビュー

コード品質は、保守性と信頼性に影響します。

ステップ 4.1：型安全性を確認する

TypeScript では、実行時ではなくコンパイル時にエラーを検出する必要があります。

discover:
  queries:
    # Find any types
    - id: any_usage
      type: grep
      pattern: ":\s*any(\\s|;|,|\\))"
      glob: "**/*.{ts,tsx}"
    # Find type assertions (as)
    - id: type_assertions
      type: grep
      pattern: "as (unknown|any|string|number)"
      glob: "**/*.{ts,tsx}"
    # Find non-null assertions (!)
    - id: non_null_assertions
      type: grep
      pattern: "![.;,)\\]]"
      glob: "**/*.{ts,tsx}"
    # Find unsafe member access
    - id: unsafe_access
      type: grep
      pattern: "\\?\\."
      glob: "**/*.{ts,tsx}"
  verbosity: locations

型安全性に関する問題：

問題	重大度	修正方法
any 型の使用	重大	適切な型または unknown を使う
as any による型アサーション	重大	根本的な型の問題を修正する
! による非 null アサーション	軽微	null チェックを追加する
戻り値の型が未指定	軽微	関数の戻り値の型を明示する
暗黙的な any 型のパラメーター	重大	パラメーターの型を追加する

ステップ 4.2：エラー処理を確認する

すべての非同期処理と API 呼び出しで、エラーを処理する必要があります。

discover:
  queries:
    # Find floating promises
    - id: floating_promises
      type: grep
      pattern: "^\\s+[a-z][a-zA-Z]*\\(.*\\);$"
      glob: "**/*.{ts,tsx,js,jsx}"
    # Find empty catch blocks
    - id: empty_catch
      type: grep
      pattern: "catch.*\\{\\s*\\}"
      glob: "**/*.{ts,tsx,js,jsx}"
    # Find console.error (should use logger)
    - id: console_error
      type: grep
      pattern: "console\\.(error|warn|log)"
      glob: "**/*.{ts,tsx,js,jsx}"
  verbosity: locations

エラー処理のチェックリスト：

• すべての Promise に .catch() または try/catch がある
• エラーがコンテキスト（ユーザー ID、リクエスト ID）とともに記録される
• ユーザーに表示するエラーがサニタイズされている（スタックトレースを含まない）
• API エラーが適切な HTTP ステータスコードを返す
• 一時的な障害に対する再試行ロジックがある

ステップ 4.3：コードの構成を確認する

ファイルが大きく複雑度が高いと、コードの保守が難しくなります。

precision_exec:
  commands:
    - cmd: "find src -not -path '*/node_modules/*' -not -path '*/dist/*' -name '*.ts' -o -name '*.tsx' -print0 | xargs -0 wc -l | sort -rn | head -20"
  verbosity: standard

コード構成のルール：

• ファイルは 300 行未満にする（例外：生成コード）
• 関数は 50 行未満にする
• 循環的複雑度は 10 未満にする
• 最大ネスト深度：3 階層
• ヘルパーを別ファイルに切り出す

フェーズ 5：テストレビュー

テストは正しさを検証し、リグレッションを防ぎます。

ステップ 5.1：テストカバレッジを確認する

変更したファイルすべてにテストが必要です。

discover:
  queries:
    # Find test files
    - id: test_files
      type: glob
      patterns: ["**/*.test.{ts,tsx}", "**/*.spec.{ts,tsx}"]
    # Find files without tests
    - id: source_files
      type: glob
      patterns: ["src/**/*.{ts,tsx}"]
    # Check test imports
    - id: test_imports
      type: grep
      pattern: "from ['\"].*/(api|lib|components)/"
      glob: "**/*.test.{ts,tsx}"
  verbosity: files_only

ソースファイルとテストファイルを比較します：

// Pseudo-logic (implement with precision tools)
const sourceFiles = results.source_files.files;
const testFiles = results.test_files.files;
const missingTests = sourceFiles.filter(f => !testFiles.some(t => t.includes(f.replace('.ts', ''))));

ステップ 5.2：テストの品質を確認する

テストでは実装ではなく、振る舞いをテストする必要があります。

discover:
  queries:
    # Find skipped tests
    - id: skipped_tests
      type: grep
      pattern: "(it\\.skip|test\\.skip|describe\\.skip)"
      glob: "**/*.test.{ts,tsx}"
    # Find focused tests (.only)
    - id: focused_tests
      type: grep
      pattern: "(it\\.only|test\\.only|describe\\.only)"
      glob: "**/*.test.{ts,tsx}"
    # Find expect assertions
    - id: assertions
      type: grep
      pattern: "expect\\("
      glob: "**/*.test.{ts,tsx}"
    # Find mock usage
    - id: mocks
      type: grep
      pattern: "(vi\\.mock|jest\\.mock|vi\\.fn)"
      glob: "**/*.test.{ts,tsx}"
  verbosity: locations

テスト品質のチェックリスト：

• .skip や .only がない（マージ前に削除する）
• 各テストに少なくとも 1 つのアサーションがある
• テストに内容を表す名前が付いている（「it should...」、「when...then...」）
• テストが分離されている（状態を共有しない）
• モックの使用は最小限にする（実際の実装を優先する）
• エッジケース（null、空、大きな値）をテストする

フェーズ 6：アーキテクチャレビュー

アーキテクチャ違反は、技術的負債を生みます。

ステップ 6.1：依存関係の方向を確認する

依存関係は外側のレイヤーから内側のレイヤーへ向かう必要があります。

discover:
  queries:
    # Find domain imports in UI
    - id: ui_imports_domain
      type: grep
      pattern: "from ['\"].*/(domain|core|lib)/"
      glob: "src/components/**/*.{ts,tsx}"
    # Find UI imports in domain
    - id: domain_imports_ui
      type: grep
      pattern: "from ['\"].*/(components|pages|app)/"
      glob: "src/domain/**/*.{ts,tsx}"
    # Find circular dependencies
    - id: imports
      type: grep
      pattern: "^import.*from"
      glob: "src/**/*.{ts,tsx}"
  verbosity: locations

依存関係のルール：

• UI コンポーネントはフック、ユーティリティ、ドメインロジックをインポートできる
• ドメインロジックから UI コンポーネントをインポートしてはならない
• API ルートはドメインロジックをインポートできるが、UI はインポートしない
• 共通ユーティリティには依存関係を持たせない

ステップ 6.2：レイヤー違反を確認する

discover:
  queries:
    # Database access in components
    - id: db_in_components
      type: grep
      pattern: "(prisma|db\\.(query|execute))"
      glob: "src/components/**/*.{ts,tsx}"
    # Business logic in API routes
    - id: logic_in_routes
      type: grep
      pattern: "export (async )?function (GET|POST)"
      glob: "src/app/api/**/*.ts"
  verbosity: files_only

ルートハンドラーを読み、次の項目を確認します：

• ルートハンドラーは 30 行未満にする（処理はサービスに委譲する）
• コンポーネント内でデータベースクエリを実行しない（サーバーアクションまたは API ルートを使う）
• ルートにビジネスロジックを含めない（サービスレイヤーに切り出す）

フェーズ 7：アクセシビリティレビュー

アクセシビリティを確保することで、誰もがアプリを使えるようになります。

ステップ 7.1：セマンティック HTML を確認する

アクセシビリティのために適切な HTML 要素を使います。

discover:
  queries:
    # Find div buttons (should be <button>)
    - id: div_buttons
      type: grep
      pattern: "<div.*(onClick|onKeyDown)"
      glob: "**/*.{tsx,jsx}"
    # Find missing alt text
    - id: missing_alt
      type: grep
      pattern: "<img(?![^>]*alt=)"
      glob: "**/*.{tsx,jsx}"
    # Find missing labels
    - id: missing_labels
      type: grep
      pattern: "<input(?![^>]*aria-label)(?![^>]*id=)"
      glob: "**/*.{tsx,jsx}"
    # Find missing ARIA roles
    - id: missing_roles
      type: grep
      pattern: "<(nav|header|footer|main)(?![^>]*role=)"
      glob: "**/*.{tsx,jsx}"
  verbosity: locations

アクセシビリティのチェックリスト：

• ボタンには <div onClick> ではなく <button> を使う
• 画像に内容を説明する alt テキストがある
• フォーム入力にラベルまたは aria-label がある
• フォーカス状態が見える（代替手段なしに outline: none を指定しない）
• 色のコントラストが WCAG AA を満たしている（テキストでは 4.5:1）
• キーボード操作が機能する（タブ順序、Enter/Space）

ステップ 7.2：ARIA パターンを確認する

discover:
  queries:
    # Find custom components
    - id: custom_components
      type: grep
      pattern: "(Accordion|Dialog|Dropdown|Tabs|Tooltip)"
      glob: "src/components/**/*.{tsx,jsx}"
  verbosity: files_only

検証するコンポーネントを確認します：

• モーダルはフォーカスをトラップし、Escape キーで閉じます
• ドロップダウンは矢印キーに対応しています
• タブは矢印キーと Home/End キーに対応しています
• ツールチップはアクセシブルです（ホバー時だけ表示されるものではありません）

フェーズ 8：レビューの採点

review-scoring スキルを使って、構造化されたフィードバックを提供します。

完全な評価基準については、plugins/goodvibes/skills/protocol/review-scoring/SKILL.md を参照してください。

10 の評価項目（重み付けあり）：

1. 正確性（15%）- 正しく動作しますか？要件を満たしていますか？
2. 型安全性（10%）- TypeScript を適切に使用していますか？any は使われていませんか？
3. セキュリティ（15%）- 脆弱性はありませんか？入力検証や認証チェックは適切ですか？
4. パフォーマンス（10%）- N+1 クエリはありませんか？インデックスやメモ化は適切ですか？
5. エラー処理（10%）- すべてのエラーを捕捉、記録、処理していますか？
6. テスト（10%）- テスト範囲は十分ですか？アサーションの品質は適切ですか？
7. コード品質（10%）- 読みやすく、保守しやすく、パターンに従っていますか？
8. アーキテクチャ（10%）- レイヤー構成は適切ですか？違反はありませんか？
9. アクセシビリティ（5%）- セマンティック HTML、ARIA、キーボード操作に対応していますか？
10. ドキュメント（5%）- 必要に応じて JSDoc、README、インラインコメントがありますか？

各項目を 1～10 で採点します：

• 1～3：大幅な修正が必要
• 4～6：改善が必要
• 7～8：良好、軽微な問題あり
• 9～10：優秀

総合スコア = 加重平均

合否の基準：

• 9.9+：優秀（すぐに承認）
• 8.0-9.4：良好（軽微な提案を添えて承認）
• 7.0-7.9：許容可能（変更を依頼 - 軽微な問題あり）
• 5.0-6.9：要修正（変更を依頼 - 重大な問題あり）
• < 5.0：却下（大幅なやり直しが必要）

フェーズ 9：自動検証

問題を検出するため、自動チェックを実行します。

precision_exec:
  commands:
    # Type check
    - cmd: "npm run typecheck"
    # Lint
    - cmd: "npm run lint"
    # Tests
    - cmd: "npm run test"
    # Security audit
    - cmd: "npm audit --audit-level=moderate"
  verbosity: standard

承認前にすべてのチェックに合格する必要があります。

フェーズ 10：フィードバックを提供する

構造化されたフィードバックは、具体的で、実行に移せる内容です。

レビュー出力形式：

## Review Summary

**Overall Score**: 8.2/10
**Verdict**: APPROVE with suggestions

**What changed**: Added user profile API with authentication
**Files reviewed**: 8 files (5 source, 3 test)

## Dimension Scores

1. Correctness: 9/10
2. Type Safety: 7/10
3. Security: 9/10
4. Performance: 8/10
5. Error Handling: 7/10
6. Testing: 8/10
7. Code Quality: 9/10
8. Architecture: 8/10
9. Accessibility: 8/10
10. Documentation: 7/10

## Issues Found

### Major (should fix)

- **FILE:LINE** - Type safety: Function `updateProfile` has implicit `any` return type
  - Fix: Add explicit return type `Promise<User>`
  - Impact: TypeScript can't catch type errors in callers

### Minor (nice to fix)

- **src/api/profile.ts:42** - Error handling: Empty catch block swallows errors
  - Fix: Log error with context before re-throwing
  - Impact: Makes debugging harder

## What Was Done Well

- Excellent input validation with Zod schemas
- Comprehensive test coverage (95%)
- Proper authentication checks on all routes
- Clean separation of concerns (route -> service -> repository)

フィードバックのガイドライン：

• 具体的にする：ファイルパスと行番号を含めます
• 実行可能にする：修正方法を正確に説明します
• 影響を説明する：なぜ重要なのかを示します
• 良い作業を認める：適切にできている点を挙げます
• 深刻度で分類する：重大 > 大 > 小

よくあるレビューのパターン

カテゴリ別に整理された詳細なアンチパターンについては、references/review-patterns.md を参照してください。

クイックリファレンス：

セキュリティパターン

• SQL インジェクション：クエリでの文字列連結
• XSS：安全でない HTML のレンダリング
• 認証のバイパス：認証チェックの欠落
• シークレットの露出：API キーのハードコーディング

パフォーマンスパターン

• N+1 クエリ：データベース呼び出しを含むループ
• インデックスの欠落：インデックスのない WHERE 句
• 不要な再レンダリング：React でのインラインオブジェクト
• メモリーリーク：クリーンアップされないイベントリスナー

コード品質パターン

• 型安全性の欠如：any 型、型アサーション
• エラー処理：未処理の Promise、空の catch
• 複雑さ：50 行を超える関数、3 階層を超えるネスト
• 重複：コピー＆ペーストされたコード

テストパターン

• テストの欠落：変更されたファイルにテストがない
• 不適切なアサーション：expect(result).toBeTruthy()
• テストの汚染：テスト間で共有される状態
• スキップされたテスト：.skip または .only が残っている

レビュー用の精密ツール

Discover Tool

複数の grep/glob クエリを並列実行して、パターンを見つけます。

例：セキュリティ上の問題を見つける

discover:
  queries:
    - id: sql_injection
      type: grep
      pattern: 'query.*\$\{'
    - id: hardcoded_secrets
      type: grep
      pattern: 'api[_-]?key\s*=\s*["''][^"'']+'
    - id: xss
      type: grep
      pattern: 'dangerouslySetInnerHTML'
  verbosity: locations

Precision Grep

コンテキスト、複数行のサポート、トークン数の制限を指定して検索します。

例：エラー処理を見つける

precision_grep:
  queries:
    - id: catch_blocks
      pattern: "try\\s*\\{[\\s\\S]*?\\}\\s*catch"
  output:
    format: context
    context_after: 3
    context_before: 1
  verbosity: standard

Precision Exec

検証コマンドを実行します。

precision_exec:
  commands:
    - cmd: "npm run typecheck"
    - cmd: "npm run lint"
    - cmd: "npm test -- --coverage"
  verbosity: standard

検証スクリプト

スクリプト/validate-code-review.sh を使って、レビューの網羅性を検証します。

./scripts/validate-code-review.sh /path/to/review-output.md

スクリプトのチェック項目：

• セキュリティパターンを確認したか
• パフォーマンスパターンを確認したか
• テストカバレッジをレビューしたか
• 変更されたファイルをすべてレビューしたか
• 評価基準に沿った採点がレビューに含まれているか
• フィードバックにファイルと行番号の参照が含まれ、具体的か

クイックリファレンス

レビューチェックリスト

レビュー前：

• 変更内容を把握する（PR の説明とコミットを読む）
• 差分を取得する（git diff または GitHub PR）
• 変更されたファイルとその目的を特定する

レビュー中：

• セキュリティ：脆弱性、認証、検証を確認する
• パフォーマンス：N+1、インデックス、再レンダリングを確認する
• 型安全性：any、型アサーション、戻り値の型を確認する
• エラー処理：未処理の Promise、空の catch を確認する
• テスト：カバレッジ、品質、スキップされたテストを確認する
• アーキテクチャ：レイヤー構成、依存関係、整理状況を確認する
• アクセシビリティ：セマンティック HTML、ARIA、キーボード操作を確認する

レビュー後：

• 自動検証を実行する（型チェック、lint、テスト）
• 10 項目すべてを採点する
• 加重スコアを計算する
• 判定を示す（承認／変更を依頼／却下）
• ファイル名と行番号を示した、実行可能なフィードバックを書く

重大度のガイドライン

重大（マージ前に必ず修正）：

• セキュリティ上の脆弱性（SQL インジェクション、XSS、認証バイパス）
• データ損失につながるバグ
• コンパイルエラー／実行時エラー
• パブリック API に対する破壊的変更

重要（マージ前に修正すべき）：

• 型安全性の問題（any の使用、型の欠落）
• パフォーマンスの問題（N+1 クエリ、インデックスの欠落）
• エラー処理の不足
• 重要な処理経路に対するテストの不足
• アーキテクチャ違反

軽微（できれば修正、または後続対応）：

• コードスタイルの不統一
• ドキュメントの不足
• 重要ではないアクセシビリティの問題
• リファクタリングの機会
• エッジケースのテストカバレッジの低さ

よくある間違いを避ける

スコアの過大評価：

• 問題があるのに 9～10 点を付けない
• 品質上の不足点について正直に評価する
• 重大な問題があればレビューを不合格にする

曖昧なフィードバック：

• 悪い例：「型を修正してください」
• 良い例：「src/api/user.ts:42 - 関数 getUser に戻り値の型 Promise<User> を追加してください」

良い点を見落とす：

• うまくできている点には必ず言及する
• 肯定的なフィードバックは改善の励みになる

重大度の不統一：

• セキュリティ上の問題は常に「重大」
• テストの不足は「軽微」ではなく「重要」
• スタイル上の問題は「重要」ではなく「軽微」

高度なテクニック

Discover による一括レビュー

複数の PR やファイルを並行してレビューします。

discover:
  queries:
    - id: all_changes
      type: grep
      pattern: ".*"
      path: "src/"
  verbosity: files_only

次に、ファイルをまとめて読み込みます。

precision_read:
  files:
    - path: "src/changed-file-1.ts"
    - path: "src/changed-file-2.ts"
  extract: content
  output:
    max_per_item: 100
  verbosity: standard

コンテキストを考慮したレビュー

precision_grep で前後のコードも含めて検索し、周辺コードを把握します。

precision_grep:
  queries:
    - id: auth_checks
      pattern: "getServerSession|auth\\(\\)"
  output:
    format: context
    context_before: 5
    context_after: 10
  verbosity: standard

差分レビュー

変更された行だけに焦点を当てます。

precision_exec:
  commands:
    - cmd: "git diff HEAD~1..HEAD --unified=5"
  verbosity: standard

差分を解析し、変更された箇所だけをレビューします。

パターンの自動検出

セキュリティやパフォーマンスのチェックをまとめて実行します。

discover:
  queries:
    # Security
    - { id: sql_injection, type: grep, pattern: 'query.*\$\{' }
    - { id: xss, type: grep, pattern: 'dangerouslySetInnerHTML' }
    - { id: secrets, type: grep, pattern: 'password\s*=\s*["''][^"'']+' }
    # Performance
    - { id: n_plus_one, type: grep, pattern: 'for.*await.*prisma' }
    - { id: inline_objects, type: grep, pattern: 'onClick=\{\{', glob: '**/*.tsx' }
    # Quality
    - { id: any_usage, type: grep, pattern: ':\s*any', glob: '**/*.ts' }
    - { id: empty_catch, type: grep, pattern: 'catch.*\{\s*\}' }
  verbosity: locations

結果を集約し、見つかった内容に基づいて採点します。

他のスキルとの連携

• 10 項目の評価基準に沿った体系的なフィードバックには、review-scoring を使用します
• レビュー中の修正で問題が発生した場合は、error-recovery を使用します
• 高度な精密ツールの使用には、precision-mastery を使用します
• テストの品質検証には、testing-strategy を使用します
• UI コンポーネントのレビューには、component-architecture を使用します
• API ルートのレビューには、api-design を使用します
• データベースのクエリやスキーマのレビューには、database-layer を使用します

リソース

• references/review-patterns.md - カテゴリー別の一般的なアンチパターン
• scripts/validate-code-review.sh - レビューを自動検証するスクリプト
• plugins/goodvibes/skills/protocol/review-scoring/SKILL.md - 採点基準の詳細
• OWASP Top 10 - https://owasp.org/www-project-top-ten/
• WCAG ガイドライン - https://www.w3.org/WAI/WCAG21/quickref/