---
name: implement-review
description: コード変更 (`git diff`) の品質・アーキテクチャ準拠・セキュリティ (OWASP Top 10) を Agent ツール委譲で読み取り専用レビューする。コミット前/PR 作成前のセルフレビュー、「変更をレビューして」「コードレビューして」などで使用。GitHub PR のレビューには implement-review-pr を使用。
model: sonnet
user-invocable: true
---

# implement-review

コード変更の品質・アーキテクチャ準拠・セキュリティをレビューします。

## フロー

### Step 1: 変更内容を確認する

```bash
git diff main...HEAD --stat
git diff main...HEAD
```

ベースブランチはリポジトリの規約に従う（`main` / `develop` 等）。
または特定のファイル・ディレクトリを対象にする（ユーザーが指定した場合）。

### Step 2: ①仕様準拠レビュー

Agent ツールに委譲して仕様への準拠を確認:

確認項目:
- 対応 Issue・PR の要件・受け入れ条件を充足しているか
- out-of-scope の実装が混入していないか
- 計画（`_/local-plans/` 等）からの逸脱がないか

### Step 3: ②コード品質レビュー（OWASP セキュリティ含む）

Agent ツールに委譲してコード品質・セキュリティを確認:

確認項目（品質）:
- アーキテクチャ準拠（コンポーネント階層、配置先）
- 命名規則
- Import ルール
- フロントエンド（React 等）の変更を含む場合: 不要な再描画リスク・props の最小化
- テストカバレッジ

確認項目（セキュリティ、必須）:
- OWASP Top 10（XSS, CSRF, インジェクション等）
- API キー・シークレットのハードコーディング
- 入力バリデーション（システム境界での検証）
- 認証・認可の実装
- 機密データの取り扱い

### Step 4: レポートを生成する

out-of-scope 項目を検出した場合は本レポートに「対象外とした項目」と対応案を含める（後述の「実装対象外（out-of-scope）の扱い」を参照）。切り出し先 Issue 番号はユーザー承認後の起票で確定するため、レポート時点では 'TBD' と記載する。out-of-scope の収集はレビュー中（Step 2〜3）に行う。

以下の形式でレポートをまとめる（①仕様準拠・②コード品質/セキュリティの2段階で記述）:

```
## Code Review Results

### ①仕様準拠レビュー
✅ 問題なし
- ...
⚠️ 要確認:
- 受け入れ条件 X が未実装

### ②コード品質レビュー

#### コード品質
✅ 問題なし
- ...
⚠️ 要改善（非ブロッキング）:
- `src/components/Foo.tsx:42` — 説明
❌ 要修正（ブロッキング）:
- `src/components/Bar.tsx:10` — 説明

#### セキュリティ（OWASP）
✅ 問題なし
- ...
❌ セキュリティ問題:
- 深刻度: HIGH/MEDIUM/LOW
- `src/api/endpoint.ts:20` — 説明
- 推奨修正: ...
```

## 実装対象外（out-of-scope）の扱い

このスキルは読み取り専用のレビューが原則だが、レビューの過程で対応すべきだが現スコープ外と判断した事項（未対応の改善・別機能・技術的負債・後続作業）を検出した場合は、放置せず追跡する。**out-of-scope 検出時に限り、ユーザー承認を得たうえで Issue へのコメント/起票という書き込み操作を行う例外**とする。

### 手順

1. **既存 Issue を確認する**
   対象を実装している既存の open Issue があるか検索する:

```bash
gh issue list --state open --search "${KEYWORD}"
```

   キーワードは `"${KEYWORD}"` でクォートして渡す。

2. **ユーザーに提示して承認を得る**
   out-of-scope 項目・既存 Issue の有無・対応案（既存 Issue へのコメント追加 or 新規起票）をレビューレポートに含めてユーザーに提示する。**承認を得てから実行する**（確認なしに Issue 操作をしない）。

3. **既存 Issue がある場合: コメントを追加する**

```bash
gh issue comment "${ISSUE_NUMBER}" --body "$(cat <<'EOF'
## 実装サポート情報（別作業から検出）

### 検出背景
コードレビュー（`git diff` ベース）の過程で発見した事項。

### 関連ファイル・シンボル
- `src/path/to/file.ts` — 対象関数名・クラス名

### パッケージ・サービスから見た役割・影響範囲
（このシンボルの担う境界、呼び出し元/呼び出し先）

### 着手時の注意点・依存関係
（依存パッケージ、順序制約など）
EOF
)"
```

4. **既存 Issue がない場合: 新規起票する**
   `create-issue-tree` が導入されていればそれを使用（既存ルートへの紐付けは `--root <ルートissue番号>`）、未導入なら `create-issue` を使用して、適切な親 Issue 配下に起票する。タイトルは Conventional Commits 形式とする。

5. **レビューレポートに明記する**
   out-of-scope 項目はレビュー中（Step 2〜3）に収集し Step 4 のレポートに含める。Issue への書き込み操作は承認後に行う。レビューレポートには「対象外とした項目」と対応案を記載する。切り出し先 Issue 番号は承認後の起票で確定するため、レポート時点では 'TBD' とし、起票後に確定番号を別途通知する。

> **セキュリティ注記**: `gh` へ渡すキーワード・コメント本文は変数を `"${var}"` でクォートし、本文は HEREDOC（`<<'EOF'`）で渡してインジェクションを防ぐ。

## 検証

レビュー完了後、レポートに「①仕様準拠」「②コード品質/セキュリティ」の両セクションが記述されていることを確認する（対象リポジトリに `.claude/rules/verification.md` が存在する場合はそちらの5段階ゲートに従う。存在しない場合は次の要点に従う: 証拠なしに完了と宣言しない）。セキュリティ問題（HIGH）が残る場合は完了を宣言しない。

## よくある失敗

| 問題 | 回避策 |
|------|--------|
| 仕様準拠を確認せずにコード品質レビューに入る | Step 2（①仕様準拠）→ Step 3（②コード品質/セキュリティ）の順を守る |
| セキュリティレビューをコード品質と独立して別報告にしてしまう | ②コード品質セクション内の「セキュリティ（OWASP）」小節に統合して報告する |
| out-of-scope 検出を記録せずに放置する | 検出したら即座に Step 4 の「対象外とした項目」節に記録し、承認後に Issue 化する |

## 注意事項

- このスキルは原則として読み取り専用のレビューのみ行う（自動修正しない）。ただし out-of-scope 追跡の目的に限り、ユーザー承認後の Issue コメント/起票という書き込み操作を例外的に許可する
- セキュリティ問題は必ず修正してからマージするよう案内する

## sandbox 環境での実行

Step 1〜4（`git diff` の読み取り、①仕様準拠レビュー、②コード品質/セキュリティレビュー、レポート生成）は sandbox 環境で実行できる。ネットワーク越しの操作を行わず、ワークスペース外への書き込みも行わない。前提として base ref（`origin/<base>` 等）がローカルに存在している必要があり、base を最新化する `git fetch` はネットワーク操作のため、そのコマンド単位で sandbox 無効にする。「注意事項」の out-of-scope 追跡（Issue コメント投稿・新規起票）のみネットワークを要する任意ステップであり、該当コマンド単位で sandbox 無効にする。