# Design Request

> デザインを見ながら対話で変更要望をまとめ、構造化されたIssueを作成する。

- Skill: `ousiass/design-request` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ousiass/design-request`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ousiass/design-request/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ousiass (https://skillmd.com/u/ousiass)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/ousiass/design-request

---


# design-request

デザイン参照（スクリーンショット、モックアップ、口頭説明）をもとに、対話で変更要望を整理し、実装可能な Issue を作成する。非エンジニアでも利用可能。

## 前提条件

- Claude Code 環境
- `gh` CLI（GitHub Issue 出力時）

## 引数

- **テキスト / 画像パス** (例: `/design-request ヘッダーのデザインを変えたい`): 初期情報として扱い、不足分をヒアリング
- **引数なし**: 最初からヒアリングを開始

## フェーズ1: デザイン参照の取得とプロジェクト把握

1. `AskUserQuestion` でデザインの参照を確認：
   - **スクリーンショット / 画像**: ファイルパスを受け取り `Read` で読み込む
   - **口頭説明**: テキストで受け取る
   - **両方**: 画像 + 補足説明
2. **プロジェクトの軽量スキャン**を実行する（ヒアリングの選択肢を実態に基づかせるため）：
   - ディレクトリ構成から画面・ページ一覧を把握（`pages/`, `views/`, `routes/` 等）
   - コンポーネントディレクトリの構造を把握（`components/` 等）
   - 使用フレームワーク・CSS ライブラリを特定
3. 対象の画面・コンポーネントがどこかを、**スキャン結果に基づく選択肢**で確認する

## フェーズ2: ヒアリング

**平易な日本語で質問し、技術用語は使わない。**
**曖昧なリクエストこそ丁寧に聞き出し、実装可能な具体性まで落とし込む。**

#### 2-1: 曖昧さの解消

ユーザーの入力が曖昧な場合、以下のパターンで具体化する。
**選択肢を提示して選ばせる形式**を優先し、自由記述の負担を減らす。

| ユーザーの入力例 | 聞き出すべきこと | 質問の仕方 |
|---------------|---------------|-----------|
| 「ダサい」「微妙」「イマイチ」 | どこが・何が気になるか | 選択肢提示: 色合い / レイアウト / フォント / 余白 / 全体の印象 / その他 |
| 「もっといい感じに」 | 理想のイメージ | 選択肢提示: シンプル・クリーン / モダン・洗練 / 温かみ・親しみ / 力強い・インパクト + 参考サイトがあれば |
| 「ここ変えたい」（箇所不明確） | 具体的な範囲 | 画面のどの部分か選択肢 or スクリーンショットで指し示してもらう |
| 「使いにくい」 | 何をしようとして困ったか | 具体的な操作シーンを聞く: どの操作で / 何が起きて / どうなってほしかったか |
| 「揃えたい」「統一感がない」 | 何を基準にするか | 選択肢提示: 既存の他の画面に合わせる / 新しい方向性にする + 基準となる画面があれば |

#### 2-2: 変更内容の収集

`AskUserQuestion` で以下をまとめて聞く（引数や画像でわかっている情報はスキップ）：

1. **何を変えたいか**: どの部分をどう変更したいか（2-1 で具体化済みならスキップ）
2. **理由・背景**: なぜ変更が必要か（任意）
3. **優先度**: 急ぎか、次のリリースで良いか

#### 2-3: 状況に応じた追加質問

回答内容に応じて**必要な情報だけ**追加で聞く（最大3つ、回答から推測できることは聞かない）：

| 状況 | 追加で聞くこと |
|------|-------------|
| レイアウト変更 | 画面サイズごとの振る舞い |
| 色・フォント変更 | 具体的な値や参考サイト |
| 新規要素の追加 | 配置場所、サイズ感、インタラクション |
| アニメーション | タイミング、種類、参考例 |
| 複数画面に影響 | 影響範囲の確認 |
| 条件付き表示 | どの条件でどう表示するか |
| 「おまかせ」と言われた | コード調査後に複数案を提示して選ばせる |

#### 2-4: 具体化の確認

ヒアリング完了後、理解した内容を**箇条書きで要約してユーザーに確認**する。
認識がずれていたら修正を繰り返し、合意を得てからフェーズ3に進む。

## フェーズ3: コードベース調査

1. **対象コンポーネントの特定** — 画面名・コンポーネント名で `Grep`/`Glob` 検索。必要に応じて `Explore` エージェントで調査
2. **現状の把握** — 現在のスタイリング、レイアウト、コンポーネント構造を確認
3. **影響範囲の確認** — 同じコンポーネントを使う他の画面、共有スタイルへの影響
4. **デザイン基盤の確認** — テーマ設定、デザイントークン、使用可能な既存コンポーネント

## フェーズ4: プレビューと出力先の確認

1. 収集情報と調査結果から下書きを作成（テンプレートは `templates/issue.md` を参照）
2. ユーザーにプレビュー表示
3. 修正があれば反映（納得するまで繰り返す）
4. `AskUserQuestion` で出力先を確認：
   - **GitHub Issue に作成**（推奨）: `design: <変更内容の要約>` の形式
   - **ローカル MD ファイルに保存**: プロジェクトルートに生成
   - **既存 Issue に追記**: Issue 番号を指定してコメント追加

## フェーズ5: 出力

#### GitHub Issue（新規作成）
- `gh issue create` でタイトル `design: <変更内容の要約>`、ラベル `design` で作成
- URL をユーザーに報告

#### 既存 Issue に追記
- `gh issue comment <番号>` でコメントとして追加
- URL をユーザーに報告

#### ローカル MD
- `design-request-<要約(kebab-case)>.md` をプロジェクトルートに生成
- パスをユーザーに報告

## 優先度の基準

| 優先度 | 基準 |
|-------|------|
| 🔴 緊急 | ユーザー体験を著しく損なう、リリースブロッカー |
| 🟠 高 | 主要画面の見た目の問題、ブランド不整合 |
| 🟡 中 | 改善すると良い、次回リリースで対応可 |
| 🟢 低 | 微調整、余裕があるときに対応 |

## ルール

- ヒアリングでは**技術用語を使わない**。ユーザーが使った場合のみ同じ言葉で返す
- `AskUserQuestion` の選択肢は**プロジェクトのスキャン結果に基づいて生成**する。プロジェクトに存在しない画面やコンポーネントを選択肢に含めない
- 質問は**最小限**。回答から推測できることは聞かない
- コード調査は**推測ではなく実際のコードを確認**
- Issue には**変更前の状態と変更後の期待**を明確に記載する
- Issue 作成前に**必ずプレビューしてユーザー承認を得る**
- コードを修正しない。成果物は Issue のみ