finesse-ui

finesse — 技術的に卓越 · 魂を感じる個性 · 安っぽさとは無縁

finesse は 2 種類のインターフェースを構築し、レジスターに応じて振り分けます（§0）：

• brand — デザインそのものが製品です。ランディングページ、ブランドサイト、ローンチページ、ポートフォリオ、ヒーローページが該当します。華やかさ + 魂 + 第一印象を最適化します。本格的なビジュアルエンジンと、明確な個性を備えます。
• product — デザインは製品を支えるものです。ダッシュボード、管理パネル、分析画面、データテーブル、アプリシェル、設定画面が該当します。明快さ + 情報密度 + 使いやすさを最適化し、安っぽさは決して許しません。

共通する軸は同じです。高い品質、AI っぽい粗悪さはゼロ。 どちらにも適用されるのは、普遍的な品質基準（色味を帯びたニュートラルカラー、#fff／#000 は使わない、半透明／極細の境界線、色味を帯びた影、コントラストの最低基準）、安っぽさのブラックリスト（§6）、および事前チェック（§8）です。異なるのは、その基準を超えた基盤と中間部分です。brandは §3 のブランド基盤（design-dna.md — 粒子感、ビネット、ディスプレイ書体）を設け、ヒーローエンジン（§4）を活用します。productは独自の基盤（product-ui.md §0 — サーフェス、カード、KPI タイル、情報密度）を設け、コンポーネントシステムとデータビジュアライゼーションを活用します。ダッシュボードは別のデザイン言語であり、チャートを加えたブランドページではありません。粒子感／ビネット／巨大なヒーロー書体／デフォルトのダークテーマ／ヒーローエンジンを引き継ぐことはありません。

この 2 つに加えて、互いに異なる 2 つのレジスターがあります。 commerce（PDP／PLP／カート／チェックアウト）はハイブリッドです。個々のページの役割に応じて、brand または product に振り分けます。h5（スマートフォン専用画面：アプリ UI、活动页、モバイル PDP、レポート H5）はコンテナです。画面枠、安全領域、親指で操作する要素の階層、OS の UI を定めたうえで、コンテンツの表現には残る 3 つのいずれかを適用します。モバイル PDP は h5 + commerce、アプリのダッシュボード画面は h5 + product です。h5 はコンテンツのレジスターを置き換えるものではなく、包み込むものです。

以下のルールはすべて状況に応じて適用します。自動的に適用されるルールはありません。要件を読み、レジスターを定め、適合するものだけを取り入れてください。どの要件でも同じページを作るスキルは失敗です。

---

Apple のデザイン言語（任意）

Apple スタイル／苹果风を採用する場合は、基盤やペルソナを選ぶ前に references/apple-design.md を読んでください。既存のレジスターは維持し、design-language=apple を追加して、apple-mode=editorial|app|spatial を選択してください。Apple に限定した上書き設定は、以下にある競合する美的デフォルト設定より優先されます。これには、純粋な黒／白の禁止、粒子感／ビネットの必須指定、極端な行送り、ペルソナ／エンジンの強制的なローテーションが含まれます。機能性とアクセシビリティの基準は引き続き適用されます。コンポーネントの依頼には、引き続きコンポーネントのスコープが適用されます。エディトリアルのレシピと実行可能な 7 つのスタディは references/apple-patterns.md に掲載されています。

このスキルの使い方

0. 何よりも先にスコープを確認します。 依頼がボタン、入力欄、カード、モーダル、トーストなどの単一の要素であれば、references/component-scope.md に進み、そちらに従ってください。以下の手順 1～6 はページ全体のためのもので、単一コンポーネントには適しません。判定方法と曖昧な場合の質問は、このファイルに記載されています。
1. §0 ブランドの読み取りを実行します。コードに触れる前に、.finesse/log.json（ローテーションの記録、divergence.md §4）を読み、レジスター（ブランドかプロダクトか）とソウルを推定してください。Design Read を出力します。内容は、座標行、ユーザーが実際に却下できる平文の You'll see: 行、画像を使う場合に各スロットに何を置き、どこから用意するかをすべて示す Images: 行、最も可能性の高い反論 2 つ、そして文として記述したローテーション（§0.B）です。Images: 行を書く前に、このセッションで実際に利用できるツールの一覧を確認してください。画像生成ツール、MCP 画像ツール、ネットワーク取得機能、または利用可能なものがないかを確認します。これは正直に提案できる内容を決めるためです（asset-sourcing.md §1）。さらに、名前を挙げる前に、これから名前を挙げるツールが実際にこの環境で動作することを確認してください（§1.1：一覧にあることと使用可能であることは別です。認証情報のない生成ツールは Path A ではありません）。提案したら待機してください。独自の推測で生成やダウンロードを行ってはいけません。
2. §1 の 3 つのダイヤル（SOUL · SPECTACLE · DENSITY）を設定します。プロダクトレジスターでは、SPECTACLE を低く、DENSITY を高く固定します。
3. 土台を敷きます。レジスターに適したものを選んでください。 すべてに共通するのは普遍的なクラフトの最低基準です（色味のあるニュートラルカラー、#fff／#000 は使用しない、半透明／極細の境界線、色味のあるシャドウ、コントラストの最低基準。references/design-dna.md §1）。
   • ブランド → §3 ブランドの土台（references/design-dna.md）：粒子感、ビネット、clamp() のディスプレイ書体、ダークをデフォルトにする設定、奥行きを重ねたヒーロー。
   • プロダクト → プロダクトの土台（references/product-ui.md §0）：プレミアムなサーフェス／カード、KPI タイル、フローティングパネル、固定の文字サイズスケール、フィードバックのみのモーション。ダッシュボードに粒子感／ビネット／巨大なヒーロー書体／ダークをデフォルトにする設定／ヒーローエンジンを持ち込んではいけません。それはブランドの文法であり、プロダクトの文法ではありません。
   • h5 → まずフレームを整えます（references/h5-mobile.md §1）：ビューポートの契約、固定された body とスクロール可能な #app、幅 560px のデスクトップ向けスマートフォンフレーム、続いてセーフエリアの計算（§2）。フレームを組み立ててから、そのフレームが包むレジスターの土台を敷きます。
4. 続いて、パスをさらに分岐させます。
   • ブランド → §2 のソウル（references/style-personas.md）を選び、§4 のヒーローエンジン（references/hero-engines.md）を 1 つ構築します。
   • プロダクト → まず references/product-palettes.md からパレットを選びます（ピクセルの 80％を占めるのはニュートラルカラーの階調です。この手順を省くと、どのダッシュボードも青基調になります）。次に、ページの役割に応じて分岐します。
     • 読むためのページ — ダッシュボード、分析、モニタリング → references/product-ui.md（密度、テーブル、チャート、インタラクション状態）。作業を始める前に、examples/ にある最も近いダッシュボード（一覧：examples/EXAMPLES.md）を開き、product-ui.md §0 が実際のコードにどう適用されているかを確認してください。パターンを取り入れ、ファイル全体を流用してはいけません。
     • 操作するためのページ — 公開／作成ウィザード、マーチャントおよび管理者向けコンソール、設定、環境設定、レビューキュー → product-ui.md の上に references/workflow-ui.md を重ねます（ワークフローシェル、番号付きセクション、ラジオカード形式の選択肢、ライブプレビュー、送信前の確認、導出された合計、下書き／確定）。examples/ にフォームワークフローのページはありません。リファレンスをもとに構築し、ダッシュボードの例をフォームに無理に当てはめてはいけません。
     • 作業を委任するためのページ — AI ワークベンチ、エージェントコンソール、コパイロット UI など、ユーザー以外の何かが一定時間作業を行うもの → product-ui.md の上に references/ai-console.md を重ねます（1 画面に 3 つの時制、実行ストリーム、9 つの実行状態、常時表示の停止ボタン、ストリーム内の承認カード、領収書としてのコスト）。examples/relay-agent-console.html を開いてください。ダッシュボードは読みにくくなることで失敗し、コンソールは完了できなくなることで失敗します。こちらは信頼できなくなることで失敗します。ダッシュボードのどの要素も、この問題には対処できません。
   • h5 → 6 つの形態（h5-mobile.md §4：アプリシェル · ページ送り式デッキ · スナップ式ナラティブ · コマーススタック · 長文サイト · アンビエントスクリーン）から 1 つ選び、そのページが包むコンテンツレジスターを読み込んで、上記の該当する項目に従います。ネイティブ UI のパーツは独自に考案せず、h5-mobile.md §5 を参考に構築してください。TabBar は慣習であり、デザインを工夫する場所ではありません。
5. 骨格を組み立てます。ここでも、レジスターに適したものを選んでください。 ブランド → ページが何をする必要があるかに基づいて、4 つの**§5 ブランドの骨格**（ランディング · ポートフォリオ · ルックブック · スタジオ）から 1 つ選びます。プロダクト → 骨格は product-ui.md §1 のシェル形態（サイドバー · フローティングパネル · ベントー · 三連構成など）であり、§5 ではありません。h5 → 骨格はフレーム（§1）と選択した形態（§4）です。§5 のブランドの骨格も product-ui.md §1 のデスクトップシェルも、幅 390px の画面には適しません。3 つすべてで、モーションはその必要性に基づいてのみ採用します。
6. リリース前に、§6 の安っぽさを招く要素のブラックリスト（references/anti-cheap.md）、モバイルの最低基準（references/mobile-floor.md）、§8 のプリフライト（references/preflight.md）を実行します。h5 のビルドでは、モバイルの最低基準の代わりに h5-mobile.md §9～§10 を実行します。ノッチ／フレーム／スクロール／タッチのチェック項目は、「デスクトップページがスマートフォンに表示される」場合とは異なる問題を対象にしています。その後、ビルドを記録します。.finesse/log.json に追記し、CSS にスタンプを付けてください（divergence.md §4.3）。記録されていないビルドは、次回の実行で衝突します。 references/*.md ファイルには詳細な資料が含まれています。現在のフェーズで必要なファイルを読み込んでください。すべてをインラインで記載しないでください。 | 参照先 | 読み込むタイミング | |-----------|-------------| | apple-design.md | Apple／苹果風の明示的なリクエスト：モードの振り分け、スコープを限定したオーバーライド、タイポグラフィ、サーフェス、マテリアル | | apple-patterns.md | Apple風のエディトリアルカード、Bento、コントラスト、余白、角、ギャラリー。実行可能な7つの事例 | | component-scope.md | Brand Readの前、ブリーフがページではなく1つの要素についてのものの場合 — ボタン、入力欄、カード、モーダル。コンポーネントのフローに振り分けます。レジスター＋クラフトの最低水準＋既存トークンを維持し、骨格／ヒーローエンジン／ローテーションは省略します。コンポーネントが適切に作られているかを判断する唯一のゲートを適用します — 8つすべての状態を実装し、状態を主張するだけでなく可視化するプレビューファイルも用意します | | divergence.md | §0、Design Readの前 — 画一化を防ぐレイヤーです。 出力がいつも同じ方向に収束するとき、ユーザーが「ありきたりに感じる／ほかのAIサイトと同じに見える」と言ったとき、または魂に関する判断を行う前に読み込みます。5軸の構成手法（リストから選ぶのではなく、魂を構成する）、デフォルトを避ける2段階の確認、モデルのargmaxを崩すサイコロ、方向性の提案を断定してから確認する方法を扱います。§4が記憶の役割を果たします — .finesse/log.json＋CSSスタンプと、定義済みの読み込み手順（§0）および書き込み手順（§8）があります。これがなければ、「繰り返さない」は裏付けのないルールです。まず§0のレジスター境界を読んでください — 発散はブランドでは目標であり、プロダクトでは範囲を限定した手法です（ダッシュボードのナビゲーション規約から逸脱してはいけません） | | design-dna.md | ブランドの基盤を構築するとき（粒子感、ビネット、ディスプレイ書体、カラートークン、パレットのファミリー）。プロダクト／ダッシュボードが受け継ぐのは普遍的なクラフトの最低水準のみです（§1：色味のあるニュートラル、半透明の境界線、コントラストの最低基準）。ダッシュボードのサーフェス／カード／文字／モーションは、ここではなくproduct-ui.md §0に従います | | theming.md | ブリーフでライト／ダークの切り替えや、名前付きテーマを複数切り替える機能が求められている場合 — 実行時のパレット切り替え（単一の固定パレットがデフォルトではありません）におけるトークンの役割と、色のハードコードに関する落とし穴 | | motion.md | モーションに言及するブリーフ — 动效 · 炫酷 · "make it move" · "有动画" — と、すべてのbrandビルド。 エンジンの上位にあるモーションレイヤーです。誰も分けて考えない2つの軸（EFFECT：見えるもの、ROUTE：実装方法）、重み・静止時の形・失敗モードを含む6つのルート（CSS · ネイティブのスクロール駆動 · View Transitions/WAAPI · GSAP · Canvas/WebGL · 依存関係ゼロのCSS 3D空間）、約80種類のバリエーションと各ファミリーの雑な実装例を含む10ファミリーのエフェクトカタログ、モデルが4行の処理に60KBを使わないようにするエフェクト→ルート対応表、そして「ヒーローエンジン1つ＋汎用的なフェードアップ」を、異なる4つのファミリーから選んだ4つのビートに置き換えるビートシートを扱います。hero-engines.mdより先に読み込みます。このファイルが答えるのはどのエンジンか、こちらが答えるのはそもそもエンジンが必要かです | | interaction-motion.md | ビルド内の何かをドラッグできる場合、またはインターフェースが指の動きに応答する必要がある場合 — ボトムシート、ドロワー、スワイプ行、ピッカー、プル・トゥ・リフレッシュ、スワイプバック、段階的に止まるパネル、ページに展開するカード、押下後に結果を確定する必要があるボタンなど。モーションのもう半分です。motion.mdが閲覧者の見るもの（タイムラインを所有するのはあなた）を扱うのに対し、こちらは閲覧者の起こすこと（それを所有するのはユーザー）を扱います。パネルを評価するテスト — 入力自体の不確実性：速度・方向・しきい値・フレーム落ちを処理しているか —、指に追従する4段階の連鎖（1：1の追従→端を越えた後の減衰→確定→スナップ）、ウィンドウ化した速度（明白な2つの計算式はどちらも誤りです）、2条件による閉じる判定、段階位置の順序付け、シートを形作る5つの判断（起点・レイヤー・制御元・段階位置・遷移先）、重要な役割を持つFLIPの二重rAF、反例の表を扱います。390pxを超える幅にも適用されます — 折りたたみ式コンソールサイドバーも同じ仕組みです。動作例：examples/h5-sheet-lab.html | | hero-engines.md | ヒーローエンジンの構築（ブランドレジスター）。また、ページ内のヒーロー以外の場面で使う、二次的なモーション表現（文字ごとの分割表示、マグネティックボタン、カーテンワイプ、走査線、カードごとのフライイン）も扱います — 選択のレイヤー（どのエンジンか）。スコープに関する注意：これはmotion.mdにある6つのルートのうち、最も重い2つ（R4 GSAP · R5 Canvas/WebGL）です — 同ファイルの対応表で重いルートを選ぶことになってから、こちらを参照してください | | page-crafting.md | ブランドの実装レイヤー — dataviz.mdに対するchart-crafting.mdのような位置づけです。選択を終えて実装を始めるときに読み込みます。モーションゲート（REDUCE／FINEの検証＋終端状態 — プロダクトも含むすべてに適用）、キャンバスのDPR＋循環パレット＋振幅エンベロープ、mask-imageによる写真のディゾルブ、写真ヒーローのスクリーンスタック、コンテナークエリのパネル、交互に並ぶセクション上のナビゲーションスクロールスパイ、依存関係ゼロのスティッキー水平ピン留め、分解表示のスクラブ、色違いのピン留め＋スナップ、clip-pathワイプ、手書きのFLIPライトボックス、ジェネレーティブ（ギロチン分割）レイアウト、CSSのみの幾何学的コラージュ、ページ全体のエンジン＋セクションのスクリーン、フィボナッチ→KNN→トラバーサルの3Dレシピを扱います | | h5-mobile.md | ページがスマートフォンでしか表示されない場合 — H5／モバイルページ／キャンペーンページ／ミニプログラムページ／アプリUIプロトタイプ／モバイルPDP／レポートH5。第4のレジスターであり、コンテンツを収める別のレジスターを包むコンテナでもあります。ビューポートの仕様、ほかのすべてのレジスターを反転させるbody固定／スクロールする#appのアーキテクチャ、560pxのデスクトップ用スマートフォンフレーム、セーフエリアの計算、親指の可動域の反転（主要な操作は下部に配置）、デスクトップに相当するものがないタッチ操作のルール（passive、pointercancel、タップ時のハイライト、44px）、6種類のスマートフォン形状、ネイティブUI部品のレシピ（ステータスバー、TabBar、ボトムシート、FAB、プッシュ遷移、手書きのFLIP遷移）を扱います。mobile-floor.mdとは別のファイルです。そちらはデスクトップページがスマートフォンで崩れないようにするもの、こちらはデスクトップ版が存在しないページを対象にしています | | mobile-floor.md | スマートフォンで表示されるすべてのビルド — つまり、ほぼすべてです。スマートフォンのレイアウトが崩れる6つの技術的な原因と、それぞれの修正方法を扱います。overflow-x: clipとhiddenの違い（およびhiddenがスティッキーナビを壊す理由）、画像を含むグリッドトラックでのminmax(0,1fr)、どの幅でも折り返さないクリック可能なテキスト、ディスプレイ見出しのoverflow-wrap: anywhere、top:0でのスティッキー配置は1つだけにすること、そして大文字のディスプレイ書体では§3の.86–.95を上書きするすべて大文字用のline-height最低値。preflight.mdは崩れるかどうかを問い、こちらは崩れる理由を説明します | | 3d-effects.md | 3D演出の追加 — CSSによる傾斜／反転／カバーフロー／奥行き視差、またはThree.jsによるモデル／ディスプレイスメント | | style-personas.md | 魂の選択（ブランドレジスター） | | inspiration-catalog.md | ペルソナを選んだものの、その魂に合う実証済みの手法を幅広く見たい場合、またはブリーフが10種類のペルソナのどれにもきれいに当てはまらない場合 | | plain-words.md | ユーザーが読むテキストを書くときはいつでも — §0.BのDesign Read、auditの指摘、記憶ロックに関する通知。finesseの語彙（register、SPECTACLE、grain、scrim、eyebrow、hairline）は内部では重要な役割を果たしますが、外部には伝わりにくく、ユーザーが判断すべき場面でそのまま表に出てしまいます。1節で観察可能な内容を説明する注釈と、ユーザーに絶対に伝えてはいけない内部用語の一覧（5軸の座標、軸の文字、参照ファイル名）を扱います | | anti-cheap.md | 納品前の、安っぽさの確認 | | product-ui.md | ダッシュボード／管理画面／データアプリ — 読むページ（プロダクトレジスター） | | workflow-ui.md | 操作するページ（プロダクトレジスター）：公開／作成ウィザード、マーチャントおよび管理者用コンソール、設定、レビューキュー — ワークフローシェル、番号付きセクションカード、ラジオカード形式の選択肢、ライブプレビューのサイド領域、送信前の確認、派生予算パネル、下書き／確定 | | ai-console.md | ユーザー以外の何かが作業を行い、ページの役割がその作業の信頼性を担保すること — AI ワークベンチ／エージェントコンソール／インテリジェントエージェントコンソール／コパイロットUI／監視ステーション。ページの種類ではなく、機能レイヤーです：まずバックオフィスかワークベンチかを判断し（§1の判定ロジック）、本文を選んでから、これを重ねます。失敗すると読みにくくなる、または完了できなくなるのではなく、信頼できなくなります。この失敗はどちらにも起こり得ます。常に答えるべき4つの問い、1画面に並ぶ3つの時制（キュー・実行中・履歴）、チャートに代わって中心となる実行ストリーム、product-ui.md §5の8つのコンポーネント状態では扱えない9つの実行状態（partialとstoppedを含む）、常に使える主要操作としての停止、証拠にリンクするストリーム内の承認カード、第一級の要素としてのコスト／コンテキスト、成果物サーフェス、デスクトップの3列シェル、そしてスマートフォンで変わる点（§9）を扱います。また、このカテゴリの成否を左右するパレットのルールも扱います：AIバイオレットがデフォルトであること、および--autoと--needsのセマンティックなペア | | product-palettes.md | プロダクトレジスターのページすべて — design-dna.md §6で扱わない色のレイヤーです。色味のあるニュートラルのランプ5種類、ライト／ダークとアクセント上のテキストのコントラストを含む16種類のアクセント、すぐに使える12種類のセット、既知のSaaSのパレット（Linear／Stripe／Supabase／Grafanaなど）を扱います。色を選ぶ前に読み込んでください。そうしないと青を選んでしまいます | | examples/EXAMPLES.md | 肯定的な参考例のコーパス — 実際に公開された22ページ（ブランド9件＋ダッシュボード8件＋AIコンソール1件＋H5 4件）と、各ファイルの「学ぶポイント」表です。構築前に最も近い例を開いてください。特にダッシュボードとスマートフォン用シェルでは、ファイル全体ではなくパターンを取り入れます | | dataviz.md | スターター表を超える、チャート中心のプロダクトUI — 25種類すべての選択マトリクス、a11yグレード＋必須の代替手段、ライブラリの選定（選択のレイヤー） | | chart-crafting.md | 1つの自己完結したファイルで手作りするあらゆるダッシュボードチャート（棒グラフでは必須 — バーコード状のチャートになる落とし穴を防ぐため）— ライブラリを使わない実装レイヤーです。値から高さを決めるルール、div height:value/max%の棒グラフレシピ、SVG座標の正規化、線／面グラフの描画、ドーナツ／ゲージの伸長、積み上げ棒グラフ、スパークライン、3種類のアニメーションと視差モーション低減の組み合わせ、スライダーでのライブ更新を扱います | | commerce-ui.md | 商品詳細ページ（PDP）、商品一覧／カテゴリーページ（PLP）、カート、チェックアウト — コマースレジスター | | asset-sourcing.md | §0.Bで、ページ内のどこかに画像が必要だとわかった時点 — ヒーロー、ギャラリー、H5のカバーやシーン、PDPの商品画像、さらにはダッシュボードの空状態やアバター行まで対象です。カテゴリ別のチェックリストでも、納品時の確認でもありません。画像の用意方法（生成・実在するストック画像・生成プレースホルダー）と、すべてに適用される先に尋ねるゲートは、レイアウトを書く前に適用しなければ機能しません。どの方法を誠実に提示できるかを判断するセッション機能の確認と、画像の指定はユーザーに答えてもらうための提案であり、生成やダウンロードを許可するものではないというルールを扱います | | preflight.md | 完了を宣言する前の最終チェックリスト | | design-model.md | 複数ページのプロジェクト — トークンの一貫性 | | redesign-mode.md | 既存ページのアップグレード — 監査を先に行う手順 | | audit.md | 読み取り専用の診断 — 安っぽさ＋スペクタクル＋preflightの確認 | | init.md | 新規プロジェクト — PRODUCT.md（永続的なブリーフ）を作成 | | document.md | 既存のコードベース — 実際のコードからdesign-model.yamlを抽出 |

---

コマンド

finesse はデフォルトでフルビルドとして実行されますが、既存ページを対象にした反復作業向けの動詞コマンドもサポートしています。これにより、1つの不満に対して Brand Read 全体をやり直す必要がありません。各コマンドはリファレンスを1つ読み込み、1つのタスクを実行します。

コマンド	カテゴリ	内容	リファレンス
craft [brief]	ビルド	一連のフロー全体：Brand Read → Dials → 基盤 → エンジン → 組み立て（デフォルト）	すべて
init	セットアップ	新規プロジェクト：PRODUCT.md（レジスター、ソウル、固定ダイヤル、アンチリファレンス）を作成します。以後のすべてのタスクが参照するブリーフです	init.md
document	セットアップ	既存のコードベース：構築済みのデザインシステムを抽出して design-model.yaml に書き出し、乖離を報告します	document.md
audit [target]	評価	読み取り専用の診断：安っぽさのブラックリスト＋スペクタクル表示＋事前チェックを実行し、調査結果のリストを出力します。何も変更しません。	audit.md
bolder [target]	改良	SPECTACLE を +2 上げ、エンジンをアップグレードします（例：Canvas → Three.js）	hero-engines.md
quieter [target]	改良	SPECTACLE を −2 下げ、GSAP / CSS のみに切り替えます。過剰なページを落ち着かせます	hero-engines.md
soul [target]	改良	このページの雰囲気が合わない場合に、ペルソナ／ソウルを選び直します	style-personas.md
diverge [target]	改良	すべてのページが同じ仕上がりになります。 ページごとではなく、システム全体を修正します。5つの直交する軸からソウルを再構成し、2つの高度でアンチデフォルトチェックを実行し、モデルの argmax と照らし合わせ、使用済みリストを確認します。「ありきたりに感じる／ほかのAIサイトと同じ感じ／毎回同じような仕上がり」とユーザーが言った場合に使います	divergence.md
animate [target]	強化	ページのビートシートを再構成します。モーションのみを対象とし、ソウルと基盤には手を加えません。ヒーローだけではありません。ファミリーを選び（§2）、それぞれで最も低コストな方法を選び（§3）、予算を守り（重いビートは1つ、合計4つまで、同じファミリーから2つ選ばない）、すべての静止画を構成します。ヒーローエンジンの入れ替えはその一例であり、コマンドの全体ではありません。まず、ビートが閲覧者の「見る」ものか、閲覧者が「起こす」ものかを見極めてください。「抽屉能不能拖」「手势不跟手」「弹窗感觉很假」は後者に当たり、interaction-motion.md が対象です。ドラッグできるパネルはカットできるビートではないため、ここでは予算ルールは適用されません	motion.md → hero-engines.md · （ポインター駆動の場合 → interaction-motion.md）
depth [target]	強化	1つの3D表現を追加します。CSS疑似3D（傾斜・反転・カバーフロー・奥行き視差）または Three.js（モデルビューアー・画像ディスプレイスメント）	3d-effects.md
densify [target]	強化	DENSITY を調整します（±）。コンテンツを追加／削除し、ビューポートあたりの情報量を調整します	product-ui.md
redesign [target]	反復	既存ページをアップグレードします。まず監査を行い、1つの不満に対してフルリビルドはしません	redesign-mode.md

ルーティングルール

1. 最初の単語がコマンドと一致する場合 → そのコマンドのリファレンスを読み込み、それに従います。コマンド名より後ろはすべて対象です。§3 の基盤を整え、該当する**§6／§8 のチェック**を実行します。ただし、その単一のアクションに当てはまらない §0～§5 の部分は省略します（例：quieter ではソウルを再選択しません）。
2. 最初の単語はコマンドと一致しないが、意図が明らかにいずれかのコマンドに対応する場合（「地味すぎる／退屈」→ bolder、「派手すぎる」→ quieter、「このページには雰囲気が合わない」→ soul、「ありがちに感じる／ページがどれも同じに見える／每次都差不多」→ diverge、「目立たせて」→ animate、「动效 / 炫酷 / 加点动画 / 让它动起来 / 太静了」→ animate（最初に motion.md を読み込みます。これらの言葉だけでは何も選択されないため、ユーザーが拒否できる判断に変えるのは §4 のビートシートです）、「奥行きを加えて／3D にして／傾けて／視差効果を加えて」→ depth、「余白が多すぎる／詰め込みすぎ」→ densify、「このページを改善して／修正して」→ redesign）→ そのコマンドにルーティングし、呼び出された場合と同様に進めます。複数のコマンドが当てはまる場合は、一度だけどれかを尋ねます。
3. 引数がまったくない場合（/finesse のみ）→ ユーザーは「ここでは何をすべきか」と尋ねています。静的なメニューをそのまま提示しないでください。手軽に確認できるシグナルをいくつか読み取り、価値の高いコマンドを上位 2～3 個、それぞれ一行の理由とともに最初に提示し、その後に代替案として完全な表を案内します。自動実行はしません。推奨し、ユーザーの確認を待ちます。シグナル → 選択：
   • PRODUCT.md がなく、実際のコードやページがある → document（実装済みの内容を記録）および／または init（ブリーフを作成）を優先します。新規の空プロジェクトなら、init の後に craft を実行します。
   • PRODUCT.md があり、実装済みのページもあるが、監査は未実施 → audit <surface>（読み取り専用のヘルスチェック）を優先します。
   • git の作業ツリーから特定のページ／ファイルに絞れる → それらのファイル名を挙げて、audit または redesign の対象を絞ります。
   • 最近の audit で P0／P1 が見つかった → redesign（未対応の項目を修正）または、指摘内容に対応する具体的な調整コマンドを優先します（gradient-text／eyebrows → quieter／soul、動きが平坦 → animate）。
   • まだ何も実装されていないが、ブリーフは明確 → craft を優先します。 的を絞った候補を 2～3 個にし、入力する正確なコマンドを示してください。メニューは代替案であり、最初に提示するものではありません。
4. 対象はあるがコマンドの指定がなく、新しいものを作る場合 → スコープを確認してから、対象面を確認します。 ブリーフが単一の要素（ボタン、入力欄、カード、モーダル）を指定している場合は、references/component-scope.md にルーティングします。ページフローの骨格、エンジン、ローテーションは単一コンポーネントには不適切であり、その品質を実際に左右する要素（実装する 8 つすべての状態）は、ページフローのどこでも確認されないためです。ブリーフがスマートフォン専用ページ（H5／モバイルページ／キャンペーンページ／ミニプログラムページ／アプリのプロトタイプ）を指定している場合は、references/h5-mobile.md を最初に読み込み、何よりも先にフレームを構築します。デスクトップを先に組み立ててから 406px に押し込むという失敗を防ぐためのファイルです。それ以外の場合は、craft のフロー全体（§0 → §8）を実行します。「ランディングページ／ダッシュボードを作って」という場合のデフォルトです。
5. audit は読み取り専用です。 指摘事項を報告するだけで、コードは編集しません。それ以外のすべてのコマンドでは、対象を変更できます。

自動トリガーに変更はありません。finesse は引き続き description を介して自然言語から起動します。コマンドは精度を高めるために追加された入口（/finesse quieter page.html）であり、置き換えるものではありません。どちらの方法でも同じリファレンスに進みます。

ページを変更するコマンドを実行した後は、完了を宣言する前に、該当する §8 の Pre-Flight ゲートを実行してください。

---

0. ブランドの読み取り（最初に行う）

AI によるデザイン出力の大半がよくないのは、ブリーフを読み取る代わりに、モデルが既定の美的スタイルに飛びつくからです。そうしないでください。

0.A レジスターを判断する（以降のすべての判断がここで分岐します）

まず、デスクトップ版の形式があるかを確認してください。 ない場合、つまり、チャットメッセージや QR コードから開き、スマートフォンのモックで見る H5 / モバイルページ / キャンペーンページ / ミニプログラムページ / アプリのプロトタイプ なら、レジスターは h5 で、これはコンテナです。references/h5-mobile.md に進んでフレームを作成してから、ここに戻り、その下にある コンテンツ のレジスターを選んでください。h5 は以下の3つのいずれかを包むものであり、置き換えるものではありません。依頼内容が「モバイル版のページ」としか書かれていない場合の、二択を決める質問は h5-mobile.md §0 にあります。「このページはスマートフォンでだけ開きますか、それともパソコンでも見栄えよくする必要がありますか？」 ——「両方」なら、これはブランド／製品ページであり、mobile-floor.md を適用します。スマートフォンのフレームを作るのは誤りです。

「ワークベンチ」についても同じ質問を、何よりも先にしてください。 「ワークベンチ」と「管理画面」は別の製品です。 このスキルでは、前者を後者と見なすのが、誤ったものを作ってしまう最もよくある原因です。何を中心にするのかを尋ねてください。一連の業務オブジェクト → 管理画面、本人が繰り返し行う一つの作業 → ワークベンチです。利用人数を尋ねてはいけません。その後で初めて画面が問題になりますが、それもワークベンチの本体（デスクトップシェルか h5-mobile.md のモーフ A.1 か）を選ぶためだけです。作業を行うエージェントは、その上に重ねる機能レイヤー（ai-console.md）であり、第三の種類ではありません。完全な判定方法は §1 のダイヤル表を参照してください。

• brand — デザインそのものがプロダクトです。ランディングページ、ブランドサイト、ローンチ、ポートフォリオ、キャンペーン、ヒーローページが該当します。大胆で、独自の見解を持ち、圧倒的な表現を目指します。ソウル＋ヒーローエンジンの方針です（§2、§4）。
• product — デザインはプロダクトに貢献します。ダッシュボード、管理画面、分析、データテーブル、アプリシェル、設定、ツールが該当します。明快さ、情報密度、使いやすさを最適化します。コンポーネントシステムの方針です（references/product-ui.md）。それでも決して安っぽくしてはいけません。普遍的な品質の下限（§3の最後の3項目）と安っぽさのブラックリスト（§6）を継承し、ブランド基盤の粒子感／ビネット／ヒーロータイポグラフィ／ダークモードをデフォルトとする設計ではなく、プロダクト基盤（product-ui.md §0）を土台にします。
  • もう一段階だけ分類します。ただし最初の分岐は、ページの仕事の一覧ではなく、后台と工作台です。 何を中心に回るかを確認します。一群の業務オブジェクト → 后台、ユーザーが何度も繰り返す単一の作業 → 工作台（§1のダイヤル表に完全な判定方法があります。このスキルで最も重要な分岐であり、最も間違えやすい箇所です）。
    • 后台は仕事の種類に応じて、閲覧と操作に分かれます。閲覧するダッシュボードは、読みにくいことで失敗します。変更せずにproduct-ui.mdを使います。主要な操作が重要な確定処理（公開／リリース／提出／設定の保存――キャンペーンを公開する販売者や、ルールを設定する管理者など）であるページは、操作するページです。完了できないことで失敗するため、references/workflow-ui.mdを追加で読み込みます。ログインフォームや検索フィルターは該当しません。これらはproduct-ui.md §4で扱います。
    • 工作台は仕事ではなく利用する端末で分かれます。デスクトップでは、A.1の情報密度とソウルを備えたproduct-ui.mdのシェルを維持し、スマートフォンではh5-mobile.mdのモーフA.1を使います。どちらも同じ種類です。
    • さらに、以上すべてとは独立して、一定時間にわたる作業をユーザー以外の何かが実行するかどうかを確認します。 エージェントが複数ステップのタスクを実行し、出力がストリーミングされ、実行が途中で失敗する可能性があり、キューがある場合は、選択済みの内容にreferences/ai-console.mdを追加します（§8はデスクトップシェル、§9はスマートフォン向けの形式です）。何をしているのか、なぜなのか、いくらかかったのか、どう止めるのかが分からないという信頼できなさによって失敗します。閲覧／操作のどちらの分類でも、この問題には対応できません。これはカテゴリではなく機能です。 エージェントのないワークベンチには不要で、エージェント機能を追加してもバックオフィスがワークベンチに変わるわけではありません。ツールもキューも成果物もないチャットボットも該当しません。モデルの利用料金を扱うダッシュボードは、あくまでダッシュボードです。
  • ここでは色の選択が必須です。 CSSを書く前にreferences/product-palettes.mdから選びます。「ダッシュボード」なら青、と決めつけず、色を決めるのはプロダクトです。
• commerce — 3つ目のハイブリッドケースです。商品詳細ページ（PDP）、カテゴリ／一覧ページ（PLP）、カート、チェックアウトが該当します。上記のどちらにもきれいには当てはまらないため、無理に分類せず、個々のページが担う仕事に応じて判断します。
  • 単一の主役商品を販売するPDP（単一SKU、ローンチ、看板商品）はbrand寄りです。ソウルを選び（§2）、仕様／レビュー／信頼性を示す情報のために高い情報密度を保ちます。PDPの基本構成はreferences/commerce-ui.mdを参照してください。
  • 多数のSKUを扱うPLP／マーケットプレイス（フィルター、並べ替え、多数の商品を並べたグリッド）はproduct寄りです。ダッシュボードと同様に情報密度を高くし、スペクタクル性を低くします。グリッド／フィルターのパターンはreferences/product-ui.mdを、価格／CTAの配置、カート、チェックアウト、ダークパターンの禁止など、コマース固有のルールはreferences/commerce-ui.mdを参照してください。
  • どちらか判断に迷ったら、こう尋ねてください。「このページは、単一商品の雰囲気を売り込もうとしているのか、それとも複数の商品を比較／絞り込みしやすくしようとしているのか？」

まず、プロジェクトのメモリーをすべて読みます。3つのファイルは、それぞれ別の問いに答えます。

ファイル	答える問い	作成者
PRODUCT.md	何を変えずに保つべきか？――文体、ユーザー、ブランドの個性、固定されたダイヤル、避けるべき参考例です。あなたの推測より優先されます。	init
design-model.yaml	すでに何が構築されているか？――固定済みのパレット／書体／基盤を確認し、このページを既存のページと一致させます。	document
.finesse/log.json	何を変えるべきか？――直近20回のビルドにおける5軸の座標です。ローテーションの記録です。	完了したすべてのビルド（§8）
最初の 2 つは一貫性を固定し、3 つ目は差異を強制します。これらは相反する目標であり、意図的に別々のファイルに置かれています — divergence.md §4 を参照してください。.finesse/log.json が存在しない場合は、コードベースで /* finesse · という CSS スタンプを grep し、そこから 1 件のエントリを推測してください。どちらも存在しない場合、これが初回実行であり、ローテーションの制約はありません。

• PRODUCT.md がなく、複数ページまたは繰り返しプロジェクトで、ブリーフが薄い → まず init を実行することを提案します（PRODUCT.md が 1 つあれば、以降のすべてのページが一貫します）。単発のページに無理強いしないでください。
• 既存のコードベースがあり、design-model.yaml がない → 追加する前に既存の内容を記録するため document を提案します。
• メモリが存在するのに新しいリクエストがそれと矛盾する場合は、その衝突を明示してください — ロックを黙って上書きしないでください。

0.B 生成前に「Design Read」を出力する — 方向性を問い合わせるのではなく、断言する

拒否したデフォルトを最初に名指しし（§0.D）、次に方向性を — そしてそのページがどう見えるかを、ユーザーが思い描ける言葉で伝えます。そして、異議を唱えるための具体的な方法を 2 つ提示します：

Lazy default (rejected): {the obvious aesthetic for this category}
Design Read: {industry} · {soul in 2-3 words} · register={brand|product} · SPECTACLE={n} ·
             layout={dominant layout family} · engine={type}
You'll see: {what appears on screen, in plain observable terms — color, motion, type size, structure}
Motion: {the beat sheet — one plain-language line per beat, plus the still. Omit only if
        the page genuinely doesn't move. Route names never appear here — motion.md §4}
Images: {how many, of what, and where they'd come from — or "none, and here's why"}
Not right? Most likely one of these: ① {the most probable objection} ② {the second}
Rotation: {plain sentence — which recent direction this deliberately avoids}

例：

Lazy default (rejected): dark page, violet glow, floating 3D render, three feature cards.
Design Read: deep-space astronomy · cinematic + reverent · register=brand · SPECTACLE=8 ·
             layout=full-page engine + scrimmed sections · engine=Three.js particle galaxy
You'll see: a near-black page with slow-drifting star dust behind everything, a very large
            headline sitting on top of it, and the galaxy rotating as you scroll.
Motion: 首屏  星尘在背后慢慢漂，标题压在上面
        滚动  往下滚星系跟着转，越滚越深
        交互  切换观测目标时，参数自己重排，不是整块刷新
        收尾  底部那行坐标逐字浮起
        静止版 星系定格在一帧构图最好的，其余全停
Images: 3 — a wide nebula plate behind the hero, 2 square instrument details in the spec band.
        I can generate them here (they'd share one cold-blue grade); say the word and I'll
        list the shots before spending anything. Or the page ships engine-only, no photography.
Not right? Most likely one of these: ① you don't want a moving background
            ② near-black is too heavy and you want this light.
Rotation: deliberately steering clear of the last three builds (machined metal / paper press /
          phosphor terminal) — this one is water and drift.

You'll see: こそが、ユーザーが実際に答える行です。 Design Read: の行はあなたにとっての座標です — SPECTACLE=8、scrimmed sections、Three.js particle galaxy は、非デザイナーが思い描くことも、順位づけすることも、したがって拒否することもできない 3 つの要素です。答えが 1 つしか通らないゲートはゲートではありません。レンダリングされるものを書いてください：色、何かが動くかどうか、文字の大きさ、構造はどうなっているか。専門用語は避けてください — どうしても用語が必要な場合は references/plain-words.md を参照してください。

Motion: がここにあるのは、「炫酷」や「好看」では何も選べないからです。 これらの言葉はどのモデルも同じ答え — フェードアップするセクションの上に WebGL パーティクルのヒーロー — にマッピングしてしまうので、これらを含むブリーフはモーションの決定ではなく、空白の決定です。彼にもっと具体的にするよう求めてはいけません。彼にはその語彙がなく、求めれば「就是要好看那种」が返ってくるために 1 ラウンドを費やすだけです。 代わりに、絵で語るビートシートを断言してください。1 行につき 1 ビートとし、2 つの Not right? の分岐を構造的に異なるビートにします — 「你想要能拖着转的，不是自己往前走的」は一言で答えられます。ヒーローだけでなくページ全体をカバーしてください。1 つの華やかなビートと 3 つのありきたりなフェードアップというページは、この行が壊すために存在する形です。ルート名は内部的なものです（R6、animation-timeline、View Transitions）— 彼は絵を読み、あなたは座標を保ちます（plain-words.md）。静止画もここに属します。それはユーザーが拒否できるビートであり、最後に付け足すフォールバックではありません。完全な手法は references/motion.md §4 にあります。

Images: がここにあるのは、ユーザーはあなたにできると知らないことは求められないからです。 あらゆるレジスターには、画像がページを支える場所があります — ブランドのヒーロー、PDP ギャラリー、H5 カバーやアンビエントシーン、さらにはダッシュボードの空の状態やアバター行まで — そしてデフォルトの失敗は静かに起こります。写真があるべき場所にグラデーションでページが作られ、誰も「画像」という言葉を口にしないのです。ですから、コードが存在する前の Design Read の時点で、レジスターが何であれ、カテゴリが何であれ、画像スロットを名指ししてください。 それらを数え上げ、それぞれが何を描くのかを述べ、このセッションでどこから来るのかを述べてください — つまり、まず実際のツールリストを確認し（画像生成ツール → 生成を提案できる、ネットワーク取得のみ → 実際のストック、どちらもない → その旨を伝える）、名指しする前にそれが動作することを検証します（asset-sourcing.md §1.1）。references/asset-sourcing.md は 3 つのパスのすべてについてのプロトコルであり、その承認ルールは依然として有効です — この行がそれを早く、まだ「はい」が安価なうちに発火させるのです。名指ししたパスが後で使えないと判明した場合、§1.2 は次の段階に下げてその旨を伝えるよう定めています — 生成からいきなり手描きのプレースホルダーに落ちてはいけません。

スロット名を挙げるのは提案であって、許可ではありません。尋ねて、返答を待ってください。生成もダウンロードもしないでください。 この一文があるのは、ユーザーに選択肢があると知らせるためです。ユーザーが望んでいると推測したからといって、生成予算を使ったり、オープンなネットワークからアセットを取得したりする許可ではありません。どちらも実際のコストがかかり、出所にも実質的な影響を及ぼす行為です。どちらを実行する場合も、許可できるのはユーザーが「はい」と答えたときだけです。これによって防ぐ失敗は、無言のグラデーションの逆です。モデルがブリーフに画像が必要だと判断したために、頼まれてもいない画像が4枚ページに表示され、費用が請求されるという事態です。枚数と出所を伝え、そこで止めて、ユーザーの返答を待ってください。asset-sourcing.md §2/§3 がどちらの方法にも設けている同じ確認手順を、まだ無料で変更できる段階に移しただけです。

そのページに写真が本当に不要な場合（蛍光体ターミナル風のデザインや、純粋なタイポグラフィによるブルータリストなページなど）は、none と、その理由を一節で記してください。これはユーザーが拒否できる判断でもあり、明記は必須です。

Not right? では、自由回答を促すのではなく、実際に異なる選択肢を示してください。 「ご意見をお聞かせください」では何も返ってきません。具体的で、ありそうな、互いに異なる2つの懸念を示せば、ユーザーは指摘しやすくなります。それぞれ、実際にデザインを変えることになる要素でなければなりません。通常はテーマと動きです。ページ全体はこの2つの判断を軸に組み立てるからです。

ローテーションの一文は必須であり、飾りではありません。 頭の中だけで行ったローテーションは、後から見ると、あなたにもユーザーにも、単にローテーションしたと説明しただけの場合と区別がつきません。コードを書く前に記録しておくことで、ローテーションが適切でなかった場合に、まだ無料で修正できる段階で見つけられます。軸の文字ではなく、文として書いてください。 differs on E + C + A (3/5 ✓) では、ユーザーにはEが何なのかわからず、実は金属の削り出しを望んでいたと異議を唱えられないため、反証できません。5軸の座標は引き続き .finesse/log.json とCSSのスタンプ（§8.0）に記録します。監査時にはそこから確認できます。しきい値と書式については divergence.md §4.4 を参照してください。この行を省略できるのは、プロジェクトの最初のビルド（ログもスタンプもない場合）だけです。その場合は、省略する理由も伝えてください。

デザインの説明を終えたら、そこで止めてください。まだコードを生成しないでください。 確認または方向転換の指示を待ちます。

尋ねるのではなく、方向を明言してください。 進める方向を示し、変更したい点があれば遠慮なく伝えてもらいましょう。形容詞を3つ並べたメニューをユーザーに渡してはいけません。見たことのないデザインを言葉だけで選ぶことはできないため、最初の候補を選ぶだけになり、何も学べません。答えがすでに明らかな場合、メニューは単なる演出です。You'll see: と Not right? の組み合わせはメニューではありません。方向性を1つ示し、起こりそうな失敗を2つあらかじめ挙げます。だからこそ、形式だけでなく、実際に使える拒否の機会になります。

ユーザーが示された方向性をまったく評価できない場合は、Mode 2です。 ブリーフに方向性の情報がなく、漠然とした称賛の言葉（「好看」、「高级」、「有质感」、「premium」、「clean」）だけの場合や、「よくわからない」と明言している場合は、どれほど明確に書いても You'll see: には形式的な承認が返ってきます。ユーザーに比較の基準がないためです。代わりに、実際に異なる3つのバリエーションを作成してください（divergence.md §7 Mode 2 と、目を細めて見るテストを参照）。方向性のない形容詞も、本当に曖昧なブリーフと同じくらい強い分岐の兆候です。

例外 — ブリーフに本当に複数の方向性がある場合（「premium」なブランドでも、北欧風の簡素なデザインと、バロック風の豪華なデザインのどちらもありうる場合、個人サイトでも、ポートフォリオとマニフェストのどちらもありうる場合など）は、選択肢を説明するのではなく、実際に作ってください。忠実度は低くても、スクリーンショットを撮れる実物のページを3つ作ります。それぞれを異なる軸で変化させて、ユーザーに見てもらいましょう。3つのバリエーションが同じものに収束するのを防ぐ目を細めて見るテストを含め、references/divergence.md §7 を参照してください。

プロジェクトごとの出力がどれも似通ってしまう場合、修正するのはこの行の形容詞を改善することではありません。references/divergence.md を見直してください（リストから選ぶのではなく、5つの軸から個性を組み立て、サイコロを振ってモデルの既定の選択を崩し、使用済みリストを管理して「繰り返さない」を実際に機能させます）。

0.C 依頼内容が曖昧な場合は、質問を1つだけして、当てずっぽうで進めない

鋭い質問を1つするほうが、誤った既定設定で5回やり取りするより効果的です。出力を最も大きく左右することを尋ねてください。「抑制されたエディトリアルな雰囲気と、最大限に華やかな雰囲気のどちらを目指しますか？」／「訪問者に、サイトを離れて10秒後に何を覚えていてほしいですか？」 そして、方針を決めます。作業を進める前に、回答を待ってください。

0.C.1 ユーザーが行動に移せる言葉で伝える

finesseの語彙は内部用です。register、SPECTACLE、grain、scrim、eyebrow、hairline、layout family は、推論ではそれぞれ役割がありますが、読む人にはどれも答えようがありません。これらが表に出るのは、次の3か所だけです。いずれも、ユーザーに何かを判断してもらう場面です。

場所	説明がないと起きる問題
§0.B Design Read	確認の段階で、「進めてください」としか言えない
audit の指摘事項	どの指摘から先に直せばいいのかわからない
メモリーロックの通知（init.md）	何がロックされたのか、どう解除するのかわからない

ルール：ユーザー向けの文面で専門用語を初めて使うときは、その直後に、目で確認できる内容を一節で説明してください。その後は説明を付けずに使ってかまいません。 説明の一覧と、ユーザーに絶対に伝えてはならない内部用語については、references/plain-words.md を参照してください。これは出力だけに適用されます。推論では好きな語彙を使ってください。

0.D 既定の選択肢を避ける

この依頼で安易に選びがちな既定の案を明示し、それを打ち破ってください。「コーヒーブランド → 既定は温かみのあるベージュ＋真鍮色のセリフ体。{x} を採用するため、これを退けます。」AIらしさが最もよく現れるのは、そのカテゴリーで誰もが思いつく美的表現に飛びつくことです。（反射的に避けるべき案の一覧は references/anti-cheap.md を参照してください。）

0.E クイックスタート用ダイヤル対応表

ブリーフに以下の手がかりが含まれている場合は、§1 で調整する前に、これらのプリセットを出発点として使用してください。

ユーザーの表現	SOUL	SPECTACLE	DENSITY
「プレミアム」、「ラグジュアリー」、「ハイエンド」	8	5	3
「ミニマル」、「クリーン」、「控えめ」	6	3	3
「大胆」、「印象的」、「インパクトのある」	7	7	4
「エディトリアル」、「雑誌」、「出版物」	8	4	6
「テック」、「AI」、「SaaS」マーケティング	6	7	5
「企業向け」、「B2B」、「エンタープライズ」	4	3	6
「遊び心のある」、「鮮やか」、「クリエイティブ」	7	6	5
「データ重視」、「ダッシュボード」、「分析」	4	2	9
「商家后台」、「管理后台」、「管理コンソール」、「バックオフィス」	5	2	7
「工作台」だけで、他に手がかりがない場合	—	—	— ← どの行も適用せず、まず何を中心に据えるかを尋ねてください（下の判別フロー）
工作台 · PC で開く — 「工作台」、「值守台」、「控制台」、「专属工作台」	6	2	6–7
工作台 · スマートフォンで開く — 「每日工作台」、「打卡页」、「记录页」、「daily desk」 (h5 · morph A.1)	6	2	4–5
↳ 追加要素：エージェントが代わりに作業する — 「AI 工作台」、「agent console」、「智能体控制台」、「copilot UI」	—	—	+1 ← 行は変えず、上記 2 行に ai-console.md の機械レイヤーを加えます
「公開／作成フロー」、「ウィザード」、「公開フロー」、「設定」、「settings」	4	1	7
「ランディングページ」（他に手がかりがない場合）	7	6	4
「ポートフォリオ」	8	6	3
「製品ページ」、「PDP」、「商品詳細」	6	4	6
「商品一覧」、「PLP」、「カテゴリーページ」、「マーケットプレイス」	3	2	8
「アプリのプロトタイプ」、「アプリ画面」、「モバイルアプリ UI」 (h5 · morph A)	6	3	6–8
「キャンペーンページ」、「H5 マーケティングページ」、「キャンペーン H5」 (h5 · morph B)	8	6	3–4
「レポート H5」、「年次レポート」、「データレポート H5」 (h5 · morph C)	8	6	5
「モバイル商品詳細」、「モバイル PDP」 (h5 · morph D)	6	3	8
「モバイルサイト」、「モバイルサイト」 (h5 · morph E)	7	5	6
「天気／ポスター系の単一画面」、「アンビエント画面」 (h5 · morph F)	9	7–8	2–3

ブリーフに、より強い手がかりや矛盾する手がかりがある場合は、すぐにそちらを優先してください。h5 の行は 形態 (h5-mobile.md §0) のダイヤルを設定します。内包するコンテンツの性質によって、値を調整する場合があります。

バックオフィスと工作台 — まず一つに分岐し、次に二つの修飾要素を加える

「工作台」と「后台」は別物であり、同じ製品ではありません。 それ以外の表現 — 个人工作台 · AI 工作台 · 每日工作台 · 值守台 · 控制台 — は、どちらかに修飾要素が付いたものです。次の 3 ステップを順番に進めてください。

① 何を中心に据えるか — 分岐はここだけです。

	后台 バックオフィス	工作台 ワークベンチ
何を中心に据えるか	一連の業務オブジェクト — N 件の顧客 · 注文 · デバイス · 作業チケット · 受講者	本人が繰り返し行う一つのこと — 家計簿をつける · トレーニングする · 子育てする · 執筆する · 監視する · 異常注文を処理する
開く理由	処理する仕事がある：注文が届いた、アラートが出た、レポートを作る時間になった	時間になったので、戻って確認する · 記録する · 締めくくる
誰がデータを書き込むか	システム、連携先、他の人	本人が数秒で行います。コストは限りなくゼロにする必要があります
性格	中立であることが必須 — 他社のブランドの中で使われ、他にも 11 個のツールが並んでいます	個性が必要 — 本人のための台であり、中立的なだけでは二度目に開く理由がありません
作り方	product-ui.md（+ 主なアクションが送信／公開なら workflow-ui.md）	下のステップ②で形態を選択

② どこで開くか — 形態だけを決めるもので、種類は変わりません。 工作台は一つのものですが、二つの形態があります。

形態	シェル	例
PC で開く	product-ui.md のシェル。ただし A.1 の個性と控えめな密度を備えます —— グラフが詰め込まれたダッシュボードではありません	examples/relay-agent-console.html
スマートフォンで開く	h5-mobile.md の morph A.1。スマートフォンのフレーム + TabBar に固定し、DENSITY は 4–5	examples/h5-fern-meal-desk.html · h5-peach-daily-desk.html

③ 本人の代わりに作業するものがあるか — これは能力レイヤーであり、①②とは直交します。 エージェントが実行中で、出力がストリーミングされ、実行途中で失敗することがあり、キューがある場合は、ai-console.md の機械レイヤー（実行ストリーム · 9 つの実行状態 · 常設の停止機能 · ストリーム内の承認カード · コストの領収情報）を追加します。これは第三の種類ではなく、工作台が備えられる能力の一つです。デスクトップとスマートフォンのどちらの形態にも追加できます（ai-console.md §8 はデスクトップシェル、§9 はスマートフォンの形態です）。エージェントのない工作台にこのレイヤーを加える必要はありません。エージェントを接続したバックオフィスも、それだけで工作台に変わるわけではありません。

判定基準ではないものが二つあります。判定に使わないでください。 利用人数：家族で共有する家計簿台や、小グループで共有する監視台は工作台です。一人で使う在庫管理システムは、依然としてバックオフィスです。画面：画面はステップ②で外観を決めるだけで、何のためのものかを決めることはありません。

ブリーフが単に「工作台」で、それ以外の情報がない場合、この語に対応するダイヤル設定はありません。推測せず、尋ねてください。 一つ質問すれば①が決まり、②と③も通常は回答から分かります。

この台子主要围着什么转？
一批客户/订单/设备这类东西 · 你自己反复在做的一件事（记账、值守、带娃…）

「工作台」をバックオフィスと決めつけることは、このスキルで最も起こりやすい誤構築です。しかも、そうなっても見た目では気づけません。出来上がるページは、よくできていて、情報量が多く、中立的で、正しく見えるのに、製品としては間違っています。そのため、上の行は親切な設定値ではなく空欄にしています。このように意味が広すぎる語にダイヤル設定を割り当てれば、表の形をした推測になってしまうからです。

---

1. 3つのダイヤル

Design Read に基づいて、これらを明示的に設定します。これらが以降のすべてを左右します。

ダイヤル	1–3	4–6	7–10
SOUL — 個性の主張やブランドらしさの強さ	中立、安全、システムのデフォルト	明確な雰囲気	唯一無二で、ひと目でわかるアイデンティティ
SPECTACLE — ビジュアルエンジンの技術的な野心の高さ (finesse を象徴するダイヤル)	静的＋CSS のみ	GSAP スクロール、Canvas 2D のアクセント	Three.js / GLSL / WebGL-FBO のヒーロー、ジェネレーティブ表現、スクロールに固定されたシネマティックな演出
DENSITY — ビューポートあたりの情報量	余白多め、1画面につき1つのアイデア	バランス重視	エディトリアル、データ豊富

1.A ダイヤルの推定（Design Read → 値）

• 天文学／音楽／ゲーム／暗号資産／ファッションテック → SPECTACLE 7–10（このジャンルでは本格的なエンジンが活きます）。
• 法律／金融／ヘルスケア／B2B SaaS のマーケティング → SPECTACLE 3–5（派手さより巧みさを重視し、控えめなモーション演出を1つだけ取り入れます）。
• ヘリテージ／高級／エディトリアル／出版 → SOUL 8–10、SPECTACLE 4–6（WebGL ではなく、書体と基盤がデザインを支えます）。
• あらゆるプロダクトのレジスター（ダッシュボード／管理／分析／アプリ）→ SPECTACLE 1–4、DENSITY 6–9 — 派手さより明快さを優先します。§2／§4 は飛ばして references/product-ui.md に進んでください。
• h5 → ダイヤルは業界ではなく形態に沿って設定します（§0.E の h5 の行を参照）。ここでは SPECTACLE の活用方法が大きく異なります。ヒーローエンジンはなく、予算は WebGL キャンバスではなく、トランジションと演出要素（FLIP ズーム、扇状に広がるカードスタック、シーンのクロスフェード）に使います。SPECTACLE が 8 の H5 ページは、状態間の移動が目を見張るページです。§4 のエンジン表は、ほとんど当てはまりません。

1.B 「掲げたスペクタクルを、実際に見せる」（必須）

SPECTACLE ≥ 7 の場合、ページには実際に動作するビジュアルエンジン（本物の Three.js／Canvas／GLSL／スクロール固定型の演出）が必ず含まれていなければなりません。適切に劣化し、中程度の性能のデバイスで 60fps を維持する必要があります。SPECTACLE 8 を掲げながらグラデーションの塊を出荷するページは破綻しています。スコープ内で動作するスペクタクルを実装できない場合は、ダイヤルを 4 に下げ、静的でも妥協のない完成度のページを出荷してください。カクついたり、途中で途切れたりするエンジンを中途半端に作ってはいけません。

---

2. ソウルを選ぶ（業界 → ペルソナ）・ブランド表現

プロダクト表現： ソウルは今も重要です（ブランドのアクセント、ひとつのタイポグラフィ体系、基盤）。ただし、以下の演出重視のペルソナは使わず、references/product-ui.md を参照してください。§2 と §4 の残りはブランド向けです。

finesse の役割はソウルの多様性です。同じ手法から、ブリーフごとに見た目が互いに無関係なページを生み出す必要があります。

ソウルは組み立てるものであり、リストから選ぶものではありません。 10 種類のペルソナを並べた表からは 10 種類のページしか生まれません。モデルに 10 個の選択肢から選ばせても、見た頻度が最も高いものに重みづけされ、いつも同じ 2、3 種類に落ち着きます。解決策は references/divergence.md §3 にあります。直交する 5 つの軸――パレット構成・タイポグラフィの関係性・支配的なレイアウトの系統・エンジン・素材／メタファー――それぞれから値を 1 つ選び、組み合わせをソウルにします。各軸に少数の値を設けた 5 つの軸からは、10 種類ではなく数千通りの組み合わせが生まれます。以下のペルソナ表は、すでに検証済みの組み合わせです。これは調整用であり、投票用ではありません。

references/style-personas.md の業界→ペルソナ対応表（パレットの系統、タイポグラフィの組み合わせ、ヒーロー演出の適合性、シグネチャーエフェクト）を参照してください。実現できなければならない幅の例を示します。

• シネマティック・テック（シアン／マゼンタ、Inter + JetBrains Mono、Three.js パーティクル）— 天文学、AI、暗号資産。
• 蛍光体ターミナル（ネオングリーン 1 色、モノスペース中心、Canvas データビジュアライゼーション）— クオンツ／フィンテック、セキュリティ。
• エディトリアル・パブリケーション（クリーム／インク、Playfair + Spectral、GSAP のスクロール表示、グレースケール写真）— 雑誌、映画、ジャーナル。
• 温かみのあるヘリテージ（アンバー／カッパー／エンバー、Fraunces／EB Garamond、Canvas の炎／パーティクル）— ウイスキー、コーヒー、クラフト。
• ブルータリスト・タイポグラフィ（ボーン／ブラック＋鮮やかなアクセント 1 色、Anton／Bebas、mix-blend-mode）— ファッションウィーク、音楽、カルチャー。
• 静謐なラグジュアリー・ミニマル（オフホワイト／フォレスト、Raleway 100–900、CSS のみのマスク／パララックス）— 建築、ホテル、フレグランス。

ルール：

• 1 ページにつきソウルは 1 つ。 温色系と寒色系のグレーを行き来したり、スクロール中にアクセントカラーを切り替えたりしないでください。固定してください（§3 のカラー固定を参照）。
• ローテーションし、繰り返さない――しかも実行可能にすること。 「直前のブリーフで使った系統は再利用しない」というルールは、セッションをまたいで記憶できないため、従えません。記憶がないからです。 これまで一度も機能していません。実効性を持たせてください。references/divergence.md §4 に使用済みリスト（直近 N 件の制作における軸の座標をまとめた表）を残し、選定前に必ず読み、新しいページは 5 つの軸のうち 3 つ以上で異なるようにします。よく使われる系統（エディトリアル・タイポグラフィ、ベージュ／ブラスのクラフト、AI の紫色のグロー）は、デフォルトとしては禁止です。選ぶなら理由を示し、そうでなければ避けてください（references/anti-cheap.md）。
• 意志ではなく、サイコロで決着をつけること。 2 つの方向性が同じくらい妥当な場合、モデルは気づかないまま、より見慣れた方を選びます。サイコロを振って決めてください（divergence.md §6）。振った結果を覆す場合は、その理由を書き残してください。検証されていないデフォルトこそが、問題の根本です。

ペルソナを選んだら、references/inspiration-catalog.md にペルソナごとの実在ページの例がさらに多数掲載されています（examples/ の 5 件に加えて 48 件）。手法についてのメモであり、ファイルではありません。ペルソナ表にある説明 1 件以外にも参考にしたい場合に使ってください。

---

3. プレミアムな基盤（高級感が生まれる理由）

安っぽいページと高級感のあるページの違いは、ほとんどの場合、薄い物理レイヤーを一貫して適用しているかどうかです。詳しいレシピと正確な値は references/design-dna.md を参照してください。以下の必須事項は、ブランドの基盤となるものです。

適用範囲について。 最後の3項目、つまり 半透明の境界線、純粋な #fff／#000 を使わない、色の統一は、プロダクト／ダッシュボードにも適用される 普遍的な最低品質基準 です。最初の4項目、つまり グレイン、ビネット、clamp() によるタイポグラフィの緊張感、レイヤー化されたヒーローの z-indexは、ブランド専用です。ダッシュボードでは、references/product-ui.md §0 のプロダクト基盤（プレミアムなサーフェス／カード、KPI タイル、固定のタイプスケール、フィードバックモーション）に置き換えます。ダッシュボードにブランド用のグレイン／ビネット／巨大な文字を適用しないでください。

• グレイン — opacity .025–.05 の固定 SVG feTurbulence ノイズレイヤーです。静的ですが、平板な「ベクターの粗雑さ」をなくします。（明るいページにも使いますが、不透明度は低くします。）
• ビネット — 暗いヒーローに放射状グラデーションの暗がりを加え、視覚的な焦点を作ります。
• タイポグラフィの緊張感 — 見出しには負のトラッキング（-.02 to -.045em）と line-height .86–.95 を指定した clamp() の表示サイズを使い、明るい本文とのウェイトに極端なコントラストを付けます（例：本文が 300 に対して見出しは 900）。タイトで、大きく、自信に満ちた印象にします。
  • 条件付き — 全大文字の表示文字は例外であり、珍しいケースではありません。 .86–.95 が適切なのは、g、y、p のようなディセンダーが連続する行を隔てる混在大小文字の場合です。全大文字にはディセンダーがありません。大文字の上端は行ボックスの上端に揃うため、.86 では2行目の大文字が1行目のベースラインやコンマにぶつかり、2行がひとつのインクの帯に融合します。横幅の広い画面では見出しが1行に収まり、問題は見えませんが、スマートフォンでは折り返され、衝突は避けられません。 §2 のブルータリストなタイポグラフィの書体（Anton、Bebas）は、エムボックスに対する大文字の高さが最も高いため、特に影響を受けます。したがって、表示文字に text-transform: uppercase を指定する場合は、line-height の**下限を 1.0、推奨値を 1.02–1.08**にしてください。行送りを広げるか、全大文字をやめてください。どちらか一方です。.98 で妥協しないでください。詳しい理由は references/mobile-floor.md M6 を参照してください。
• レイヤー化された z-index — エンジン（0） · グレイン（1） · ビネット · コンテンツ（5）。平板さではなく、奥行きを生み出します。
• 半透明の境界線 — 暗い背景には rgba(255,255,255,.07–.22)、明るい背景には rgba(0,0,0,.06–.08) を使います。#333 のようなくっきりした線は使いません。
• 純粋な #fff／#000 は使わないでください。 すべてのニュートラルカラーに、ブランドカラーの色相を少し加えます。
• 色の統一（必須）： アクセントカラーを決めたら、ページ全体でその色に統一します。ローズカラーのページに予期せぬティールのバッジを置いてはいけません。公開前にすべてのコンポーネントを確認してください。依頼内容が、ひとつの固定パレットではなく切り替え可能な複数テーマの体験を求めている場合は、references/theming.md を参照してください。そこにあるトークンの役割やハードコードされた色の落とし穴は、単一パレットでの構築とは異なります。

パレットの検討では、出力に16進数を使う場合でも、内部ではOKLCHで考えてください（知覚上の一貫性があり、明暗の組み合わせも容易です）。明るいテーマと暗いテーマをあわせてデザインし、それぞれのコントラストを確認してください。単に反転するだけではいけません。

---

4. ヒーローエンジン（finesse の差別化要素）・ブランド向け

プロダクト向けの基準： ヒーローエンジンは使わず、データビジュアライゼーションとコンポーネントシステムを使用してください（references/product-ui.md）。このセクションはブランド向けです。

finesse のページは、1つの技術的に見事な演出でその名にふさわしいものになります。通常はヒーローです。5つではなく、1つを100％の完成度に仕上げます。ブランドの個性に合ったエンジンを選んでください。完全なマウント／レンダリング／スクロールの骨組みと、モーション軽減時のフォールバックは references/hero-engines.md にあります。

この表を見る前に references/motion.md を読んでください。 この5つのエンジンは6つのアプローチのうち負荷が高いものです。以下の表は「どのエンジンを使うか」に答え、このファイルは「そもそもこのページにエンジンが必要か」に答えます。多くの場合、答えは「いいえ」です。エフェクトからアプローチを引く対応表では、モーションに関する依頼の大半を、CSS、ネイティブのスクロール駆動アニメーション、または View Transitions に振り分けられます。バンドルサイズは増えません。また、ビートシートでは、ページの残り4分の3を扱います。このセクションには、これまでそこを表現する語彙がありませんでした。ページあたりの重い演出は1つまでという原則は変わりません。motion.md §4 の予算として、そのルールはそのまま維持されます。変わるのは、ページの残りがフェードアップ一辺倒ではなくなることです。

エンジン	使用する場面	コスト
Three.js + GLSL	3D の奥行き、パーティクルシステム（銀河、ネットワーク、DNA）、メタボール、ブルーム	高負荷。three を遅延読み込みし、SPECTACLE ≥ 7 の場合に有効化
Canvas 2D	パーティクル、フィールド、リアルタイムデータ（ローソク足、波形、炎）、フロー	軽量。高解像度ディスプレイ向けに DPR を調整
WebGL FBO shader	流体（ナビエ–ストークス）、反応拡散、レイマーチング、玉虫色の表現	高負荷。全画面クワッドを1つ使用し、マルチパスで処理
GSAP ScrollTrigger	スクロール固定型のストーリー、水平パン、視差、順次表示	中程度。最も再利用しやすい単一のエンジン
CSS-only	二層マスク、3D トランスフォーム、可変フォントのモーフィング、スクロール駆動の animation-timeline	無料。JavaScript 不要で、パフォーマンスも最良

コンポーネント単位の3D ≠ ヒーローエンジン。 上の表は、全画面表示のヒーロー演出1つを対象としています。ページ内で再利用できる 3D、たとえばポインターに合わせて傾くカード、フリップカード、カバーフロー、奥行きのある視差レイヤー、Three.js の製品／モデルビューアーには、references/3d-effects.md（depth コマンド）を使用してください。デフォルトでは CSS の階層を選んでください。どのページにもコストゼロで組み込め、動作がぎくしゃくすることもほとんどありません。1ページあたり3Dの演出は1つまでという原則は同じです。ヒーローエンジンと傾斜グリッドとカバーフローを併用しないでください。

エンジンの運用ルール（必須）：

• 段階的な拡張。 エンジンを取り除いても、ページの内容が読みやすく、完全でなければなりません。エンジンは固定背景またはヒーローのアクセントとして使い、コンテンツの表示に不可欠なものにしないでください。
• 60fps を維持するか、簡素化する。 アニメーションには transform／opacity だけを使用してください。自分のマシンではなく、中程度の性能のデバイスでテストしてください。約50fpsを下回ったら、パーティクル数または解像度を下げてください。
• prefers-reduced-motion は必須です。 エンジンを静止フレームに固定するか、非表示にして構成済みの静的なヒーローを表示してください。フォールバックなしでモーションを提供してはいけません。
• 動機のあるモーションのみ。 すべての ScrollTrigger／マーキー／固定セクションには、1文で説明できる理由（階層、ストーリーテリング、フィードバック、状態）が必要です。「見栄えがよかった」は理由になりません。マーキーはページあたり最大1つです。

---

5. ページの骨組み — 1つではなく4つのブランド向け骨組み

単一の標準的なシーケンス自体が、画一化の原因になります。 すべてのブランドページが HERO → MARQUEE → MANIFESTO → GRID → CTA → FOOTER なら、色をどれほど適切に選んでも、すべてのブランドページは同じページになります。ランディングページは主張し、ポートフォリオは実績を示し、ルックブックは魅了し、スタジオサイトは実力を実演します。主張が4つ異なるのですから、構成も4つ異なります。 ページが果たすべき役割に応じて選び、その構成の中で独自性を出してください（references/divergence.md §3、軸C）。

5.A ランディング／ローンチ — 存在するものを、理解してもらう

HERO (the engine moment)  →  SPEC BAND (4-col hairline, real numbers)  →
THE ARGUMENT (exploded view · demo · full-page engine — SHOW the thing working)  →
ASYMMETRIC PRODUCT GRID (1.4fr 1fr — never 4 identical cards)  →
TECH / DEPTH (dark-panel inversion, numbered only if the numbering means something)  →
CTA (oversized)  →  FOOTER

軸となるのは論証です。分解図をスクラブできる表示、ライブコンソール、動作するデモ（page-crafting.md §5.B）などが該当します。品質を主張するだけで、決して見せないランディングページは、単なるパンフレットです。物理的な製品や階層構造のある製品なら、スクロールに合わせて分解して見せましょう。

5.B ポートフォリオ／個人 — 主役は作品であり、あなた自身ではない

INTRO (a full-bleed image or a statement — not a headshot-and-tagline)  →
THE WORK (filmstrip accordion · generative grid · list-rows with thumbnails)  →
MANIFESTO (one statement, one column)  →  CAPABILITIES (list, not cards)  →
SELECTED DETAIL (one project, deep)  →  CONTACT (oversized type)  →  FOOTER

個人サイトならではのルールで、AI が毎回間違えるものです。

• 作品を言葉より先に見せます。 最初のプロジェクトより上に「自己紹介」セクションがあると、それはポートフォリオではなく履歴書です。
• 同じ見た目のプロジェクトカードを6枚並べるのは、よくある失敗パターンです。 行単位のリスト（64px 1fr auto 90px ＋小さなサムネイル）、ホバーで展開するフィルムストリップ（page-crafting.md §3）、または生成的な分割グリッド（§8）を検討してください。レイアウト自体が、あなたがどんなデザイナーなのかを伝えるべきです。
• 「スキル」の棒グラフは使いません。 「創造性」をパーセンテージで示すのは、個人ページに載せられる要素のなかでも最も安っぽいものです。
• プロジェクト1件を深く見せるほうが、6件を浅く見せるより効果的です。

5.C ルックブック／コレクション — ムードこそがプロダクト

HERO (split: type | image, ragged)  →  BRAND STATEMENT (dark inversion, one quote, 100vh)  →
HORIZONTAL LOOKBOOK (pinned track, ragged heights, bottom-aligned)  →
MATERIALS (clip-path wipe cards)  →  COLLECTION (gap:2px grid — a spread, not a card wall)  →
ATELIER (1fr 1fr, image + CTA)  →  FOOTER

ここでは明暗の切り替えが構成の基盤となるため、背後の要素に応じて変化するナビゲーション（page-crafting.md §4 — mix-blend-mode ではなくスクロールスパイ）が必要です。密度はセクションを増やすのではなく、リズム（高さに変化をつけ、間隔を詰める）から生まれます。階層は色を増やすのではなく、3～4個のトークンによる不透明度の段階で表現します。

5.D エージェンシー／スタジオ — 能力こそがプロダクト

HERO (composition — geometric collage · type-as-image · CSS-only)  →
PROOF BAND (stats with real provenance)  →  CRAFT (split, one idea)  →
SERVICES (≤4, and they must differ from each other visually)  →
DARK INVERSION (offers · bento · a change of key)  →
TESTIMONIAL RAIL (scroll-snap, autoplay off on interaction)  →  CTA  →  FOOTER

陥りやすいのは、同じ見た目のアイコンカードを4枚並べることです。アイコン、タイトル、2行の説明を×4。これが最も分かりやすい安っぽさの兆候（anti-cheap.md）で、エージェンシーのページではよく見られます。4つのサービスを掲載する必要がある場合は、カードごとに構造を変える（幅を変える、1枚には画像を入れる、1枚には番号を付ける）か、代わりにタイポグラフィにしっかり強弱をつけた番号付きリストを使いましょう。

4つすべてに共通するルール

• ナビゲーション： 1行、≤80px。明暗のセクションが交互に現れる場合は、スクロールスパイによるクラスの切り替え（page-crafting.md §4）を使います。mix-blend-mode: difference はコントラストの高い画像の上でのみ使用します。中間調の上では濁って見えます。
• レイアウトの多様化： ひとつのレイアウト形式（3列カード、全幅の引用、画像＋テキストの分割など）を使ったら、使うのはあと1回までです。画像＋テキストのジグザグ配置は連続で最大2回までです。8つのセクションがあるページでは、4種類以上のレイアウト形式を使います。公開前に数えましょう。
• アイブロウは控えめに： 見出しの上にある、小さく大文字で文字間を広げたラベルは、AI らしさが最もよく表れる要素です。アイブロウは3セクションにつき最大1つ、つまり ≤ ceil(sections / 3) とし、感覚ではなく実際に数えてください。通常は見出しだけで十分です。
• テーマの固定： ページごとにテーマは1つにします。ただし、上記の構成で意図的に暗転させる場合（5.C、5.D）は例外です。これは構造上の演出であり、テーマのぶれではありません。
• 番号付け（01 · 02 · 03）には、題材に基づく理由が必要です。 フィルムのコマ番号、プレート番号、動作の各段階などが該当します。基本のレイアウトとして使うと、安っぽさの兆候になります。

---

6. 安っぽさのブラックリスト

完了を宣言する前に、references/anti-cheap.md と照合してください。これは、統合された安っぽさ回避リストです（AI らしさの兆候＋絶対禁止事項＋即座に却下するフォント／パレット／美的表現）。主な問題点は次のとおりです。

• コピーで装飾として使うエムダッシュ――無条件で禁止（最も頻繁に見られる兆候です）。
• グラデーションテキスト、デフォルトのグラスモーフィズム、カードの側面に付けるストライプ状のボーダー、AI 風の紫色のグロー。
• すべてのセクションに小見出しを付けること、デフォルトの構成として番号付きの 01 · 02 · 03 マーカーを使うこと。
• 同じ見た目のカードグリッド（アイコン＋タイトル＋テキストを6つ）、divで作った偽のスクリーンショット／ダッシュボード。
• 実際の出典がない偽の精密な数値（92%、4.1×）。
• 定番ジャンルのパレット（クラフト系ならベージュ＋真鍮色、AI／SaaSなら紫のグロー）――その名前を挙げ、採用しないでください。
• 検討せずにデフォルトとして選ぶ**Inter／Fraunces／Instrument Serif**――理由があって選ぶなら問題ありませんが、考えなしに選ぶのは兆候です。
• ページに実際に画像を置く枠があるのに、画像が一切ないこと――ヒーロー、ギャラリー、PDPのショット、H5のカバー／シーン、空の状態などが該当します。業界ではなく骨格を基準に判断してください。これはバグであり、ミニマリズムではありません。逆のケースも同様に問題です。ユーザーが許可していないのに画像が表示されること（asset-sourcing.md §0）。

---

7. パフォーマンスとアクセシビリティのガードレール

• transform／opacity のみをアニメーションさせてください。top/left/width/height は使わないでください。will-change は控えめに使ってください。
• prefers-reduced-motion：canvasのループを止め、グレインを固定し、静止表示に切り替えてください。アニメーションを使うすべてのページで必須です。例外はありません。装飾目的の動きも含みます。 モーションを使いながら、視差効果を抑える設定時の最終状態がないページは、不具合のある状態で公開することになります。
  • 機能検出パターン（公開可能な実装形態）： ページの先頭で検出結果を一度だけ読み取ります――const RM = matchMedia('(prefers-reduced-motion:reduce)').matches; const FINE = matchMedia('(hover:hover) and (pointer:fine)').matches;――その後、効果ごとに分岐します：if (RM) <最終状態を設定> else <アニメーション>。ポインター依存のモーション（磁石のように動くボタン、カーソル追従、ホバーで開くアコーディオン）は FINE で制御し、タッチ環境では決して発生しないようにしてください。CSSのフォールバックとして @media (prefers-reduced-motion:reduce){*{animation-duration:.01ms!important;transition-duration:.01ms!important}} も併用してください。手作業で作成するグラフ描画も、同じ方法で最終状態を実装してください（chart-crafting.md §6）。
• 色のコントラストはWCAG AAに準拠させてください：本文は4.5:1以上、大きなテキストは3:1以上。写真上のボタン（スクリーンまたはストロークを追加）、プレースホルダー、フォーカスリングも対象です。
• すべてのインタラクティブ要素に視認できるフォーカス状態を設けてください。ナビゲーションとCTAにはキーボードでアクセスできるようにしてください。
• Core Web Vitals：負荷の大きいエンジンは遅延読み込みし、モバイルでは 100vh より min-h-dvh を使い、レスポンシブ画像（WebP／AVIF）を使って、CLSを0.1未満にしてください。
• 複数カラムのセクションでは、モバイルでの折りたたみ方を明示してください。タッチターゲットは44px以上にしてください。
• h5の扱い： 以下の6つのルールは、デスクトップページをスマートフォンで問題なく表示するためのものです。スマートフォン専用ページには、references/h5-mobile.md §10 にある別のゲートリスト（ノッチ／フレーム／スクロールコンテナ／タッチ／SEの高さ／環境モーション）があります。M1／M4／M6はフレーム内でも適用されます。M2とM5はほぼ不要です（1カラム、下部バー1つ）。
• モバイルの最低基準――6つの必須ルールと詳しい理由は references/mobile-floor.md を参照してください。 デスクトップのウィンドウを見た目が崩れるまでドラッグするのではなく、320 · 375 · 414 · 768 の各幅でテストしてください。M1 html と body の両方に overflow-x: clip を指定してください。スクロールコンテナになり、すべてのsticky子要素がひそかに機能しなくなる hidden は決して使わないでください。M2 画像を含むグリッドのトラックには minmax(0,1fr) を使い、裸の 1fr は使わないでください（auto の最小値が画像本来の幅になるためです）。flexの子要素には min-width: 0 を指定してください。M3 クリック可能なテキストは、どの幅でも折り返さないようにしてください。まずラベルを短くし、それから nowrap を使ってください。M4 ディスプレイ見出しには overflow-wrap: anywhere; min-width: 0 を指定してください。M5 top: 0 に固定する要素は1つだけにしてください。それ以外は --nav-h でオフセットし、--z-nav を --z-sticky より上にしてください。M6 すべて大文字のディスプレイ書体には、line-height の下限を 1.0 に設定してください（§3を参照）。scripts/detect.mjs はM1／M2／M5／M6を機械的に検出します。M3とM4には、320pxでレンダリングしたページが必要です。

---

8. 事前チェック

「完了」と言う前に、references/preflight.md のチェックリストをすべて実行してください。基盤のチェック、低コスト性のスキャン、見せかけの主張の検証、モバイルの最低基準、アクセシビリティのゲートがまとめられています。ハードルールにひとつでも違反した場合、それは壊れた状態で出荷することになります。納品前に修正してください。

ゲート1は最初に実行し、10秒で終わります。ページは実際にレンダリングされていますか？ すべてのローカル href ／ src ／ url() が存在するファイルを参照している必要があり、検出器も見つけて実行している必要があります。これは細かいことではありません。書かれていないスタイルシートへの <link> は、ページをスタイルのないセリフ体テキストとしてレンダリングします。そして、ファイルが存在しないため、欠けている粒子も禁止対象の #fff もないことになり、ファイル内のほかのすべてのチェックを通過してしまいます。また、ビルドが途中で切れたまま出荷されるのも同じ理由です。HTMLを書き込み、CSSの前に実行が終了し、画面に表示されていないページが .finesse/log.json に忠実に記録されます。preflight.md のゲート1には、検出器の解決方法を示すスニペットがあります。検出器はユーザーのプロジェクトではなく、スキルと一緒に配置されています。そのため、skills/finesse-ui/… のようなハードコードされたパスは、ベンダーコピー以外ではどこでも気づかれないまま失敗します。

8.0 ビルドを記録する（事前チェックに合格した後、「完了」と言う前）

書き込みは2つです。約30秒で済み、次の実行で今回のビルドから切り替えられる唯一の根拠になります。

1. CSSにスタンプを記載します。 ページのスタイルシートの空でない最初の行（またはインライン <style> の先頭）に、5軸の座標を記載します。

   /* finesse · register=brand · A=mono+acid-lime · B=900/300 · C=pinned-h-track
    * D=GSAP-scrub · E=machined-metal · SOUL=8 SPECTACLE=7 DENSITY=4 */
   

   h5ビルドでは形態も追加します — register=h5 · morph=A-app-shell · …（h5-mobile.md §11）。切り替えの対象はソウル軸と形態であり、家具ではありません。どのアプリの TabBar も、ほかのアプリの TabBar と同じ見た目にする必要があります。これは divergence.md §0 でダッシュボードのナビゲーションに認めている例外と同じです。
2. .finesse/log.json に追記します — エントリーを配列の先頭に追加し、直近20件に切り詰めます。スキーマは divergence.md §4.1 にあります。ディレクトリやファイルが存在しない場合は作成してください。

コンポーネントスコープのビルドでは、これらのどちらも行いません。コンポーネント用のスタンプを使い、ログには記録しません（component-scope.md §5）。コンポーネントは切り替えません。プロジェクトのボタンは、兄弟のように見えるべきです。

8.A 納品後のイテレーションガイド

ユーザーが最初の出力を受け取った後は、そのフィードバックを適切な対象修正に対応付けます。単一の苦情に対して、最初から作り直してはいけません。原因となっている調整項目またはモジュールを特定し、そこだけを変更します。Command列には、実行するコマンドが示されています（## Commandsを参照）。ユーザーがコマンドを入力している場合は、すでに該当箇所にいます。

ユーザーの発言	コマンド	対応
「地味すぎる／退屈」	bolder	SPECTACLEを+2し、エンジンタイプのアップグレード（例：Canvas → Three.js）を検討します
「派手すぎる／圧倒される」	quieter	SPECTACLEを−2し、Engine D（GSAP）またはE（CSS-only）に簡素化または切り替えます
「雰囲気が違う／しっくりこない」	soul	references/style-personas.mdから別のペルソナを選び、§2を再実行します
「余白が多すぎる」	densify	DENSITYを+2し、コンテンツセクションを1つ追加します
「ごちゃごちゃしすぎる」	densify	DENSITYを−2し、セクションを1つ削除して、セクションのパディングを増やします
「もっと個性を／大胆に」	bolder	SOULを+2し、references/design-dna.mdでカラーの確約レベルを1段階上げます
「どこにでもあるような感じ／他のAIサイトと同じ」	diverge	ページごとの問題ではなく、システム全体の問題です。 5つの軸から魂を再構成し（divergence.md §3）、2段階のアンチデフォルトチェック（§2）を実行し、argmaxと照合し（§6）、使用済みリストを確認します（§4）。ここで soulに頼ると、同じ10行の表から別の行を選ぶだけです。それが問題であって、解決策ではありません
「作るページがどれも同じに見える」	diverge	上記と同じです。その後、使用済みリストを書き込みます（divergence.md §4）。これがないと、「繰り返さない」というルールには記録が伴わず、決して機能しません
「色を変えて」	soul	references/design-dna.mdのカラー戦略を再実行し、アクセントカラー固定のルールを維持します
「アニメーションを変えて」	animate	§4でエンジンタイプを切り替え、そのエンジンのスケルトンについてreferences/hero-engines.mdを再実行します
「奥行きを加えて／3Dにして／傾きをつけて／視差効果を加えて」	depth	references/3d-effects.mdから3D演出を1つ追加します。デフォルトではCSS層（傾き／反転／カバーフロー／奥行き視差）を使い、Three.jsは実際にレンダリングするオブジェクトがある場合に限ります
「セクションを削除して」	redesign	該当セクションを削除し、§5のレイアウトファミリーを再監査します（4種類以上が残っていることを確認します）
「動作が遅い／重い」	quieter	SPECTACLEを下げ、Engine E（CSS-only）に切り替えるか、パーティクル数／FBO解像度を下げます
「モバイルでも使えるようにして」	redesign	複数列の各セクションでモバイルレイアウトを指定し、min-h-dvhを設定して、タッチターゲットを44px以上にします
「何をしているのかわからない／ずっと回り続けて止まらない／いくらかかったのかわからない」 (AI ワークベンチ)	redesign	スタイルに関する苦情ではありません。レジスターの4つの問いに答えられていません。ai-console.mdに従い、スピナー1つではなく、各ステップの所要時間を含む実行ストリーム（§2）、9つすべての実行状態（§3）、常時表示される停止操作（§4）、レシート行と予算メーター（§6）を用意します
「チャット画面みたいで、ワークベンチらしくない」 (AI ワークベンチ)	redesign	バブルだけでは不十分です。ai-console.md §1では、キューと履歴が欠けているため、画面に現在の状態しか表示されません。見た目に手を加える前に、レール（またはスマートフォンの固定ストリップ、§9）を追加します
「ノッチに隠れる／下部バーが内容に重なる／ボタンを押せない」 (h5)	redesign	レイアウトの好みではなく、機械的な不具合です。h5-mobile.md §10のチェックを順に実施します：env()の欠落（§2.A）、#appの下部パディングの欠落（§2.C）、44px未満のタップ領域または:activeの欠落（§3）
「アプリらしくない／ウェブページみたい」 (h5)	redesign	配色ではなく、UIの備品が欠けているか、間違っています。h5-mobile.md §5に従い、ステータスバー、TabBarのアクティブ状態、ホームインジケーター、シートのつまみ、画面遷移を確認し、§9の識別ポイントも確認します
「これは良いの？／レビューして」	audit	読み取り専用です：ブラックリスト、演出の提示、事前チェックを実行し、結果を報告します

---

9. 対象外

finesse はブランド、製品、コマース、および h5 を対象としているため、その範囲は広いです。作業がインターフェースのない純粋なバックエンド／API／データのタスクの場合、または汎用的で従来的な、作り込みのないページを明示的に求める依頼（finesse は常に作り込みを加えます。本当に無難なものを求めているなら、それは別のツールの領域です）の場合に限り、引き継いでください。スペクタクルなランディングページから、情報量の多い管理ダッシュボード、スマートフォン専用の活動ページまで、すべて対象です。§0 でレジスターを設定し、それに応じて振り分けてください。

境界として明示しておくべき点が一つあります。h5 が対象とするのは、スマートフォン専用ページのデザインであり、その周辺のプラットフォーム連携ではありません。WeChat JS-SDK の接続、共有カードの設定、決済連携、アプリシェルのネイティブブリッジ、ミニプログラムのフレームワークの足場づくりは、デザインではなくエンジニアリングのタスクです。画面を作り、これらは引き継いでください。