---
name: design-brainstorm
description: |
  デザインのブレインストーミングからPencilデザイン出力までを一貫して行うスキル。
  ページ構成・機能・レイアウトのプランニングを対話的に進め、Pencil MCPでデザインに落とし込む。
  使用タイミング:
  - 新しい画面やコンポーネントのデザインを考えたい時
  - 既存デザインのリニューアルやバリアント追加
  - 「デザインブレスト」「画面設計」「レイアウト考えて」等のリクエスト
  Keywords: デザイン, ブレスト, 画面設計, レイアウト, Pencil, ワイヤーフレーム
user-invocable: true
argument-hint: '<対象画面やコンポーネントの説明>'
---

# Design Brainstorm

デザインブレインストーミング → プランニング → Pencilデザイン出力。
対話を通じてデザインを形にする。

## 原則

- **Visual Over Verbal**: テキスト説明だけで終わらない。必ずPencilで形にする
- **Intent First**: 「誰が・何を・どう感じるか」を最初に明確にする
- **Design File is Truth**: 数値やパターンはdesigns/design.penが正。テキストで二重管理しない
- **対話的に進める**: 各フェーズでユーザーの確認を取りながら進行する

## 前提知識

以下のリファレンスを必要に応じて参照する:

- 共通思考原則 → [shared/thinking-principles.md](../shared/references/thinking-principles.md)
- デザインクラフト原則 → [references/design-craft.md](references/design-craft.md)
- Pencil MCP操作ナレッジ → [references/pencil-tips.md](references/pencil-tips.md)
- 既存デザインシステム → color-system-designスキル参照
- プロダクト思想 → `.design-intent/purpose.md`（存在する場合）

---

## Phase 1: Intent — 誰のために、何を、どう感じさせるか

**このフェーズの目的**: デザインの方向性を決める土台を作る。

### 1.1 ヒアリング

ユーザーのリクエストから以下を明確にする。不足があれば質問する:

**Who** — この画面を使う人は誰か

- 役割、スキルレベル、利用シーン（朝イチの確認？集中作業中？）

**What** — その人が達成したいこと

- 「ダッシュボードを見る」ではなく動詞で。「今日の優先タスクを3秒で把握する」

**Feel** — どう感じてほしいか

- 「きれい」「モダン」は禁止。具体的に。
- 例: 「密度感があるが圧迫感はない」「信頼できる静けさ」「一目で状況が分かる安心感」

### 1.2 プロダクト思想の確認

`.design-intent/purpose.md` が存在する場合、読み込んでIntentとの整合を確認する。
存在しない場合はスキップ。

### 1.3 Intent宣言

ヒアリング結果をまとめてユーザーに提示し、合意を取る:

```
Intent:
  Who: [具体的なペルソナ]
  What: [達成したいこと（動詞で）]
  Feel: [感じてほしいこと（具体的に）]
```

**ユーザーの合意を得てから次に進む。**

---

## Phase 2: Explore — デザインの方向性を探索する

**このフェーズの目的**: Intentを満たすデザインの方向性を2〜3案提示する。

### 2.1 現状調査

- 既存のdesigns/design.penをPencil MCPで確認（関連する画面・コンポーネントがあれば）
- 既存の変数・パターンを把握: `mcp__pencil__get_variables()`
- 関連する画面があればスクリーンショットを取得

### 2.2 ドメイン探索

interface-designの思考法に従い、プロダクトの世界を探索する:

**Domain** — このプロダクトの世界にある概念・メタファー（5つ以上）
**Color World** — この世界に自然に存在する色（既存パレットとの親和性も考慮）
**Signature** — このプロダクトにしかないデザイン上の特徴
**Defaults** — この種の画面で「よくある」デザイン（＝避けるべき安易な選択）3つ

### 2.3 方向性提案

2〜3案を以下の形式で提示:

```
--- 方向性A: [名前] ---
概要: [1〜2文で方向性を説明]
レイアウト: [構成の特徴]
カラー: [既存変数との関係、新規が必要な場合はその理由]
タイポグラフィ: [フォントの使い方]
Signature: [この方向ならではの特徴]
Intentとの整合: [Phase 1のIntentをどう満たすか]
```

**ユーザーに方向性を選んでもらう。ハイブリッドもOK。**

---

## Phase 3: Plan — 画面構成とコンポーネント設計

**このフェーズの目的**: 選ばれた方向性を具体的な画面設計に落とす。

### 3.1 画面構成

選択された方向性に基づいて:

- ページ全体のレイアウト構成（ヘッダー、サイドバー、コンテンツエリア等）
- 情報の優先順位と配置
- コンポーネントの一覧と役割

### 3.2 コンポーネント設計

各コンポーネントについて:

- 表示する情報と優先順位
- サイズ感（既存パターンとの整合）
- 使用する既存変数（$--teal-600, $--spacing-md 等）
- 新規変数が必要な場合はユーザーに確認

### 3.3 設計確認

画面構成をテキストまたは簡易図で提示し、ユーザーの合意を取る。

**ユーザーの合意を得てから次に進む。**

---

## Phase 4: Design — Pencilでデザインを作成する

**このフェーズの目的**: Phase 3の設計をPencil MCPで実際のデザインに落とし込む。

### 4.1 準備

```javascript
// エディタ状態確認
mcp__pencil__get_editor_state();

// デザインファイルを開く（既存ファイルがある場合）
mcp__pencil__open_document({ filePathOrTemplate: 'designs/design.pen' });

// 配置場所を確認
mcp__pencil__find_empty_space_on_canvas({ direction: 'right', width: X, height: Y });
```

### 4.2 フレーム構築

batch_designでフレームを構築する:

- 1回のbatch_designは最大25オペレーション
- 作業中は `placeholder: true` を設定
- 既存の変数を積極的に参照（`"$--variable-name"` 形式）
- テキストノードには `textGrowth: "fixed-width"` を付ける
- justifyContentは `"space_between"`（ハイフンではなくアンダースコア）
- paddingで変数参照: `["$--spacing-md", "$--spacing-lg"]`

### 4.3 変数バインド

- fill/stroke/fontSize等で変数参照する場合は `batch_design` の `U()` で設定
- `replace_all_matching_properties` は変数バインドに使えない（文字列保存のみ）

### 4.4 完了処理

- `placeholder: false` を設定
- スクリーンショットを取得して確認

---

## Phase 5: Review — 3人のレビュワーによるチェック

**このフェーズの目的**: 実装者以外の3つの視点でデザインを検証する。

### 5.1 セルフチェック（自動）

Pencilのスクリーンショットを撮り、以下をまず自分でチェック:

- Phase 1のIntentとの整合
- 既存デザインシステムとの一貫性
- 明らかなレイアウト崩れや抜け

問題があれば修正してからレビュワーに渡す。

### 5.2 レビュワー3名によるレビュー

スクリーンショットとPhase 1〜3の情報を基に、以下の3つの視点でレビューする:

#### UXデザイナー

**視点**: ユーザー体験・使いやすさ

- 情報設計: 優先順位が視覚的に明確か
- 操作フロー: ユーザーの自然な視線・操作動線に沿っているか
- 認知負荷: 一度に処理する情報量は適切か
- アクセシビリティ: コントラスト比、タッチターゲット、色だけに頼った表現がないか

#### ビジュアルデザイナー

**視点**: 見た目の品質・クラフト

- 階層: サーフェス・テキスト・ボーダーの階層が明確か
- 余白: スペーシングシステムに一貫性があるか
- 色バランス: アクセントカラーの使い方が適切か（多すぎ・少なすぎ）
- タイポグラフィ: サイズ・ウェイトの差で情報の重要度が伝わるか
- 一貫性: 既存デザイン（他の画面・コンポーネント）とトーンが揃っているか

#### プロダクトオーナー

**視点**: プロダクト価値・Intentとの整合

- Intent整合: Phase 1で定めた「Who / What / Feel」を満たしているか
- 価値提供: この画面でユーザーが目的を達成できるか
- プロダクト思想: `.design-intent/purpose.md` がある場合、理念との整合
- 優先度: 最も重要な情報/アクションが最も目立っているか

### 5.3 レビュー結果の提示

```
Design Review: [画面名]

■ UXデザイナー
  ✅ [良い点]
  ⚠️ [改善提案] → [具体的な修正案]

■ ビジュアルデザイナー
  ✅ [良い点]
  ⚠️ [改善提案] → [具体的な修正案]

■ プロダクトオーナー
  ✅ [良い点]
  ⚠️ [改善提案] → [具体的な修正案]

→ 修正提案 N件。自動修正する？それとも調整したい箇所がある？
```

### 5.4 修正ループ

ユーザーの判断に基づいて:

- **自動修正**: レビュー指摘をPencil上で修正 → 再スクショ → 再確認
- **ユーザー調整**: ユーザーのフィードバックを反映して修正
- **完了**: 問題なければ終了

修正ループは最大3回。3回で収束しない場合はユーザーに方針を相談する。

---

## コミュニケーションルール

- 各フェーズの開始時に「今からPhase Xをやるね」と一言伝える
- **質問時は必ず `AskUserQuestion` ツールを使う**（テキストだけの質問は避ける）
  - 予想される回答を選択肢（2〜4個）として提示する
  - 自由回答が必要な場合も、想定される選択肢を提示しつつOtherで対応
- デザインの「なぜ」を常に説明する（「きれいだから」は禁止）
- レビュワーの指摘は客観的に。実装者（自分）の弁護はしない

## 中断・再開

途中で中断する場合:

- 現在のフェーズと状態をユーザーに伝える
- Pencilのplaceholderはtrueのまま残す
- 再開時はPhase番号を指定して途中から再開可能