editorial-card-screenshot

編集カードのスクリーンショット

概要

ソーステキストを、ユーザーの編集プロンプトに沿ったコンパクトでコントラストの高い HTML 情報カードに変換し、対応するアスペクト比のいずれかでスクリーンショットをレンダリングします。 目標は、単に情報を詰め込むことではなく、明確な階層、強い視覚的な軸、意図しない切り抜きや余白のない、スクリーンショットで安定したレンダリングを備えた編集品質を実現することです。

ユーザーが明示的に省略を求めない限り、常に次の 3 段階で出力します。

1. 情報密度を高・中・低のいずれかで評価する一文を書く。
2. CSS を埋め込んだ完全な HTML を出力する。
3. モバイルで本文が読みやすいままであることを自己確認する。

ワークフロー

1. コンテンツの密度を分析する

references/content-fit.md を読みます。意味上の単位を洗い出し、密度を見積もって、密度と比率の両方に基づいてレイアウト戦略を選びます。

• コンテンツが少なく、ひとつのフレーズ、数字、またはフックでページを印象づけられる場合は、「ビッグキャラクター」構成を使います。
• コンテンツが多く、より明確な階層が必要な場合は、2 列または 3 列の編集グリッドを使います。
• 余白を避けるために、大きな数字、太い罫線、色付きブロック、引き合いの大きな引用を使います。
• 情報量の多いコンテンツを、均等な重みのタイルに無理に押し込みません。主要ブロック、二次ブロック、補助的な軽いブロックを作ります。
• コンテンツの種類に合わせて構成します。
  • ランキング／おすすめのコンテンツ：非対称なヒーロー領域と構造化されたリストを組み合わせます。
  • チュートリアル／分析／解釈のコンテンツ：概要、主要な判断、解釈、境界、結論にグループ化します。
• 最終 HTML の前に、短いスペース配分計画を書きます。ヒーロー、主要モジュール、補助エリア、フッターのおおよその面積を割り当てます。
• スターターテンプレートの現在の配置を、適切な骨格である根拠として使わないでください。

コンテンツを圧縮する前に、まずレイアウトの骨格を変更します。

• 比率を変える場合は、主に読み進める順序、階層、モジュールの配置を変えます。
• 比率の変更を、デフォルトでコンテンツを削除する理由として扱わないでください。
• レイアウトを再構成した後でも、現在の比率ではコンテンツを明瞭に収められない場合に限り、圧縮、グループ化、要約を行います。

2. 保存された編集ルールを適用する

ユーザーが上書きしない限り、これらのデフォルトを使用します:

• Google Fonts をインポートする:

  <link href="https://fonts.googleapis.com/css2?family=Noto+Serif+SC:wght@700;900&family=Noto+Sans+SC:wght@400;500;700&family=Oswald:wght@500;700&family=Inter:wght@400;600;700&display=swap" rel="stylesheet">
  

• 900px 幅のコンポジションでは、本文テキストを 18px から 20px に保ちます。
• メタ情報／タグのテキストは最低 13px に保ちます。
• コンパクトなスペーシングを使用します: コンテナのパディングは 40px から 50px、コンポーネント間の間隔は 30px から 40px、行の高さは 1.5 から 1.6。
• 4px から 6px のアクセント罫線、繊細なグレーの面、4% のノイズオーバーレイで視覚的な重みを加えます。
• ユーザーが別のパレットを指定しない限り、#f5f3ed または同様の温かみのある紙のような背景を優先します。
• 余白を保ちます。カードが落ち着きを失うほど外側のマージンを縮めないでください。
• タイトルゾーンでは、より大きな行の高さと、サブタイトル／要約ブロックとの明確な分離を優先します。
• 密度の高い右側のモジュールでは、重く感じさせずにページを明快に保つため、フォントの太さを少し抑えます。
• ブロック内ではより強い内部構造を使用します: 小見出し、箇条書き、番号付きの行、比較行、または副次的なラベル。
• カードが密度の高い場合、同じ重みのボックスは避けます。少なくとも 1 つのモジュールは他よりも視覚的に重く感じられるべきです。
• すべてのモジュールがまったく同じ視覚言語を使うのは避けます。トーン、スケール、背景の処理、またはタイポグラフィの重みによって、少なくとも 1 つか 2 つの領域を差別化します。
• デフォルトでは、選択的なハイライトを備えた落ち着いた編集モードにします。ユーザーがより強い表現を求めた場合は、次の方向に寄せてもかまいません:
  • Bold: よりカバーのような、強いアンカー、より大きな弱背景テキスト、より重いアクセント。
  • Refined: より軽いコントラスト、より静かなアクセント、より抑制された紙のような雰囲気。
  • Hybrid: スタイルが指定されていない場合に推奨されるデフォルト。全体的には refined で、いくつかの bold なアンカーの瞬間を伴います。
• Google Fonts のインポートは維持しますが、リモートフォントの読み込みに失敗してもレンダリングされた PNG が構造的に安定するよう、常にローカルのフォールバックスタックを提供します。
• ユーザーがタイトルを明示的に指定した場合、デフォルトでその正確なタイトルをメインのヘッドラインとして使用します。ユーザーが求めた場合、またはレイアウト変更後に比率がそれを明確に保てない場合にのみ、圧縮または再解釈します。
• 解釈、要約、フレーミングは、メインタイトルを黙って書き換えるのではなく、サブタイトル／デッキ／要約のフィールドに置きます。
• ユーザーが明示的にブランディングを求めない限り、再利用可能なカードに個人の署名、作成者のアバター、アカウントハンドルをハードコードしないでください。

3. 適切なレイアウトスケルトンを選択する

最終的なコピーを書く前に、比率に応じた構造を選びます。

4:3

• 完全な分析的な見開き、またはランク付きリストに最適です。
• 優先: ヒーロー + 要約帯 + 密度の高い 2 カラムリスト + より強いフッター。
• ページが 10 個の等しい項目の平坦な壁にならないよう、リストの前に 1 つの主要な判断ブロックを使用します。
• 推奨される再利用可能なスケルトン:
  • 主要なプロセス／順序／フレームワーク用の左側の重いプライマリモジュール
  • 要点、落とし穴、または判断用の右側のより狭いスタック
  • 下部の軽いが意図的なソース／核心判断の帯
• 4:3 を上から下まで対称的な 2 カラムの新聞の壁にしないでください。

3:4

• 同じ情報への意欲を保ちつつ、読み進める経路を変えます。
• 優先: タイトル帯 + インサイト行 + 大小混在の本文モジュール。
• 混在するスケールを使用します: 1 つの重いプライマリブロック、1 つまたは 2 つの中規模ブロック、より小さなサポートブロック。
• 縦長カード全体が長い単一カラムに崩れないようにしてください。
• 推奨される再利用可能なスケルトン:
  • 強いカバースタイルのタイトルゾーン
  • コンパクトな統計帯またはインサイト帯
  • 1 つの大きなプライマリモジュール
  • 1 つの中規模の判断モジュール
  • 要点／落とし穴／例のための 2 つのより小さな下部モジュール
• 下半分が、ほんの数行のコピーだけの 2 つの大きな空のボックスになるレイアウトは避けてください。

1:1

• 能力マップ、グループ化された比較、またはバランスの取れた編集的な概要に最適です。
• 推奨: 強いヒーロー + 1 つの重めのクアドラント + 3 つの補助的なクアドラント + 密度の高いフッターストリップ。
• 正方形のレイアウトは、均等にタイル状に並べるのではなく、中央揃えでモジュール式に感じられるべきです。
• 1:1 をすべてのカードのデフォルトのスケルトンとして扱わないでください。出力比率が実際に正方形である場合にのみ選択してください。
• 推奨される再利用可能なスケルトン:
  • 上部全体にわたる強いタイトル / サブタイトルのヒーロー
  • 1 つのコンパクトな統計ストリップ
  • 主要なフレームワークまたはシーケンス用の 1 つの重い左モジュール
  • 1 つの右上の判断モジュール
  • 要点 / 落とし穴または比較ブロック用の 1 つの右下の分割
  • 下部の 1 つの薄いソース / 核心的判断ストリップ
• 4 つの等しいクアドラントを避け、あまりに多くのボックスに広がる小さなタイポグラフィを避けてください。

ワイドカバー (3:1、5:2、2.35:1)

• 段落の長さを積極的に短縮してください。
• より少なく、より大きなブロック、より強い見出し、短いサポート行を使用してください。

16:9

• 横方向のヒーローと 1 つの構造化されたサポート領域を優先してください。
• 快適な容量は、およそ 2 ～ 5 の主要ポイント相当に保ってください。

9:16

• コンパクトなヒーロー、1 つの支配的な中央モジュール、グループ化された下部サポートを備えた、段階的な縦方向の読み取りパスを使用してください。
• キャンバス全体にわたって同じ高さのモジュールを繰り返すことは避けてください。

4. レンダリング用 HTML の構築

HTML をスクリーンショットにする場合は、レスポンシブなウェブページではなく、サイズを固定したキャンバスとしてページを設計します。

• references/ratios.md で選択した比率プリセットと、ピクセル寸法を正確に一致させます。
• カードは、流動的な 100vw / 100vh レイアウトではなく、width と height を明示したデザインボードとして扱います。
• html, body { margin: 0; } を指定して、ブラウザーのデフォルトの余白を削除します。
• カード自体をスクリーンショットのビューポートと寸分違わず一致させます。
• インタラクション、固定ヘッダー、長いスクロールセクションは避けます。
• 次のように、ピクセル単位で固定したラッパーを使用します。

  .frame {
    width: 2000px;
    height: 1500px;
  }
  
  .card {
    width: 100%;
    height: 100%;
    padding: 48px;
    background: #f5f3ed;
  }
  

スクリーンショット出力の主要なデザインサイズとして、100vw、100vh、レスポンシブなコンテナ幅に頼らないでください。

ユーザーが HTML のみを求めた場合でも、スクリーンショットに適したレイアウトにします。

同時に、ブラウザーでの基本的なプレビュー動作も維持します。

• スクリーンショットモードでは、html、body、外側のフレームをターゲットのキャンバスサイズと正確に一致させます。
• モバイル／狭い幅のプレビューモードでは、メディアクエリのフォールバックを追加し、ページを通常のフローに戻して、スクリーンショットのワークフロー以外でも HTML を読みやすくします。

カードを構成する際は、次の構造上のヒューリスティクスを使用します。

• 比率を意図的に活用します。静的なテンプレートをそのまま拡大縮小するのではなく、幅と高さに合わせてレイアウトのバランスを調整します。
• 4:3 の横向きでは、情報量の多い分析コンテンツに左右非対称のレイアウトが適していることがよくあります。
• 3:4 の縦向きでは、幅の狭い単一カラムではなく、縦向きに適した混合グリッドを使用します。
• タイトル、サブタイトル、要約、モジュールは、明確な行や帯で区切り、互いに重ならないようにします。
• ユーザーからタイトルが提供されている場合は、重要な基準点として扱います。短縮や言い換えを検討する前に、タイトルを中心にレイアウトを広げます。
• 番号付きモジュールを使う場合は、番号の視覚的な存在感を十分に弱め、タイトルと重ならないようにします。
• セクションが視覚的に単調になった場合は、装飾を増やして雑然とさせるのではなく、階層を変えてコントラストを付けます。
• 大きなモジュールには、小さなモジュールよりも豊富なコピーを配置します。すべてのブロックに同じ量のテキストを入れないでください。
• フッター付近に意図しない大きな空白が生じたり、重要なコンテンツがキャンバスの端に押しやられたりするような 1fr の行や列の使い方は避けます。
• 色付きや暗色のパネルを引き伸ばして、余った高さを埋めないでください。色付きパネル内の空白は、余白ではなく未完成のモジュールに見えます。
• 下半分が空いている場合は、テキストを小さくしたりコンテナを引き伸ばしたりする前に、まずモジュールの階層を調整するか、下部により印象的な帯を追加します。
• 情報密度の高いカードでは、最後のモジュールとフッターの間に大きな無地の空白を残さないでください。モジュールを再配置するか、簡潔な結論の帯を追加します。
• 下部のモジュールが視覚的に大きい場合は、その面積に見合うだけの内部構造や、判断を示す補助的な一文を加えます。

5. スクリーンショットをキャプチャする

ユーザーが PNG 出力を希望する場合は、付属のシェルスクリプトを使用します。

./scripts/capture_card.sh input.html output.png 3:4

対応する比率とレンダリングサイズは、references/ratios.md に記載されています。

レンダリングヘルパーには、ローカルの Chrome または Chromium バイナリが必要です。 CHROME_BIN が設定されている場合はその値を優先し、設定されていない場合は一般的なバイナリ名と macOS の Chrome アプリのパスを順に使用します。

スクリプトを実行する前に：

• 生成した HTML をローカルファイルに保存します。
• フォント以外の外部依存がない、自己完結型のページであることを確認します。
• デフォルトのフォントインポートを維持する場合、レンダリング時にネットワーク経由で Google Fonts がリクエストされます。
• HTML で、選択した比率プリセットに合った固定サイズのデザインキャンバスを使用していることを確認します。
• ビューポートの構成が、要求された比率にすでに合っていることを確認します。
• ヘッドレスレンダリング中にフォントのダウンロードに失敗してもレイアウトが安定するよう、フォールバックフォントを指定します。

スクリプトの実行後：

• PNG を開いて確認します。
• references/content-fit.md に記載されているレンダリングチェックをすべて実施します。
• タイポグラフィを変更したり、文言を短くしたりする前に、骨組みを見直します。
• 説明のつかない空白領域、窮屈なモジュール、切り取られたコンテンツがある場合は、最初のレンダリングを納品しないでください。

レイアウトを改善してもスクリーンショットの下部に余白が残る場合：

• デフォルトの比率に基づくスクリーンショットを、メインの出力として維持します。
• ユーザーが縦横比のわずかな変更を明示的に許可した場合に限り、レンダリング後にオプションのトリミングヘルパーを実行します。
• トリミングは後処理による調整とし、デフォルトのレンダリング動作にはしないでください。

6. 比率のポリシー

次の比率プリセットのみを受け付けます：

• 3:4
• 4:3
• 1:1
• 16:9
• 9:16
• 2.35:1
• 3:1
• 5:2

ユーザーがこの一覧にない比率を指定した場合は、新しい比率を独自に作るのではなく、最も近い対応プリセットに置き換えるよう依頼します。

出力の要件

カードの生成を依頼された場合：

• 情報密度を説明する文を、ちょうど 1 文だけ最初に記載します。
• 続けて、完全な HTML を 1 つのコードブロックに出力します。
• 画像も併せて依頼された場合は、HTML の後に使用した比率とスクリーンショットのコマンドを記載します。
• 説明は簡潔にし、HTML を成果物とします。

リソース

references/ratios.md

正確なプリセット名やキャプチャ寸法が必要なときに開きます。

references/editorial-card-prompt.md

最新の検証済みエディトリアルカードの動作を求められた場合に、標準のプロンプト仕様として使用します。

references/recommended-skeletons.md

その場限りの構成案ではなく、比率ごとに再利用できる骨組みを使う場合に参照します。

references/content-fit.md

骨組みを選ぶ前とレンダリング後に開きます。意味単位の密度、比率ごとの収容力、スペース配分、空白や過密なカードを却下するためのチェック項目が記載されています。

scripts/capture_card.sh

対応する比率プリセットを使用して、ローカル HTML ファイルから PNG をキャプチャするときに実行します。 ローカルの Chrome または Chromium バイナリ、あるいは明示的な CHROME_BIN の指定が必要です。

scripts/trim_card_bottom.sh

下部の余白を取り除く代わりに、最終画像がわずかに短くなることをユーザーが許可した場合に限り、任意の後処理として実行します。

assets/card-template.html

実際のコンテンツを入れる前に、比率に対応した最小限の HTML キャンバスを用意するときの出発点として使用します。 テンプレートはキャプチャ時にキャンバスのサイズをアクティブなビューポートに合わせます。また、ブラウザーの幅が狭い場合は、読みやすい通常フローにフォールバックします。

失敗チェック

HTML または PNG を最終確定する前に、以下のいずれかに該当する場合は、結果を明示的に却下してください。

• より適切なレイアウトなら比率を保てたにもかかわらず、ユーザー指定のタイトルが黙って書き換えられている。
• タイトルがサマリーや本文コンテンツに重なっている、視覚的にぶつかっている、または隠している。
• 横幅に余裕があるのに、タイトルが狭い縦長の帯になっている。
• 情報量の多いカードが、同等の重みを持つボックスに細かく分割されすぎている。
• 大きなブロックの文章量が少なすぎて、中身のないコンテナーのように見える。
• より明確な階層構造、内容の充実したブロック、またはより大きなメインモジュールで埋められる大きな空白がキャンバスにある。
• PNG が HTML のレイアウト意図に比べて明らかに空疎に感じられる。
• リモートフォントの読み込みに失敗し、ローカルのフォールバックスタックも指定されていないため、レンダリングされた PNG と HTML で読み進めるリズムが異なる。
• フッターまたは下部の帯が切れている、あるいはグリッドのサイズ設定によってコンテンツが下端から離れ、大きな余白が下部に生じている。
• 意図的に情報量を抑えたカバー構成でないにもかかわらず、最下部の意味のあるコンテンツがキャンバスの高さの 80% より上で終わっている。
• 説明のない空白領域が、全体のおよそ 20% を超えている。
• 選択した比率では収まりきらないのに、カードがグループ化、要約、または分割されていない。