implement-review

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

フロー

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

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 があるか検索する:

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

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

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

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

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）が残る場合は完了を宣言しない。

よくある失敗

注意事項

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

sandbox 環境での実行

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