space-image2proto

画像からプロトタイプを作成するスキル

UI のスクリーンショットから、忠実で本番品質の単一ファイル HTML プロトタイプを作成し、ユーザーのフィードバックに基づいて反復的に改善します。すべてのやり取りを記録するため、時間とともにこのユーザーのスタイルをより深く理解できるようになります。

初回起動：オンボーディング

このスキルを初めて使うとき（つまり、references/learning_log.jsonl が空であるか存在せず、かつ references/design_system.json にユーザーがカスタマイズした内容がない場合）は、プロトタイプを作成する前に次のオンボーディングを行います。

1. 参考画像を収集する

既存の製品やデザインシステムから、できるだけ多くの参考スクリーンショットを提供するようユーザーに依頼します。目的は、プロトタイプの作成を始める前に、信頼性の高いデザインルール一式を抽出することです。次のように尋ねます。

「プロトタイプの出力を製品のスタイルにより近づけるため、まず既存のシステムのスクリーンショットを数枚ご提供ください（一覧ページ、モーダル、フォームなど）。そこから配色、余白、コンポーネントのスタイルなどのデザインルールを抽出し、以降のプロトタイプにすべて自動で適用します。」

提供されたスクリーンショットから、次の情報を抽出し、references/design_system.json に書き込みます。

• カラーパレット（プライマリ、成功、危険、警告、テキストの色、境界線の色、背景）
• コンポーネントの寸法（モーダルの角丸、フォームラベルの幅、ボタンの高さ、入力欄の高さ）
• アイコンのスタイル（SVG のストロークベースか、塗りつぶしか、絵文字か）
• フォントファミリー
• 繰り返し使用されるコンポーネントのパターン（タグ、カード、ステップウィザードなど）

2. 要件ドキュメントの形式を確認する

要件をどのように記述するのがよいか、ユーザーに尋ねます。次のデフォルト形式を提案します。

「毎回の要件はどのように記述しますか？デフォルトは次のような簡単な説明です。 • スクリーンショット＋変更内容を一文で説明 • または、スクリーンショット＋フィールドの一覧（例：『タイトルをXXに変更し、一覧のフィールドをA、B、Cに変更』） 独自の要件ドキュメントのテンプレートがあれば、それを送っていただいてもかまいません。」

選択された形式を references/config.json の requirements_format に保存します。

3. ファイルの保存場所を設定する

プロトタイプを保存するルートディレクトリをユーザーに選んでもらいます。

「プロトタイプファイルはどのディレクトリに保存しますか？ルートディレクトリを選択してください。以降、すべてのファイルは ルートディレクトリ/MMDD-デザイン名.html のルールに従って保存されます。」

パスを references/config.json の output_root に保存します。ユーザーが指定しない場合は、現在のワークスペースフォルダーをデフォルトとして使用します。

4. 初期設定を書き込む

オンボーディングの後、references/config.json を作成します。

{
  "output_root": "/path/to/user/chosen/directory",
  "file_naming": "MMDD-设计名称.html",
  "requirements_format": "screenshot + brief Chinese description",
  "onboarding_completed": true
}

オンボーディングが完了したら、以降のセッションでは通常のワークフローに直接進みます。

---

基本ワークフロー

ステップ 1：コンテキストを読み込む

作業を始める前に、次のファイルが存在する場合は読み込みます。

1. references/config.json — 出力ディレクトリ、命名規則、形式の設定
2. references/design_system.json — ユーザーのデザインシステム（色、コンポーネント、余白）
3. references/learning_log.jsonl — 蓄積されたやり取りの履歴の直近 20 件

config.json が存在しない場合、または onboarding_completed が true でない場合は、まず上記のオンボーディングを行います。

ステップ 2：スクリーンショットを分析する

ユーザーからスクリーンショットが提供されたら、注意深く調べ、次の情報を抽出します。

• レイアウト構成：ページはどのように構成されていますか？（モーダル、一覧ページ、フォーム、ダッシュボードなど）
• コンポーネント一覧：どのような UI 要素がありますか？（テーブル、フォーム、タブ、ボタン、ドロップダウン、タグ、ステップウィザード、トグルなど）
• カラーパレット：プライマリアクション、成功状態、警告、境界線、背景にはどのような色が使われていますか？
• タイポグラフィ：見出し、ラベル、値のフォントサイズ、ウェイト、色
• 余白のパターン：パディング、マージン、要素間の間隔
• アイコンのスタイル：アイコンは SVG のストロークベース、塗りつぶし、絵文字、テキストのどれですか？
• インタラクティブ要素：ホバー状態、クリック時の動作、ステップ間の遷移がある要素はどれですか？

ざっと見るだけではなく、しっかり確認します。ユーザーが重視するのは視覚的な忠実度です。スクリーンショットに「なんとなく似ている」程度のプロトタイプでは不十分です。色、余白、コンポーネントのスタイルを正確に合わせます。

ステップ 3: プロトタイプを生成する

出力形式: 常に単一の HTML ファイルとし、すべての CSS を <style> ブロックに、すべての JS を <script> ブロックに記述します。外部フレームワークや CDN 依存は使用しません（フローチャート用の Mermaid を除く）。

ファイル命名: config.json のルールに従います。デフォルトは MMDD-设计名称.html です。例えば、0327-模型类型配置.html のようになります。output_root ディレクトリに保存します。

設計原則:

1. 忠実性を最優先。 スクリーンショットにできるだけ忠実に合わせます。スクリーンショットでボタンに特定の青の濃淡が使われているなら、「だいたい近い色」ではなく、その正確な濃淡を使用します。

2. クリーンでセマンティックな HTML。 コンポーネントを表す意味のあるクラス名（.modal-header、.f-row、.type-tag）を使用し、汎用的な名前（.box1、.div-wrapper）は避けます。

3. CSS の整理。 コンポーネントごとにコメントを付けてスタイルをグループ化します。まずレイアウト／構造、次にコンポーネントのスタイル、最後に状態のスタイルを配置します。

4. 機能的なインタラクティブ性。 スクリーンショットがインタラクティブな動作（タブの切り替え、ドロップダウンの開閉、ステップウィザードのナビゲーション、トグルスイッチ）を示唆している場合は、バニラ JS で実装します。プロトタイプは静的ではなく、生き生きと感じられるものであるべきです。

5. 透かしなし、絵文字なし。 デフォルトではクリーンなインライン SVG アイコン（塗りつぶしではなくストロークベース）を使用します。ユーザーが明示的に絵文字を求めた場合にのみ絵文字を使用します。

6. レスポンシブなモーダル。 妥当な max-width を設定し、スクロール可能なコンテンツ領域には overflow-y: auto を併用した max-height を使用します。

ステップ 4: 修正リクエストを処理する

ユーザーはプロトタイプを修正するために、しばしばフォローアップのリクエストを送信します。これらのリクエストは簡潔で文脈に依存する傾向があります:

• 「这个也一样」 / 「这个弹窗也是一样」 — 以前のプロトタイプと同じパターン／変更をこの新しいスクリーンショットに適用します。会話の文脈から「一样」が何を指すのかを理解します。

• 「加一个XX字段」 / 「顶部显示XX」 — 特定のフィールドや要素を追加します。スクリーンショットと既存のレイアウトパターンに基づいて論理的に配置します。

• 「筛选框增加一个 XX」 — 検索バー領域にフィルター／検索条件を追加します。

• 「弹窗宽一些」 — 寸法を調整します。数値を変えるだけでなく、広くなったスペースをどう活用すべきかを考慮します。

• 「去掉水印」 / 「不要 emoji」 — 特定の視覚要素を削除します。今後のプロトタイプのためにこの好みを覚えておきます。

• 「输出设计说明」 — ユーザーは、行った設計変更の簡単な要約をリスト形式で求めています。

既存のファイルを修正する場合は、ファイル全体を書き直すのではなく、Edit ツールを使って対象を絞った変更を行います。ファイル構造が根本的に変わるほど大規模な修正の場合は、Write を使ってファイルを置き換えます。

ステップ 5: 学習ログを更新する

各プロトタイプまたは修正を完了した後、references/learning_log.jsonl にログエントリを追記します。各エントリは 1 行の JSON です:

{"timestamp": "2026-03-27T14:30:00Z", "action": "create|modify", "file": "0327-模型类型配置.html", "screenshot_description": "Brief description of the UI shown in the screenshot", "changes": "What you created or modified", "user_instruction_style": "How the user communicated (terse, detailed, Chinese, English)", "design_patterns_used": ["pattern-a", "pattern-b"], "color_palette": {"primary": "#409eff"}, "user_preferences_learned": ["preference discovered in this interaction"], "component_library": ["reusable component identified"]}

記録すべき内容:

• timestamp: このやり取りが行われた日時
• action: 新しいプロトタイプには "create"、既存のものへの変更には "modify"
• file: 出力ファイル名
• screenshot_description: スクリーンショットが示していた内容の簡単な説明
• changes: 行ったこと
• user_instruction_style: ユーザーがどのように伝えたか
• design_patterns_used: 適用した再利用可能なパターン
• color_palette: 抽出または使用した色
• user_preferences_learned: このやり取りで発見した新しい好み
• component_library: 特定した新しい再利用可能なコンポーネント

このログは追記専用です — 決して上書きしないでください。時間の経過とともに、ユーザーのデザインシステムとコミュニケーションスタイルの豊富な記録となり、その後のすべてのプロトタイプをより正確にします。

---

デザインシステムリファレンス

プロトタイプを構築する際、ユーザーのデザインシステムの生きたリファレンスを references/design_system.json に維持します。新しいパターンを発見するたびに更新します。構造:

{
  "colors": {
    "primary": "#409eff",
    "success": "#67c23a",
    "danger": "#f56c6c",
    "warning": "#e6a23c",
    "text_primary": "#303133",
    "text_regular": "#606266",
    "text_placeholder": "#c0c4cc",
    "border": "#dcdfe6",
    "background": "#f0f2f5"
  },
  "components": {
    "modal": {"border_radius": "8px", "header_font_size": "16px"},
    "form_label_width": "110px",
    "button_height": "36px",
    "input_height": "36px"
  },
  "icon_style": "inline SVG, stroke-based, stroke-width 2, no fill",
  "font_family": "-apple-system, BlinkMacSystemFont, 'Segoe UI', 'PingFang SC', 'Microsoft YaHei', sans-serif"
}

各セッションの開始時にこのファイルを読み込みます。存在しない場合は、最初に構築するプロトタイプから作成します。

---

共通コンポーネントパターン

これらはプロトタイプ間でよく繰り返されるパターンです。スクリーンショットでこれらを見かけたら、自信を持って再現できます:

ステータス／カテゴリタグ

<span class="type-tag type-a">类型A</span>
<span class="type-tag type-b">类型B</span>

カテゴリごとに異なる色を使用します。デザインシステムのカテゴリ → 色の対応表を参照してください。テーブルの列、フォームヘッダー、詳細ビューで使用します。

2 列フォームレイアウト

左側にラベル（右揃え、幅固定）、右側にコントロール（flex: 1）を配置します。モーダルやステップウィザードのフォームでよく使用されます。

ステップウィザード

完了／アクティブ／保留中の状態を表示する横方向のステップバーです。完了には緑のチェックマーク、アクティブには濃色のアイコン、保留中にはグレーを使用します。ステップパネルは JS で切り替えます。

検索／フィルターバー

フォームコントロール（セレクト、入力欄）を横一列に並べ、検索ボタンを配置します。新しいフィルターは通常、最も左に追加します。

2 列の連動セレクター

左パネルにカテゴリ、右パネルにチェックボックス付きの項目を表示します。選択した項目は、トリガーの下にタグとして表示します。選択内容が親カテゴリに依存する場合に使用します。

CRUD 対応タグ

追加／編集／削除が可能なタグです。各タグにはテキスト、編集アイコン（鉛筆の SVG）、削除ボタン（×）を表示します。タグは種類ごとに、アイコンと色で視覚的に区別できます。編集するとオーバーレイダイアログが開きます。

---

フローチャート／Mermaid 図

ユーザーがプロセスの流れ（→矢印や手順ごとの説明）を示し、フローチャートを依頼した場合は、CDN から Mermaid.js を読み込んで図を描画する HTML ファイルを生成します。

デフォルトスタイル：Notion 風の白黒

ユーザーが特定の配色を指定しない限り、Notion をイメージしたすっきりとしたモノクロスタイルを使用します。

• 背景：純白 #fff
• メインノード：白の塗りつぶし、#37352f の濃色の枠線（2px）、#37352f のテキスト、角丸 rx:4
• サブノード／詳細ノード：薄いグレーの塗りつぶし #f7f6f3、グレーの枠線 #e3e2de（1px）
• 終端／最終ノード：反転表示 — 濃色の塗りつぶし #37352f、白いテキスト
• 線：薄いグレー #d3d1cb、1.5px
• フォント：システムフォントスタック、14px
• ページタイトル：大きく（28px）、太字にし、フローの概要を示すグレーのサブタイトルを付けます

Notion スタイル用 Mermaid themeVariables：

{
  theme: 'base',
  themeVariables: {
    fontFamily: '-apple-system, BlinkMacSystemFont, "PingFang SC", "Microsoft YaHei", sans-serif',
    fontSize: '14px',
    lineColor: '#d3d1cb',
    primaryColor: '#fff',
    primaryTextColor: '#37352f',
    primaryBorderColor: '#37352f',
    secondaryColor: '#f7f6f3',
    tertiaryColor: '#f7f6f3'
  }
}

番号付きステップ：Unicode の丸囲み数字（①②③...）を HTML エンティティ ① から ⑮ で表し、メインフローノードの先頭に付けます。サブノードには番号は不要です。

ユーザーが色を指定した場合：design_system.json のカラーパレットを使い、ステージ／役割ごとに色分けします（例：内部運用には青、ユーザー向けには緑、データ／ログには赤、分類にはオレンジ）。

HTML テンプレートの構造

<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<title>流程标题</title>
<style>
  /* Notion-style page: white bg, system font, centered */
</style>
</head>
<body>
  <h1>流程标题</h1>
  <div class="subtitle">一句话摘要</div>
  <div class="chart-container">
    <div class="mermaid">
      flowchart TD
        ...
    </div>
  </div>
  <script src="https://cdnjs.cloudflare.com/ajax/libs/mermaid/10.9.0/mermaid.min.js"></script>
  <script>mermaid.initialize({...});</script>
</body>
</html>

良いフローチャートを作成するためのヒント

• 順次処理には flowchart TD（上から下）、並列／スイムレーン型のフローには flowchart LR（左から右）を使用します
• メインステップは四角形ノード ["text"]、分岐は角丸ノード ("text") または円形ノード (("text")) にします
• ノードのラベルは簡潔にします（可能であれば 15 文字未満）
• 関連する詳細は、親ステップから分岐する子ノードとしてまとめます
• すべての矢印をまとめてスタイル設定するには linkStyle default を使用します

---

品質チェックリスト

プロトタイプを納品する前に、次の項目を確認します。

• 色がスクリーンショットと一致している（「近い色」ではなく、正確な hex 値を使用）
• レイアウトの比率が適切である（列幅、モーダルの寸法、間隔）
• すべてのインタラクティブ要素が動作する（タブの切り替え、ドロップダウンの表示、ステップの移動）
• SVG アイコンが整っていて一貫している（線の太さとスタイルが統一されている）
• 絵文字が使われていない（ユーザーが明示的に希望した場合を除く）
• ファイルが自己完結している（フローチャートの Mermaid CDN を除き、外部依存がない）
• ファイルが正しいディレクトリに適切な名前で保存されている（MMDD-设计名称.html）
• 学習ログが更新されている

「输出设计说明」への対応

ユーザーがデザインメモを求めた場合は、作成または変更した内容を簡潔なリストにまとめます。次の形式を使用します。

ページ名 デザインメモ

• 変更 1：簡潔な説明
• 変更 2：簡潔な説明
• ...

事実に基づいて簡潔に記述します。ユーザーが求めているのはチームと共有できる記録であり、詳細な論文ではありません。