/harness-review           # 自動判定
/harness-review code      # コードレビュー強制
/harness-review plan      # 計画レビュー強制
/harness-review scope     # スコープ分析強制

変更ファイル分析
    ↓
┌─────────────────────────────────────────┐
│           品質判定ゲート                 │
├─────────────────────────────────────────┤
│  判定項目:                              │
│  ├── カバレッジ不足？（テストなし）     │
│  ├── セキュリティ注意？（auth/api/）    │
│  ├── a11y 注意？（UI コンポーネント）   │
│  └── パフォーマンス注意？（DB/ループ）  │
└─────────────────────────────────────────┘
          ↓
    重点レビュー領域を決定

📊 品質判定結果 → 重点レビュー領域

| 判定 | 該当 | 対象ファイル |
|------|------|-------------|
| セキュリティ | ⚠️ | src/api/auth.ts |
| カバレッジ | ⚠️ | src/utils/helpers.ts (テストなし) |
| a11y | ✅ | - |
| パフォーマンス | ✅ | - |
| SEO/OGP | ⚠️ | app/layout.tsx (OGP 未設定) |
| クロスプラットフォーム | ✅ | - |

→ セキュリティ・カバレッジ・SEO を重点的にレビュー

undefined

**出力例**:
```markdown
🔍 LSP 影響分析結果

変更: updateUserProfile() のシグネチャ変更

影響を受ける箇所:
├── src/pages/profile.tsx:89 ⚠️ 引数更新必要
├── src/pages/settings.tsx:145 ⚠️ 引数更新必要
├── tests/user.test.ts:67 ✅ 更新済み
└── src/api/admin.ts:23 ⚠️ 引数更新必要

→ 3箇所で引数の更新が必要

undefined

undefined

📊 コミット履歴分析（構造化）

| Hash | Subject | Author | Date |
|------|---------|--------|------|
| a1b2c3d | feat: add auth | Alice | 2026-02-04 |
| e4f5g6h | fix: cors error | Bob | 2026-02-03 |

変更ファイル（--raw）:
├── src/auth.ts (Modified)
├── src/api/middleware.ts (Added)
└── tests/auth.test.ts (Modified)

→ 認証周りの変更を重点的にレビュー

undefined

**表示例**:

```markdown
📚 過去のレビュー指摘（関連あり）

| 日付 | 指摘内容 | ファイル |
|------|---------|---------|
| 2024-01-15 | XSS脆弱性: innerHTML 使用禁止 | src/components/*.tsx |
| 2024-01-20 | N+1クエリ: prefetch 必須 | src/api/*.ts |

💡 今回のレビューで上記パターンを重点チェック

設定確認: .claude-code-harness.config.yaml
    ↓
├── review.mode: default → Claude 単体レビュー
└── review.mode: codex   → Codex 並列レビュー（レビュータイプごとに4エキスパート）

✅ 正しい: 4回の `codex exec` 呼び出しを1つのレスポンス内で並列実行
❌ 間違い: 1回の呼び出しで「全観点をレビューして」と依頼（まとめ依頼）

/codex-mode on

base=$(git merge-base HEAD origin/main 2>/dev/null \
  || git merge-base HEAD main 2>/dev/null \
  || git merge-base HEAD master 2>/dev/null \
  || git rev-parse HEAD~1 2>/dev/null \
  || git hash-object -t tree /dev/null)
committed=$(git diff --name-only --diff-filter=ACMRTUXB $base...HEAD)
staged=$(git diff --name-only --cached)
unstaged=$(git diff --name-only)
files=$(echo -e "$committed\n$staged\n$unstaged" | sort -u | grep -v '^$')
files_count=$(echo "$files" | wc -l)

function countReviewAspects(files) {
  let aspects = 0;
  if (files.some(f => /\/(auth|api|middleware|security)\//.test(f))) aspects++;
  if (files.some(f => /\/(db|sql|repository|cache)\//.test(f))) aspects++;
  if (files.some(f => /\/(components|pages|app)\/.*\.tsx$/.test(f))) aspects++;
  if (files.some(f => /\/(pages|app)\/.*\.(metadata|head|seo)/.test(f))) aspects++;
  return Math.max(aspects, 1);
}

Task tool 並列呼び出し:
  #1: subagent_type="code-reviewer"
      prompt="セキュリティ観点でレビュー: {files}"
  #2: subagent_type="code-reviewer"
      prompt="パフォーマンス観点でレビュー: {files}"
  #3: subagent_type="code-reviewer"
      prompt="コード品質観点でレビュー: {files}"

harness_ast_search pattern="console.log($$$)" language="typescript" path="src/"
harness_ast_search pattern="catch ($ERR) { }" language="typescript" path="src/"

🔍 AST-Grep Code Smell Scan

Patterns checked:
- console.log($$$) → Debug logs
- catch ($ERR) { } → Empty catch blocks

Results:
├── 3x console.log found (src/api/*.ts)
├── 1x empty catch block (src/utils/error.ts:45)
└── 0x unused async

📊 LSP 診断結果

| ファイル | エラー | 警告 |
|---------|--------|------|
| src/components/Form.tsx | 0 | 2 |
| src/utils/api.ts | 1 | 0 |

⚠️ 1件のエラーを検出
→ レビューで指摘事項に追加

🔍 変更影響分析

変更: validateInput()

参照箇所:
├── src/pages/signup.tsx:34
├── src/pages/settings.tsx:56
└── tests/validate.test.ts:12

→ テストでカバー済み ✅

// ページ範囲指定で読み取り
Read({ file_path: "docs/architecture.pdf", pages: "1-15" })

// 変更履歴セクションのみ
Read({ file_path: "docs/changelog.pdf", pages: "5-12" })

// セキュリティ要件のみ
Read({ file_path: "docs/requirements.pdf", pages: "45-60" })

大型セキュリティ仕様書（200ページ）のレビュー:

1. **目次で構造を把握**（1-3ページ）
   Read({ file_path: "security-spec.pdf", pages: "1-3" })

2. **認証・認可の章を精読**（25-45ページ）
   Read({ file_path: "security-spec.pdf", pages: "25-45" })

3. **脆弱性対策の章を精読**（78-92ページ）
   Read({ file_path: "security-spec.pdf", pages: "78-92" })

この方法で、セキュリティレビューに必要な部分だけを効率的に確認できます。

パフォーマンス要件書（150ページ）のレビュー:

1. **目次とサマリー**（1-5ページ）
   Read({ file_path: "performance-spec.pdf", pages: "1-5" })

2. **レスポンスタイム要件**（34-50ページ）
   Read({ file_path: "performance-spec.pdf", pages: "34-50" })

3. **負荷テスト結果**（120-135ページ）
   Read({ file_path: "performance-spec.pdf", pages: "120-135" })

1. 目次を読んで構造を理解
   Read({ file_path: "spec.pdf", pages: "1-3" })

2. 変更箇所を特定
   目次から変更セクションのページ番号を取得

3. 関連セクションのみ精読
   Read({ file_path: "spec.pdf", pages: "{変更範囲}" })

📝 コードチェックを依頼するときの言い方

1. **「チェックして」**
   - 全体的に問題がないか見てもらう

2. **「セキュリティ大丈夫？」**
   - 悪意ある攻撃に耐えられるかチェック

3. **「遅くない？」**
   - 速度に問題がないかチェック

4. **「誰でも使える？」**
   - 障害のある方でも使えるかチェック

💡 ヒント: 「全部チェックして」と言えば、
4つの観点すべてを自動で確認します