Design Critique

---
user-invocable: true
description: "デザイン成果物のレンダリング結果を、文脈遮断した新鮮な目で批評するデザイン版レビューループ。art-direction/design-drafterの規律に対応するルーブリックで違和感を言語化し、must-fix 0まで描画→批評→修正を反復する。design-mock/design-ui等の描画後、人間のVibe確認の前に使う。"
---

# design-critique — デザイン版レビューループ（文脈遮断の見る目）

`basic-review`（表面）→ `deep-review`（設計）の**デザイン版**。コードではなく**絵（レンダリング結果）**を見る。

> 出自: 同一デザインランゲージの複数モデル比較実験（2026-07）。
> 上位モデルの強さは描画力ではなく「自分の描画結果を新鮮な目で見て違和感を言語化し、直す」反復にあった
> （実例: 叩き台がv1→v4まで「チカチカの解消」「影だけの四角」等の批評ログを刻んで進化していた）。
> この「見る目」をモデル地力に頼らず仕組みにするのが本スキル。

## 発火条件

- `design-mock` / `design-ui` / `design-html` / `auto-design` が**描画を終えた直後**（人間のVibe確認の前）
- デザイン成果物が「あからさま」「テンプレっぽい」と感じて原因を特定したいとき
- `/design-critique <対象HTMLパス or URL>` で単体起動

## なぜ文脈遮断か（原理）

**作った本人は自分の選択に錨づけされる**。「光沢」と自分でSSOTに書いたモデルは、光沢の玉を見ても「宣言どおり」としか判定できない。
批評の有効性は次の3条件で決まる:

1. **固定ルーブリック**: 下記10問で見る。「なんとなく良い/悪い」を言わせない
2. **文脈遮断**: 批評者には**スクリーンショットとAD宣言だけ**を渡す。生成の経緯・コード・会話履歴は渡さない
3. **絵を見せる**: 「チカチカする」「影だけの四角に見える」はコードレビューでは出ない。必ずレンダリング結果を見る

---

## 実行手順（ループ）

```
1. レンダリング → 2. 文脈遮断批評（サブエージェント） → 3. 違和感リスト
   → 4. must-fix を修正 → 1. へ戻る … must-fix 0 で通過（最大3周で人間へ）
```

### 1. レンダリング（スクリーンショット取得）

- 静的HTML: ブラウザで開いてスクリーンショットを取得（agent-browser / chrome-devtools 等、利用可能な手段で）
- 開発サーバー: 起動してから対象画面を撮る
- **取得できない環境では停止して人間にスクリーンショットを依頼**する（コードから絵を想像して批評しない。未検証の批評は禁止事項の「でたらめな引用」と同種）
- 対象ビューポートは `doc/input/rdd.md` のターゲット表示環境に従う（主要ブレイクポイント分撮るのが理想、最低1枚）

### 2. 文脈遮断批評（サブエージェント起動）

**`design-critic` サブエージェント**（`.claude/agents/design-critic.md`。専任の批評者定義）に**以下の2点だけ**を渡して批評させる:

- スクリーンショット画像のパス
- AD宣言（`art-direction` の出力フォーマット。コンセプト一語/タグライン/材質/禁止則等）

ルーブリックはエージェント側が本スキルから自分で読む（ルーブリックのSSOTは本スキル）。

**渡してはいけないもの**: 生成の経緯、ソースコード、SSOT JSON、これまでの会話。批評者は「初めてこの画面を見る人」でなければならない。

⚠️ **結果の受け取り**

`teammateMode: tmux` ではサブエージェントは**独立セッション**として走るため、
**最終テキストは親に自動返却されない**。`SendMessage` で返させる必要がある。

- エージェント定義の `tools:` に **`SendMessage` が含まれているか**を確認する
- **戻ってこないときは「重い」と決めつけない。** ログの `turn_duration` で完走済みか分かる
  （詳細は `.claude/rules/tool-usage.md`「サブエージェントの結果が返らないとき」）
- 最終手段として、ログから結果を回収できる

### 3. 出力形式（違和感リスト）

批評者は以下の形式で返す:

```
【批評結果】判定: pass / fail
| # | 違和感（どこで何が） | ルーブリック該当 | 重大度 | 修正の方向 |
|---|---|---|---|---|
| 1 | {具体的に。例: 全ての玉に同じ濃い影があり全員が浮いて見える} | Q5 | must-fix | {例: 静止玉は接地影のみに} |
```

- 重大度: `must-fix`（ルーブリック違反）/ `nice`（好みの範囲）
- **違和感が本当に0なら、視線がどの順に動いたかを記述して証明する**（「問題ありません」の一言はレビューとして無効。見た証拠を残す）
- 良い点は書かない（賞賛は次の修正の錨になる）

### 4. 修正 → 反復

- `must-fix` を修正して手順1へ戻る。修正のたびに**ファイル冒頭コメントへ vN と「解消した違和感」を記録**する（例: `v3: チカチカの解消 ─ 近似色の矩形を並べない`。批評ログを成果物に刻む）
- `nice` は人間のVibe確認に委ねる（勝手に全部直して個性を均さない）

### 5. 収束条件

- **must-fix 0 で通過**。批評結果（最終の違和感リスト＋vログ）をAD宣言と併せて人間への提示に添える
- **最大3周**して収束しなければ中断し、残った違和感リストを添えて人間に判断を仰ぐ（無限ループしない）

---

## ルーブリック（SSOT。`art-direction` の各規律と対応）

批評者はこのルーブリック**だけ**で見る。各問に YES（問題なし）/ NO（違和感あり＝リストに記載）で答える。

| # | 問い | 対応する規律 |
|---|---|---|
| Q1 | **匿名テスト**: プロダクト名を隠したとき、他のアプリのスクショと区別がつくか（汎用テンプレ検知） | 導出線 |
| Q2 | **導出線**: 目につく視覚判断（材質/色/影/角丸/タイポ）がAD宣言のコンセプト一語から説明できるか | 導出線 |
| Q3 | **材質整合**: コンセプトの手触りと描画の質感が一致しているか（例:「とける」のに光沢プラスチックは矛盾） | 材質ファースト |
| Q4 | **禁色**: 純白のハイライト・純黒の影がないか。影の色相が1系統（パレット由来の有彩色）に揃っているか | 禁色 |
| Q5 | **効果の序列**: 影・動き・彩度が「状態の差」にだけ割り当てられているか（全要素に同じ影/全部が動く＝NO） | 効果の序列 |
| Q6 | **声量**: 見出し・数値が必要以上に大きく/太くないか。画面が静かか | 声量予算 |
| Q7 | **引き算**: カードで囲われた静的情報がないか。塗り（solid fill）は1〜2個以内か | 引き算の禁止則 |
| Q8 | **シグネチャ表現**: テーマ由来の固有表現を1つ指させるか。それは装飾でなく状態・操作に宿っているか | シグネチャ表現 |
| Q9 | **声**: 名前・タグライン・コピーがプロダクトの声で書かれているか | コンセプト導出線 |
| Q10 | **視線の序列**: 視線が迷わないか。主張する要素を3つ以内で順に指させるか。近似色の面が並んでチカチカしないか | 効果の序列 |
| Q11 | **グルーピング**: 意味の仲間が近くに束ねられているか。所属のねじれ（例: 操作説明が無関係な箱に同居）がないか。情報が等価な箱の羅列になっていないか | 情報設計（design-drafter） |
| Q12 | **余白と整列**: 余白は設計されたもの（グルーピングの道具）か、それとも「埋まらなかった余り」か。死んだ空間・巨大な空白がないか。要素はグリッドに整列し、重なりには意味があるか | 情報設計（design-drafter） |
| Q13 | **メタファーの漏れ（図地）**: メタファーが地（レイアウト・タイポ・情報表示）にまで染みていないか。地は乾いて静かか。「〜っぽい見た目の再現」が「〜のように振る舞う翻訳」の代わりに全面に塗られていないか。メタファー表現を1つ外しても画面が成立するか | デフォルメの規律 |

## やってはいけない

- コードを読んで批評する（絵だけを見る）
- 批評者に生成の文脈を渡す（錨になる）
- スクリーンショットが取れないのに想像で批評する（停止して人間に依頼）
- `nice` まで全部直して無難に均す（最終判断は人間のVibe Coding）
- 3周超えて自律で回し続ける