app-store-screens

App Store スクリーン

ブランドと実際の製品画面を組み合わせて、iPhone 6.9 インチサイズ（1290×2796）の App Store キャンペーン用スクリーンを5〜6枚制作します。製品画面には、書き出した素材、Figma／ソースファイル、または Pika MCP 経由で取得した公開 App Store 掲載情報を使用できます。ストーリー性があり、目を引き、ブランドに厳密に沿ったデザインにします。

これは build-a-brand の姉妹スキルです。このスキルの brand.md 仕様を使用しますが、ユーザーから提供されたあらゆるブランド仕様にも対応します。

費用の透明性に関する確認

有料 MCP 呼び出しの前に、identity_balance({verbose: true}) を1回呼び出してください。現在の残高、直近の消費ペース、残りの利用可能期間を提示したうえで、次の正確なメッセージで実行の許可を求めてください。

Estimated cost: about 150-300 credits (~$1.50-$3.00) for a typical 5-6 screen set using GPT-image-2, PNG renders, post-render analyze_media QA, and full-resolution individual PNG QA. This is below $5, but Reply proceed to continue or cancel to stop.

ユーザーが proceed と返信するまでは、有料 MCP ツールを呼び出さないでください。ユーザーが cancel と返信した場合は、生成せずに終了してください。非対話型の --quick または --config 呼び出しでは、設定に cost_ack=proceed が必要です。指定がない場合は、クレジットを消費せず、見積もりを提示して終了してください。

納品物

番号付きの PNG 5枚または6枚を、~/Desktop/[app-name]-app-store-screens/（またはユーザー指定の場所）に保存します。

01_hook.png            ← biggest claim, works as a search-result thumbnail
02_value.png           ← the one thing the app does best
03_feature_a.png       ← specific capability
04_feature_b.png       ← another specific capability
05_proof.png           ← social proof, awards, "loved by", differentiator
06_close.png           ← optional 6th — closer / CTA / brand flourish

さらに、全6枚を一覧できるコンタクトシート（_preview.png）を用意します。

ワークフロー

ステップ0 — 受付とスタイルの選択

引数が空で、利用可能なブランド／スクリーンショット／デモのコンテキストもない状態で呼び出された場合は、このメニューをそのまま表示して終了してください。必要な入力がそろうまでは、画像の生成や HTML のレンダリングを行わないでください。

どのような App Store スクリーンセットを作成しますか？ 必須：

• ブランド仕様 — 名前、カラーパレット、フォント、トーン、画像の方向性を含む brand.md または同等のブランドメモ。あるいは、掲載情報を取得してブランドの読み取りから作成する場合は、App Store の URL／アプリ名
• 製品の生スクリーンショット — 書き出した PNG、書き出し可能な Figma／ソースファイル、スクリーンショットのフォルダー、または Pika MCP で取得できる App Store の URL／アプリ名
• または架空アプリのデモ概要 — 実在する製品がないローンチデモ／コンセプトに限ります。demo_mode: true と指定し、架空のアプリの機能を説明してください

任意：参考用の App Store スクリーンショット、ムードボード、希望するスクリーン数（5枚または6枚）、出力フォルダー。

対話モードでユーザーから一部の入力が提供されている場合は、不足している必須項目だけを尋ねて終了してください。非対話型のファストレーンが適用される場合は、代わりにステップ0.5を使用してください。必須入力：

• brand.md または、名前、カラーパレット、フォント、トーン、画像の方向性を含む同等のブランド仕様。ユーザーが App Store の URL を提示し、「作成を手伝って」と依頼した場合は、まず掲載情報を取得し、その掲載情報／アイコン／スクリーンショットから推定したブランド仕様を作成して、承認を得てください
• 製品のソースを1つ：製品の生スクリーンショット、書き出し可能な Figma／ソースファイル、または Pika MCP 経由で取得できる App Store の URL／アプリ名
• 架空のローンチデモに限り、実際の製品スクリーンショットの代わりに demo_mode: true と demo_brief を使用できます。「架空アプリのデモモード」の手順に従ってください
• 特定の App Store スタイルを希望する場合は、参考用のスクリーンショットまたはムードボードを任意で指定できます

ステップ 0.5 — 非対話型の高速レーン

呼び出し元が --quick または --config <path> を渡す場合、あるいは CI、サブエージェント、バッチジョブ、その他の非対話型ハーネスから実行していると明言した場合は、この方法を使用します。

このセクションは、以下の対話型の質問／待機指示よりも優先されます。該当する場合はこの高速レーンを使用し、必要なブランド情報と、製品のスクリーンショットまたは明示的なデモモードの入力が本当に不足している場合を除き、複数ターンにわたる情報収集には移行しないでください。

• --config <path> は、事前に決められた選択肢を含む JSON ファイルを指定します。選択肢は brand_spec、product_screenshots、app_store_url、website_url、reference、style、screen_count、narrative_arc、demo_mode、demo_brief、output_folder です。
• --quick の場合、参照が指定されていなければデフォルトのスタイルを選び、提供されたブランド仕様または App Store の掲載情報からブランドの印象を推測し、5～6 画面の流れを自分で作成して、そのまま進めます。
• --quick または --config の場合、スタイルの選択、ブランドの印象の共有、参照ルールの共有、5～6 画面の戦略案について確認を求めて作業を止めないでください。前提をインラインで記録し、デザイン／レンダリングを続けてください。
• 実際の製品スクリーンショットも、demo_brief を伴う明示的な demo_mode: true も利用できない場合は、複数ターンの質疑応答を始めず、不足している項目を簡潔にまとめて一度だけ提示して停止してください。

架空アプリのデモモード

呼び出し元が、これが架空のアプリ、偽のアプリ、ローンチデモ、コンセプトデモであると明示した場合、または設定で demo_mode: true を渡した場合にのみ使用してください。実在する製品にはデモモードを使用しないでください。

実在する製品のスクリーンショットがない場合、デモモードではブランドのトーンに沿った代表的な UI モックを作成できます。ただし、出力には本番用アセットではなく、デモ専用のコンセプト作業であることを明記する必要があります。作成した画面は、実在する製品の App Store Connect 対応の証拠ではなく、絵コンテ形式の QRT／デモ用成果物として扱ってください。

• demo_brief、またはアプリの中核となる役割、対象ユーザー、3～5 個の機能、訴求／CTA の方向性を定義できるだけのユーザー提供の製品コンセプト詳細を必須とします。
• そのブリーフと内部的に一貫した UI 状態を生成してください。プロンプトで明示的に提供されていない限り、実在する顧客、実在するレビュー、実在する指標、実在する連携機能を示唆しないでください。
• 納品時の注記とコンタクトシートのラベルに、デモ専用であることを示す文言を追加してください：「Demo UI concept — not production assets and not real product screenshots.」
• 非対話モードでは、設定で demo_mode: true が指定され、demo_brief が提供されている場合にのみ進めてください。それ以外の場合は、不足している項目を簡潔に列挙して停止してください。

対話モードでは、必要な入力が揃っている場合、簡潔なアジェンダを提示し、最初にスタイルについて質問を 1 つしてください。デフォルトを希望するか、特定のリファレンスを希望するかを確認するには、このタイミングが最も効率的です。非対話のファストレーンでは、reference または style が指定されていない限り、デフォルトのスタイルを選択し、その前提をインラインで記録して続行してください。

here's how this works:
1. **Read your brand + screenshots** — i absorb the brand voice, palette, type, and figure out what the app actually does
2. **Strategy** — i pitch a 5–6 screen narrative arc (hook → value → features → proof → close) with headlines for each, before any design
3. **Design + generate** — i design each layout, composite at 1290×2796
4. **Preview** — i deliver the PNGs + a contact sheet so you can see the whole campaign at once

quick question before i start — **do you want the default style, or something specific?**

- **Default** — clean, restrained, screens shown untouched. Full-frame device, headline + sub above, solid brand-color backgrounds, brand-voice copy. Codified in `references/default-layout.md`. This is what i deliver well.
- **Something specific** — share a clear reference: a screenshot of an App Store page you love (Notion, Calm, Things, Headspace, anything), a figma file, a moodboard image. I'll study it, extract the compositional rules (device size + position, headline treatment, background, any signature flourishes), pitch back what i read before designing, then build the campaign — **with your brand's palette, fonts, voice, and photography style swapped in**. So if the reference uses an over-the-shoulder photo, i'll generate one in your brand's photo style (`gpt-image-2` accepts the reference as a style input). The reference dictates the composition; your brand dictates the look.

if you don't tell me, i'll go with default.

「派手に」する自動モードがない理由。 リッチで変化に富み、ドラマチックな構成をうまく作るには、視覚的な判断（遠近感、レイヤー構成、タイポグラフィの階層、色のバランス）が必要で、プログラムで答えを出せるものではありません。リファレンスなしでリッチさを求められた場合、私の近似案は素人っぽくなりがちです。具体的なリファレンスを尋ねれば、自由に創作するのではなく、再現するための具体的なルールを抽出できます。また、ユーザーも意図した方向性が合っているかを確認できます。

回答に応じて、以降は次の 2 つの進め方に分かれます。

• デフォルト → references/default-layout.md に最初から最後まで従ってください。すべての画面で同じ構成の骨格を使い、色とコンテンツで変化をつけます。一貫性があり、ブランド規範に沿った成果物になります。
• リファレンスを再現 → リファレンスを調べ、ルールを抽出し、ユーザーのブランドに置き換えます。詳しい手順は、以下の「リファレンス主導の進め方」を参照してください。

ユーザーがリファレンスを提供できない、または提供するつもりがない一方で、デフォルト以上のものを希望する場合は、穏やかに説明してください。リファレンスがなければ、デフォルトにユーザーのブランドカラーを加えたものを提供することになり、それは推測を重ねる試行錯誤を繰り返すよりよい選択です。その場で「派手な」スタイルを考案しないでください。

ステップ 1 — ブランドと製品を確認する

App Store の掲載情報を使う場合

ユーザーが製品のソースとして apps.apple.com の URL、数値形式の App Store アプリ ID、またはアプリ名の検索語を指定した場合は、後続のレンダリング工程ですぐに使えるホスト済みのスクリーンショットとアイコンのアセットが返され、処理も高速で安定しているため、まず Pika MCP の fetch_appstore_screens を試してください。

fetch_appstore_screens(
  query: <app_store_url | numeric_app_id | search_term>,
  country: "us",
  max_screens: 10,
  include_icon: true
)

返された metadata、icon、screenshots を製品のソースとして使用してください。返されたスクリーンショットの url 値はすでに Pika がホストする HTTPS アセットなので、後続の html_to_png 段階でそのまま使用できます。

ユーザーが特定の国の App Store URL を提供した場合は、可能であればツールを呼び出す際にもその国のストアフロントを維持してください。国が不明な場合は、ユーザーから別のストアフロントを指定されない限り、デフォルトで "us" を使用してください。

MCP ツールが利用できない、認証されていない、またはスクリーンショットが返されない場合は、何が起きたかを伝えてから、利用可能な方法のうち最も不安定さの少ないフォールバックを使用してください。ほかの読み取り／取得ツール、公式の App Store／iTunes メタデータエンドポイント、またはユーザー提供のスクリーンショットを使えます。実際の掲載情報に基づくアセットを使用し、製品 UI を創作しないでください。

想定される結果の形式：

{
  "app_url": "https://apps.apple.com/...",
  "metadata": { "name": "...", "subtitle": "...", "description": "...", "category": "...", "icon_url": "https://..." },
  "icon": { "url": "https://cdn.pika.art/...", "source_url": "https://is...mzstatic.com/...", "filename": "appstore-icon.png", "mime_type": "image/png", "width": 1024, "height": 1024 },
  "screenshots": [
    { "url": "https://cdn.pika.art/...", "source_url": "https://is...mzstatic.com/.../1290x2796bb.png", "filename": "appstore-screen-01.png", "mime_type": "image/png", "width": 1290, "height": 2796 }
  ],
  "count": 1
}

ソーススクリーンショットの準備

デフォルトのスマートフォンレイアウトを選択する前に、取得した各ソーススクリーンショット、またはユーザー提供の各ソーススクリーンショットを分類し、使用する source_treatment を記録します。

• clean_ui_capture - デバイスのモックアップに適した、アプリ内 UI の未加工のキャプチャです。
• composed_marketing - 完成済みの App Store 向けマーケティング画面であり、アプリ内のクリーンなスクリーンショットではありません。
• legacy_footer_cleanup - デバイスに埋め込む前に、掲載ブランドのフッターまたはウォーターマークだけを除去すればよい、クリーンな UI です。

composed-marketing のソースは、あらかじめ構成されたマーケティング画面です。よくある特徴として、スマートフォンの上に見出しや小見出しがすでに配置されている、スマートフォンがソース画像の端まで達している、背景がすでにキャンペーン用アートになっている、ソース画像がクリーンな製品 UI ではなく、完成済みの 1290x2796 の App Store 画面である、などが挙げられます。2025 年版 Notion の掲載画像はこのパターンです。

ソースが composed_marketing の場合、別のデバイスモックアップ内に配置し直したり、既存の見出しの上に2つ目の見出しや小見出しを追加、記述、生成したりしないでください。代わりに、クリーンな UI キャプチャを優先してください。キャプチャ可能な実際の UI 画面がある場合は、製品のウェブサイト、オンボーディング、またはウェブアプリで capture_website を使用するか、シミュレーター、Figma、または未加工の UI エクスポートを依頼してください。クリーンな UI 画面が利用できない場合は、source_treatment=composed_passthrough を使用します。構成済みのソースをそのまま画面／背景として提示し、最小限の表示枠、番号、またはコンタクトシートのラベルだけを追加してください。構成済みのソースの修正に、下部 6-8% の切り抜きを頼らないでください。誤った領域が削られるだけで、見出しの重複という問題は解決しません。

それ以外はクリーンな UI である旧形式のソーススクリーンショットについては、生成するキャンペーン内で余計な表示にならないよう、フッターのウォーターマークのにじみや掲載ブランドのフッターがないか確認してください。R4 版 Notion の掲載画像では、画面下部のコンテンツに NOTION · NOTES, TASKS, AI という未加工のフッターが重なる問題が見られました。取得したもの、またはユーザー提供のクリーンな UI のソーススクリーンショットにこの種のフッターウォーターマークがある場合は、デバイスに埋め込む前に下部 6-8% を切り抜くかマスクしてください。未加工のスクリーンショットをそのままデバイスに配置しないでください。

HTML の段階では、準備済みのスクリーンショット用ラッパーを使用し、ソースの上端を固定します。ラッパーには独自のジオメトリを定義してください。デバイスまでのすべての親要素に明示的な高さが設定されている場合を除き、height:100% に依存しないでください。

<div class="source-screen-crop source-screen-crop--phone" style="
  width:100%;
  aspect-ratio:1290 / 2796;
  overflow:hidden;
  position:relative;
">
  <img src="s://screen01" style="
    width:100%;
    height:calc(100% / 0.92);   /* shows the top 92% while cropping the bottom 8% */
    object-fit:cover;
    object-position:top center;
    display:block;
  ">
</div>

8% の切り抜きで実際の製品 UI が削られる場合は、代わりにフッターの下部にブランドカラーのフェードを重ねます。ただし、最終的なデバイスモックアップにスクリーンショットを入れる前に、ウォーターマークのにじみは必ず除去してください。

Mac アプリまたはハイブリッドアプリのスクリーンショットの扱い

fetch_appstore_screens は、Things 3、Drafts、Numbers、Day One、OmniFocus、BBEdit などの Mac 専用アプリや iOS/Mac ハイブリッドアプリについて、iPhone の縦向きスクリーンショット（1290×2796）ではなく、横向きの Mac スクリーンショット（例：1290×806）を返すことがあります。デフォルトの iPhone 縦向きレイアウトを選択する前に、これを検出してください。

向きの判定ルールは aspect_ratio_w > aspect_ratio_h です。ピクセル寸法だけがある場合は、width > height を使用します。

mac_shots = [s for s in screenshots if s.aspect_ratio_w > s.aspect_ratio_h]
# Equivalent when explicit aspect ratios are not present:
mac_shots = [s for s in screenshots if s.width > s.height]

mac_shots が空でない場合は、フルフレームのデバイスショットではなく、references/mac-app-layout.md に記載されている埋め込みカードレイアウトを使用してください。Mac 専用アプリやハイブリッドアプリでは、各横向きスクリーンショットを iPhone のフレームに合わせて切り抜いたり、レターボックス化したり、フルフレームのデバイス画像として扱ったりせず、1290×2796 の縦向きキャンバス内に角丸の UI カードとして埋め込みます。Things 3 のラウンド 2 ベンチマークでは、この方法の有効性が確認されました。Mac のスクリーンショットは読みやすさを保ち、縦向きのキャンペーンも App Store Connect の要件を満たしました。

ソーススクリーンショットの準備は Mac のカードにも適用されます。横向きスクリーンショットに、掲載ブランドのフッターやフッターウォーターマークのにじみがないか、埋め込む前に確認してください。Mac の UI にスマートフォン用の縦向き切り抜きを適用しないでください。source-screen-crop--mac のような専用カードラッパーを使い、横向きのアスペクト比を維持してください。修正が必要な場合は、カード内で下部に細いマスクやフェードを適用するか、横向きの比率を保ったまま下部を少し切り抜いてください。

不足している App Store の掲載情報に関するガードレール

fetch_appstore_screens の実行後、実際の製品 UI が表示されている、使用可能なスクリーンショットの数を数えます。実際の製品スクリーンショットが 3 枚未満の場合は、App Store の掲載情報が不足していると判断します。

• UI を捏造して 5～6 画面のキャンペーンを作成しないでください。デバイスフレームには、実際の製品 UI を使用することが原則です。
• 対話モード：戦略の立案に進む前に止まり、次の 2 つの選択肢を提示します。
  1. ウェブサイトのキャプチャ経路 — capture_website または提供されたウェブサイト／オンボーディングの URL を使用して実際の製品画面をキャプチャし、そのキャプチャを製品スクリーンショットとして続行します。
  2. 実際のスクリーンショットを使う経路 — 続行する前に、シミュレーターからの書き出し画像、Figma フレーム、またはその他の製品 UI キャプチャを依頼します。 実際の製品について、合成したデバイス UI を提案しないでください。ユーザーが明示的に架空のローンチ／コンセプトデモへ切り替える場合は、「架空アプリのデモモード」に切り替え、demo_mode: true と demo_brief を必須とします。
• 非対話型の高速レーン：website_url または明らかに製品のウェブサイトとわかるものがある場合は、ウェブサイトのキャプチャ経路を優先します。キャプチャ可能な製品画面がない場合は、設定で demo_mode: true が明示され、demo_brief が指定されている場合を除き、不足項目を簡潔に列挙して一度だけ停止します。

取得後は、掲載情報とビジュアルから暫定的なブランド像のみを推測します。内容は、アプリ名、カテゴリー、見て取れる配色、推定される書体の方向性、サブタイトル／説明文から読み取れるトーン、注目すべき UI の場面です。対話モードでは、5～6 画面の展開を提案する前に、暫定的なブランド仕様としてユーザーに提示し、修正を求めます。非対話型の高速レーンでは、これを暫定的なブランド仕様として記録し、そのまま続行します。

参考資料主導のパス：参考資料のスタイルにユーザーのブランドを適用する方法

参考資料が示すのは、レイアウトやスタイルがどのように見えるかです。ブランドが示すのは、どの色、フォント、語り口、写真を使うかです。このスキルの役割は、両者を組み合わせることです。参考資料のビジュアル構成を再現しつつ、ユーザーのブランドで表現します。参考資料から2つ、ブランドから2つの要素を抽出します。

参考資料から、構造上のルールを抽出します：

• デバイスのサイズ（キャンバスに対する割合）と傾きの角度
• 見出しの表現（サイズ、位置、色のルール — キーワードをアクセントにするか、色付きの背景ピルにするか）
• 背景の表現（単色、写真、グラデーション、抽象的な要素）
• ヒーロー画像のパターン（スマートフォンを持つ手、肩越しの視点、画面から飛び出す実在の被写体、浮かぶ3Dオブジェクトなど）
• コールアウト／引き出しのパターン（矢印付きの吹き出し、浮かぶカード、ポラロイド風フレームなど）
• 繰り返しのルール：すべての画面で同じレイアウトにするか、スロットごとに変化させるか

ブランドから、具体的な要素を適用します：

• カラーパレット（参考資料で単色のブロックが使われている箇所をブランドカラーに置き換える）
• フォント（参考資料で文字が使われている箇所を、ブランドのディスプレイフォントと本文フォントに置き換える）
• 語り口（見出しやサブ見出しはすべてブランドの語り口に書き換え、参考資料の文言はコピーしない）
• 写真の方向性（生成画像はすべてブランドの撮影ルールに従う。DeltaStream の場合は、ドキュメンタリー調の35mm写真、ゴールデンアワー、実際のアパートメント、すべてのフレームにバター色のアクセント、多様な人々のキャスト）
• ムード（温かみのある雰囲気か、無機質な雰囲気か、遊び心のある雰囲気か、専門的な雰囲気かなど）

ヒーロー画像を生成する場合：参考資料を images として generate_image_edit 経由で gpt-image-2 に渡します。 このツールでは、最大16枚の参考画像を使用できます。参考資料に特徴的な写真構図（スマートフォンを持つ手、肩越しの視点、画面から飛び出す人物、画面から現れる3Dキャラクターなど）が使われている場合に利用してください。プロンプトにはブランドの撮影ルールも組み合わせます：

Reference: [user's reference photo — e.g., insect app's hand-holding-phone with butterfly]

Prompt: "In the EXACT composition and lighting style of the reference image — hand
holding a phone at the same angle and scale — but render the subject and scene
per [BRAND] photography rules: documentary 35mm, golden hour window light, real
apartment, butter-yellow ceramic mug visible, mid-30s mixed-race cast, 35mm film
grain. Vertical 9:16 portrait."

こうすることで、参考資料のコンテンツをコピーせずに、そのスタイルを取り入れられます。手とスマートフォンの構図は引き継ぎ、ライティング、キャスト、設定はブランドに合わせます。

対話モードでデザインを始める前に、抽出したルールを提示します。 ルールを短い箇条書き（「デバイスはキャンバスの75％、傾きは-8°、デバイスの上に黄色いピル型の見出し、肩越しのヒーロー画像、インク色のコールアウトに曲線矢印」など）にまとめ、参考資料を正しく読み取れているかユーザーに確認します。非対話型の高速モードでは、抽出したルールをその場に記録して続行します。その後、これらのルールを一貫して適用しながら、6画面すべてを作成します。キャンペーンの途中で逸脱しないでください。

続けて、以下を実際に確認します：

• brand.md — ブランド名、タグライン、カラーパレット（16進数コード付き）、ディスプレイフォントと本文フォント、語り口を表す形容詞、語り口の例、禁止語、写真／イラストの方向性、ムードを表す言葉を抽出します。ファイルが別の形式（PDF、プレーンテキストのメモなど）の場合は、内容を読み取り、対話モードでは不足情報について質問します。非対話型の高速モードでは、重要でない不足情報について妥当な仮定を記録します。ブランドをでっち上げてはいけません。
• 製品のスクリーンショット — それぞれを開き、アプリが実際に何をするのか、正直なイメージをつかみます。主要なUIパターン（フィード、チャット、キャンバス、リスト、マップなど）、主要な操作領域、そして「目を引く瞬間」の画面（生成された結果、美しい状態、独自の操作など）を確認します。
• 画像として読み込まずにスクリーンショットを確認するために analyze_media を使える場合は、簡単に確認するにはより速いため、使用します。

次に、見つけた内容を会話形式で3〜5行にまとめて伝えます：

ok — reading [brand name]: [tagline]. palette: [colors]. voice: [adjectives]. the app looks like
it does [X] — i see [specific UI cue 1] and [specific UI cue 2]. the standout screen is [screen
N] because [reason]. correct me where i'm wrong, otherwise i'll pitch the 6-screen arc.

対話モードでは、戦略を提案する前に確認を待ちます。こうすることで、読み違いを早い段階で修正できます。非対話型の高速モードでは、ブランドの読み取りは暫定的なものとして扱い、仮定をその場に記録して、戦略へと進みます。

ステップ 2 — 6 画面の戦略を提案する

デザインを始める前に、まずストーリーの流れをプレーンテキストで書き出します。各画面には次の要素が必要です。

• 役割（フック／価値／機能／証明／締めくくり）
• 見出し（ブランドのトーンに合わせて 5～8 語。「コピー」の項を参照）
• サブ見出し（任意）（短い 1 行）
• レイアウトの型（下記を参照。まだ描画せず、名前だけを記載）
• 使用する元のスクリーンショット（ファイル名）— または「なし、タイポグラフィを全面に配置」
• 証明要素（証明画面のみ）— 星評価、Editors' Choice バッジ、推薦文カード、レビュー数チップ、受賞バッジなど、目に見える証明要素を少なくとも 1 つ含めます。証明画面をテキストだけにしてはいけません。

次の形式で提示してください。

**Screen 1 — HOOK**
Headline: "Sleep like you mean it."
Sub: (none — let the headline carry)
Layout: full-bleed UI with bold typography overlay
Featured screenshot: home_screen.png

**Screen 2 — VALUE**
Headline: "One tap. Then quiet."
...

対話モードでは、生成や合成を行う前に、ストーリーの流れをユーザーに確認してもらいます。コピーの修正はここで行います。修正に最も手間がかからない段階だからです。対話なしの高速モードでは、確認を挟まず、設定済みまたは推定したストーリーの流れに基づいて生成します。

証明画面のルール： 証明画面には、主張だけでなく、目に見える証明要素が必要です。「何百万人にも愛されています…」のようなテキストだけのソーシャルプルーフを証明画面として公開してはいけません。App Store の掲載情報またはブランド仕様に実際の証明要素がある場合は、星評価、Editors' Choice バッジ、推薦文カード、レビュー数チップ、受賞バッジ、または出典付きの引用カードとして視覚的に表示します。実際の証明要素がない場合は、レビュー、受賞歴、評価、顧客数を捏造せず、製品のスクリーンショットで裏付けられた視覚的な差別化要素を証明の見せ場にします。

ステップ 3 — ブランドの世界観を表現する画像を生成する

華やかな背景画像やヒーロー画像が必要な画面では、generate_image を使って画像を生成します（上記の参照画像を使う手順で参照画像を渡す場合は generate_image_edit を使用します）。

App Store のスプラッシュ画像に適したデフォルト設定：

• provider: gpt-image-2
• quality: medium（完成版のスクリーンショットの場合）。low を使うのは、ユーザーが高速な反復を明示的に希望した場合のみです。
• aspect_ratio: 9:16（全面背景の場合。iPhone のキャンバスに適合します）
• デフォルトは 1K です。画面でより高解像度が実際に必要な場合（例：拡大表示する精細な背景）は、gpt-image-2 を 2K／4K に上げる（9:16 の背景はどちらにも対応）か、seedream に切り替えます。トレードオフを説明し、事前に確認してください。

ブランドの世界観を表現する画像のプロンプト構成：

1. 被写体＋構図（「風雨にさらされたオーク材の上に置かれた、陶器のマグカップ 1 つを広角でシネマティックに撮影…」）
2. 色名で指定するブランドパレット（「インクブラック #0E0E10、オート #F5F0E6、アクセントカラーのラスト #C84B2F のみに限定」）
3. 光＋ムード（「曇りの日の窓から差し込む柔らかな光、わずかなフィルム粒子、ドキュメンタリーの雰囲気」）
4. 含めない要素（「指定がない限り、テキスト、ロゴ、人物は含めない。ストックフォトのような光沢感も出さない」）
5. 9:16 背景の構図：「見出し用の余白を上部 3 分の 1 に確保した縦構図」

上部 3 分の 1 は見出し用に空けてください。 テキストを配置する場所を画像モデルに伝え、余白を確保します。

サーバー側のレンダリングでは、生成した画像の URL に HTTPS／CDN URL を使用してください。ユーザーからローカルの製品スクリーンショットや背景画像が提供された場合は、まず upload_asset でアップロードし、返された public_url を使用してください。html_to_png はローカルの file:// パスを読み取れません。工程間で長い CDN URL を繰り返し使う場合は、s://screen01 のような短いトークンを HTML／CSS 内で使い、完全な URL は short_link_map を通じて渡してください。空白を含む URL や https:// が欠けた不正なアセット URL は、レンダリング前に拒否されます。

Step 4 — 各画面を1290×2796で合成する

画面ごとにHTMLステージを1つ作成し、Pika MCPのhtml_to_pngでPNGにレンダリングします。以下についてはreferences/render-pipeline.mdを参照してください。

• html_to_pngの正確なリクエスト形式
• サーバー側のアセット／フォントのルール
• セーフゾーンのガイド
• よくある注意点（フォントの読み込み、Retinaでのテキストのシャープさ、曲線途中での切り抜き）

各HTMLステージは正確に1290×2796pxにしてください。@font-faceでは、fonts.gstatic.comのWOFF2フォントファイルへの直接URL、またはインラインのdata:font/...ソースを使用します。レンダラーのHTMLでは、GitHub rawのGoogle Fontsリンクを使用しないでください。text/htmlとして解決され、フォントのMIME許可リストにより失敗する可能性があります。ローカルのブランドキットのフォントファイルは、公開HTTPS URLで公開するか、インラインにしてください。upload_assetはフォントのMIMEタイプを受け付けません。コピーして使えるGoogle Fontsのスニペットについては、references/fonts.mdを参照してください。

CJKやその他の非ラテン文字を含むアプリ名、見出し、お客様の声、UIラベルを使う場合は、すべてのCSSのfont-familyスタックに、"Noto Sans SC", "Noto Sans TC", "Noto Sans JP", "Noto Sans KR", "Noto Sans Arabic", system-ui, sans-serifなど、幅広い文字体系をサポートするフォールバックを追加してください。Chromiumは、対応するラテン文字にはブランドフォントを使用し、サポート対象外の文字体系では文字ごとにフォールバックするため、豆腐のような四角い文字が表示されません。

暗い背景では、中間グレーを使い回さず、ダークモード用のサブヘッドトークンを設定してください。--subhead-on-dark: #B5B4B0、またはブランドパレットの同等の明るいニュートラルカラーを、不透明度100%で使用します。黒に近い背景に#787774系のグレーを使わないでください。また、明るい背景用のopacity: 0.7-0.75のルールでダークモード用トークンを薄くしないでください。#787774系のグレーは明るい背景専用です。見出しはクリーム色／白に切り替えられますが、サブヘッドも読みやすいダークモード用の色に切り替えてください。

各レンダリング後、PNGを採用する前に納品前のQAを実施してください。レンダリングした画像にanalyze_mediaを使用し、可能な場合は作成したHTML内の位置も確認します。テキストブロックのバウンディングボックスにより、見出し、アイブロウ、サブヘッド、CTA、製品UIなど、重要な要素がreferences/render-pipeline.mdに記載されているセーフコンテンツ領域の外に出ている画面は、却下して再レンダリングしてください。

Step 5 — コンタクトシートを作成して納品する

6枚すべてのPNGが問題なくレンダリングされたら、次の手順に進みます。

1. html_to_pngを使って_preview.pngのコンタクトシートを作成します。ニュートラルな背景に、役割ラベルを付けたサムネイル6枚を3×2のグリッドに約25%のサイズで配置します。
2. コンタクトシートのURLと、各スクリーンショットのfile_urlを提示します。ローカルコピーも保存した場合は、そのパスも別途記載してください。
3. 「修正したい点はありますか？」と尋ねます。よくある修正は、コピーの調整（低コスト）、レイアウトの入れ替え（中コスト）、新しい画像の追加（最も高コスト）です。

_preview.pngが作成され、納品に含まれるまでは、スクリーンショット一式が完成したと報告しないでください。コンタクトシートのレンダリングに失敗した場合は、シートのHTMLを修正するか、欠けているPNGを先に再レンダリングしてください。個別のPNGだけを納品して、キャンペーンが完了したと報告してはいけません。

フライト後の品質ゲート

完了を宣言する前に、キャンペーン全体のバリエーションを確認するため、_preview.png のコンタクトシートに対して analyze_media を呼び出し、証拠となるコピーがある画面、背景が暗い画面、または用意されたソーススクリーンショットを含む画面は、個別の PNG をフル解像度で確認してください。25% のコンタクトシートだけでは、フッターの透かしのにじみ、暗い背景でのサブヘッドのコントラスト、細かな証拠のアーティファクト、または構成済みのマーケティングソースにおける見出しの二重表示の問題を検証するには不十分です。

以下について、個別の PNG をフル解像度で確認してください。

• 証拠となる画面
• 背景に黒に近い色または暗い色を使っているすべての画面
• 出品ブランドのフッターテキストが含まれている可能性のある、取得済みまたはユーザー提供のソーススクリーンショットを埋め込んでいるすべての画面
• source_treatment=composed_passthrough を使用しているすべての画面、または composed_marketing に分類されたソースを使用しているすべての画面
• mac_shots を使用した、すべての Mac の横向きカード画面

コンタクトシートについては、構造化された判定を求めてください。

Return JSON only: {
  "verdict": "clean" | "degraded" | "catastrophic",
  "observations": string[],
  "quality_warning": string | null,
  "re_roll_suggestion": string | null
}
Check that the contact sheet shows every requested screenshot, App Store safe zones are respected, product UI is readable, headlines are legible at thumbnail scale, and no generated text is garbled.

対象となる個々のレンダリング済み PNG については、以下を尋ねてください。

Return JSON only: {
  "proof_artifact_visible": boolean | null,
  "dark_subhead_contrast_ok": boolean | null,
  "footer_watermark_bleed_visible": boolean,
  "composed_source_double_headline_visible": boolean | null,
  "mac_card_preserves_landscape_ui": boolean | null,
  "verdict": "clean" | "degraded" | "catastrophic",
  "observations": string[],
  "re_roll_suggestion": string | null
}
Check at readable resolution. The proof screen must include a visible proof artifact such as a star row, Editors' Choice badge, testimonial card, review-count chip, award badge, or sourced quote card. Dark-background subheads must use a light dark-mode token and remain readable. Source screenshots and Mac cards must not show footer watermark bleed or listing-brand footer clutter. For composed-marketing sources, verify there is no generated headline stacked above a baked headline and no extra device mockup wrapped around the source.

• verdict が clean の場合は、コンタクトシートと個別 PNG の URL を納品してください。
• verdict が degraded の場合は、ユーザーが公開前に確認できるよう、quality_warning とともに URL を納品してください。
• verdict が catastrophic の場合は、キャンペーンを完了扱いにせず、完了を宣言する代わりに判定結果と re_roll_suggestion を提示してください。
• 証拠となる画面に目視できる証拠アーティファクトがない場合、暗い背景でサブヘッドのコントラストが低い場合、ソーススクリーンショットのフッターに透かしのにじみが残っている場合、または composed_source_double_headline_visible が true の場合は、最低でも degraded として扱い、通常どおり納品する前に該当画面を再レンダリングしてください。構成済みのソースに、埋め込み済みの見出しと生成された見出しの両方がある状態で、キャンペーンを完了扱いにしないでください。

5 つのレイアウトの基本形

画面ごとに 1 つ使用してください。デバイスを重ねないでください。 1 画面につき、大胆なアイデアを 1 つに絞ってください。

CSS のスケルトンとビジュアル例の詳細は references/layout-archetypes.md を参照してください。クイックリファレンス：

1. フローティングデバイス — スプラッシュ背景に傾けたスマートフォンを配置します。汎用性の高い基本形です。価値や機能を伝える画面に最適です。
2. フルブリード UI — スマートフォンのキャンバスがフレーム全体を占め、画面上部または下部にタイポグラフィを重ねます。フックに最適です。
3. 左右並列 — 片側にデバイス、もう片側に生成したライフスタイル画像を配置します。感情に訴える機能に最適です。
4. パララックススタック — 手前にスマートフォンを置き、後ろにブランドの図形や画像を浮かべます。「驚きの瞬間」を演出する機能画面に最適です。
5. 引用カード — 大きな引用文と、小さく隅に配置したデバイスを組み合わせます。証拠となる画面に最適です。

コピー — 譲れない条件

App Store の見出しは、小さな枠内で評価されます。次の条件を満たす必要があります。

• 5〜8 語にすること。 それより長い見出しは、検索結果に表示される 6.1 インチのスマートフォンでは目に留まりません。
• ブランドの語り口を正確に反映すること。 brand.md で語り口が「淡々としていて、無表情で、感嘆符を使わない」と定められているなら、見出しの末尾に ! を付けてはいけません。「温かみがあり、少しからかうような」語り口なら、見出しにリズムを持たせてください。
• 説明ではなく、主張を伝えること。 「本気で眠る」＞「睡眠を記録する」。「1 日に静かな 1 時間のために」＞「生産性アプリ」。
• 最初の 2 画面だけでもサムネイルとして成立させること。 文字を大きくし、フックを明確にしてください。App Store の検索結果では最初の 2〜3 枚が展開表示され、残りはユーザーがタップした場合にのみ表示されます。

使用禁止（App Store 版の「愛を込めて作りました」に相当する表現）：

• 「整理整頓を続けましょう。」
• 「あなたの毎日のパートナー。」
• 「オールインワンの［カテゴリ］。」
• 「［動詞］をサポートするために設計されました。」
• 「記録する。計画する。達成する。」
• 「シームレスに」「簡単に」「パワフル」「スマート」「インテリジェント」を含む表現。

500 個の他のアプリにも違和感なく使えてしまう見出しなら、書き直してください。

ビジュアルの基準

• 主役はデバイス、文字はキャプションです。 1290×2796 のキャンバスでは、デバイスの幅を 1050～1150px（キャンバスの約 81～89%）にします。それより小さいと迫力に欠けます。見出しは画面の内容を引き立てるものであり、競い合うものではありません。
• タイポグラフィの階層を明確にします。 画面ごとに最も目立つ要素は 1 つにします。通常はデバイスです。見出しは Funnel-Display クラスで 100～140px、小見出しは 36～44px とし、太さとサイズに明確な差をつけます。（150px を超えると、見出しがデバイスと視線を奪い合い始めます。）
• SVG のストロークで iPhone フレームを描くのは避けてください。スクリーンショットの角と合いません。 ストロークベースの SVG ベゼルはパスの内側と外側にまたがり、角丸や Dynamic Island の比率も実際の iPhone と完全には一致しません。Figma／シミュレーターから透過スクリーンショットを書き出すか、透明な切り抜きのある実物に近い iPhone モックアップ PNG を使ってください。長方形のソーススクリーンショットしかない場合は、一貫した CSS の border-radius と overflow:hidden を使ったラッパーで囲み、角を目視で QA してください。従来のローカル clean_phone_uniform() PIL レシピは、今や標準の依存関係ではなく、文書化された MCP のギャップです。
• どちらか一方を選んでください。裁ち落としか、全体表示か。下部の曲線を途中で切らないでください。 デフォルトは全体表示です（デバイスの上端を y=580、幅を 1000 に設定し、角丸の下部がキャンバス内に完全に収まり、下に約 48px の余白ができます）。裁ち落としの場合（デバイスの上端を 819 以上に設定）は、角丸の下部が y=2796 を完全に超えるため、インパクトを狙う導入画面に便利です。その中間では、キャンバスが角丸の弧の途中を横切り、曲線が半端に切れて見えます。このルールで防ぐのは、まさにこの失敗です。
• Apple のセーフゾーンを守ってください。 厳格なセーフゾーンのルールとして、重要なテキストと製品 UI は y=180..2616 の範囲内に配置します。上下の 100px の帯には重要なコンテンツを置かず、さらに 80px の余白を確保することで、App Store の表示要素、検索結果のトリミング、テキストのアセンダーが端に詰まるのを防ぎます。装飾は問題ありませんが、重要な訴求内容や、読み取り可能であるべきアプリ UI は配置しないでください。
• 画面ごとに大胆なデバイスを 1 つだけ置いてください。 大きな文字、生成画像、引用のいずれか 1 つにします。派手さと雑然さは別物です。
• 色はブランドパレットのみを使ってください。 スクリーンショット用に新しい色を作り出さないでください。パレットの制約が厳しすぎると感じる場合、それはあなたではなくブランド側が解決すべき問題です。

画面の入手元

元の画面はどこから取得しても構いません。Pika MCP 経由で取得した App Store の掲載情報、Figma のフレーム、Sketch の書き出し、シミュレーターのスクリーンショット、ローカルファイルなどが使えます。ソースが App Store の URL／アプリ ID／アプリ名の場合は、上記の App Store 掲載情報の手順を使ってください。ソースが Figma で、Figma MCP にアクセスできる場合：

• get_screenshot(fileKey, nodeId) はノードのレンダリング済み PNG を返します。Figma デスクトップアプリでユーザーに選択してもらう必要はありません。
• スマートフォンを横並びにするレイアウトでは、個別のスマートフォン画像を書き出すよう依頼してください。横並びの画像しかない場合は、デザインソースから手動で切り抜くか、利用可能になったら将来のサーバー側切り抜き／クリーンアップツールを使ってください。このスキルの標準の依存関係として、ローカル PIL による切り抜きを追加しないでください。
• 自然なレンダリングサイズは通常、論理ピクセルのサイズです（例：iPhone 15 Pro 1 台につき 393×852）。これを App Store のキャンバス上でデフォルトのデバイス幅 1000px に拡大しても、ピクセル単位の精度が重要でないコンテンツであれば問題ありません。より高い忠実度が必要な場合は、より高解像度の書き出しがあるか確認してください。

品質基準

納品前に、目を細めて確認してください。

1. コンタクトシートを目を細めて見る。 6つの画面をひと目で見分けられますか？（見出し、レイアウト、視覚的な重心がそれぞれ異なっていますか？）同じ画面のバリエーションが6つ並んでいるように見える場合は、再設計してください。
2. 最初の2画面のサムネイルテスト。 画面1と2を25%のサイズに縮小します。見出しは読めますか？フックは明確ですか？身を乗り出さないと読めないなら、文字が小さすぎます。
3. ブランドテスト。 各画面のデバイスを隠します。周囲のデザインにもブランドらしさが残っていますか？（色、文字、雰囲気、見出しの語り口）そうでなければ、スクリーンショットがありきたりです。
4. ありきたりさの回避テスト（「ブランドを築く」と同じ）：この画面は、このカテゴリのほかのどのアプリにも当てはまりそうですか？そうなら、コピーを書き直し、視覚的な優先順位を組み直してください。
5. セーフゾーンの監査。 レンダリングしたPNGをすべて確認し、重要なテキストや製品UIがセーフコンテンツ領域から外れている画面は却下して、再レンダリングしてください。

重要なフレーズ

以下の要点は、生成するキャンペーンの読みやすさとブランドらしさを保つためのものです。

フレーズ	場所	重要な理由
vertical composition with negative space in upper third for headline	ブランドの世界観を表現する画像のプロンプト	情報量の多い画像にテキストを無理に重ねず、実際のApp Store用見出しを配置できるスペースを確保します。
The device is the hero — type is the caption	ビジュアル基準	コピーが製品UIを圧倒するポスターのような画面を防ぎます。
Apple safe zones	ビジュアル基準／レンダリングQA	ステータスバーやApp Storeのオーバーレイ領域に、重要な訴求がかからないようにします。
no text, no logos	生成する背景のプロンプト	使えない生成テキストを避け、実際のコピーはHTMLで追加します。
Pick one: bleed OR full-frame	デバイスのレイアウトルール	レンダリングの不具合に見える、角丸が途中で切れたようなトリミングを防ぎます。

エンジンの選択：HTMLを優先してレンダリングし、ブランドの世界観を表す画像にのみgpt-image-2を使用

最終的なスクリーンショットは、html_to_pngでレンダリングする、再現性の高いHTML/CSS合成画像にしてください。App Store用のコピー、デバイスマスク、セーフゾーン、ブランドの文字表現を正確に制御する必要があるためです。gpt-image-2は、生成によってビジュアルの豊かさが増すスプラッシュ画像、背景、ブランドの世界観を表す画像にのみ使用し、実際の製品UIにはスクリーンショットを使ってください。特定の生成背景で1Kを超える解像度が本当に必要な場合に限り、gpt-image-2を2K/4Kティアに引き上げるか、seedreamに切り替えてください。

実行時間の目安

ユーザーによる確認の量にもよりますが、通常の実行時間は10～25分です。

ステップ	所要時間	備考
要件の確認＋スタイルの選択	1～5分	参考資料が必要な場合は、ユーザーのペースに合わせます
ブランド／スクリーンショットの確認	2～5分	ビジュアルの確認と機能の対応付けを含みます
戦略案の提示	2～5分	コピーを手軽に調整できる最適なタイミングです
画像生成	2～8分	背景や、参考資料に基づくメインビジュアルにのみ使用します
HTML合成＋レンダリング	5～10分	1290x2796のPNG 6枚とコンタクトシートを作成します
QAの修正	変動	コピーの調整は手軽ですが、新しい画像の生成には時間がかかります

失敗モード

症状	原因	対処法
画面が同じレイアウトの6種類のバリエーションのように見える	コンテンツのコントラストが不十分なまま、デフォルトの骨組みを繰り返していた	レイアウトの型を割り当て直し、焦点の重み、色、スクリーンショットの選択を入れ替えます
コンタクトシートで見出しが読めない	App Store のサムネイルに使うには文字が小さすぎる	見出しを大きくし、文言を5～8語に短縮して、再レンダリングします
生成された背景に文字や偽の UI が含まれている	プロンプトでブランドや製品の詳細を説明しすぎていた	テキストやロゴを含めないための制約を設けて再生成し、実際の UI はスクリーンショット用に確保します
App Store の掲載ページに使えるスクリーンショットが3枚未満しかない	App Store の掲載内容が乏しい。コンパニオンアプリや掲載開始直後によく見られます	Webサイトのキャプチャ手順を使う、実際のスクリーンショットを依頼する、または作業を中止します。架空のローンチデモ案に限り、demo_mode: true、demo_brief、デモ専用の開示とともに Fictional app demo mode を使用します
架空のアプリに実際の製品スクリーンショットがない	ローンチデモ案には代表的な UI が必要ですが、制作ルールでは幻覚による UI の生成を禁止しています	demo_mode: true、具体的な demo_brief、代表的な UI モック、デモ専用の開示を用意した場合に限り、Fictional app demo mode を使用します
重要なテキストが上下の端に近すぎる	セーフゾーンの QA を省略したか、テキストブロックのバウンディングボックスではなく、レンダリング後の見た目だけを確認していた	テキストブロックのバウンディングボックスが厳格なセーフゾーンのマージン内に収まるようにして、却下して再レンダリングします
デバイスの角が均一に見えない	元のスクリーンショットの角丸部分にすでに背景が含まれているか、CSS の角丸が元画像と一致していません	透過または高解像度の元データの書き出しを依頼する、実際のモックアップの切り抜きを使う、または統一した CSS マスクを適用して目視で QA します。サーバー側で角を均一に整える機能は、依然としてツールの不足点です。
スクリーンショットを隠すとブランドがありきたりに感じられる	周囲のデザインが brand.md のトーン、カラーパレット、画像のルールを反映していない	再レンダリングの前に、ブランド仕様に基づいて画面の外枠を作り直します
レンダリングがぼやけている、または拡大縮小されている	ステージの寸法またはラスター化のオプションが正しくありません	ステージサイズが1290x2796で、html_to_png の viewport_px:1290x2796、device_scale:1 が指定されていることを確認します

ユーザーの要望に異議を唱えるべき場合

• 参考資料を提示せずに「もっと派手に」してほしいと言われた場合は、異議を唱えます。気に入った App Store ページのスクリーンショット、figma ファイル、またはムードボードを依頼します。参考資料がなければ、デフォルトのデザインにブランドカラーを加えたものを納品することになり、「刺激的」なデザインを推測するよりもよいと説明します。（このルールは実際のキャンペーン制作から得たもので、自動的に派手にした場合は毎回、素人っぽい仕上がりになりました。）
• 10画面のキャンペーンを希望された場合は、異議を唱えます。最適なのは5～6画面です。それ以上は疲れを招きます。
• brand.md のブランドトーンが「モダン、親しみやすい、直感的」のようにありきたりな場合は、その点を指摘します。画面の制作はできますが、見出しの個性はトーンの仕様次第だと伝えます。まずトーンを磨くことを提案します（brand.md の Voice & Tone セクションに記載されています）。
• 実際の製品スクリーンショットがなく、架空のアプリのデモモードも明示的に希望していない場合は、UI を作り上げてはいけません。スクリーンショット、Webサイトやオンボーディングのキャプチャ対象、または具体的な demo_brief とともに明示された demo_mode: true を依頼します。
• ブランドがまったくない場合は、感覚だけで作業を進めてはいけません。まず build-a-brand を案内するか、最低限、名前、パレットの16進カラーコード、ディスプレイフォント、本文フォント、1行のトーン説明を書いてもらいます。

参考資料

• references/default-layout.md — ユーザーから参考資料が提供されない場合に、このスキルが生成するビジュアルシステムです。 どの実行でも、まずこれを読んでください。見出しを上部に配置し、デバイスを主役にして、フレーム全体を使う構成、色のローテーション、目を細めて確認するチェックリストを定めています。このスキルが得意とする成果物です。
• references/mac-app-layout.md — Mac 専用またはハイブリッドの掲載情報に含まれる、横向き Mac スクリーンショット向けの縦長 App Store レイアウトです。fetch_appstore_screens が 1290×806 などの横向きスクリーンショットを返す場合に使用してください。
• references/layout-archetypes.md — 実際の App Store キャンペーンで見られるレイアウトパターンの用語集です。ユーザーから提供された参考資料を分析する場合にのみ使用してください。自由に選べるメニューではありません。
• references/render-pipeline.md — html_to_png のレンダリングリクエスト、サーバー側のアセット／フォント規則、セーフゾーンのオーバーレイ、フォント読み込みチェックリスト、納品前チェックリストです。