review

Original source / Raw SKILL.md

---
name: review
description: "Reviews code for quality, security, performance, and accessibility issues. Use when user mentions レビュー, review, コードレビュー, セキュリティ, パフォーマンス, 品質チェック, セルフレビュー, PR, diff, 変更確認. Do NOT load for: 実装作業, 新機能開発, バグ修正, セットアップ."
allowed-tools: ["Read", "Grep", "Glob", "Bash", "Task"]
context: fork
---

# Review Skills

コードレビューと品質チェックを担当するスキル群です。

## 機能詳細

| 機能 | 詳細 |
|------|------|
| **変更レビュー** | See [references/changes-review.md](references/changes-review.md) |
| **品質チェック** | See [references/quality-review.md](references/quality-review.md) |
| **セキュリティ** | See [references/security-review.md](references/security-review.md) |
| **パフォーマンス** | See [references/performance-review.md](references/performance-review.md) |
| **アクセシビリティ** | See [references/accessibility-review.md](references/accessibility-review.md) |
| **SEO/OGP** | See [references/seo-review.md](references/seo-review.md) |
| **Codex 統合** | See [references/codex-integration.md](references/codex-integration.md) |
| **コミット判定** | See [references/commit-judgment-logic.md](references/commit-judgment-logic.md) |

## 実行手順

1. **品質判定ゲート**（Step 0）
2. **残コンテキスト確認（Codex モード時）**（Step 1）
3. ユーザーのリクエストを分類
4. **（Claude-mem 有効時）過去のレビュー指摘を検索**
5. 並列実行の判定（下記参照）
6. 上記の「機能詳細」から適切な参照ファイルを読む、または並列サブエージェント起動
7. 結果を統合してレビュー完了

### 入力の優先順位

- `files` が渡されている場合は **そのファイルのみ** を対象にレビューする
- `files` が渡されていない場合は `git_diff` から変更箇所を推定する
- `context_from: code_content` が渡されている場合は **その内容を優先** してレビューする

### Step 0: 品質判定ゲート（レビュー重点領域の特定）

レビュー開始前に変更内容を分析し、重点領域を特定:

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

#### カバレッジ判定

| 状況 | 指摘内容 |
|------|---------|
| 新規ファイルにテストなし | 「テストが不足しています」 |
| 変更ファイルのテストが古い | 「テストの更新を検討してください」 |
| カバレッジ < 60% | 「カバレッジ向上を推奨」 |

#### セキュリティ重点レビュー

| パス | 追加チェック項目 |
|------|-----------------|
| auth/, api/ | OWASP Top 10 チェックリスト |
| 入力処理 | サニタイズ、バリデーション |
| DB クエリ | パラメータ化確認 |

#### a11y 重点レビュー

| パス | チェック項目 |
|------|------------|
| src/components/ | alt, aria, キーボード操作 |
| src/pages/ | 見出し構造, フォーカス管理 |

#### パフォーマンス重点レビュー

| パターン | 警告内容 |
|---------|---------|
| ループ内 DB クエリ | N+1 クエリの可能性 |
| 大規模データ処理 | ページネーション検討 |
| useEffect 乱用 | レンダリング最適化 |

#### SEO/OGP 重点レビュー

| パス | チェック項目 |
|------|------------|
| src/pages/, app/ | title, description, canonical |
| public/ | robots.txt, sitemap.xml, OGP 画像 |
| layout.tsx, _document.tsx | viewport, OGP タグ, Twitter Card |

#### クロスプラットフォーム重点レビュー

| パス | チェック項目 |
|------|------------|
| src/components/, app/ | レスポンシブ（固定幅チェック） |
| *.css, *.scss, tailwind | 100vw 使用、overflow 設定 |
| public/ | favicon, apple-touch-icon |

#### 重点レビュー統合出力

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

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

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

#### LSP ベースの影響分析（推奨）

変更レビュー時に LSP ツールで影響範囲を確認:

| 変更タイプ | LSP 操作 | 確認内容 |
|-----------|---------|---------|
| 関数シグネチャ変更 | findReferences | 全呼び出し元が対応済みか |
| 型定義変更 | findReferences | 使用箇所での型互換性 |
| API 変更 | incomingCalls | 影響を受けるエンドポイント |

**レビューフロー**:
1. 変更ファイルを特定
2. `LSP.findReferences` で影響範囲を列挙
3. 影響を受けるファイルも含めてレビュー

**使用例**:
```
# 1. 変更された関数の参照箇所を確認
LSP operation=findReferences filePath="src/api/user.ts" line=42 character=15

# 2. 関数の呼び出し階層を確認
LSP operation=incomingCalls filePath="src/api/user.ts" line=42 character=15

# 3. 型定義の使用箇所を確認
LSP operation=findReferences filePath="src/types/api.ts" line=10 character=12
```

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

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

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

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

> **注**: LSP サーバーが設定されている言語でのみ動作します。

### Step 1: 残コンテキスト確認（Codex モード時）

Codex モード（`review.mode: codex`）の場合は、**残コンテキストが 30%以下なら /compact を先に実行**してください。

> **注意**: /compact 後も余裕が少ない場合は縮退せず続行します。

### Step 2: 過去のレビュー指摘検索（Memory-Enhanced）

Claude-mem が有効な場合、レビュー開始前に過去の類似指摘を検索:

```
# mem-search で過去のレビュー指摘を検索
mem-search: type:review "{変更ファイルのパターン}"
mem-search: concepts:security "{セキュリティ関連のキーワード}"
mem-search: concepts:gotcha "{変更箇所に関連するキーワード}"
```

**表示例**:

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

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

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

> **注**: Claude-mem が未設定の場合、このステップはスキップされます。

## レビューモードの選択

レビュースキルは 2 つのモードで動作します:

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

### Default モード（Claude 単体）

Claude が直接レビューを実行。小〜中規模の変更に最適。

### Codex モード（並列エキスパート）

Codex MCP 経由で**最大 8 つの専門エキスパート**を **個別に並列呼び出し**（不要なエキスパートは除外）:

| エキスパート | 観点 | プロンプトファイル |
|-------------|------|-------------------|
| Security | OWASP Top 10、認証、インジェクション | `experts/security-expert.md` |
| Accessibility | WCAG 2.1 AA、セマンティック HTML | `experts/accessibility-expert.md` |
| Performance | N+1 クエリ、レンダリング、アルゴリズム | `experts/performance-expert.md` |
| Quality | 可読性、保守性、ベストプラクティス | `experts/quality-expert.md` |
| SEO | メタタグ、OGP、サイトマップ | `experts/seo-expert.md` |
| Architect | 設計、トレードオフ、スケーラビリティ | `experts/architect-expert.md` |
| Plan Reviewer | 計画の完全性、明確性、検証可能性 | `experts/plan-reviewer-expert.md` |
| Scope Analyst | 要件分析、曖昧さ検出、リスク | `experts/scope-analyst-expert.md` |

#### ⚠️ Codex モード実行時の必須ルール

**絶対に1回の MCP 呼び出しで複数エキスパートをまとめないこと。**

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

**実行手順**:
1. **呼び出すエキスパートを判定**（全部ではなく必要なもののみ）:
   - 設定で `enabled: false` → 除外
   - CLI/バックエンド → Accessibility, SEO 除外
   - ドキュメントのみ変更 → Quality, Architect, Plan Reviewer, Scope Analyst を優先（Security, Performance は除外可）
2. 有効なエキスパートの `experts/*.md` からプロンプトを **個別に読み込む**
3. 有効なエキスパートのみ `mcp__codex__codex` を **1つのレスポンス内で並列実行**
4. 各結果を統合して判定

**詳細**: [codex-review/references/codex-parallel-review.md](../codex-review/references/codex-parallel-review.md)

**Codex モード有効化**:
```bash
/codex-mode on
```

**詳細**: [references/codex-integration.md](references/codex-integration.md)

---

## 並列サブエージェント起動（Default モード）

以下の条件を**両方**満たす場合、Task tool で code-reviewer を並列起動:

- レビュー観点 >= 2（例: セキュリティ + パフォーマンス）
- 変更ファイル >= 5

**起動パターン（1つのレスポンス内で複数の Task tool を同時呼び出し）:**

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

**小規模な場合（条件を満たさない）:**
- 子スキル（doc.md）を順次読み込んで直列実行

---

## 🔧 LSP 機能の活用

レビューでは LSP（Language Server Protocol）を活用して精度を向上します。

### LSP をレビューに統合

| レビュー観点 | LSP 活用方法 |
|-------------|-------------|
| **品質** | Diagnostics で型エラー・未使用変数を自動検出 |
| **セキュリティ** | Find-references で機密データの流れを追跡 |
| **パフォーマンス** | Go-to-definition で重い処理の実装を確認 |

### LSP Diagnostics の出力例

```
📊 LSP 診断結果

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

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

### Find-references による影響分析

```
🔍 変更影響分析

変更: validateInput()

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

→ テストでカバー済み ✅
```

詳細: [docs/LSP_INTEGRATION.md](../../docs/LSP_INTEGRATION.md)

---

## VibeCoder 向け

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

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

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

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

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

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


---

## Referenced Files

> The following files are referenced in this skill and included for context.

### references/changes-review.md

```markdown
---
name: review-changes
description: "自分の変更をセルフレビューし、改善提案を出す。コード変更後のセルフレビューが必要な場合に使用します。"
allowed-tools: ["Read", "Grep", "Bash"]
---

# Review Changes

実装した変更をセルフレビューし、品質を確認するスキル。
コミット前やハンドオフ前に使用します。

---

## 入力

- **変更ファイル**: git diff で特定された変更
- **リポジトリコンテキスト**: コーディング規約、既存パターン

---

## 出力

- **レビュー結果**: 各観点での評価
- **改善提案**: 問題がある場合の修正提案

---

## レビュー観点

### 1. セキュリティ 🔒

- [ ] 機密情報（API キー等）がハードコードされていない
- [ ] 入力値のバリデーションが適切
- [ ] SQL インジェクション対策
- [ ] XSS 対策

### 2. パフォーマンス ⚡

- [ ] 不要な再レンダリングがない
- [ ] N+1 クエリがない
- [ ] 重い計算がメモ化されている

### 3. コード品質 📐

- [ ] 型が適切に定義されている
- [ ] エラーハンドリングがある
- [ ] 命名が適切
- [ ] 不要なコード・コメントがない

### 4. 一貫性 🎨

- [ ] 既存のコーディングスタイルに従っている
- [ ] ファイル構成が適切
- [ ] import の順序が統一されている

---

## 実行手順

### Step 1: 変更の確認

```bash
# 変更ファイル一覧
git diff --name-only HEAD~5

# 変更内容
git diff
```

### Step 2: 各観点でのチェック

#### セキュリティチェック

```bash
# ハードコードされた機密情報を探す
grep -rn "sk-\|api_key\|password\|secret" --include="*.ts" --include="*.tsx" | grep -v ".env"
```

#### パフォーマンスチェック

```typescript
// 問題のパターンを探す
// - useEffect の依存配列の問題
// - 毎レンダリングで新しいオブジェクト生成
// - 巨大な配列の filter/map チェーン
```

#### コード品質チェック

```bash
# TypeScript エラー
npx tsc --noEmit

# ESLint
npx eslint src/ --ext .ts,.tsx
```

### Step 3: レビュー結果の生成

```markdown
## 📊 セルフレビュー結果

**対象**: {{変更ファイル数}} ファイル
**総合評価**: {{A / B / C}}

### 観点別評価

| 観点 | 評価 | 備考 |
|------|------|------|
| セキュリティ | ✅ OK | - |
| パフォーマンス | ⚠️ 要確認 | {{詳細}} |
| コード品質 | ✅ OK | - |
| 一貫性 | ✅ OK | - |

### 改善が必要な箇所

1. **{{ファイル:行}}**
   - 問題: {{問題の説明}}
   - 改善案: {{具体的な修正方法}}

### 自動修正可能な項目

- [ ] ESLint の自動修正
- [ ] Prettier の適用
```

### Step 4: 改善の適用（任意）

```bash
# ESLint 自動修正
npx eslint --fix src/

# Prettier 適用
npx prettier --write src/
```

---

## 評価基準

| 評価 | 意味 | アクション |
|------|------|-----------|
| A | 問題なし | コミット可能 |
| B | 軽微な問題あり | 修正推奨だが続行可 |
| C | 重大な問題あり | 修正必須 |

---

## よくある問題と修正

### any 型の使用

```typescript
// ❌ 問題
function process(data: any) { ... }

// ✅ 修正
interface DataType { ... }
function process(data: DataType) { ... }
```

### 未処理の Promise

```typescript
// ❌ 問題
fetchData()

// ✅ 修正
fetchData().catch(console.error)
// または
await fetchData()
```

### 不要な再レンダリング

```typescript
// ❌ 問題
const items = data.filter(x => x.active).map(x => x.name)

// ✅ 修正
const items = useMemo(() =>
  data.filter(x => x.active).map(x => x.name),
  [data]
)
```

---

## 完了後のアクション

```markdown
## ✅ セルフレビュー完了

**評価**: {{A / B / C}}

{{問題なしの場合}}
コミットの準備ができました。
「コミットして」と言ってください。

{{問題ありの場合}}
上記の改善を適用しますか？
```

---

## 注意事項

- **完璧を目指さない**: 80% で十分
- **自動ツールを活用**: 手動チェックは最小限に
- **レビューは任意**: スキップしてコミットも可能

```

### references/quality-review.md

```markdown
---
name: review-quality
description: "コード品質（可読性、保守性、ベストプラクティス）をチェックするスキル。コードレビューが要求された場合、リファクタリング後、または複雑なロジックの実装後に使用します。"
allowed-tools: ["Read", "Grep", "Glob", "Bash"]
---

# Review Quality

コードの品質（可読性、保守性、ベストプラクティス）をチェックするスキル。

---

## 目的

以下の観点でコード品質を評価：
- 可読性（命名、構造、コメント）
- 保守性（モジュール性、依存関係）
- ベストプラクティス準拠
- コーディング規約準拠

---

## 入力

| 項目 | 説明 |
|------|------|
| `files` | チェック対象ファイルのリスト |
| `code_content` | ファイルの内容 |
| `eslint_output` | ESLint/Linter の出力（あれば） |

---

## 出力

| 項目 | 説明 |
|------|------|
| `quality_issues` | 検出された問題のリスト |
| `quality_score` | 品質スコア (A-F) |

---

## チェック項目

### 1. 可読性

| チェック | 問題 | 改善 |
|---------|------|------|
| 命名 | `x`, `tmp`, `data` などの曖昧な名前 | 意味のある名前に変更 |
| 関数の長さ | 50行以上の関数 | 小さな関数に分割 |
| ネスト深度 | 4段階以上のネスト | 早期リターン、関数抽出 |
| マジックナンバー | 直書きの数値 | 定数化 |

### 2. 保守性

| チェック | 問題 | 改善 |
|---------|------|------|
| 重複コード | 同じロジックの繰り返し | 共通関数に抽出 |
| 密結合 | 直接的な依存関係 | 依存性注入、インターフェース |
| グローバル状態 | グローバル変数の多用 | スコープの限定 |
| 未使用コード | 使われていない変数・関数 | 削除 |

### 3. ベストプラクティス

| チェック | 問題 | 改善 |
|---------|------|------|
| エラーハンドリング | 空の catch ブロック | 適切なエラー処理 |
| 型安全性 | any 型の多用 | 適切な型定義 |
| 非同期処理 | コールバック地獄 | async/await |
| テスタビリティ | テストしにくい構造 | 依存性注入 |

---

## スコアリング

| スコア | 基準 |
|--------|------|
| A | クリーンコード、問題なし |
| B | 軽微な改善余地 |
| C | 中程度の問題あり |
| D | 可読性・保守性に問題 |
| F | 深刻な品質問題 |

---

## 出力例

```markdown
## コード品質レビュー結果

**スコア**: B

### 検出された問題

| 重大度 | ファイル | 行 | 問題 |
|--------|---------|-----|------|
| 中 | src/services/user.ts | 45 | 関数が長すぎる (78行) |
| 低 | src/utils/helpers.ts | 12 | 未使用の import |
| 低 | src/api/posts.ts | 89 | マジックナンバー使用 |

### 推奨改善

1. **長い関数の分割**
   - `processUserData` 関数を以下に分割:
     - `validateUserInput()`
     - `formatUserData()`
     - `saveUser()`

2. **未使用コードの削除**
   - `import { unused } from './utils'` を削除

3. **定数化**
   ```typescript
   // Before
   if (retryCount > 3) { ... }

   // After
   const MAX_RETRY_COUNT = 3;
   if (retryCount > MAX_RETRY_COUNT) { ... }
   ```
```

---

### 4. クロスプラットフォーム

| チェック | 問題 | 重大度 | 改善 |
|---------|------|--------|------|
| レスポンシブ未対応 | 固定幅（`width: 1200px`）、viewport meta 未設定 | 中 | `max-width` + メディアクエリ |
| スクロールバー問題 | `100vw` 使用による横スクロール | 低 | `100%` または `calc(100vw - スクロールバー幅)` |
| 長文入力未対応 | overflow/truncate 未設定で UI 崩れ | 低 | `overflow-hidden`, `text-overflow: ellipsis` |
| フォント未指定 | system-ui/font-family 未設定 | 低 | システムフォントスタック指定 |
| タッチターゲット | 小さすぎるボタン（< 44px） | 中 | 最小 44x44px |

**検出パターン**:
```css
/* ❌ 問題: 固定幅 */
.container { width: 1200px; }

/* ✅ 改善: レスポンシブ */
.container { max-width: 1200px; width: 100%; }

/* ❌ 問題: 100vw（スクロールバーで崩れる） */
.full-width { width: 100vw; }

/* ✅ 改善 */
.full-width { width: 100%; }
```

### 5. Web 基盤チェック

| チェック | 問題 | 重大度 | 改善 |
|---------|------|--------|------|
| favicon 未設定 | ブラウザタブにアイコンなし | 低 | `<link rel="icon">` 追加 |
| apple-touch-icon 未設定 | iOS ホーム画面追加時のアイコンなし | 低 | `<link rel="apple-touch-icon">` 追加 |
| 404/5xx ページ | デフォルトエラーページ | 低 | カスタムエラーページ作成 |
| lang 属性未設定 | `<html>` に lang なし | 低 | `<html lang="ja">` 追加 |
| charset 未設定 | 文字化けリスク | 低 | `<meta charset="UTF-8">` 追加 |

**検出パターン**:
```html
<!-- ❌ 問題: 基本設定なし -->
<html>
<head>
  <title>My App</title>
</head>

<!-- ✅ 改善: 基本設定あり -->
<html lang="ja">
<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <link rel="icon" href="/favicon.ico">
  <link rel="apple-touch-icon" href="/apple-touch-icon.png">
  <title>My App</title>
</head>
```

### 6. LocalStorage / Cookie 管理

| チェック | 問題 | 重大度 | 改善 |
|---------|------|--------|------|
| 有効期限なし | 永続的なデータ保存 | 低 | 適切な有効期限設定（7日推奨） |
| サードパーティ Cookie 依存 | ブロックされる可能性 | 中 | ファーストパーティへ移行 |
| 機密情報の保存 | LocalStorage にトークン等 | 中 | HttpOnly Cookie へ移行 |

---

## 注意事項

- プロジェクトの既存スタイルを尊重する
- 過度な改善提案は避ける
- 優先度を付けて報告する
- フレームワーク固有の機能を考慮する（Next.js App Router, Remix, etc.）

```

### references/security-review.md

```markdown
---
name: review-security
description: "コードのセキュリティ脆弱性をチェックするスキル。セキュリティレビューが要求された場合、本番デプロイ前、または機密情報を扱うコードの変更時に使用します。"
allowed-tools: ["Read", "Grep", "Glob", "Bash"]
---

# Review Security

コードのセキュリティ脆弱性をチェックし、問題を報告するスキル。

---

## 目的

OWASP Top 10 を含む一般的なセキュリティ脆弱性を検出：
- インジェクション攻撃（SQL, コマンド, XSS）
- 認証・認可の問題
- 機密データの露出
- セキュリティの設定ミス

---

## 入力

| 項目 | 説明 |
|------|------|
| `files` | チェック対象ファイルのリスト |
| `code_content` | ファイルの内容 |

---

## 出力

| 項目 | 説明 |
|------|------|
| `security_issues` | 検出された問題のリスト |
| `security_score` | セキュリティスコア (A-F) |

---

## チェック項目

### 1. インジェクション

| チェック | 検出対象 |
|---------|----------|
| SQL インジェクション | 文字列連結でのクエリ構築 |
| コマンドインジェクション | 安全でないコマンド実行関数の使用 |
| XSS | 未サニタイズのHTML出力 |

### 2. 認証・認可

| チェック | 検出対象 |
|---------|----------|
| ハードコードされた認証情報 | パスワード、APIキーの直書き |
| 弱い認証 | 平文パスワード保存 |
| 認可チェック漏れ | 権限確認なしのリソースアクセス |

### 3. 機密データ

| チェック | 検出対象 |
|---------|----------|
| 機密情報のログ出力 | パスワード、トークンのログ |
| 安全でない通信 | HTTP での機密データ送信 |
| .env ファイルのコミット | git に含まれる機密ファイル |

### 4. 設定ミス

| チェック | 検出対象 |
|---------|----------|
| デバッグモード有効 | 本番での DEBUG=true |
| CORS 設定ミス | 過度に寛容なオリジン設定 |
| セキュリティヘッダー欠如 | CSP, X-Frame-Options の未設定 |

---

## スコアリング

| スコア | 基準 |
|--------|------|
| A | 問題なし |
| B | 軽微な問題 1-2 件 |
| C | 中程度の問題あり |
| D | 重大な問題あり |
| F | クリティカルな脆弱性あり |

---

## 出力例

```markdown
## セキュリティレビュー結果

**スコア**: B

### 検出された問題

| 重大度 | ファイル | 行 | 問題 |
|--------|---------|-----|------|
| 中 | src/api/users.ts | 45 | SQL インジェクションの可能性 |
| 低 | src/config.ts | 12 | ハードコードされた API URL |

### 推奨対策

1. **SQL インジェクション対策**
   - プレースホルダーを使用したクエリに変更
   - ORM のパラメータバインディングを活用

2. **設定の外部化**
   - API URL を環境変数に移動
```

---

### 5. Cookie セキュリティ

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| HttpOnly 未設定 | 認証 Cookie が JS からアクセス可能（`document.cookie` で読める） | 高 |
| SameSite 未設定/None | CSRF 脆弱性のリスク、クロスサイトリクエスト許可 | 高 |
| Secure 未設定 | HTTP 経由での Cookie 送信（盗聴リスク） | 高 |
| Domain 過度に広い | サブドメイン間での不正アクセス（`.example.com` 等） | 中 |
| 有効期限が長すぎる | セッション Cookie に長期 Expires 設定 | 中 |

**検出パターン**:
```typescript
// ❌ 問題のある設定
res.cookie('session', token);  // オプションなし
res.cookie('auth', token, { httpOnly: false });
document.cookie = "session=...";  // クライアントサイドでの設定

// ✅ 安全な設定
res.cookie('session', token, {
  httpOnly: true,
  secure: true,
  sameSite: 'strict',
  domain: 'example.com'  // 明示的に制限
});
```

### 6. レスポンスヘッダー

| ヘッダー | 必須度 | 検出対象 | 効果 |
|---------|--------|----------|------|
| `Strict-Transport-Security` | 必須 | HSTS 未設定（HTTP ダウングレード攻撃） | HTTPS 強制 |
| `X-Content-Type-Options: nosniff` | 必須 | MIME スニッフィング許可 | XSS 防止 |
| `Content-Security-Policy` | 推奨 | CSP 未設定（インラインスクリプト許可） | XSS 防止 |
| `X-Frame-Options` / CSP `frame-ancestors` | 推奨 | フレーム埋め込み許可 | クリックジャッキング防止 |
| `Referrer-Policy` | 推奨 | 未設定（リファラ漏洩） | プライバシー保護 |

**検出パターン**:
```typescript
// チェック対象: レスポンスヘッダー設定箇所
// - middleware.ts
// - server.ts / app.ts
// - next.config.js (headers)
// - vercel.json / netlify.toml

// ❌ 問題: ヘッダー未設定
app.use((req, res, next) => next());

// ✅ 推奨: セキュリティヘッダー設定
app.use(helmet());  // または個別設定
res.setHeader('Strict-Transport-Security', 'max-age=31536000; includeSubDomains');
res.setHeader('X-Content-Type-Options', 'nosniff');
res.setHeader('X-Frame-Options', 'DENY');
```

### 7. リダイレクト・ファイルアップロード

#### オープンリダイレクト

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| 未検証リダイレクト | ユーザー入力を直接 `redirect()` に渡す | 高 |
| URL パラメータの利用 | `?returnUrl=` `?next=` `?redirect=` | 高 |
| 外部ドメインへのリダイレクト | 許可リストなしでの外部リダイレクト | 高 |

**検出パターン**:
```typescript
// ❌ 危険: 未検証リダイレクト
const returnUrl = req.query.returnUrl;
res.redirect(returnUrl);

// ✅ 安全: ホワイトリスト検証
const allowedHosts = ['example.com', 'app.example.com'];
const url = new URL(returnUrl, 'https://example.com');
if (allowedHosts.includes(url.hostname)) {
  res.redirect(returnUrl);
}
```

#### ファイルアップロード

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| MIME タイプ未検証 | Content-Type のみ信頼（偽装可能） | 高 |
| 拡張子未検証 | `.php`, `.exe` 等の危険な拡張子許可 | 高 |
| ファイルサイズ未検証 | 無制限アップロード（DoS リスク） | 中 |
| パストラバーサル | `../` を含むファイル名の未サニタイズ | 高 |
| マジックバイト未検証 | ファイルヘッダーの検証なし | 中 |

**検出パターン**:
```typescript
// ❌ 危険: 未検証アップロード
app.post('/upload', (req, res) => {
  const file = req.files.upload;
  file.mv(`./uploads/${file.name}`);  // パストラバーサル可能
});

// ✅ 安全: 複数層の検証
const allowedMimeTypes = ['image/jpeg', 'image/png', 'application/pdf'];
const allowedExtensions = ['.jpg', '.jpeg', '.png', '.pdf'];
const maxFileSize = 10 * 1024 * 1024;  // 10MB

// 1. サイズチェック
if (file.size > maxFileSize) throw new Error('File too large');

// 2. 拡張子チェック
const ext = path.extname(file.name).toLowerCase();
if (!allowedExtensions.includes(ext)) throw new Error('Invalid extension');

// 3. MIME タイプチェック（マジックバイト推奨）
if (!allowedMimeTypes.includes(file.mimetype)) throw new Error('Invalid type');

// 4. ファイル名サニタイズ
const safeName = crypto.randomUUID() + ext;
```

### 8. 決済セキュリティ

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| 重複課金 | 冪等性キーの未使用 | 高 |
| 金額改ざん | クライアントサイドでの金額決定 | 高 |
| 状態不整合 | 決済プロバイダとアプリ状態の不一致 | 高 |
| Webhook 未検証 | 署名検証なしの Webhook 処理 | 高 |

**検出パターン**:
```typescript
// ❌ 危険: クライアントから金額を受け取る
const { amount, productId } = req.body;
await stripe.paymentIntents.create({ amount });

// ✅ 安全: サーバーサイドで金額を決定
const product = await db.products.findUnique({ where: { id: productId } });
await stripe.paymentIntents.create({
  amount: product.price,
  idempotencyKey: `order_${orderId}`  // 冪等性キー
});

// ✅ Webhook 署名検証
const sig = req.headers['stripe-signature'];
const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);
```

---

## 注意事項

- false positive を減らすためコンテキストを考慮する
- セキュリティ問題は優先度高で報告する
- 修正方法も合わせて提示する
- フレームワーク固有のセキュリティ機能を考慮する（Next.js, Express, etc.）

```

### references/performance-review.md

```markdown
---
name: review-performance
description: "コードのパフォーマンス問題をチェックするスキル。パフォーマンスレビューが要求された場合、レスポンスが遅いと報告された場合、または大量のデータ処理を行うコードの変更時に使用します。"
allowed-tools: ["Read", "Grep", "Glob", "Bash"]
---

# Review Performance

コードのパフォーマンス問題を検出し、改善提案を行うスキル。

---

## 目的

以下のパフォーマンス問題を検出：
- 非効率なアルゴリズム
- 不要な再レンダリング
- N+1 クエリ問題
- メモリリーク
- 重い処理のブロッキング

---

## 入力

| 項目 | 説明 |
|------|------|
| `files` | チェック対象ファイルのリスト |
| `code_content` | ファイルの内容 |

---

## 出力

| 項目 | 説明 |
|------|------|
| `performance_issues` | 検出された問題のリスト |
| `performance_score` | パフォーマンススコア (A-F) |

---

## チェック項目

### 1. フロントエンド（React/Vue）

| チェック | 問題 | 対策 |
|---------|------|------|
| 不要な再レンダリング | `useCallback`, `useMemo` 未使用 | メモ化の追加 |
| 大きなリストの非仮想化 | 1000+ アイテムの直接レンダリング | 仮想スクロール導入 |
| 重い計算の同期実行 | レンダリングブロック | Web Worker 使用 |
| バンドルサイズ | 大きな依存関係のインポート | 動的インポート |

### 2. バックエンド（API）

| チェック | 問題 | 対策 |
|---------|------|------|
| N+1 クエリ | ループ内でのDBクエリ | Eager loading |
| インデックス未使用 | 大量データのフルスキャン | インデックス追加 |
| 同期I/O | ファイル操作のブロッキング | async/await 使用 |
| キャッシュ未使用 | 頻繁な同一クエリ | Redis キャッシュ |

### 3. 一般

| チェック | 問題 | 対策 |
|---------|------|------|
| O(n²) アルゴリズム | ネストしたループ | より効率的なアルゴリズム |
| 文字列連結 | ループ内での `+=` | 配列 + join |
| 正規表現の非効率 | 毎回のコンパイル | 事前コンパイル |

---

## スコアリング

| スコア | 基準 |
|--------|------|
| A | 問題なし、最適化済み |
| B | 軽微な改善余地あり |
| C | 中程度の問題あり |
| D | 明らかなボトルネックあり |
| F | 深刻なパフォーマンス問題 |

---

## 出力例

```markdown
## パフォーマンスレビュー結果

**スコア**: C

### 検出された問題

| 重大度 | ファイル | 行 | 問題 |
|--------|---------|-----|------|
| 高 | src/api/posts.ts | 23 | N+1 クエリ問題 |
| 中 | src/components/List.tsx | 45 | 1500件の非仮想化リスト |
| 低 | src/utils/search.ts | 12 | O(n²) の検索アルゴリズム |

### 推奨対策

1. **N+1 クエリ問題**
   ```typescript
   // Before
   for (const post of posts) {
     const author = await getAuthor(post.authorId);
   }

   // After
   const posts = await getPosts({ include: ['author'] });
   ```

2. **仮想スクロール導入**
   - react-window または react-virtualized を使用
```

---

## 注意事項

- 早期最適化は避け、実際のボトルネックを優先
- 測定可能な改善効果を示す
- トレードオフ（可読性 vs パフォーマンス）を考慮

```

### references/accessibility-review.md

```markdown
---
name: review-accessibility
description: "Webアクセシビリティ（a11y）をチェックするスキル。Webアプリケーションのアクセシビリティレビューが要求された場合に使用します。"
allowed-tools: ["Read", "Grep", "Bash"]
---

# Review Accessibility

Web アクセシビリティ（a11y）をチェックし、WCAG ガイドラインへの準拠を確認するスキル。

---

## 目的

以下のアクセシビリティ問題を検出：
- セマンティック HTML の使用
- ARIA 属性の適切な使用
- キーボード操作対応
- 色コントラスト
- スクリーンリーダー対応

---

## 入力

| 項目 | 説明 |
|------|------|
| `files` | チェック対象ファイルのリスト |
| `tech_stack` | フレームワーク（React, Vue など） |

---

## 出力

| 項目 | 説明 |
|------|------|
| `a11y_issues` | 検出された問題のリスト |
| `a11y_score` | アクセシビリティスコア (A-F) |

---

## チェック項目

### 1. セマンティック HTML

| チェック | 問題 | 改善 |
|---------|------|------|
| 見出し構造 | h1 → h3 のスキップ | 正しい順序に修正 |
| ランドマーク | `<div>` のみの使用 | `<nav>`, `<main>`, `<aside>` 使用 |
| リスト構造 | 手動でのリスト作成 | `<ul>`, `<ol>` 使用 |
| ボタン | `<div onclick>` | `<button>` 使用 |

### 2. 画像とメディア

| チェック | 問題 | 改善 |
|---------|------|------|
| alt 属性 | 欠落または空 | 意味のある説明を追加 |
| 装飾画像 | alt に説明 | `alt=""` または `aria-hidden` |
| 動画 | 字幕なし | キャプション追加 |

### 3. フォーム

| チェック | 問題 | 改善 |
|---------|------|------|
| ラベル | `<label>` 欠落 | `<label for="id">` 追加 |
| エラーメッセージ | 色のみで表示 | テキストでも表示 |
| 必須フィールド | 視覚的のみ | `aria-required` 追加 |

### 4. キーボード操作

| チェック | 問題 | 改善 |
|---------|------|------|
| フォーカス管理 | フォーカス不可要素 | `tabindex="0"` 追加 |
| フォーカス表示 | `outline: none` のみ | 代替スタイル追加 |
| キーボードトラップ | モーダルからの脱出不可 | ESC キー対応 |

### 5. ARIA

| チェック | 問題 | 改善 |
|---------|------|------|
| 冗長な ARIA | `<button role="button">` | 不要な role 削除 |
| 無効な ARIA | 存在しない ID 参照 | 正しい ID に修正 |
| 動的コンテンツ | 変更の通知なし | `aria-live` 追加 |

---

## スコアリング

| スコア | 基準 |
|--------|------|
| A | WCAG 2.1 AA 準拠 |
| B | 軽微な問題のみ |
| C | 中程度の問題あり |
| D | 重大なアクセシビリティ問題 |
| F | 基本的なアクセシビリティ欠如 |

---

## 出力例

```markdown
## アクセシビリティレビュー結果

**スコア**: C

### 検出された問題

| 重大度 | ファイル | 行 | 問題 | WCAG |
|--------|---------|-----|------|------|
| 高 | src/components/Button.tsx | 12 | div を button として使用 | 4.1.2 |
| 中 | src/components/Image.tsx | 8 | alt 属性が空 | 1.1.1 |
| 低 | src/components/Modal.tsx | 45 | ESC キーでの閉じる未対応 | 2.1.2 |

### 推奨改善

1. **セマンティックなボタン**
   ```tsx
   // Before
   <div onClick={handleClick} className="button">Click</div>

   // After
   <button onClick={handleClick} className="button">Click</button>
   ```

2. **画像の alt 属性**
   ```tsx
   // Before
   <img src={user.avatar} />

   // After
   <img src={user.avatar} alt={`${user.name}のアバター`} />
   ```
```

---

## 注意事項

- WCAG 2.1 AA を基準とする
- 技術スタック（React/Vue）に応じたチェック
- 自動チェックで検出できない問題は手動確認を推奨

```

### references/seo-review.md

```markdown
---
name: review-seo
description: "SEO・OGP・メタ情報をチェックするスキル。ローンチ前レビュー、ページ追加時、またはSEO最適化が要求された場合に使用します。"
allowed-tools: ["Read", "Grep", "Glob", "Bash"]
---

# Review SEO & OGP

SEO 最適化と OGP タグをチェックし、検索エンジン・SNS シェア品質を向上するスキル。

---

## 目的

以下の観点で SEO/OGP を評価：
- 検索エンジン最適化（title, description, canonical）
- ソーシャルメディア対応（OGP, Twitter Card）
- クローラビリティ（robots.txt, sitemap）
- 技術的 SEO（構造化データ, ページ速度）

---

## 入力

| 項目 | 説明 |
|------|------|
| `files` | チェック対象ファイルのリスト |
| `pages` | ページ一覧（静的/動的） |
| `public_dir` | public ディレクトリのパス |

---

## 出力

| 項目 | 説明 |
|------|------|
| `seo_issues` | 検出された問題のリスト |
| `seo_score` | SEO スコア (A-F) |

---

## チェック項目

### 1. 基本メタタグ

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| `<title>` 欠落 | 全ページに設定されているか | 高 |
| `<title>` 重複 | 複数ページで同一タイトル | 中 |
| `<title>` 長さ | 60文字超過（検索結果で切れる） | 低 |
| `<meta name="description">` 欠落 | 重要ページに設定されているか | 中 |
| `<meta name="description">` 長さ | 160文字超過 | 低 |
| canonical URL 欠落 | 重要ページに `<link rel="canonical">` | 中 |
| viewport 未設定 | モバイル対応必須 | 高 |

**検出パターン**:
```tsx
// ❌ 問題: メタタグなし
export default function Page() {
  return <div>Content</div>;
}

// ✅ 改善: Next.js App Router
export const metadata = {
  title: 'ページタイトル | サイト名',
  description: 'ページの説明文（160文字以内）',
  alternates: { canonical: 'https://example.com/page' }
};

// ✅ 改善: HTML
<head>
  <title>ページタイトル | サイト名</title>
  <meta name="description" content="ページの説明文">
  <link rel="canonical" href="https://example.com/page">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>
```

### 2. OGP（Open Graph Protocol）

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| `og:title` 欠落 | シェア可能ページに設定されているか | 中 |
| `og:description` 欠落 | 適切な説明があるか | 中 |
| `og:image` 欠落 | 画像が設定されているか | 中 |
| `og:image` サイズ | 1200x630px 推奨 | 低 |
| `og:url` 不一致 | canonical と一致しているか | 低 |
| `og:type` 欠落 | `website`, `article` 等 | 低 |

**検出パターン**:
```tsx
// ✅ Next.js App Router
export const metadata = {
  openGraph: {
    title: 'ページタイトル',
    description: '説明文',
    url: 'https://example.com/page',
    siteName: 'サイト名',
    images: [{ url: 'https://example.com/og-image.png', width: 1200, height: 630 }],
    locale: 'ja_JP',
    type: 'website',
  },
};

// ✅ HTML
<meta property="og:title" content="ページタイトル">
<meta property="og:description" content="説明文">
<meta property="og:image" content="https://example.com/og-image.png">
<meta property="og:url" content="https://example.com/page">
<meta property="og:type" content="website">
```

### 3. Twitter Card

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| `twitter:card` 欠落 | `summary_large_image` 推奨 | 低 |
| `twitter:title` 欠落 | OGP と重複可 | 低 |
| `twitter:description` 欠落 | OGP と重複可 | 低 |
| `twitter:image` 欠落 | OGP と重複可 | 低 |

**検出パターン**:
```tsx
// ✅ Next.js App Router
export const metadata = {
  twitter: {
    card: 'summary_large_image',
    title: 'ページタイトル',
    description: '説明文',
    images: ['https://example.com/twitter-image.png'],
  },
};
```

### 4. クローラビリティ

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| robots.txt 欠落 | `public/robots.txt` が存在するか | 中 |
| robots.txt 全拒否 | `Disallow: /` で全ページブロック | 高 |
| sitemap.xml 欠落 | 存在するか | 低 |
| noindex 残存 | 開発中の `<meta name="robots" content="noindex">` | 高 |

**検出パターン**:
```bash
# チェック対象
public/robots.txt
public/sitemap.xml
app/robots.ts (Next.js)
app/sitemap.ts (Next.js)
```

```txt
# ✅ 推奨 robots.txt
User-agent: *
Allow: /
Sitemap: https://example.com/sitemap.xml

# ❌ 危険: 全拒否
User-agent: *
Disallow: /
```

### 5. HTTP ステータス

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| エラーページ 200 | 404/500 が 200 を返す | 高 |
| リダイレクトチェーン | 3回以上のリダイレクト | 中 |
| soft 404 | 存在しないページが 200 を返す | 高 |

**検出パターン**:
```typescript
// ❌ 問題: エラーページが 200 を返す
export default function NotFound() {
  return <div>Page not found</div>;  // ステータス 200
}

// ✅ 改善: 正しいステータスコード
// app/not-found.tsx (Next.js App Router は自動で 404)
export default function NotFound() {
  return <div>Page not found</div>;
}
```

### 6. 構造化データ（オプション）

| チェック | 検出対象 | 重大度 |
|---------|----------|--------|
| JSON-LD 欠落 | 記事、商品、FAQ 等に推奨 | 低 |
| JSON-LD エラー | 構文エラー、必須フィールド欠落 | 中 |

---

## スコアリング

| スコア | 基準 |
|--------|------|
| A | 全項目クリア |
| B | 軽微な問題のみ（低重大度 1-2件） |
| C | 中程度の問題あり |
| D | 重大な問題あり（noindex 残存等） |
| F | 基本的な SEO 欠如 |

---

## 出力例

```markdown
## SEO/OGP レビュー結果

**スコア**: C

### 検出された問題

| 重大度 | ファイル | 問題 |
|--------|---------|------|
| 高 | app/layout.tsx | viewport meta 未設定 |
| 高 | public/robots.txt | 存在しない |
| 中 | app/about/page.tsx | title が他ページと重複 |
| 中 | app/blog/[slug]/page.tsx | OGP image 未設定 |
| 低 | app/page.tsx | description が 180 文字（160 推奨） |

### 推奨改善

1. **viewport 設定**
   ```tsx
   // app/layout.tsx
   export const metadata = {
     viewport: 'width=device-width, initial-scale=1.0',
   };
   ```

2. **robots.txt 作成**
   ```txt
   User-agent: *
   Allow: /
   Sitemap: https://example.com/sitemap.xml
   ```

3. **OGP 画像設定**
   - 1200x630px の画像を用意
   - 各ページに設定
```

---

## 注意事項

- フレームワーク固有の SEO 機能を考慮する（Next.js Metadata API, Remix meta 等）
- 動的ページ（`[slug]`）は代表的なパターンでチェック
- 構造化データは Google Rich Results Test で検証推奨
- Core Web Vitals はパフォーマンスレビューで別途チェック

```

### references/codex-integration.md

```markdown
---
name: codex-integration
description: "レビュースキルへの Codex セカンドオピニオン統合手順"
allowed-tools: ["Read", "Bash"]
---

# Codex 統合レビュー

既存のレビューフローに Codex のセカンドオピニオンを統合する手順。

---

## 🎯 概要

Codex MCP が有効な場合、Claude のレビューに加えて Codex からもレビューを取得し、結果を統合して表示します。

```
/harness-review 実行
    ↓
設定確認: review.codex.enabled
    │
    ├── false → Claude 単独レビュー（従来通り）
    │
    └── true → Codex 統合レビュー
            │
            ├── Claude レビュー（並列）
            └── Codex MCP 呼び出し（並列）
                    ↓
            結果統合 → 出力
```

---

## 実行フロー

### Step 1: 設定確認

`.claude-code-harness.config.yaml` を確認:

```yaml
review:
  codex:
    enabled: true   # これが true の場合のみ Codex 統合
    auto: false     # false の場合は確認を求める
```

### Step 2: 確認プロンプト（auto: false の場合）

```markdown
🤖 Codex セカンドオピニオン

Codex にもレビューを依頼しますか？
- Claude と Codex の両方でレビューし、結果を統合します
- 追加で数秒〜数十秒かかります

[Y] はい / [N] いいえ
```

### Step 3: 並列レビュー実行

**Claude レビュー（従来通り）**:
- 品質判定ゲート
- 変更ファイル分析
- 重点領域のレビュー

**Codex MCP 呼び出し（並列）**:
```
MCP 呼び出し: mcp__codex__*
    prompt: "{設定ファイルのプロンプト}"
    files: "{変更ファイル一覧}"
```

### Step 4: 結果統合

両方のレビュー結果を統合して表示:

```markdown
## 📊 統合レビュー結果

### Claude のレビュー

| 観点 | 指摘数 | 重要度 |
|------|--------|--------|
| セキュリティ | 1 | 高 |
| 品質 | 3 | 中 |
| パフォーマンス | 0 | - |

**主な指摘**:
1. [高] SQL インジェクションの可能性 (src/api/users.ts:45)
2. [中] 未使用の import (src/components/Form.tsx:3)
3. ...

---

### Codex のレビュー（セカンドオピニオン）

| 観点 | 指摘数 |
|------|--------|
| コードスタイル | 2 |
| 設計パターン | 1 |

**主な指摘**:
1. 関数が長すぎる（50行超）→ 分割を推奨
2. 命名規則の不統一（camelCase と snake_case の混在）
3. Strategy パターンの適用を検討

---

### 統合サマリ

| 観点 | Claude | Codex | アクション |
|------|--------|-------|-----------|
| セキュリティ | ⚠️ 1件 | - | **対応必須** |
| コードスタイル | - | 2件 | 推奨 |
| 設計 | - | 1件 | 検討 |
| 品質 | 3件 | - | 推奨 |
```

---

## フォールバック処理

### Codex MCP エラー時

```markdown
⚠️ Codex レビューがスキップされました

理由: MCP 接続エラー
詳細: Connection timeout after 30s

Claude のレビュー結果のみを表示します。
```

**対応**:
1. Claude のレビュー結果はそのまま表示
2. エラーをログに記録
3. 次回実行時の参考情報を表示

### Codex 認証切れ

```markdown
⚠️ Codex 認証が必要です

以下のコマンドで再認証してください:
\`\`\`bash
codex login
\`\`\`
```

---

## パフォーマンス考慮

### 大規模変更時

変更ファイルが多い場合（10ファイル超）:

1. **チャンク分割**: 5ファイルずつに分割して Codex に送信
2. **優先度付け**: 変更行数の多いファイルを優先
3. **タイムアウト**: 60秒でタイムアウト、部分結果を表示

### 並列実行の最適化

```
Claude レビュー ─────┐
                     ├──→ 結果統合
Codex MCP 呼び出し ─┘

最大待機時間: max(Claude, Codex) ≈ Codex 待機時間
```

---

## VibeCoder 向け

```markdown
💡 セカンドオピニオンの使い方

**言い方**:
- 「他の AI にも見てもらって」
- 「Codex にもチェックさせて」
- 「ダブルチェックして」

**結果の見方**:
- Claude と Codex で同じ指摘 → 確実に対応が必要
- 片方だけの指摘 → 内容を確認して判断
- 矛盾する指摘 → 両方の理由を確認
```

---

## 関連ドキュメント

- [codex-review/SKILL.md](../../codex-review/SKILL.md) - Codex 統合スキル
- [codex-mcp-setup.md](../../codex-review/references/codex-mcp-setup.md) - セットアップ手順

```

### references/commit-judgment-logic.md

```markdown
# コミット判定ロジック

harness-review の最終判定（APPROVE / REQUEST CHANGES / REJECT）を出力するためのロジック。

## 判定基準

| 判定 | 条件 | 次のアクション |
|------|------|---------------|
| **APPROVE** | Critical: 0, High: 0, Medium: ≤3 | コミット OK |
| **REQUEST CHANGES** | Critical: 0, High: ≥1 または Medium: >3 | 自動修正 → 再判定 |
| **REJECT** | Critical: ≥1 | 手動対応必要 |

### Severity 定義

| Severity | 定義 | 例 |
|----------|------|-----|
| **Critical** | セキュリティ脆弱性、データ損失リスク | SQL インジェクション、認証バイパス |
| **High** | 重大なバグ、パフォーマンス問題 | 無限ループ、N+1 クエリ |
| **Medium** | コード品質問題、ベストプラクティス違反 | 未使用変数、不適切な命名 |
| **Low** | スタイル、軽微な改善提案 | フォーマット、コメント追加 |

## 判定フロー

```
レビュー結果収集
    ↓
Severity 集計
    ├── Critical >= 1 → REJECT
    ├── High >= 1 || Medium > 3 → REQUEST CHANGES
    └── それ以外 → APPROVE
    ↓
判定出力
```

## 出力形式

### APPROVE

```markdown
## 🚦 コミット判定: APPROVE ✅

**判定理由**: 重大な問題なし

| Severity | 件数 |
|----------|------|
| Critical | 0 |
| High | 0 |
| Medium | 2 |
| Low | 5 |

📝 **Low/Medium の指摘**（任意対応）:
- [Medium] `src/utils/helpers.ts:45` - 未使用の import
- [Medium] `src/components/Form.tsx:78` - any 型の使用

**次のアクション**: `git commit` でコミット可能です
```

### REQUEST CHANGES

```markdown
## 🚦 コミット判定: REQUEST CHANGES 🟡

**判定理由**: 修正可能な問題あり

| Severity | 件数 |
|----------|------|
| Critical | 0 |
| High | 2 |
| Medium | 4 |
| Low | 3 |

📝 **修正が必要な項目**:

| # | Severity | ファイル | 内容 | 修正案 |
|---|----------|---------|------|--------|
| 1 | High | `src/api/users.ts:34` | N+1 クエリ | `include` で事前取得 |
| 2 | High | `src/pages/login.tsx:56` | XSS 脆弱性 | `sanitize()` を追加 |

**自動修正を実行しますか？** [Y/N]

> 自動修正後、再度レビューを実行して判定します（最大3回）
```

### REJECT

```markdown
## 🚦 コミット判定: REJECT ❌

**判定理由**: 重大なセキュリティ問題

| Severity | 件数 |
|----------|------|
| Critical | 1 |
| High | 3 |
| Medium | 2 |
| Low | 1 |

🚨 **Critical な問題**:

| # | ファイル | 内容 | 影響 |
|---|---------|------|------|
| 1 | `src/api/auth.ts:45` | SQL インジェクション | データ漏洩リスク |

**手動対応が必要です**:
1. 上記の Critical 問題を修正
2. 再度 `/harness-review` を実行

> ⚠️ 自動修正は Critical 問題には対応しません（安全のため）
```

## 自動修正ループ

REQUEST CHANGES 判定時の自動修正フロー:

```
REQUEST CHANGES 判定
    ↓
修正案を生成
    ↓
Claude が修正実行
    ↓
再度レビュー → 判定
    │
    ├── APPROVE → 完了
    ├── REQUEST CHANGES → ループ（最大3回）
    └── REJECT → 手動対応
```

### リトライ上限到達時

```markdown
## ⚠️ 自動修正上限に到達

3回の自動修正を試みましたが、以下の問題が残っています:

| # | Severity | ファイル | 内容 |
|---|----------|---------|------|
| 1 | High | `src/api/users.ts:34` | N+1 クエリ |

**推奨アクション**:
1. 手動で上記を修正
2. 再度 `/harness-review` を実行

> 💡 複雑な問題は自動修正が困難な場合があります
```

## Codex モードとの統合

Codex モード時は、各エキスパートからの指摘を集約して判定:

```
Codex 並列レビュー
    ├── Security Expert → findings[]
    ├── Accessibility Expert → findings[]
    ├── Performance Expert → findings[]
    ├── Quality Expert → findings[]
    ├── SEO Expert → findings[]
    ├── Architect Expert → findings[]
    ├── Plan Reviewer Expert → findings[]
    └── Scope Analyst Expert → findings[]
    ↓
全 findings を Severity で集計
    ↓
判定基準に基づいて判定
```

## 設定による制御

`.claude-code-harness.config.yaml`:

```yaml
review:
  judgment:
    enabled: true      # 判定を出力するか
    auto_fix: true     # REQUEST CHANGES 時に自動修正
    max_retries: 3     # 自動修正の最大回数
```

## 関連ファイル

- `skills/review/SKILL.md` - レビュースキル本体
- `skills/codex-review/references/codex-parallel-review.md` - Codex 並列呼び出し
- `commands/optional/codex-mode.md` - Codex モード切り替え

```

### ../codex-review/references/codex-parallel-review.md

```markdown
# Codex 並列レビュー実行ガイド

Codex モード時に複数のエキスパートを並列で呼び出すためのオーケストレーション手順。

## 概要

Codex モードでは、Claude がオーケストレーターとして**最大 8 つのエキスパート**を MCP 経由で並列呼び出しします（プロジェクト種別・変更内容に応じて不要なエキスパートは除外）。

```
Claude (オーケストレーター)
    ↓
並列 MCP 呼び出し
    ├── Security Expert
    ├── Accessibility Expert
    ├── Performance Expert
    ├── Quality Expert
    ├── SEO Expert
    ├── Architect Expert
    ├── Plan Reviewer Expert
    └── Scope Analyst Expert
    ↓
結果統合 → コミット判定
```

---

## ⚠️ 並列呼び出し必須ルール（MANDATORY）

**このルールは絶対に守ること。違反した場合、レビュー品質が大幅に低下します。**

### 禁止事項

| 禁止 | 理由 |
|------|------|
| ❌ 1回の MCP 呼び出しで複数エキスパートをまとめる | 各エキスパートの専門性が薄まる |
| ❌ 「セキュリティとパフォーマンスと品質を見て」と1回で依頼 | 観点が混在し、深い分析ができない |
| ❌ experts/*.md を読まずに汎用プロンプトを送る | 専門家プロンプトの知見が活かされない |

### 必須事項

| 必須 | 方法 |
|------|------|
| ✅ 各エキスパートを **個別の MCP 呼び出し** で実行 | `mcp__codex__codex` を8回呼び出し |
| ✅ experts/*.md から **個別にプロンプトを読み込む** | `security-expert.md` → Security 呼び出し → `accessibility-expert.md` → Accessibility 呼び出し... |
| ✅ **1つのレスポンス内で8つの MCP 呼び出しを並列実行** | Claude の並列ツール呼び出し機能を使用 |

### 正しい実行パターン

```
1. 設定とプロジェクト種別から有効なエキスパートを判定
2. 有効なエキスパートのみ、1つのレスポンス内で同時に実行:

mcp__codex__codex({prompt: security-expert.md の内容})
mcp__codex__codex({prompt: performance-expert.md の内容})
mcp__codex__codex({prompt: quality-expert.md の内容})
... (有効なもののみ)

→ 必要なエキスパートのみ並列実行
→ 無関係な観点はスキップしてコスト削減
```

### なぜ分けるのか

| 1回でまとめた場合 | 8回に分けた場合 |
|------------------|-----------------|
| 各観点が2-3行で浅い | 各観点が詳細に分析される |
| 重要な問題を見落とす | 専門家視点で漏れなく検出 |
| 「問題なし」で終わりやすい | 具体的な改善提案が出る |

---

## 実行フロー

### Step 0: 残コンテキスト確認

Codex 並列レビューの前に**残コンテキストが 30%以下なら /compact を実行**してください。

> **注意**: /compact 後も余裕が少ない場合はそのまま Step 1 に進みます。

### Step 1: 設定確認

```yaml
# .claude-code-harness.config.yaml から読み込み
review:
  mode: codex
  codex:
    enabled: true
    experts:
      security: true
      accessibility: true
      performance: true
      quality: true
      seo: true
      architect: true
      plan_reviewer: true
      scope_analyst: true
```

### Step 2: 変更ファイルの収集

```bash
# git diff で変更ファイルを取得
git diff --name-only HEAD~1
```

### Step 3: 呼び出すエキスパートの判定（フィルタリング）

**全エキスパートを毎回呼ぶのではなく、必要なもののみ選択する。**

#### 3.1 設定ベースのフィルタリング

`.claude-code-harness.config.yaml` で `false` のエキスパートは除外:

```yaml
experts:
  security: true       # ✅ 呼び出す
  accessibility: false # ❌ スキップ
  performance: true    # ✅ 呼び出す
  ...
```

#### 3.2 プロジェクト種別による自動除外

| プロジェクト種別 | 自動除外するエキスパート |
|-----------------|------------------------|
| CLI / バックエンドAPI | Accessibility, SEO |
| ライブラリ / SDK | Accessibility, SEO |
| Webフロントエンド | （全て有効） |
| モバイルアプリ | SEO |
| 計画/レビューのみ | Security, Performance, Quality（コード変更なし時） |

**判定方法**:
```
1. 変更ファイルのパスを確認:
   - src/components/, pages/, app/ → Webフロントエンド → Accessibility, SEO 有効
   - src/api/, server/, cli/ → バックエンド/CLI → Accessibility, SEO 除外
   - *.md のみ → ドキュメント変更 → Quality, Architect, Plan Reviewer, Scope Analyst を優先

2. package.json / pyproject.toml を確認:
   - react, vue, next → Webフロントエンド
   - express, fastify, flask → バックエンド
   - commander, yargs → CLI
```

#### 3.3 変更内容による除外

| 変更内容 | 優先するエキスパート | 除外可能 |
|---------|---------------------|---------|
| Plans.md のみ変更 | Plan Reviewer, Scope Analyst | Security, Performance, Quality, Accessibility, SEO, Architect |
| テストファイルのみ変更 | Security, Quality, Performance | Architect, Plan Reviewer, Scope Analyst |
| README / ドキュメントのみ | Quality, Architect, Plan Reviewer, Scope Analyst | Security, Performance, Accessibility |

#### 3.4 最終的な呼び出しリスト決定

```
設定で有効 AND プロジェクトに関連 AND 変更内容に関連
→ 呼び出すエキスパートリスト

例1: Webフロントエンドでコード変更あり
→ Security, Accessibility, Performance, Quality, SEO, Architect
→ 6エキスパート並列（Plan Reviewer, Scope Analyst は除外）

例2: CLI プラグインでドキュメントのみ変更
→ Quality, Architect, Plan Reviewer, Scope Analyst
→ 4エキスパート並列（Security, Performance, Accessibility, SEO は除外）
```

### Step 4: エキスパートプロンプトの準備

**Step 3 で決定したエキスパートのみ**、`experts/*.md` からプロンプトを読み込み:
- `{files}`: 変更ファイルリスト
- `{tech_stack}`: 検出された技術スタック
- `{plan_content}`: Plans.md の内容（Plan Reviewer 用）
- `{requirements}`: 要件内容（Scope Analyst 用）

### Step 5: 並列 MCP 呼び出し

**重要**: Step 3 で決定した有効なエキスパートのみ呼び出し

```typescript
// 並列呼び出しの概念コード
const enabledExperts = Object.entries(config.review.codex.experts)
  .filter(([_, enabled]) => enabled)
  .map(([name]) => name);

// 並列実行
const results = await Promise.all(
  enabledExperts.map(expert =>
    mcp__codex__codex({
      prompt: getPromptForExpert(expert, files, techStack),
      sandbox: "read-only"
    })
  )
);
```

### Step 6: 結果統合

各エキスパートからの結果を統合:

```markdown
## 📊 Codex 並列レビュー結果

### エキスパート別サマリー

| Expert | Score | Critical | High | Medium | Low |
|--------|-------|----------|------|--------|-----|
| Security | B | 0 | 1 | 2 | 3 |
| Accessibility | A | 0 | 0 | 1 | 2 |
| Performance | C | 0 | 2 | 3 | 1 |
| Quality | B | 0 | 0 | 4 | 5 |
| SEO | A | 0 | 0 | 0 | 2 |
| Architect | B | 0 | 1 | 1 | 0 |
| Plan Reviewer | APPROVE | - | - | - | - |
| Scope Analyst | Proceed | - | - | - | - |

### 統合 Findings

| # | Expert | Severity | File | Issue |
|---|--------|----------|------|-------|
| 1 | Security | High | src/api/auth.ts:45 | SQL Injection |
| 2 | Performance | High | src/api/posts.ts:23 | N+1 Query |
| 3 | Architect | High | src/services/ | Circular dependency |
```

### Step 7: コミット判定

統合結果から最終判定を算出:

| 集計 | 判定 |
|------|------|
| Critical ≥ 1 | REJECT |
| High ≥ 1 または Medium > 3 | REQUEST CHANGES |
| それ以外 | APPROVE |

## エラーハンドリング

### 一部エキスパート失敗時

```markdown
⚠️ 一部のエキスパートでエラーが発生しました

| Expert | Status |
|--------|--------|
| Security | ✅ 成功 |
| Performance | ❌ タイムアウト |
| Quality | ✅ 成功 |

失敗したエキスパートをスキップして判定を続行しますか？
```

### 全エキスパート失敗時

```markdown
❌ Codex エキスパートとの通信に失敗しました

原因: MCP サーバー接続エラー

フォールバック: Claude 単体でレビューを実行しますか？
```

## 自動修正ループ

REQUEST CHANGES 判定時の自動修正フロー:

```
REQUEST CHANGES 判定
    ↓
修正対象の抽出（High/Medium の Findings）
    ↓
Claude が修正実行
    ↓
再度 Codex 並列レビュー
    │
    ├── APPROVE → 完了
    ├── REQUEST CHANGES → ループ（リトライ: ${current}/${max_retries}）
    └── REJECT → 手動対応必要
```

### リトライ制限

- デフォルト: 最大 3 回
- 設定: `review.judgment.max_retries`

### リトライ超過時

```markdown
## ⚠️ 自動修正上限に到達

${max_retries} 回の自動修正を試みましたが、以下の問題が残っています:

| # | Severity | File | Issue |
|---|----------|------|-------|
| 1 | High | src/api/users.ts | N+1 Query |

**推奨アクション**:
1. 手動で上記を修正
2. 再度 `/harness-review` を実行
```

## 関連ファイル

| ファイル | 役割 |
|---------|------|
| `experts/security-expert.md` | セキュリティエキスパートプロンプト |
| `experts/accessibility-expert.md` | a11y エキスパートプロンプト |
| `experts/performance-expert.md` | パフォーマンスエキスパートプロンプト |
| `experts/quality-expert.md` | 品質エキスパートプロンプト |
| `experts/seo-expert.md` | SEO エキスパートプロンプト |
| `experts/architect-expert.md` | 設計エキスパートプロンプト |
| `experts/plan-reviewer-expert.md` | 計画レビューエキスパートプロンプト |
| `experts/scope-analyst-expert.md` | 要件分析エキスパートプロンプト |
| `commit-judgment-logic.md` | コミット判定ロジック |

```

### ../../docs/LSP_INTEGRATION.md

```markdown
# LSP Integration Guide

Claude Code の LSP（Language Server Protocol）機能を活用するためのガイドです。

---

## LSP 機能の概要

Claude Code v2.0.74+ で利用可能な LSP 機能：

| 機能 | 説明 | 活用シーン |
|------|------|-----------|
| **Go-to-definition** | シンボルの定義元へジャンプ | コード理解、影響範囲調査 |
| **Find-references** | シンボルの全使用箇所を検索 | リファクタリング前の影響分析 |
| **Rename** | シンボル名を一括変更 | 安全なリネーム操作 |
| **Diagnostics** | コードの問題を検出 | ビルド前の問題検出、レビュー |
| **Hover** | シンボルの型情報・ドキュメント表示 | コード理解 |
| **Completions** | コード補完候補の提示 | 実装作業 |

### 対応言語

- TypeScript / JavaScript
- Python
- Rust
- Go
- C/C++
- Ruby
- PHP
- C#
- Swift
- Java
- HTML/CSS

---

## ゼロからのセットアップ（推奨）

LSP を使うには **2つのもの** が必要です:

1. **言語サーバー** - 実際にコード解析を行うプログラム
2. **LSP プラグイン** - Claude Code と言語サーバーを接続

### Step 1: 言語サーバーをインストール

| 言語 | Language Server | インストールコマンド |
|------|-----------------|---------------------|
| **TypeScript/JS** | typescript-language-server | `npm install -g typescript typescript-language-server` |
| **Python** | pyright | `pip install pyright` または `npm install -g pyright` |
| **Rust** | rust-analyzer | [公式手順](https://rust-analyzer.github.io/manual.html#installation) |
| **Go** | gopls | `go install golang.org/x/tools/gopls@latest` |
| **C/C++** | clangd | macOS: `brew install llvm` / Ubuntu: `apt install clangd` |

### Step 2: 公式 LSP プラグインをインストール

**プロジェクトで使用する言語に必要なプラグインのみ**インストールしてください。

```bash
# 例: TypeScript/JavaScript プロジェクトの場合
claude plugin install typescript-lsp

# 例: Python プロジェクトの場合
claude plugin install pyright-lsp

# 例: Go プロジェクトの場合
claude plugin install gopls-lsp
```

**どのプラグインが必要か分からない場合**:
- `/plugin` コマンドで "lsp" を検索して、プロジェクトの言語に該当するものを選択
- または `/lsp-setup` コマンドで自動検出・提案を受ける

**利用可能な公式プラグイン**: typescript-lsp, pyright-lsp, rust-analyzer-lsp, gopls-lsp, clangd-lsp, jdtls-lsp, swift-lsp, lua-lsp, php-lsp, csharp-lsp（詳細は下記「公式LSPプラグイン一覧」参照）

### Step 3: Claude Code を起動

```bash
claude
```

**これで完了！** Go-to-definition、Find-references、Diagnostics が使えるようになります。

---

## 公式 LSP プラグイン一覧

以下の言語向けに公式LSPプラグインが提供されています。**プロジェクトで使用する言語に必要なものだけ**インストールしてください。

| プラグイン | 言語 | 必要な言語サーバー |
|-----------|------|-------------------|
| `typescript-lsp` | TypeScript/JS | typescript-language-server |
| `pyright-lsp` | Python | pyright |
| `rust-analyzer-lsp` | Rust | rust-analyzer |
| `gopls-lsp` | Go | gopls |
| `clangd-lsp` | C/C++ | clangd |
| `jdtls-lsp` | Java | jdtls |
| `swift-lsp` | Swift | sourcekit-lsp |
| `lua-lsp` | Lua | lua-language-server |
| `php-lsp` | PHP | intelephense |
| `csharp-lsp` | C# | omnisharp |

**インストール方法**:
```bash
# 例: TypeScript/JavaScript プロジェクトの場合
claude plugin install typescript-lsp

# 例: Python プロジェクトの場合
claude plugin install pyright-lsp
```

または `/plugin` コマンドで "lsp" を検索して、該当言語のプラグインをインストール。

> **重要**: プラグインは言語サーバーのバイナリを**含みません**。Step 1 で言語サーバーを別途インストールしてください。

> **迷ったら**: `/lsp-setup` コマンドが、プロジェクトの言語を自動検出して必要なプラグインを提案します。

---

## 既存プロジェクトへの導入

既存プロジェクトに LSP を追加するには `/lsp-setup` コマンドを使用:

```
/lsp-setup
```

このコマンドは:
1. プロジェクトの言語を自動検出
2. 必要な言語サーバーのインストール確認・実行
3. 公式プラグインのインストール
4. 動作確認


---

## VibeCoder 向けの使い方

技術的な詳細を知らなくても、自然な言葉で LSP 機能を活用できます：

| 言いたいこと | 言い方 |
|-------------|--------|
| 定義を見たい | 「この関数の定義はどこ？」「`handleSubmit` の中身を見せて」 |
| 使用箇所を調べたい | 「この変数はどこで使われてる？」「`userId` の参照箇所を探して」 |
| 名前を変えたい | 「`getData` を `fetchUserData` にリネームして」 |
| 問題を検出したい | 「このファイルに問題ある？」「エラーをチェックして」 |
| 型情報を知りたい | 「この変数の型は何？」 |

---

## コマンド・スキルでの LSP 活用

### `/work` - 実装時

```
LSP 活用ポイント:
- 定義ジャンプで既存コードの理解を高速化
- 参照検索で影響範囲を事前把握
- 診断で実装中のエラーを即座に検出
```

### `/harness-review` - レビュー時

```
LSP 活用ポイント:
- Diagnostics で型エラー・未使用変数を自動検出
- Find-references で変更の影響範囲を確認
- 静的解析結果をレビュー観点に追加
```

### `/refactor` - リファクタリング時

```
LSP 活用ポイント:
- Rename でシンボルを安全に一括変更
- Find-references で漏れのない変更を保証
- Diagnostics で変更後の問題を即座に検出
```

### `/troubleshoot` - 問題解決時

```
LSP 活用ポイント:
- Diagnostics でエラー箇所を正確に特定
- Go-to-definition で問題のあるコードの原因を追跡
- 型情報で期待値と実際の不一致を発見
```

### `/validate` - 検証時

```
LSP 活用ポイント:
- プロジェクト全体の Diagnostics を実行
- 型エラー・警告の一覧を生成
- ビルド前に問題を検出
```

---

## LSP 診断の出力形式

```
📊 LSP 診断結果

ファイル: src/components/UserForm.tsx

| 行 | 重要度 | メッセージ |
|----|--------|-----------|
| 15 | Error | 型 'string' を型 'number' に割り当てることはできません |
| 23 | Warning | 'tempData' は宣言されていますが、使用されていません |
| 42 | Info | この条件は常に true です |

合計: エラー 1件 / 警告 1件 / 情報 1件
```

---

## LSP と Grep の使い分け

LSP と Grep はそれぞれ得意分野が異なります。適切に使い分けることで効率が上がります。

### 使い分け早見表

| 目的 | 推奨 | 理由 |
|------|------|------|
| シンボルの定義を探す | **LSP** | スコープを理解し、同名の別変数を区別 |
| シンボルの参照箇所を探す | **LSP** | 意味論的に正確な参照のみ抽出 |
| 変数・関数のリネーム | **LSP** | 漏れなく一括変更、安全 |
| 型エラー・構文エラー検出 | **LSP** | ビルド前に検出可能 |
| 文字列リテラル内を検索 | **Grep** | LSP はコード構造のみ対象 |
| コメント内を検索 | **Grep** | `TODO:` や `FIXME:` など |
| 正規表現パターン検索 | **Grep** | 柔軟なマッチング |
| 設定ファイル・ドキュメント | **Grep** | LSP はコードのみ対象 |
| LSP 非対応言語 | **Grep** | フォールバック |

### 具体例

```
❓「userId 変数はどこで使われてる？」
→ LSP Find-references（別スコープの userId を除外）

❓「"userId" という文字列はどこに書いてある？」
→ Grep（API レスポンス、コメント、ログも含む）

❓「TODO: を全部探して」
→ Grep（コメント内のテキスト）

❓「fetchUser を fetchUserById に変えたい」
→ LSP Rename（確実に全箇所変更）

❓「API エンドポイント /api/users を探して」
→ Grep（文字列リテラル検索）
```

### VibeCoder 向けの判断基準

| こう聞かれたら | 使うツール |
|---------------|-----------|
| 「この関数の定義はどこ？」 | LSP |
| 「この変数はどこで使われてる？」 | LSP |
| 「〇〇 を △△ にリネームして」 | LSP |
| 「"〇〇" という文字列を探して」 | Grep |
| 「TODO を全部リストして」 | Grep |
| 「〇〇 というテキストがどこにあるか」 | Grep |

---

## LSP 活用のベストプラクティス

### 1. 実装前に定義を確認

```
実装前:
1. 関連するシンボルの定義を LSP で確認
2. 既存のパターンを把握
3. 影響範囲を Find-references で調査
```

### 2. 変更後に診断を実行

```
変更後:
1. LSP Diagnostics を実行
2. エラー・警告を確認
3. 問題があれば即座に修正
```

### 3. リファクタリングは LSP Rename を使用

```
リファクタリング:
1. 変更対象を Find-references で確認
2. LSP Rename で一括変更
3. Diagnostics で問題がないことを確認
```

---

## Phase0: LSP tool_name の確認（開発者向け）

公式LSPプラグインの実際の `tool_name` を確認するには、Phase0ログを使用します。

### Phase0ログの有効化

Phase0ログはデフォルトで**無効**になっています。tool_name を確認する際のみ、環境変数で有効化してください。

```bash
# Phase0ログを有効化してClaude Codeを起動
CC_HARNESS_PHASE0_LOG=1 claude

# または、現在のセッションで有効化
export CC_HARNESS_PHASE0_LOG=1
claude
```

**重要**: tool_name確定後は、必ずPhase0ログを無効化してください（ログ肥大化防止）。

```bash
# Phase0ログを無効化（デフォルト状態に戻す）
unset CC_HARNESS_PHASE0_LOG
```

### 手順

1. **Phase0ログを有効化してセッション開始後、LSPツールを1回実行**:
   - 例: TypeScriptファイルで definition, references, diagnostics 等を実行

2. **tool-events.jsonl を確認**:
   ```bash
   cat .claude/state/tool-events.jsonl | grep -i lsp
   ```

3. **tool_name の検出条件を確認・調整**:
   - **現在の実装**: `scripts/posttooluse-log-toolname.sh` が `grep -iq "lsp"` で tool_name に "lsp" が含まれるかチェック
   - **tool_name が想定と異なる場合** (例: "lsp" を含まない名前の場合):
     - `scripts/posttooluse-log-toolname.sh` の LSP 検出条件（line 164付近）を更新:
       ```bash
       # 例: tool_name が "TypeScriptLSP" の場合
       if echo "$TOOL_NAME" | grep -iq "lsp\|TypeScriptLSP"; then
       ```
   - **matcher依存を回避**: PostToolUse は `matcher: "*"` で全ツールを観測するため、matcher設定は不要

4. **Phase0ログを無効化**:
   ```bash
   unset CC_HARNESS_PHASE0_LOG
   ```

### 想定される tool_name パターン

- `"LSP"` - 基本的なLSPツール
- `"typescript-lsp"` - 言語別プラグイン名
- `"LSP:definition"` - 操作別ツール名

いずれも "lsp" を含むため、デフォルトの検出条件（`grep -iq "lsp"`）で対応可能です。

**注意**: Phase0ログは最小フィールドのみ記録（tool_name, ts, session_id, prompt_seq）し、tool_input/tool_response は保存しません（漏洩リスク回避）。

---

## トラブルシューティング

### LSP が動作しない場合

1. 公式LSPプラグインがインストールされているか確認
2. 言語サーバーがインストールされているか確認（例: `which typescript-language-server`, `which pyright`）
3. `/lsp-setup` コマンドで設定を確認

### 診断結果が表示されない場合

1. 対応言語かどうかを確認
2. プロジェクトの設定ファイル（tsconfig.json 等）が正しいか確認
3. `restart_lsp_server` で言語サーバーを再起動

---

## 関連ドキュメント

- [ARCHITECTURE.md](./ARCHITECTURE.md) - プロジェクト全体の設計
- [OPTIONAL_PLUGINS.md](./OPTIONAL_PLUGINS.md) - オプションプラグインについて

```