Section 2: 自作 Claude スキルによる、ブランチ差分のレビュー

使うツール: /code-review (軽量) と /cross-review (クロスレビュー) の 2 スキル

目的

• 早期発見: PR を出す前に問題を発見・修正できる
• 効率化: PR 後のレビュー指摘を減らせる
• 品質向上: Critical な問題を事前に潰せる

完成形

/code-review (軽量コードレビュー):

1. フィーチャーブランチでコミットした状態で /code-review を実行
2. AI が base..HEAD の累積 diff を読み、要修正 / 任意修正 の 2 段階で短く報告

/cross-review (複数エージェントレビュー):

1. PR 提出前のブランチで /cross-review を実行
2. AI が 辛口レビュアー と 甘口レビュアー を 並列に起動 (1 メッセージで 2 つの Agent を呼び出し)
3. 両者の指摘をすり合わせ、合意 / 重大度高 / 要すり合わせ の 3 区分で統合レポート

準備

Section 1 の続きとして、練習ブランチで複数コミットを積んだ状態を前提にします。デバッグ出力や typo をわざと混ぜておくと、レビューの効きが分かりやすくなります。

# Section 0 でクローンしたフォークに移動
cd svelte-todo

手順

1. コードレビュースキル /code-review を登録

~/.claude/skills/code-review/SKILL.md を作成する。

mkdir -p ~/.claude/skills/code-review
vi ~/.claude/skills/code-review/SKILL.md

---
name: code-review
description: |
  現在のフィーチャーブランチの累積差分 (base..HEAD) を 1 パスで軽量レビューし、
  要修正 / 任意修正 の 2 段階で指摘を返す。コミット直後の素早いセルフレビュー用途。
disable-model-invocation: true
allowed-tools: Bash(git *), Read, Grep
argument-hint: "[base-branch]"
---

## 起動時コンテキスト

- 現在ブランチ: !`git branch --show-current`
- 作業ツリー状態: !`git status --short`
- ベースブランチ候補: !`git for-each-ref --format='%(refname:short)' refs/heads/ refs/remotes/origin/ | grep -E '^(origin/)?(main|master|develop)$' | head -3`
- 推定マージベース (vs origin/main): !`git merge-base origin/main HEAD 2>/dev/null || echo "n/a"`
- 累積コミット (vs origin/main): !`git log origin/main..HEAD --oneline 2>/dev/null | head -20`
- 累積差分サマリ (vs origin/main): !`git diff origin/main...HEAD --stat 2>/dev/null | tail -20`

ベースブランチは引数 `$ARGUMENTS` の有無で分岐するため、起動時コンテキストは `origin/main` 仮定の参考値として扱う。

## 事前チェック

1. `git branch --show-current` で現在ブランチを取得。`main` / `master` / `develop` 上ならレビュー対象がないので中止し、トピックブランチへ切り替えるよう案内。
2. ベースブランチを決定:
   - 引数 `$ARGUMENTS` が指定されていればそれを採用 (例: `/code-review develop` なら `develop`、`/code-review origin/release/x` なら `origin/release/x`)。`git rev-parse --verify <base>` で存在確認し、見つからなければユーザーに正しいブランチ名を聞き直す。
   - 引数が無ければ既定 `origin/main`。起動時コンテキストで `n/a` なら `master` / `develop` / ローカル `main` を順に試して最初に見つかったものを採用。どれも当たらなければユーザーにベースブランチを質問。
3. 採用するベースブランチをユーザーに 1 行で提示し、明示的に承認を取る。例: `ベースは origin/main で進めます。よいですか？` (引数で指定された場合は `指定どおり <base> で進めます。` と短く確認する)
4. 累積差分が 0 行なら `レビュー対象の差分がありません。` と返して終了。
5. 累積差分が **1000 行を超える** ときは、観点を絞るか / コミット単位でレビューするか / そのまま続行するかを選んでもらう。

## レビュー手順

1. `git diff <base>...HEAD` の本文を読む。サイズが大きい場合は **ファイル単位** で `git diff <base>...HEAD -- <path>` に分けて読む。
2. 以下の観点を 1 パスで横断チェック (浅め広め):
   - **シークレット混入**: `.env`, `*_KEY`, `*_TOKEN`, `BEGIN .* PRIVATE KEY`, ハードコード URL に含まれる認証情報など
   - **デバッグコード残置**: `console.log` / `console.debug` / `debugger` / `dd(` / `dump(` / `var_dump` / `print(` / `pp ` (Ruby) / `fmt.Println` の追加行
   - **TODO / FIXME / XXX** が **新規** 追加されているか (既存は無視)
   - **明らかな typo**: 識別子・コメント (英単語スペル誤り、地の日本語の誤字)
   - **コミット粒度**: 1 コミット内で「機能追加 + 無関係なリファクタ」「実装 + 大量フォーマット」が混ざっていないか
   - **不要な差分**: 末尾空白だけの変更、コメントアウトされた古いコード、空行だけの増減
   - **明らかな破綻**: 構文エラー疑い、未閉じカッコ、明らかに使われていない import の追加
3. 各指摘は `<ファイルパス>:<行番号>` を必ず付ける。行番号は diff の `@@ -a,b +c,d @@` から新ファイル側 (`+c`) で計算する。

## 出力フォーマット

レビュー結果は以下の Markdown で返す。指摘がない区分は見出しごと省略してよい。見出しはすべて日本語で出すこと (英語ラベル `Must` / `Nits` / `Should` を使わない)。

```markdown
## サマリ

- ベース: <base>
- 範囲: <commits> コミット / <files> ファイル / +<add>/-<del> 行
- 所感: <1-2 文>

## 要修正

- <path>:<line> - <指摘内容>

## 任意修正

- <path>:<line> - <指摘内容>
```

判定の目安:

- **要修正**: そのまま push したら明らかに事故るもの (シークレット、デバッグコード、構文破綻、コミットに入れるべきでない無関係差分)
- **任意修正**: 動作には影響しないが整えた方がよいもの (typo、コメントアウト残骸、軽微なスタイル)

## 禁止事項

- 自動でコード修正・コミット・amend をしない。レビューは **読むだけ**。
- ベースブランチ承認なしに `git diff` を実行しない (起動時コンテキストの範囲なら可)。
- `git push` / `git reset` / `git rebase` 等の状態変更コマンドは使わない。
- 推測で指摘を増やさない。実際に diff 上で確認できた箇所のみ報告する。

## 最後に伝えること

- 指摘 0 件なら `要修正 / 任意修正 ともに指摘なし。` と明示する。
- 要修正がある場合は「修正後にもう一度 `/code-review` を実行することを推奨します」と案内する。
- 観点を変えたい / より厳しく見たい場合は `/cross-review` (辛口/甘口クロスバリデーション版) を案内する。

コードレビュースキル実行

cd svelte-todo

# 用意している練習用ブランチに切り替え
git switch -c feat/filter origin/feat/filter

claude

/code-review main

• feat/filter ブランチには All, Active, Completed でフィルタリングできる機能を追加している

どのベースブランチ (main 等) との差分をレビューしてもらいたいか指定します。 AIレビュー結果例:

## サマリ

- ベース: main
- 範囲: 1 コミット / 1 ファイル / +33/-4 行
- 所感: フィルタ機能の追加は素直で、`deleteTodo` をインデックスから `Todo` 参照に変えたのもフィルタ後配列との整合上正しい修正。致命的な問題は見当たらない。

## 任意修正

- src/routes/+page.svelte:115 - `{#each filteredTodos as todo (todo)}` のキーにオブジェクト参照を使っている。`Todo` 型は `{ text, done }` のみで一意性保証がなく、同じ文言の Todo を 2 件作ると参照は別でも実装上の意図が曖昧になる。`Todo` に `id` を追加し `(todo.id)` をキーにするのが堅い (将来の並び替え/編集にも有利)。
- src/routes/+page.svelte:55-59 - `deleteTodo` で `indexOf` 検索→`splice` するより、`todos = todos.filter((t) => t !== todo)` の方が immutability ガイドライン (グローバル `standards.md`) に沿う。`splice` は既存コードでも使われているため必須ではないが、新規追加分はイミュータブル更新に寄せるとよい。
- src/routes/+page.svelte:87 - `aria-label="Filter todos"` が英語。UI のラベル (`All` / `Active` / `Completed`) も英語のままで一貫しているので問題ないが、本アプリは日本語想定なら i18n 方針を決めて統一すると良い (任意)。

要修正の指摘なし。観点を変えてより厳しく見たい場合は `/cross-review` の利用を案内します。

致命的な問題はなし。 Todoの型にidをキーにすると並び順が保証されるよ的なアドバイスなどをくれている。

2. クロスレビュースキル /cross-review を登録

以下の内容で ~/.claude/skills/cross-review/SKILL.md を作成。

mkdir -p ~/.claude/skills/code-review
vi ~/.claude/skills/code-review/SKILL.md

---
name: cross-review
description: |
  現在のフィーチャーブランチの累積差分 (base..HEAD) を、辛口/甘口の 2 ロールで
  並列レビューさせ、両者の指摘をすり合わせて統合レポートを返す。
  単一 AI レビューの視点偏りをクロスバリデーションで補正するためのスキル。
disable-model-invocation: true
allowed-tools: Bash(git *), Read, Grep, Glob, Agent
argument-hint: "[base-branch]"
---

## 起動時コンテキスト

- 現在ブランチ: !`git branch --show-current`
- 作業ツリー状態: !`git status --short`
- 推定マージベース (vs origin/main): !`git merge-base origin/main HEAD 2>/dev/null || echo "n/a"`
- 累積コミット (vs origin/main): !`git log origin/main..HEAD --oneline 2>/dev/null | head -30`
- 累積差分サマリ (vs origin/main): !`git diff origin/main...HEAD --stat 2>/dev/null | tail -30`

ベースブランチは引数 `$ARGUMENTS` の有無で分岐するため、起動時コンテキストは `origin/main` 仮定の参考値として扱う。

## 事前チェック

1. `git branch --show-current` で現在ブランチを取得。`main` / `master` / `develop` 上なら中止。
2. ベースブランチを決定:
   - 引数 `$ARGUMENTS` が指定されていればそれを採用 (例: `/cross-review develop`)。`git rev-parse --verify <base>` で存在確認し、見つからなければユーザーに聞き直す。
   - 引数が無ければ既定 `origin/main`。無ければ `master` / `develop` / ローカル `main` を順に試す。
3. 採用するベースをユーザーに提示し承認を取る (引数で指定された場合は `指定どおり <base> で進めます。` と短く確認)。
4. 累積差分が 0 行なら終了。
5. 累積差分が **2000 行超** のときは、観点を絞るか / コミット単位レビューに切り替えるか / そのまま続行するかを確認。

## レビューフロー

### ステップ 1: 2 ロール並列起動

承認後、**1 メッセージ内で 2 つの Agent を並列に起動** する (Claude Code は同一メッセージ内の複数 Agent 呼び出しを並列実行する)。

両エージェントには **同じ diff 本文** を渡し、ロール定義 (口調・観点・厳しさ) のみ差し替える。

#### 共通プロンプト要素

両ロールに共通で渡す内容:

- ベースブランチと現ブランチ名
- `git diff <base>...HEAD` の本文 (差分が大きい場合はファイル単位に分けて全文)
- 累積コミット一覧 (`git log <base>..HEAD --oneline`)
- 出力フォーマット指定 (下記)
- 指摘には必ず `<path>:<line>` を付けること
- 推測ではなく diff 上で確認できる箇所のみ報告すること

#### 辛口ロール

```text
あなたは辛口のシニアレビュアーです。マージブロックすべき欠陥を見逃さないことが最優先です。

観点:
- 設計の妥当性 (責務分離、抽象化の早すぎ/遅すぎ)
- 命名整合 (既存コードベースとの一貫性、誤解を招く命名)
- エラーハンドリング (例外漏れ、握りつぶし、エラーメッセージのリーク)
- セキュリティ (入力検証、SQLi/XSS、権限チェック、シークレット混入)
- テスト網羅 (新規ロジックに対するテストの有無、境界値、異常系)
- パフォーマンス (N+1、O(n^2) ループ、不要な同期処理)
- 可読性・保守性

スタンス: 改善余地はすべて推奨修正以上で出してください。「動くなら通す」ではなく「ベストか」で判断してください。

出力フォーマット (Markdown、見出しは日本語固定。`Must` / `Should` などの英語ラベルは使わない):

## 要修正
- <path>:<line> - <指摘>

## 推奨修正
- <path>:<line> - <指摘>

## サマリ
<1-2 文>
```

#### 甘口ロール

```text
あなたは甘口のレビュアーです。マージを止めるべき欠陥だけ指摘してください。スタイルや命名、軽微な改善は無視します。

観点 (これ以外は無視):
- バグ (動作が壊れる、データ破損リスク、無限ループ、競合状態)
- セキュリティ事故 (シークレット混入、認証回避、権限昇格、SQLi/XSS)
- データ消失リスク (誤った DELETE / DROP、unsafe な migration)
- ビルド破綻 (構文エラー、未定義参照)

スタンス: 「動いて事故らないなら通す」。命名・スタイル・テスト不足・軽微なリファクタ提案は出さない。

出力フォーマット (Markdown、見出しは日本語固定):

## 要修正
- <path>:<line> - <指摘>

## サマリ
<1-2 文>
```

### ステップ 2: すり合わせ

両エージェントの結果が揃ったら、**指摘を箇所 (path:line もしくは同一トピック) でグルーピング** し、以下のロジックで分類する:

| 辛口     | 甘口     | 分類             | 重大度                                                  |
| -------- | -------- | ---------------- | ------------------------------------------------------- |
| 指摘あり | 指摘あり | **合意指摘**     | 確定 (両者が指摘するのでほぼ確実)                       |
| 指摘なし | 指摘あり | **重大度高**     | 最優先 (甘口がブロッカー認定する箇所は本当に危険)       |
| 指摘あり | 指摘なし | **要すり合わせ** | 採否はユーザー判断 (辛口の改善提案 vs 甘口のスルー判定) |
| 指摘なし | 指摘なし | 出力しない       | -                                                       |

トピックの突合は次の手順で行う:

1. 完全一致の `path:line` で揃っているものを最初にマージ。
2. 同じファイルの近接行 (±3 行以内) かつ指摘内容が概ね同じものは **合意指摘** に寄せる。判断に迷ったら「合意」ではなく「要すり合わせ」へ寄せる。
3. ファイル横断の同一トピック (例: 「全体的にエラーハンドリング不足」など総論) は分類せず **サマリ** に回す。

### ステップ 3: 不一致が多いときのオプション

`要すり合わせ` が **5 件以上** のときは、ユーザーに次の選択肢を提示してよい (任意):

- **3 人目のジャッジを呼ぶ**: もう 1 つ Agent を起動し、辛口/甘口両方の指摘を渡して中立的な判定 (採用 / 却下 / 議論) をさせる
- **そのまま提示する**: ユーザー自身が判断する

ジャッジを呼ぶ場合のロール:

```text
あなたは中立のテックリードです。辛口レビュアーが出した指摘を、甘口レビュアーがスルーしました。
辛口の主張と diff の該当箇所を踏まえ、各指摘について「採用 (要修正/推奨修正)」「却下」「保留 (要議論)」のいずれかを判定し、
1 行で理由を添えてください。
```

## 出力フォーマット (最終レポート)

最終レポートの見出し・ラベルはすべて日本語で出すこと (`Must` / `Should` / `Nits` などの英語ラベルは使わない)。

### 出力原則 (読みやすさのため必ず守る)

- **進行ログを結果に混ぜない**: 「並列起動します」「⏺ N agents finished」などの進捗表示は最終レポートと同じ流れに出さない (内部処理として実行し、結果出力は最終レポートだけにする)。
- **空セクションは出さない**: 0 件の区分は見出しごと省略する。「（なし）」とだけ書いた見出しを残さない。
- **「言及なし」の繰り返し禁止**: セクション見出しで「辛口のみ」と分類済みなので、各項目内に `甘口: 言及なし` のような片側ロール無言及行を書かない。
- **推奨アクション語彙は 3 値に正規化**: `採用推奨` / `仕様確認` / `保留・任意` の 3 段階のみ。「採用寄り」「保留〜採用」「却下」などの中間語彙は使わない (ジャッジ判定セクションは別)。
- **項目内の行数は最大 2 行**: 1 行目に「箇所と指摘要約」、2 行目に必要なら「根拠 / 反論 / 補足」。ロール意見が割れた時のみ 2 行目で並記。

### テンプレート

```markdown
## サマリ

- ベース: <base>
- 範囲: <commits> コミット / <files> ファイル / +<add>/-<del> 行
- 辛口の所感: <1-2 文>
- 甘口の所感: <1-2 文>
- 合意指摘 / 重大度高: <X> 件 / <Y> 件 ※両方 0 のときは「いずれも 0 件」とだけ書く
- 要すり合わせ: <Z> 件 (採用推奨 <a> / 仕様確認 <b> / 保留・任意 <c>)

## 合意指摘 (両ロールが指摘)

- <path>:<line> - <指摘要約>

## 重大度高 (甘口のみ指摘)

- <path>:<line> - <指摘要約>

## 要すり合わせ (辛口のみ指摘)

### 採用推奨

- <path>:<line> - <指摘要約>

### 仕様確認

- <path>:<line> - <指摘要約>
  辛口: <根拠> / 甘口: <反論または静観の理由>

### 保留・任意

- <path>:<line> - <指摘要約>

## (オプション) ジャッジ判定

- <path>:<line> - 採用 / 却下 / 保留: <1 行理由>
```

### 「要すり合わせ」のサブセクション分類ロジック

辛口のみが指摘した項目を、3 サブセクションに振り分ける基準:

| 分類           | 条件                                                                                                                                        |
| -------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **採用推奨**   | 辛口の元出力で `要修正` だった、または明白なバグ・規約違反・デバッグ残置 (`console.log` / 未使用コード)・テスト欠如など反論余地が小さいもの |
| **仕様確認**   | 機能仕様の解釈で結論が変わるもの (例: 「編集時に完了状態をリセットすべきか」)、または辛口/甘口で意見が真っ向から割れたもの                  |
| **保留・任意** | リファクタ提案、抽象化、本 PR スコープ外、UX 改善の任意レベル                                                                               |

迷ったら一段下 (`採用推奨` から `仕様確認`、`仕様確認` から `保留・任意`) に倒す。各サブセクションが 0 件のときはそのサブ見出しごと省略する。

### ゼロ件・全件ゼロの扱い

- 個別セクションが 0 件: 見出しごと省略
- 合意指摘・重大度高が両方 0 件: サマリ行で「いずれも 0 件」とだけ書き、本文側のセクションは出さない
- 要すり合わせのサブセクションが 0 件: そのサブ見出しごと省略
- すべて 0 件: 本文は出さず `両ロールともに指摘なし。` の 1 行のみ

## 禁止事項

- 自動でコード修正・コミット・amend をしない (レビューのみ)。
- 同一メッセージで 2 ロールを並列起動すること。**直列 (1 つずつ) で呼ぶと無駄に時間がかかる**。
- 推測で指摘を増やさない。両エージェントの出力に存在しない指摘を最終レポートに混ぜない。
- ユーザー承認なしにジャッジ (3 人目) を呼ばない。
- `git push` / `git reset` / `git rebase` 等の状態変更コマンドは使わない。

## 最後に伝えること

最終レポートの末尾に **1 文だけ** 次のフォローアップを添える。複数の選択肢を並べない (現在の状態で最有効な 1 つに絞る)。

- 合意指摘 / 重大度高がある場合: 「先に <件数> 件のブロッカー候補を確認してください。」
- 要すり合わせの「採用推奨」が残っている場合: 「採用推奨 <件数> 件から取り込みを検討してください。」
- 不一致が 5 件以上で意見が割れている場合のみ: 「中立ジャッジを呼ぶなら『ジャッジ』と返信してください。」
- 全件 0 件の場合: 「修正不要。マージしてよい状態です。」

`/code-review` 再実行の案内などは原則出さない (ユーザーが必要なら自分で実行する)。

クロスレビュースキル実行1

同じ練習ブランチで:

cd svelte-todo

# 用意している練習用ブランチに切り替え
git switch -c feat/filter origin/feat/filter

claude

/cross-review main

両ロールの結果が揃ったのでレポートにまとめます。

---

## サマリ

- ベース: main
- 範囲: 1 コミット / 1 ファイル / +33/-4 行
- 辛口の所感: イミュータビリティ規約違反、参照同一性に依存した削除/key、テスト不在を要修正と評価。
- 甘口の所感: バグ・セキュリティ・データ消失・ビルド破綻に該当する欠陥は無し。マージ可。
- 合意指摘 / 重大度高: いずれも 0 件
- 要すり合わせ: 8 件 (採用推奨 4 / 仕様確認 2 / 保留・任意 2)

## 要すり合わせ (辛口のみ指摘)

### 採用推奨

- src/routes/+page.svelte:54-59, src/types/todo.ts - 本 PR で `deleteTodo(index)` → `deleteTodo(todo)` + `indexOf` に変更したことで参照同一性に依存した設計が新規導入された。`Todo` に `id` を追加し `id` ベースで削除・each key を組むのが堅牢。
- src/routes/+page.svelte:104 - `{#each filteredTodos as todo (todo)}` のオブジェクト参照 key は `id` ベース (`(todo.id)`) に切り替える前提で上の `id` 追加と連動させるのが望ましい。
- src/routes/+page.svelte:98 - `f === 'all' ? 'All' : f === 'active' ? 'Active' : 'Completed'` のネスト三項は `Filter` 追加時に壊れる。`Record<Filter, string>` ルックアップで網羅性を TS に検知させるべき。
- src/routes/+page.svelte 全体 - 新規ロジック (filter 派生、参照ベース削除) に対し Vitest/Playwright テストが未追加。`filter` 各値の派生結果、同名 Todo に対する `deleteTodo` 挙動の最低 2 ケースは追加したい。

### 仕様確認

- src/routes/+page.svelte:5,87,98 - `'all' | 'active' | 'completed'` 定数がテンプレート (L87) とラベル分岐 (L98) に散らばっている。`const FILTERS` 等で単一ソース化するか、現規模ならインライン許容かは設計判断。
- src/routes/+page.svelte:86 - `role="group"` + `aria-pressed` は排他選択の意味付けとしては弱い。`role="radiogroup"` + `aria-checked` のほうが支援技術には正確だが、トグル群として `aria-pressed` も許容範囲。

### 保留・任意

- src/routes/+page.svelte:49,57 - `push` / `splice` のミューテーションがグローバル規約「Immutability」に反する (`addTodo` の `push` は本 PR 範囲外、`deleteTodo` の `splice` は本 PR で書き直した箇所なので採用推奨に寄せても可)。
- src/routes/+page.svelte:23,26,33,38,49 - `localStorage` 入力検証欠如、`console.error` 残置、`newTodo.trim()` の保存時不整合、`isInitialized` ガードの初期化レース等は本 PR の差分外で既存からの問題。

---

採用推奨 4 件から取り込みを検討してください (`Todo.id` 追加が最も波及効果大)。

クロスレビュースキル実行2

cd svelte-todo

# 用意している練習用ブランチに切り替え
git switch -c feat/todo-enhancements origin/feat/edit-todo

claude

/cross-review main

• feat/edit-todo はTodoをダブルクリックで編集でき、Enterで保存する機能を追加。
  • 意図的にデバッグ用のコンソールログを消してなかったり、Escで編集をキャンセルする機能を実装していない状態

補足

1. マルチエージェント並列起動

Agent ツールを 同一メッセージ内で複数回呼ぶ と Claude Code は並列に実行します。直列で呼ぶと 2 倍の時間がかかるので、レビューのように 互いに依存しないタスク はまとめて投げます。allowed-tools に Agent を含めるのを忘れずに。

2. ロールでクロスレビュー

同じモデル・同じ diff でも、システム指示 (= ロール) を変えると結論が変わります。 /cross-review はそれを逆手にとり、辛口/甘口の 2 つの極端なロール で 2 回レビューさせ、両者の重なりと差分を機械的に分類しています。

• 両者一致 → ほぼ確実に修正案件 (合意指摘)
• 甘口のみ指摘 → 甘口がブロッカー認定する箇所は本当に危険 (重大度高)
• 辛口のみ指摘 → 採否は人間判断 (要すり合わせ)
• 両者スキップ → 出力しない

3. すり合わせロジックを SKILL.md に明文化する

/cross-review の SKILL.md には、上の分類を真理値表として書いてあります。AI は曖昧な「いい感じに統合して」より、表で示された分岐 のほうが安定してこなせます。プロンプトで決定論的な動きを引き出したいときの定石です。

4. 不一致が多いときの「3 人目のジャッジ」

要すり合わせ が多い場合は、3 つ目の Agent を中立ロールで起動して採否を裁定させるオプションがあります。デフォルトでは呼ばず、ユーザー承認を取ってから起動する設計にしておくと、コストが暴れません。

補足

• 使い分けの目安: コミット直後の素早い確認は /code-review、PR 前のじっくりレビューは /cross-review
• 大きな差分: 1000-2000 行を超えるブランチは、観点を絞るかコミット単位レビューに切り替えましょう。両スキルとも事前に確認を入れます。
• ロールを増やす: /cross-review の辛口/甘口 2 ロールに、「セキュリティ専任」「テスト専任」を追加して 3〜4 ロール化する発展版も作れます。

---