design-exploration

[スキル名] design-exploration

ユーザーが新機能や新モジュールについて漠然としたアイデアを持っているものの、具体的な要件がまだ明確でない場合に、構造化された探索プロセスを通じて、漠然としたアイデアを明確な設計案へと収束させ、完全な設計参照ドキュメントを作成するのを支援します。

核心原則

• 推測せず、多く質問する — 範囲が確認されるまで図を作成せず、設計仕様がない場合は質問し、確信が持てない場合はユーザーに選択してもらいます。
• ASCII 先行 — まず情報構造とレイアウトロジックを合わせ、ロジックが正しいことを確認してから HTML に着手します。
• 一度に複数の案を提示する — 5〜8個の案をまとめて提示し、ユーザーに方向性を選択してもらいます。一つずつ試すのは避けます。
• 全状態が必須 — 正常状態は出発点に過ぎません。異常状態、境界条件、インタラクションフィードバックは網羅的に洗い出す必要があります。
• 決定は文書化する — 会話で確認されたすべての決定は、要件の要約に書き込み、会話のコンテキスト内だけに存在させないようにします。

成果物

探索ごとに 3つのファイル を作成し、設計/v{バージョン番号}-{モジュール名}/ ディレクトリにアーカイブします。

バージョン番号とモジュール名はユーザーが決定します。必ずユーザーに確認してください。

作業フロー

ステップ 1：要件の発散と収束

ユーザーが漠然としたアイデアを述べた後、積極的に以下の質問をします。

• ペインポイントは何ですか — 現在どのような問題に直面していますか？なぜこれを作りたいのですか？
• コアシナリオ — 最も典型的な使用シナリオは何ですか？
• 境界はどこですか — このバージョンで何を行いますか？何を行いませんか？

構造化された要件合意書にまとめます。

何を作るか：
- xxx
- xxx

何を作らないか：
- xxx

媒体：スタンドアロンアプリケーション / 既存アプリケーションの新しいタブ / プラグイン / ...

禁止事項：ユーザーが何か一言言っただけで図を作成し始めること。まず要件の境界を合わせる必要があります。

ステップ 2：技術調査（必要に応じて）

調査が必要かどうかの判断：機能が外部データ（設定ファイル、API、サードパーティシステム、ファイル形式）に関わる場合、まず技術的制約を調査する必要があります。純粋な UI 機能で外部依存がない場合は、スキップします。

調査内容：

• データ保存場所と形式
• 既存システムのインターフェースと制限
• 技術的実現可能性の検証

調査結果は設計案に直接影響します（例えば、2つのツールの設定形式が異なることが判明し、インターフェースに「タイプ」列を表示する必要がある、など）。

禁止事項：調査をスキップして直接図を描き、後で技術的に実現不可能であることが判明すること。

ステップ 3：ASCII による一括探索

一度に 5〜8個 の異なるアプローチの ASCII レイアウト案を作成します。各案には以下を含めます。

• ASCII レイアウト図
• コアとなるアイデアを説明する一文

案 A：カードリスト + ツールチェックボックス
┌──────────────────────────────────┐
│ ┌────────────────────────────┐   │
│ │ pencil       [✓] CC [✓] CX│   │
│ └────────────────────────────┘   │
└──────────────────────────────────┘

案 B：テーブルビュー、1行1項目
┌──────────────────────────────────┐
│ 名称       タイプ   CC    CX      │
│ pencil     stdio  [✓]   [✓]    │
│ github     http   [✓]   [✓]    │
└──────────────────────────────────┘

ユーザーは以下のことができます。

• 直接1つの案を選択する
• 複数の案の要素を組み合わせる（「B の構造 + E のスイッチスタイル」）
• すべてを却下し、新しい方向性を補足する

禁止事項：

• 1〜2個の案しか提示しない（ユーザーに選択肢がない）
• 10個を超える案を提示する（選択が困難になる）
• 案間の差異が小さすぎる（本質的な違いがない）

ステップ 4：デザインスタイルの確認

ユーザーに以下の質問をします。

1. 既存のデザイン仕様はありますか？（例：design-system.html）

   • ある → design tokens（色、フォントサイズ、角丸、間隔）を読み込み、厳密に遵守します。
   • ない → スタイルの好みを聞くか、直接図を作成してユーザーに感覚を選んでもらいます。

2. 参考にしたい既存のページはありますか？（外枠、ナビゲーション構造）

   • ある → 参考ページを読み込み、外枠のスタイル（例：mac-window、sidebar レイアウト）を合わせます。
   • ない → 独立したページとして扱います。

3. 媒体形式は？

   • 既存アプリケーションの新しいページ/タブ → 既存ページの外枠とナビゲーションに合わせる必要があります。
   • スタンドアロンアプリケーション → 外枠をカスタマイズします。
   • その他 → 詳細を確認します。

禁止事項：質問せずに、特定のデザイン仕様をデフォルトで使用すること。

ステップ 5：HTML デザインモックアップ

選択された案と確認されたデザインスタイルに基づいて、HTML モックアップを出力します。

• 実際のデータで埋める（lorem ipsum は使用しない）
• デザイン仕様がある場合、CSS 変数 / design tokens を厳密に使用する
• 参考ページがある場合、外枠構造は一貫性を保つ

出力後、ユーザーにブラウザで開いて確認してもらい、フィードバックに基づいて微調整します。微調整は具体的な小さな変更（間隔、配色、文言）であり、直接実行します。案の再選択は不要です。

ステップ 6：全状態の網羅

完全な全状態設計参照 HTML を作成します。以下の内容を必ず含めます。

必須で網羅するページ状態

必須で網羅するインタラクションフィードバック

• Toast まとめ：すべての操作の成功/失敗/警告 Toast。具体的な文言を含む。
• Toast ルール：位置、表示時間（成功は短く、エラーは長く）、同時に表示できる最大数。

必須で網羅する境界条件

• 長文の切り詰め（名前、パス、URL）
• 大量のデータのスクロール
• その他、具体的なシナリオに応じて補足

必須で含めるインタラクション動作ルール表

テーブル形式、列の定義：

すべてのユーザー操作とシステム動作の完全なマッピングを網羅し、フロントエンド開発者が直接参照して実装します。

ドキュメント構造

• 上部：タイトル、バージョン、日付
• 目次：アンカーリンク
• 各状態をセクションにする：タグ + タイトル + 説明 + プレビュー画面 + 注釈
• 下部：インタラクション動作ルール表

禁止事項：正常状態のみで終了すること。全状態の網羅は、このフローの主要な成果物です。

ステップ 7：要件の要約 + アーカイブ

テンプレート（templates/需求总结-模板.md）に基づいて要件の要約ドキュメントを生成します。

会話で確認されたすべての決定を抽出し、「主要な決定」セクションに書き込みます。これらの決定は会話のあちこちに散らばっていることが多いため、積極的に収集・整理し、漏れがないようにする必要があります。

3つのファイルを 設計/v{バージョン番号}-{モジュール名}/ ディレクトリにアーカイブします。バージョン番号とモジュール名はユーザーに確認します。

設計/v0.11-MCP管理/
├── 需求总结.md
├── mcp-manager-设计稿.html
└── mcp-manager-全状态设计参考.html

プロセス中のコミュニケーション規範

ユーザーに必ず質問すること

ユーザーに質問する必要がないこと

AI が決して行うべきではないこと

• ユーザーが漠然としたアイデアを述べただけで HTML を作成し始めること
• ASCII 案を1つしか作成しないこと
• 正常状態のみで異常状態を考慮しないこと
• 技術調査をスキップして直接図を描くこと（外部データに関わる場合）
• 決定を会話に残したまま、要件の要約に書き込まないこと
• 自分でバージョン番号とモジュール名を決めること
• 質問せずに、特定のデザイン仕様をデフォルトで使用すること