ousiass design-request
デザイン参照（スクリーンショット、モックアップ、口頭説明）をもとに、対話で変更要望を整理し、実装可能な Issue を作成する。非エンジニアでも利用可能。
前提条件
- Claude Code 環境
ghCLI（GitHub Issue 出力時）
引数
- テキスト / 画像パス (例:
/design-request ヘッダーのデザインを変えたい): 初期情報として扱い、不足分をヒアリング - 引数なし: 最初からヒアリングを開始
フェーズ1: デザイン参照の取得とプロジェクト把握
AskUserQuestionでデザインの参照を確認：- スクリーンショット / 画像: ファイルパスを受け取り
Readで読み込む - 口頭説明: テキストで受け取る
- 両方: 画像 + 補足説明
- スクリーンショット / 画像: ファイルパスを受け取り
- プロジェクトの軽量スキャンを実行する（ヒアリングの選択肢を実態に基づかせるため）：
- ディレクトリ構成から画面・ページ一覧を把握（
pages/,views/,routes/等） - コンポーネントディレクトリの構造を把握（
components/等） - 使用フレームワーク・CSS ライブラリを特定
- ディレクトリ構成から画面・ページ一覧を把握（
- 対象の画面・コンポーネントがどこかを、スキャン結果に基づく選択肢で確認する
フェーズ2: ヒアリング
平易な日本語で質問し、技術用語は使わない。 曖昧なリクエストこそ丁寧に聞き出し、実装可能な具体性まで落とし込む。
2-1: 曖昧さの解消
ユーザーの入力が曖昧な場合、以下のパターンで具体化する。 選択肢を提示して選ばせる形式を優先し、自由記述の負担を減らす。
| ユーザーの入力例 | 聞き出すべきこと | 質問の仕方 |
|---|---|---|
| 「ダサい」「微妙」「イマイチ」 | どこが・何が気になるか | 選択肢提示: 色合い / レイアウト / フォント / 余白 / 全体の印象 / その他 |
| 「もっといい感じに」 | 理想のイメージ | 選択肢提示: シンプル・クリーン / モダン・洗練 / 温かみ・親しみ / 力強い・インパクト + 参考サイトがあれば |
| 「ここ変えたい」（箇所不明確） | 具体的な範囲 | 画面のどの部分か選択肢 or スクリーンショットで指し示してもらう |
| 「使いにくい」 | 何をしようとして困ったか | 具体的な操作シーンを聞く: どの操作で / 何が起きて / どうなってほしかったか |
| 「揃えたい」「統一感がない」 | 何を基準にするか | 選択肢提示: 既存の他の画面に合わせる / 新しい方向性にする + 基準となる画面があれば |
2-2: 変更内容の収集
AskUserQuestion で以下をまとめて聞く（引数や画像でわかっている情報はスキップ）：
- 何を変えたいか: どの部分をどう変更したいか（2-1 で具体化済みならスキップ）
- 理由・背景: なぜ変更が必要か（任意）
- 優先度: 急ぎか、次のリリースで良いか
2-3: 状況に応じた追加質問
回答内容に応じて必要な情報だけ追加で聞く（最大3つ、回答から推測できることは聞かない）：
| 状況 | 追加で聞くこと |
|---|---|
| レイアウト変更 | 画面サイズごとの振る舞い |
| 色・フォント変更 | 具体的な値や参考サイト |
| 新規要素の追加 | 配置場所、サイズ感、インタラクション |
| アニメーション | タイミング、種類、参考例 |
| 複数画面に影響 | 影響範囲の確認 |
| 条件付き表示 | どの条件でどう表示するか |
| 「おまかせ」と言われた | コード調査後に複数案を提示して選ばせる |
2-4: 具体化の確認
ヒアリング完了後、理解した内容を箇条書きで要約してユーザーに確認する。 認識がずれていたら修正を繰り返し、合意を得てからフェーズ3に進む。
フェーズ3: コードベース調査
- 対象コンポーネントの特定 — 画面名・コンポーネント名で
Grep/Glob検索。必要に応じてExploreエージェントで調査 - 現状の把握 — 現在のスタイリング、レイアウト、コンポーネント構造を確認
- 影響範囲の確認 — 同じコンポーネントを使う他の画面、共有スタイルへの影響
- デザイン基盤の確認 — テーマ設定、デザイントークン、使用可能な既存コンポーネント
フェーズ4: プレビューと出力先の確認
- 収集情報と調査結果から下書きを作成（テンプレートは
templates/issue.mdを参照） - ユーザーにプレビュー表示
- 修正があれば反映（納得するまで繰り返す）
AskUserQuestionで出力先を確認：- GitHub Issue に作成（推奨）:
design: <変更内容の要約>の形式 - ローカル MD ファイルに保存: プロジェクトルートに生成
- 既存 Issue に追記: Issue 番号を指定してコメント追加
- GitHub 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 のみ