brand-to-design-md

ブランドから DESIGN.md を作成

概要

このスキルを使用すると、公開されているブランド情報を、コーディングエージェントが一貫性のある UI を生成するために使える、トークン対応の DESIGN.md にまとめられます。必要に応じて、デモ HTML ページも作成し、ブラウザーで検証します。

例のディレクトリやサードパーティのショーケースページではなく、Google Labs の DESIGN.md 標準を出発点にします。成果物は実用的で、情報源に基づき、エージェントが実行可能なものにします。

ワークフロー

1. 対象範囲と標準を確認する

必要な場合に限り、次の点を確認します。

• 対象ブランドの URL またはブランド名。
• 必要な成果物：DESIGN.md のみ、または DESIGN.md とデモ HTML およびスクリーンショット。
• 対象コンテキスト：ウェブサイト、アプリ UI、開発者向けドキュメント、製品ページ、エディトリアル素材、または汎用システム。

構造の参照として Google Labs の DESIGN.md 形式を使用します。メタデータ、デザイントークン、コンポーネントのガイダンス、画像のルール、ロゴの使用範囲、Do/Don't のガイダンスを含めます。

2. 情報を収集する

一次情報と信頼性の高い情報を優先します。

• 公式ホームページと製品ページ。
• 公式のブランド、プレス、ニュースルーム、メディアキット、または商標に関する法的ページ。
• 公開 CSS、フォントの宣言、SVG ロゴ、ファビコン、画像、スクリーンショット。
• アイデンティティシステムについて説明しているデザインエージェンシーの事例紹介。
• サードパーティのブランドデータベースは補助情報としてのみ使用します。

情報は次の4つのグループに分けて記録します。

• 直接的な証拠： 確認した CSS、SVG の塗りつぶし、画像の色、フォント名、レイアウトの挙動。
• 公式の説明文： ブランドの使用ルール、タイポグラフィの説明、プレスキットの注記。
• デザインの根拠： モチーフ、コンセプト、色の名称、書体システムの説明。
• 推論： 情報源に明記されていない、実用的なエージェント向けの判断。

CAPTCHA、ログイン、またはセキュリティ上のチャレンジによってアクセスがブロックされた場合、回避してはいけません。アクセス可能な公式ページ、キャッシュや検索結果のスニペット、プレスキット、公開されているダウンロード可能な素材を使用するか、制限事項を明記します。

3. トークンを抽出する

値だけでなく、用途に基づいて情報をトークンに変換します。

主要なトークングループ：

• colors：プライマリ、セカンダリ、ターシャリ、ニュートラル、サーフェス、プライマリ上の色、テキスト、ボーダー、ステータス／アクセントカラー。
• typography：ディスプレイ、h1、h2、本文、ラベル、モノスペース／コード（該当する場合）。
• rounded：小、中、大、ブランド特有の形状。
• spacing：基本スケール、一般的なセクション間隔。
• components：ボタン、カード、入力欄、リンク、コードパネル、通知、ナビゲーション。
• imagery：写真のスタイル、イラストのスタイル、テクスチャ、グラデーション、モーション、アイコンのルール。

主要なトークンごとに、次のような用途の説明を優先します。

• 情報の出典。
• 使用すべき箇所。
• 使用すべきでない箇所。

4. DESIGN.md を作成する

簡潔で実用的なファイルを作成します。

---
version: alpha
name: Brand Name
description: One sentence identity summary.
sources:
  - https://...
notes:
  - Evidence and limitation notes.
colors:
  primary: "#..."
typography:
  display:
    fontFamily: ...
components:
  button-primary:
    backgroundColor: "{colors.primary}"
---

## Overview
...

## Colors
...

## Typography
...

## Layout
...

## Components
...

## Imagery
...

## Logo And Usage
...

## Do's and Don'ts
...

具体的に記述します。証拠に裏付けられ、それを具体的なデザイン上の指示に落とし込める場合を除き、「モダン」「クリーン」「革新的」といった一般的な主張は避けます。

5. 必要に応じてデモを生成する

デモを求められた場合は、ワークスペースに単一ファイルの HTML 成果物を作成します。

デモでは、DESIGN.md が実用に耐えることを示します。

• 最初の画面には説明ページではなく、ブランドを反映した実際の製品またはサイトの画面を表示します。
• パレット、タイポグラフィ、ボタン、カード、フォーム、データ／コードパネル、ブランド固有のモチーフを1つ含めます。
• 使用が許可され、役立つ場合は、抽出した公開素材を使用します。
• 色だけでなく、ブランドの挙動や階層構造も再現します。
• モバイルでも読みやすく、レスポンシブにします。

ブラウザーベースの成果物では、実際のブラウザーまたはプレビュー環境を使って検証します。

• 利用可能なブラウザーまたはプレビュー環境でファイルを開きます。
• コンソールエラーを確認します。
• 横方向のオーバーフローを確認します。
• デスクトップとモバイルのスクリーンショットを撮影します。
• 重要な画像とフォントが適切にフォールバックすることを確認します。

6. 成果物を報告する

次の項目を返します。

• DESIGN.md のパス。
• 作成した場合はデモ HTML のパス。
• 作成した場合はスクリーンショットのパス。
• 情報源の概要。
• 検証結果。
• 制限事項または推論に基づく選択。

品質基準

優れた出力であれば、将来のコーディングエージェントが追加のコンテキストなしで、ブランドらしさがひと目で伝わるページを作成できます。

次の点を確認してください。

• トークンが意味のある役割に対応していること。
• 色以外にも、ブランド独自のビジュアル表現があること。
• ロゴと商標の使用範囲が守られていること。
• デモページで、複数のUIコンテキストにシステムが使われていること。
• 出力で、根拠と推論が区別されていること。

さらに読むには

簡潔なチェックリストと出力テンプレートについては、references/workflow-checklist.md をお読みください。