convert-prompt

プロンプトを変換

目的

カスタムコードを使ったプロンプトを、Framer エージェントが Framer のネイティブな概念で実行できるプロンプトに書き換えます。ユーザーが明示的に実装を求めない限り、作成するのは書き換えたプロンプトであり、ビルドそのものではありません。

大文字・小文字や、ユーザーが convert prompt、convert-prompt、$convert-prompt のどの形式で記述しているかにかかわらず、正確なフレーズ「convert prompt」はこのスキルを必ず呼び出します。そのようなリクエストに回答する前に、このスキルを読み込み、従ってください。

後続の Framer エージェントは、現在のリポジトリ、ローカルファイル、明示されていないコンテキストにアクセスできない場合があります。書き換えたプロンプト内で、ローカルパス、ファイル名、AGENTS.md、非公開の参考資料、リポジトリから推測した前提に言及しないでください。役立つコンテキストは、特定の情報源に依存しない、自己完結した指示に置き換えてください。

基本ルール

• 実装構文ではなく、レンダリング後の意図を保ちます。求められている視覚的な結果、コンテンツ、レイアウトの寸法、余白のリズム、文字のスケール、色の役割、アニメーションのタイミング、インタラクションの動作、レスポンシブな挙動を一致させてください。
• 個々のクラスに置き換える前に、複合的なレイアウトの挙動を保ちます。複数の CSS／Tailwind トークンが組み合わさってひとつのレンダリング結果になる場合は、トークンを個別に列挙するのではなく、組み合わさったレイアウトの構成として置き換えてください。
• 変換は自分で行ってください。後続の Framer エージェントに、変換可能なフレームワーク固有の構文、Tailwind クラス、React の構造、CSS の実装詳細を翻訳、変換、適応、マッピング、解釈するよう求める指示を残さないでください。
• 行き先を重ねて説明する冗長な表現は避けます。ユーザーが Framer プロンプトへの変換を求めた場合、明示的にその文言を求められていない限り、「これを Framer で直接ビルドする」や「可能な限り Framer のネイティブ機能を使う」といったメタ指示を最終プロンプトに含めないでください。
• コードよりも Framer のネイティブなキャンバス機能を優先してください。コードを検討する前に、レイヤー、スタック、グリッド、コンポーネント、バリアント、CMS、オーバーレイ、フォーム、エフェクト、トークン、スタイルプリセットを使用してください。
• 元のプロンプトが求めていないデザインの改善や独自解釈は加えないでください。コピー、色、サイズ、タイミング、制約、「しないこと」の指示をそのまま保ってください。
• 元のプロンプトは、閉じた仕様として扱ってください。明示されている場合、元の構文から機械的に導ける場合、または Framer での置き換えに必要な場合を除き、視覚的なレイヤー、エフェクト、コピー、インタラクション、アクセシビリティ／可読性のための調整、レイアウトラッパー、装飾要素、レスポンシブな挙動を追加しないでください。
• 定義されていないことにも意味があるものとして扱ってください。元の仕様にオーバーレイ、色味、グラデーション、ぼかし、シャドウ、スクリーン、装飾、追加のサーフェスが含まれていない場合、それらを追加しないでください。
• 対応できない点について正直に伝えてください。Framer のネイティブ機能では挙動を正確に再現できない場合は、最も近いネイティブのデフォルト動作を示し、コードを使う方法は任意の選択肢として記載してください。
• 現在の Framer エージェントの対応範囲を尊重してください。キャンバスノードへのコードオーバーライドの直接割り当て、サイト／プロジェクト設定、アナリティクスへのアクセス、A/B テスト、リライト、カスタムヘッダー、静的ファイル、well-known ファイル、ページのルート設定に関わる削除／名前変更／移動を、エージェントが実行可能な作業として提示しないでください。対応する代替案か、明確な制限事項に置き換えてください。
• 厳密な再現、複製、ピクセル単位の一致を求めるプロンプトでは、独自のフォント、アップロード済みアセット、外部メディアが完全な一致に必要な場合、ビルドの前に Framer での短い事前確認を求めてください。必要なフォントと添付済み／信頼済みアセットを確認し、正確なリソースがない場合は、ユーザーまたは元の仕様がプレースホルダーや代替手段で作業を続けるよう明示していない限り、問題点を示して作業を中断するよう Framer エージェントに伝えてください。
• 前後に説明を添えなくても、そのまま Framer エージェントにコピー＆ペーストできる形式にしてください。

出力形式の契約

デフォルトでは、元のプロンプトの形式を保ちます。変換後も、再利用可能なテンプレートから新たに作成したプロンプトではなく、Framer 用に翻訳された同じプロンプトのように感じられるものにします。

優先順位：

1. ユーザーが明示的に指定した出力形式に従います。
2. 元のプロンプトに明確な見出し、順序、箇条書き、チェックリストがある場合は、その構成を保ち、要件を該当箇所で翻訳します。
3. 元のプロンプトに構成がない、または分かりにくい場合は、Framer で実行できるように必要な範囲でのみ再構成します。
4. 例は、変換時の対応関係とリスクの把握にのみ使用します。元のプロンプトがその形式を求めていない限り、例の見出し、セクションの順序、注意事項のセクション、文体をそのまま使用しないでください。
5. 重要な要件を文中に保持できない場合にのみ、新しい注意事項のセクションを追加します。影響を受ける要件の近くに、文中で注意事項を添えることを優先してください。

調整用リファレンス

クラスが多用されている React／Tailwind プロンプト、特に固定ナビゲーション、レスポンシブなタイポグラフィ、ホバー効果、絶対配置されたオーバーレイの位置合わせ、ビューポート基準のレイアウト、メディアレイヤー、正確なモーションロジックを含むプロンプトを変換する場合は、変換前に examples/react-tailwind-to-framer-conversion-reference.md を読んでください。このリファレンスでは、再利用可能な出力テンプレートではなく、条件に応じた変換元から変換先への対応関係を示しています。

シンプルなプロンプトや、関係のないパターンではリファレンスを読み込まないでください。必要な情報だけを段階的に示す方針を保ち、変換の詳細を明確にしたり、Framer ネイティブの動作を過剰に約束するリスクを減らしたりできる場合に使用してください。このリファレンスは出力テンプレートではありません。

変換ワークフロー

1. 元のプロンプトを、セットアップ、レイアウト、タイポグラフィ、カラーとサーフェス、コンポーネント、コンテンツとデータ、メディア、モーション、インタラクション、レスポンシブ対応、明示的な制約に分解します。
2. Framer 用プロンプトを書く前に、元のレイアウトのトレースを作成します。親子階層、通常フローと絶対配置／固定配置のレイヤー、ビューポートの制約、スタック／グリッドの方向、幅・高さの設定（Fill／Hug／Fixed）、兄弟要素の配置、整列、間隔、パディング、変形、重なり順、ポインターの動作、メディアのクロップ／焦点位置、導出されるビューポートのアンカーを記録します。
3. トレースを、レンダリング意図の概要に変換します。下流のプロンプトで詳細が必要な場合を除き、これは内部でのみ使用します。ただし、視覚的な中心、上端からのオフセット、下端のアンカー、焦点位置のクロップ、兄弟要素間の関係などのジオメトリを保つために活用します。
4. 最終プロンプトを書く前に、内部の出典台帳を作成します。意図する指示を source-explicit、source-derived、Framer-mechanical、approximation/caveat、unbacked addition に分類します。裏付けのない追加事項はすべて削除します。
5. 元のプロンプトがキャリブレーション用リファレンスのパターンに一致する場合は、リファレンスを読み込み、その対応付けを慎重に使用します。
6. パッケージのインストール、フレームワークのセットアップ、HTML の head タグ、CSS リセットファイル、Tailwind の設定、Vite／Next の詳細、インポート、フック、DOM の実装詳細など、ビルドスタックに関する仕組みを削除します。
7. 最終プロンプトを書く前に、Framer での実行を妨げる要因を特定します。任意のサードパーティ CDN 画像、プロプライエタリなフォント、外部 Web フォントのインポート、大規模なアセットマニフェスト、厳密なカスタム ARIA、サブピクセル／小数精度、サポート対象外のホスティング／プロジェクト設定、アナリティクスへのアクセス、A/B テスト、コードオーバーライドの直接割り当て、ルーティングされたページの削除／名前変更／移動が対象です。厳密な再現やピクセル単位の一致が求められる場合は、まずフォントと添付済み／信頼済みアセットを確認し、正確なリソースが不足していれば作業を一時停止するよう、簡潔な事前確認要件を追加します。忠実度が低い場合は、元の内容／ユーザーの意図で許可されるときに限り、プレースホルダーや代替手段を認め、それらを Framer エージェントに報告させます。
8. 残った要件を、以下の変換ガイドに基づいて Framer 固有の用語で言い換えます。元のプロンプトの見出し、順序、グループ分けが明確な場合は、それらを維持します。
9. 最終プロンプトを書く前に、フレームワーク固有の構文を、変換後の値と Framer 固有の説明に置き換えます。「Tailwind のスタイルを翻訳する」や「React のレイアウトを変換する」のような表現で、変換作業を委ねてはいけません。
10. 具体的な内容を維持します。正確な文言、意図的な改行、色、サイズ、間隔の関係、ブレークポイント、継続時間、遅延、イージング、スタッガー値、アセット、メディアの焦点位置、変形、重なり順、否定的な制約を含みます。
11. 導出されたジオメトリを維持します。元のレイアウト計算から画面上のアンカーが導かれる場合は、「コンテンツの視覚的中心をビューポートの高さの約 35% に配置する」や「フッターを通常フローの最下部に配置する」など、Framer 用語で目標となるアンカーを含めます。
12. CSS のメディアクエリや Tailwind のプレフィックスではなく、Desktop、Tablet、Phone のブレークポイントごとの動作としてレスポンシブ対応を表現します。元のプロンプトでブレークポイントが指定されていない場合は、幅として 1200、810、390 をデフォルトで使用します。
13. コードのみで実現できる動作は、必要な場合に限り明示します。ネイティブでの近似をデフォルトとし、ユーザーが明示的にコードを求めた場合を除き、コードコンポーネントの使用は任意とします。既存のノードにコードオーバーライドを直接割り当てるよう、下流のエージェントに指示してはいけません。プロンプトの内容が分かりにくくなる場合に限り、簡潔な注意事項のセクションを追加し、それ以外は該当要件の近くに注意事項を添えます。
14. 返す前に、下流プロンプトの境界チェックを行います。

• ローカルパス、ローカルのファイル名、リポジトリ名、非公開のリファレンス名を含めないこと。
• このリポジトリやローカルドキュメントを読むよう指示しないこと。
• 実装用コマンド、内部 ID、非公開のツール構文を含めないこと。
• このワークスペースにアクセスできない Framer エージェントにも通じるプロンプトにすること。

レンダリング意図の概要

複雑なビジュアルプロンプトでは、最終プロンプトを書く前にこの概要を作成してください。後続のエージェントに役立つ場合を除き、最終出力に「レンダリング意図の概要」という見出しを含めないでください。

Rendered intent:
- Viewport model: <100vh/full page/auto page/section height, overflow behavior>
- Layer model: <normal-flow, absolute, fixed, z-order, pointer behavior>
- Primary layout formula: <stack/grid/flex relationships, fill/hug/fixed children>
- Visual anchors: <hero center, nav offset, footer position, card grid bounds>
- Media model: <object fit, focal point, transform/crop, overlay order>
- Responsive changes: <Desktop, Tablet, Phone geometry differences>
- Exactness risks: <features that require approximation or optional code>

この概要を Framer プロンプトの信頼できる情報源として使用してください。最終プロンプトで項目を維持できない場合は、該当する要件の横に、最も近い視覚的な代替案を明記してください。

レイアウトの忠実性に関するルール

• レイアウトはクラスの寄せ集めではなく、幾何学的なものとして扱ってください。目に見える結果を生み出す配置の仕組みを維持してください。
• 垂直または水平方向の配置に影響する場合は、通常フローにおける兄弟要素の関係を維持してください。ヘッダー、残りの領域を埋める本文領域、フッターは、間接的にコンテンツの位置を決めることがよくあります。
• 親レイアウトの計算式の一部として、伸縮・内容に合わせたサイズ・固定サイズを維持してください。flex-1、h-screen、min-h-screen、auto、fit-content、固定ピクセル高は、子孫要素の位置に影響します。
• パーセント指定の変形は、基準となるボックスとともに維持してください。CSS の translateY(20%) は、ビューポートやテキストそのものではなく、変形対象の要素自身のボックスを基準とします。
• 変形対象の要素を維持してください。動画・メディアレイヤーの変形はトリミングや焦点のフレーミングを変え、コンテンツラッパーの変形はコンテンツの視覚的な基準位置を変え、塗りつぶされた親要素の変形は広い領域を移動させることがあります。
• justify-*、items-*、content-*、self-*、auto margins、space-between、間隔は、組み合わせによる配置システムとして維持してください。
• 絶対配置・固定配置のオフセットは、包含するフレームに対する制約として維持してください。包含するフレームがビューポートでない場合は、そのフレームも明記してください。
• object-fit と object-position／トリミングの指定を維持してください。メディアを多用するプロンプトでは、塗りつぶし方法と意図した焦点領域の両方を明記してください。
• 元のレイアウトから数値で指定できる場合は、感覚的な表現よりも数値による基準を優先してください。元のレイアウトで精度を判断できる場合は、「中央より少し上」ではなく、「ビューポート上端から約 34～35％」としてください。
• 元のレイアウト自体が曖昧な場合を除き、具体性の高いレイアウトを「中央に」「ゆとりを持たせて」「バランスよく」「高めに」「低めに」「上部近くに」「下部近くに」といった一般的な表現に置き換えないでください。

翻訳ガイド

プロジェクトのセットアップ

• HTML エントリーファイル、フォントリンク、head タグ、インポート、CSS リセット、グローバル CSS、Tailwind の設定、バンドラーに関する注記、TypeScript に関する注記、Vite、Next.js、React のセットアップ → 削除してください。
• ページタイトル、メタデータ、説明、ソーシャル画像の指定 → Framer のページメタデータとして扱ってください。
• サイト／プロジェクトの設定、分析ダッシュボード、A/B テスト、リライト、カスタムヘッダー、静的ファイル、well-known ファイル → 現在のエージェントツールではサポートされていません。制限を明記するか、ユーザーの意図を維持できる場合に限り、サポート対象のページ／コンテンツの代替案に変換してください。
• コードに含まれるグローバルデザイントークン → Framer のカラートークン、テキストスタイルのプリセット、リンクスタイル、および再利用されている場合は再利用可能なコンポーネントスタイルとして扱ってください。

レイアウトとレスポンシブ構造

• Flexbox の行または列 → 方向、配置、分布、間隔、パディング、サイズを設定した Framer のスタックフレーム。
• CSS グリッド → カードやリストの折り返しレイアウト、多段構造には Framer のグリッドレイアウト。
• flex-1、全幅、高さを埋める、または「残りのスペース」 → 該当するスタックまたはグリッドで、塗りつぶし／可変サイズを使用します。
• 中央揃えの最大幅コンテナ → コンテンツフレームを中央揃えにした親セクションと、最大幅を設定します。
• px-6 md:px-12 lg:px-16 のようなレスポンシブなパディング → デスクトップ、タブレット、スマートフォンのブレークポイントごとにパディングを上書きします。
• 絶対配置または固定配置 → 意図的な重なり、画面幅いっぱいに固定するメディア、装飾レイヤー、または実際に固定する UI にのみ使用します。
• object-cover の背景メディア → 適切なトリミングと重なり順を設定し、フレームを覆うサイズにしたネイティブの画像／動画レイヤー。
• モバイルの 1 列グリッド → Framer でより安定して読みやすくなる場合は、縦方向のスタックに変換します。
• min-h-screen または h-screen と flex flex-col → 高さ 100vh の縦方向スタック。子要素にヘッダー／ナビゲーション、flex-1 の本文、フッター／下部コントロールが含まれる場合は、前景コンテンツをすべて 1 つのフレーム内で中央揃えにするのではなく、その 3 つの部分構造を維持します。
• 塗りつぶされた領域内の justify-center → ビューポート内とは限らず、その塗りつぶされた領域内で中央揃えにします。
• justify-between または子要素の分散配置 → 上／中央／下、または左／中央／右の分布を明示的に維持します。
• 負のマージンと変形 → 明示的な視覚上のオフセットに変換し、影響を受けるレイヤーの名前を示します。
• translate-y-[17%] や -translate-y-[20%] のようなパーセント変形 → パーセンテージと基準となる要素を維持します。Framer で直接表現できない場合は、同等の視覚的なアンカーを指定します。
• vh、vw、dvh、svh などのビューポート単位 → ビューポート相対のサイズを維持し、デスクトップ、タブレット、スマートフォンでの意図した動作を明記します。
• アスペクト比、最小／最大幅、固定寸法、空白／折り返し禁止のルール → 折り返し、トリミング、または表示上の配置に影響する場合は維持します。

タイポグラフィ

• Tailwind の文字サイズまたは CSS メディアクエリによる文字サイズ → ブレークポイントごとのサイズを設定した Framer のテキストスタイルプリセット。
• フォントの太さ → 利用可能な場合は、名前付きまたは数値指定の Framer フォントウェイトを使用します。未対応のウェイトを作り出さないでください。
• 外部 Web フォントのインポート → インポートの仕組みを取り除き、必要なフォントを利用可能にするための要件に置き換えます。Framer のエージェントは、プロンプトに記載された任意の外部 Web フォント URL に依存できません。
• テキストのメトリクスを正確に再現するために必要な独自フォントまたはカスタムフォント → そのフォントがプロジェクトですでに利用可能か、カスタムフォントとしてアップロード済みであることを事前に確認するよう求めます。そのフォントがなく、ピクセル単位の厳密な一致が必要な場合は、代替フォントを使わず、作業を中断してフォントファイルを依頼するよう Framer のエージェントに指示します。
• フォールバックフォント → 明示的な近似としてのみ使用します。フォールバックフォントの字形メトリクスによって改行位置が変わる可能性がある場合、正確な折り返しやピクセル単位の一致をうたわないでください。
• 文字間隔と行の高さ → テキストスタイルの値を明示的に指定します。
• リテラルの \n 改行 → 生のエスケープシーケンスではなく、Framer のテキストコンテンツ内で実際の改行にします。
• 単語ごとの色、太さ、強調 → インライン書式を維持したリッチテキストランを使用します。
• テキストのパディング → テキストレイヤーではなく、包含するフレームにパディングを設定します。
• リンク → 適切な場合は、リンクスタイルプリセットを使用したリッチテキストリンクにします。

色、エフェクト、サーフェス

• Tailwind のカラートークンまたは CSS 変数 → 明示的な Framer のカラー値にし、再利用する場合はカラートークンとして登録します。
• 枠線 → ネイティブの枠線を使用します。グラデーション枠線が必要な場合は、グラデーションで塗りつぶした薄い背面フレームで近似するか、正確なグラデーション枠線にはコードによる実装が必要になる可能性があることを明記します。
• グラスモーフィズムまたは背景のぼかし → 半透明の塗りつぶし、背景のぼかし、枠線、控えめな内側／外側のシャドウを使用します。
• ボックスシャドウ → 必要に応じて内側のシャドウも含め、Framer のシャドウエフェクトを使用します。
• グラデーション → Framer のグラデーション塗りつぶしを使用します。
• 装飾用のラッパー → 表面に見た目を付ける必要がない限り、透明のままにします。

モーションとインタラクション

• マウント時またはスクロール時のエントランスアニメーション、IntersectionObserver、AOS、フック駆動の表示状態 → マウント時または画面内に入ったときにトリガーされる Framer の表示エフェクト。
• 文字ごと、単語ごと、または行ごとのテキスト表示 → トークン化とスタガーを使った Framer のテキストエフェクト。
• ホバースタイル → ホバーエフェクト、ジェスチャーバリアント、またはボタン／リンクコンポーネントの状態。
• ループする動き、視差効果、マーキー、ティッカー、またはカーソルエフェクト → 利用可能な場合は Framer のネイティブエフェクト。
• タブ、アコーディオン、トグル、メニュー、ドロワー、開閉 UI、および固定された状態セット → バリアントとイベントハンドラーを備えたネイティブコンポーネント。
• モーダル、ドロップダウン、ポップオーバー、ツールチップ → トリガーと閉じる動作を設定した、固定または相対配置のオーバーレイ。
• カルーセルとスライダー → 要求される動作に応じて、ネイティブの Carousel／Slideshow コンポーネント、またはバリアント駆動のコンポーネント。

コンテンツ、データ、CMS、フォーム

• カード、投稿、製品、人物、イベント、お客様の声、またはレコードにマッピングされるハードコードされた配列 → デフォルトでは、Framer CMS コレクションとコレクションリスト。
• 3つのプロセスステップや独自の統計カードなど、小規模で固定されたビジュアルグループ → 管理対象レコードではなく構造的な要素であれば、ネイティブの繰り返しフレームを使用できます。
• 詳細ページ／テンプレートページ → 可変バインドされたフィールドと安定したスラッグを備えた CMS 詳細ページ。
• フォーム → ネイティブフォームフレーム、適切なタイプを設定したラベル付き入力欄、送信ボタンのコンポーネントインスタンス。元のプロンプトで求められている場合にのみ、インテグレーションについて言及します。
• ローカライズまたは翻訳の更新 → 変更を適用する前に利用可能なロケールとローカライズ済みフィールドを確認し、明示的な置き換え指示がない限り既存のローカライズ済みの値を保持します。一括削除、置き換え、または破壊的なローカライズ移行の前には確認を求めます。
• ネイティブフォームの動作を超える実行時の検証または送信ロジック → コード対応へ移行する旨の注記。

コンポーネント、メディア、アイコン、再利用

• 再利用可能なボタン、カード、バッジ、ナビ項目、FAQ 項目、または繰り返し使われる UI → まず既存の Framer コンポーネントを再利用します。ない場合は、バリアントと編集可能なプロパティを備えたネイティブのキャンバスコンポーネントを作成します。
• 実行時の動作が必要な既存のスタイル付き要素 → まずネイティブのインタラクション、バリアント、イベントハンドラーを使用します。コードが必要な場合は、対応していればコードコンポーネントのワークフローを指定します。既存のノードへのコードオーバーライドの直接割り当てを約束してはいけません。
• アイコン → Framer ネイティブのアイコンセット、または利用可能なプロジェクトのアイコンコンポーネントを使用します。依頼がない限り、Unicode 記号をアイコンの代わりに使用してはいけません。
• 任意のサードパーティ CDN 画像 URL → Framer に適用できると想定してはいけません。厳密な複製やピクセル単位の一致が求められるプロンプトでは、作成前に添付／アップロード済みの画像ファイル、順序が明示された添付アセットパック、または信頼できる組み込み画像検索の結果から取得したアセットを用意する必要があります。
• 大規模な画像マニフェスト → 各アセットの配置に必要な対応関係を含めますが、URL を組み立てるよりも「このファイル名／レイヤー名に一致する添付ファイルを使用する」方法を優先します。URL の一覧表は順序の整理に役立つことがありますが、信頼できない外部オリジンを利用可能にするものではありません。
• YouTube、Vimeo、Spotify、マップ、音声、iframe などの埋め込み → 対応するネイティブコンポーネントまたは埋め込みコンポーネントを使用します。
• 共通のナビゲーション、フッター、サイドバー、またはページ共通の UI → 各ページで同じレイヤーを複製するのではなく、レイアウトテンプレートを使用します。

コードへの切り替え

動作をネイティブのキャンバス構造、CMS データ、ローカライズされたコンテンツ、バリアント、オーバーレイ、エフェクト、コントロール、イベントハンドラーで表現できない場合に限り、コードコンポーネントを使用します。既存のノードにコードオーバーライドを割り当てるよう、後続のエージェントに指示しないでください。外部エージェントによるオーバーライドの割り当てはサポートされていません。

通常、次の場合はコードが必要です。

• ライブタイマー、時計、カウントダウン、ポーリング、または setInterval。
• 実行時の fetch、SDK 呼び出し、ライブの外部 API データ、認証、またはブラウザー API。
• localStorage、再読み込みをまたいで保持される状態、クリップボード、位置情報、ファイル API、またはメディア API。
• ネイティブフォームや連携機能では対応できない、複雑なフォーム検証や送信動作。
• 任意のドラッグ＆ドロップによる並べ替え、自由形式の連続ロジック、または Framer のエフェクトでは表現できないカスタムアニメーションの計算式。

コードが必要な場合は、ネイティブ機能による実装をデフォルトの表示上の実装として維持するよう、Framer のプロンプトを作成します。コードが必要となる具体的な要件に短いインライン注記を付け、必要な動作を明記してください。「カスタムコードが必要な場合は」のような全体に関わる前置きや、ネイティブ機能とコードのどちらを選ぶかという広範な指示は追加しないでください。後続の Framer エージェントに、コードスタックの構造を Framer に変換するよう依頼しないでください。変換後の表示上の構造は自分で提示し、コードを必要とする動作だけを切り分けてください。

最終プロンプトの監査

返答する前に、変換したプロンプトを一度読み直し、以下のチェックリストで見つかった問題を修正してください。

• # Prompt (Framer version) のような汎用的なタイトルを、Framer エージェントが作成または編集する対象を具体的に示すタイトルに置き換えてください。
• パッケージのインストール、React、Tailwind、Next.js、Vite、motion/react、className、src/、index.html、CSS 変数の設定、インポート文などのフレームワーク由来の記述を削除してください。ただし、その説明が役立つ場合は、ソースの実装方法を意図的に省いたことを簡潔に記してください。
• 変換を委ねる表現を削除してください。最終プロンプトでは、「Tailwind 形式のサイズや余白を変換する」「これらのクラスを変換する」「React の構造を適応させる」「CSS を Framer にマッピングする」など、フレームワークの解釈を後続の Framer エージェントに委ねる指示は禁止です。
• タスクから明らかな、行き先を繰り返し示す表現を削除してください。たとえば、「これを Framer で直接構築する」「可能な限りネイティブの Framer を使う」「必要に応じて Framer Code Component を使う」といった独立した前置きが該当します。具体的な構築要件と、特定の動作に関する補足だけを残してください。
• ローカル環境に依存する記述（ローカルパス、リポジトリ名、ファイル名、参照ドキュメント名、AGENTS.md、非公開ツール構文、内部 ID、非公開のコンテキストを読む指示など）を削除してください。
• リポジトリにアクセスできない Framer エージェントだけでプロンプトを完結して実行できることを確認してください。
• 正確に再現する必要のあるソースアセット、コピー文字列、改行、色、フォント、サイズ、余白の関係、ブレークポイント、アニメーションの長さ、遅延、イージング、ホバー状態、明示された制約が、それぞれ保持されているか、該当する要件の近くで近似であることを明記しているか確認してください。
• 厳密な再現、複製、またはピクセル単位の一致を求めるプロンプトでは、正確なフォントやメディアが Framer で信頼できる状態ですでに利用可能とは限らない場合に備え、最終プロンプトに具体的な事前確認手順が含まれていることを確認してください。
• レイアウトに影響するソース内の各指定について、次のいずれかがあることを確認してください。Framer での直接的な対応方法、レンダリング結果を保つ複合的な Framer 構造、または最も近い視覚的な目標を添えた、該当要件の近くでの明示的な補足。
• ファーストビューに含まれるセクションでは、該当する場合、重要なビューポート上の位置関係（ナビゲーション／ヘッダーのオフセット、見出しまたは主要コンテンツの視覚的な中心、フッター／画面下部のコントロール位置、メディアの焦点領域、オーバーレイの重なり順）が保持されていることを確認してください。
• パーセント指定の transform では基準となる要素を明示し、曖昧な配置表現に置き換えないでください。
• コンテンツの配置に影響する場合、通常のフローにおけるヘッダー／本文／フッターの関係を保持してください。
• レスポンシブ対応は CSS メディアクエリや Tailwind のプレフィックスではなく、デスクトップ、タブレット、スマートフォンでの動作として記述してください。
• ネイティブの Framer 実装を既定とし、コードのみで実現できる動作は、ユーザーが正確なコード動作を明示的に求めていない限り、任意の Code Component に関する注記に限定してください。
• ソースに含まれる Tailwind の各ユーティリティ、CSS セレクター／クラス、React の各 prop、フック、インポート、パッケージ、ビルドスタックに関する記述が、具体的な Framer ネイティブの要件に変換されているか、無関係なセットアップ情報として削除されているか確認してください。明示されたコードのみの効果に必要な正確な CSS を除き、Framer エージェントに解釈させるためのソース構文を残さないでください。
• ソースプロンプトの見出しと主要な箇条書きのまとまりを出力と比較してください。追加、削除、改名されたセクションがある場合は、ソースの曖昧さ、ユーザーの指示、または避けられない Framer 固有の補足によるものか確認してください。
• キャリブレーション例のセクション、補足用の見出し、または説明文の文体が最終出力に混入していないことを確認してください。
• 変更内容を逆方向から監査してください。変換後のプロンプトを確認し、ソースにない指示を特定して削除してください。ただし、Framer への機械的な変換、ソース由来の寸法、明示的な近似や補足は除きます。
• よくある不要な追加に特に注意してください。オーバーレイ、スクリーン、グラデーション、シャドウ、ぼかし、テクスチャ、装飾的な図形、セクションや CTA の追加、ブランドの位置付けの書き換え、「プレミアム」なスタイル、読みやすさやアクセシビリティの改善、ホバーやアニメーションの装飾などです。
• ベストプラクティスとして改善すると有用に思えても、変換後のプロンプトには含めないでください。提案を求められた場合に限り、プロンプトの外に任意の注記として記載してください。

出力ガイドライン

変更前と変更後の比較ではなく、書き換えたプロンプトを1つ返してください。フレームワーク固有の仕組みを取り除いたうえで、元のプロンプトの設計意図、優先順位、構成をできる限り維持してください。

Framer エージェントが求められる成果物を理解しやすい、具体的なタイトルを付けてください。たとえば、# Build the Product Launch Landing Page や # Create the Pricing Page With Interactive FAQ のようなタイトルです。# Prompt (Framer version) のような汎用的なタイトルは使わないでください。

暗黙のセットアップ手順は省いてください。まず作成または編集する具体的な内容を示し、そのあとに変換した要件を列挙してください。プロンプトがFramer向けであること、Framerを使うこと、元のスタックの構文をFramer向けに変換することを、Framer エージェントに伝えないでください。

固定のセクションテンプレートを強制しないでください。元のプロンプトに明確なセクションがある場合は、そのセクションを維持し、内容を翻訳してください。元のプロンプトの構成が煩雑、またはコードのような形式の場合は、Framerでの実装が明確になる範囲でのみ再構成してください。

標準化された注記や注意事項のセクションを、デフォルトで追加しないでください。要件を本文中に維持できず、その注意事項が実装に大きく影響する場合に限り追加してください。

元のプロンプトに長いQAスクリプトや冗長な検証手順が含まれている場合は、ユーザーがテストスクリプト全体を残すよう明示的に求めていない限り、Framerで確認できる具体的な結果に基づく、短い合否チェックリストに変換してください。各項目は、Framer エージェントが確認、スクリーンショットの撮影、または報告を行える内容を1つずつ対象としてください。