taste-skill

Name: taste-skill
Author: huytieu

github.com/huytieuデザイン・UI1.3k120 回インストール1 週間前に更新

リポジトリ

taste-skill について

taste-skillは、ランディングページ、ポートフォリオ、リデザイン向けのフロントエンド設計スキルです。要件を読み解いてから、ビジュアルの方向性やレイアウト、モーション、実装規約を選ぶようエージェントを導きます。

主な機能

01対象者、参考、制約の推定
02変化度、モーション、密度の設定
03デザインシステムや表現手法の選択
04React、Tailwind、Motionの実装規約
05アクセシビリティとレスポンシブ設計の確認

活用シーン

01要件に沿ったランディングページの作成
02対象者に合わせたポートフォリオの調整
03ブランドを維持したサイトのリデザイン
04表現方針に合う実装パターンの選択

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/huytieu/cog-second-brain --skill taste-skill

インストール後、Claude Code で/taste-skillを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

canonical-sources.md

design-systems-install.md

liquid-glass.md

motion-skeletons.md

pattern-vocabulary.md

詳細

tasteskill：アンチスロップ・フロントエンドスキル

ランディングページ、ポートフォリオ、リデザイン向けです。ダッシュボード、データテーブル、複数ステップのプロダクト UI 向けではありません。以下のルールはすべて状況に応じて適用します。自動で適用されるものはありません。まず依頼内容を読み、合うものだけを取り入れてください。

0. 依頼内容の読み取り（まず状況を見極める）

コードに触れたり、設定を調整したりする前に、ユーザーが本当に求めているものを推測してください。LLM によるデザインの成果物の多くがよくないのは、状況を読み取らずに、モデルが既定の美的感覚に飛びつくからです。

0.A まず次のシグナルを読み取る

ページの種類 - ランディングページ（SaaS／消費者向け／エージェンシー／イベント）、ポートフォリオ（開発者／デザイナー／クリエイティブスタジオ）、リデザイン（既存のデザインを維持するか、刷新するか）、エディトリアル／ブログ。
ユーザーが使った雰囲気を表す言葉 - 「ミニマル」「落ち着いた」「Linear 風」「Awwwards」「ブルータリスト」「プレミアムな消費者向け」「Apple 風」「遊び心のある」「真面目な B2B」「エディトリアル」「エージェンシー風」「ガラスのような」「ダークテック」。
参考資料のシグナル - ユーザーがリンクした URL、貼り付けたスクリーンショット、名前を挙げたプロダクト、競合するブランド。
対象ユーザー - B2B の調達担当者パネルか、デザインにこだわる消費者か、ポートフォリオを確認する採用担当者か。美的感覚を決めるのはあなたの好みではなく、対象ユーザーです。
既存のブランドアセット - ロゴ、色、書体、写真。リデザインの場合、これらは出発点であり、任意の入力ではありません（セクション 11 を参照）。
明示されていない制約 - アクセシビリティを最優先する対象ユーザー、公共部門、規制対象業界、信頼を重視するコマース、子ども向けプロダクト。こうした制約は美的な好みよりも優先されます。

0.B 生成前に「デザインの読み取り」を一文で出力する

コードを書く前に、一文で次のように述べてください：「次のように読み取りました：<page kind> を <audience> 向けに作成し、<vibe> な表現で、<design system or aesthetic family> 寄りにします。」

読み取り例：

「次のように読み取りました：技術系の購入者向け B2B SaaS ランディングページで、Linear 風のミニマルな表現を取り入れ、Tailwind ユーティリティ + Geist + 控えめなモーションを採用します。」
「次のように読み取りました：採用担当者向けの個人デザイナーポートフォリオで、エディトリアル／動的なタイポグラフィ表現を取り入れ、ネイティブ CSS + スクロール駆動アニメーション + カスタムタイポグラフィを採用します。」
「次のように読み取りました：公共サービスサイトのリデザインで、信頼を最優先する表現を取り入れ、GOV.UK Frontend または USWDS を採用します。」

0.C 依頼内容が曖昧なら、推測せず質問を一つだけする

確認の質問は必ず一つだけにしてください。複数の質問をまとめて投げてはいけません。また、デザインの読み取りが本当に分かれる場合にのみ質問してください。例：「Linear のようなクリーンな雰囲気と、Awwwards のような実験的な雰囲気では、どちらに近づけますか？」

文脈から自信を持って推測できるなら、質問しないでください。デザインの読み取りを明示して、そのまま進めてください。

0.D 既定のデザインを避ける

次のものを既定で使わないでください：AI 風の紫色グラデーション、暗いメッシュ背景上の中央揃えヒーロー、均等なサイズの機能カード 3 枚、あらゆる場所で使う汎用的なグラスモーフィズム、どこまでも続くマイクロアニメーション、Inter + slate-900。これらは LLM の定番です。デザインの読み取りに基づき、意識して定番の先を目指してください。

1. 3 つのダイヤル（コア設定）

デザインの読み取りの後、3 つのダイヤルを設定してください。以下のレイアウト、モーション、密度に関する判断は、すべてこれらの設定に従います。

DESIGN_VARIANCE: 8 - 1 = 完全な対称性、10 = 芸術的なカオス
MOTION_INTENSITY: 6 - 1 = 静的、10 = シネマティック／物理的
VISUAL_DENSITY: 4 - 1 = アートギャラリー／ゆったり、10 = コックピット／データ満載

基準値： 8 / 6 / 4。デザインの読み取りによる上書きがない限り、これを使ってください。このファイルを編集するようユーザーに頼んではいけません。上書きは会話の中で行います。

1.A ダイヤルの推論（デザインの読み取り → ダイヤルの値）

シグナル	VARIANCE	MOTION	DENSITY
「ミニマリスト / クリーン / 落ち着き / エディトリアル / Linear 風」	5-6	3-4	2-3
「プレミアム消費者向け / Apple っぽい / ラグジュアリー / ブランド」	7-8	5-7	3-4
「遊び心 / ワイルド / Dribbble / Awwwards / 実験的 / エージェンシー」	9-10	8-10	3-4
「ランディングページ / ポートフォリオ / マーケティングサイト（デフォルト）」	7-9	6-8	3-5
「信頼第一 / 公共部門 / 規制対象 / アクセシビリティ重視」	3-4	2-3	4-5
「リデザイン - 維持」	既存に合わせる	+1	既存に合わせる
「リデザイン - 大幅刷新」	+2	+2	既存に合わせる

1.B ユースケース別プリセット

ユースケース	VARIANCE	MOTION	DENSITY
ランディング（SaaS、一般向け）	7	6	4
ランディング（エージェンシー / クリエイティブ）	9	8	3
ランディング（プレミアム消費者向け）	7	6	3
ポートフォリオ（デザイナー / スタジオ）	8	7	3
ポートフォリオ（開発者）	6	5	4
エディトリアル / ブログ	6	4	3
公共部門のサービス	3	2	5
リデザイン - 維持	既存に合わせる	既存+1	既存に合わせる
リデザイン - 大幅刷新	+2	+2	既存に合わせる

1.C ダイヤルがアウトプットをどう左右するか

これら（またはユーザーが上書きした値）をグローバル変数として使用します。本書全体を通じた相互参照は、これらの正確な変数名を指します。LAYOUT_VARIANCE や ANIM_LEVEL のような別名を勝手に作らないでください。

2. ブリーフ → デザインシステムのマッピング

デザインの読み取り（セクション 0）とダイヤル（セクション 1）ができたら、適切な基盤を選びます。公式パッケージが存在するものに対して独自の CSS を発明しないでください。美的トレンドを公式システムであるかのように装わないでください。

2.A 実際のデザインシステムに手を伸ばすべきとき（公式パッケージを使用する）

ブリーフがこう読めるなら…	これを使う	理由
Microsoft / エンタープライズ SaaS / ダッシュボード	`@fluentui/react-components` または `@fluentui/web-components`	公式 Fluent UI、Microsoft のトークン、アクセシビリティ対応済み
Google っぽい UI、Material 風のプロダクト	`@material/web` + Material 3 トークン	公式、Material Theming でテーマ化可能
IBM 風の B2B / エンタープライズ分析	`@carbon/react` + `@carbon/styles`	公式 Carbon、成熟したデータ密度パターン
Shopify アプリの画面	`polaris.js` Web Components / Polaris React	Shopify 管理 UI では必須
Atlassian / Jira 風のプロダクト	`@atlaskit/*` + `@atlaskit/tokens`	公式 Atlassian DS
GitHub 風の開発ツール / コミュニティページ	`@primer/css` または `@primer/react-brand`	公式 Primer。マーケティングには Brand バリアント
英国公共部門のサービス	`govuk-frontend`	法的・規制的に期待される
米国公共部門 / 信頼第一	`uswds`	同上
スピード重視の地元ビジネス / エージェンシー MVP	Bootstrap 5.3	地味だが速く、動く
モダンでアクセシブルな React 基盤	`@radix-ui/themes`	プリミティブ + 洗練されたテーマ
コンポーネントを自社で所有するモダン SaaS	shadcn/ui（`npx shadcn@latest add ...`）	コードを自分で所有し、カスタマイズが容易。デフォルト状態のまま出荷しないこと
Tailwind ベースのモダン SaaS / AI マーケティング	Tailwind v4 ユーティリティ + `dark:` バリアント	インディー + 小規模チームのビルドのデフォルト

誠実さのルール: ブリーフが上記のいずれかのシステムとして読めるなら、公式パッケージをインストールして使用してください。その CSS を手作業で再現しないでください。あるシステムのトークンをインポートしておきながら、その 90% を上書きしないでください。

1 プロジェクトにつき 1 システム。 同じツリー内で Fluent React と Carbon を混在させないでください。Material 3 アプリに shadcn/ui コンポーネントをインポートしないでください。

2.B ブリーフがシステムではなく、ビジュアルスタイルを指定している場合

これらの方向性には、公式パッケージが一つに定まっているわけではありません。ネイティブ CSS ＋ Tailwind ＋メンテナンスされているコンポーネントライブラリを使って構築してください。コードコメントでは、借用したインスピレーションと公式素材を明確に区別してください。

ビジュアルスタイル	正直な実装方法
グラスモーフィズム／「すりガラス」	`backdrop-filter`、レイヤー状のボーダー、ハイライトオーバーレイを使用します。`prefers-reduced-transparency` 用に単色塗りつぶしのフォールバックを用意してください。
ベントー（Apple 風タイルグリッド）	セルサイズを変えた CSS Grid を使用します。これを所有する単一のライブラリはありません。
ブルータリズム	ネイティブ CSS、等幅フォント、装飾のないボーダーを使用します。ライブラリはありません。
エディトリアル／雑誌風	セリフ体、非対称グリッド、ゆとりのある余白を使用します。ライブラリはありません。
ダークテック／ハッカー風	等幅フォントとアクセントカラーのネオン、ターミナルのモチーフを使用します。ライブラリはありません。
オーロラ／メッシュグラデーション	SVG または重ねた放射状グラデーションを使用します。ライブラリはありません。
キネティックタイポグラフィ	ネイティブ CSS アニメーション、スクロール駆動アニメーション、スクロールを乗っ取る場合は GSAP を使用します。ライブラリはありません。
Apple Liquid Glass	Apple はこれを Apple プラットフォーム向けにのみ公開しています。公式の `liquid-glass.css` はありません。 Web 向けの実装は、`backdrop-filter` ＋レイヤー状のボーダー＋ハイライトを使った近似表現です。近似表現であることを明確に示してください。

3. デフォルトのアーキテクチャと規約

デザインの分析で実在するデザインシステムが選ばれていない場合（セクション 2.A）、以下をデフォルトとします。

3.A スタック

フレームワーク： React または Next.js。デフォルトでは Server Components（RSC）を使用します。
- RSC の安全性： グローバル状態が機能するのは Client Components のみです。Next.js では、プロバイダーを "use client" コンポーネントでラップしてください。
- インタラクティビティの分離： Motion、スクロールリスナー、またはポインターの物理演算を使用するコンポーネントは、必ず独立したリーフコンポーネントとし、先頭に 'use client' を指定してください。Server Components では静的なレイアウトのみをレンダリングします。
スタイリング： Tailwind v4（デフォルト）。既存プロジェクトで必要な場合に限り、Tailwind v3 を使用します。
- v4 の場合、postcss.config.js で tailwindcss プラグインを使用しないでください。@tailwindcss/postcss または Vite プラグインを使用します。
アニメーション： Motion（旧 Framer Motion ライブラリ）。motion/react からインポートします（import { motion } from "motion/react"）。framer-motion パッケージはレガシーエイリアスとして引き続き動作しますが、新しいコードでは motion/react を優先してください。
フォント： 必ず next/font（Next.js）を使用するか、@font-face ＋ font-display: swap でセルフホストしてください。本番環境では Google Fonts を <link> で読み込まないでください。

3.B 状態

分離された UI にはローカルの useState／useReducer を使用します。
グローバル状態は、深い階層にわたる props の受け渡しを避ける場合に限り使用します（Zustand、Jotai、または React context）。
連続的に変化する値を、ユーザー入力に応じて追跡するために useState を使用しないでください（マウス位置、スクロールの進行状況、ポインターの物理演算、磁石のようなホバー効果など）。Motion の useMotionValue／useTransform／useScroll を使用してください。useState は変更のたびに React ツリーを再レンダリングし、モバイルでは処理が破綻します。

3.C アイコン

使用可能なライブラリ（優先順）： @phosphor-icons/react、hugeicons-react、@radix-ui/react-icons、@tabler/icons-react。
非推奨： lucide-react。ユーザーが明示的に指定した場合、またはプロジェクトがすでに依存している場合に限り使用できます。
SVG アイコンを自作しないでください。 必要なグリフがない場合は、別のライブラリを追加するか、プリミティブを組み合わせてください。アイコンのパスを一から描画しないでください。
プロジェクト内で使うアイコンファミリーは一つに統一します。 同じコンポーネントツリー内で Phosphor と Lucide を混在させないでください。
strokeWidth を全体で統一します（例：1.5 または 2.0）。

3.D 絵文字の方針

コード、マークアップ、表示テキストでは、デフォルトで絵文字の使用を避けてください。記号はアイコンライブラリのグリフに置き換えます。例外： ユーザーが遊び心のある雰囲気、チャット風の雰囲気、またはソーシャルメディアに馴染む雰囲気を明示的に求めた場合に限り、絵文字を使用できます。その場合でも、意図を持って控えめに使用してください。

3.E レスポンシブ対応とレイアウトの仕組み

ブレークポイントを標準化します（sm 640、md 768、lg 1024、xl 1280、2xl 1536）。
max-w-[1400px] mx-auto または max-w-7xl を使ってページレイアウトをコンテナ内に収めます。
ビューポートの安定性： 高さが画面全体に及ぶヒーローセクションに h-screen は絶対に使わないでください。モバイル（iOS Safari のアドレスバー）でレイアウトが跳ねるのを防ぐため、必ず min-h-[100dvh] を使ってください。
Flex の計算より Grid： 複雑な Flexbox のパーセンテージ計算（w-[calc(33%-1rem)]）は絶対に使わないでください。必ず CSS Grid（grid grid-cols-1 md:grid-cols-3 gap-6）を使ってください。

3.F 依存関係の確認（必須）

サードパーティライブラリをインポートする前に、必ず package.json を確認してください。パッケージが見つからない場合は、最初にインストールコマンドを出力してください。ライブラリが存在すると決して決めつけないでください。

4. デザインエンジニアリング指針（バイアスの補正）

LLM はありきたりな表現に偏りがちです。こうした傾向をあらかじめ上書きしてください。各ルールには、状況に応じた例外条件があります。

4.1 タイポグラフィ

ディスプレイ／見出し： デフォルトは text-4xl md:text-6xl tracking-tighter leading-none です。
本文／段落： デフォルトは text-base text-gray-600 leading-relaxed max-w-[65ch] です。
サンセリフフォントの選択：
- デフォルトでは非推奨： Inter。まずは Geist、Outfit、Cabinet Grotesk、Satoshi、またはブランドに適したセリフ体を選んでください。
- 例外： ユーザーがニュートラル／標準的／Linear 風の印象を明示的に希望する場合、または公共機関向け／アクセシビリティ優先のサイトである場合は、Inter を使用できます。
おすすめの組み合わせ： Geist + Geist Mono、Satoshi + JetBrains Mono、Cabinet Grotesk + Inter Tight、GT America + IBM Plex Mono。
セリフ体の使用ルール（デフォルトでは非常に非推奨）：
- セリフ体は、どのプロジェクトでもデフォルトのフォントとして使うことは非常に非推奨です。 「クリエイティブ／プレミアム／エディトリアルな印象になる」は、セリフ体を選ぶ理由にはなりません。「クリエイティブなブリーフ＝セリフ体」というエージェントの既定の考え方は、本番ラウンドで最も頻繁に見られる AI らしさの兆候です。
- セリフ体が許容されるのは、次のいずれかが明示的に当てはまる場合のみです：
  - ブランドのブリーフにセリフ体のフォント名が明記されている、または
  - 美的な方向性が真にエディトリアル／ラグジュアリー／出版物／写本／ヘリテージ／ヴィンテージに当てはまり、かつ、なぜこのセリフ体がこのブランドに適しているのかを説明できる
- それ以外（クリエイティブエージェンシー、デザインスタジオ、モダンなブランド、プレミアムな消費者向けブランド、ポートフォリオ、ライフスタイル）では、デフォルトとしてサンセリフのディスプレイフォント（Geist Display、ABC Diatype、Söhne Breit、Cabinet Grotesk Display、Migra Sans、GT Walsheim、Inter Display、PP Neue Montreal）を使用してください。サンセリフのディスプレイフォントは「退屈」ではありません。ファッションで黒がデフォルトであるのと同じ理由で、これがデフォルトです。
- 強調ルール（関連事項）： 見出しの中の単語を強調したい場合（「and spatial design」のような動きのある表現）は、同じフォントのイタリック体または太字を使ってください。視覚的な面白さを加えるためだけに、サンセリフの見出しに無関係なセリフ体の単語を混ぜたり（またはその逆をしたり）しないでください。異なるフォントファミリーを混ぜた強調は素人っぽくなります。同じファミリー内でイタリック体または太字を使うのが正しい方法です。
- デフォルトとして明確に禁止： Fraunces と Instrument_Serif（LLM が好みがちな 2 つのディスプレイ用セリフ体）。
- セリフ体の使用が妥当な場合（上記のとおり、まれです）は、この候補から選び、連続するプロジェクトで同じセリフ体を使い回さないでください：PP Editorial New、GT Sectra Display、Cardinal Grotesque、Reckless Neue、Tiempos Headline、Recoleta、Cormorant Garamond、Playfair Display、EB Garamond、IvyPresto、Migra、Editorial Old、Saol Display、Söhne Breit Kursiv、Domaine Display、Canela、Schnyder、Tobias、NB Architekt、ITC Galliard。
イタリック体のディセンダー用余白（必須）： ディスプレイ文字でイタリック体を使い、単語にディセンダー文字（y g j p q）が含まれる場合、leading-[1] または leading-none ではディセンダーが切れてしまいます。最低でも leading-[1.1] を使い、親要素に pb-1 または mb-1 を加えて余白を確保してください。リリース前に、ディスプレイ見出し内のイタリック体の単語をすべて確認してください。

4.2 色の調整

アクセントカラーは最大1色です。デフォルトでは彩度を80％未満にします。
LILA ルール： デフォルトの美学として、「AI パープル／ブルーの輝き」は推奨されません。ボタンに自動で紫の光彩を付けたり、無作為にネオンのグラデーションを使ったりしないでください。ニュートラルなベースカラー（Zinc／Slate／Stone）に、コントラストの高い単色のアクセント（エメラルド、エレクトリックブルー、ディープローズ、バーントオレンジなど）を組み合わせてください。
例外： ブランドやブリーフで紫／バイオレット／ライラックが明示的に求められている場合は、積極的に取り入れてください。ただし、意図を持って仕上げてください。一貫性のあるパレット、調和の取れたニュートラルカラー、控えめなグラデーションを用います。ありきたりな AI 風グラデーションの乱用は避けてください。
プロジェクトごとにパレットは1つです。 同じプロジェクト内で、暖色系と寒色系のグレーを切り替えないでください。
色の一貫性ロック（必須）： ページのアクセントカラーを決めたら、ページ全体でその色を使用してください。暖色系グレーのサイトで、セクション7だけ青い CTA を突然使うことは避けてください。ローズをアクセントにしたサイトのフッターに、ティールのステータスバッジを置くことも避けてください。アクセントカラーを1色選んで固定し、リリース前にすべてのコンポーネントを確認してください。
プレミアム消費者向けパレットの禁止（必須、AI らしさが表れる頻度が2番目に高い要因）：
- プレミアム消費者向けのブリーフ（調理器具、ウェルネス、職人技、高級品、伝統工芸、DTC 家庭用品など）では、LLM がデフォルトで選びがちな組み合わせは 暖色系のベージュ／クリーム＋真鍮／粘土／オックスブラッド／オークル＋エスプレッソ／インク色の濃い文字色です。具体的には、デフォルトの背景色およびアクセントカラーとして、以下の16進カラーの系統を禁止します。
  - 背景色：#f5f1ea、#f7f5f1、#fbf8f1、#efeae0、#ece6db、#faf7f1、#e8dfcb（いずれも「暖かな紙／クリーム／チョーク／ボーン」）
  - アクセントカラー：#b08947、#b6553a、#9a2436、#9c6e2a、#bc7c3a、#7d5621（いずれも「真鍮／粘土／オックスブラッド／オークル」）
  - 文字色：#1a1714、#1a1814、#1b1814（いずれも「エスプレッソ／暖色系のほぼ黒」）
- このパレットをプレミアム消費者向けブリーフのデフォルトとして選ぶことは禁止です。これまでにリリースしたプレミアム消費者向けサイトは、どれもこのパレットを使っています。その結果、ブランドの個性が見えなくなります。
- デフォルトの代替案（ローテーションして、使い回さないでください）：
  - コールドラグジュアリー： シルバーグレー＋クローム＋スモーク（Tesla、レザーを使わない Apple Watch Hermès をイメージ）
  - フォレスト： 深いグリーン＋ボーン＋アンバーのアクセント（Filson、Patagonia のプレミアムラインをイメージ）
  - ブラック＆タン： 純粋なオフブラック＋暖色系のタン、強いコントラスト、ベージュは使わない
  - コバルト＋クリーム： 真鍮は使わず、単色のニュートラルカラーに鮮やかなブルーを合わせる
  - テラコッタ＋スレート： 真鍮は使わず、暖色系の錆色を寒色系のグレーに合わせる
  - オリーブ＋レンガ＋紙： 彩度を抑えたオリーブにレンガ色のアクセントを合わせる
  - 純粋なモノクロ＋鮮やかな色を1色： オフホワイト＋オフブラック＋明るいアクセントを1色（エレクトリックブルー、エメラルド、ホットピンクなど）
- パレットローテーションのルール： 直前に生成したプレミアム消費者向けプロジェクトでベージュ＋真鍮系のパレットを使った場合、このプロジェクトでは必ず別の系統を使ってください。同じ暖色系のクラフトパレットを2回続けてリリースしないでください。
- 例外： ベージュ＋真鍮＋エスプレッソのパレットを使用できるのは、ブランドブリーフでそれらの色が明示されている場合、またはブランドのアイデンティティが真にヴィンテージ／職人技／暖かなクラフト調であり、この特定のパレットがこの特定のブランドに合う理由を説明できる場合に限ります。「調理器具のブリーフだから」という理由でデフォルトとして選ぶことは禁止です。

4.3 レイアウトの多様化

中央配置への偏りを避ける： DESIGN_VARIANCE > 4 の場合、中央揃えのヒーロー／H1 セクションは避けてください。「画面を左右に分割」（50/50）、「左揃えのコンテンツ／右揃えのアセット」、「非対称な余白」、またはスクロール固定型の構成を採用してください。
例外： メッセージそのものがデザインとなる、エディトリアル／マニフェスト／ローンチ告知のブリーフでは、中央揃えのヒーローを使ってもかまいません。

4.4 マテリアリティ、シャドウ、カード

カードを使うのは、エレベーションが実際の階層を伝える場合に限ります。それ以外の場合は、border-t、divide-y、または余白でグループ化します。
シャドウを使う場合は、背景の色相に合わせて色味を付けます。明るい背景に純粋な黒のドロップシャドウを使ってはいけません。
VISUAL_DENSITY > 7 の場合、汎用的なカードコンテナは禁止です。データ指標は装飾のないレイアウトで、ゆとりを持たせます。
形状の一貫性を保つ（必須）： ページ全体で使う角丸のスケールを1つ選び、統一します。選択肢は、すべて角張った形状（半径0）、すべて柔らかい形状（12～16px）、すべてピル型（インタラクティブ要素は完全な丸み）です。文書化されたルール（例：「ボタンは完全なピル型、カードは16px、入力欄は8px」）があり、そのルールを全体で守る場合に限り、異なる形状を組み合わせてもかまいません。四角いレイアウトに丸いボタンを置いたり、ピル型ボタンのページに四角いカードを置いたりするのは、デザインの破綻です。

4.5 インタラクティブ UI の状態

LLM は「成功した静的状態のみ」に偏りがちです。常に一連の状態をすべて実装します。

読み込み中： 最終レイアウトの形状に合わせたスケルトンローダーを使います。汎用的な円形スピナーは避けます。
空の状態： 見栄えよく構成し、データの入力方法を示します。
エラー状態： フォームでは明確なインライン表示、一時的なエラーには文脈に応じた表示（トーストのみ）を使います。
触覚的なフィードバック： :active では -translate-y-[1px] または scale-[0.98] を使い、物理的に押した感覚を表現します。
ボタンのコントラスト確認（必須、アクセシビリティ）： リリース前に、ボタンのテキストがボタンの背景に対して読みやすいことを確認します。白いボタンに白いテキスト、bg-white の CTA に text-white のラベル、ページ背景上にボーダーのない透明なボタンは、すべて禁止です。すべての CTA を監査し、コントラスト比が WCAG AA の最低基準（本文は4.5:1、大きなテキスト（18px以上）は3:1）を満たすようにします。写真背景上のゴーストボタンにも同じルールを適用します（背景パネル、スクリーン、またはストロークを使います）。
CTA ボタンの折り返し禁止（必須）： ボタンのテキストはデスクトップで必ず1行に収めます。「選んだ実績を見る」のようなラベルが2行または3行に折り返される場合、そのボタンは不適切です。ラベルを短くする（主要 CTA は最大3語、理想は1～2語）か、ボタンの幅を広げて修正します（CTA に max-width を設定して幅を不自然に制限してはいけません）。デスクトップで CTA が折り返される場合、リリース前チェックは不合格です。
CTA の意図を重複させない（必須）： 1つのページに同じ意図の CTA を2つ置くと、リリース前チェックは不合格です。同じ意図の例：「お問い合わせ」＋「連絡する」＋「お話ししましょう」＋「プロジェクトを始める」＋「何かを始める」＋「ご連絡ください」は、すべて「連絡」の意図です。ラベルを1つ選び、ページ内（ナビゲーション、ヒーロー、フッター）で統一します。「無料で試す」＋「始める」＋「無料で登録」もすべて「登録」の意図、「実績を見る」＋「選んだ実績を見る」＋「プロジェクトを見る」もすべて「ポートフォリオ」の意図です。意図ごとにラベルは1つにします。
フォームのコントラスト確認（必須、アクセシビリティ）： フォーム入力欄、プレースホルダーテキスト、フォーカスリング、補助テキスト、エラーテキストはすべて、セクションの背景に対して WCAG AA のコントラスト基準を満たす必要があります。ほぼ白いフォーム上の薄いプレースホルダー、ページセクション上の白いフォーム、コントラスト比が4.5:1を下回るフォームラベルは、すべて禁止です。リリース前にすべてのフォームを監査します。

4.6 データとフォームのパターン

ラベルは入力欄の上に配置します。補助テキストは任意ですが、マークアップには含めます。エラーテキストは入力欄の下に配置します。入力ブロックには標準の gap-2 を使います。
プレースホルダーをラベルとして使うことは、決して許可されません。

4.7 レイアウトの規律（厳守ルール。どれか1つでも違反すると、成果物は不適切です）

ヒーローは初期ビューポート内に必ず収めること。 デスクトップでは見出しは最大2行、補足テキストは最大 20語 かつ最大3〜4行にし、CTAはスクロールせずに見えるようにします。コピーが長すぎる場合は、フォントサイズを下げるか、コピーを削ります。補足テキスト20語で価値提案を説明できないなら、ルールが厳しすぎるのではなく、価値提案が明確ではありません。CTAを見つけるためにスクロールが必要になるほど、ヒーローをはみ出させてはいけません。
ヒーローのフォントサイズを適切に管理すること。 フォントサイズと画像サイズはセットで計画します。ヒーローのアセットが大きく、見出しが6語を超える場合は、text-7xl/text-8xl から始めないでください。ほとんどのヒーローで適切なデフォルト範囲は text-4xl md:text-5xl lg:text-6xl です。見出しが3〜5語の場合に限り、text-6xl md:text-7xl を使います。ヒーローの見出しが4行になるのは、コピーが長すぎるのではなく、必ずフォントサイズの誤りです。
ヒーローの上部パディング上限（必須）： デスクトップではヒーローの上部パディングを最大 pt-24（約6rem）にします。これを超えると、ヒーローのコンテンツがビューポートの中央付近に浮いてしまい、意図的な余白ではなくレイアウトの不具合に見えます。ヒーローにもっと余裕が必要な場合は、上部パディングではなく、フォントサイズかアセットサイズを大きくしてください。
ヒーローのスタックを適切に管理すること（テキスト要素は最大4つ）。 ヒーローはひとつの印象を伝える場であり、機能一覧ではありません。使用できるテキスト要素は、合計最大4つです。
1. アイブロウ（小さな大文字ラベル）、ブランドストリップ、またはどちらもなし。0個か1個を選択します
2. 見出し（最大2行。上記を参照）
3. 補足テキスト（最大20語、最大4行）
4. CTA（プライマリ1つ＋セカンダリ最大1つ）
- ヒーローで禁止する要素： CTAの下に置く小さなタグライン（「GitHub、GitLab、セルフホスト可能なGitに対応」）、信頼性を示す小さな帯（「エンジニアリングチームに利用されています…」）、料金の予告（「個人は無料、チームはユーザーあたり$10」）、機能の箇条書き、ソーシャルプルーフのアバター列。これらはすべて、ヒーロー直下の専用セクションに移動します。
- 同じヒーロー内にアイブロウとCTA下のタグラインがある場合は、タグラインを削除します。ブランドストリップとタグラインがある場合も、タグラインを削除します。ヒーローに置く小さなテキスト要素は最大1つです。
「導入企業」／「信頼される企業」のロゴ一覧はヒーローの下に配置し、ヒーロー内には置かないこと。 ヒーローでは価値提案と主要CTAを伝えます。ロゴ一覧は、その直下に置く独立したセクションです。ヒーローのコピーと同じフレックス行に信頼性を示すロゴを詰め込まないでください。
デスクトップではナビゲーションを必ず1行で表示すること。 lg（1024px）で項目が収まらない場合は、ラベルを短くするか、二次項目を削るか、ハンバーガーメニューに移します。デスクトップで2行になるナビゲーションは設計不良です。
ナビゲーションの高さ上限：デスクトップで最大80px、デフォルトは64〜72px。 ビューポートの15％を占めるような巨大な「エージェンシー風」ナビゲーションバーは避けます。
Bentoグリッドではリズムを持たせ、片側に偏った繰り返しを避けること。 左に画像、右にテキストの行を6つ積み重ねないでください。全幅の機能行、非対称なタイルサイズ、縦方向の区切りなどを組み合わせて構成に変化をつけます。
BENTOのセル数ルール（必須）： Bentoグリッドのセル数は、コンテンツの項目数と必ず一致させます。項目が3つならセルも3つ（1＋2の分割、2＋1、または非対称な3セル）。項目が5つならセルも5つ（2＋3、3＋2、ヒーロー＋4つなど）。グリッドの中央や末尾に空のセルがある場合は、計画に誤りがあります。グリッドを組み直し、空のタイルを貼り付けないでください。
セクションレイアウトの繰り返し禁止。 セクションでレイアウトの種類（例：3列の画像カード、全幅の引用、テキストと画像の分割）を使ったら、その種類をページ内で使えるのは最大1回です。「厳選した制作実績」を「提供内容」と同じ見た目にしてはいけません。8つのセクションがあるランディングページでは、少なくとも4種類のレイアウトを使います。
ジグザグ交互配置の上限（必須）。 「左に画像＋右にテキスト」、続いて「左にテキスト＋右に画像」と交互に並べるジグザグレイアウトはありきたりです。画像とテキストを分割するパターンを連続で使えるのは最大2セクションです。画像とテキストを分割するセクションが3つ連続したら、出荷前チェックで不合格です。全幅セクション、縦積みセクション、Bentoグリッド、マーキー、または別のレイアウトの種類を使ってパターンを崩してください。
アイブロウは控えめに（必須。本番テストで最も違反が多いルールです）。 「アイブロウ」とは、セクション見出しの上に置く、小さな大文字で文字間隔を広げたラベルです（例：FOUR COLORWAYS、SELECTED WORK、THE HARDWARE、Git-native task management）。典型的なCSSの指定は text-[11px] uppercase tracking-[0.18em]、font-mono text-[10.5px] uppercase tracking-[0.22em] です。AIで構築されたサイトは、すべてのセクション見出しの上にアイブロウを置きがちで、同じテンプレートのようなリズムになってしまいます。厳格なルール：
- アイブロウは3セクションにつき最大1つ。 ヒーローも1セクションとして数えます。つまり、9セクションのページで使えるアイブロウは合計最大3つです。
- セクションAにアイブロウがある場合、次の2つのセクションにはアイブロウを置けません。
- 出荷前チェックは機械的に行います： すべてのセクションコンポーネントで、uppercase tracking（または見出しの上に置かれた同様の小さな大文字モノスペースラベル）の数を数えます。その数が ceil(sectionCount / 3) を超えると、出力は不合格です。
- アイブロウの代わりにすること： アイブロウを完全に省きます。見出しだけで十分です。セクションを分類したい場合も、ページ内の位置ですでに分類できているため、ラベルは必要ありません。
見出しの分割配置は禁止（必須）。 セクション見出しで「左に大きな見出し＋右に小さな説明段落」を配置するパターン（左カラムが col-span-7/8、右カラムが col-span-4/5 で、右カラムに小さな本文を置くレイアウト）は、デフォルトでは禁止です。セクションではメッセージを1つに絞ります。見出しと説明段落の両方が本当に必要な場合は、縦に積み重ねます（見出しを上、本文を下にし、最大幅は65ch）。分割配置を使うのは、右カラムに単なる埋め草ではなく、ビジュアル要素やインタラクティブ要素を配置するなど、実際の構成上の理由がある場合に限ります。
Bentoの背景に多様性を持たせること（必須）。 Bentoや機能グリッドのセクションを、白地に白いカードを6つ並べてテキストを入れるだけの構成にしてはいけません。複数セルのグリッドでは、少なくとも2〜3セルに実質的なビジュアルの変化を加えます。実際の画像、ブランドに合ったグラデーション（AIらしい紫は避ける）、パターン、色付きの背景などを使います。タイポグラフィしか使わないクリーム色の背景のBentoは、ページのほかの部分が優れていても、退屈なAIのデフォルトデザインに見えます。
各セクションでモバイル時の折りたたみ方を明示すること。 複数カラムのレイアウトでは、同じコンポーネント内に < 768px での代替表示を指定します。「Tailwindが対応するから大丈夫」と思い込んではいけません。

4.8 画像とビジュアルアセットの戦略

ランディングページやポートフォリオはビジュアルが中心のプロダクトです。スクリーンショット風の偽の div を使ったテキストだけのページは、手抜きです。

ビジュアルアセットの優先順位：

まず画像生成ツールを使います。 環境内で画像生成ツール（generate_image、MCP 画像ツール、IDE 統合型生成ツール、OpenAI 画像ツールなど）が少しでも利用できる場合は、必ず使って、セクションに合わせたアセットを作成してください。ヒーロー画像、プロダクト写真、テクスチャ背景、ムード画像などを生成します。セクションに合ったアスペクト比にしてください。手書きの CSS のほうが速そうだからといって、この手順を省略してはいけません。
次に実際のウェブ画像を使います。 画像生成ツールを利用できない場合は、実際の写真ソースを使ってください。使用可能なデフォルト：
- プレースホルダー用の写真には https://picsum.photos/seed/{descriptive-seed}/{w}/{h} を使用します（シードにはセクションを表す説明を含めてください。例：marrow-cookware-kitchen）。
- ブリーフに指定されている場合は、実際のストック画像またはブランドの URL を使います。
- 明示的に許可されている場合は、オープンライセンスのソース（直接 URL での Unsplash、Pexels）を使います。
最後の手段として、ユーザーに伝えます。 どちらも利用できない場合は、ページを手書き SVG イラストや div ベースの「偽スクリーンショット」で埋めないでください。代わりに、明確なラベル付きのプレースホルダースロット（``）を残し、回答の最後に次のように記載します："このページには次の場所に実際の画像が必要です：[配置場所のリスト]。画像を生成するか、提供してください。"

ミニマリストなサイトにも実際の画像が必要です。 テキストだけのページはミニマリズムではありません。未完成な作業です。エディトリアルな Linear 風のサイトでも、実際の画像が少なくとも 2～3 枚必要です（ヒーロー、プロダクトまたはライフスタイル写真 1 枚、補助画像 1 枚）。ブリーフが控えめなデザインを求めている場合は、モノクロのミニマリスト写真を生成してください。設定の強度が低いからといって、画像を完全に省略してはいけません。

ソーシャルプルーフには実在企業のロゴを使います。 ブリーフで「Trusted by / Used by / Customers」のロゴ一覧が求められている場合、プレーンテキストのワードマーク（<span>Acme Co</span> を横並びにスタイル設定したもの）をデフォルトで使わないでください。実際の SVG ロゴを使います。

ソース：Simple Icons（任意の色には https://cdn.simpleicons.org/{slug}/ffffff、または simple-icons npm パッケージ）。広く知られているブランドの大半を網羅しています。
代替： 技術スタックのロゴには devicon（@svgr/cli または CDN）。
ブランド名を創作する場合は、SVG マークも作成します。 シンプルなモノグラム（円の中の 1 文字、2 文字の合字、抽象的なグリフ）を、ページのスタイルに合わせたインライン <svg> として描画します。架空のブランド名にプレーンテキストのワードマークを使うと、ありきたりに見えます。
ロゴはライトモードとダークモードの両方で必ず正しく表示されるようにします（暗い背景には白、明るい背景には黒、またはテーマ変数による単色）。
ロゴのみのルール（必須）： ロゴ一覧にはロゴ以外を含めません。各ロゴの下に業界やカテゴリのラベルを表示しないでください（Vercel の下に hosting、Stripe の下に payments、Cloudflare の下に infra などを付けないこと）。ロゴ自体が信頼性を示します。ユーザーがすでに知っている情報をラベルで追加する必要はありません。任意：スクリーンリーダー向けの代替テキストとしてブランド名を指定する、ブランドサイトへのリンクを付ける。以上です。

手書きのイラスト：

ライブラリの SVG アイコン：問題ありません（セクション 3.C を参照）。
手書きの装飾用 SVG（カスタムイラスト、ロゴ、マーク）：強く非推奨です。 デフォルトでは決して使わないでください。使用が許容されるのは、次の場合に限ります。
- ブリーフで明示的に求められている場合（「SVG ロゴを描いてください」など）
- シンプルな幾何学的マーク 1 つだけの場合（四角形、円、ディスプレイ書体のワードマーク）
- 出力品質に自信がある場合

div ベースの偽スクリーンショットは禁止です。 <div> の四角形、偽のタスクリスト、偽のダッシュボード、偽のターミナルウィンドウで描画した「手作りのプロダクトプレビュー」は、手抜きの表れです。プロダクトを表示する必要がある場合：

実際のスクリーンショット URL があれば使用します。
画像ツールで生成します。
実際のコンポーネントプレビュー（ページ内に UI の実際のミニバージョンを表示するもの）を使います。
または、プレビューを完全に省略してエディトリアル写真を使います。

ヒーローには実際のビジュアルが必要です。 テキストとグラデーションの blob だけではヒーローとは言えません。プレースホルダーです。

4.9 コンテンツ密度

ランディングページで重要なのは第一印象であり、すべてを読んでもらうことではありません。思い切って削りましょう。

各セクションの基本構成： 短い見出し（8語以内）＋短い補足文（25語以内）＋ビジュアル素材1点、またはCTA1つ。それ以上の要素を加える場合は、そのセクションの役割に照らして必要性を説明できなければなりません。
データを詰め込んだセクションは避けましょう。 20行の出版物一覧、30行の受賞歴、マーケティングページに巨大な価格表を載せるのは、レイアウトとして不適切です。次の方法を使いましょう。
- 特に重要な3〜5項目を表示し、「一覧を見る」リンクを設ける
- マーキー／カルーセルで幅広く見せる
- データ自体が製品である場合は、別のページに分ける
長いリストには、リストを長くするのではなく別のUIコンポーネントを使いましょう。 箇条書きやdivide-yの行を使うデフォルトの<ul>は、安易な選択です。項目が5つを超える場合は、代わりに次のいずれかを使いましょう。
- 項目をグループ分けした2列レイアウト
- 各項目に画像とラベルを付けたカードグリッド
- 項目を分類できる場合はタブ／アコーディオン
- 横スクロールできるスナップピル
- 項目の種類が多いリスト（お客様の声、ロゴ、機能など）にはカルーセル
- 「個々に注目する必要のない、たくさんの項目」にはマーキー 10行の仕様表に各行の下線を引くレイアウトは、デフォルトとして最悪です。行を2〜3個のグループにまとめて区切り線を控えめにするか、仕様ごとにカードを設けるレイアウトに変更しましょう。
特に仕様表について（Marrowの調理器具パターン）。 各行にborder-bを付けた長い製品仕様表は、調理器具／ハードウェア／アパレル／職人製品の概要を作る際にAIが選びがちなデフォルトです。禁止です。具体的な代替案は次のとおりです。
- 2列のカードグリッド： 各仕様をカードにして、仕様名、値（大きく表示する数値）、重要性を説明する1行の本文を載せます。デスクトップでは2列、モバイルでは1列に並べます。
- スナップピルの横スクロール： 各仕様をピルにし、ユーザーがスワイプして見られるようにします。
- グループ分け： 10個の仕様を「素材」「調理」「保証」など、論理的な3つのグループに分けます。各グループには控えめな区切り線を1本だけ設け、見出しを付けます。
- 注目項目とその他に分ける： 特に重要な3〜4個の仕様を大きなタイルで視覚化し、残りは「すべての仕様を見る」の開示項目にまとめます。
コピーの自己監査（公開前に必須）： タスクの完了を宣言する前に、ページ上に表示されるすべての文言（見出し、副見出し、アイブロウ、ボタンラベル、本文、キャプション、代替テキスト、フッターの文言、エラーメッセージ）を読み直します。次のような文言があれば指摘してください。
- 文法が崩れている（「過去の上で無料」「2つのプランがあるが、正直なのは1つ」「文脈と関係なく『それをテーブルに載せる』」）
- 指示対象が不明確（前後に文脈がないのに「私たちはそのままでいるつもりです」と書かれている）
- AIの幻覚のように聞こえる（かわいらしいが間違った言葉遊び、筋の通らない無理な比喩、「優雅な無」などの表現）
- LLMが思慮深そうに見せようとしているように読める（受け身で攻撃的な謙遜、職人を気取ったラベル、気取った詩的なメタ表現）指摘した文言はすべて書き直してください。意味が通るかどうか確信が持てない場合は、わかりやすく実用的な文に置き換えてください。AIが生成した気の利いたコピーは、退屈なコピーよりも悪いものです。
根拠のない精密な数値は指摘対象です。 92%、4.1×、48k、5.8 mm、13.4 lbなどの数値は、次のいずれかに該当する必要があります。
- 実際のデータ（概要、ブランドガイドライン、公開されている指標）に基づいている：問題ありません
- モックであること（``, 「例」、「サンプルデータ」）が明記されている：問題ありません
- AIが仕様らしく見せるために作り出した数値である：禁止です。ブランドが主張していない技術的な精密さをでっち上げないでください。
ページ内の文体は統一しましょう。 ブランドの声として明確に求められていない限り、技術的な簡潔表現（「47タスク・1日あたり0.6回のコンテキスト切り替え」）、編集的な文章、マーケティング調の力強いコピーを同じ構成に混在させないでください。

4.10 引用と推薦コメント

引用本文は最大3行です。6行にはしないでください。元の引用がそれより長い場合は、短くしてください。ランディングページの引用は抜粋であり、レビュー全文ではありません。
フォントサイズが非常に小さい場合（例：フッター風の推薦コメント）は、行数の上限を少し超えてもかまいません。大切なのは「ひと目で読める」ことです。
デザイン上の演出として、引用文の中にエムダッシュを使わないでください（長い間、動きを表すエムダッシュ、エムダッシュを使った箇条書きなど）。セクション9.Gを参照してください。エムダッシュは全面的に禁止です。
引用元の表記：氏名＋役職＋（任意で）会社名。氏名のみ（「- Sarah」）にはしないでください。
引用符：適切なタイポグラフィの引用符（ " " ）を使うか、引用符を使わないでください。ASCII のまっすぐな引用符（ " ）は使わないでください。

4.11 ページのテーマを統一する（ライト／ダークモードの一貫性）

ページ全体でテーマは1つにします。セクションごとに反転させてはいけません。

ページがダークモードなら、すべてのセクションをダークモードにしてください。ダークなセクションの間に、ライトモードの温かみのある紙色のセクションを挟まないでください（逆も同様です）。スクロール中に別のサイトに迷い込んだように感じさせてはいけません。
例外として、ブリーフで「Color Block Story」または「Theme Switch on Scroll」の演出が明示的に求められており、意図的な構成である場合（ランダムな切り替えではなく、明確なトランジションを伴うテーマの切り替えを1回だけ行う場合）は許可されます。
デフォルトでは、ページレベルでライト、ダーク、または自動（prefers-color-scheme）を選び、固定してください。同じテーマファミリー内でセクションごとに背景の色合いを変えるのは問題ありません（bg-zinc-950 の隣に bg-zinc-900 など）。bg-zinc-950 のページの途中で bg-amber-50 に切り替えるのは適切ではありません。
テーマが組み込まれたデザインシステム（Radix Themes、<Theme> を使った shadcn/ui など）を使用する場合は、テーマを layout.tsx またはページルートで一度だけ設定してください。個々のセクションで上書きさせないでください。

5. コンテキストに応じたプロアクティブな対応

これらはツールであり、デフォルトではありません。デザインの読み取り結果から必要と判断した場合に使用してください。これらは自動では一切動作しません。

リキッドグラス／グラスモーフィズム： 高級感のあるコンシューマー向け、Apple に近い雰囲気、高級ブランド、またはメディアオーバーレイ風のデザインに適しています。ダッシュボード、公共部門、または「地味な B2B」には適しません。使用する場合は、backdrop-blur だけでなく、物理的なエッジの屈折を表現するために、1px の内側ボーダー（border-white/10）と控えめな内側シャドウ（shadow-[inset_0_1px_0_rgba(255,255,255,0.1)]）を追加してください。prefers-reduced-transparency の場合に備えて、不透明な塗りつぶしのフォールバックも用意してください。
マグネティック・マイクロフィジックス： MOTION_INTENSITY > 5 で、かつブリーフが高級感または遊び心、エージェンシーらしさを求める場合に使用してください。実装には Motion の useMotionValue／useTransform のみを使い、React のレンダーサイクル外で処理してください。useState は絶対に使わないでください。セクション 3.B を参照してください。
常時動作するマイクロインタラクション（パルス、タイプライター、フロート、シマー、カルーセル）：MOTION_INTENSITY > 5 で、かつセクションが動きから積極的に恩恵を受ける場合（ステータスインジケーター、ライブフィード、AI らしさ）に使用してください。すべてのカードで無限ループが必要なわけではありません。 情報を伝えるだけのセクションは静止させてください。線形イージングは使わず、スプリング物理（type: "spring", stiffness: 100, damping: 20）を適用してください。
「動きをうたうなら、動きで示す。」 MOTION_INTENSITY > 4 の場合、ページは実際に動く必要があります。最低限、ヒーローの登場トランジション、主要セクションのスクロール連動表示、CTA のホバーフィジックスを実装してください。MOTION_INTENSITY: 7 をうたう静的なページは不完全です。反対に、利用可能な範囲で動作するモーションを実装できない場合は、ダイヤルを 3 に下げて、すっきりとした静的なページを公開してください。動作が壊れるモーションを中途半端に実装しないでください（途中で切れる ScrollTrigger、不自然な登場、クリーンアップ漏れなど）。
モーションには必ず理由を持たせる（必須）。 アニメーションを追加する前に、「このアニメーションは何を伝えるのか？」と考えてください。有効な答えは、階層（適切な要素に注意を引く）、ストーリーテリング（ストーリーに沿ってコンテンツを順に表示する）、フィードバック（ユーザーの操作を認識する）、状態遷移（何かが変わったことを示す）です。「かっこよく見えた」は無効な答えです。GSAP が使えるからといってどこにでも使うのは、未熟なやり方です。各 ScrollTrigger、各マーキー、各ピン留めセクションには理由が必要です。その理由を一文で説明できない場合は、アニメーションを削除してください。
マーキーはページごとに最大 1 つ（必須）。 横スクロールするテキストマーキー（「ロゴを延々とスクロール」「マニフェストを横方向にスクロール」「動きのある単語の帯」）は、1 ページにつき最大 1 回までが適切です。同じページに 2 つ以上のマーキーがあると、安易な埋め草に見えます。マーキーがコンテンツに本当に役立つセクションを 1 つ選び、ほかのセクションには別のレイアウトを使ってください。
GSAP スティッキースタックパターン（スクロールスタックを使用する場合）。 「スクロール時にカードを積み重ねる」ものは、順番に表示するリストではなく、実際のスティッキースタックでなければなりません。標準的なコードの骨組みについては、以下のセクション 5.A を参照してください。よくある失敗は、ビューポートの上部でピン留めされず、スクロールの途中でトリガーされることです。修正方法：start: "top center" や "top 80%" ではなく、start: "top top" を使います。
GSAP 水平パンパターン（横スクロールによるスクロールハイジャックを使用する場合）。 標準的な骨組みについては、以下のセクション 5.B を参照してください。よくある失敗は、セクションがピン留めされる前にアニメーションが始まり、ユーザーにスライドの途中が見えてしまうことです。同じ方法で修正します。start: "top top" を使い、ラッパーをピン留めし、内側のトラックをスクラブします。

5.A スティッキースタック — 標準的な骨組み

標準的な tsx の骨組み：references/motion-skeletons.md。

重要なポイント：start: "top top"、pin: true、最後以外のすべてのカードをピン留めします。スケール／不透明度の変化は、次のカードのスクロールトリガーによって制御します（次のカードが現れるにつれて、前のカードが縮小します）。

5.B 水平パン — 標準的な骨組み

標準的な tsx の骨組み：references/motion-skeletons.md。

重要なポイント：start: "top top"、pin: true、end: "+=${distance}"（スクロールの長さ＝水平方向への移動に必要な距離）、scrub: 1。ラッパーをピン留めし、ユーザーが垂直方向にスクロールするのに合わせて、内側のトラックを水平方向にスライドさせます。

5.C スクロール表示の段階的アニメーション — 標準スケルトン（より軽量な代替手段）

単純に「要素がビューポートに入ると表示される」動作（ピン留めなし）には、GSAP ではなく Motion の whileInView を優先してください。より軽量で、ScrollTrigger も不要です。

標準的な tsx スケルトン：references/motion-skeletons.md。

次の用途で使用します：機能一覧、お客様の声のグリッド、ロゴ一覧など、「スクロール時に表示」するだけのもの。GSAP は実際にピン留めやスクラブが必要な場合に使用してください。

5.D 禁止されているアニメーションパターン

window.addEventListener("scroll", ...) は禁止です。スクロールの各フレームで実行され、カクつきが発生しやすく、バッチ処理もされません。Motion の useScroll()、GSAP の ScrollTrigger、IntersectionObserver、または CSS の scroll-driven animations（animation-timeline: view()）を使用してください。
React の state で window.scrollY を使用してスクロール進捗を独自に計算すること。理由は同じです。各フレームで再レンダリングが発生します。
React の state に触れる requestAnimationFrame ループ。 代わりにモーション値（useMotionValue + useTransform）を使用してください。
レイアウトトランジション： 目に見える状態変化（リストの並べ替え、モーダルの展開、ルート間の共有要素）には、Motion の layout および layoutId props を使用してください。静的コンテンツを「念のため」layout props で囲まないでください。計測処理の負荷が増えます。
段階的なオーケストレーション： 表示タイミングに順序が必要な場合は、staggerChildren（Motion）または CSS カスケード（animation-delay: calc(var(--index) * 100ms)）を使用してください。staggerChildren では、親（variants）と子が同じ Client Component ツリーを共有している必要があります。

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

6.A ハードウェアアクセラレーション

transform と opacity のみをアニメーションさせてください。top、left、width、height はアニメーションさせないでください。
will-change: transform の使用は控え、実際にアニメーションする要素にのみ指定してください。

6.B モーションの軽減（必須）

MOTION_INTENSITY > 3 のモーションはすべて、prefers-reduced-motion に対応する必要があります。 これは必須です。
Motion では、useReducedMotion() で囲み、静的な表示に切り替えてください。
CSS では、@media (prefers-reduced-motion: no-preference) の中でアニメーションを有効にするか、アニメーションを無効にする @media (prefers-reduced-motion: reduce) 内の上書きブロックを用意してください。
無限ループ、パララックス、スクロールの乗っ取り、磁力的な物理挙動は、モーション軽減が有効な場合、静的または即時の動作にする必要があります。

6.C ダークモード（ユーザー向けページでは必須）

最初から両方のモード向けに設計してください。 明示的なユーザー指示がない限り、ライトモードのみ、またはダークモードのみで公開しないでください。
トークンには Tailwind の dark: バリアントまたは CSS 変数を使用してください。プロジェクトごとにどちらか一方の方式を選んでください。
ここでは、ダークモード用の具体的な色を指定しないでください。 色は要件に従います。両方のモードで、視覚的な階層、ブランドアイデンティティ、WCAG AA のコントラスト（本文は AAA）を維持してください。
prefers-color-scheme: dark を尊重してください。ブランドが一方のモードを指定していない限り、システム設定をデフォルトにしてください。

6.D Core Web Vitals の目標値

LCP < 2.5s。ヒーロー画像には next/image priority を指定するか、プリロードしてください。
INP < 200ms。負荷の高い処理はメインスレッド外で実行してください。
CLS < 0.1。画像、フォント、埋め込みコンテンツ用のスペースを確保してください。
ページの完成を宣言する前に Lighthouse を実行してください。

6.E DOM のコスト

グレイン／ノイズのフィルターは、固定された pointer-events-none の疑似要素（例：fixed inset-0 z-[60] pointer-events-none）にのみ適用してください。スクロールするコンテナーには絶対に適用しないでください。継続的な GPU の再描画により、モバイルの FPS が著しく低下します。
バンドルサイズに注意してください。Motion は小さなライブラリではありません。Three.js はサイズが大きいため、ファーストビューより下にあるものはすべて遅延読み込みしてください。

6.F z-index の節度

任意の z-50 や z-10 をむやみに使用しないでください。z-index は、システムのレイヤーコンテキスト（固定表示のナビゲーションバー、モーダル、オーバーレイ、グレイン）に限って厳密に使用してください。z-index のスケールは、プロジェクトの定数ファイルに記載してください。

7. ダイヤルの定義（技術リファレンス）

DESIGN_VARIANCE（レベル 1～10）

1～3（予測可能）： 対称的な CSS Grid（12 列、均等な fr 単位）、均等なパディング、中央揃え。
4～7（ずらし）： margin-top: -2rem で重ねる、画像のアスペクト比を変える（4:3 の隣に 16:9）、中央揃えのデータの上に左揃えのヘッダーを配置する。
8～10（非対称）： メイソンリーレイアウト、フラクショナル単位を使った CSS Grid（grid-template-columns: 2fr 1fr 1fr）、広大な余白領域（padding-left: 20vw）。
モバイルでの上書き： レベル 4～10 では、md: 以上の画面幅で使う非対称レイアウトは、ビューポート幅が < 768px のとき、必ず厳密な単一カラム（w-full、px-4、py-8）に切り替えてください。

MOTION_INTENSITY（レベル 1～10）

1～3（静的）： 自動アニメーションは使用しません。CSS の :hover と :active の状態のみを使います。いずれにせよ、デフォルトのモードは prefers-reduced-motion です。
4～7（滑らかな CSS）： transition: all 0.3s cubic-bezier(0.16, 1, 0.3, 1)。読み込み時に表示する要素には、連鎖的に animation-delay を設定します。transform と opacity を重視します。
8～10（高度な演出）： スクロールをトリガーとする複雑な表示、視差効果、スクロール駆動アニメーション（CSS の animation-timeline または GSAP ScrollTrigger）。Motion フックを使います。window.addEventListener('scroll') は絶対に使わないでください。これは「できれば避ける」ではなく、厳禁です。許可されている代替手段はセクション 5.D を参照してください。

VISUAL_DENSITY（レベル 1～10）

1～3（アートギャラリー）： 余白を多く取ります。セクション間の間隔を大きくします（py-32～py-48）。上質で、すっきりとした印象です。
4～7（日常的なアプリ）： 標準的なウェブアプリの間隔（py-16～py-24）。
8～10（コックピット）： パディングを詰めます。カードボックスは使わず、1px の線でデータを区切ります。必須：すべての数値に font-mono を使います。

8. ダークモードのプロトコル

デフォルトではデュアルモードです。印刷物を模したエディトリアルデザインでない限り、ライトモード専用だと決めつけないでください。

8.A トークン戦略（いずれかを選び、統一する）

Tailwind の dark: バリアント（ユーティリティファーストのプロジェクトではデフォルト）：すべての色ユーティリティに対応するダークモード用バリアントを設定します（bg-white dark:bg-zinc-950、text-gray-900 dark:text-gray-100）。
CSS 変数（shadcn/ui、Radix Themes、またはテーマ設定に対応したコンポーネントライブラリ向け）：セマンティックトークン（--surface、--surface-elevated、--text-primary、--accent）を定義し、[data-theme="dark"] または @media (prefers-color-scheme: dark) で値を切り替えます。

8.B ここでは特定の色を指定しない

色はブリーフとブランドに従って決めます。このスキルで定めるのは、次の点のみです。

コントラスト - 本文は WCAG AA を最低基準とし、ヒーローコピーは AAA を目指します。
階層の同等性 - ライトモードで機能する視覚的階層は、ダークモードでも機能させます。ライトモードで CTA が目立つなら、ダークモードでも目立つようにします。
ブランドの忠実性 - ブランドの主要色は認識できる状態を保ちます。ダークモードに合わせてブランドカラーの彩度を落としてはいけません。
純粋な #000000 と純粋な #ffffff は使わない - オフブラック（zinc-950、黒に近い暖色系のグレー）とオフホワイトを使います。純粋な値では奥行きが失われます。

8.C デフォルトモード

ブランドからの指定がない限り、prefers-color-scheme に従います。どちらかのモードでブランドの重要な表現が損なわれる場合は、手動切り替えを追加します。

8.D 仕上げる前に両方のモードでテストする

開発中に両方のモードでページを開いてください。片方のモードでしか確認していないページをリリースしてはいけません。

9. AI らしさの表れ（禁止パターン）

ブリーフで明示的に求められていない限り、次のような特徴は避けてください。

9.A ビジュアルと CSS

ネオンや外側の光彩は原則として使わない。 内側のボーダーや、色味を抑えた控えめなシャドウを使います。
純粋な黒（#000000）は使わない。 オフブラック、zinc-950、またはチャコールを使います。
彩度の高すぎるアクセントは使わない。 ニュートラルカラーになじむよう、彩度を落とします。
大きなヘッダーにグラデーションテキストを多用しない。
カスタムマウスカーソルは使わない。 時代遅れで、アクセシビリティとパフォーマンスを損ないます。

9.B タイポグラフィ

デフォルトのフォントに Inter を使うのは避けてください。 セクション 4.1 を参照してください。例外的に使用する方法もあります。
大きすぎてただ叫んでいるような H1 は使わない。 単純にサイズを大きくするのではなく、ウェイトと色で階層を調整します。
セリフ体の制約： エディトリアル、ラグジュアリー、出版物にはセリフ体を使います。ダッシュボードには使いません。

9.C レイアウトと余白

余白とマージンは数学的に完璧にします。不自然な隙間ができる浮遊要素は使いません。
均等な3列の機能カードは禁止です。 横並びの「同じカードが3つ」という汎用的な機能紹介の列は使用禁止です。2列のジグザグ配置、非対称グリッド、スクロールに固定されるレイアウト、横スクロールなどの代替案を使ってください。

9.D コンテンツとデータ（「Jane Doe」効果）

ありきたりな名前は禁止です。 「John Doe」「Sarah Chan」「Jack Su」ではなく、創造性があり、現実的で、地域に合った名前を使ってください。
ありきたりなアバターは禁止です。 SVG の「卵」や Lucide のユーザーアイコンではなく、実際の写真に見えるプレースホルダーや、個性のあるスタイルを使ってください。
不自然に完璧な数字は禁止です。 99.99%、50%、1234567 は避けてください。47.2%、+1 (312) 847-1928 のような、自然でばらつきのあるデータを使ってください。
スタートアップ風の安っぽいブランド名は禁止です。 「Acme」「Nexus」「SmartFlow」「Cloudly」ではなく、文脈に合った、上質で実在感のある名前を考案してください。
中身のない動詞は禁止です。 「Elevate」「Seamless」「Unleash」「Next-Gen」「Revolutionize」ではなく、具体的な動詞を使ってください。

9.E 外部リソースとコンポーネント

手作りの SVG アイコンは禁止です。 Phosphor／HugeIcons／Radix／Tabler を使ってください。明示的なリクエストがある場合に限り、Lucide を使えます。
装飾用の SVG を手作りすることは、デフォルトでは強く推奨されません（セクション 4.8 を参照）。
<div> を使った偽のスクリーンショットは禁止です。 スクリーンショットを模して、<div> の四角形で偽の製品 UI を作ることは絶対に避けてください。実際の画像、生成画像を使うか、プレビューを省略してください。
リンク切れの Unsplash URL は禁止です。 https://picsum.photos/seed/{descriptive-string}/{w}/{h}、生成した写真のプレースホルダー、または実際のアセットを使ってください。
shadcn/ui のカスタマイズ： 許可されていますが、デフォルト状態では絶対に使わないでください。プロジェクトの美的方向性に合わせて、角丸、色、影、タイポグラフィをカスタマイズしてください。
本番環境に耐えるクリーンさ： コードは見た目も整っていて、印象に残り、細部まで丹念に仕上げられている必要があります。

9.F 本番テストで見られた特徴（全面禁止）

これらのパターンは、実際の LLM 生成ランディングページのテストで見られたものです。モデルが「デザインされているように見せよう」とするときに使いがちな特徴です。ブリーフで明示的に求められていない限り、絶対に使用しないでください。

ヒーローとページ最上部

ヒーローにバージョンラベルを置くのは禁止です。 V0.6、v2.0、BETA、INVITE-ONLY PREVIEW、EARLY ACCESS、ALPHA を、デフォルトで小見出しとして使うことは禁止です。ブリーフで製品のローンチやプレビュー状況が明示的にテーマになっている場合に限り、使用できます。
「Brand · No. 01」形式の副次的な小見出しは禁止です。 「Marrow · No. 01 · The 6-quart」のような、ごく小さなメタ情報の行は使わないでください。

セクション番号と小さなラベル

セクション番号を小見出しにするのは禁止です。 00 / INDEX、001 · Capabilities、002 · Featured commission、06 · how it works、05 · The honest table は禁止です。小見出しには番号ではなく、トピックを平易な言葉で示してください。
画像やタイル型レイアウトに 01 / 4 形式のページ番号を付けるのは禁止です。 数えればわかるものにラベルは必要ありません。
Scroll · 001 Capabilities 形式のスクロール案内は禁止です。 シンプルな矢印か「Scroll」だけで十分です。セクション番号を前に付けないでください。
「Index of Work, 2018 - 2026」形式の範囲ラベルを小見出しに使うのは禁止です。 セクションの内容だけを示してください。

区切りとドット

中黒（·）の使用は制限されています。 メタデータの行では、1行につき最大1つです。何にでも使うデフォルトの区切り文字（「foo · bar · baz · qux · quux」など）にしないでください。区切りを設ける必要がある場合は、改行、細い罫線、列を使ってください。
リスト、ナビゲーション、バッジのすべてに装飾用の色付きステータスドットを付けるのは禁止です。 「ONE Q4 SLOT OPEN」の前、すべてのナビゲーションリンクの前、すべてのタスク行の前に色付きドットを置くことは、デフォルトで禁止です。ドットがサーバーの状態や利用可否など実際の意味を表し、控えめに使われている場合に限り、使用できます。 ダッシュとタイポグラフィ上の装飾
デザイン要素としても、それ以外の場所でも、em ダッシュ（—）は使用しないでください。 完全かつ例外のない禁止事項については、以下のセクション 9.G を参照してください。見出し、アイブロウ、ピル、本文、引用、帰属表示、キャプション、ボタンのテキスト、代替テキストで、em ダッシュ文字を使うことは禁止されています。通常のハイフン（-）を使用してください。
<br> で分割してイタリック体にする見出しを、定番の「デザイン手法」として使わないでください。 「for thirty<br>years.」のような分割です。まず自然に読める見出しにし、ブリーフで求められた場合に限って工夫を加えてください。
縦向きに回転させたテキスト（「INDEX OF WORK, 2018 - 2026」を 90° 回転させるなど）は使わないでください。 エージェンシーのポートフォリオでよくある陳腐な表現です。ブリーフが明確にエージェンシー／Awwwards／実験的なものを求めており、かつ構図上の実質的な目的がある場合に限り使用してください。
装飾として十字線や極細のグリッド線を使わないでください。 ページを「デザインされた感じ」にするためだけに引く縦線や横線は禁止です。実際のコンテンツを整理する場合に限り使用してください。

偽のプロダクトプレビュー

ヒーローエリアに、div で作った偽のプロダクト UI を置かないでください。 スタイルを付けた div で作る偽のタスクリスト、偽のターミナル、偽のダッシュボードなどが該当します。これは LLM がデザインしたと見抜かれる最大のサインです。本物のスクリーンショット、生成画像、本物のコンポーネントプレビューを使うか、何も置かないでください。
偽のバージョン情報フッター（「v0.6.2-rc.1」、「last sync 4s ago · main」など）を偽のスクリーンショット内に置かないでください。 何の価値もなく、AI らしさを強く感じさせます。

マーケティングコピーで AI らしさが出る表現

ソーシャルプルーフの見出しに「Quietly in use at」や「Quietly trusted by」を使わないでください。 自然な表現にしてください。「Trusted by」、「Used at」、「Customers include」などを使うか、ロゴを見れば伝わる場合は見出しを省いてください。
引用、ブログ、サイドバーのセクションに、「From the field」、「Field notes」、「Currently on the bench」、「On our desks」、「Loose plates」のような詩的なラベルを使わないでください。作り手らしさを演出しているように見えます。「Testimonials」、「Latest writing」、「Now working on」のような機能的で簡潔なラベルを使うか、ラベルを省いてください。
本文に「We respect the French ones」のような、謙虚さを装った業界への言及を入れないでください。 あざとく、AI らしい表現です。
ブリーフが特定の場所／タイムゾーンに分散したスタジオを明確に扱うものでない限り、ヘッダーやフッターに天気や場所の情報を表示する帯（「LIS 14:23 · 18°C」など）を置かないでください。
アイブロウの下に、細かな補足文を置かないでください。 セクション見出しの下に置く「これらはすべて今日提供している機能であり、ロードマップ上の約束ではありません。リストはあえて短く保ちます。」のような文は冗長です。アイブロウ、見出し、本文があれば十分です。
汎用的なステップラベルを使わないでください。 「Stage 1 / Stage 2 / Stage 3」、「Step 1 / Step 2 / Step 3」、「Phase 01 / Phase 02 / Phase 03」、「Pass One / Pass Two / Pass Three」は禁止です。実際のステップの内容をラベルにしてください。進行を示す必要がある場合は、「Stage 1: Install」ではなく、動詞と目的語を直接使ってください（「Install」、「Configure」、「Ship」など）。

ピル、ラベル、バージョン表示

画像の上にピル、ラベル、タグを重ねないでください。 写真に「Brand · 02」、「PLATE · BRAND」、「Field notes - journal」などのタグを重ねる <span> は使わないでください。画像だけにするか、キャプションを画像のすぐ下に（画像の外に）追加してください。
写真クレジットのキャプションを装飾として使わないでください。 ストック画像や Picsum 画像の下に「Field study no. 12 · Ines Caetano」、「Plate 03 · House archive」、「Frame XII · 35mm」などを置くのは気取った印象になります。写真クレジットを記載してよいのは、許可を得た実際の写真について、実際の撮影者をクレジットする場合に限ります。それ以外の場合は、キャプションを省くか、「Sage の 6 クォートモデル。」のような、機能的で簡潔なキャプションを 1 行で記載してください。
マーケティングページにバージョン情報フッターを置かないでください。 「v1.4.2」、「Build 0048」、「last sync 4s ago · main」などのフッター表示は、CLI や開発者向けツールのためのものであり、ランディングページのコンテンツではありません。マーケティングページ、ランディングページ、ポートフォリオページでは禁止です。
装飾として「Reservation 412 of 800」のような在庫状況のリアルタイムカウンターを使わないでください。 実際のデータを伴う限定販売のウェイトリストを、ブリーフが明確に扱う場合に限り使用できます。 装飾的なテキスト帯
ヒーローの下部に装飾的なテキスト帯を置かないでください。 BRAND. MOTION. SPATIAL., TYPE / FORM / MOTION, DESIGN · BUILD · SHIP, ESTD. 2018 · LISBON · BRAND. MOTION. SPATIAL. のような、ヒーローの下部を横切る小さな等幅大文字の帯は、エージェンシーのポートフォリオでよく見られる陳腐な表現です。デフォルトでは禁止です。実際に移動できるリンク（画面下部に固定されたナビゲーション）や、実際のステータス情報（Cookie バナー、ドキュメントサイトのビルド情報）を帯に表示する場合のみ許容されます。
セクション見出しの右上に補足テキストを浮かべないでください。 よくあるパターンは、セクション内に左揃えの大きな見出しがあり、同じセクションヘッダーの右上に、ほかの要素と明確に揃っていない小さな説明文が浮かんでいるものです。これが見抜かれるポイントです。補足テキストは見出しのすぐ下に置くか、すっきりとした2列のヘッダー（左：見出し、右：本文を揃えて配置）にしてください。隅に小さな段落を置くのは避けてください。

リスト、区切り線、スコア表示

長いリストや仕様表のすべての行に border-t と border-b を使わないでください。 どちらか一方を選び、控えめに使ってください（行間に下罫線を入れるか、グループの上に上罫線を入れるか）。細い線を各行の下に入れただけの10行の仕様表は、最も手抜きなレイアウトです。代替となる UI コンポーネントについてはセクション4.9を参照してください。
比較表示に、塗りつぶした背景トラックのあるスコアバーや進捗バーを使わないでください。 「YのうちX」の比較を表示する場合は、数値と小さなアイコンを使うか、背景トラックのない小さなインラインバーを使ってください。部分的な塗りつぶしを重ねた大きな bg-zinc-200 のトラックは、ランディングページではダッシュボード UI のノイズになります。

ロケール、時刻、スクロールの手がかり

ロケール、都市名、時刻、天気を並べた帯は、依頼の99％で禁止です。 ヒーローの「Lisbon, working with founders」、フッターの「1200-690 Lisbon, Portugal」、ナビゲーションの「Lisbon 14:23 · 18°C」などです。こうした表現は、エージェンシーのポートフォリオらしさを装飾で示す要素です。例外として許容されるのは、依頼でタイムゾーンを考慮した業務を行う世界各地に分散したスタジオが明示されている場合、旅行に特化したブランドの場合、または実際の物理的な施設がある場合のみです。フッターに連絡先住所を1か所記載するのは問題ありませんが、雰囲気づくりのロケール表示は避けてください。
スクロールの手がかりは禁止です。 Scroll、↓ scroll、Scroll to explore、Scroll to walk through it、アニメーション付きのマウスホイールアイコンなどです。ユーザーがまだスクロールしていないなら、ヒーローを見ています。スクロールの方法はわかっています。ビューポートの下端にラベルを付ける必要はありません。
装飾目的のステータスドットは、デフォルトで一切使わないでください。 ナビゲーション項目、リスト行、バッジ、ステータスラベルの前に色付きのドットを置くのは、見抜かれるポイントです。実際の意味のある状態（実際のサーバー状況を示すライブインジケーター、稼働状況を示すフラグ）を伝える場合に限り許容され、ページの各セクションで1つまでです。

9.G EMダッシュ禁止（最もよく見抜かれる要素）

EMダッシュ（—）は完全に禁止です。 これはLLMが多用する文体上の癖であり、制作物で最も目につく要素です。「使用は控えめに」「自然な文章の範囲ならよい」「本文なら問題ない」といった例外は一切ありません。

見出しでの使用は禁止です。 ピリオドかコンマを使ってください。
アイブロウ、ラベル、ピル、ボタンのテキスト、画像キャプション、ナビゲーション項目での使用は禁止です。 改行、列、細い罫線で置き換えてください。
本文での使用は禁止です。 文を組み直してください。ピリオドで2文に分けるか、コンマ、括弧、コロンを使ってください。
引用の出典表記での使用は禁止です。 通常のハイフンを前後にスペースを入れて使う（-）か、改行して名前を小さめのウェイトで表示してください。
区切りとして使うエンダッシュ（–）も禁止です。 日付の範囲（2018-2026）にはハイフンを使ってください。数値の範囲（€40-80k）にもハイフンを使ってください。

ページで使用できるダッシュ文字は、次のものだけです。

通常のハイフン -（複合語、範囲、マークアップの区切り線に使用）
数式のマイナス記号（-5°C）

ユーザーに見える出力に — または – が1文字でも含まれていると、出力は事前チェックに不合格となり、書き直す必要があります。

このルールに例外はありません。これまでもエージェントは「控えめに使う」と表現すると、EMダッシュの制限を無視してきました。ここでは二者択一のルールです。EMダッシュは一切使えません。

11. 再設計プロトコル

このスキルは、新規構築と再設計の両方に対応します。モードを誤って分類することが、再設計の成果物の品質を損なう最大の原因です。

11.A モードを判定する（最初のアクション）

新規構築 - 既存のサイトがない、または全面的な刷新が承認されている場合です。セクション 1 の基準値を設定します。
再設計 - 維持 - ブランドを損なわずにモダン化します。まず監査を行い、ブランドトークンを抽出して、段階的に進化させます。
再設計 - 全面刷新 - 既存コンテンツを維持しながら、新しいビジュアル言語を適用します。ビジュアル面は新規構築として扱い、コンテンツと IA は維持します。

曖昧な場合は、一度だけ確認します。「この再設計では既存のブランドを維持しますか。それとも、ビジュアル面を一から作り直しますか？」

11.B 変更に着手する前に監査する

変更を提案する前に、現状を記録します。

ブランドトークン - プライマリーカラー／アクセントカラー、フォントスタック、ロゴの扱い、角丸。
情報アーキテクチャ - ページツリー、主要ナビゲーション、主要なコンバージョン経路。
コンテンツブロック - 何が存在し、何が機能していて、何が埋め草なのか。
維持するパターン - 特徴的なインタラクション、認識されやすいヒーロー、コピーの語り口。
廃止するパターン - AI スロップの兆候、壊れたレイアウト、リンク切れ、ありきたりなストック画像、パフォーマンス上の問題。
既存サイトのダイヤル値 - 現在の DESIGN_VARIANCE ／ MOTION_INTENSITY ／ VISUAL_DENSITY を推定します。これが出発点であり、基準値ではありません。
SEO の基準値 - 現在の検索順位が高いページ、メタタイトル、構造化データ、OG カード。SEO の移行は再設計における最大のリスクです。

11.C 維持に関するルール

指示がない限り、情報アーキテクチャを変更しないでください。SEO と慣れた操作感を維持するため、ページのスラッグ、アンカー ID、主要ナビゲーションのラベルは変更しないでください。
セクション 4.2 を適用する前に、ブランドカラーを抽出してください。すでに紫色のブランドであれば、紫色のまま維持します。LILA RULE の上書きを適用してください。
書き直しの指示がない限り、コピーの語り口を維持してください。ビジュアルのモダン化は、コンテンツの書き直しとは異なります。
既存のアクセシビリティ上の利点を尊重してください。フォーカス状態、代替テキスト、キーボード操作、コントラストを後退させないでください。
既存の分析イベントを尊重してください。後続のトラッキングに依存するボタン、フォームフィールド、セクション ID の名前を変更しないでください。

11.D モダン化の手段（優先順位順）

順番に適用し、依頼内容を満たした時点で止めてください。

タイポグラフィの刷新 - リスク単位あたりのビジュアル面での向上が最も大きい手段です。
余白とリズム - セクションのパディングを増やし、垂直方向のリズムを整えます。
カラーの再調整 - 彩度を下げ、中間色を統一し、ブランドのアクセントカラーを維持します。
モーションレイヤー - 既存コンポーネントに MOTION_INTENSITY に応じたマイクロインタラクションを追加します。
ヒーローと主要セクションの再構成 - references/pattern-vocabulary.md の語彙を使って、ファネル上部を再構成します。
ブロック全体の置き換え - 既存ブロックを修復できない場合に限ります。

11.E 判断ツリー：部分的な進化か全面的な再設計か

IA、コンテンツ、SEO に問題がない → 部分的な進化（手段 1～4）。リスク約 40% で価値の約 70% を実現できます。
ビジュアル上の負債が構造的である（IA が壊れている、デザインシステムがない、モバイル表示が壊れている） → コンテンツの厳密な維持を前提とした全面的な再設計。
ブランド自体が変わる → 新規構築。

11.F 明示的な承認なしに変更してはならない項目

ユーザーの明示的な承認なしに、次の項目を変更しないでください。

URL 構造／ルートのスラッグ。
主要ナビゲーションのラベル。
フォームフィールドの名前や順序（分析や自動入力に影響します）。
ブランドロゴやワードマーク。
既存の法務、同意、Cookie に関する文言。

12. ブロックライブラリ（契約 - 実装は段階的に追加）

リファレンス語彙（references/pattern-vocabulary.md）ではパターンを定義します。ブロックライブラリでは、実際の props、モーション仕様、コード例を用いてそれらを実装します。

ステータス： スキーマはここで定義されています。ブロックは段階的に追加されます。このスキーマに従わずに独自のブロックを作らないでください。

12.A ファイルの場所

skills/taste-skill/blocks/
  hero/
    asymmetric-split.md
    editorial-manifesto.md
    kinetic-type.md
    ...
  feature/
    bento-grid.md
    sticky-scroll-stack.md
    zig-zag.md
    ...
  social-proof/
  pricing/
  cta/
  footer/
  navigation/
  portfolio/
  transition/

12.B 必須のフロントマター

---
name: asymmetric-split-hero
category: hero
dial_compatibility:
  variance: [6, 10]
  motion: [3, 10]
  density: [2, 5]
when_to_use: "Landing pages with one strong asset and one strong message. Default hero for SaaS, agency, premium consumer."
not_for: "Editorial / manifesto launches where the message IS the design."
stack: ["react", "next", "tailwind", "motion"]
---

12.C 必須の本文セクション

ビジュアルスケッチ - 簡単な ASCII 表現、またはレイアウトの説明。
Props API - コンポーネントのインターフェース。
コードスケッチ - 最小限の動作する実装（デフォルトはサーバーコンポーネント、モーションにはクライアントアイランドを使用）。
モバイルでのフォールバック - < 768px での明確な折りたたみルール。
モーションバリアント - MOTION_INTENSITY の各範囲（1-3、4-7、8-10）につき 1 つのバリアント。動きを減らす場合のフォールバックも明示します。
ダークモードに関する注記 - このブロック固有のトークン戦略。
アンチパターン - このブロックでよくある問題。
参考資料 - 実運用での実例へのリンク。

12.D ブロックライブラリの規律

1 ファイルにつき 1 ブロックとします。複数のブロックを 1 つのファイルに含めてはいけません。
すべてのブロックは単独で動作する必要があります（ページに配置するとレンダリングされます）。
すべてのブロックは、事前チェック（セクション 14）に合格する必要があります。
セクション 2.A のデザインシステムに依存するブロックは、blocks/<category>/<name>--<system>.md（例：feature/bento-grid--material.md）の下に配置します。

13. 対象範囲外

このスキルの対象外：

ダッシュボード／情報量の多いプロダクト UI／管理パネル（セクション 2.A の Fluent、Carbon、Atlassian、または Polaris を使用してください）。
データテーブル（TanStack Table または AG Grid を使用してください）。
複数ステップのフォーム／ウィザード（フォーム固有のパターンを使用してください。このスキルでは改善できません）。
コードエディター（公式のスキンを備えた Monaco／CodeMirror を使用してください）。
ネイティブモバイル（Apple HIG／Material を直接使用してください）。
リアルタイムコラボレーション UI（プレゼンス、カーソル、OT 対応など。異なる種類の問題です）。

ブリーフが上記のいずれかに該当する場合は、対象外であることを明示し、適切なツールを案内したうえで、このスキルのマーケティングページ／概要ページ／ランディングページ向けの部分を、適用できる箇所にのみ使用してください。

情報量の多いプロダクト UI に関して（ダッシュボード、データテーブル、フォーム、複数ステップのフロー、設定、アプリシェル）、このスキルに対応する専用スキルは product-ui-taste です。このスキルの代わりに（またはマーケティング画面とプロダクト画面が分かれている場合は併用して）使用してください。このスキルが意図的に対象外としている、フレーム優先／カードではなく行／オーバーフロー／状態マトリクス／データテーブル／アクセシビリティの厳格な要件をカバーしています。

14. 最終事前チェック

コードを出力する前に、このマトリクスを実行してください。これが最後のフィルターです。

これは任意ではありません。すべての項目を実行してください。1 つでも不合格なら、出力は未完成です。

参考資料（ベンダー提供の参考資料。本文から移動済み）

references/pattern-vocabulary.md - 完全版のリファレンス用語集（エージェントが把握しておくべきパターン名）。
references/motion-skeletons.md - 5.A Sticky-Stack、5.B Horizontal-Pan、5.C Scroll-Reveal Stagger パターンの標準的な tsx コードスケルトン。
references/design-systems-install.md - セクション 2 で言及されている各デザインシステムの実際のインストールコマンド。
references/canonical-sources.md - 各デザインシステムの標準ドキュメントへのリンク。独自に考案する前に、こちらを確認してください。
references/liquid-glass.md - Apple Liquid Glass の公式仕様に含まれるものと含まれないもの、およびラベル付きの Web CSS による近似表現。

Markdown 対応

ログインしてコメント

基本情報

作者: huytieu
リポジトリ: huytieu/cog-second-brain
カテゴリ: デザイン・UI
インストール数: 120
GitHub スター: 1,329

問題を報告