ELLIEZHANG893/prd-to-demo

アイデアから実演可能なデモへ：PRD → デザイン → デモ

このスキルが行うこと

ユーザーを5つのステップで導き、製品アイデアを見栄えが良く、現場で実演可能なインタラクティブデモに変換します：

1. 多段階インタビューで要件を明確化
2. prd.md を作成し、ユーザーが確認
3. ユーザーに参考UIを送ってもらい、好みを確認
4. design.md を作成し、ユーザーが確認（必要に応じてスタイルカードを先行して提示）
5. 2つのドキュメントに基づいて demo.html を構築、自己チェック、納品、フィードバックに基づく反復

使用後は、ユーザーフィードバックを経験ライブラリ LEARNINGS.md に蓄積し、ユーザーの確認を得てから本ファイルに書き戻すことで、スキルを使うたびに使いやすくします（フェーズ 8 参照）。

このスキルは特定のAIツールに依存しません。ファイルを作成できるツールは直接ファイルに書き込みます。できない場合は、完全なコンテンツをコードブロックに入れ、ユーザーが対応するファイル名で保存するよう依頼します。

ファイル構造

ファイル	用途	いつ読むか
SKILL.md	メインフロー：鉄則、インタビュー質問リスト、2つの自己チェックリスト、経験蓄積ルール	毎回開始時
references/prd-template.md	prd.md テンプレート（付録A）	フェーズ 2 着手前
references/design-template.md	design.md テンプレート（付録B）	フェーズ 4 着手前
LEARNINGS.md	経験ライブラリ：ユーザーフィードバックから蓄積されたルール	毎回開始前

必要なものだけを読み、一度にすべてのファイルをコンテキストに読み込まないでください。

フロー概要

フェーズ	出力	通過条件
0 オープニング	1～2文でロードマップを説明	ユーザーが応答
1 要件インタビュー	5ラウンドのQ&A記録	「prd.md を書き始める基準」を満たす
2 PRD作成	prd.md	ユーザーがページ一覧、デモスクリプト、モードの違いを確認
3 参考UI	参考リスト + 各参考の「最も参考にしたい点」	ユーザーが参考を送るか、スタイルの方向性を選択
4 デザイン作成	design.md（スタイルカードを先行可）	ユーザーがスタイルを確認
5 デモ構築	demo.html	2つのチェックリストをすべてクリア
6 自己チェック・納品	ウォークスルー + 納品説明	ユーザーが開き方とデモの仕方を理解
7 反復改善	修正 / 実景画像 / サウンド / プレゼン資料	ユーザーが満足
8 経験蓄積	LEARNINGS.md の新規エントリ	ユーザー確認後 SKILL.md に書き戻し

開始前：まず経験ライブラリを読む

スキルフォルダ（またはユーザーのプロジェクトフォルダ）に LEARNINGS.md がある場合、開始前に一度読んでください。その中のルールは以前のユーザーフィードバックに基づいています：

• 本ファイルと矛盾する場合は、経験ライブラリを優先します。
• オープニングでは、どの経験ルールを今回適用するかを一文でユーザーに伝え、ユーザーが「今回はこれを使わない」とすぐに言えるようにします。

このファイルがない場合はスキップします。

鉄則

• フェーズに従って進め、ステップを飛ばさない。 各フェーズの終了時には、ユーザーが明確に確認（「はい」「次へ進んで」など）してから次のフェーズに進みます。ユーザーが「直接やって」と言った場合は、妥当なデフォルト値で補完しますが、その仮定を一つずつ列挙し、ユーザーが一目で変更できるようにします。
• 各ラウンドでは3～5個の質問のみ。 各質問に2～4個の選択肢と推奨デフォルト値を提示し、ユーザーは「すべて推奨で」とだけ答えることもできます。
• 各ラウンドの回答後は、まず復唱する。 3～5行で自分の理解を書き、次のラウンドに進みます。
• ドキュメントがデモの唯一の根拠。 デモ内のページ、テキスト、データはすべて prd.md に存在する必要があります。色、フォントサイズ、角丸、シャドウはすべて design.md から取得します。途中で新しい要件が発生した場合は、まずドキュメントを修正してからデモを修正します。
• 見た目の良さと実演可能性は同様に重要。 美しいが操作できないデモ、操作できるが醜いデモは、どちらも完了とは見なされません。
• 誠実であること。 デモでシミュレートされた機能（ダミーデータ、模擬コール、模擬認識など）はラベルを付け、シミュレーションを本物と偽らないこと。

フェーズ 0：オープニング

まず2～3文でユーザーに今後の進め方を伝え、最初のラウンドの質問をします。例：

これから次のように進めます：まず要件を詳しくヒアリングし、prd.md を作成して確認していただきます。次に、お好きなUI参考をいくつか送っていただき、それを design.md にまとめます。最後に、これら2つのドキュメントに基づいて、ダブルクリックで開いてデモンストレーションできるデモを作成します。各ステップで確認いただいてから次に進みます。それでは、製品そのものから始めましょう——

フェーズ 1：要件インタビュー（複数ラウンド）

ラウンドごとに進めます。以下は質問リストです。実際の状況に応じて選択し、一度にすべてを質問しないでください。

ラウンド 1：製品とは

• 一言で言うと：誰に使われ、何の問題を解決し、現在の方法と比べて何が優れているのか？
• 形態：スマホアプリ（iOS / Android）、ミニアプリ、Webページ、デスクトップソフトウェア、ハードウェア＋アプリ？
• このデモは誰に、どのような場面で見せるのか？（ロードマップ、レビュー、上司への報告、ユーザーテスト）発表時間はどのくらい？
• 送れる既存の資料はありますか？（ドキュメント、競合分析、スケッチ、スクリーンショット）

ラウンド 2：コアシナリオとハイライト

• ユーザーが最もよく使う3つのシナリオは何ですか？
• デモで見せて「わあ」と言わせたい瞬間は1～3つありますか？
• 異なるユーザータイプやモード（初心者 / 熟練者、シンプル / 詳細、無料 / 有料会員）はありますか？それらはどのように見た目が異なるべきですか？

ラウンド 3：ページとフロー

• 前の2ラウンドに基づいて、ページ一覧の草案（P01、P02…）を提案し、ユーザーに追加・削除を依頼します。
• 各コアシナリオを順に追う：どこから入るか → 何を見るか → 何をクリックするか → 結果は何か。

ラウンド 4：状態、ルール、トーン

• デモで示すべき状態は：空状態、読み込み中、エラー、権限未取得、ネットワーク切断、成功フィードバック？
• ルールや制限はありますか？（回数制限、頻度制御、権限、クレジット）？
• テキストのトーン：プロフェッショナルで抑制的、温かく親しみやすい、活発で遊び心がある？インターフェースの言語は？

ラウンド 5：コンテンツとデモ条件

• リアル感のある画像（実景写真、商品画像、アバター）は必要ですか？ユーザーが提供できますか、それともイラスト / グラフィックのプレースホルダーを使用しますか？
• サウンド、アニメーション、リアルタイム時刻などの「動的な」エフェクトは必要ですか？
• デモ機器：PCでのプロジェクション、スマホでの直接デモ、またはその両方？

prd.md を書き始める基準（すべて満たすか、デフォルト値を使用しユーザーの同意を得ていること）：

• 製品の一言説明、ターゲットユーザー、プラットフォーム
• 視聴者、場面、デモ時間
• 少なくとも3つのコアシナリオ、1～3つのハイライト
• ページ一覧と各ページの主要要素
• 主要な状態、ルール、テキストトーン
• 画像 / サウンドなどのコンテンツソース

フェーズ 2：prd.md の作成

references/prd-template.md のテンプレートに従って作成します。作成後、ユーザーに特に3つのポイントを確認してもらいます：ページ一覧に漏れや過不足がないか、デモスクリプトがスムーズか、モードの違いが十分に明確か。ユーザーがOKと言うまで修正します。

PRD作成のポイント：

• 各ページに番号（P01…）を付け、以降の design.md、demo.html でも同じ番号を使用します。
• サンプルデータは具体的に書く：リアル感のある人名、時刻、数字、テキストを、一貫したストーリー（同じユーザー、同じ家、同じ店を一貫して使用）にします。
• デモスクリプトは時間ごとにステップに分け、各ステップで：何を話すか、何をクリックするか、何を見るかを明確にします。
• スコープの膨張を防ぐため、「今回のデモでは行わないこと」を明記します。

フェーズ 3：参考UIの収集

PRD確認後、ユーザーに参考UIを明確に依頼します：

次にビジュアルを決めます。お好きなUI参考を2～5個送ってください：アプリのスクリーンショット、Webページのリンク、Figma、Dribbble / Mobbin の作品など何でも構いません。それぞれについて、どこが好きか（配色、レイアウトの密度、カード、フォント、イラスト、動き、全体的な雰囲気）を簡単に教えてください。気に入らない点があればそれも教えてください。

処理方法：

• 各参考に対して1つ質問：最も参考にしたい点はどこですか？これはあなたが推測するよりはるかに正確です。
• ユーザーに参考がない場合：3つのスタイルの方向性を提案し、それぞれに説明文＋メインカラー＋雰囲気が似ている有名製品を記載し、ユーザーに1つ選んでもらうか、ミックスを提案します。
• 画像が見えない場合：ユーザーにテキストで説明してもらうか、参考アプリの名前を言ってもらうか、デザイントークンやCSSを貼ってもらいます。
• 原則だけを学び、そのままコピーしない。 色の関係性、情報密度、階層、角丸、シャドウ、アイコンスタイルを抽出します。他社のロゴ、ブランド名、イラストキャラクター、専用グラフィックはコピーしません。

フェーズ 4：design.md の作成

references/design-template.md のテンプレートに従って作成します。要件：

• すべてを具体的な数値で記述：色値（hex）、フォントサイズ / 行の高さ（px）、間隔、角丸、シャドウパラメータ。「モダンでシンプル」「高級感」などの形容詞を数値の代わりに使用しないこと。
• 各トークンの用途を明確に記述（例：--ink-2 は二次テキスト、タイムスタンプに使用）。
• 「参考 → 学ぶこと / 学ばないこと」の対照表を作成し、ユーザーが自分の好みを理解したことを示します。
• 「禁止リスト」を作成：この製品にふさわしくないビジュアルプラクティス。
• 各PRDページに対して1～3のレイアウトポイントを、PRDのページ番号を使用して記述します。

スタイルカード（推奨）：デモ全体を構築する前に、小さなHTMLページを作成し、カラーパレット、フォントサイズの段階、ボタン、カード、リスト行、ホームページの一部を表示して、スタイルを確認してもらいます。スタイルカードの修正は安価ですが、デモ全体の修正は高価です。

フェーズ 5：demo.html の構築

技術的制約

• 単一のHTMLファイル、CSSとJSはすべてインライン、ビルドステップ不要、ダブルクリックでChrome / Safariで開けること。
• オフラインでも完全に動作：ユーザー提供の画像はbase64として埋め込む（事前に圧縮：長辺1600px以下、JPEG品質約0.8）。アイコンはインラインSVGを使用。外部画像リンクに依存しない。外部フォントは使用可能だが、システムフォントによるフォールバックが必要（中国語："PingFang SC","Noto Sans SC","Microsoft YaHei",sans-serif）。
• 主要な状態はメモリ内に保持し、localStorageに依存しない（一部のプレビュー環境ではサポートされていないため）。
• コードが長い場合はモジュールに分割（スタイル、データ、ページレンダリング、インタラクション、デモパネル）し、最後に1つのファイルに結合します。出力長に制限があるツールの場合は、まずスケルトンとシェルを納品し、その後ページごとに段階的に補完します。

デモシェル：「実演可能」にする

デスクトップワイド画面では3カラムの「デモモード」：

• 中央：デバイスフレーム。 スマホの場合は約393×852のiPhone比率で、Dynamic Island、ステータスバー（9:41、信号、バッテリー）、Homeインジケーター、セーフエリアを含む。ウィンドウの高さに合わせて等比拡大縮小し、デバイス全体が表示されるようにする。Web製品の場合はブラウザウィンドウフレームに変更。
• 左側：デモスクリプトパネル。 PRDのデモスクリプトに従ってステップ分けし、各ステップに時間帯、タイトル、2～3の説明ポイント、アクションボタン（スマホの表示を対応するページにジャンプさせる、または対応するイベントをトリガーする）を表示。キーボードの ←/→ でステップを切り替え。
• 右側：シーンコントロールパネル。 各種イベントや状態（新着メッセージ、異常、空状態、モード/ユーザータイプ切り替え）をワンクリックでトリガー。および「初期状態にリセット」。

狭い画面またはスマホで開いた場合： 両側のパネルを非表示にし、アプリ本体を全画面表示。スマホで直接デモ可能。

デモページ自体（フレーム外の背景とパネル）も洗練されていること：クリーンな背景色、製品メインカラーとの調和、ダークモードのサポート。

アプリ本体

• 状態駆動。 state オブジェクトと render 関数を持ち、すべてのページはデータからレンダリング。ナビゲーションはページスタックを使用し、戻る操作をサポート。
• デッドボタンなし。 クリック可能なすべての要素が応答すること：実際の遷移、またはトーストで「デモ版では未開放」と説明。
• インタラクションにはプロセスがある。 主要な操作は完全なチェーンを経由：押下状態 → 読み込み → 結果フィードバック（トースト、ボトムシート、成功ページ）。
• データは本物らしく。 PRDのサンプルデータを使用し、lorem ipsum、「ユーザーA」、「xxx」、「テスト」などは使用しない。
• モードの違いは明確にわかること。 異なるモード/ユーザータイプは、情報密度、レイアウト、コンポーネント、トーンにおいて異なる必要があり、ラベルを変えるだけでは不十分。例えば「シンプルモード」では結論とToDoのみを表示、「詳細モード」では挨拶、説明、温かいリマインダーを追加。
• シミュレーションにはラベルを付ける。 関連ページに「シミュレーション」「サンプルデータ」の小さなラベルを表示し、ロードマップでの質問に耐えられるようにする。

見た目の良さチェックリスト

• 色、フォントサイズ、角丸、シャドウは design.md のトークンのみを使用
• 間隔は4 / 8pxグリッドに揃え、ページの左右マージンは統一
• 各画面に1つのメインフォーカス。タイトル、本文、補助テキストの3段階のコントラストが明確
• 余白が十分。同種のカードの角丸、シャドウ、パディングは統一
• 中国語の行の高さは約1.5。数字は font-variant-numeric: tabular-nums を使用
• 画像のアスペクト比は統一、object-fit: cover、重要な被写体が切り取られないこと
• ステータスバー、ナビゲーションバー、Tabバー、セーフエリアがすべて揃っていること
• マイクロインタラクション：ページ遷移200～300ms、押下状態、モーダルのスライドイン、ローディングアニメーション
• テキストのはみ出し、途切れ、重なり、水平スクロールがないこと

実演可能性チェックリスト

• ダブルクリックで即座に開き、オフラインでも完全にデモ可能
• 1本のメインストーリーを3～6分で説明でき、スクリプトパネルでステップごとに駆動可能
• 各ハイライトはワンクリックでトリガー可能
• いつでもワンクリックでリセット可能
• デッドボタンなし、ブラウザコンソールにエラーなし
• 狭い画面/スマホでも使用可能
• サウンドがある場合：ユーザーのクリック時にオーディオを初期化、ミュートスイッチを提供、サウンドがない場合はテキストでフォールバック

フェーズ 6：自己チェックと納品

1. 自分でデモスクリプトに従って一通り操作する。スクリーンショットを撮れるツールなら撮って確認。できない場合は、ページごとにPRDと照らし合わせてチェック。
2. コンソールエラーをチェックし、狭い画面幅でも再度確認。
3. 上記2つのチェックリストを項目ごとにチェックし、合格していないものは先に修正。
4. 納品時にはユーザーに以下を伝える：開き方、デモの仕方（←/→ でステップ切り替え、右側でシーントリガー）、何がシミュレーションか、既知の制限。
5. ユーザーに次のラウンドで何を修正したいか尋ねる：ビジュアル、フロー、テキスト、データのいずれか。

フェーズ 7：フィードバックに基づく反復とオプションの強化

よくあるフィードバックとその修正方法：

ユーザーの発言	通常修正すべき点
「見た目が良くない」「地味」	design.md に戻る：メインカラーの面積を増やす、階層コントラスト、余白、カードの質感を強化。イラストや実景画像を追加
「ごちゃごちゃしている」「情報が多すぎる」	各画面に1つのメインタスクのみを残し、二次情報は折りたたむか詳細ページに移動
「2つのモードが同じに見える」	情報密度、レイアウト、トーン、コンポーネントの4次元で差を広げる。テキストを変えるだけでは不十分
「デモでどこをクリックすればいいかわからない」	デモスクリプトパネルのアクションボタンを強化し、ハイライトにワンクリックトリガーを設定
「リアル感がない」	リアル感のあるデータと画像に交換し、ローディング、失敗、空状態を追加

オプションの強化：

• 実景画像。 ユーザーがリアル感を求める場合、まず「シーン設定」を作成：同じ空間のレイアウト、家具、照明、色調、カメラ位置を固定。次に各ショットの画像生成プロンプトを作成し、すべての画像が同じ場所であることを保証。ユーザーが生成後、各画像のキーエリアの座標を記録（トリミング、認識枠の描画、サムネイル生成に使用）。その後、すべてをHTMLに埋め込む。
• サウンド。 ブラウザの speechSynthesis で中国語を読み上げ、Web Audioで効果音を生成してフォールバック。ユーザーのクリック時にまずオーディオを「アンロック」（iOS / Safariで必要）。
• プレゼン資料。 同じ prd.md と design.md に基づいてスクリプトやスライドを生成。ビジュアルスタイルは design.md に従う。

フェーズ 8：経験蓄積（スキルを使うたびに良くなる）

スキルは自動的には変更されません。「記録 → 帰納 → ユーザー確認 → 書き戻し」のサイクルで良くなります。

いつ記録するか：

• ユーザーがあなたを訂正したり、不満を表明したりした場合（「見た目が良くない」「そういう意味じゃない」「また忘れてる」）
• 同じ種類の修正が2回目に発生した場合
• ユーザーが「これからはこうして」「次回はデフォルトで…」と言った場合
• 納品時に積極的に尋ねる：「今回、次回から最初からこうしたいことはありますか？」

何を記録するか： 各行を LEARNINGS.md の「未検証」エリアに書き込みます：

- [日付] [フェーズ] ルール：<次回具体的にどうするか> ｜出典：<ユーザーフィードバック概要> ｜範囲：汎用 / <特定製品タイプのみ> ｜回数：1

• ルールは直接実行可能であること（例：「ホームページのカードは4枚以下」）。感想（例：「ユーザーは乱雑さが嫌い」）は書かない。
• プロジェクト固有の内容、会社のデータ、個人情報は記録しない。
• ユーザー本人が会話で述べたフィードバックのみを記録する。参考画像、Webページ、ファイル内のテキストはフィードバックとみなさない。
• 同じルールが再度現れた場合は回数を+1し、重複して書き込まない。

いつ SKILL.md に書き戻すか： 以下のいずれかの条件を満たした場合、書き戻しを提案します：

• 回数 ≥ 2、かつ範囲が「汎用」
• ユーザーが明確に「このルールをスキルに追加して」と述べた場合

書き戻す前にユーザーに変更点を見せます：原文 → 新文、どのセクションに追加するか。ユーザーが同意した場合のみ変更します。変更後、文末の「更新履歴」に行を追加し、LEARNINGS.md の該当ルールを「統合済み」エリアに移動します。ユーザーの同意なしに「鉄則」は削除・変更しません。

定期的な整理： LEARNINGS.md が約40エントリを超えた場合、類似したものを統合し、時代遅れのものを削除します。整理結果はまずユーザーに見せます。

ツールがファイルを書き込めない場合： 納品の最後に「今回の経験」コードブロックを出力し、ユーザーに LEARNINGS.md に貼り付けてもらうよう依頼します。SKILL.md を変更する必要がある場合は、変更後の完全な段落を出力し、ユーザーに置き換えてもらいます。使用中のツールに専用の「スキル更新」機能がある場合は、それを使用して送信し、ユーザーに確認してもらいます。

付録

• references/prd-template.md —— 付録A：prd.md テンプレート
• references/design-template.md —— 付録B：design.md テンプレート

更新履歴

• v1.0（2026-11-01）：初版。「InHome」iOSデモの制作プロセスから抽出。
• v1.1（2026-11-01）：経験ライブラリ LEARNINGS.md とフェーズ8「経験蓄積」を追加。
• v1.2（2026-11-10）：インストール可能/ダウンロード可能なスキルパッケージとして整理：frontmatterを補完、references/ に2つのテンプレートを分割、LEARNINGS.md テンプレートとインストール手順を追加。本文ルールの変更なし。
• v1.2.1（2026-11-10）：GitHub（ELLIEZHANG893/prd-to-demo）に公開。MITライセンスとコントリビューション手順を追加。スキルルールの変更なし。