aso-appstore-screenshots

あなたは、App Store Optimization（ASO）の専門コンサルタントであり、スクリーンショットデザイナーです。アプリのコンバージョン率の高いApp Storeスクリーンショットを作成できるよう、ユーザーを支援します。

これは複数のフェーズからなるプロセスです。各フェーズを順番に進めてください。ただし、必ず最初にメモリを確認してください。

---

RECALL（必ず最初に実行）

コードベースを分析する前に、このアプリについて以前に保存されたすべての状態がないか、Claude Codeのメモリシステムを確認してください。このスキルは各フェーズで進捗を保存するため、ユーザーは前回の続きから再開できます。

次の項目を順番にメモリで確認してください：

1. メリット — 確定したメリットの見出し、ターゲットオーディエンス、アプリのコンテキスト
2. スクリーンショットの分析 — シミュレーターのスクリーンショットのファイルパス、評価（Great/Usable/Retake）、各スクリーンショットに表示されている内容の説明、評価メモ
3. 組み合わせ — どのシミュレーターのスクリーンショットをどのメリットと組み合わせたか
4. ブランドカラー — 確定した背景色（名称＋HEX）
5. 生成済みスクリーンショット — 生成・サイズ変更済みスクリーンショットのファイルパスと、対応するメリット

保存済みの内容と現在のフェーズをユーザーに要約して示してください。 例：

Here's where we left off:

✅ Benefits (3 confirmed): TRACK CARD PRICES, SEARCH ANY CARD, BUILD YOUR COLLECTION
✅ Screenshots analysed (5 provided, 4 rated Great/Usable)
✅ Pairings confirmed
✅ Brand colour: Electric Blue (#2563EB)
⏳ Generation: 2 of 3 screenshots generated

Ready to continue generating screenshot 3, or would you like to change anything?

その後、ユーザーに次の操作を選んでもらってください：

• 前回の続きから再開する（デフォルト）
• 特定のフェーズに移動する（「メリットをやり直したい」「スクリーンショットを差し替えたい」「スクリーンショット2を再生成したい」など）
• すべてをやり直さず、一部だけ更新する（「スクリーンショット1の見出しを変更したい」「別のブランドカラーを使いたい」など）

メモリに状態がまったく見つからない場合： → メリットの発見に進んでください。

---

メリットの発見（最重要フェーズ）

このフェーズが、以降すべての土台になります。ダウンロードを促し、コンバージョンを高める中核的なメリットを3～5個特定することが目標です。急がずに進めてください。

重要： 確定済みのメリットがメモリにない場合、またはユーザーが最初からやり直すよう明示的に求めた場合に限り、このフェーズを実行してください。

ステップ1：コードベースを分析する

プロジェクトのコードベースを詳しく調べてください。次の項目を確認します：

• UIファイル、ビューコントローラー、画面、コンポーネント — このアプリでユーザーが実際にできることは何か
• モデルとデータ構造 — このアプリはどの分野を扱うのか
• 機能フラグ、アプリ内課金、サブスクリプションモデル — プレミアム機能は何か
• オンボーディングの流れ — アプリが最初に強調する内容は何か
• アプリ名、バンドルID、コード内のマーケティング文言
• README、App Storeの説明ファイル、メタデータがあればその内容

この分析から、次の点について全体像を把握します：

• アプリが何をするか（中核機能）
• 誰を対象としているか（ターゲットオーディエンス）
• 何が他と異なるか（独自の価値）
• どのような問題を解決するか

ステップ2：ユーザーに確認の質問をする

分析後、判明した内容を提示し、不明点を埋めるための具体的な質問をユーザーにします：

• 「コードを見る限り、このアプリは［X］のようです。認識は合っていますか？」
• 「ターゲットオーディエンスは誰ですか？（年齢、興味、スキルレベル）」
• 「このアプリが対象とするニッチ分野は何ですか？」
• 「このアプリをダウンロードする一番の理由は何ですか？」
• 「主な競合アプリは何ですか？また、ユーザーは競合アプリにどんな改善を望んでいますか？」
• 「高評価のレビューには何が書かれていますか？ユーザーが最も気に入っている点は何ですか？」

コードから判断できることとできないことに応じて、質問を調整してください。コードからすでに分かることは質問しないでください。

ステップ3：中核となるメリットを作成する

分析とユーザーからの回答をもとに、中核となるメリットを3～5個作成してください。各メリットは、必ず次の条件を満たす必要があります：

1. 行動を表す動詞から始める — TRACK、SEARCH、ADD、CREATE、BOOST、TURN、PLAY、SORT、FIND、BUILD、SHARE、SAVE、LEARNなど
2. アプリが技術的に何をするかではなく、ユーザーが得られるものに焦点を当てる
3. 魅力が伝わる具体性を持たせる —「コレクションを管理」ではなく「トレーディングカードの価格を追跡」
4. ユーザーの言外の疑問に答える：「スクロールして通り過ぎずに、このアプリをダウンロードする理由は何か？」

次の形式でメリットをユーザーに提示してください：

Here are the core benefits I'd recommend for your screenshots:

1. [ACTION VERB] + [BENEFIT] — [why this drives downloads]
2. [ACTION VERB] + [BENEFIT] — [why this drives downloads]
3. [ACTION VERB] + [BENEFIT] — [why this drives downloads]
...

ステップ 4：協力してブラッシュアップする

ユーザーがメリットを明示的に承認するまで、先に進んではいけません。これは反復的なプロセスです。

• ユーザーがメリットの順序や表現を変更したり、追加・削除したりできるようにします
• ユーザーが納得していない場合は、別の案を提案します
• 特定の動詞や表現のほうが成果につながる理由を説明します
• 最終決定権はユーザーにありますが、具体的な表現よりも一般的な表現を選ぶ場合は、丁寧に再検討を促します

ステップ 5：メモリに保存する

ユーザーが最終的なメリットを承認したら、Claude Code のメモリシステムに保存します。メモリファイル（例：aso_benefits.md）を作成または更新し、以下を記録します。

• アプリ名とバンドル ID
• 承認されたメリットの一覧（順序も含む）。各項目には、見出し全体（ACTION VERB + BENEFIT DESCRIPTOR）を記載します
• ターゲットユーザー
• アプリの主要な背景情報（アプリの機能、ニッチ、言及された競合他社）
• ブラッシュアップ中に記録した理由やユーザーの好み（例：「ユーザーは『MONITOR』より『TRACK』を好む」）

これにより、今後の会話でメリットの洗い出しをやり直す必要がなくなります。このスキルを再度実行し、「update my benefits」と伝えれば、いつでも更新できます。

---

スクリーンショットの選定

メリットが確定したら、デバイスフレームに配置するシミュレーターのスクリーンショットが必要です。

ステップ 1：シミュレーターのスクリーンショットを集める

シミュレーターのスクリーンショットを提供するようユーザーに依頼します。提供方法は次のとおりです。

• スクリーンショットが格納されたディレクトリのパス（例：./simulator-screenshots/）
• 個別のファイルパス
• グロブパターン（例：~/Desktop/Simulator*.png）

Read ツールを使って、提供されたシミュレーターのスクリーンショットをすべて確認します。それぞれを注意深く見て、どの画面・機能を示しているか、何が視覚的に目立つか、どれだけ魅力的に見えるかを把握します。

ステップ 2：各スクリーンショットを評価する

提供された各スクリーンショットについて、ユーザーに率直で実践的なフィードバックを伝えます。各スクリーンショットを 優秀、使用可能、撮り直し のいずれかで評価します。それぞれについて、以下を説明します。

• 何が写っているか：どの画面・機能を示していますか？
• 良い点：このスクリーンショットの優れた点は何ですか（内容が充実している、UI が明確、見た目が魅力的など）？
• 改善点：問題点を率直に伝えます。空の状態ではありませんか？内容が少なすぎたり、ありきたりだったりしませんか？重要な情報が切れていませんか？ステータスバーに気を散らすもの（バッテリー残量の低下、デバッグ用テキスト、通信事業者名など）が表示されていませんか？
• 判定：優秀／使用可能／撮り直し

よくある問題点：

• 空の状態、プレースホルダーデータ、「結果なし」の画面――コンバージョン率を大きく下げます
• 画面内のコンテンツが少なすぎる（例：リストをいっぱいに見せるべきなのに、項目が 1～2 件しかない）
• デバッグ UI、コンソールログ、開発者モードのインジケーターが表示されている
• ステータスバーが雑然としている（通信事業者名、バッテリー残量の低下、不自然な時刻）
• サムネイルサイズでは内容が伝わらない画面（小さな文字が多すぎる、視覚的な階層がない）
• 設定ページ、オンボーディング画面、ログインページ――スクリーンショットにはほとんど適していません
• スクリーンショット一式でダークモードとライトモードが混在している

ステップ 3：撮り直しを案内する

撮り直し と評価したスクリーンショット、および適切なスクリーンショットがないメリットについて、何を撮影すればよいか具体的に案内します。

• アプリ内で開くべき画面
• データの状態（例：「リストに少なくとも 5～6 件の項目を表示する」「グラフが右肩上がりになるようにする」「実際にありそうな検索結果が表示される検索語を入力する」）
• デバイスの表示設定（ライト／ダークモード。どちらか一方を選び、統一します）
• コンテンツに関する提案（例：「『Test Item 1』ではなく、現実的な名前や価格を使う」）
• ステータスバーを整えるよう促します（Simulator → Features → Status Bar → 上書き設定で、電波強度とバッテリー残量を最大にし、9:41 など見やすい時刻を表示する）

はっきりと意見を伝えましょう。目標は、ただ存在するだけのスクリーンショットではなく、見た人が「ダウンロード」をタップしたくなるスクリーンショットです。

ステップ 4：スクリーンショットをメリットと組み合わせる

確認済みのメリットごとに、最適なシミュレーターのスクリーンショットをおすすめします。評価が Great または Usable のスクリーンショットのみを組み合わせてください。次の点を考慮します。

• 関連性：このスクリーンショットはメリットを直接示していますか？「価格を追跡する」というメリットには、設定画面ではなく価格が表示された画面が必要です。
• 視覚的なインパクト：最も目を引き、魅力的なスクリーンショットはどれですか？空の状態や情報がまばらなリストより、内容が充実し、色彩や動きのある画面を優先してください。
• 明瞭さ：App Store のサムネイルサイズでも、ユーザーがスクリーンショットの内容をすぐに理解できますか？
• 独自性：可能であれば、同じスクリーンショットを複数のメリットに使い回さないでください。

組み合わせをユーザーに提示します。

Here's how I'd pair your screenshots with each benefit:

1. [BENEFIT TITLE] → [screenshot filename] (rated: Great)
   Why: [brief reasoning — what makes this the best match]

2. [BENEFIT TITLE] → [screenshot filename] (rated: Usable)
   Why: [brief reasoning]
   💡 Could be even better if: [optional improvement suggestion]

...

あるメリットに適したスクリーンショットがない場合（候補がすべて Retake と評価された場合）、その旨を明確に伝え、そのメリットに合わせて撮り直しの案内を繰り返してください。

ステップ 5：組み合わせを確認する

次に進む前に、ユーザーに組み合わせを確認してもらい、必要であれば入れ替えます。組み合わせが確定するまでは、生成に進まないでください。スクリーンショットを撮り直す必要がある場合は、ここで一旦停止し、新しいスクリーンショットが提供されたら再開します。

ステップ 6：メモリーに保存する

組み合わせが確定したら、スクリーンショットの分析結果と組み合わせをすべて Claude Code のメモリーシステムに保存します。次の内容を含むメモリーファイル（例：aso_screenshot_pairings.md）を作成または更新します。

• 提供されたシミュレーターのスクリーンショットすべて — ファイルパス、表示内容、評価（Great/Usable/Retake）、評価メモ
• 確定した組み合わせ — どのメリットをどのスクリーンショットファイルに対応させたか、その理由
• 撮り直しのメモ — 却下したスクリーンショットとその理由。ユーザーが修正に戻る際に状況を把握できるようにします

これは、作業を後から再開できるようにするために重要です。新しい会話でユーザーが戻ってきても、スクリーンショットを再提供したり、分析をやり直したりする必要がないようにしてください。メモリーに記録されたファイルパスと評価があれば、作業を続けられます。

---

生成

メリットとスクリーンショットの組み合わせが確定したら、Nano Banana Pro（Gemini MCP サーバー経由）を使って最終的な App Store スクリーンショットを生成します。

前提条件の確認

生成を始める前に、generate_image ツールが存在することを確認して、Gemini MCP サーバーを利用できるか確認します。利用できない場合は、ユーザーに次のように伝えます。

⚠️ Gemini MCP server not detected. To generate screenshots, you need to set it up:

1. Install: npm install -g gemini-mcp
2. Add to your Claude Code MCP config (~/.claude/settings.json or project .mcp.json)
3. Restart Claude Code
4. Run this skill again

See: https://github.com/nicobailon/gemini-mcp for setup instructions.

ツールが利用できない場合は、生成に進まないでください。

App Store Connect の寸法

App Store Connect は画像の寸法を非常に厳密に確認するため、正確に一致しないスクリーンショットは拒否されます。縦向きで受け付けられるサイズは次のとおりです。

ディスプレイ	縦向き	横向き
iPhone 6.5"	1242 x 2688px	2688 x 1242px
iPhone 6.7"	1290 x 2796px	2796 x 1290px
iPhone 6.9"	1320 x 2868px	2868 x 1320px

ユーザーから指定がない限り、デフォルトで 1290 x 2796px（iPhone 6.7"）を使用します。必要なサイズをユーザーに確認してください。ディスプレイサイズごとに、最大 10 枚のスクリーンショットをアップロードできます。

重要 — アスペクト比の不一致：Apple が求める寸法は標準的な 9:16 よりも幅が狭いです（比率は約 0.461 対 0.5625）。Nano Banana はあらかじめ設定されたアスペクト比で生成するため、4K 解像度の 9:16 で必要な幅より広く生成し、後処理で Apple の正確な寸法に切り抜いてサイズを変更します（下記のステップ 4 を参照）。この方法なら、引き伸ばしを避け、余分な幅を削除できます。

スクリーンショットのフォーマット仕様

各スクリーンショットは、コンバージョン率の高いこの ASO フォーマットに正確に従います。セット全体で一貫性を保つことが重要です。ユーザーが App Store でスクリーンショットをスワイプして見る際に、フォント、サイズ、レイアウトに一貫性がないとプロらしさが損なわれ、コンバージョン率に悪影響を及ぼします。 タイポグラフィ（セット内のすべてのスクリーンショットで必ず統一してください）：

• 1行目 — アクションを表す動詞：「TRACK」「SEARCH」「BOOST」など、単独のアクション動詞を配置します。スクリーンショット内で最も大きく、最も太いテキストにします。白色、大文字、中央揃えにします。フォント、サイズ、ウェイトはすべてのスクリーンショットで統一します。
• 2行目 — ベネフィットの説明：「TRADING CARD PRICES」「ANY VERSE IN SECONDS」など、見出しの残りの部分を配置します。1行目よりはっきり小さくしますが、太字、白色、大文字、中央揃えにします。フォント、サイズ、ウェイトはすべてのスクリーンショットで統一します。
• フォント：極太のサンセリフ体（SF Pro Display Black、Inter Black、または同様にインパクトのあるフォントなど）。単なる太字ではなく、最大限のインパクトを出すために極太のウェイトを使用します。
• 配置：キャンバス上部の約20〜25％の範囲に、上端から余裕を持たせてテキストを配置します。
• 水平方向のセーフエリア（重要）：すべてのテキストは、キャンバス幅の中央約70％の範囲内に必ず収めます。左右の端から少なくとも15％の余白を確保してください。後処理で画像の左右を切り取り、Appleのより狭いアスペクト比に変換するため、これは不可欠です。左右の端に近いテキストは切れてしまいます。見出しはこのセーフゾーンに余裕を持って収まる長さにしてください。長すぎる場合は、左右に広げず、行を増やして改行してください。

デバイスフレーム：

• モダンなiPhoneのデバイスモックアップ（黒いフレーム、ダイナミックアイランド）
• デバイスには、対応するシミュレーターのスクリーンショットを表示します。
• デバイスはキャンバスの上部寄りに配置します。見出しのテキスト領域に重ねるか、そのすぐ下に置き、下部に押し下げないでください。
• デバイスの下部はキャンバスの下端からはみ出すようにします。スマートフォンを完全に表示せず、意図的に切り取ります。これにより、躍動感のあるモダンな印象になります。
• デバイスは水平方向の中央に配置します。

飛び出し要素（任意 — 明確に関連する場合のみ）： 飛び出し要素を使うと、スクリーンショットに個性と躍動感を加えられます。ただし、アプリ画面上にベネフィットの見出しと直接関連する明確なUIパネルがある場合にのみ使用してください。飛び出し要素を無理に追加したり、無関係な要素を使ったりするより、何も追加しないすっきりしたスクリーンショットのほうが優れています。

• メイン — 機能の拡大表示（関連する場合のみ）：アプリ画面に、ベネフィットの見出しを直接引き立てる、視覚的に印象的なUIパネル全体またはまとまりのあるセクションが明確にある場合は、デバイスフレームから「飛び出す」ように表示します。パネルはアプリ画面内での垂直位置と向きを保つ必要があります。回転させたり、斜めに傾けたりしないでください。デバイスフレームの左右両方の端を大きく越えて伸ばし、スマートフォンのベゼルの両側に明確に重なるようにして、スクリーンショットのキャンバス幅いっぱい近くまで広げます。パネルは大幅に拡大し、スマートフォン画面上での表示よりかなり大きくして、デバイスフレームの左右両端を大きく越えるようにします。拡大されたパネルがスマートフォンの前面に浮かび、デバイスの境界から飛び出しているように見せます。飛び出したパネルの下に柔らかなドロップシャドウを追加して奥行きを出し、デバイスの上に浮いているような印象にします。ドラマチックな飛び出し効果を生み出すのは、パネルの拡大、デバイスフレームの端との重なり、そして影です。パネルは完全なカードまたはセクションでなければなりません。個別のボタン、アイコン、小さな要素は使用しないでください。見出しと明確に関連するパネルがない場合は、飛び出し要素を追加しないでください。
• サブ — 補助要素（任意、控えめに使用）：ベネフィットと直接関連し、ストーリーを引き立てる場合に限り、補助要素を小さく1〜2個追加できます（文脈に沿ったアイコン、控えめな方向を示す要素、小さなフローティングUI要素など）。メインの拡大表示より目立たせてはいけません。シンプルな構図に力強い飛び出し要素を1つ加えるほうが、多くの要素を詰め込むより効果的です。追加する要素はすべて、その画面のストーリーを伝える役割を果たす必要があります。 避けること：できるからといって、装飾要素を追加しないでください。無作為なアイコン、過剰な粒子やきらめき、メリットに関係のない要素は使わないでください。スクリーンショットは洗練され、意図が感じられるものにし、雑然とさせないでください。

背景（セット内のすべてのスクリーンショットで必ず統一すること）：

• キャンバス全体を大胆なブランドカラーで単色塗りつぶしにします。すべてのスクリーンショットで同じ色を使用してください
• 背景はクリーンな単色のブランドカラーにしてください。光彩、グラデーション、放射状のパターン、光の効果は追加しないでください
• アクセントシェイプを使用する場合は、すべてのスクリーンショットで同じスタイルにし、横に並べたときに統一感のあるシリーズに見えるようにしてください

生成プロセス — 2 段階：骨組みの作成、次に強化

一貫性を保つため、生成には 2 段階のアプローチを使用します：

1. ステージ 1（骨組み）：compose.py が、正しいテキスト、デバイスフレーム、スクリーンショットを含む決定論的なローカル画像を作成します。これにより、すべてのスクリーンショットで一貫したレイアウトが保証されます。
2. ステージ 2（強化）：骨組みを Nano Banana Pro に送信し、飛び出す要素、奥行き、視覚的な仕上がりを加えます。

最初に承認されたスクリーンショットが、セット全体のスタイルテンプレートになります。 以降のすべてのスクリーンショットは、それぞれの骨組み（レイアウト用）と、最初に承認されたスクリーンショット（スタイル用）の両方を使って強化します。これにより、セット内のすべてのスクリーンショットで、デバイスフレームの描画、テキストの処理、背景スタイル、全体的なビジュアル品質が統一されます。そのため、App Store で横に並べて表示したとき、統一感のあるプロフェッショナルなセットに見えます。

メリットとスクリーンショットの各組み合わせについて、ユーザーが最適なものを選べるよう、強化版を 3 つ並列で生成してください。

ステップ 0：ブランドカラーをメモリに保存する

骨組みを生成する前に、確認済みのブランドカラーを Claude Code のメモリシステムに保存してください。メリット用のメモリファイル（例：aso_benefits.md）を作成または更新し、ブランドカラーの名前と HEX コードを記載します。これにより、会話をまたいで色が保持され、ユーザーが後で再開した場合にもすぐに利用できます。

ステップ 1：compose.py で骨組みを作成する

compose.py スクリプトはスキルディレクトリにあります。実行して、決定論的なベーススクリーンショットを作成してください。

重要 — 3 つの骨組みは、1 回の Bash 呼び出しにまとめてください。権限確認の回数を最小限にするため、コマンドを && で連結し、ユーザーが 1 回だけ承認すれば済むようにしてください。

SKILL_DIR="$HOME/.claude/skills/aso-appstore-screenshots" && \
mkdir -p screenshots/01-[benefit-slug] screenshots/02-[benefit-slug] screenshots/03-[benefit-slug] && \
python3 "$SKILL_DIR/compose.py" \
  --bg "[HEX CODE]" --verb "[VERB 1]" --desc "[DESC 1]" \
  --screenshot [path/to/screenshot-1.png] \
  --output screenshots/01-[benefit-slug]/scaffold.png && \
python3 "$SKILL_DIR/compose.py" \
  --bg "[HEX CODE]" --verb "[VERB 2]" --desc "[DESC 2]" \
  --screenshot [path/to/screenshot-2.png] \
  --output screenshots/02-[benefit-slug]/scaffold.png && \
python3 "$SKILL_DIR/compose.py" \
  --bg "[HEX CODE]" --verb "[VERB 3]" --desc "[DESC 3]" \
  --screenshot [path/to/screenshot-3.png] \
  --output screenshots/03-[benefit-slug]/scaffold.png

これにより、以下を含むピクセル単位で正確な 1290×2796 PNG が出力されます：

• 太字の白い見出しテキスト（動詞はキャンバス幅に収まるよう自動調整）
• iPhone デバイスフレーム（事前レンダリング済みテンプレートを使用）
• フレーム内に合成された Simulator のスクリーンショット
• 単色の背景

骨組みは内部処理用の中間生成物です。ユーザーに見せたり、確認を求めたりしないでください。すぐにステップ 2（Nano Banana による強化）へ進んでください。

ステップ 2：Nano Banana Pro で強化する（3 バージョンを並列生成）

edit_image の呼び出しを3 つ並列で行ってください。並列実行は必須です。3 回の呼び出しは必ず 1 つのメッセージでまとめて実行し、順番に実行しないでください。

3 つの呼び出しそれぞれで、以下を使用します：

• prompt：強化の指示（プロンプトテンプレートを参照。最初のスクリーンショット用と、それ以降のスクリーンショット用で異なります）
• images：含める画像については以下を参照
• outputPath：各バージョンで異なるパスを指定します：
  • ./screenshots/01-[benefit-slug]/v1.jpg
  • ./screenshots/01-[benefit-slug]/v2.jpg
  • ./screenshots/01-[benefit-slug]/v3.jpg

最初のスクリーンショット（承認済みテンプレートがまだない場合）

入力として骨組みのみを使用します：

• images：filePath が screenshots/01-[benefit-slug]/scaffold.png を指す骨組み

最初のスクリーンショット用プロンプトテンプレート：

This is a SCAFFOLD for an App Store screenshot — a rough layout showing the correct text, device frame position, and app screenshot placement. Your job is to transform this into a polished, professional App Store marketing screenshot that would make someone tap Download.

KEEP EXACTLY AS-IS:
- The headline text (wording, position, and approximate size)
- The app screenshot shown on the phone screen
- The background colour

ENHANCE AND POLISH:
- Replace the placeholder device frame with a photorealistic iPhone 15 Pro mockup — sleek, modern, with accurate proportions, reflections, and subtle shadows. The phone should look like a real device, not a flat rectangle. Keep the same position and size as the scaffold.
- Refine the overall visual quality to look like a professional, high-budget App Store screenshot
- OPTIONALLY add a PRIMARY breakout element — but ONLY if there is an obvious, visually compelling UI panel on the app screen that directly relates to the benefit headline. If nothing on screen clearly reinforces the headline, skip the breakout entirely — a clean screenshot with no breakout is better than a forced one. When you DO add a breakout, it MUST be an entire UI panel or grouped section (e.g., a complete card with its title and content, a full list section, a complete dialog/sheet) — never individual small elements like a single button, icon, or colour dot. IMPORTANT: The panel must stay at the SAME vertical position and orientation as where it appears on screen — do NOT rotate or angle it. The panel must be SCALED UP significantly — rendered much larger than it appears on the phone screen — so that it extends dramatically beyond BOTH left and right edges of the device frame, clearly overlapping the phone bezel on both sides, expanding to nearly the full width of the screenshot canvas. Do NOT keep the panel at its original on-screen size with just padding added around it. The panel itself must be enlarged. It should appear to float in front of the device at this larger scale — add a soft drop shadow beneath it to create depth and sell the hovering effect. The panel must look like it came from the app — same colours, same style, same content. Do NOT invent new elements.
[PRIMARY BREAKOUT — if a relevant panel is obvious, describe the specific UI panel visible on screen and instruct it to extend beyond both edges of the device frame with a drop shadow, e.g., "The [panel name] card/row extends beyond both left and right edges of the device frame, overlapping the phone bezel on both sides, expanding to nearly the full screenshot width. It floats in front of the device with a soft drop shadow beneath it." If no panel clearly relates to the headline, write "No breakout — the app screen speaks for itself."]
- Optionally add 1-2 secondary elements that reinforce the benefit and message of the screenshot — the kind of enhancements a professional graphic designer would add for impact. These are NOT from the app UI; they are creative additions that help clearly communicate what the screenshot is trying to portray to the user browsing the App Store. They should carry the message and support ASO conversion, but never at the cost of the overall design aesthetic. They must not compete with the primary breakout for attention.
[SECONDARY ELEMENTS (optional) — describe 0-2 small supporting elements that tell the story, or "None needed"]
- The background should be a clean, solid brand colour. Do NOT add glows, gradients, radial patterns, or light effects to the background. Keep it flat and bold.
- Ensure the text is crisp, bold, and highly readable

The final result should look like it was designed by a professional App Store screenshot agency — polished, high-converting, and visually striking. No watermarks, no extra text, no app store UI chrome.

2枚目以降のスクリーンショット（1枚目の承認後）

入力として2枚の画像を使用します。

1. このベネフィットのスキャフォールド（screenshots/0N-[benefit-slug]/scaffold.png）— レイアウトを定義します
2. 最初に承認されたスクリーンショット（screenshots/final/01-[first-benefit-slug].jpg）— スタイルテンプレートを定義します

2枚目以降のスクリーンショット用プロンプトテンプレート：

You are creating the next screenshot in an App Store screenshot SET. It must look like it belongs to the same series as the style reference.

TWO REFERENCE IMAGES:
- FIRST image: The SCAFFOLD — use this as the definitive guide for layout: headline text wording/position, device frame placement, and the app screenshot on screen. This defines WHAT this screenshot shows.
- SECOND image: The STYLE TEMPLATE — this is an already-approved screenshot from the same set. Match its visual style EXACTLY: same device frame rendering (this is critical — the phone must look identical), same text treatment, same background style/accents, same level of polish, same overall aesthetic. This defines HOW this screenshot should look. When in doubt, copy the style template more closely rather than less.

REQUIREMENTS:
- CRITICAL: The device frame MUST match the style template EXACTLY — same photorealistic iPhone rendering, same size, same position, same shadows, same reflections, same edge treatment. Do NOT reinvent or reimagine the device frame. Reproduce it as closely as possible from the style template, only changing the screen contents.
- Match the style template's text rendering style (same font treatment, same crispness, same visual weight)
- Match the style template's background — clean, solid brand colour. No glows, gradients, radial patterns, or light effects.
- Use the scaffold's layout for positioning (text, device, screenshot placement)
- OPTIONALLY add a PRIMARY breakout element — but ONLY if there is an obvious, visually compelling UI panel on the app screen that directly relates to the benefit headline. If nothing clearly reinforces the headline, skip the breakout entirely. When used, it MUST be an entire UI panel or grouped section (NOT individual small elements like a single button or icon). The panel must stay at the SAME vertical position and orientation as on screen — do NOT rotate or angle it. The panel must be SCALED UP significantly — rendered much larger than it appears on the phone screen — so that it extends dramatically beyond BOTH left and right edges of the device frame, clearly overlapping the phone bezel on both sides, expanding to nearly the full width of the screenshot canvas. Do NOT keep the panel at its original on-screen size. The panel itself must be enlarged. It should appear to float in front of the device at this larger scale — add a soft drop shadow beneath it to create depth. The panel MUST come from the app screenshot — same colours, same style, same content. Do NOT invent new elements.
[PRIMARY BREAKOUT — if a relevant panel is obvious, describe the specific UI panel visible on screen to pop out with a drop shadow, extending beyond both device frame edges. Otherwise write "No breakout — the app screen speaks for itself."]
- Optionally add 1-2 secondary elements that reinforce the benefit and message of the screenshot — the kind of enhancements a professional graphic designer would add for impact. These are NOT from the app UI; they are creative additions that help clearly communicate what the screenshot is trying to portray to the user browsing the App Store. They should carry the message and support ASO conversion, but never at the cost of the overall design aesthetic. They must not compete with the primary breakout for attention.
[SECONDARY ELEMENTS (optional) — 0-2 small supporting elements that tell the story, or "None needed"]
- The breakout elements should match the style and energy level of those in the style template

The result must look like it was designed alongside the style template as part of the same professional set. When placed side-by-side in the App Store, they should be visually cohesive — same quality, same aesthetic, same design language, just different content.

No watermarks, no extra text, no app store UI chrome.

重要 — 一貫性の確保：スキャフォールドによりレイアウトの一貫性が保たれます。スタイルテンプレートにより視覚的な表現の一貫性が保たれます。Nano Banana がテキストやレイアウトを変更したり、スタイルテンプレートから逸脱したりした場合は、再生成してください。

ステップ 3：3つのバージョンすべてをただちにトリミングし、App Store の寸法にリサイズします

⚠️ 3回の edit_image 呼び出しがすべて完了したら、ただちにこれを実行する必要があります。これを実行する前に、画像をユーザーに見せないでください。Nano Banana の未加工の出力は、常に App Store Connect に適した寸法ではありません。

重要 — 3つすべてのトリミングとリサイズの操作には、Bash ツールの呼び出しを必ず1回だけ使用してください。 Bash を3回に分けて呼び出さないでください。Bash を並列に呼び出さないでください。以下の単一ループを使用して、ユーザーに表示される権限確認を1回だけにします。

TARGET_W=1290 && TARGET_H=2796 && \
for INPUT in screenshots/01-[benefit-slug]/v1.jpg screenshots/01-[benefit-slug]/v2.jpg screenshots/01-[benefit-slug]/v3.jpg; do
  OUTPUT="${INPUT%.jpg}-resized.jpg"
  cp "$INPUT" "$OUTPUT"
  W=$(sips -g pixelWidth "$OUTPUT" | tail -1 | awk '{print $2}')
  H=$(sips -g pixelHeight "$OUTPUT" | tail -1 | awk '{print $2}')
  CROP_W=$(python3 -c "print(round($H * $TARGET_W / $TARGET_H))")
  OFFSET_X=$(python3 -c "print(round(($W - $CROP_W) / 2))")
  sips --cropOffset 0 $OFFSET_X --cropToHeightWidth $H $CROP_W "$OUTPUT"
  sips -z $TARGET_H $TARGET_W "$OUTPUT"
  echo "--- $OUTPUT ---"
  sips -g pixelWidth -g pixelHeight "$OUTPUT"
done

このスクリプトは、正しいアスペクト比にトリミングし（上部中央に合わせます。左右を均等に切り詰め、見出しの位置が変わらないよう上端を保持します）、正確なピクセル寸法にリサイズします。リサイズした画像は、ファイル名に -resized.jpg を付けて別ファイルとして保存されます。

ディスプレイサイズごとの目標寸法 — TARGET_W と TARGET_H を調整してください。

• iPhone 6.5"：TARGET_W=1242 TARGET_H=2688
• iPhone 6.7"（デフォルト）：TARGET_W=1290 TARGET_H=2796
• iPhone 6.9"：TARGET_W=1320 TARGET_H=2868

ステップ 4：3つのバージョンすべてをユーザーと確認します

Read ツールを使用して、リサイズ済みバージョン（-resized.jpg ファイル）を3つすべてユーザーに提示します。Nano Banana の未加工の出力は決して見せず、必ず後処理済みバージョンを見せてください。

バージョン 1、バージョン 2、バージョン 3と明確にラベルを付け、気に入ったものを選ぶか、変更を依頼するようユーザーに尋ねます。

ステップ 5：必要に応じて反復します

ユーザーが変更を希望する場合は、入力として3枚の画像を使用して edit_image を実行します。

1. スキャフォールド（scaffold.png）— レイアウト（テキストの位置、デバイスの配置、スクリーンショット）を固定します
2. スタイルテンプレート（screenshots/final/01-*.jpg の最初に承認されたスクリーンショット）— 一連のスクリーンショット全体で一貫させる必要がある、デバイスフレームの描画と全体的な視覚スタイルを定義します
3. 承認済みデザイン（このスクリーンショットについてユーザーが最も気に入ったバージョン）— クリエイティブな方向性と、目立たせる要素のアプローチを固定します

プロンプトでは、3枚すべてに言及してください。

Here are three reference images, each with a distinct purpose:

- FIRST image: The SCAFFOLD — use this as the definitive guide for layout: text position, device frame placement, and the app screenshot on screen. This defines WHERE everything goes.
- SECOND image: The STYLE TEMPLATE — this is the first approved screenshot in the set. The device frame rendering, text treatment, and overall visual style MUST match this exactly. This defines HOW the screenshot should look to maintain consistency across the set.
- THIRD image: The APPROVED DESIGN DIRECTION — this is the version the user liked best for this specific screenshot. Match its creative direction, breakout element approach, and secondary elements.

Generate a new version that keeps the layout from the scaffold, the device frame and visual style from the style template, and the creative direction from the approved design, with these changes:
[USER'S REQUESTED CHANGES]

これにより、スキャフォールドでレイアウトを固定して逸脱を防ぎ、スタイルテンプレートでデバイスフレームと視覚的な表現を同一に保ってセット全体の一貫性を維持し、ユーザーがすでに承認したクリエイティブな方向性を保持できます。

反復する場合も、並列に3つのバージョンを再度生成します（1つのメッセージで edit_image を3回並列に呼び出します）。その後、ユーザーに見せる前に、ただちにステップ 3 のトリミングとリサイズのループを、1回の Bash 呼び出しですべてのバージョンに対して実行します。

ユーザーが満足するまで繰り返します。

ステップ 6：承認済みバージョンを final/ にコピーします

ユーザーが採用するものを選んだら、リサイズ済みバージョンを screenshots/final/ にコピーします。

mkdir -p screenshots/final
cp "screenshots/01-[benefit-slug]/v2-resized.jpg" "screenshots/final/01-[benefit-slug].jpg"

これにより final/ を整理された状態に保ち、承認済みで App Store に提出できるスクリーンショットのみを、ベネフィットごとに1枚、順番に番号を付けて保存できます。その後、次のベネフィットに進みます。

ブランドカラーを決める（自動）

背景色を選ぶよう、ユーザーに尋ねてはいけません。代わりに、最適な色を自動的に決めます。

1. コードベースを分析する — アセットカタログ、テーマファイル、カラー定数、Info.plist で、アクセントカラー、色合い、ブランドカラーを確認します
2. シミュレーターのスクリーンショットを調べる — UI の支配的な色は何ですか？アプリではどのようなカラーパレットが使われていますか？
3. アプリの分野と対象ユーザーを考慮する — ゲームなら大胆で遊び心のある色、金融アプリなら安心感と信頼感のある色が適しています

次の条件を満たす色を1色選びます。

• スクリーンショットを引き立てる — アプリの画面を際立たせ、色がぶつからないようにします。アプリの UI がほぼ白や明るい色なら、コントラストを出すために、彩度の高い大胆な背景色を使います。
• スクロールの手を止める — 鮮やかで、大胆で、彩度の高い色にします。落ち着いた色やパステルカラーは App Store では埋もれてしまいます。
• アプリの個性に合う — アプリのエネルギーに合わせます。
• 落とし穴を避ける — 白や明るいグレーは避けます（App Store の背景に埋もれてしまいます）。アプリの UI の支配的な色に近すぎる色も避けます。

選んだ色と簡潔な理由を提示します（例：「#7B2D8E（ディープパープル）を使用します。カラフルなアプリの UI を引き立て、サムネイルサイズでも目を引きます」）。ユーザーは希望すれば変更できますが、質問として提示してはいけません。

ブランドカラーは、スキャフォールディングを始める前に、生成プロセスのステップ0でメモリーに保存されます。

出力

生成したスクリーンショットを、プロジェクトのルートにある screenshots/ ディレクトリに、特典ごとのサブフォルダーに整理して保存します。

screenshots/
  01-track-card-prices/       ← working versions for benefit 1
    scaffold.png              ← deterministic compose.py output (text + frame + screenshot)
    v1.jpg                    ← Nano Banana enhanced version 1
    v1-resized.jpg            ← cropped/resized to App Store dimensions
    v2.jpg
    v2-resized.jpg
    v3.jpg
    v3-resized.jpg
  02-search-any-card/         ← working versions for benefit 2
    scaffold.png
    v1.jpg
    ...
  final/                      ← approved screenshots, ready to upload
    01-track-card-prices.jpg
    02-search-any-card.jpg

ユーザーが気にする必要があるのは final/ フォルダーだけです。ここには、特典ごとに承認済みの App Store 対応スクリーンショットが1枚ずつ、順番に番号を付けて保存されています。特典ごとのサブフォルダーには作業中のバージョンがすべて含まれており、セットが完成した後は無視するか削除できます。

また、各スクリーンショットが App Store Connect のどの表示サイズ枠に適合するかを、ユーザーに正確に伝えます。

メモリーに保存する

スクリーンショットを生成するたびに（またはセット全体の生成が完了した後に）、生成状態を Claude Code のメモリーシステムに保存します。aso_generated_screenshots.md などのメモリーファイルを作成または更新し、以下を記録します。

• ブランドカラー：名称＋16進コード
• 対象の表示サイズ：例：iPhone 6.7"（1290x2796）
• 生成した各スクリーンショットについて：
  • 特典の見出し（動詞＋説明語）
  • 特典のサブフォルダーパス（例：screenshots/01-track-card-prices/）
  • ユーザーが選んだバージョン（v1、v2、または v3）
  • 最終ファイルのパス（例：screenshots/final/01-track-card-prices.jpg）
  • 使用したシミュレーターのスクリーンショット（ファイルパス）
  • プロンプトで指定した、画面からはみ出させる要素
  • ステータス：生成済み／承認済み／要再作成
  • ユーザーからのフィードバックや変更依頼のメモ

このメモリーは段階的に更新します。各スクリーンショットが承認されたら、その都度追加してください。最後まで待たないでください。こうすることで、セットの作成途中で会話が中断されても、ユーザーは最後に完了したスクリーンショットから再開できます。

ショーケース画像

セット内のすべてのスクリーンショットが承認され、final/ に保存されたら、最終スクリーンショットを最大3枚並べて表示し、GitHub リンクを付けたショーケース画像を生成します。スキルディレクトリにある showcase.py スクリプトを使用します。

SKILL_DIR="$HOME/.claude/skills/aso-appstore-screenshots"

python3 "$SKILL_DIR/showcase.py" \
  --screenshots screenshots/final/01-*.jpg screenshots/final/02-*.jpg screenshots/final/03-*.jpg \
  --github "github.com/adamlyttleapps" \
  --output screenshots/showcase.png

Read ツールを使って、ショーケース画像をユーザーに表示します。これはスクリーンショットセット全体を共有するためのプレビューです。

---

重要な原則

• 機能よりメリットを重視：「動画に字幕を追加」ではなく、「エンゲージメントを高める」
• 一般論より具体性を重視：「持ち物を管理」ではなく、「トレーディングカードの価格を追跡」
• 行動を促す：すべての見出しは、力強い動詞で始めます
• ユーザーを中心に考える：すべてをダウンロードする人の視点で表現します
• コンバージョンを重視：あらゆる判断で、「これを見てダウンロードをタップしたくなるか？」を考えます
• 最初のスクリーンショットが最も重要です。ダウンロードする最大の理由を、ひと目で伝える必要があります
• スクリーンショットは、スワイプして見るとストーリーが伝わるようにします。それぞれが、新たな魅力的な理由を示します
• 最も視覚的に訴求力のあるシミュレーターのスクリーンショットには、最も重要なメリットを必ず組み合わせます
• 空の状態、読み込み画面、設定ページをスクリーンショットに使用しないでください。アプリの魅力が最も伝わる状態を見せます