guizang-social-card-skill

Guizang Social Card Skill

小紅書／Rednote、WeChat 公式アカウント、記事カバー、プラットフォームのサムネイル用に、洗練されたソーシャルカード一式を作成します。

このスキルは単独で使用できます。Guizang PPT スタイルシステムの視覚的な原則を取り入れていますが、元の PPT スキル、そのテンプレート、参照資料を編集してはいけません。元の PPT スキルが利用できる場合は、参照目的に限り閲覧できます。

生成した成果物は、スキルのルートではなくタスクフォルダーに保存してください。デフォルトでは、このリポジトリ内の local-tests/<slug>/ を使用するか、ユーザーが明示した出力フォルダーを使用します。social-card-*、livephoto-*、wechat-*、output/ などのルート直下のタスクフォルダーや、SKILL.md の隣にレンダリング済みアセットを作成しないでください。

作成するもの

以下にはこのスキルを使用してください。

• ソーシャルカード／カルーセル画像一式：表紙と本文ページ。特に小紅書／Rednote の 3:4。
• ユーザーが Live Photo／实况照片 を求め、動画の証拠または画面録画を提供した場合の、短い Live Photo モーションカード。
• 高品質の動画素材があり、テキストをほとんど、またはまったく追加せず、1画面・2分割・3分割・4分割のモーションカードを希望する場合の、素材主体の Live Photo パズルレイアウト。
• 3本の短い動画、3つの結果、3つの視点、または1つのイメージカード単位にまとめるべき情報量の多い比較がある場合の、3枚組 Live Photo コラージュ。
• Live Photo 用の長尺動画の受付対応：レンダリング前に、トリミング、高速化、3枚組コラージュへの分割、またはユーザーへの具体的な時間範囲の確認が必要かを判断します。
• WeChat 公式アカウントのカバーペア：21:9 のメインカバーと 1:1 の正方形カバーを、視覚確認のため同じ HTML 内で一緒に構成します。
• スクリーンショットを多用した製品紹介記事、記事カバー、チュートリアルのカルーセル、アウトドア／ライフスタイルの投稿、AI／製品アップデートの解説。
• Guizang スタイルのスイス風またはエディトリアルマガジン風レイアウトが必要なソーシャル画像。

以下にはこのスキルを使用しないでください。

• スライド一式や横長の PPT ウェブサイト。該当する場合は PPT スキルを使用してください。
• 長尺動画の生成。該当する場合は動画スキルを使用してください。このスキルが対応するのは、静止画の枠を動画に置き換える、短くレイアウトに沿った Live Photo カードのみです。
• レイアウトや記事内容の抽出を必要としない、純粋な画像編集。

Rednote カテゴリーの対応範囲（対応可能カテゴリー）

Rednote（小紅書）で特によく見られる11のカテゴリーは、3つのグループに分かれます。レシピ別の振り分けについては references/category-cookbook.md を参照してください。

最初から最後まで強く対応（テキスト、構成、画像のストーリーをすべて扱います）：

• 旅行（Travel）、職場（Workplace）、おすすめ（Recommended。サブタイプを指定した場合）。

テキストと構成には強く対応。画像はユーザー提供のもの、または調達したライブラリから用意する必要があります：

• ゲーム（Game）、映画／テレビ（Film/TV）、美食・レシピ系（Food — recipes only）、メイク・チュートリアル系（Makeup — tutorials only）、フィットネス（Fitness）、インテリア（Home）、ファッション・厳選系（Outfit — capsule/essay only）。

対応範囲外 — 成果を約束せず、率直にお伝えしてください：

• 美食の料理写真を主役にした盛り付け。
• ファッションの日常 OOTD 全身写真（生成やシミュレーションには対応できません）。
• 感情系の夢核／雰囲気重視の装飾スタイル（エディトリアルとスイス風の両方に合いません）。
• Y2K／千禧系ギャル／ゴスロリ／kawaii 装飾スタイル。
• 画像そのものが成果物のすべてとなる、純粋な写真紹介の投稿。

3つ目のグループに該当する依頼では、受付時に対応できない内容を伝えてください。ユーザーの意図に合わないレイアウトを、黙って後から当てはめないでください。

基本原則

表現を最優先します。テキストをポスターに詰め込むことではなく、元の内容を明確な視覚的主張に変えることが目的です。

各ページについて、以下を判断してください。

• 見た人に一目で理解してほしいことは何ですか？
• それを裏付ける証拠、スクリーンショット、画像は何ですか？
• 大きく表示すべき言葉と、キャプションやメタデータにできる言葉はどれですか？
• 投稿本文に含めるべきで、画像から削除できるものは何ですか？

必要な参照資料

必要に応じて、以下のファイルを参照してください。

• 正確な比率、出力サイズ、命名規則については、references/platform-specs.md を参照してください。
• Guizang の編集方針とスイス風ビジュアルのルールについては、references/style-system.md を参照してください。
• 電子雑誌の配色やスイス風アクセントカラーを選ぶ際は、references/theme-presets.md を参照してください。
• カルーセル／ソーシャルカード／WeChat ページの構成を選ぶ際は、references/layout-recipes.md を参照してください。
• 共通コンポーネントの仕様（フォントスタック、文字サイズのスケール、読みやすさを保つ最小サイズ、中国語タイトルの長さの目安、スイス風カードの塗りつぶしの相互排他ルール、画像コンテナの比率クラス、スペーシングトークン、Lucide アイコンのルール）については、references/components.md を参照してください。
• 電子雑誌の WebGL／インク／紙の背景を作成する際は、references/background-systems.md を参照してください。
• レイアウトを 3:4 に合わせ、縦方向の余白が大きくなりすぎないようにする際は、references/portrait-fill.md を参照してください。
• 表紙のフック、ページ構成、コピーの圧縮については、references/content-planning.md を参照してください。
• HTML／CSS のレンダリングと画像の処理については、references/production-workflow.md を参照してください。
• ユーザーが Live Photo／实况照片／三连实况拼图を求める場合、ソーシャルカード用の動画素材を提供する場合、または Xiaohongshu／WeChat 向けのモーションカードを希望する場合は、references/live-photo-production.md を参照してください。情報量の予算、単体とトリプルの Live Photo、長尺動画の受け入れ、プラットフォームへの公開時の注意点について説明しています。
• テキストを写真に重ねる場合は、必ず references/image-overlay.md を参照してください。写真の適格性、部分的な色調補正による代替策、マルチモーダルな対象物マッピングによる顔や被写体の回避について説明しています。
• ユーザーからアプリ／ウェブ／コード／ダッシュボードのスクリーンショットが提供された場合は、references/screenshot-treatment.md を参照してください。.frame-img ではなく .frame-shot を選び、角、影、背景、インセットを設定して、.device-browser または .device-phone のフレームを使用するか判断します。
• 内容に空間的な関係（旅行ルート、店舗の場所、街歩きツアーなど）が含まれる場合は、references/map-component.md を参照してください。実際のルートには Mapbox Static または OSM の静的タイルを標準で使用し、模式的な SVG は概念図やイラストマップに限って使用します。ピンは HTML オーバーレイとして配置し、ライブ JS マップは使用しないでください。
• WeChat の 21:9 以上＋1:1 の表紙ペア、またはプラットフォームをまたいだ再利用を行う場合は、references/title-shortener.md を参照してください。長いタイトルから 1:1 用の短いタイトルを導き出す方法（5 ステップの抽出、4 つのパターン、避けるべきパターン、.poster.square でのサイズ調整）について説明しています。
• ユーザーが指定した Rednote カテゴリー（旅行／職場／ゲーム／映画・ドラマ／メイク／グルメ／ファッション／インテリア／フィットネス／恋愛／おすすめ）に応じて適切なレシピを選び、対象範囲を確認するには、references/category-cookbook.md を参照してください。
• 最終画像を納品する前に、references/qa-checklist.md を参照してください。

ワークフロー

1. 受付

出力内容を左右する不足情報だけを確認します。

• 対象プラットフォームとアスペクト比。

• 原文、字幕、記事、またはタイトル。

• Rednote のカテゴリー — ユーザーがよくある 11 種類（旅行 / 職場 / ゲーム / 映画・ドラマ / グルメ / メイク / コーディネート / インテリア / フィットネス / 恋愛 / おすすめ）のいずれかを指定した場合は、references/category-cookbook.md を参照して適切なレシピを探し、依頼が対応範囲内であることを確認します（前述の「Rednote Category Capability」を参照）。対応範囲外に該当する場合は、デザインに着手する前にユーザーへ伝え、黙って対象範囲に合わせて内容を変更しないでください。

• 提供された画像やスクリーンショットと、それぞれの掲載位置。ニュース / チュートリアル / データ / レビューのコンテンツでは、スクリーンショットや写真の提供を積極的に促してください。これらは証拠となる要素です。実物の素材がないポスターは、埋め草のように見えがちです。

• Live Photo を希望している場合は、提供された動画素材。ユーザー提供の動画を通常の素材として扱ってください。ウェブで入手した無料動画を使うのは、デモ / プロモーションの場合、またはユーザーが素材の入手を明示的に希望した場合に限ります。長さはプラットフォームによって異なるため、対象プラットフォームを確認してください。Xiaohongshu は 5s に対応しています。WeChat 公式アカウントの Live Photo は 3s にし、iPhone からアップロードする必要があります。編集を始める前に references/live-photo-production.md を読み、依頼を単体の Live Photo、3 枚コラージュ、長尺動画のいずれかに分類してください。素材が長すぎる場合や、使用可能な場面が複数含まれる場合は、まず低コストで内容を確認し、その後、トリミング、速度変更、複数の枠への分割、または指定した時間範囲の使用のいずれかを一度だけ尋ねてください。素材が目標の長さより短い場合は、長いクリップの提供、短い Live Photo の受け入れ、または静止・スローダウンの明示的な許可のいずれかを尋ねてください。重要な被写体が曖昧な場合は、トリミングや拡大の選択肢を提案し、実行前にユーザーの判断を待ってください。

• ユーザーがテキストのみを提供し、画像をまったく提供していない場合は、デザイン前に一度だけ尋ねてください。

  这篇我需要 1-2 张图。三种走法：
  A. 你自己有照片 / 截图，传给我（推荐——最不"AI 感"）
  B. 我去 Pexels / Unsplash / Flickr 帮你找
  C. 用 AI 生成
  

  A を一行でおすすめしてください。自分で撮った写真があると、ポスターが AI 生成らしく見えにくくなります。ユーザーの選択（「どれでもいい、任せる」を含む）を受け入れて作業を進めてください。**後から再度尋ねたり、複数回にわたって A を勧め続けたりしないでください。**この質問は一度きりです。

• 指定がある場合は、希望するスタイル：スイス・スタイル、雑誌 / エディトリアル、テック、アウトドアなど。

• 必須条件：タイトルの文言、1:1 の表紙には画像を入れない、ハードウェアの写真を必ず入れる、スクリーンショットを読める状態にする、など。

ユーザーから十分な情報が提供されている場合は、妥当な前提を置いて進めてください。

最新の製品リリース、ポリシー、価格、主張、ニュースが含まれる場合は、ブラウジングで変動しやすい情報を確認し、最終回答で出典を示してください。

2. ストーリーを組み立てる

デザインに着手する前に、原文をページ構成に落とし込みます。

Rednote の場合：

• 1 ページ目は表紙のフックです。
• 2 ページ目以降は、各ページにアイデアを 1 つだけ載せます。
• ほとんどの投稿は 5～9 ページにします。下部のスペースが空く場合は、ページを圧縮するか統合してください。
• 細かなニュアンスは投稿本文に残し、画像にはフック、比較、チェックリスト、端的な結論を載せます。

WeChat の場合：

• 必ず 21:9 のメイン表紙と 1:1 の正方形表紙をセットで作成します。
• 2 種類の表紙を同じ HTML ファイル内で作成し、両者の視覚的なつながりをまとめて確認できるプレビューセクションを追加します。
• 21:9 には、タイトル全体またはほぼ全体、サブタイトル、印象的なビジュアル上の関係を 1 つ入れます。
• 1:1 には長いタイトルをもとにした短いタイトルを使います。文字を大きく中央に配置し、デフォルトでは画像を使わず、サブタイトルを詰め込まないでください。

3. スタイルモードを選ぶ

パッケージごとに、いずれかのモードを選びます。2つのシステムは、特定のコンテンツタイプに限定されません。異なるのはビジュアルの姿勢であり、扱えるトピックではありません。職場についてのエッセイをエディトリアルに、旅の記録をスイス・インターナショナルにできます。カテゴリーを調べて決めるのではなく、求める雰囲気で選んでください。

エディトリアルマガジン x E-ink の特徴：

• セリフ体／宋体のディスプレイフォントと控えめなサンセリフ体の本文フォント、紙とインクのパレット。
• 温かみのある紙のベースに重ねる雰囲気レイヤー（紙の粒子／インクのにじみ／WebGL キャンバス）。
• 台帳風の行、欄外の書き込み、プルクオート、大きな写真スペースによる雑誌特集の雰囲気。
• ページにゆったりとした、熟考された、手作業で組まれた印象を与えたい場合に最適です。

スイス・インターナショナル の特徴：

• Inter／Helvetica の雰囲気、大きなサイズでは非常に細いディスプレイフォント、小さなサイズではモノスペースのラベル。
• 厳密な左揃えのグリッド、極細の罫線、彩度の高いアクセントカラーを1色。
• カード塗りのマトリックス、KPI のタワー、横棒グラフ、番号付きのステートメントによる、システム／データの雰囲気。
• ページに設計された、定量的で、決断力のある印象を与えたい場合に最適です。

どちらもコンテンツに合う場合は、編集上の意図で決めます。「これは特集記事か、リリースノートか？」その答えでモードを選び、トピック自体では決めません。

ユーザーから明示的にハイブリッドを求められない限り、同じ画像セット内で2つのビジュアルシステムを混在させないでください。

次に、テーマを1つ選びます。

• エディトリアルマガジン x E-ink では、6つのマガジンパレットから1つを使います：Ink Classic、Indigo Porcelain、Forest Ink、Kraft Paper、Dune、または Midnight Ink（唯一のダークバリエーション。ゲームのキービジュアル／夜間写真／シネマティックなカバー向けです）。
• スイス・インターナショナルでは、4つのアクセントパレットから1つを使います：IKB Blue、Lemon Yellow、Lemon Green、または Safety Orange。

正確な CSS トークンは references/theme-presets.md を参照してください。ユーザーに厳格なブランド要件がない限り、任意の色を作らないでください。

4. ページの計画

簡潔な内部計画を作成します。

Page 01 / cover / hook / image source / layout intent
Page 02 / point / key copy / visual evidence / layout intent
...

ユーザーが承認を求めた場合は、レンダリングの前にこの計画を提示します。それ以外の場合は、内部で使用して作業を進めます。

references/layout-recipes.md を使用して、ページ構成を選びます。すべてのページを、タイトルとカードを繰り返すレイアウトにしないでください。

3:4 の画像では、コーディングの前に references/portrait-fill.md を確認します。短い表や台帳は、引用列、画像による証拠、欄外の書き込み、行の拡大、背景のヒーローゾーンなどを用いて、縦長の構成に展開する必要があります。

ユーザー向けのコピーでは、制作方法ではなく、ユーザーが実際に体験するシーンを描写する必要があります。3s、5s、Live Photo、triple collage、information budget、long-video intake、speed-up、highlight detection、one action point、layout template などの内部用語は、計画、ファイル名、QA メモ、納品概要の作成には使用できますが、ユーザーがそれらの概念について解説する投稿を明示的に作成している場合を除き、H1、フック、本文のメインコピーに使ってはいけません。レンダリングの前に、表示されるすべての見出しを実際の閲覧者の視点で一度読み、作業要件のように聞こえる場合は、そのシーンに即したコピーに差し替えます。

自動的な密度警告に対応するためだけに、テンプレートにない装飾を追加しないでください。追加の定規、サイドバー、疑似時間軸、装飾的なラベル、創作したバッジは、既存のレイアウトレシピまたはユーザーの依頼に基づくものでなければなりません。密度警告が出た場合は、より適切なレシピを選ぶ、実際のコンテンツのサイズを調整する、または視覚的な根拠を示して助言的な警告を受け入れることで対処します。カードに意味のない UI を配置してはいけません。

Live Photo カードは、まず通常のソーシャルカードとして計画し、その後で動きの役割を決めます。役割は、1つのアクションポイント、小さな一連の動き、変化の前後、3つの並列した結果、または雰囲気や証拠のいずれかです。構造上の変更は、1つ以上の画像領域が動画領域になることだけです。同じアスペクト比、トリミング、セーフエリア、タイポグラフィ、スタイルモードのルールを維持し、静止画のトリミングロジックを動画ストリームにも適用します。最初のフレームは静止画像と同じチェックを通過する必要があります。過剰なトリミングがなく、主要な UI／コンテンツが読みやすく、選択したレイアウトレシピに沿っていることを確認してください。レンダリングの前に references/live-photo-production.md を読みます。

素材を主役にする Live Photo パズルカードでは、動画素材を主役にします。コピーはほとんど使わないか、まったく使いません。動画が1つのカバーなら、短い見出し1つで十分です。2分割、3分割、4分割のバージョンには、通常、追加のテキストを入れません。1つの動画カバーで映像の上にテキストを載せる場合は、M16 Image-Led Cover／画像上のテキストのルールに従います。まず被写体の配置を確認し、安全な余白を確保します。Editorial serif／Songti のタイトルはレギュラーからミディアムのウェイト、紙のようなクリーム色にし、キャンバス全体を覆うマスクは既定で使いません。デザイン性を演出するためだけに、キッカー、メタ情報、細線、ラベル、定規、バッジ、字幕、説明的な制作用語を追加してはいけません。見出しが1つだけの場合は、フレーズに合わせた改行、控えめなサイズ、字間、配置、位置で、タイポグラフィ自体にレイアウトを担わせます。素材に埋め込まれたテキストは映像の一部として扱います。ユーザーからの依頼がない限り、新しいテキストを追加しないようにします。

4.5. シードテンプレートをコピーする

HTML をゼロから書かないでください。ステップ 3 で選択したスタイルモードに基づいて、シードテンプレートを 1 つ選びます。

• エディトリアルマガジン × E-ink → assets/template-editorial-card.html をタスクフォルダーに index.html としてコピーします。
• スイス・インターナショナル → assets/template-swiss-card.html をタスクフォルダーに index.html としてコピーします。

シードには、フォントの読み込み、テーマトークン、3 種類すべてのポスターサイズ（.poster.xhs / .poster.square / .poster.wide）、ペアプレビューのフレーム、グレイン／背景レイヤー、レイアウトレシピで参照するすべてのクラス定義があらかじめ設定されています。

<html> 要素にテーマ／アクセントを設定します。

• エディトリアル：<html data-theme="ink-classic | indigo-porcelain | forest-ink | kraft-paper | dune | midnight-ink">。
• スイス：<html data-accent="ikb | lemon-yellow | lemon-green | safety-orange">。

`` の後にあるプレースホルダーポスター 1 つを置き換え、各ページに 1 つずつ、選択したレイアウトレシピ（エディトリアルは M01-M16、スイスは S01-S12）の HTML 骨組みを含む <section class="poster ..."> ブロックを配置します。誤ったテンプレートのクラスシステムは決して読み込まないでください。エディトリアルのレシピはセリフ体ディスプレイ書体 + ledger/marginalia/pipeline-v を前提とし、スイスのレシピは Inter + card-fills + matrix/h-bar/kpi-tower を前提としています。これらを混在させると、気付かないうちにレイアウトが崩れます。

5. ビルドとレンダリング

デフォルトの実装パターン：

• デフォルトでは local-tests/<slug>/ の下にタスクフォルダーを作成します。ユーザーが出力先フォルダーを指定した場合は、その中に作成します。生成したタスクフォルダー、レンダリング画像、MOV ファイル、.pvt パッケージ、ダウンロードしたソースを、SKILL.md と並ぶスキルのルートには絶対に置かないでください。
• ソース画像は assets/ に置きます。
• 空のファイルではなく、Step 4.5 でコピーしたシードテンプレートをベースにします。ページごとに変更するのは、原則として `` 領域のみです。タスクでカスタムレイアウト CSS が必要な場合は、コピーしたファイルにタスク専用の名前が明確なブロックを 1 つ追加し、セマンティックなデフォルトをリセットしてください（figure { margin:0; } とし、ブラウザーのデフォルトの余白による予期しないずれを防ぎます）。
• Playwright またはブラウザーのスクリーンショットツールを使って、各 .poster または .cover ノードを書き出します。
• レンダリング画像は output/ に保存します。
• 画像の寸法を確認し、レンダリングした PNG を目視で確認します。
• 自動チェックに備え、node validate-social-deck.mjs <task-dir> を実行できる状態にしておきます。このコマンドは、オーバーフロー（R1）、フッターとの衝突（R2）、Swiss の太字ディスプレイ（R3）、最小フォントサイズ（R4）、4 バンドの密度（R5）、.h-xl の行数上限（R6）、ブラウザーのデフォルトの figure マージンによるずれ（R7）、視覚的な境界／下部の余白（R8）、タイトルとコンテンツの間隔（R9）をチェックします。いずれかのチェックが FAIL の場合、終了コードは 1 です。自動チェックが求められている場合は、最終納品の前に修正してください。WARN は参考情報ですが、内容を確認してください。

Live Photo の分岐：

• レンダリング前に情報量の上限を決めます。3s なら 1 つのアクションポイント、5s なら 1 つの小さなプロセスを表現できます。3 分割コラージュなら並行する 3 つのクリップを表現できますが、複雑なストーリーには向きません。長い動画は編集前に内容を確認する必要があります。
• 長いソース動画では、正確な自動ハイライト検出ができると主張しないでください。再生時間と解像度を確認し、間隔を広めに取ったコンタクトシートを作成してから、トリミング、速度変更、分割／3 分割コラージュ、またはユーザーへの時間範囲の確認のいずれかを選びます。
• 各動画から最初のフレームを抽出し、最終的な静止画カードのレイアウトに配置して、.pvt を作成する前にプレビューを表示して確認します。これにより、トークン消費とレンダリングコストを大幅に抑えながら、トリミングと階層構造の問題を検出できます。
• プラットフォームに合わせた長さで、対応する MOV をレンダリングします。Xiaohongshu は 5s、WeChat Official Account は 3s です。
• 内容を読み取れる代表的なフレームから、キービジュアルとなる JPG を抽出します。
• makelive を使って JPG + MOV を .pvt にパッケージ化します。iPhone でテストする場合は、.pvt を 1 つの項目として AirDrop します。
• 寸法、再生時間、フレーム数、パッケージの内容、動きの品質を検証します。目視確認ではコンタクトシートのフレームストリップを優先し、最終的に人間またはモデルが確認するタイル画像が 1 枚だけになるようにします。正確なコマンドと失敗時の確認事項については、references/live-photo-production.md を参照してください。

画像内に、目に見える操作手順、キーボードショートカット、使用方法の説明を入れないでください。

Editorial Magazine x E-ink では、レイヤー化された背景システムを使用します。控えめな WebGL のインクフローキャンバス、または固定したプロシージャルキャンバスに紙の粒子感を重ねたものを推奨します。references/background-systems.md を読み、単色のベージュ背景に頼らないでください。また、ページ全体にグリッドやドットの背景を追加しないでください。

6. 画像とスクリーンショットの扱い

ユーザーからスクリーンショットが提供された場合：

• ユーザーが再デザインを求めていない限り、スクリーンショットの内容を保持します。
• プログラムによるフレーミングを優先します。目標とするアスペクト比のキャンバス、安全な余白、すっきりした背景、読みやすいスクリーンショットを使用します。
• スクリーンショットを引き伸ばさないでください。
• スクリーンショットの鮮明さが重要な場合は、スクリーンショットの表示領域を広げ、近くのテキストを減らします。

画像上のテキスト配置

ポスターで写真の上にテキストを配置する場合（全面カバー、大きな画像領域、生成画像へのオーバーレイ）は、必ず references/image-overlay.md に従ってください。

• まず画像を選び、必要な場合に限り色を重ねます。 キャンバスの60％以上を占める写真は、まず image-overlay.md の静かな領域と明るさのテストに合格する必要があります。最初はマスクなしで配置し、サムネイルチェックに失敗した場合のみ、タイトル周辺に画像になじむ色合いの色を局所的に重ねます。キャンバス全体にグラデーションをかけるのを標準にしないでください。
• 被写体の位置を必ず把握します。 タイトルを配置する前に、Read ツールで画像を確認し、被写体の顔や焦点となる特徴がどこにあるかを平易な言葉で説明して、ヒーローブロックの隣に HTML コメントとして被写体マップを記録します。テキストは記録されたセーフゾーンにのみ配置してください。
• トリミングを適切に行います — すべての写真で object-position をインライン指定します。 テンプレートのデフォルト（center 50%）はフォールバックであり、推奨値ではありません。すべての <img> について、被写体の位置に基づいて決め、インラインで記述してください。例：胴体が中央にある被写体には style="object-position:center 62%"、地平線上に被写体がある空の多い風景には center 30%、前景のギアには center 70%。範囲については references/components.md の表を、顔写真の詳細については image-overlay.md を参照してください。この指定を省略すると、縦長の比率（r-3x4、r-21x9）で被写体がフレームから意図せず切り取られます。
• サムネイルテスト。 レンダリングした PNG を幅360 pxに縮小し、タイトルが引き続き読めることを確認します。タイトルが写真と競合する場合は、タイトルを移動するか、写真を差し替えるか、画像になじむ色合いの色を局所的に重ねます。写真の印象が弱くなる場合は、色を重ねすぎているか、テキスト配置に適さない写真を選んでいます。

キービジュアルにゲームのアートを使ったエディトリアルなダークカバーも、ヒーロー写真を使ったスイススタイルのカバーも、どちらもこれらの確認が必要です。これらを省略することは既知の失敗パターンです（style-system.md のアンチパターン D を参照）。

ユーザーが画像を用意していない場合：

• この分岐は、Step 1 の「三选一」ゲートで B（ウェブから取得）または C（AI 生成）が選ばれた場合にのみ実行します。ユーザーが選んでいないのに、B や C に暗黙のうちに進んではいけません。
• C（AI 生成）の場合：生成したビットマップは、通常1～2ページなど、本当に価値を加える箇所にのみ使用します。汎用的な装飾ではなく、ページのビジュアル上の役割に合った画像を生成します。明示的に必要な場合を除き、生成画像にタイトル、ページ番号、ロゴ、偽の UI ラベルを含めないでください。
• B（ウェブから取得）の場合：以下の「ウェブから取得した画像」のセクションを参照してください。

Web から取得した画像（ユーザーが画像を持っていない場合の代替手段）

ユーザーがスクリーンショットや写真を持っておらず、生成したビットマップ画像がページの役割に合わない場合（例：エディトリアルな雰囲気の写真、屋外／ライフスタイルの背景、ゲームのカバーアート、実在する製品の写真）は、ページが簡素にならないよう、Web から画像を取得します。

方針：まず取得し、その後に出典を開示し、帰属表示はユーザーに判断してもらいます。 推測したライセンスを根拠に、あらかじめ取得元を絞り込まないでください。最終的な構成の権利者はユーザーであり、何を許容するかはユーザーが決めます。

推奨する取得元を優先順に示します。以下の5つはすべて、ライセンス料が不要な無料プランのライブラリです。 有料ストックフォトサイト（视觉中国 / Getty / 站酷海洛など）は利用しません。

1. Unsplash — https://unsplash.com/s/photos/<keyword>。屋外／ライフスタイル／雰囲気のある背景に強みがあります。英語のキーワードが最適です。ライセンスは寛容ですが、個別に確認してください。
2. Pexels — https://www.pexels.com/search/<keyword>/ または https://www.pexels.com/zh-cn/search/<keyword>/。中国語のキーワード検索を標準でサポートしており、Unsplash が対応しにくい国内のシーン（中文の街並み／中国風の小物／現地の地名）を補えます。対象が中国固有のもの、またはキーワードが中国語の場合は、まずこちらを使ってください。Pexels License の下で無料です。
3. Flickr CC ライセンス対象の写真 — https://www.flickr.com/search/?text=<keyword>&license=2%2C3%2C4%2C5%2C6%2C9。ライセンスフィルター（license=2,3,4,5,6,9）で、Creative Commons の写真に限定できます。「ドキュメンタリーらしさ」を補えます。街頭写真、日常の中の人々、実際の室内、Unsplash／Pexels では不足しがちな演出されていないシーンなどに適しています。ユーザーが帰属表示を選んだ場合は、必ず CC の帰属表示を維持してください。
4. Wallhaven — https://wallhaven.cc/search?q=<keyword>。ゲーム／アニメ／壁紙のテーマに強みがあります。コンテンツはユーザーがアップロードしたもので、権利は未確認です。
5. Web の直接検索 — 製品のレンダリング画像、ゲームのスチル、歴史的な写真など、特定の対象が必要な場合に使います。WebFetch / WebSearch で候補の URL を探してください。

エディトリアルモードでの選択順：Pexels（キーワードが中国語／中国固有の場合）→ Unsplash → Flickr CC（実生活らしさが必要な場合）→ 直接検索。Swiss モードでは、これらが必要になることはほとんどありません。製品のレンダリング画像、UI のスクリーンショット、キービジュアル風の画像は、ストック画像ではなく、ユーザーから提供してもらうか AI で生成してください。

取得方法：

• WebFetch または curl を使って、タスクフォルダーの assets/ ディレクトリに画像をダウンロードします。
• ハッシュではなく用途に基づいてファイル名を付けます：assets/hero-mountain.jpg、assets/ui-pulse-card.png。
• 画像と同じ場所に assets/SOURCES.md ファイルを作成し、取得元 URL を記録します（ファイルごとに1行：hero-mountain.jpg ← <url>）。最終画像への帰属表示をユーザーが辞退した場合も、必ず記録してください。人間の作成者が出典を追跡できるようにするためです。

取得後、デザインを完成させる前に、ユーザーに出典情報を提示してください。

我从 <site> 取了这些图：
- assets/hero-mountain.jpg — <url>
- assets/ui-pulse-card.png — <url>

⚠️ 版权未经核实。请你判断是否可用。
是否需要在图文中标注来源？
- 要：我把 "Photo · <site> · @<author>" 加到对应页脚 / 角标。
- 不要：原样使用,不加注释。

ユーザーが「标注」を選んだ場合は、小さな mono キャプションを追加します（Swiss：隅に .t-meta を18〜20pxで配置。Editorial：画像の脇に .label を配置）。レイアウトの注目箇所にキャプションを詰め込まないでください。

ユーザーが「不标注」を選んだ場合は、そのまま作業を続けます。出典情報は引き続き、ユーザー自身の記録用に assets/SOURCES.md に残します。

画像が複数要素で構成される合成画像の一要素にすぎない場合（例：マトリクス内の9枚の写真のうち1枚）、ユーザーが帰属表示を省略するのは妥当な場合があります。レイアウトを損なうクレジット表記を無理に追加しないでください。

7. 納品

まずユーザーに確認してもらい、依頼があれば検証します。 レンダリングのたびに自動でバリデーターを実行すると時間がかかりすぎ、ユーザーが結果を見るまでの時間が遅れます。デフォルトの流れは次のとおりです。

1. レンダリングが完了したら、すぐにレンダリング済み画像をインライン（絶対パス）でユーザーに表示し、何を生成したかを一文で要約します。
2. 1つ質問します: 「先你自己看，还是我先自动核查一遍？」（先にご自身で確認しますか、それとも私が自動チェックを実行しましょうか？）
3. ユーザーが「我自己看」/「先给我」/「no need」と言ったら — ここで停止し、ユーザーに確認してもらい、提起された内容に応答します。
4. ユーザーが「你查吧」/「auto-check」/「yes」と言ったら — そのとき初めて node validate-social-deck.mjs <task-dir> を実行し、FAIL を修正して再レンダリングしてから最終納品します。density/cap の WARN について言及します。

ユーザーに表示する前にバリデーターを黙って実行しないでください — 1回の実行に数分かかりますし、多くの場合ユーザーのほうが早く問題を見つけます。

最終レスポンス（ユーザーが確認した後、または自動チェックを依頼した後）には次を含める必要があります:

• 出力フォルダのパス。
• 必要に応じて、レンダリング済み画像を絶対パス付きでインライン表示。
• 寸法と検証に関する短い注記（または「未検証、ご確認をお待ちしています」）。
• Web から取得した画像がある場合: ソース URL + サイト + ユーザーが行った帰属の判断。
• Live Photo の場合: .pvt パッケージのパス、デバッグ用の JPG + MOV ペア、対象プラットフォームの再生時間、検証の概要。
• Live Photo の公開について: ユーザーに2点をリマインドします: プラットフォームの制限（5s 小紅書、3s WeChat 公式アカウント）と公開パス（.pvt パッケージを1つの項目として AirDrop で iPhone に送信し、対応するモバイルアプリのパスから公開します。デスクトップ/Web のアップロードパスは一般的に .pvt を公開可能な Live Photo として認識できません）。
• ユーザーが iPhone/AirDrop の公開パスを使用できない場合（例: デスクトップ専用のワークフロー、Android、または Live Photo をサポートしないプラットフォーム）、劣化版の納品を提案します: 同じ MOV ソースから短いループ GIF または無音の MP4 クリップを書き出します。GIF/MP4 は動きの証拠は保ちますが、Live Photo のタップして再生する体験は失われます。このフォールバックに切り替える前にユーザーに確認してください。
• 未解決のリスク（例: ソース画像の解像度が低いなど）。

絶対に守ること

• 元の Guizang PPT スキルや、他の場所からコピーした上流のスキルは、決して編集しないでください。
• スキルのルートに生成物を作成しないでください。すべてのタスク成果物は、デフォルトで local-tests/<slug>/ の下、またはユーザー指定の出力フォルダーに保存してください。social-card-*、livephoto-*、wechat-* のようなルート直下の生成フォルダーや、個別に置かれた出力アセットは禁止です。
• 装飾目的だけの無作為な SVG の楕円、ブロブ、雨粒、ステッカー、意味のない円は作成しないでください。
• 入れ子のカードや、汎用的な SaaS カードレイアウトをデフォルトとして使用しないでください。
• テキストをはみ出させたり、端に触れさせたり、フッターバンドに重ねたりしないでください。.foot はフレックスカラム内で margin-top: auto を使って固定し、伸びるコンテンツに重ねる position: absolute は決して使わないでください。
• コンテンツがはみ出す場合は、編集前にその量を測定してください。小さなはみ出しには小さな修正を加えます。1-40px は位置調整または間隔の縮小、40-90px は局所的な圧縮、90-160px はタイトルまたは段落を少し圧縮し、160px+ の場合に限りレシピの変更やコンテンツの削除を行います。修正後は R8 の下部余白を確認し、はみ出しを巨大な下部の空白に変えてしまわないようにしてください。
• タイトルを次のコンテンツブロックに触れさせないでください。メインのディスプレイタイトルは通常、下に少なくとも 28px、ローカル見出しは少なくとも 16px の間隔を確保してください。目視確認に頼る前に、バリデーター R9 を使用してください。
• モバイルで読みにくくなるほどテキストを小さくしないでください。
• Swiss では、ディスプレイタイトルにインラインの font-size と font-weight を指定しないでください。型付きクラス（.h-hero / .h-statement / .h-xl / .num-mega）を使用してください。ウェイト 700-900 の 80-120px の見出しは Swiss ではありません。「大きいほど軽く」というルールは必ず守ってください。
• 背景が単調な紙色で、すべての行にモノラベルがあり、雰囲気のレイヤーがない Editorial ポスターを納品しないでください。references/style-system.md の Editorial Identity Test を実行してください。セリフ体のタイトルだけでは、ポスターは Editorial になりません。
• データ、リリースの詳細、パーセンテージを捏造しないでください。
• ユーザーが明示的に許可しない限り、顔、重要な UI テキスト、ハードウェアや製品の詳細をトリミングしないでください。
• 動画カードを、説明なしに偽の静止画シーケンスへ変えないでください。ソースが目標時間より短い場合は、より長いソースを依頼するか、プラットフォームで安全に使える短い時間にするか、静止またはスローダウンを明示的に記録してください。
• Live Photo の最初のフレームのプレビューを省略しないでください。動画は動きを伴う画像枠です。MOV をレンダリングする前に、最初のフレームが静止画の 3:4 レイアウトとトリミングのルールを満たしている必要があります。
• 浅いトリミングで、結果の動画がセクションの境界をまたいでスクロールする状態にしないでください。これは「動画の重なり」不具合の原因になります。パッケージ化の前にコンタクトシートを確認し、安定した時間範囲を選んでください。
• 動画を拡大またはトリミングして読みやすくする際に、ユーザーが何を優先するかを推測しないでください。トリミングと拡大のトレードオフを提示し、ユーザーの確認後に適用してください。ただし、依頼内で焦点領域が明示されている場合はこの限りではありません。
• 21:9 のカバーをそのまま 1:1 にトリミングして流用しないでください。各アスペクト比に合わせて個別に構成してください。
• 3:4 カードはキャンバスを余さず使う必要があります。コンテンツ（テキスト + 画像 + データ）は、キャンバスの高さの ≥75% を占める必要があります。キャンバスの高さの >15% にあたる単色の空白帯には、すべて「余白の理由」が必要です：(a) ヒーロー画像そのものが余白を生み出している、(b) 一文で構成する宣言的なヒーローステートメント、(c) 段落の上部と下部のリーディングおよびトレーリングの余白（合計 ≤15%）。<div style="flex: 1"></div> で上下から挟み、コンテンツを中央に押し込むことは禁止です——雑誌のページの余白の考え方はソーシャルカードには適用できません（雑誌では見開きで余白を吸収できますが、ソーシャルカードは一枚ずつ個別にスクロールされるため、内容が少ないと PPT の配置漏れのように見えます）。レシピごとの最小密度は、references/layout-recipes.md の各レシピにある「Minimum density」セクションを参照してください。レンダリング後は必ず qa-checklist.md の 4 横帯密度チェックを実行してください。