Code Review Quality

<default_to_action> コードレビュー、またはレビュー慣行を確立する場合:

1. フィードバックを優先順位付けする: 🔴 ブロッカー (修正必須) → 🟡 メジャー → 🟢 マイナー → 💡 提案
2. 以下に焦点を当てる: バグ、セキュリティ、テスト容易性、保守性 (スタイルの好みではない)
3. 命令よりも質問をする: 「検討されましたか...?」 > 「これを変更してください...」
4. コンテキストを提供する: 変更内容ではなく、なぜ重要なのか
5. スコープを制限する: 効果を最大化するために、一度に 400 行未満のレビュー

クイックレビューチェックリスト:

• ロジック: 正しく動作するか? エッジケースに対応しているか?
• セキュリティ: 入力値の検証? 認証チェック? インジェクション攻撃のリスク?
• テスト容易性: テスト可能か? テストされているか?
• 保守性: 名前が明確か? 単一責任か? DRY原則に従っているか?
• パフォーマンス: O(n²)ループ? N+1クエリ? メモリリーク?

成功の重要要因:

• コードをレビューする、人をレビューしない
• バグ検出 > スタイルの細かい指摘
• 高速フィードバック (< 24時間) > 詳細なフィードバック </default_to_action>

クイックリファレンスカード

使用時機

• PR コードレビュー
• ペアプログラミングのフィードバック
• チームレビュー基準の確立
• 開発者へのメンタリング

フィードバック優先度レベル

レベル	アイコン	意味	アクション
ブロッカー	🔴	バグ/セキュリティ/クラッシュ	マージ前に修正必須
メジャー	🟡	ロジック問題/テストギャップ	マージ前に修正推奨
マイナー	🟢	スタイル/命名	修正するとよい
提案	💡	代替アプローチ	将来検討する

レビュースコープの制限

変更行数	推奨
< 200	単一レビューセッション
200-400	分割してレビュー
> 400	PR分割をリクエスト

フォーカスすべき項目

✅ レビュー対象	❌ スキップ
ロジックの正確性	フォーマット (linter を使用)
セキュリティリスク	命名の好み
テストカバレッジ	アーキテクチャ議論
パフォーマンス問題	スタイル意見
エラーハンドリング	細かい変更

---

フィードバックテンプレート

ブロッカー (修正必須)

🔴 **ブロッカー: SQL インジェクションリスク**

このクエリは SQL インジェクション脆弱性があります:
```javascript
db.query(`SELECT * FROM users WHERE id = ${userId}`)

修正方法: パラメータ化クエリを使用:

db.query('SELECT * FROM users WHERE id = ?', [userId])

理由: SQL にユーザー入力を直接含めると、攻撃者が任意のクエリを実行できます。

### メジャー (修正推奨)
```markdown
🟡 **メジャー: エラーハンドリングが不足**

`fetchUser()` がスロー した場合、どうなりますか? エラーがハンドルされずにバブルアップします。

**提案:** try/catch を追加して適切なエラーレスポンスを返す:
```javascript
try {
  const user = await fetchUser(id);
  return user;
} catch (error) {
  logger.error('Failed to fetch user', { id, error });
  throw new NotFoundError('User not found');
}

### マイナー (修正するとよい)
```markdown
🟢 **マイナー:** 変数名がより明確にできます

`d` は意味を伝えません。`daysSinceLastLogin` を検討してください。

提案 (検討)

💡 **提案:** これをヘルパーに抽出することを検討

この検証ロジックは 3 箇所に現れます。`validateEmail()` ヘルパーは重複を削減します。ブロッカーではありませんが、後続の PR で検討する価値があるかもしれません。

---

レビュー時に尋ねるべき質問

ロジック

• X が null/空/負の数の場合はどうなる?
• ここでレースコンディションはないか?
• API 呼び出しが失敗したらどうなる?

セキュリティ

• ユーザー入力は検証/サニタイズされているか?
• 認証チェックは実施されているか?
• シークレットまたは PII が公開されていないか?

テスト容易性

• これをどのようにテストしますか?
• 依存関係は注入可能か?
• ハッピーパスのテストがあるか? エッジケースは?

保守性

• 次の開発者がこれを理解できるか?
• これは複数のことをしすぎていないか?
• 削減できる重複はないか?

最小検出項目の強制

レビューは最小加重検出スコア 3.0 (CRITICAL=3, HIGH=2, MEDIUM=1, LOW=0.5, INFORMATIONAL=0.25) を満たす必要があります。初期レビューがこれに満たない場合は、メタレビュアーとして qe-devils-advocate エージェントを実行して追加の観察を見つけてください。すべてのレビューには少なくとも 3 つの実行可能な観察が必要です。

---

エージェント支援レビュー

// 包括的なコードレビュー
await Task("Code Review", {
  prNumber: 123,
  checks: ['security', 'performance', 'testability', 'maintainability'],
  feedbackLevels: ['blocker', 'major', 'minor'],
  autoApprove: { maxBlockers: 0, maxMajor: 2 }
}, "qe-quality-analyzer");

// セキュリティ重視のレビュー
await Task("Security Review", {
  prFiles: changedFiles,
  scanTypes: ['injection', 'auth', 'secrets', 'dependencies']
}, "qe-security-scanner");

// テストカバレッジレビュー
await Task("Coverage Review", {
  prNumber: 123,
  requireNewTests: true,
  minCoverageDelta: 0
}, "qe-coverage-analyzer");

---

エージェント調整ヒント

メモリ名前空間

aqe/code-review/
├── review-history/*     - 過去のレビュー決定
├── patterns/*           - チーム/リポジトリ別の共通問題
├── feedback-templates/* - 再利用可能なフィードバック
└── metrics/*            - レビューターンアラウンドタイム

フリート調整

const reviewFleet = await FleetManager.coordinate({
  strategy: 'code-review',
  agents: [
    'qe-quality-analyzer',    // ロジック, 保守性
    'qe-security-scanner',    // セキュリティリスク
    'qe-performance-tester',  // パフォーマンス問題
    'qe-coverage-analyzer'    // テストカバレッジ
  ],
  topology: 'parallel'
});

---

レビュー礼儀

✅ すべき	❌ すべきでない
「検討されましたか...?」	「これは間違っています」
なぜそれが重要なのかを説明	「これを修正してください」とだけ言う
よいコードを認める	否定的な点だけを指摘
提案する、要求しない	高圧的になる
< 400 行レビュー	一度に 2000 行レビュー

---

関連スキル

• agentic-quality-engineering - エージェント調整
• security-testing - セキュリティレビューの深さ
• refactoring-patterns - 保守性パターン

---

忘れずに

フィードバックを優先順位付けする: 🔴 ブロッカー → 🟡 メジャー → 🟢 マイナー → 💡 提案。バグとセキュリティに焦点を当て、スタイルではない。質問をする、命令しない。一度に 400 行未満をレビュー。高速フィードバック (< 24 時間) は詳細なフィードバックより優れています。

エージェントで: エージェントはセキュリティ、パフォーマンス、カバレッジチェックを自動化し、人間のレビュアーがロジックと設計に焦点を当てることを可能にします。一貫した高速な初期レビューのためにエージェントを使用してください。

スキル構成

• セキュリティ懸念事項 → セキュリティ重視のレビューのために /security-testing と構成
• カバレッジチェック → 変更されたファイルで /qe-coverage-analysis を実行
• 配置決定 → レビュー結果を /qe-quality-assessment にフィード

注意点

• エージェントが 400 行以上を一度にレビューして問題を見落とす — レビューを最大 200-400 行にチャンク化
• スタイルの細かい指摘をしながらロジックバグを見落とす、これがエージェントレビュー失敗の #1 原因 — フォーマットより正確性を優先
• エージェントが、コンパイルされるがサブルな競合状態を持つコードを承認 — 常に共有状態と非同期パターンをチェック
• 提案された修正がないレビューコメントは役に立たない — 常に代替案を含める
• エージェントがリンクされた問題を PR が実際に解決しているかをチェックしない — 述べられた問題が実際に修正されたことを確認