AgentSkillsCN

ui-mockup-builder

该技能专为 Web/应用的“屏幕原型图（UI Mockup / 高保真原型图）”而设计。当用户提出“制作原型图”“进行 UI 设计”“希望将界面效果打磨至极致”“交付开发团队的屏幕设计”“在导入 Figma 之前先敲定基础框架”“希望在每个屏幕状态下（空状态、错误状态、加载状态等）都精心设计”等需求时，此技能便会自动启动。首先，需根据具体目标判断是需要线框图、原型图，还是高保真原型图；若选择制作原型图，则应在静态高保真设计中，细致规划每个屏幕的色彩、字体、留白、组件布局及状态表现，并在仓库内生成包含开发交付所需注释与详细规格的“Mockup Pack”。

SKILL.md
--- frontmatter
name: ui-mockup-builder
description: >
  Web/アプリの「画面モックアップ(UI Mockup / high-fidelity mockup)」を作成するためのSkill。
  依頼に「モックアップ」「UIデザイン」「見た目を最終に寄せたい」「開発に渡せる画面デザイン」「Figmaに起こす前の叩き」「画面ごとの状態(空/エラー/ローディング等)込みで作りたい」
  などが含まれるときに発動する。
  目的に応じて wireframe / mockup / prototype のどれが必要かをまず判定し、モックアップが適切なら
  画面ごとの静的な高フィデリティ設計(色/タイポ/余白/コンポーネント/状態)と、開発引き渡し用の注釈・仕様をまとめた「Mockup Pack」をリポジトリ内に生成する。

UI Mockup Builder

画面モックアップは、最終プロダクトに近い「見た目」を具体化する静的な設計図(高フィデリティ)です。

Purpose

  • •合意形成を早く・安く、実装前に見た目の地雷を潰す
  • •開発引き渡しを滑らかにする
  • •静的画だけで誤解される「状態」を先に明確にする

Output (default)

リポジトリに「Mockup Pack(モックアップ一式)」を作成します。Figma自体の操作はせず、Figmaに起こせる粒度の仕様と、必要ならHTML/Tailwindで再現できる静的モックを生成します。

推奨の出力先:

  • •docs/mockups/<feature-or-epic>/
    • •README.md(目的・前提・対象画面・参照・決定事項)
    • •style-guide.md(色/タイポ/余白/角丸/影/アイコン方針)
    • •tokens.json(色・スペーシング・タイポなどのトークン)
    • •screens/
      • •<screen-id>__spec.md(画面仕様)
    • •components/
      • •<component-id>__spec.md(コンポーネント仕様)
    • •copy/
      • •strings.md(文言案、i18n注意、可変長対策)
    • •state-matrix.md(主要状態一覧)
    • •html/(任意:静的HTMLモック)
    • •exports/(任意:スクリーンショット、PNG出力物など)

Operating Principles

  1. •最初にWireframe/Mockup/Prototypeを判定:早期にフィデリティを間違えない
  2. •既存資産を最優先:デザインシステム/トークン/コンポーネントがあれば必ず寄せる
  3. •状態を先に潰す:通常/空/ローディング/エラー/成功を最低限揃える
  4. •作り込みすぎない:目的に対して過剰なフィデリティは避ける
  5. •実データで検証:ダミーテキストでなく、実データ寄りで桁・改行・i18nを確認

Workflow

Step 0: Activation check(最初に必ずやる判定)

  1. •依頼が「ワイヤー」「モック」「プロトタイプ」のどれかを判定する
    • •Wireframe:構造・情報設計・導線のラフ(未完成に見せて議論をロジックに寄せる)
    • •Mockup:見た目を最終に寄せた静的画(色/タイポ/余白/コンポーネント/状態)
    • •Prototype:遷移や操作感の検証(インタラクティブ)
  2. •モックアップが適切なら、このSkillを続行
  3. •ワイヤーが先なら「まずワイヤー→確定後にモックアップ」の順に提案し、同じフォルダに段階成果物として残す

Step 1: Repo scan(既存資産の確認)

  • •既存のデザインシステム/UIライブラリ/トークンがあれば最優先で寄せる
    • •例:design/, docs/design-system/, tokens/, tailwind.config.*, shadcn/ui, MUI, Chakra, Ant 等
  • •既存の画面遷移図/PRD/要件/ユーザーフローがあれば読み、画面一覧を確定する

Step 2: Minimal questions(不足があるときの最小ヒアリング)

  • •resources/intake_questions.md を参照し、足りない情報だけを質問する
  • •ユーザーに確認するのは「作るために絶対必要」なものだけ
  • •なければ仮定して進め、仮定はREADMEに明記

Step 3: Foundation(見た目の土台を決める)

  • •resources/style_guide_template.md と tokens.json を作る(既存があれば拡張・補完のみ)
  • •タイポ/カラー/レイアウト/コンポーネント方針を決定

Step 4: Screen-by-screen mockup spec(画面ごとに静的モック仕様を作る)

  • •各画面 screens/<screen>__spec.md を作成
  • •resources/screen_spec_template.md をベースに仕様を埋める
  • •画面の目的/レイアウト/コンポーネント/表示データ/状態/注釈を必ず含める

Step 5: Components(ズレを防ぐためにコンポーネントを先に固める)

  • •新規コンポーネントが必要なら components/<component>__spec.md を作る
  • •resources/component_spec_template.md をベースに作成
  • •variants / states / props を明確にし、画面間で使い回せる前提にする

Step 6: State matrix(例外や落とし穴を先に潰す)

  • •state-matrix.md に「画面×状態」を表でまとめる
  • •最低限:空(0件)/ローディング/エラー/成功/無効

Step 7: Optional HTML mock(必要な場合だけ)

  • •開発側との合意形成やレビュー効率のために、静的HTMLで見た目を再現する(任意)
  • •ルール:動的ロジックは作らない(見た目と状態だけ)
  • •Tailwind等があるならそれに寄せる

Step 8: Handoff pack(開発引き渡しの不足情報を埋める)

  • •README.md に以下をまとめる
    • •対象画面一覧、到達条件(権限/ルート)
    • •画面ごとの仕様ファイルへのリンク
    • •未確定事項(要確認)と暫定仮定
    • •重要なデザイン判断

Step 9: Quality check(品質チェック)

  • •resources/quality_checklist.md で自己レビューし、問題があれば修正
  • •特に以下を重点確認:
    • •目的に対してフィデリティが適切
    • •静的画で誤解される「状態」が揃っている
    • •実データ寄りの内容で崩れ検証している
    • •レスポンシブとアクセシビリティを意識している
    • •コンポーネント/トークンに寄せて、画面ごとのズレが生まれない

Formatting Rules

  • •Markdownを基本にし、読みやすさ優先
  • •テーブル、箇条書き、画像リンクを活用
  • •重要な判断は太字、参照はリンク
  • •コード例はシンタックスハイライト付き

Examples (triggers)

  • •「この機能の画面モックアップ作って。開発に渡せる状態(空・エラー・ローディング込み)で」
  • •「Figmaに起こす前に、画面の見た目を最終に寄せたモック仕様をMarkdownで作りたい」
  • •「この画面群、ブランドカラーとタイポまで決めた高フィデリティの静的デザインが欲しい」
  • •「UI mockupを作って」
  • •「画面デザインの状態パターンも含めて設計書を作って」

References