aesthetic-application

Aesthetic Application

概要

指定された美意識を、開発者がすぐに実装できる完全なデザイン仕様に変換します。構造化されたトークン仕様表、文化的な特徴のリスト、コンポーネント単位の注記、競合に関するフラグのセクションで構成されます。すべての判断は具体的で実装可能なものとし、抽象的な雰囲気の描写にとどめません。美意識フレームワークの7つの次元すべてを対象とします。

互換性／ツール

このスキルでは、allowed-tools フロントマターを意図的に宣言していません。Agent Skills 互換のランタイムであれば利用でき、SKILL.md とスキル内の references/ Markdown ファイル、およびインストール済みの aesthetic-literacy 辞書の読み込みに依存します。エージェントにファイル読み取りツールがある場合は、それらのファイルを読み込んでください。ない場合は、関連する抜粋をユーザーに提示してもらってください。

このスキルを適用する場面

次の場合に適用します。

• ユーザーが「X のような見た目にして」「この美意識を適用して」「X のデザイントークンを作って」と依頼した場合
• ユーザーが美意識の方向性に基づいた、開発者への引き継ぎ用仕様を必要としている場合
• ユーザーが美意識に基づいた CSS 変数、デザイントークン、コンポーネントの注記を求めている場合
• ユーザーが、トークンとして整形する必要のある、根拠のある視覚的な値を提示した場合

次の場合は適用しないでください。

• 美意識が特定されていない場合（まず aesthetic-literacy で曖昧さを解消してください）
• ユーザーがコンポーネント、アクセシビリティの問題解決、パフォーマンスに関する実装上の助言を求めている場合（対象範囲外です）

依存関係

必須：aesthetic-literacy（7次元フレームワーク、辞書、必須要件）
利用可能な場合は、参考画像からユーザーが提示した根拠のある値を併用します。辞書による近似値より、明示的に提示された値を優先してください。

インストール済みのユーザー向けスキル内のリファレンス：

• references/output-contract.md — 必須の回答形式と品質基準
• references/token-template.md — トークン表の完全なひな型
• references/css-translation-patterns.md — 美意識の次元ごとの CSS 実装パターン
• references/component-notes-contract.md — コンポーネント注記に必要な内容

ナレッジベースのパス

トークンやコンポーネント注記を作成する前に、インストール済みの aesthetic-literacy スキルから正規の辞書エントリーを読み込んでください。

• 必要に応じて、aesthetic-literacy/references/aesthetic-index.md でスラッグを確認します。
• 通常のアプリデザインの情報源として、aesthetic-literacy/aesthetics/<slug>.md を読み込みます。
• 最終的な引き継ぎ資料の作成前に、references/output-contract.md を読み込みます。

通常のアプリデザインのワークフローでは、ルートのリサーチログを読み込まないでください。ルートの knowledge/aesthetics/ プロファイルと追記専用ログは、出典確認、保守、またはリサーチ用のリソースです。ユーザーが出典確認、保守、リサーチの詳細を明示的に求めた場合、または正規エントリーに出典の確認が必要な不確実性が示されている場合に限り、読み込んでください。

6段階の適用ワークフロー

ステップ 1 — 美意識を確認する

美意識の名称を明示してください。曖昧なまま先に進まないでください。

• ユーザーの依頼が曖昧な場合（「かっこよくして」／「未来的な感じ」など）は、まず aesthetic-literacy の曖昧さ解消プロトコルを適用します
• リクエストされた用語が、正規スラッグではなく下位または関連する美意識（例：「outrun」「datamoshing」「old money」「Web 2.0 Gloss」）の場合は、親となる美意識を特定し、その辞書エントリーを読み込み、Subsets / Related セクションを確認して、強調すべき下位の美意識固有の重点を記録します。次のように明示します。「[親となる美意識] を [ニュアンスモード] モードで適用し、[下位の美意識] を強調します。」
• aesthetic-literacy/aesthetics/<slug>.md を読み込み、制作の指針として使用します
• 正規エントリーがなく、美意識が未知またはニッチな場合は、値を創作せず、この公開パッケージには出典に基づく十分な指針がまだ含まれていないと明示します
• 次のように明示します。「[美意識名] を [ニュアンスモード] モードで適用します。」

Step 2 — 印象の意図を定める

次の4つの印象モードから1つを選び、明示してください。

モード	意味	使用する場面
Authentic	時代考証に忠実な純粋な表現	ニッチなオーディエンス、文化的な製品、自覚的なコンテキスト
Nostalgic quotation	想起させつつ現代的に更新する — 現代の使いやすさと、見覚えのある美的要素	消費者向け製品、ライフスタイルブランド
Ironic pastiche	機知や論評を込めた、意図的な誇張	エディトリアル、クリエイティブなプロジェクト
Contemporary revival	現代のデザイン感覚を通して再解釈した、新鮮な表現	伝統を打ち出す現代のテック製品

ユーザーが指定していない場合は、コンテキストから推測し、その推測を明示してください。不確かな場合は質問してください。

Step 3 — 制約を収集する

出力を作成する前に、以下を収集して記録してください。

• WCAG AA：コントラストに関する問題があれば記録してください。問題として明示し、解決してはいけません。アクセシビリティ要件と競合する美的要素をどう扱うかは、開発者が決定します。
• ダークモード：その美的表現には自然なダークモード版がありますか。それとも、ダークモードにすると美的表現が根本的に変わりますか。
• プラットフォーム：Web、iOS、Android、印刷物のどれですか。（モーションやフォントの機能は大きく異なります。）
• 融合：複数の美的表現を組み合わせていますか。両方の要素を挙げてください。競合を生む要素を特定してください。

Step 4 — 各要素について具体的に決定する

7つの要素すべてを検討してください。決定事項はすべて、実装可能な値でなければなりません。

要素	必須の出力
パレット	用途（背景、サーフェス、プライマリ、セカンダリ、アクセント）を割り当てた16進数値
タイポグラフィ	フォントが指定されていない場合はフォントファミリー名または書体カテゴリ、ウェイト、サイズ、字間、行の高さ
テクスチャ	CSS プロパティと値（または「none」）
形状	角丸の値（px）、形状のスタイルに関する注記
モーション	期間の範囲（ms）、イージング（名称または cubic-bezier）、推奨するアニメーションの種類
スペーシングの慣例	基準となるスペーシング単位（px）、スケール（4px / 8px / 12px など）、密度の説明
文化的な特徴	含めるシグナルを3～5個、避けるシグナルを2～3個

Step 5 — 競合を解決する

美的表現を組み合わせることで競合が生じる場合は、明示的に解決してください。

• 両方の要素を挙げる
• 競合する具体的な要素を特定する
• 要素ごとの解決策を示す：
  • どちらの要素を優先するか
  • または、両方に適した折衷案の値
  • または、ユーザーが解決する競合（明示して、推測しない）

未解決の組み合わせを出力してはいけません。未解決の組み合わせは、一貫性のない出力につながります。

Step 6 — 出力を作成する

以下の出力セクションを4つすべて作成してください。

---

出力形式

1. トークン仕様

カラー（7トークン）、タイポグラフィ（8トークン）、形状（3トークン）、モーション（3トークン）、スペーシング（6トークン）、レイアウト（任意の4トークン）を網羅する、システムに依存しないフラットなトークン値の表です。プロジェクトのトークンシステム（CSS カスタムプロパティ、Tailwind config、DTCG JSON、Sass 変数、Swift/Android トークンなど）に変換してください。

すべてのトークン名、カテゴリ、注記を記載した空のテンプレートについては、references/token-template.md を読み込んでください。

出力形式に関する注記：トークンの表は、形式に依存しない主要な出力です。開発者が DTCG JSON、CSS カスタムプロパティ、または Tailwind config を明示的に求めた場合は、指定された形式に変換してください。DTCG JSON の例は EXAMPLES.md にあります。

2. 文化的な特徴

含める（シグナルを3～5個）：

• シグナル 1
• シグナル 2
• シグナル 3

避ける（シグナルを2～3個）：

• 避けるシグナル 1
• 避けるシグナル 2

3. コンポーネントに関する注記

主要な UI コンポーネント12種類について、簡潔で実装可能な注記を記載します：ボタン、カード、入力欄、ナビゲーション、ヒーロー／ヘッダー、見出し、区切り線、リンク、バッジ／タグ、モーダル／オーバーレイ、アラート／通知、アイコン。

コンポーネントの網羅性に関する契約の全文については、references/component-notes-contract.md を読み込んでください。

4. フラグ

開発者の対応が必要な項目です。解決はせず、そのまま提示してください。

• WCAG の競合：パレット内で AA のコントラスト比を満たさない色の組み合わせを列挙してください（テキストは 4.5:1、大きなテキストは 3:1）。
• 動きを抑えた表示：美的表現が動きに依存している場合は記してください（prefers-reduced-motion では表示されなくなる効果）。
• ダークモードの不足：ダークモード版が作成されていない場合は記してください。
• 美的表現の飽きやすさのリスク：美的表現が「飽和のピーク」段階にある場合は、タイミングを考慮できるよう記してください。
• 未解決のブレンド競合：Step 5 でフラグが立てられ、ユーザーの判断が必要な競合を列挙してください。

例

出力形式、トークンテーブルの構成、またはブレンド競合への対処に迷った場合は、EXAMPLES.md を読み込んでください。Y2K の仕様、ブルータリズムと WCAG の解決例、アールデコのブレンド例がすべて含まれています。

注意事項

• トークンの代わりに文章で説明しないでください。 開発者に必要なのは「メタリックな表面」ではなく、#C0C0C0 です。すべての出力は実装可能な値にしてください。
• 確認せずに、美的表現が WCAG AA と互換性がないと断定しないでください。 生のブルータリズム（黒地に白、白地に黒）は簡単に AA を満たします。包括的に非互換だと主張せず、実際に競合する色の組み合わせを特定してください。
• ブレンドを未解決のままにしないでください。 「X の優雅さと Y のすっきりしたラインを組み合わせる」は概要であり、仕様ではありません。競合する要素を明示し、要素ごとの判断を具体的に示してください。
• 文化的マーカーを必ず含めてください。 含める文化的シグナルと避ける文化的シグナルのリストがないトークンでは、何にでも当てはまる一般的な仕様になってしまいます。文化的マーカーは必須の出力です。

参考資料

トークン形式の仕様、アクセシビリティのしきい値、またはフォントの調達元が必要な場合は、REFERENCES.md を読み込んでください。

• W3C DTCG JSON トークン形式 → DTCG Format Specification
• WCAG のコントラスト比のしきい値 → WCAG 2.1 SC 1.4.3；WebAIM Contrast Checker
• フォントの調達元 → Google Fonts、Fonts In Use