LucasH1225/restaurant-website-skills

レストランデモビルダー

証拠に基づいたセールスデモを構築し、オーナーが自分のレストランを認識し、失われたオンラインの機会が明白になるようにします。デモは、単にレストラン名を貼り付けた汎用テーマではなく、そのレストランのウェブサイトの有用な最初のバージョンとして扱います。

本格的な調査、デザイン、画像制作、実装の前に、references/demo-playbook.mdを読んでください。リクエストに関連するセクションのみを使用してください。

タスクモードの選択

行動を起こす前に、要求されたモードを判断します：

• 分析： 出典付きのコンセプト、根拠、ページ構成、画像の方向性、メニュープラン、検証ギャップを返します。特に指示がない限り、プロジェクトファイルを編集しないでください。
• 構築： レストランを調査し、適切なアセットを作成または準備し、動作するデモを実装し、実行し、デスクトップとモバイルビューを視覚的に検証します。
• リフレッシュ： 既存のデモと現在の公開情報を検査し、古くなった部分や弱い部分のみを更新し、視覚検証を再実行します。

複数の事業者が同じ名前を共有し、正しい場所を推測できない場合にのみ、明確化を求めてください。それ以外の場合は、まずローカルのリードデータと公開ソースを調査します。

証拠から作業する

1. ブラウジングする前に、現在のワークスペースを検査します。リードのエクスポート、ブリーフ、既存のデモ、デザインアセットからレストラン名、場所、プレースID、URLを検索します。
2. レストラン情報は頻繁に変更されるため、現在の公開情報を検証します。レストランが所有するサイトとソーシャルページ、GoogleリスティングまたはMapsデータ、現在のメニューまたは注文ページ、最近のレビュー、関連する公式観光または商工会議所のページを確認します。
3. 名前、住所、電話番号、営業時間、評価、レビュー数、カテゴリ、サービス、メニュー項目、価格、イベント、オンライン注文、ソーシャルリンク、およびデモに提案された会場や外観の画像について、ソースと信頼度を記録します。
4. 作業中にコンテンツを3つのラベルに分類します：
   • 検証済みの事実： 現在のソースによって直接サポートされている。
   • 合理的な推論： レビューや場所のコンテキストの繰り返しパターンによってサポートされている。
   • クリエイティブな提案： デモ用に作成されたタグライン、アートディレクション、レイアウト、キャンペーンアイデア。
5. 矛盾する事実は、可能な限り最新のオーナー管理ソースで解決します。未解決の矛盾はオーナー検証リストに載せます。
6. レストランのアイデンティティ、ウェブサイトの問題、メニューの可用性、主要な連絡先詳細、主要なオーディエンスの証拠、繰り返されるレビューテーマが十分に確立されたら、調査を停止します。分析モードでは、網羅的なディレクトリスイープよりも、少数の強力なソースを優先します。ブリーフを遅らせる代わりに、未解決の詳細をリストアップします。

メニュー項目、価格、営業時間、賞、割引、配達、予約、注文、イベントスケジュール、アクセシビリティの主張を決して invent しないでください。宛先とサービスが本物でない限り、動作しているように見えるコマンドボタンを追加しないでください。

1つの商業的ポジションを定義する

証拠から、1つの主要オーディエンスと1つの主要コンバージョン目標を選択します。典型的なオーディエンスには、通りすがりの旅行者、地元の家族、朝食の常連、スポーツバーの客、夜のグループが含まれます。典型的な目標には、メニューの閲覧、道順の取得、電話、または確認されたオンライン注文が含まれます。

最初のビューポートは、5秒以内に以下に答えなければなりません：

1. これはどのレストランか？
2. なぜこの訪問者はこのレストランを選ぶべきか？
3. 営業中か、またはいつ営業しているか？
4. 訪問者はどのようにメニューを見たり、そこに行ったりできるか？

レストラン名をH1として使用します。ポジショニングはサポートコピーに配置します。「素晴らしい料理」や「新鮮な食材」などの一般的なフレーズではなく、営業時間帯、看板料理、場所、営業時間、ポーション、レビューテーマなどの具体的な証拠を優先します。

デザインをルーティングする

レストランの証拠、オーディエンス、機会、主要なアクションが確立されたら、references/design-routing.mdを読んでください。レストランプロファイルを作成し、scripts/select_recipe.pyを実行し、生成された recipe-lock.json をデモ調査記録とともに保存します。

選択されたレシピリファレンスのみを読み、その後、assets/layouts/<layout-id>/ から独立して選択されたレイアウトスターターをコピーします：

• morning-regular: references/recipe-morning-regular.md
• hometown-table: references/recipe-hometown-table.md
• local-tavern: references/recipe-local-tavern.md
• occasion-dining: references/recipe-occasion-dining.md

references/layout-research-2026-07-v2.md は、V2ライブラリの背後にある構造的証拠をレビューする場合、レイアウト文法を拡張する場合、またはデザインミスマッチを診断する場合にのみ使用してください。以前の design-research-2026-07.md と assets/starters/ はV1の履歴であり、新しいデモルーティングには参加しません。リファレンスレストランのコード、写真、文章、ロゴ、イラスト、または特徴的な完全な構成をコピーしないでください。

レシピとレイアウトの選択は別々の制約として扱います。レシピはオーディエンス、トーン、機能、視覚的な態度を制御します。レイアウト文法は、Hero、メディア構成、証明フォーム、メニュージオメトリ、セクションジオメトリ、モバイル変換を制御します。検証済みのレストラン証拠は、引き続き注文、予約、イベント、営業時間、サービス、メニューコンテンツ、レビュー、画像を制御します。V2ロックを手動でバイパスしないでください。結果が間違っている場合は、プロファイル、互換性定義、または履歴フィンガープリントを修正してください。

レストランのブランドパレットをロックする

$restaurant-brand-palette を、レシピとレイアウトのロック後、最終的なビジュアルスタイリングの前に使用します。ただし、店頭、看板、ロゴ、メニュー、パッケージ、または店内の画像が使用可能なアイデンティティカラーの証拠を提供する場合に限ります。検証済みの brand-palette.json を保存し、recipe-lock.json の横にプレビューします。

パレット、レシピ、レイアウトは別々のロックとして扱います。パレットはCSSカラーの役割と比率を制御します。オーディエンス、機能、Hero文法、またはセクションジオメトリは変更しません。トークンをインポートする前に、パレットスキルの handoff ステージが必要です。検証済みのトークンをCSS変数にマッピングし、実装中にアドホックな代替16進値を導入しないでください。

証拠レビューで信頼できるブランドカラーが残らない場合、パレットスキルに明確にラベル付けされたレシピフォールバックを作成させます。フォールバックがレストランからのものであると主張しないでください。トークン変更後は再検証し、写真上のテキストを個別に検査します。

意思決定を中心にページを構築する

選択されたレシピが証拠に基づいたより良い順序を指定していない場合は、以下のデフォルトシーケンスを使用します。証拠がないセクションは削除します：

1. 「メニュー」、「お気に入り」、「訪問」と価値の高いコマンドを備えたコンパクトなナビゲーション。
2. レストラン名、具体的な価値提案、「メニューを見る」、「道順を取得」または「電話」を備えたフルブリードのヒーロー。
3. 検証済みの評価/レビュー数、営業時間、価格シグナル、またはダウンタウン/ロケーションコンテキストを備えた証明ストリップ。
4. 確認された名前が利用可能な場合はそれを使用した、3〜6の特徴的な料理。料理に検証済みの実際の写真がない場合、リアルな食品画像を invent するのではなく、テキスト主体のカテゴリまたは代表的なラベルを使用します。
5. カテゴリナビゲーションを備えた読みやすいHTMLメニュー。
6. 体験または時間帯セクションは、ビジネスを明確にする場合のみ。例：朝食から深夜まで、家族向けダイニング、スポーツ、ライブイベントなど。
7. 選択したポジショニングをサポートする、短く出典のあるレビュー証明。
8. 検証済みの店頭写真が認識や道案内を著しく向上させる場合の、到着または外観バンド。
9. 住所、現在の営業時間、電話、地図/道順、所有ソーシャルリンクを備えた訪問セクション。
10. 最も重要なコマンドのためのモバイルスティッキーアクション。

エクスペリエンスを直接的で有用に保ちます。すべてのセクションに装飾的なカード、偽の予約フォーム、一般的なシェフのストーリー、根拠のない「街で一番」の主張、長いマーケティングコピーを避けます。

一貫した画像システムを作成する

$restaurant-food-image-studio を、実際のフードリファレンス監査、画像生成、修復、マニフェスト追跡、およびソースと提案のコンタクトシートに使用します。完全なデモ構築では、ここで最初にレストランの証拠と商業的な方向性を確立し、次に検証済みの料理ショートリストと画像要件をそのスキルに渡します。以下の原則を最終サイトの受け入れ契約として維持します。

フードイメージスタジオのマニフェストV3 demo 検証を統合境界として扱います。同じレストランの一意で記録された実際の served-dish-photo が存在し、実際の写真が画像入力として提供され、ソースが1つのロックされた顧客向け写真システムにルーティングされ、両方の標準証拠シートがハッシュロックされ、5つのQAゲートすべてを通過し、現在のマニフェストが <food-image-skill>/scripts/validate_manifest.py --stage demo を通過しない限り、AIでリステージされたフードアセットをウェブサイトにコピーしないでください。各出力をコピーする直前と、最終デモQA中に再度、そのバリデータを実行します。ソース、写真システム、証拠記録、またはQAゲートのいずれかが欠けている場合、スロットをテキスト主体のままにするか、個別に検証された非食品アセットを使用します。メニューの説明、ストックフォト、合成スタイル画像、または representative-concept レンダリングでこのゲートをバイパスしないでください。

料理のアイデンティティと雰囲気は証拠であるため、実際のレストラン所有の画像を優先します。プライベートセールスデモの場合、Maps、ソーシャルページ、レビュープラットフォーム、ディレクトリ、メニューページからの公開実際の写真は、アップロード者が不明であっても、一時的な事実または構成の参照として機能することがあります。ソースと不確実性を記録し、参照権限がクリアされていることを暗示せず、公開前に承認または代替アセットを取得します。

別々のゲートを使用します。ソースゲートでは、一意の実際の料理ソース、ソースカメラ評価、ルート、来歴、ハッシュを自動的に保持します。プライベートデモゲートでは、ソースとデザインされた写真の比較、生成タイミング、登録された出力角度、および5つのゲート（忠実度、スタイル一貫性、食欲最適化、AIの痕跡、ウェブ対応）を保持します。ユーザーは後でいずれかのアーティファクトを検査し、変更を要求できます。実際の公開写真が正しいレストランに信用できる形で結びついている場合、アップロード者の身元は必要ありません。パブリックローンチゲートでは、クリアされた代替品または関連する権利保持者の許可と、事実の正確性に関するオーナーの確認が必要です。記録されたプライベートまたは1対1の使用が公開権を付与することを暗示しないでください。

現在のデジタルメニューが存在しない場合、$restaurant-food-image-studio にGoogle Mapsファーストのフォールバックを実行させます。繰り返される実際の料理写真をグループ化し、メニュー写真、ソーシャル投稿、キャプション、レビューの言及でそれらを裏付け、3〜6の特徴的な候補をショートリストします。繰り返しは選択のシグナルであり、販売量の証明ではありません。デフォルトで「おすすめ」を使用し、「人気」、「一番人気」、「ベストセラー」、または正確な料理名は、裏付けのある主張のために予約します。

AIをアートディレクションと修復のレイヤーとして使用します：

• 生成する前に、すべての実際のソースを検査し、そのカメラビューを分類します。
• 料理の種類、食材、ポーション、調理法、サイド、盛り付け容器を保持します。ソースを必須の最終構成ではなく、食品の真実として扱います。
• レストランセットに対して、1つの主要な顧客向けカメラファミリー、アングル許容範囲、被写体スケール、クロップ、背景、照明方向、グレード、レンズ感、小道具ポリシーをロックします。
• そのシステムに適合しないソースは reference-restage にルーティングします。実際のものであるという理由だけで、不適切なオーバーヘッドやカジュアルなスナップショットアングルを保持しないでください。
• 露光、ホワイトバランス、およびソースで裏付けられた食欲の手がかり（自然な金色のパンや目に見える焼き目など）を改善しますが、火の通り方、焼き目、ポーション、食材は変更しません。
• プラスチックのような光沢、ワックス状の質感、繰り返し、完璧な幾何学形状、不可能な効果、その他の目に見えるAIの痕跡を拒否します。
• ヒーローにはワイド画像を、特集料理には一貫した 4:3 ファミリーを使用します。
• 特集料理の画像は3〜6枚のみ生成します。完全なメニューはテキスト主体のままにします。
• 不確実な出力はコンセプトイメージとしてマークし、オーナー検証セットに含めます。
• Google Mapsのスクリーンショットやその他のサードパーティのオリジナルはデモページに保存せず、内部マニフェストとコンタクトシートにのみ記録します。

リファレンスが食材を証明していない場合、生成された画像を正確なメニュー項目としてラベル付けしないでください。不可能なガーニッシュ、誇張されたスチームやチーズの引き、偽のロゴ、生成されたメニューテキスト、過度の完璧さ、レストランと矛盾するストックフォトの輝きを避けます。

$restaurant-exterior-image-studio を、実際の店頭ソース監査、保存計画、AI支援による修復またはリファレンスベースの再作成、マニフェスト追跡、登録、比較、6パートQAに使用します。完全なデモ構築では、ここで最初に到着画像の目的とスロットを決定し、次にアスペクト比、焦点、意図された配置、および道案内の要件をそのスキルに渡します。

外観イメージスタジオの demo 検証を統合境界として扱います。現在の実際のソースが看板、入口、ファサード形状、ファサードカラー、固定機能を証明し、すべての出力向け領域がサポートされているかクロップアウトされ、保存契約が完了し、6つのQAゲートすべてを通過し、<exterior-skill>/scripts/validate_manifest.py --stage demo が統合直前に成功しない限り、AI支援による店頭をウェブサイトにコピーしないでください。

食欲が主要なコンバージョンである場合、フード主体のヒーローを維持します。建物自体が検証済みのアトラクションでない限り、外観は訪問セクションの近くに配置します。公開プラットフォームのオリジナルは内部に保持し、プライベートデモ出力は写真提案としてラベル付けし、別々のオーナー精度と公開権ゲートを維持します。ストリートビューは、公式の埋め込みまたはリンクを除き、調査のみに留めます。

アセットを計画または配置する前に、references/demo-playbook.md の「外観と到着画像」セクションを読み、専門スキルに制作詳細を制御させます。

メニューを中核ユーティリティにする

メニューは構造化されたページコンテンツとして構築し、画像やPDFの埋め込みとしては構築しません。