cdk-review

AWS CDK インフラコードをレビューしてください。あなたはレビュー本体を行わず、**レンズに割って並列に走らせ、返ってきた結果を統合する**役です。 1体に全観点を見せると、データ損失やデプロイ事故につながる誤設定を探す注意力が命名・コメントの照合に取られ、一番見落としたくない欠陥の見落としが減りません。レンズごとに並列に走らせ、判定・severity・修正案はレンズ側に決め切らせ、あなたには手順どおりの決定・統合だけを残します。 ## Phase 1: 対象ファイル・判定範囲・設計書を決める（1回だけ） ### 対象ファイルの検出 ファイルパスがある場合は、そのファイルパスを直接対象とする（複数指定可）。 ファイルパスが無い場合は、`--full` の有無で候補を集める。 - `--full` が無い：Bash で `git diff HEAD --name-only --diff-filter=ACMR`（未コミットの変更）と `git ls-files --others --exclude-standard`（未追跡の新規ファイル）を実行して結合し、重複を除いたうえで `infra/**/*.ts` に当たるものを候補にする - `--full` がある：Glob で `infra/**/*.ts` を検出して候補にする 候補から `**/*.test.ts`、`*.config.*`、`cdk.json`、`node_modules`、`cdk.out/` を除く。該当ファイルが 0 件の場合は「infra/ 配下に対象ファイルが見つかりませんでした」と出力して終了する。 ### 判定範囲を決める 対象ファイルごとに、判定範囲を **差分** か **全文** に決める。 | 条件 | 判定範囲 | | ------------------------------------------------------------------ | -------- | | 引数に `--full` がある | 全文 | | `git diff HEAD -- <パス>` に出力がある、または未追跡の新規ファイル | 差分 | | どちらでもない（パスを指定したが変更が無い） | 全文 | 差分のファイルは、Phase 3 の手順1で引用と突き合わせるため、ここで `git diff HEAD -U0 -- <パス>` を1回だけ取っておく（未追跡の新規ファイルは全行が追加行）。 ### 種別を決める 対象ファイルそれぞれについて、以下のルールで種別を判定する: | ディレクトリパターン | 種別 | | ------------------------------------------------------------- | --------- | | `infra/bin/*.ts` | App | | `infra/lib/*-stack.ts` | Stack | | `infra/lib/constructs/*.ts` または `infra/lib/*-construct.ts` | Construct | | `infra/parameter.ts` または `infra/lib/parameters/*.ts` | Parameter | どのパターンにも当たらないファイルは種別「その他」として渡す（種別ごとの重点観点は無い）。 続けて各ファイルの最終コミット情報を取得する: ```bash git log -1 --pretty=format:"%h - %an, %ar : %s" -- [ファイルパス] ``` 対象ファイル・判定範囲・種別・最終コミット情報の組を、この後の全レンズ起動に渡す（レンズごとに決め直させない）。差分の中身はプロンプトに書き写さない——各レンズが `git diff HEAD -- <パス>` で自分で取る。書き写すと、その分がレンズの数だけ出力トークンになる。 ### インフラ設計書・IaC 設計書の特定 設計ハブ `docs/design-hub.md` を Read し、各設計書の担当範囲からインフラ設計（何を組むか）と IaC 設計（どう作り・変えるか）を扱うものを**両方**特定する。片方しか無ければその1本、どちらも無ければ「対象設計書なし」とする。 特定した設計書の判定範囲も、対象ファイルと同じ表で決める。ただし `--full` が無く、`git diff HEAD -- <パス>` に出力が無い（今回変更していない）設計書は対象から外す。外した結果が0本なら「対象設計書なし」とする。差分の設計書は、対象ファイルと同じく `git diff HEAD -U0 -- <パス>` を1回だけ取っておく。 ## Phase 2: レンズを並列起動する `cdk-reviewer-agent` を、**レンズごとに1回ずつ、1メッセージ内でまとめて** Task 起動する。逐次に投げると、待ち時間がレンズの数だけ積み重なる。 起動の前に `.claude/agents/cdk-reviewer-agent/cdk-reviewer-agent.md` の「レンズ一覧と担当観点（正典）」を Read し、そこにあるレンズ名をそのまま渡す。 - **「設計書の内容」以外のすべてのレンズ**には次を渡す: - **レンズ名**：レンズ一覧のうち1つ - **対象ファイルの一覧**：Phase 1 で決めた全ファイル。各ファイルにパス・判定範囲（差分／全文）・種別・最終コミット情報を添える - **設計書の内容**レンズには次を渡す: - **レンズ名**：「設計書の内容」 - **対象設計書の一覧**：Phase 1 で特定したインフラ設計書・IaC 設計書のパスと判定範囲（差分／全文）（無ければ「対象なし」） **レンズの一覧と担当観点は `cdk-reviewer-agent` の定義が正典です。** ここに書き写しません——2箇所に持つと、割り方を変えたときに片方が古いまま残ります。 ## Phase 3: 統合してレポートを出す 各レンズのレポートを1つに統合する。判断は手順4の食い違いの裁定だけにし、次の手順で行う: 1. **引用の無い指摘を落とす**。判定範囲が差分のファイル・設計書では、引用が Phase 1 で取った差分の追加行（`+`）・削除行（`-`）のどれにも無い指摘も落とす（範囲の制限をレンズの自己申告に頼らないため） 2. **同じ観点で引用が重なる指摘だけを1件にまとめる**（観点が違う指摘はまとめない） 3. **severity を変えない**（レンズの判定を尊重する） 4. **修正案が食い違ったら裁定する**：同じ箇所に別々のレンズが逆向きの修正案を出したら、ポリシーの条文（該当が無ければ `docs/policy/refined-engineer-judgment-principles.md`）を引用して一方を採り、捨てた修正案と根拠を添える。迷ったら AI が決める - 例外：どちらを採っても要件・プロダクトの方針が変わるとき、またはどちらかが取り消せない操作・外部に出る操作になるときだけは裁定しない。その食い違い1件を、`.claude/skills/quick-issue/SKILL.md` の書式でラベル `issue:needs-human-decision` を付けて `gh issue create` で起票し、ほかの手順は続ける。本文には、食い違った各指摘の観点名と引用を書き写す。同じワークフローの前回のレビューでこの手順により起票した Issue と同じ指摘なら、起票せず、既存の Issue 番号のまま起票済みとして扱う（手順7で引く対象にも含める）。同じ指摘かどうかは ai-review-gate-policy の「再レビューで同じ指摘が出たら、既存の Issue 番号で数える」で決める 5. **「次のステップ」の優先度は severity から機械的に決める**（Critical→高・High→中・Medium→低） 6. **観点一覧の行名で穴を照合する**：`references/review-criteria.md` の観点一覧の全行と、観点一覧の外の「サービス設定値（セキュリティ）」「サービス設定値（運用・性能）」を、どれかのレンズの「判定した観点」と突き合わせる。判定済みとみなすのは、各レンズの「判定した観点」に名前が挙がっている観点だけ。無ければ「未判定」として観点名をそのまま報告する（**これはレビュー対象の欠陥ではなく、レンズの割り方の穴**。黙って埋めない）。「設計書の内容」レンズの担当（`iac-infra-design-doc-policy.md`「レビュー観点」）は対象設計書がある場合のみ照合する 7. **合否を判定する**：[ai-review-gate-policy](../../../docs/policy/ai-review-gate-policy.md) の合格条件（残してよい例外以外の Critical が0件）で決める。コード・設計書レビューを通じた Critical の合計から、手順4で `issue:needs-human-decision` として起票した食い違いに含まれる Critical 指摘の件数を引き、残りが0件なら ✅ 合格、1件以上なら 🚫 要修正とする。起票した Issue 番号は「Issue にして残す Critical」に書く 指摘はファイルごとにまとめる。複数ファイルを渡した場合も、レンズをまたいで同じファイルの指摘を1箇所に集める。 出力は `references/report-format.md` の書式に従う。