レストラン食品画像スタジオ

実際のレストランスナップ写真を、一貫性のある小規模ウェブサイト写真セットに変換します。実写を料理の事実上の権威として使用します。レストラン撮影システムを、カメラアングル、構図、照明、背景、色、トリミング、顧客向けプレゼンテーションの権威として使用します。

弱いソースアングルを、それが実写であるという理由だけで保持しないでください。頭上からの撮影、散らかった、または一貫性のないスナップ写真がウェブサイトシステムに適合しない場合は、reference-restageを使用して、固定された顧客向けカメラから同じ料理を提示します。再構成によって料理の事実が変更されることは決して許されません。

収集、計画、プロンプト作成、生成、またはレビューの前に、references/food-image-playbook.mdを読んでください。ワークオーダーを独自に作成する代わりに、バンドルされたManifest V3とStyle Lockの構造をコピーしてください。

モードの選択

収集: 実際の単一レストランの候補画像を取得し、出典を保存します。
監査: レストランの同一性、料理の視認性、ソースアングル、再構成リスクを検証します。生成は行いません。
作成: 1つの撮影システムをロックし、各ソースをルーティングし、実際のソースごとに1つのデザインされた写真を生成し、タイミングを保持します。
修復: 失敗したゲートを診断した後、実際のソースとロックされた撮影システムから再生成します。
レビュー: 正式なソース/出力アーティファクトと、5つのQA判断すべてを自動的に保持します。

完全なデモのためのビジネス証拠、オーディエンス、ウェブサイトレイアウト、画像スロットを確立するには、$restaurant-demo-builderを使用してください。このスキルは食品写真システムとアセットに使用します。

証拠レビューを非ブロッキングに保つ

正式な候補、ソース、ソース対出力シートを、承認リクエストではなく、自動的な証拠記録として扱います。正式なソースシートが存在する場合、各適格ソースを status: recorded、reviewer: workflow で記録し、generate ステージを検証し、ユーザーを待たずに画像生成に進みます。出力QA後、同じ方法で正式な比較を記録し、プライベートデモゲートに進みます。

証拠または検証が失敗した場合、現在の changes-requested レコードが存在する場合、ソースが提案された画像を真実味をもってサポートできない場合、またはユーザーが現在の実行を一時停止するよう明示的に要求した場合にのみ停止します。人間による検査は後でも利用可能であり、changes-requested を作成する可能性がありますが、生成の前提条件になることは決してありません。所有者の事実確認と公開権は、別個の起動ゲートとして保持します。

Manifest V3契約の強制

すべてのデモ食品画像が以下のすべてのルールを満たすことを要求します：

同じレストランからの一意の served-dish-photo 視覚プライマリに厳密にバインドします。
未加工のソースを、プラットフォームID、元のURL、SHA-256とともにローカルに保存します。
その実際のソースをimagegenに供給します。プロンプトのみの食品生成は決して使用しません。
source_assessment.camera_view、顧客向け適合性、隠れた詳細リスクを記録します。
生成前に、1つのレストランレベルの photography_system を完了します。
ソースがすでにそのシステムに適合している場合にのみ、constrained-edit を使用します。
カメラ、構図、または顧客向けプレゼンテーションを変更する必要がある場合に、reference-restage を使用します。
隠れた詳細リスクが高いアングル変更の再構成は、別の実際のビューが利用可能になるまでブロックします。
同じレストランからの別のライブ監査済み served-dish-photo で、正確な同一料理一致記録がある場合にのみ、裏付けとなるビューを受け入れます。
料理ごとの変換計画と許可された食欲調整を記録します。
imagegenの開始、完了、および所要時間を記録します。
出力を完全にデコードし、実際の幅と高さを記録し、ピクセル比を撮影システムに対して検証します。
5つの個別のゲート（忠実度、スタイルの一貫性、食欲の最適化、AIの兆候、ウェブサイトの準備完了）を通過します。
正式な実際のソースとソース対デザイン写真のアーティファクトを保存します。
出力をウェブサイトにコピーする前に、Manifest demo ステージを通過します。

信頼できる実際の料理写真が存在しない場合は、スロットをテキスト主体に保ち、別途クリアされた非食品画像を使用し、別の撮影済み料理を選択するか、所有者の写真をリクエストします。

所有者の写真は、実装された収集記録、完全なピクセルデコード、正式な候補シート、Apify/Masaと同等の候補監査が完了するまで、視覚プライマリではなく、将来の取得候補として扱います。Manifest V3は現在、監査済みのApify Google MapsとMasaの写真のみを視覚プライマリとして認めています。

ワークオーダーの準備

output/food-image-studio/<restaurant-slug>/ を作成し、sources/、prompts/、drafts/、selected/、review/ を含めます。以下を使用します：

image-manifest.json 用の assets/image-manifest-template.json。
style-lock.md 用の assets/style-lock-template.md。

小文字のASCIIファイル名を使用します。APIトークン、秘密鍵、アカウントシークレットをこれらのファイルに決して配置しないでください。

コマンドでは、<food-image-skill> をこのスキルの利用可能なスキルロケーターから解決します。

実際の料理リファレンスの収集

選択したレストランのみに対してコレクターを実行します：

APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
  --place-id <google-place-id> \
  --max-images 20 \
  --output-dir <work-order>

python3 <food-image-skill>/scripts/collect_real_references.py masa \
  --store-id <masa-store-id> \
  --item-name <exact-menu-item-name> \
  --output-dir <work-order>

Maps URLの場合は、独立して既知のプレースIDも提供します。返されるレコードはそれと一致する必要があります：

APIFY_TOKEN=... python3 <food-image-skill>/scripts/collect_real_references.py apify \
  --maps-url <exact-google-maps-place-url> \
  --expected-place-id <google-place-id> \
  --output-dir <work-order>

コレクターはJPEG、PNG、WebPピクセルを完全にデコードし、300ピクセルの短辺または150,000総ピクセル未満のソースを拒否します。ApifyがロックされたプレースIDを返し、Masaがレスポンスまたはメニュー項目コンテキストで要求されたストアIDを返すことを要求します。要求された識別子だけを証拠として扱うことは決してありません。

オフラインJSONインポートは、再現可能な監査資料としてのみ使用します。入力ハッシュと offline-audit-only 層を保持しますが、プロモートしたりデモに入力したりすることはできません。

独立した候補監査の記録

正式な未分類候補シートをレンダリングします：

python3 <food-image-skill>/scripts/make_candidate_sheet.py \
  --source-index <work-order>/source-index.json \
  --out <work-order>/review/candidate-sources.svg

view_image と保持されたシートを使用して、すべてのローカル候補を検査します。スクリーンショット、メニュー、プレースホルダー、ストック画像、合成画像、ぼやけた食品、間違ったリストを拒否します。分類を自動監査ステップとして記録します。ユーザーの承認のために一時停止しないでください：

python3 <food-image-skill>/scripts/record_candidate_review.py \
  --source-index <work-order>/source-index.json \
  --candidate-sheet <work-order>/review/candidate-sources.svg \
  --candidate-id <candidate-id> \
  --out <work-order>/review/<candidate-id>.json \
  --status recorded \
  --reviewer workflow \
  --classification served-dish-photo \
  --restaurant-match verified \
  --restaurant-match-notes <identity-evidence> \
  --dish-visibility served-dish-visible \
  --visual-notes <visible-served-dish-evidence> \
  --notes <audit-summary>

監査記録は、候補ID、未加工ソースハッシュ、ソースインデックスハッシュ、正式な候補シートハッシュ、レビュアー、タイムスタンプ、分類、視覚的所見をロックします。非食品候補は実際の分類で記録し、プロモートしないでください。後で changes-requested レコードが作成されると、プロモーションとデモ検証が即座にブロックされます。

モードを選択する前のスナップショット評価

ソースのカメラビューを overhead、near-overhead、three-quarter、low-angle、straight-on、または unknown として記録します。次に記録します：

fit: ソースがすでに撮影システムに一致する場合。constrained-edit を許可します。
restage-required: 料理は事実であるが、アングルまたは構図が顧客向けでない場合。reference-restage が必要です。
unusable: 食品が不明瞭または不確かすぎる場合。生成をブロックします。

ロックされた顧客向けシステムが three-quarter テーブルトップである場合、頭上からのスナップ写真を fit と呼んではいけません。Sake Sushiの失敗は正式なアンチパターンです。実際の頭上からのソースは、編集が同じ頭上からの構図を維持するという理由だけで通過できません。

バリデーターはカメラファミリーの互換性を強制します。overhead および near-overhead ソースは、three-quarter-tabletop、low-tabletop、または straight-on に対して fit とマークできません。互換性のないビューは restage-required とし、angle_change_required: true を設定し、reference-restage を使用する必要があります。

提案された出力ごとに1つの候補をプロモートします：

python3 <food-image-skill>/scripts/promote_candidate.py \
  --source-index <work-order>/source-index.json \
  --candidate-review <work-order>/review/<candidate-id>.json \
  --manifest <work-order>/image-manifest.json \
  --candidate-id <candidate-id> \
  --dish-id <dish-id> \
  --dish-name <dish-name> \
  --restaurant-name <restaurant-name> \
  --restaurant-slug <restaurant-slug> \
  --location <location> \
  --google-place-id <place-id> \
  --dish-match-status <exact-or-category-only> \
  --dish-match-notes <name-or-category-evidence> \
  --source-camera-view overhead \
  --customer-facing-fit restage-required \
  --hidden-detail-risk medium \
  --composition-notes <why-the-snapshot-needs-restaging> \
  --angle-change-required yes \
  --generation-mode reference-restage

Masaの場合は、--google-place-id の代わりに --masa-store-id を使用します。

プロモーションは、live-verified コレクションからの served-dish-photo として分類された現在の recorded / audit-record のみを受け入れます。完全な元の出典とソースメタデータをマニフェストにコピーします。ソースインデックスと候補レビューファイルはハッシュにバインドされたままで、後のすべてのステージで再検証されます。

live-verified をワークフローで証明された証拠として扱います。ApifyまたはMasaからの暗号署名ではありません。ワークオーダーへの書き込みアクセス権を持つ人は、ローカルJSONを編集し、ローカルハッシュを再計算できます。出典が争われる場合、またはパブリックローンチがそのアセットに依存する前に、ライブプロバイダーコレクションを再実行し、返されたレストランIDと画像ハッシュを比較するか、将来のオーナー取り込み監査を通過したクリアされたオーナーアセットに置き換えてください。ローカルチェーンを改ざん防止として決して説明しないでください。

1つのデザイン撮影システムをロックする

生成前に、構造化された photography_system と style-lock.md の両方を完了します。レストランセット用に1つのプライマリカメラファミリーをロックします。通常は、顧客向けのカジュアルな食品写真撮影のために、35〜45度の再現可能な three-quarter-tabletop システムです。15度を超えないアングル許容差を記録します。

以下のすべての変数をロックします：

ターゲットアングル、カメラ高さ、レンズの印象、被写体のスケール。
アスペクト比、トリミング、ウェブサイトのネガティブスペース。
表面、背景ファミリー、プロップの抑制。
照明の方向、照明の品質、影の特性。
露出、ホワイトバランス、彩度、コントラスト。
食欲の処理と許容される実際の不完全さ。
AIレンダリングされた外観を避けるために必要な自然な手がかり。

セット全体で1つのプライマリカメラファミリーを使用します。頭上、真正面、スリークォーター画像を気軽に切り替えないでください。

真実の食欲最適化を計画する

プロンプト作成前に、料理固有の調整を記録します。ソースによってサポートされる改善のみを許可します：

露出を適度に上げ、ホワイトバランスを補正します。
既存のパンやクラストを自然により温かく、よりゴールデンにします。
既存の焼き目、クリスプな端、野菜の色、またはソースのつやを明確にします。
気を散らす背景の詳細をクリーンアップし、プレートの配置を改善します。
通常のサービスのばらつき、不均一なカット、ソースの非対称性を保持します。

焦げ目、グリルマーク、ガーニッシュ、材料、ソース、蒸気、分量、器、または豪華な盛り付けを発明しないでください。「より食欲をそそる」ことはプレゼンテーションの目標であり、料理を再設計する許可ではありません。

ソースアーティファクトを自動的に記録する

ソースシートを作成する前に、構造化された撮影システム、スタイルロック、およびすべての変換計画が完了していることを要求します：

python3 <food-image-skill>/scripts/validate_manifest.py \
  --manifest <image-manifest.json> \
  --stage plan

次に、正式なソースシートを作成し、一時停止せずに記録します：

python3 <food-image-skill>/scripts/make_contact_sheet.py \
  --manifest <image-manifest.json> \
  --stage source \
  --out <work-order>/review/source-review.svg

python3 <food-image-skill>/scripts/record_review.py \
  --manifest <image-manifest.json> \
  --dish-id <dish-id> \
  --gate source \
  --status recorded \
  --reviewer workflow \
  --notes <source-angle-route-and-evidence-notes>

シートのレンダリング後に一時停止しないでください。適格なすべてのソースを自動的に記録し、すべてのプロンプト TODO マーカーを置き換え、validate_manifest.py --stage generate を要求し、検証が合格したら直接imagegenに進みます。

デザインされた写真を生成する

$imagegen を使用します。すべての呼び出しで視覚プライマリを提供し、隠れた詳細リスクが必要とする場合には実際の裏付けビューを追加します。すべてのプロンプトで：

裏付けIDごとに、source_assessment.supporting_source_matches.<source-id> を status: exact と特定の同一料理メモで記録します。 output.input_source_ids の視覚プライマリの後に、監査済みの実際のビューのみを含めます。メニュードキュメント、会場写真、ストック画像、合成画像は隠れた詳細リスクを満たすことができません。

ソースIDと constrained-edit または reference-restage を指定します。
ターゲットカメラファミリーとターゲットアングルを明示的に指定します。
実際のソースを料理の事実として、撮影システムをプレゼンテーションの事実として扱います。
検証済みの食品の事実、数、分量、サイド、ソース、火の通り具合、器を繰り返します。
計画された構図と食欲の改善のみを説明します。
実際の不規則性と通常の独立系レストランのプレゼンテーションを保持します。
プラスチックのような光沢、ワックス状のテクスチャ、繰り返される幾何学模様、完全な対称性、変形したエッジ、偽のエフェクト、テキスト、ロゴを禁止します。
1つ作成します。

…

[truncated for translation]

LucasH1225/restaurant-website-skills

restaurant-website-skills とは？

お気に入りのAIに質問する

ドキュメント