---
name: intent-first-review
description: 相手の意図・設計思想を先に読み取った上で、率直かつ建設的なレビューを行うスキル。「忖度なし、でも否定に寄り過ぎない」フィードバックで、意図を尊重しながら実益のある指摘をする。Use this skill when the user asks for an honest opinion, review, or critique with "忖度なし", "正直に意見して", "intent-first-review", or wants balanced feedback that respects their design intent while surfacing real issues.
version: 0.3.0
---

# Intent-First Review

設計者・作者の意図を先に理解してから、その文脈で率直に問題点を指摘するレビュースキル。

## 核心原則

**「なぜそうしたか」を読んでから「何が課題か」を言う。**

- **意図の先読み**: レビュー前に「なぜこの設計にしたか」の仮説を立てる
- **意図の尊重**: 前提や方向性を否定せず、その中での課題を出す
- **実益重視**: 指摘は「知っていたら役立つ情報」に絞る
- **忖度なし**: 問題点は問題点として明確に言う（ただし否定のための否定はしない）

## このスキルが活躍する場面

- ビジネス戦略・プロダクト方針の相談
- コード設計・アーキテクチャのレビュー
- LP・コピー・デザインのフィードバック
- 「意見がほしいけど全否定されたくない」というシチュエーション

NG例（他のスキルを使う場面）:
- コードのバグ検出のみ（修正不要） → `/code-review`
- バグ検出＋自動修正ループ → `/iterative-fix` or `/rfl`

## 実行モード

### 通常モード（デフォルト）

Agentツール（Opus 4.6）がStep 1〜5を単体で実行する。

### Codex dual レビューモード（`--c` 引数指定時）

`--c` が指定された場合、**Codex GPT-5.4 を2インスタンス並列で実行**し、結果をマージしてからStep 1〜5を適用する。
観点を分けることで単一インスタンスとの差別化を実現する。

- **インスタンス1（品質・設計観点）**: コード品質・設計一貫性・可読性・命名・重複コードに集中
- **インスタンス2（セキュリティ・バグ検出観点）**: セキュリティ脆弱性・バグ・エッジケース・エラーハンドリングに集中

**実行手順:**

SESSION_TMPDIRはメインコンテキストが `mktemp -d /tmp/ifr-codex-XXXXXX` で作成する。

**プロンプト構成（ファイルパス渡し方式）:**
レビュー対象のファイル内容をプロンプトに埋め込まない。代わりにファイルパス一覧のみを渡し、Codex自身にファイルを読ませる。これによりシェル引数のARG_MAX制限（Windows Git Bash: ~32KB）を回避する。

各インスタンスのプロンプトファイルに以下を書き込む:
```text
以下のファイルを読んでからレビューしてください。

## レビュー対象ファイル
[ファイルパスを1行ずつ列挙]

## レビュー観点（インスタンス固有）
[品質・設計 or セキュリティ・バグ検出]

## 出力フォーマット
[IFR Step 4フォーマット]
```

インスタンス1（品質・設計）の観点指示:
```text
## レビュー観点（品質・設計）
- コード品質・設計一貫性・可読性・命名規則・重複コードに集中してレビューしてください
- セキュリティ・バグ検出は対象外（別インスタンスが担当）
```

インスタンス2（セキュリティ・バグ検出）の観点指示:
```text
## レビュー観点（セキュリティ・バグ検出）
- セキュリティ脆弱性・バグ・エッジケース・エラーハンドリング漏れに集中してレビューしてください
- コード品質・設計観点は対象外（別インスタンスが担当）
```

**実行:**
```bash
# プロンプトをファイルに書き出してパイプで渡す（シェル引数に埋め込まない）
PROMPT_FILE=$(mktemp "$SESSION_TMPDIR"/codex1-prompt-XXXXXX.txt)
cat > "$PROMPT_FILE" << 'PROMPT_EOF'
[レビュールール + ファイルパス一覧（内容は埋め込まない）]
PROMPT_EOF
cat "$PROMPT_FILE" | "${CODEX_PATH:-codex}" exec \
  --dangerously-bypass-approvals-and-sandbox > "$SESSION_TMPDIR"/codex1-review.md
rm -f "$PROMPT_FILE"
# インスタンス2も同様
```

**出力の保存とマージ:**

1. 各インスタンスの出力を tmpファイルに保存:
   - インスタンス1 → `"$SESSION_TMPDIR"/codex1-review.md`
   - インスタンス2 → `"$SESSION_TMPDIR"/codex2-review.md`

2. マージスクリプトを実行:
```bash
python "$HOME/.claude/scripts/merge_parallel_reviews.py" \
  --input codex1:"$SESSION_TMPDIR"/codex1-review.md \
  --input codex2:"$SESSION_TMPDIR"/codex2-review.md \
  --format markdown --stats
```

3. マージ結果をStep 1〜5の入力として使用する（意図の読み取り・分類・修正はマージ後の結果に適用）

**スクリプト失敗時のフォールバック:** メインコンテキストが2インスタンスの出力を手動マージする。

**Codex失敗時のOpusフォールバック（ユーザー許可必須）:**
Codexインスタンスが両方とも失敗した場合（exit code != 0 かつ出力0バイト）、Opusサブエージェントへのフォールバックはトークン消費が大きいため、**ユーザーに許可を求めてから実行する**。
```
Codex dual reviewが失敗しました（理由: [エラー内容]）。
Opusサブエージェントでフォールバックレビューを実行しますか？（トークン消費が増加します）
```
ユーザーが許可した場合のみ、Opusサブエージェント（Agentツール）で同等のレビューを実行する。許可しなかった場合はレビューをスキップし、理由を報告して終了する。

**`/rfl --c` との違い:** `/rfl --c` は最大5ループの自動修正ループ付き。`/ifr --c` は単発レビュー（Step 5で最大3ループ）。

---

## プリフライトアプローチ確認（レビュー開始前）

レビュー対象と方針を提示し、ユーザーの承認を得てからレビュープロセスへ進む。

```
📋 レビュー対象:
- [ファイル1] (種別: Code/Doc)
- [ファイル2] ...

🔍 アプローチ:
- 意図の仮説: [このプロジェクト/変更の目的の推定]
- レビュー観点: [品質/セキュリティ/設計一貫性/etc.]

→ この方針でレビューを開始してよいですか？
```

**注意:** `/rfl` 経由で呼ばれた場合、このステップは rfl Step 0-9 で実施済みのためスキップする。
`$ARGUMENTS` に `--no-preflight` が含まれる場合もスキップ。

---

## レビュープロセス

### Step 1: 意図の言語化（読む前に仮説を立てる）

「この設計・選択の背景にある意図は何か？」を明示する。

```
[意図の読み取り]
「〜を実現したいから、あえて〜にしたのだと理解している」
「〜というトレードオフを承知の上で〜を優先したのだと思う」
```

意図が読み取れない場合は確認する:
```
「この設計の意図を教えてほしい。〜という理解で合ってる？」
```

### Step 2: 意図を尊重した指摘

前提・方向性を否定せず、**その前提の中での課題**を指摘する。

**禁止フレーム:**
- ❌ 「そもそもこのアプローチが間違ってる」
- ❌ 「前提からやり直した方がいい」（意図の確認なしに）
- ❌ 「一般的には〜が正しい」（意図と関係ない比較）

**推奨フレーム:**
- ✅ 「この方向性を前提にすると、〇〇が課題になる」
- ✅ 「意図は分かった上で言うと、〇〇のリスクがある」
- ✅ 「〜を実現したいなら、〇〇も考慮に入れると精度が上がる」

### Step 3: 指摘の優先度付けと網羅性

**件数制限なし。** 見つけた問題はすべて出す。速度より精度を優先し、時間をかけてでも高精度で問題箇所を発見する。
ただし優先度フィルターは維持し、実益のない指摘は出さない。

| 優先度 | 出す指摘 |
|--------|---------|
| 必ず出す | 意図を実現する上でブロッカーになる問題 |
| 出す | 気づいていなさそうなトレードオフ・リスク |
| 出さない | 好みの違い・別アプローチへの乗り換え推奨 |
| 出さない | 意図と関係のない「一般論」 |

**レビュー精度の原則:**
- 対象ファイルは全ファイル・全行を丁寧に読む（流し読み禁止）
- 「3件見つけたから終わり」ではなく、最後まで読み切ってから指摘を整理する
- 時間がかかっても構わない。網羅的に問題を拾い上げることが最優先

### Step 4: 出力フォーマット

```
意図: [1行の体言止め]

## 自動修正可
### [課題1タイトル]
- severity: [critical / warning / info]
- auto_fixable: true
- 何が起きるか: [具体的な問題]
- なぜ起きるか: [原因]
- 対策案:
  - 対象: [ファイルパス:行番号]
  - 変更内容: [何を・どう変えるか（diff相当の具体度）]

### [課題2タイトル]
...

## 要確認

> **堅牢方向の自動選択ルール**: 選択肢が「実装が重いが堅牢性が高い」vs「現状維持」の2択に割れた場合、**常に堅牢な方を自動選択して修正する**。ユーザーに聞かなくてよい。
> **適用条件（両方満たす場合のみ）:** 実装リスクがない（バグ・データ破壊・挙動変化の危険がない）かつ差がロバスト性・保守性・一貫性のみ（機能要件・設計意図の変更ではない）。
> **適用例:** インタラクティブ→非対話形式CLI、暗黙的判定→明示的判定、個別記述→統一フォーマット
> **除外例:** アーキテクチャ変更、削除・リネーム、ロジックの意味が変わる変更

> **自律修正原則（再検出可能性ベース）**: コンテキストが完全にリセットされた新セッション・別レビュアーが同じファイルをレビューした場合に**再び同じ指摘として検出される可能性が高い**問題で、かつ**修正の実装コストが中以下・リスクがない**（バグ混入・挙動変化・設計意図逸脱のおそれがない）ものは、`auto_fixable: true` として分類する。ユーザーに確認せず自動修正する。
> **背景:** ユーザーは人間がタスク遂行の時間的ボトルネックであると認識しており、レビューエージェントにはより高度な自律性を求めている。「次も同じ指摘が出る」問題を要確認で止めるのは非効率。
> **判定フロー:** (1)この指摘は新セッションでも再検出されるか? → No なら要確認（文脈依存の判断）。Yes → (2)修正コストは大か? リスクはあるか? → Yes なら要確認。No → **auto_fixable: true**。
> **「実害なし」は要確認の理由にならない:** (2)の「リスクあり」に「現状で実害が出ていない」は含めない。再現する指摘（(1)Yes）を「今は動いているから放置」で要確認にするのは禁止。未修正のまま残すと次のレビューサイクルで再検知され、フローの混乱を引き起こし続ける。要確認にするのは、対処することで別のリスクが生じる、または明確なトレードオフが存在する場合のみ。

severity: [critical / warning / info]
auto_fixable: false
問題: [課題タイトル]
詳細: [何が起きるか・なぜ問題か（具体的に1〜2文）]
判断ポイント: [ユーザーが判断すべき選択肢 or 方向性（「A or B」「〜か〜か」形式）]
─────────────────────────────

severity: [critical / warning / info]
auto_fixable: false
問題: [課題タイトル]
詳細: [何が起きるか・なぜ問題か（具体的に1〜2文）]
判断ポイント: [ユーザーが判断すべき選択肢 or 方向性]
─────────────────────────────

## 良い点（省略可）
[意図が上手く実現できている部分があれば一言]
```

### Step 4.5: machine-readable block 併記方針

可能なら、上の人間向けMarkdownに加えて **JSON fenced block** を併記する。
block 名は次を優先:

```text
```review-outcome-json
[ ...items... ]
```
```

items は `scripts/review_outcome_contract.py` / `scripts/review_output_bridge.py`
が読める shape に合わせる。

最低限ほしい項目:
- `type`
- `title`
- `summary`
- `severity`
- `file_path`
- `line`
- `status`
- `auto_fixable`
- `needs_judgment`
- `confidence`

補足:
- machine block を出せる場合は、それを PDCA 連携の正本として扱う
- machine block が難しい場合でも、上記 Step 4 の markdown は
  `scripts/review_output_bridge.py` が parse できる shape を保つ
- 特に `## 自動修正可` / `## 要確認` / `severity:` / `対象:` / `判断ポイント:`
  の見出し・キー名は崩さない

### Step 5: 自動修正ループ（レビュー後に必ず実行 — `mode: "review-only"` 時はスキップ）

**`mode: "review-only"` が指定されている場合、Step 5・Step 6は実行しない。** レビュー結果を返して終了する。

`mode: "review-only"` で終了する場合でも、環境が許せば review 結果を
temp markdown に保存し、次の bridge で PDCA へ流してよい:

```bash
python scripts/review_output_bridge.py \
  --input-file "$REVIEW_OUTPUT_FILE" \
  --reviewer intent-first-review \
  --runtime claude-code \
  --mode review-only \
  --forward-to-pdca
```

補足:
- sibling repo 構成なら `--forward-to-pdca` だけで
  `../claude-review-pdca/scripts/record-review-outcome.py` を自動解決する
- 必要に応じて `--pdca-root` / `--producer-path` / `PDCA_PRODUCER_PATH` を使う
- auto-fix ループを回していない単発レビューでは、legacy markdown 由来の
  `自動修正可` 項目は既定で `pending` 扱いになる

レビュー出力が完了したら、**ユーザーに確認せず**即座に以下のループを実行する。

1. `自動修正可` の全指摘を一括修正する
2. 修正完了後、差分を対象に再レビューを実施（Step 1〜4 を再実行）
3. 新たな `自動修正可` が出た場合 → 手順1に戻る（最大3ループ。`/rfl` 経由時はrfl側の最大5ループが適用され、本Step 5は実行されない）
   - 再レビュー時は修正差分のみを対象とし、「これはループN回目の再レビューです。前回の指摘に対する修正が正しく行われているかの確認と、修正によって新たに発生した問題がないかの検出が目的です。変更差分のみを対象にしてください。」を追加コンテキストとして付与する
4. `自動修正可` が0件になったら終了。`要確認` のみをまとめてユーザーに提示する

#### 堅牢方向の自動選択ルール（ユーザーへの確認不要）

選択肢が「実装が重いが堅牢性が高い」vs「現状維持」の2択に割れた場合、**常に堅牢な方を自動選択して修正する**。
ユーザーに聞かなくてよい。

**適用条件（両方満たす場合のみ）:**
- 実装リスクがない（バグ・データ破壊・挙動変化の危険がない）
- 差がロバスト性・保守性・一貫性のみ（機能要件・設計意図の変更ではない）

**判定フロー:** 「ユーザーから見た動作が変わるか？」→ Yes なら除外 → No なら堅牢性向上として自動選択
**適用例:** インタラクティブ→非対話形式CLI、暗黙的判定→明示的判定、個別記述→統一フォーマット
**除外例:** アーキテクチャ変更、削除・リネーム、ロジックの意味が変わる変更

**ループ終了後の報告形式:**
```
[自動修正ループ完了]
- 修正ループ回数: N回
- 修正した指摘: X件

---
## 要確認（ユーザー判断が必要な項目）
[Step 4のカード形式で列挙]
```

### /go-robust 自動実行（Step 5 終了後）

**`mode: "review-only"` 時はこのステップもスキップする。**

要確認の提示が完了したら、即座に `/go-robust` を実行する。
`/go-robust` は Step 0 で要確認件数をチェックし、0件なら「要確認なし。対応不要。」として自動終了する。
要確認が残っている場合は堅牢性優先方針で判断・処理可能なものを全件実行する。

#### /go-robust 強制実行 hook（enforce-go-robust）

Stop hook (`enforce-go-robust-stop.py`) がレビュー出力内の要確認マーカー
（`## 要確認` + severity + auto_fixable: false、または区切り線 `─────`）を検出し、
`/go-robust` 実行前に会話をユーザーへ返そうとした場合、`decision:"block"` で
強制継続させる。これにより「要確認を出したまま /go-robust を忘れる」事故を防ぐ。

**脱出口（どうしても /go-robust をスキップしたい場合）:**

- **`--no-go-robust` フラグ**: レビューコマンド実行時にフラグを付ける。
  例: `/ifr --no-go-robust` / `/rfl --no-go-robust`
  → そのサイクル1回限り hook をバイパス。
- **`/skip-go-robust-once` コマンド**: レビュー後・次応答の直前に単発で実行する。
  → 次の1応答だけ hook をバイパス（one-shot）。

**適用条件:** 脱出口を使うべきなのは「明示的に /go-robust を走らせたくない」
レアケースのみ（例: ユーザーに先に要確認を見せてから個別に判断したい場合）。
通常の運用では hook に任せて全件 /go-robust で処理させる方が安全。

### Step 6: 方針決定のマスタードキュメント記録要求

要確認への回答でユーザーがプロジェクト方針を確定させたら、**そのセッション内で**記録を提案する。

「今の決定（〇〇）をプロジェクトのマスタードキュメント（CLAUDE.md等）に残しておきますか？」

- **対象**: ユーザーが「要確認」に対して方向性を確定させた判断（「〇〇でいく」「〇〇はやめる」「〇〇を優先する」等）
- **タイミング**: 要確認への回答を受け取った直後、実装着手前
- **提案方法**: 記録するかどうか一言確認し、承認を得てから書き込む
- **記録先**: そのプロジェクトの `CLAUDE.md` / マスタードキュメント（ユーザーが指定する場合はその先）
- **記録形式**: 決定内容を1〜2行で簡潔に。「なぜそう決めたか」の背景も一言添えると価値が高い

**省略禁止条件**: 要確認への回答を受け取るたびに、その直後に提案する（まとめて後回しにしない）。
セッション終了前に提案していない方針決定が残っている場合は、必ず遡って確認する。

## 指摘スタンスのガイドライン

### 忖度なし = 問題は問題と言う

遠慮で問題を隠さない。はっきり言う。
ただし「言い方」は意図尊重フレームで。

```
❌ 「少し気になる点があって…」（問題の深刻さを隠す）
✅ 「これはユーザー離脱に直結する問題だと思う。理由は〜」
```

### 否定に寄り過ぎない = 設計者の意図を仮想敵にしない

「なぜこうしたか」に理解を示してから課題を出す。
相手が解説コストを払わずに済む構造にする。

```
❌ 「なぜこんな設計にしたのか理解できない」
✅ 「〜という意図は分かった。その上で〇〇が課題になる」
```

### バランスの基準

- 指摘は「伝えないと損をする情報」に絞る
- 「気に入らないから」の指摘はしない
- 「このアプローチより自分なら〜する」は、求められない限り言わない
- 相手が意図を持っていると推定できるなら、先に意図を確認する

## 実例

### ビジネス戦略の相談

**悪いレビュー例（否定に寄り過ぎ）:**
> 「BYOKモデルはそもそもライトユーザーに向かない。ターゲット設定が間違っている」

**良いレビュー例（intent-first）:**
> 「リテラシー高めのユーザーを最初から狙うという意図は理解した。その前提で言うと、LPがライトユーザーにも最適化されているとリテラシー高めの人には『これ俺向けじゃない』と感じさせるリスクがある。ターゲットを明示するコピーにすると離脱が減るかもしれない」

### コード設計のレビュー

**悪いレビュー例:**
> 「このアーキテクチャは拡張性がない。やり直した方がいい」

**良いレビュー例:**
> 「スピード優先でシンプルに保ちたいという意図だと理解している。その前提で言うと、〇〇のユースケースが増えた時に〇〇部分が詰まりやすい構造になっている。今のうちに〇〇だけ抽象化しておくと後が楽になる」

## 出力の言語・文体ガイドライン

### 言語

- **原則として日本語のみで書く**
- 技術用語はカタカナ化できるものはカタカナにする（例: URL ロット、利用規約、外部連携）
- どうしても英語表記が必要な固有名詞（サービス名・コマンド名等）はそのまま使ってよい
- 「URL rot」「ToS」「BYOK」のような略語は初出時に日本語で意味を添えるか、日本語に言い換える

**変換例:**
- ❌ `URL rot` → ✅ `URL が壊れるリスク（リンク切れ）`
- ❌ `ToS 的にグレー` → ✅ `利用規約的にグレー`
- ❌ `BYOK モデル` → ✅ `キー持ち込み型モデル（BYOK）` または `BYOK（自分の API キーを持ち込む方式）`

### 文体

- **AI が人間にレポートを提出する文体は使わない**
- 「〜という分析結果が得られた」「〜であることが確認される」のような書き方は避ける
- 対話・壁打ちの続きとして書く。相手と話している感覚を保つ
- 体言止めや箇条書きを使っても、全体として「言葉をかけている」トーンにする

**変換例:**
- ❌ 「本提案における主要リスクとして以下の2点が挙げられる」
- ✅ 「リスクは2つあって、まず〇〇、それから〇〇」

## 注意事項

- **意図の読み取りが難しい場合は必ず先に確認する**（推測で指摘しない）
- **件数制限なし。見つけた問題はすべて報告する**（優先度フィルターで「出さない」に該当するものは除く）
- **速度より精度を優先する**（ユーザーを待たせないための省略・手抜きは禁止。全ファイル・全行を丁寧に確認する）
- **対策案は意図を壊さないものを提案する**（「やり直し」推奨は禁止）
- **このスキルは「全否定」の代わりとして使わない**（忖度なしは維持する）