cinematic-ui

Cinematic Layout

Primary Platforms

このスキルは、主要なランタイムである Claude Code と OpenAI Codex 向けに構築・保守されています。

Claude Code

• /cinematic-ui で呼び出します。
• プロジェクトのメモリと Claude 固有のメモは CLAUDE.md にあります。
• インストール先（Windows）：C:\Users\<your-user>\.claude\skills\cinematic-layout
• インストール先（macOS / Linux）：~/.claude/skills/cinematic-ui

OpenAI Codex / ChatGPT

• Codex 固有のコンテキストは CODEX.md にあります。
• インストール先：$CODEX_HOME/skills/cinematic-ui

追加の互換性ファイル：

• GEMINI.md — Gemini / Antigravity スタイルのワークフロー
• AGENTS.md — ツール共通のリファレンス
• .github/copilot-instructions.md — GitHub Copilot
• .cursor/rules/cinematic-ui.mdc — Cursor（クローン時に自動読み込み）
• .windsurf/rules/cinematic-ui.md — Windsurf（クローン時に自動読み込み）

---

汎用的なランディングページではなく、映画の制作現場のようにサイトをデザインしてください。 これは、リサーチと翻訳のスキルであると同時に、デザインライブラリのスキルでもあります。映画の参考作品を調査し、活用可能な映画的な特徴を抽出して、それをページのナラティブ、セクション構成、モーションの方向性、実装可能なウェブ仕様へと変換します。 中核となる仕組みは固定されています。監督と特定の映画を使ってサイトの感情表現を決め、それをウェブの構造と実装へ翻訳します。これを汎用的な高級ブランドのロジックに置き換えないでください。 映画とワークフローの成果物を混同しないでください。映画はリサーチの入力であり、感情の源となる素材です。コンピューター上で実行可能なワークフローは、それらの観察内容が decisions.md、storyboard.md、compiled-spec.md、実装へと翻訳されて初めて始まります。

開始

• 呼び出すたびに、フェーズ 1 の開始前に開始時の質問事項をすべて完了してください。
• 質問事項が完了するまでは、decisions.md、監督の選定、映画の選定、アーキテクチャ、ビジュアル計画に進まないでください。
• すべての質問と成果物で、ユーザーの言語に合わせてください。
• 質問は簡潔にし、作業を妨げる質問を一度に 1 つだけ尋ねてください。
• 呼び出すたびに、次の開始時の質問を行ってください：
  1. 開始方法を尋ねます：
  • Screenshot：画像または URL をもとに、ビジュアルの参考例をリバースエンジニアリングします。
  • Step-by-step：ユーザーがジャンル、監督、映画を選びます。
  • Surprise me：プロジェクトの履歴を参照できる場合は、これまでの作業とは異なる新しい組み合わせを選びます。
  2. デザインに画像のプレースホルダーを含めるかどうかを尋ねます。
  3. アーキテクチャに進む前に、サイトのニッチとページ一覧を尋ねます。
• 環境が構造化された質問票やフォームに対応している場合は、それらを使用してください。
• 環境が構造化された質問票に対応していない場合は、同じ項目を自然な言葉で尋ねてください。
• ユーザーが最初のリクエストで一部の項目に回答している場合は、その回答を確認または記録し、不足している項目だけを尋ねてください。
• 必要な開始時の質問事項すべてに回答があるか、ユーザーのリクエストから明示的に推定できた後にのみ、フェーズ 1 を開始します。

デモの独自性に関するプロトコル

同じユーザーがこのスキルを使って、すでにほかのサイト、デモ、またはホームページのコンセプトを1つ以上作成している場合は、必ずこのプロトコルに従ってください。

• 同じユーザーの過去の出力は、再利用できるひな型ではなく、デザイン履歴のコンテキストとして扱ってください。
• Phase 1 を完了する前に、可能な場合は直前の出力を確認し、独自性の監査結果を decisions.md に記録してください。
• 繰り返されやすい特徴を挙げた Previous-work audit を作成してください。例：
  • 左にコピー、右にオブジェクトを配置したヒーロー
  • 上部ナビゲーションと、縦に積み重ねた枠付きパネル
  • 角丸のプレミアムカードの繰り返し
  • ピル型のメタデータ行
  • 細い境界線を用いたダークな高級感のある配色
• 新しいプロジェクトで使わないレイアウト特徴を挙げた Shell-ban list を作成してください。これらは、新しい制作物が過去の制作物に似すぎるのを防ぐため、明示的に禁止する特徴です。
• ページのデザインを始める前に、新しいプロジェクトの Primary composition family を決定してください。例：
  • 全面に広がるステージ
  • 回廊
  • 垂直の塔
  • アーカイブの壁
  • パノラマ状の一枚板
  • 内部を切り取った一枚岩
• ユーザーが意図的な続編を明示的に求めない限り、新しいプロジェクトでは、ユーザーの直近の類似した制作物とは異なる主要な構成ファミリーを選んでください。
• ユーザーが時間をかけて複数の異なるサイトを依頼する場合、色やタイポグラフィだけでなく、サイトのシェル、ヒーローの見せ方、セクションのリズム、ナビゲーションの構成、密度のパターン、主要な幾何学的形状の違いを優先してください。
• 色、書体のスタイル、装飾効果を取り除いても、ワイヤーフレームが以前のデモに見える場合、新しいデモは不合格です。
• プロジェクト履歴を参照できない場合は、その旨を明記したうえで、陥りやすい一般的なひな型を避けるための Shell-ban list も作成してください。

運用モデル

4つの厳格なフェーズに従ってください。先のフェーズに飛ばしてはいけません。各フェーズの出力は、作業中のプロジェクト内の個別の Markdown ファイルに保存してください。

1. Phase 1：意思決定
2. Phase 2：ストーリーボード
3. Phase 3：仕様の確定
4. Phase 4：構築と検証

Phase 2 と Phase 3 では、次の順序を守り、省略しないでください。

1. サイト全体のシネマティックな表現のルールを定義する。
2. 主要なページの役割ごとに、独立したシーンの主題を書く。
3. ページごとに、代替できないシグネチャー構成を1つ固定する。
4. ページの構成が明確になってから、共通システムを導き出す。

これらのファイルを作成する前に、references/output-templates.md を読んでください。

委任モデル

• 環境がサブエージェントや並列ワーカーに対応している場合は、ディレクターと作品が決まった後、原則として活用してください。
• サイト全体のシネマティックな表現のルールと、最終的な一貫性には、主担当のエージェントが責任を持つようにしてください。
• 次のような、範囲を限定した補助タスクを委任してください。
  • 作品やニッチな分野の参考情報の調査
  • 個別ページの役割に応じたシーンの検討
  • ページの役割が重複しない仕様の草案作成
  • 別ファイルでの実装または検証
• 複数のエージェントが、それぞれ独自にディレクター、作品、サイト全体のビジュアル上の主題を再定義しないようにしてください。
• 委任した作業を、ひとつの統一されたシステムにまとめてください。完成物が委員会の制作物ではなく、ひとつの作品として感じられる必要があります。
• タスクが小さく委任の効果がない場合や、環境がサブエージェントに対応していない場合を除き、委任を省略しないでください。

段階的な読み込み

SKILL.md は簡潔に保ってください。現在のフェーズに必要な参考資料だけを読み込んでください。

常に最初に読む

• references/library-index.md
• references/premium-calibration.md

フェーズ 1：決定事項

• references/data/directors-200.md のみを読みます。
• サブエージェントが利用できる場合は、ユーザーの方向性が明確になった後、映画のリサーチ、ニッチのリサーチ、または参考資料の分析を、それぞれ範囲を限定したタスクとして委任します。
• ユーザーがワークスペースに過去のサイトやデモを置いている場合は、繰り返してはいけない要素を特定するのに必要な範囲で確認します。
• ユーザーがスクリーンショットや実際のサイトを起点にしている場合は、まずその参考資料を調べ、想定されるジャンル、監督、映画を推測します。確定する前にユーザーの確認を求めます。
• ウェブアクセスが可能な場合は、このフェーズを完了する前に、選定した監督と映画をリサーチします。これは必須であり、任意ではありません。
• 外部ソースを使って、次のような創作に役立つ情報を集めます。
  • 映画の色調と照明の特徴
  • 撮影のパターン、フレーミングの論理、シーンのリズム
  • プロダクションデザインや素材の手がかり
  • 監督特有の技法
  • 同じニッチ分野のプレミアムサイトを2〜3件
• 利用できる場合は一次情報源または権威ある情報源を優先し、解釈を深めるために二次分析を追加します。
• リサーチの情報源と、解釈についての短いメモを記録します。あらすじや一般的な豆知識を羅列しないでください。
• ウェブアクセスを利用できない場合は、その旨を明示し、ローカルライブラリから可能な範囲で推測を続けます。リサーチが通常より限定的であることを記録します。
• ユーザーから参考資料が提供された場合、それをそのまま模倣しないでください。references/reference-protocol.md を読み、リズム、素材感、タイポグラフィ、フレーミング、画像処理などの特徴に分解します。
• 独自性の監査結果、使用禁止シェルの一覧、主要な構成ファミリーを decisions.md に記録します。
• decisions.md を作成します。

フェーズ 2：ストーリーボード

• 以下のファイルを、一度にすべてではなく、1つずつ読みます：
  • references/anti-convergence.md
  • references/data/hero-archetypes.md
  • references/data/narrative-beats.md
  • references/data/section-functions.md
  • references/data/section-archetypes.md
• references/data/dna-index.tsvを使い、ムード、フォントの方向性、形状の表現、モーション、抑制、密度、素材の豊かさを基準に、相性のよいデザインDNAのソースを2〜3個選びます。
• 有望なソースがインデックスで示され、サイトレベルのDNAの詳細がさらに必要な場合にのみ、references/data/design-dna-db.txtを読みます。
• 個々のページをデザインする前に、サイト全体のシネマティックな文法を定義します。以下を記録します：
  • ページシェルのロジック
  • ナビゲーションの姿勢
  • フレーミングのルール
  • 密度のリズム
  • 繰り返し登場する素材や雰囲気のレイヤー
  • 選んだ映画に合う構成の系統
• 選択したページシェルのロジックと構成の系統が、フェーズ 1 のシェル禁止リストに違反しないことを確認します。
• 監督ブリーフを作成し、以下を含めます：
  • ビジュアルの主張を一文で表したもの
  • 3つの特徴的なテクニックと、それらをウェブ向けに翻訳したもの
  • 正確なカラーのトークン
  • タイポグラフィの方向性
  • モーションのルール
• references/premium-calibration.mdにあるプレミアム調整を実施します。
• 主要なページの役割ごとに、共通コンポーネントを定義する前に、個別のシーンの主題を書きます。各ページをまず独立したシーンまたはポスターとして扱い、その後、ページを1つのサイトとしてつなげます。
• サブエージェントを利用できる場合は、サイト全体のシネマティックな文法が承認された後に限り、異なるページの役割を別々のエージェントに割り当てます。
• ページごとに、ページレベルのビジュアルの主題を1つ定義します。これは、そのページを印象に残るものにする、支配的なアイデアです。例：モニュメンタルなタイポグラフィ、彫刻的な光、エディトリアルなフレーミング、虚無と輝き、舞台となるオブジェクト。ほかのすべての要素は、このアイデアを支えるものとし、競合させません。
• 汎用的なグラデーションや一般的なアプリUIに頼らず、ヒーローが高級感やシネマティックな印象を与える理由を正確に説明する、ヒーローの優位性に関する声明を書きます。
• 再利用可能なレイアウトの基本要素を導入する前に、ページごとに代替不可能な特徴的な構成を1つ定義します。
• 既定のHero -> Features -> Stats -> CTAに頼らず、各ページを物語の展開に沿って構成します。
• ヒーローの類型、物語の展開、セクションの類型を選ぶ際は、references/anti-convergence.mdの収束回避システムを適用します。
• storyboard.mdを作成します。
• 共同作業または探索的なタスクの場合は、フェーズ 3 に進む前にユーザーの承認を得ます。

フェーズ 3：コンパイル済み仕様

• 最終的な CSS と JS を抽出する前に、references/implementation-guardrails.md を読みます。
• 承認済みのストーリーボードに必要な項目だけを読みます。
  • references/data/camera-shots-50.md
  • references/data/interaction-effects-50.md
  • references/data/compositions.md
  • references/data/visual-elements.md
  • references/data/background-techniques.md
  • references/data/typography-cinema.md
  • references/data/color-grades.md
  • references/data/font-moods.md
  • references/data/textures.md
• 仕様を確定する前に、references/anti-garbage.md を読みます。
• 共通のレイアウトプリミティブを導き出す前に、各ページの特徴的な構図を確定します。
• 共通システムは最後に扱います。ナビゲーション、フッター、スペーシングのリズム、タイポグラフィ、トークン、ユーティリティの抽出は、ページ固有の構図が明確になってから行います。
• サブエージェントを利用できる場合は、ページ仕様の抽出または実装タスクを重複しないように割り当て、リードエージェントがレビューして統合します。
• インタラクションの厳格な予算を守ります。
  • ページあたりの重いインタラクションは最大 1 つ
  • ページあたりの注意を引くリビールパターンは最大 2 つ
  • それ以外の動きは、そのページのビジュアル上の主題を引き立てる範囲にとどめます
• 気の利いた効果を多用するより、数を絞って印象的な演出を優先します。
• プレミアムな印象は、アニメーションだけでなく、サーフェス、スペーシング、文字の階層、エッジ処理、大気感のあるレイヤーで表現します。
• Grid と flex は、見えない整列の基盤として使用できます。ただし、選んだ映画の表現が明確に支持していない限り、目に見える構図を標準的なカードのマトリクスにしてはいけません。
• セクションの仕様を書く前に、ページごとのエントランスマップを作成します。
• fadeUp / opacity + translateY は、ページあたり最大 2 回まで使用できます。
• ページに十分なセクションがある場合は、ページごとに少なくとも 4 種類の異なるエントランスタイプを使用します。
• 選択したインタラクション効果の ID が references/implementation-guardrails.md において JS 必須とされている場合は、完全な JS を compiled-spec.md に記載する必要があります。
• references/implementation-guardrails.md の External Library Decision ブロックを compiled-spec.md に含めます。
• 仕様を完成とみなす前に、references/implementation-guardrails.md のフェーズ 3 品質チェックリストを実行します。
• 適切なライブラリエントリーがすでにある場合は、記憶を頼りに主要なインタラクションや大気感を生み出す演出を考案しません。
• ページごとに、次の項目について選択したライブラリソース ID を記録します。
  • カメラ／リビールの挙動
  • インタラクションの挙動
  • 構図
  • タイポグラフィの処理
  • 使用する場合は、大気感のある背景テクニック
• 重いインタラクション、際立つリビール、ヒーローの大気レイヤー、特徴的な構図には、すべて compiled-spec.md 内でライブラリエントリー ID を明記します。
• カスタム効果が依然として必要な場合は、明示的に Custom と記載し、ライブラリでは不十分な理由を説明したうえで、選んだ映画の表現に従属させます。
• レイアウト、エントランス、インタラクションの CSS をすべて抽出します。
• 選択したインタラクションで必要な場合は、完全な JS を含めます。
• 実装に関する唯一の信頼できる情報源として compiled-spec.md を作成します。

フェーズ 4：構築と検証

• 次のものだけを読みます。
  • compiled-spec.md
  • references/anti-garbage.md
  • references/implementation-guardrails.md
• 新たなレイアウトロジックを即興で加えず、仕様に基づいて構築します。
• 選んだ映画の表現を損なわずに、動きを抑える設定への対応とレスポンシブな挙動を追加します。
• 出力をストーリーボードおよびコンパイル済み仕様と照らし合わせて検証します。
• 初回構築後に結果を調整する際は、references/implementation-guardrails.md の Screening Room と Post-Screening Adjustments のルールを使用します。

厳守事項

• 選択した監督と映画の表現言語を、色、書体、余白、構図、動きで一貫して表現してください。
• 感情表現の主な源は、監督と映画にしてください。プレミアムな調整は、選択した映画の固有の表現を上書きするのではなく、仕上がりを研ぎ澄ますために使ってください。
• 監督名、映画のタイトル、チャプターマーカー、調整に関する専門用語、ワークフローのメタデータは、通常、作業ファイル内にとどめ、ユーザー向け UI には表示しないでください。
• ユーザーがメタ的・編集的な表現を明示的に求めない限り、最終インターフェースに chapter、director、film、calibrated、report build、treatment などのプロセスに関する用語を表示しないでください。
• セクションごとのリズムに変化をつけてください。見せ場、情報量の多い箇所、余白のある箇所を織り交ぜてください。
• ページに十分なセクションがある場合、少なくとも4種類の異なる登場パターンを使ってください。
• 隣り合うセクションで、同じ見せ方を繰り返さないでください。
• 単なるテキストブロック以外の視覚的な構成要素を加えてください。ヒーローセクションには少なくとも3つ、その他の大半のセクションには少なくとも1〜2つの視覚的な要素を含めてください。
• 各ページは、ひとつの大きな視覚的アイデアを中心に、読みやすく構成してください。すべてのセクションで新しいコンセプトを持ち込まないでください。
• まずサイト全体の映画的な表現文法を定義し、次に各ページのシーンを定め、置き換えのきかないページ構成を決めてから、共通システムを設計してください。
• 同じユーザー向けの過去の成果物がある場合は、ワイヤーフレームの段階で明確に差別化してください。色、コピー、表層的なスタイルだけを変えた、以前のサイトと同じ外枠を新しいサイトで使い回さないでください。
• 下層ページは、ホームページを簡略化したものではなく、同じ映画の中の新しいシーンとして感じられるようにしてください。
• 主要なページの役割ごとに、汎用的な製品マーケティング用のグリッドやデフォルトのテンプレートレイアウトでは置き換えられない、独自の構図をひとつ用意してください。
• サイトのスタイルは、色、タイポグラフィ、表層的なスタイルだけでなく、レイアウト、テンポ、階層、構図を通じて、ホームページとすべての主要なページの役割に選択した監督の表現が反映されるまで、完成とみなさないでください。
• グリッドは構成の土台として扱い、構図そのものとはみなさないでください。セクションが汎用的な2列2行または3列の商品グリッドとしてそのまま機能してしまうなら、構図が弱すぎます。
• まず各下層ページを独立したシーンとして設計してください。共通パターンは、それらのシーンを平板化するのではなく、支えるものでなければなりません。
• 抑制もデザインの手段として扱ってください。上質なデザインでは、明白な演出をさらに20％加えるより、20％取り除くことがよくあります。
• 曖昧な形容詞より、正確なトークンと実装上の指示を優先してください。
• ウェブ上の調査や参照サイトが利用できない場合は、その制約を明示し、立ち止まらずに、入手可能な情報から最善の推定を続けてください。
• 映画そのものを仕様書、コンポーネント一覧、コンピューターのワークフローとして扱わないでください。まず映画作品として調査し、その後、ウェブ上での表現へと必要な要素だけを落とし込んでください。

アンチパターン

• 元の映画が本当にその表現を支持している場合を除き、コピーを中央に配置した汎用的なグラデーションのヒーローを出力しないでください。
• ヒーローやナビゲーションに、監督名、映画のタイトル、チャプターラベル、ワークフロータグを、プレミアム感を装うマイクロコピーとして透かしのように表示しないでください。
• すべてのセクションで、同じホバー、表示、カードのパターンを使い回さないでください。
• ページをモーションのデモやエフェクトの見本集にしないでください。
• 参照サイトをレイアウトのテンプレートとして使わないでください。構図全体ではなく、品質の要素を取り入れてください。
• 共通コンテナや再利用可能なカードによって、ページ固有のシーンのアイデンティティを損なわないでください。
• ページごとの構図を確定する前に、共通コンポーネントシステムを決めないでください。
• ユーザーが継続性を明示的に求めない限り、以前のデモのヒーローの構え、ナビゲーションの構え、セクションのリズム、主要な幾何学的形状を使い回さないでください。
• ライブラリ全体を一度に読み込まないでください。
• decisions.md、storyboard.md、compiled-spec.md を作成せずに、ユーザーの依頼から HTML に直接進まないでください。

ファイルガイド

• 読み込むライブラリを決める際は、references/library-index.md を使用してください。
• 成果物の構成には、references/output-templates.md を使用してください。
• 映画的なコンセプトを損なわずにページを高級感のあるものにする方法を決める際は、references/premium-calibration.md を使用してください。
• ユーザーがビジュアルの参考資料を提示しているものの、テンプレートの模倣を避けたい場合は、references/reference-protocol.md を使用してください。
• コーディング前の最終チェックには、references/anti-garbage.md を使用してください。