fandhe-ai 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 ルール
- 不要な再描画リスク
- 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 へのコメント/起票という書き込み操作を行う例外とする。
手順
- 既存 Issue を確認する 対象を実装している既存の open Issue があるか検索する:
gh issue list --state open --search "${KEYWORD}"
キーワードは "${KEYWORD}" でクォートして渡す。
ユーザーに提示して承認を得る out-of-scope 項目・既存 Issue の有無・対応案（既存 Issue へのコメント追加 or 新規起票）をレビューレポートに含めてユーザーに提示する。承認を得てから実行する（確認なしに Issue 操作をしない）。
既存 Issue がある場合: コメントを追加する
gh issue comment "${ISSUE_NUMBER}" --body "$(cat <<'EOF'
## 実装サポート情報（別作業から検出）
### 検出背景
コードレビュー（`git diff` ベース）の過程で発見した事項。
### 関連ファイル・シンボル
- `src/path/to/file.ts` — 対象関数名・クラス名
### パッケージ・サービスから見た役割・影響範囲
（このシンボルの担う境界、呼び出し元/呼び出し先）
### 着手時の注意点・依存関係
（依存パッケージ、順序制約など）
EOF
)"
既存 Issue がない場合: 新規起票する
create-issue-treeが導入されていればそれを使用（既存ルートへの紐付けは--root <ルートissue番号>）、未導入ならcreate-issueを使用して、適切な親 Issue 配下に起票する。タイトルは Conventional Commits 形式とする。レビューレポートに明記する out-of-scope 項目はレビュー中（Step 2〜3）に収集し Step 4 のレポートに含める。Issue への書き込み操作は承認後に行う。レビューレポートには「対象外とした項目」と対応案を記載する。切り出し先 Issue 番号は承認後の起票で確定するため、レポート時点では 'TBD' とし、起票後に確定番号を別途通知する。
セキュリティ注記:
ghへ渡すキーワード・コメント本文は変数を"${var}"でクォートし、本文は HEREDOC（<<'EOF'）で渡してインジェクションを防ぐ。
検証
レビュー完了後、レポートに「①仕様準拠」「②コード品質/セキュリティ」の両セクションが記述されていることを確認する（.claude/rules/verification.md）。セキュリティ問題（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 無効にする。