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 のみ