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

implement review コード変更の品質・アーキテクチャ準拠・セキュリティをレビューします。フロー Step 1: 変更内容を確認するベースブランチはリポジトリの規約に従う（ 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段階で記述）: 実装対象外（out of scope）の扱いこのスキルは読み取り専用のレビューが原則だが、レビューの過程で対応すべきだが現スコープ外と判断した事項（未対応の改善・別機能・技術的負債・後続作業）を検出した場合は、放置せず追跡する。 out of scope 検出時に限り、ユーザー承認を得たうえで Issue へのコメント/起票という書き込み操作を行う例外とする。手順 1. 既存 Issue を確認する対象を実装している既存の open Issue があるか検索する: キーワードは "${KEYWORD}" でクォートして渡す。 2. ユーザーに提示して承認を得る out of scope 項目・既存 Issue の有無・対応案（既存 Issue へのコメント追加 or 新規起票）をレビューレポートに含めてユーザーに提示する。承認を得てから実行する（確認なしに Issue 操作をしない）。 3. 既存 Issue がある場合: コメントを追加する 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 ）。セキュリティ問題（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 無効にする。