design-lounge

デザインラウンジ

ライブラリはすでにこのスキルフォルダーにあります。読んでください。製品やツールについては、カラーパレット、書体の組み合わせ、角丸、イージング、コンポーネントの表現を勝手に作り出さず、ウェブサイトを待つこともありません。

ライブラリは土台であり、語彙です。上限ではありません。相手が華やかさを求めるなら、その題材のために作られたものをひとつ軸にしてページを構築し、その世界観に合った色と書体を選び、ライブラリは技術を支えます。これが show.md にある Show モード、Free です。パレットを勝手に作らないという上記のルールは、製品やツールに適用されます。

新しい制作はすべて、ブリーフから始めます。相手の言葉を、優れたデザイナーが求めるプロンプトに書き直します。詳しくは、以下の「まずブリーフを書く」をご覧ください。

Design Lounge は、Susan Acharya のデザインライブラリです。https://www.designlounge.live で閲覧できます。

相手の言葉を優先する

このスキルは、デフォルト設定の集まりです。たとえば動きを増やす、エフェクトを追加する、ペアのないダークモードにする、手順を省略するなど、デフォルト設定で禁止されていることを相手が求めた場合は、その要望に従ってください。どのデフォルト設定を、なぜ適用しなかったかを DESIGN.md に一行で記載します。反論したり、黙って無視したりしないでください。

まずブリーフを書く

新しいウェブサイトやアプリを制作するときは、レシピを読む前に、brief.md を使って相手の依頼をブリーフにまとめます。相手の言葉を引用し、製品とその事実、対象ユーザー、世界観、中心となる要素、目標、モード、技術スタック、不足している情報、厳守すべき制約、完成の定義を記載します。DESIGN.md の先頭に置き、ブリーフに沿って制作します。サブエージェントに作業を依頼する場合は、ブリーフ全体を共有してください。「質問すべきタイミング」で許可されている質問があれば、ブリーフを作成する前に尋ね、その回答をブリーフに記録します。

「スクロールが楽しい宇宙のウェブサイトを作って」という短い依頼と、よく練られたブリーフでは、できあがるサイトは大きく異なります。ブリーフに事実を加えることはありません。相手の言葉からすでに読み取れることを明確にし、目指す水準を定めます。

ライブラリを読む

必要な情報はすべてこのファイルの近くにあります。作業に必要なものだけを読みます。

1. library/map.json — 最初に読みます。種類、ファミリー、レシピ一覧、ムード別のすべてのテーマと組み合わせ、モーショントークンが記載されています。約 39 KB です。各レシピの手順は、それぞれ専用のファイルにあります（手順 2）。
2. 次に、使用するものだけを開きます。レシピとその手順は library/starts/<id>.json、テーマは library/themes/<id>.css、組み合わせは library/pairings/<id>.css です。
3. library/pieces.txt — ピースごとに 1 行で記載されています。検索してください（カテゴリ、プラットフォーム、タグで grep します）。最初から最後まで読まないでください。
4. library/briefs/<id>.md — 1 つのピースの仕様です。構築するピースだけを開いてください。
5. library/icons.json — Lounge Icons。画面にアイコンが必要な場合に限ります。library/wada.txt — Sanzo Wada の 348 色の組み合わせ。Free colour、ブランドボード、またはユーザーが独自に指定した色を使う場合に限ります。検索してください。
6. components.md — コントロール、アイコン（見つからない場合の対応を含む）、ロゴとファビコン、および用途ごとに使用するピースが記載されています。
7. practice.md — すべての構築に共通する方法です。最初の行に、作業で追加する他のファイルが記載されています。website.md、app.md、[native.md)、locale.md のいずれかを読みます。そのファイルだけを読んでください。
8. brief.md — ユーザーの依頼を構築ブリーフにまとめる方法です。新しいウェブサイトやアプリを作るたびに読みます。
9. show.md — Show モードの内容です。中心となる要素、Free colour とタイポグラフィ、レンダリングの基準が記載されています。ブリーフに Mode: Show とある場合に限ります。
10. flows.md — アプリの最短ルート、Adopt フロー、Brand フローが記載されています。「依頼内容」に従って参照する場合に限ります。
11. taste.md — taste-skill パックに含まれる内容です。名前付きのルック（ミニマル、ブルータリスト、ハイエンド）、ページ形状、仕上げの詳細、画像を主役にしたモックアップ、ブランドボードが記載されています。これらのスキルを別途インストールする必要はありません。
12. styles.md — スタイルのルーティング表です。名前付きスタイル、その同義語、参照先がすべて記載されています。スタイルが指定されている場合に限ります。

このスキルからスクリプトを実行しないでください。library/map.json がない場合、インストールが壊れています。その旨を伝えてください。記憶を頼りにデザインしないでください。

開いているプロジェクトが Design Lounge リポジトリそのもの（src/demos と src/content/pieces が存在する）で、ユーザーがライブラリを編集している場合は、その編集でこのスキルを使うのをやめてください。代わりに docs/PIECE-SPEC.md に従ってください。

求めていること

求めていること	対応
行は上から順に確認してください。一致する最初の行を使います。
プロジェクトにデザインシステム、DESIGN.md、トークン、またはスタイル設定済みの画面がすでにある	Adopt フロー
既存サイトのリデザイン	Adopt フローの後、practice.md の Redesign（監査）
「Stripe っぽく」（または Linear、Apple、Notion など、名前の挙がったブランドのように）	Brand フロー
名前で指定されたスタイル（styles.md のいずれかの行。-ism 形やスペルミスも含む）	styles.md を読み、該当する行の Named aesthetic を設定してから、フローを決めるために以下の行を読み進めます。一致する次の行によって決まります（新規プロダクトなら Kit フロー、アプリなら app short path、見せ場重視なら Show mode）
新しいプロダクト、サイト、アプリ、またはデザインシステム	Kit フロー
brief.md の「リクエストを読み解く」で見せ場重視と判断されるもの（brief に Mode: Show とある場合）	Kit フローの後、show.md の Show mode。テーマ、色、ブランドが指定されていない限り、色と書体は自由に選べます。それ以外は、見せ場やローンチ、描ける世界の表現であっても Kit mode です
1つのプロダクトに2種類のルックを用意する、または「選択肢を見せて」と具体化する	テーマ、書体の組み合わせ、ヒーローが異なる2つの方向性で、Kit フローを2回実行します。題材に世界観がある場合は、一方を Show mode の Free にし、もう一方はライブラリに固定します
ゲームサイト、Web ゲーム、ロビー、スコアボード	Kit フロー、レシピ game、続いて taste.md の Games と Three.js
Three.js、3D シーン、またはオービットが指定され、見せ場、ローンチ、会場が目的ではない	Kit フロー、レシピ game、方向性は Orbit。Lounge のデモは生の WebGL です。brief に基づいて Three.js でプロダクトを構築します。
手書き、または手描き文字風のサイト	Kit フロー、レシピ notebook
ブランドキット、アイデンティティ、ロゴシステム、またはブランドボード	Kit フローの後、taste.md の Brand board
ブラウザーでログインして使うプロダクト	Kit フローの後、app short path、レシピ web-app。公開ホームページは saas として別途作成します
スタッフ向け管理画面、運用画面、ダッシュボード	Kit フローの後、app short path、レシピ dashboard
世界観が指定されていないスマートフォンアプリ	Kit フローの後、app short path、レシピ mobile-app
PWA	目的に合ったレシピ（ショップ、ニュースアプリ、Web アプリなど）の後、native.md の PWAs。自動的に mobile-app にはしません
React Native、Expo、Flutter、SwiftUI、または Compose	Kit フローの後、app short path と native.md
デスクトップアプリ、Electron、Tauri、Mac のウィンドウ	app short path。スタッフ向け運用画面の場合は web-app または dashboard。スマートフォン用のタブバーは使いません
「まず見せて」、コンセプト、またはモックアップ画像の依頼で、画像を作成できる場合	Kit フローの後、コードを書く前に taste.md の Image first
1つの画面、セクション、またはコンポーネント	既存の固定済みキット内で Piece フロー
パレット、フォント、アイコン、またはモーションのみ	Library フロー
種類の指定がない「いい感じにして」	Kit フロー。種類、用途、トーンを推測し、仮定した内容を伝えます。

スタックが指定されていない場合は、プロジェクトで現在使われているものを使用します。空のフォルダーでは、以下の「確認が必要な場合」に従います。brief はスタックに依存しません。翻訳するのはあなたです。

選択内容を伝えてから構築する

選択して伝え、同じターンで構築します。library/map.json の site を使い、返信の冒頭に次の内容を記載します。

• Theme：名前、雰囲気を一行で表した説明、{site}/themes/<id>。Free の場合は Free に続けて、色とその由来となる光を記載します
• Pairing：名前、{site}/type/<id>。Free の場合は Free に続けて、書体と選んだ理由を記載します
• Family：名前と、固定する角丸の半径
• Pieces：各画面またはエフェクトのタイトルと {site}/demo/<id>。そのピースのページは {site}/p/<id> です。ほかのパスを作らないでください。

同じリンクを Sources として DESIGN.md にも記載します。後続のメッセージで「テーブルを変更して」と言われたとき、どのデモを参照したか分かるようにするためです。

尋ねるタイミング

ビルド前に尋ねるかどうかについてのルールは、これだけです。それ以外のファイル、概要、テンプレートにはすべて、このルールが適用されます。ツールをインストールする前に尋ねる場合（reference.md のページを開く）は別です。

「そのまま作って」「進めて」「決めて」「尋ねないで」と言われた場合は、決して尋ねないでください。プロジェクトの技術スタックを使うか、空のフォルダーではプレーンな HTML + CSS と少量の JS を使います。practice.md の「レシピが重複する場合」に従ってレシピを決めます。リデザインではブランドを維持します。その後、ビルドします。

それ以外の場合、以下のいずれかに当てはまるときに限り、ビルド前に一度だけ、1つのメッセージで尋ねてください。その後は尋ねるのをやめます。

• フォルダーが空で、技術スタックの指定もありません。どの技術スタックを使うか尋ね、希望がなければプレーンな HTML + CSS と少量の JS を使うと伝えます。
• practice.md の「レシピが重複する場合」に従っても2つのレシピが残り、それぞれ異なるテーマ（スタッフ用ダッシュボードと個人用台帳など）に決まる場合は、どちらにするか尋ねます。
• 選択肢を見たい、または選びたいと言われた場合は、3つの配色と2つの組み合わせを、リンク、名前、雰囲気だけで示します。
• リデザインで、ブランドを維持するかどうか判断できない場合（flows.md の「採用フロー」）。
• ポートフォリオで、作品の提示がない場合（website.md の「実際のコンテンツのみ」）。

それ以外は自分で判断し、何を前提にしたかを伝えます。

その後、変更を求められた場合は、該当する Source 行だけを編集し、同じシート上でその画面を再ビルドします。2つ目の配色は開かないでください。

Webサイトの最短手順

全手順は長いため、Webサイトで重要な手順を順番に示します。該当する手順に進んだら、そのセクションを開いてください。

0. ブリーフ（brief.md）を書きます。Ambition と Mode の行によって、手順 3 で Show モードに切り替えるか、Free にするかが決まります。
1. ~/.design-lounge/history.jsonl を読みます（practice.md の「Recent picks」）。次に、題材の世界を表す言葉を 3 つ書きます。「初心者向け」や「親しみやすい」ではなく、その世界の素材、道具、場所を選びます（practice.md の「Pick a direction」、ルール 2～4）。
2. スタイルが指定されている場合は、ロックする前に styles.md の「Named aesthetic」行を書きます。レシピをロックし、その世界の雰囲気を表す名前が付いた方向性のうち、このレシピの最近の履歴にないものを選びます。名前の番号は、同点の場合にのみ使います。方向性によってヒーロー、作品、フッターが決まります。それらを使います。今すぐ履歴に claim 行を追加し、隣で作業しているエージェントが同じ方向性を選ばないようにします。
3. アイデアとシグネチャーを書きます（website.md の「Write the idea」）。避けているデフォルトの見た目を、スタジオのテンプレートも含めて明記します。スペクタクルを求められた場合は、ここで show.md の Show モードに切り替えます。アイデアが中心となり、方向性のヒーロー、作品、フッターが候補になります。Free の場合は、テーマと組み合わせも候補に加わります。Free colour and type を使って色と書体を選びます。
4. about と contact は、用意されているコンテンツに応じて選びます（website.md の「Sections, one by one」）。作品とフッターは方向性に沿ったままにします。ヒーローの形とフレームを書きます（website.md の「Hero shape and the frame」）。次に「Recent picks」で独自性を確認します。ヒーロー、作品、フッターのうち 2 つが、このレシピまたは関連グループの最近のサイトと一致する場合、あるいは形やフレームが繰り返される場合は、次の方向性を選びます。シートに Unlike 行を書きます。その後、work、footer、shape、frame を記入した履歴行を追加します。
5. ヘッダー、電話バー、メニュー、コピー ボタンなど、作成するすべてのパーツのブリーフを開きます。それぞれ「Optional below this line」まで読み、その要点を守ります（practice.md の「Adapting a brief」）。パーツを使わずにブロックを作る前に、pieces.txt と components.md のルートを検索します。
6. 相手から提供された事実だけを使って作成します。ブリーフに記載された名前、価格、引用はそのまま使用します。別の製品名に置き換えても成り立つ文は書き直します。ボタンには、この画面での操作を明記します。リンクは説明どおりの場所に移動させます。描画したデータには「Example」と表示します。不足している事実は、プレースホルダーを並べるのではなく、1 行で示します。
7. Web とスマートフォンのスクリーンショットを撮り、それぞれの効果をスクロールしながら確認します（reference.md の「Opening the page」）。見つけた問題を修正します。修正を 1 つ行います。
8. 「The reply」にある締めくくりのブロックで終えます。

ルールは最低限であり、デザインそのものではありません。すべてのルールを満たせば、ページとして正しくなります。アイデアとシグネチャーによって、その人らしさが生まれます。

アプリの最短手順

flows.md を参照してください。上の表で案内されたら開いてください。

キットフロー

0. brief.mdでブリーフを作成します。ただし、DESIGN.mdにすでにブリーフがある場合は不要です。
1. reference.mdの種類マップを使って、種類（website、product、platform、personal）を選びます。次に、library/map.jsonのstartsから該当するレシピを選び、library/starts/<id>.jsonを開いて、directionsのいずれかをロックします（practice.mdの「方向を選ぶ」を参照）。その際、最近の選択を確認してください。同じ文を使っても、2人が同じサイトになってはいけません。また、1つのレシピ内で題材が2つ重複してもいけません。最初に並んでいるという理由で、最初のパレット、組み合わせ、ファミリーを選んではいけません。
2. ウェブサイトの場合は、まずwebsite.mdの「目立たせる」を読みます。避けるべきデフォルトの見た目に名前を付け、「アイデア」を一文で絵のように表現し、作品は画像で見せます。クライアントを捏造してはいけません。アプリの場合は、app.mdの「1つの画面」を読み、「アプリの短い道筋」に従います。
3. 「画面を決める」にある4つの項目を書きます。対象者、1つの判断、最初に目にするもの、次のアクションです。
4. ロックしたシステムは、library/themes/<id>.css、library/pairings/<id>.css、およびファミリーのrules、radius、button、densityです。これらの数値に合わせてください。
5. 組み合わせにcautionがある場合は、作業を始める前にそれを伝えてください。本文には--font-textを使います。数値には.numを使います。組み合わせにモノスペースフォントがある場合、.numとコードにはそれを使います。numbersがdisplayの場合、.numにはディスプレイ用書体を使います。組み合わせにモノスペースフォントがない場合、.numには等幅数字のテキスト用書体を使い、コードにはシステムのモノスペースフォントを使います。Googleのモノスペースフォントは追加しません。
6. テーマは1つのモードを表し、各テーマにはもう一方のモード用のpairがあります。スマートフォンアプリでは両方を使い、システム設定に従います。ウェブサイトでは、昼夜両方を求められた場合、またはユーザーが開いたままにするタイプの製品の場合に、両方を使います。テーマCSSにはサンプルの角丸とシャドウが含まれていますが、これは無視してください。角丸とシャドウはファミリーで設定します。
7. まずシェルを作成し、次にメイン画面を作成してから、app.mdの「最小限の画面」にある残りを作成します。ヒーロー、ナビゲーション、テーブル、フッターを考案する前に、それぞれのブリーフを開いてください。ウェブサイトでは、ヒーロー、作品、フッターについて「最近の選択」の独自性チェックを行います。チェック後に履歴行を記入し、workとfooterを埋めてください。
8. 画面を開き、practice.mdの「見た目の確認」と「1つ修正」を実行します。不合格の箇所はすべて修正してください。

内部ツール、管理画面、運用画面、ダッシュボードは種類をplatformにし、次にdashboardレシピを選びます。チャート、指標、空のリスト、読み込み失敗の表示は、チャートライブラリのデフォルトではなく、パーツから作成してください。

AdoptフローとBrandフロー

リデザインの場合は、flows.mdに従います。上の表からそこへ案内された場合は、開いてください。

パーツフロー

1. library/pieces.txtをカテゴリ、プラットフォーム、タイトル、スタイル、タグで検索するか、components.mdのルートを使います。プラットフォームはweb、mobile-web、mobile-app、pwa、tabletです。
2. library/briefs/<id>.mdを読みます。ブリーフには、構造、数、サイズ、モーションのタイミング、状態、タップ領域の仕様が記載されています。モーションを確認する必要がある場合は、demoのHTML受け入れファイルを確認してください。
3. ブリーフに記載された色、フォント、ライトモードまたはダークモードは、そのデモ用のものです。practice.mdの「ブリーフの適用」に従い、役割に応じて、ロックしたテーマと組み合わせに置き換えます。ライトテーマで夕暮れの青を使ったパララックスは、レイヤーと速度はそのままに、日中のパララックスに置き換えます。
4. ブリーフの受け入れチェックリストを基準に確認します。デモの文言にのみ当てはまる項目は省略します。不合格の箇所は修正してください。

キットがロックされておらず、プロジェクトにデザインシステムもない場合は、まずLibraryフローを使って、この製品の雰囲気に合うテーマと組み合わせをロックし、どれを選んだかを伝えてください。プロジェクトの標準Tailwindカラーやフレームワークカラーはデザインシステムではありません。設定済みのテーマ、トークン、またはスタイルが適用された画面がデザインシステムに該当します。

pieces.txtにその用途に合うパーツがない場合は、その旨を伝えてください。スラッグを作り出してはいけません。

ライブラリの使い方

• テーマ：library/map.json から雰囲気で選び、library/themes/<id>.css をコピーします。プライマリー、セカンダリー、ターシャリー、成功、警告、危険、情報、サーフェス、link が含まれています。
• 組み合わせ：library/map.json から選び、library/pairings/<id>.css をコピーします。
• テーマ全体ではなく、相性のよい 2〜4 色：library/wada.txt の 1 行を使います。使い方はヘッダーに記載されています。
• アイコン：library/icons.json。24px のストローク幅は 1.75 です。アイコンがない場合は、components.md のアイコンとナビゲーションに従ってください。
• ロゴ、ファビコン、共有画像：components.md のロゴとファビコンを参照してください。
• モーション：motion。デフォルトのイージングは cubic-bezier(0.2, 0.7, 0.2, 1) です。UI は 200ms、レイアウトは 320ms、シートは 400ms です。prefers-reduced-motion を尊重してください。

数値が食い違う場合

それぞれに記載された内容に従ったうえで、次の優先順位を適用します。

1. 維持するよう指定された既存のデザインシステム。
2. 半径、シャドウ、ボタンスタイル、密度については、ロックされたファミリー。
3. すべての色については、ロックされたテーマ。フォントについては、ロックされた組み合わせ。Free では、シートに記載された色と書体がそれらに代わります。
4. 構成、領域、モーション、インタラクション、状態、ヒットターゲットについては、パーツのブリーフ。

ブリーフで指定された色をトークンに割り当ててください。ホバー状態や選択状態のために、新しい hex 値を混ぜないでください。

ブリーフの役割	トークン
ページ	--bg
カードまたは行	--surface
ホバー	--surface-2
押下または選択	--primary-soft
選択中かつホバー	--surface-3
細い境界線	--line
強い境界線	--line-strong
本文テキスト	--ink
セカンダリテキスト	--ink-2
控えめなテキスト	--ink-3
テキストボタンまたはリンク	--link
プライマリボタン	--primary の塗りつぶし、--primary-ink のラベル
グロー、グラデーションの色止め、ハイライト	--primary-soft、または明るい色止めを 1 つだけ使う場合は --primary
フィードバック色の背景上のテキスト	対応する -soft に対して --success-on-soft / --warning-on-soft / --danger-on-soft / --info-on-soft

ルール

• 1 つのビューにつき、プライマリボタンは 1 つです。ブリーフで 2 つ描かれている場合は、片方をアウトラインにします。
• フィードバック色は、現在の状態を示すために使い、装飾には使いません。
• 製品にすでにブランドカラーがある場合は、テーマのサーフェスを維持し、--primary をブランドカラーに設定してください。--primary-ink には、コントラスト比が 4.5 以上になる #141210 または #fffdf8 のいずれかを使います。
• 2 つ目のパレット、無作為な Google フォント、デフォルトの Tailwind テーマを追加しないでください。Show モードのシーントークンと 1 つのスクリプト書体は、シートに理由とともに記載されているため、2 つ目のパレットや無作為なフォントには該当しません。Free の色とタイポグラフィは、そのサイトのテーマと組み合わせに代わるものです。それらはテーマの役割として記載する 1 つのパレットであり、各色に理由が必要です。
• 独自の公式デザインシステムを持つ別のプラットフォーム内に画面がある場合、その画面にはそのシステムのパッケージを使ってください。Shopify 管理画面内では Polaris、英国政府のサービスでは govuk-frontend、米国政府のサービスでは USWDS、Jira または Confluence 内では Atlaskit、Microsoft 365 内では Fluent を使います。Lounge は、そのプラットフォームの外にある部分にのみ使ってください。
• ページ上でユーザーが読むテキストには、em ダッシュ（—）と en ダッシュ（–）を使いません。代わりに、句点、コンマ、コロン、または括弧を使ってください。範囲にはハイフンを使います：2018-2026。
• ファイル全体を書いてください。実際のコードの代わりに // rest of code、// TODO、... を使わないでください。返信が長すぎる場合は、ファイルの末尾で止め、残りのファイルを伝えてください。
• クレジット：Designed using <a href="https://www.designlounge.live">Design Lounge</a> をサイトまたはアプリのフッター、あるいは概要画面に、フッターの小さなテキストスタイルで 1 回記載してください。コピーしたトークンブロックにも、同じ行をコメントとして残してください。製品での使用は自由です。カタログをカタログとして再公開しないでください。

返信

簡潔にしてください。最初に、選んだ項目をリンク付きで記載します。次に、作成したもの、practice.mdに記載した内容、失敗したチェックとその修正方法だけを記載します。成功したチェックの一覧は貼り付けないでください。

ビルドの返信は、毎回このブロックで終えてください。すべてのチェックに合格した場合も、確認したことを示すために必須です。実際のスクリーンショットファイル名を記載してください。ページを開けなかった場合は、「未確認」と記載し、その理由を説明してください。コードを読んだだけなのに、確認したと言ってはいけません。

Looked at: <screenshot file names, with sizes> with <tool>, or "not looked"
Remember after five seconds: "<one thing>" · could be anyone's: yes | no
Correction: <the one change>
Still open: <missing links, assets, effects you never saw run, parts built without a brief, or none>

例

examples.mdを参照してください。パスと種類の対応表：reference.md。