pm-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'
  }
}

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

ユーザーが色を指定した場合：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：简要描述
• ...

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

---

上下游衔接

本 Skill 是 pm-skills 工作流的一环，由 pm-master 总控统一路由。

• 上游：pm-prd-writer（PRD 的界面交互描述）、pm-image2pencil（要设计稿而非可运行原型时用它）
• 下游：pm-review-board（原型可作为评审材料）

交接规则：链路模式下，完成后输出一段「交接摘要」（≤10 行：本步结论 + 下一步所需输入），供下一个 Skill 直接使用。