bitomule/Koubou - App Store スクリーンショット生成ツール

Koubou: App Store スクリーンショット生成ツール

HTML/CSSテンプレート、100以上の実機フレーム、xcstringsによるローカライゼーション、Appleピクセルパーフェクトな寸法を使って、プロフェッショナルなApp Storeスクリーンショットを生成します。

スクリーンショットは広告であり、ドキュメントではありません。各スライドは1つの感情、成果、またはペインポイントの解決策を売り込みます。

このスキルでは、ユーザーの指示が常にデフォルト設定よりも優先されます。

クリエイティブな方向性はデフォルトでオープンです。 このスキルのルールは、インパクト、可読性、キャンバスに合わせたスケーリングを強制するために使い、すべてのセットを同じに見せるためには使いません。

ルール階層

このスキルのガイダンスは以下の順序で扱います：

1. ハード制約 — 可読性、スケール、サムネイルの明瞭さ、真実のプロダクトマーケティング、実際のキャンバス認識
2. 強いデフォルト — 多様性、非対称性、オーバーラップ、リズム、汎用的なレイアウトの回避
3. 好みの選択 — アンチ・スロップヒューリスティックとスタイルのデフォルト。より良いアイデアが明らかに作品を改善する場合、破ることができる

デフォルトを破る方がより良いスクリーンショットセットを生み出すなら、意図的に破り、生成前にそのトレードオフを自分自身に説明してください。

参考ファイル（必要なときに読み込む、最初からは読まない）：

• setup.md — インストールとHTMLランタイムのセットアップ
• design-guide.md — デザイン原則、コピーライティングルール、CSSルール、HTMLテンプレート例
• style-intake.md — 質問前にアプリの実際のビジュアル言語を調査する方法
• style-interview.md — 短く、シグナルの高いスタイル質問と会話パターン
• yaml-reference.md — YAML設定形式、ローカライゼーション、アセット、デバイス、サイズ
• capabilities-reference.md — koubouの全機能（コンテンツモード、ハイライト、ズーム、グラデーション）

フェーズ1: セットアップ（自動、非表示）

最初に kou が利用可能か確認します。kou がすでに動作している場合は、Pythonのパッケージングを再インストールしたり触ったりしないでください。

優先順位：

kou --version 2>/dev/null

kou --version が成功した場合：

• koubouはインストール済みと見なす
• pip、pip3、または playwright install を実行しない
• ユーザーの環境を「アップグレード」や「修正」しようとしない
• 生成前に必ず kou setup-html を実行する。このスキルはHTML専用であり、このコマンドは繰り返し実行しても安全なように設計されている

kou --version が失敗した場合、setup.md を読み、環境に最も負担の少ない方法に従います。

HTMLレンダリングサポートの場合：

• 常に kou setup-html を使用する
• 以前の実行でHTMLが動作したからといって、このステップをスキップしない
• playwright install chromium を直接実行しない

セットアップが失敗した場合のみユーザーに通知します。動作中のインストールを決して変更しないでください。

フェーズ2: アプリを読み、質問する

一般的なスタイルアンケートから始めないでください。まずアプリの実際のビジュアル言語を調査し、その後でまだ不足している、または曖昧な部分だけを質問します。

スタイル質問の前に style-intake.md を読みます。この順序に従います。

2.1 スタイルの発見（スタイル質問の前に必須）

まずローカルプロジェクトソースを調査します。ユーザーにビジュアルの方向性を質問する前に、自動的に検索します。

以下のソースを優先します：

1. Assets.xcassets、アプリアイコン、イラスト、ロゴ、カラーアセット
2. 既存のスクリーンショットとマーケティングフォルダ：
   • .maestro/
   • screenshots/
   • AppStore/
   • fastlane/screenshots/
   • marketing/
3. プロダクトドキュメントとポジショニング：
   • README*
   • CLAUDE.md
   • ローンチ計画、ランディングページのコピー、docsフォルダ
4. デザイントークンとUIコード：
   • CSS変数
   • SwiftUIの色、グラデーション、マテリアル、タイポグラフィの選択
   • ウェブテーマファイルと共有デザイン定数
5. 以前のApp Storeの成果物（存在する場合）：
   • 以前のテンプレート
   • 古いスクリーンショットキャンペーン
   • ローカライズされたマーケティングアセット

少なくとも以下のシグナルを抽出し要約します：

• 支配的な色とアクセントカラー
• 全体的なコントラスト：ダーク、ライト、ミックス、ミュート、ビビッド
• UIの密度：風通しが良い、バランスが良い、密
• 形状言語：シャープ、ソフト、ラウンド、カード主体、フラット
• アイコンとイラストのスタイル
• 見える場合のタイポグラフィの方向性
• コピーのトーン：落ち着いた、技術的、遊び心のある、プレミアム、温かい、緊急性がある
• アプリが落ち着いている、技術的、温かい、エネルギッシュ、洗練されている、遊び心があるなどの印象

アプリのスタイルが明確な場合：

• 検出したシグナルを平易な言葉でユーザーに要約する
• 一般的なテンプレート言語から再始動するのではなく、その方向性から構築することを確認する

シグナルが弱い、不足、または矛盾している場合：

• 見つかったものを伝える
• 広範なデザインアンケートを送る代わりに、不確実な点について焦点を絞ったフォローアップ質問をする

2.2 意図のインタビュー（短く、シグナルの高い）

style-interview.md を読み、最小限の質問だけをします。会話調に保ちます。すべての質問を一度に投げないでください。

必要なスタイル質問（まだ必要な場合）：

1. キャンペーンが投影すべき感情は：プレミアム、遊び心、エディトリアル、実用的、技術的、温かいなど？
2. 方向性に影響を与えるべきApp Storeの参考、ブランド、またはスクリーンショットセットはありますか？
3. 視覚的に禁止されているものは：派手なグラデーション、ガラスモーフィズム、ダークのみ、カードグリッド、過度に遊び心のあるスタイリングなど？
4. アプリ自体のどの視覚的特徴がスクリーンショットでも認識可能でなければなりませんか？

まだ未解決の場合のみ、オプションの質問：

5. 好ましいタイプの方向性またはフォントの個性
6. ライト、ダーク、またはミックスのバイアス
7. 密度の好み：より風通しが良い vs より情報量が多い
8. セットがスライド間でしっかり一貫しているべきか、それとも目に見えて変化しているべきか

2.3 プロダクト情報（必須）

スタイル発見を開始した後、残りの制作入力を自然に収集します：

1. アプリ: 名前、何をするか（1文）、主な価値提案
2. スクリーンショット: アプライメージはどこにありますか？ まず自動的に検索：
   • 見つかった場合、見つけたものを表示して確認
   • 見つからない場合、ユーザーがどのように生成するか尋ねる
   • クリーンなシミュレーターキャプチャでアプリUIが明確に表示されているものを優先。ユーザーが選択できる場合、最近の6.1インチiPhoneキャプチャをソース素材として推奨
3. ハイライトする機能: 優先順位付きの機能/ベネフィットリスト（3〜5を推奨）。各スライド = 1機能
4. ヒーローアセット: アプリアイコンまたは他のブランドアセット。質問する前に自動的に検索
5. スライド数: スクリーンショット数（最初は3〜5を推奨、Appleは最大10まで許可）

該当する場合のみオプション：

6. デバイス: デフォルトは iPhone 16 Pro - Black Titanium - Portrait。iPad/Mac/他が適切な場合のみ質問
7. ローカライゼーション: プロジェクトがすでにxcstringsまたは複数言語サポートを持っている場合のみ
8. 追加アセット: フローティングUI要素、バッジ、補足イラスト
9. 追加制約: 必要な主張、禁止スタイル、またはマーケティング制約

2.4 スタイル決定（HTMLの前に必須）

テンプレートを作成する前に、これら6項目を明示的に決定し内部でロックします：

• 検出されたブランドシグナル
• 選択されたキャンペーンスタイル
• コピーの声色
• 背景システム
• デバイス構成のリズム
• スライド間のバリエーション計画

各項目は、以下のいずれかで正当化されなければなりません：

• スタイル発見からのアプリの証拠、または
• インタビューからの直接のユーザーフィードバック

これらの1つを正当化できない場合、デザインする前に焦点を絞った質問を続けてください。

派生項目（ブロックされていない限り質問しない）

• ブランドカラーとUIムードからの背景グラデーションまたはテクスチャ
• レイアウト配分（ヒーロー → 機能トップ → 機能ボトム → 交互）
• 機能と価値提案からの見出しコピー
• アプリの実際のパレットからのセカンダリパレット
• project.device + project.output_size から kou inspect-frame を使用して得られるキャンバスクラス
• アプリ名を表示するかどうか。デフォルト：可読サイズで実際のブランド価値を追加する場合を除き、省略する
• アプリアイコンを表示するかどうか。デフォルト：ヒーローまたはクロージングスライドで控えめに使用し、小さな装飾マーカーとしては使用しない

原則: コンテキストがローカルで利用可能な場合、質問する前にそれを使用します。スタイル質問は調査の後、前ではありません。

フェーズ3: 生成

テンプレートを生成する前に design-guide.md を読みます。設定を書く前に yaml-reference.md を読みます。

1. 作業ディレクトリを作成（例：プロジェクトに適した AppStore/）

2. kou setup-html を実行

3. YAMLから project.device と project.output_size を読み取る

4. kou inspect-frame "<device>" --output-size <size> --output json を実行し、CSSを書く前にそのジオメトリを使用する

5. ナラティブアークとスライドごとに2〜3の見出し/サブタイトルオプションを作成。最初に最強のものを選ぶ。コピーの品質はCSSより優先される

6. スタイル決定をキャンペーンブリーフに変換：

   • セットがどのように感じられるべきか
   • 許可されるモチーフ
   • 禁止されるモチーフ
   • 最初の5スライドでどの程度のバリエーションを見せるか

7. templates/ にHTMLテンプレートを作成 — 最低3つの異なるレイアウト、最初の3スライドは同じ構成アーキタイプを繰り返さない

8. すべてのHTMLテンプレートで、CSSを書く前に以下の要素に data-kou-id と data-kou-role を追加：

   • メイン見出し: data-kou-id="headline" data-kou-role="headline"
   • 補足コピー: data-kou-id="subtitle" data-kou-role="supporting"
   • プライマリデバイス画像: data-kou-id="device" data-kou-role="device"
   • 機能タイトル/サブ（クロージング/機能スライド）: data-kou-id="feature-N-title" data-kou-role="feature-title"、data-kou-id="feature-N-sub" data-kou-role="feature-sub"

   これらがないと、レイアウトサイドカーの elements 配列が空になり、レンダリング後のQAが盲目的になります。正しいアノテーションパターンについては design-guide.md のテンプレート例を参照してください。

9. koubou設定で config.yaml を作成（形式については yaml-reference.md を参照）

10. キャンバスとコピーの長さに適応するCSSを使用：vw または clamp() を意図的に使用し、CSS Grid、オーバーラップ、絶対配置レイヤーを優先し、実際のキャンバスで最終的なテキストスケールを確認する

11. HTMLを書く前に: 各スライドのテキスト/デバイスゾーンを計画（どのエリアがキャンバスの何パーセントを占めるか）。ゾーンが明確になるまでCSSを開始しない

12. kou generate config.yaml --output json を実行

13. 生成された各HTMLスクリーンショットについて、JSON結果から layout_path を読み取り、レイアウトが許容可能か判断する前にサイドカーを検査する

14. レンダリング後QA（必須 — スキップしない）:

    • 各生成スライドを視覚的にレビュー
    • layout_path で参照される各 *.layout.json サイドカーを開く
    • design-guide.md の拒否チェックリストと照合
    • レンダリングされたセットが、発見したアプリスタイルを反映しているか確認（汎用的なApp Storeデフォルトになっていないか）
    • レイアウトJSONは客観的なジオメトリ（位置、占有スペース、比率、数学的オーバーラップ）にのみ使用
    • 測定されるべきHTMLスライドで elements が空の場合、アノテーションが欠落または壊れていると見なし、テンプレートを修正
    • 確認: 絵文字アイコンがない、同一のカードグリッドがない、デバイスが中心からずれていない、テキストが最小スケール以下でない、意図しないデバイスクロッピングがない（ヒーロースライドではデバイスの上部/ノッチが見えること、画面コンテンツが読み取れること）
    • ロゴスワップテストを適用: これらのスライドは競合他社でも機能するか？
    • いずれかのスライドが不合格の場合、修正してユーザーに表示する前に再生成

15. 出力フォルダを開く: open <output_dir>

16. ユーザーが調整を望むか尋ねる — すべてを再生成せずに特定のスライドのみを繰り返し改良

イテレーションルール

• ユーザーが特定のスライドの変更を要求した場合、そのテンプレートと設定エントリのみを変更
• ユーザーがグローバルなスタイル変更（色、フォント、ムード、密度、太さ）を要求した場合、すべてのテンプレートを更新
• 変更後、kou generate config.yaml --output json を再実行して、新しい layout_path 値とサイドカーが同期したままになるようにする
• ユーザーが編集中にリアルタイムプレビューを望む場合、kou live config.yaml を使用
• スライドが小さく感じられる場合、まずスケールを大きくするかレイアウトを変更。余分なグラデーションやラベルで問題を隠さない
• コピーが小さなテキストを強制する場合、コピーを書き直すか、より適切なレイアウトを選択。「テキストが収まらなければならなかった」という理由で弱々しいスライドを受け入れない
• バリエーションを高く保つ: 目標はキャンペーンの一貫性であり、レイアウトの繰り返しではない
• 最初のレンダリングが成功しても、出力がデザインルールや拒否チェックリストに違反している場合は停止しない
• ユーザーがムードの変更を要求した場合、以前のデフォルトを守るのではなく、品質制限内でセット全体を再解釈
• スクリーンショットとレイアウトJSONが矛盾する場合、味覚についてはレンダリングされたスクリーンショットを信頼し、古いジオメトリからレイアウト決定を強制するのではなく、アノテーションまたはレンダリングタイミングを調査

ハードルール

ハード制約

• 絵文字をアイコンとして使用しない — CSSシェイプ（アクセントバー、ドット）またはテキストのみを使用
• 禁止コピー句を使用しない — 「革新的」、「シームレス」、「アンロック」、「ゲームチェンジャー」など
• ロゴスワップテストを適用 — 競合他社の名前が当てはまる場合、セットは汎用的すぎる
• すべてのHTMLテンプレートに data-kou-id アノテーションが必要 — 最低でも: headline、subtitle、device。生成後にレイアウトサイドカーの elements が空の場合、アノテーションが欠落している — QAが合格する前にテンプレートを修正。アノテーションされていないスライドをユーザーに提示しない

スケール

• 縦長のiPhoneポートレート（iPhone6_9、iPhone6_7）では、ヒーロー見出しは >=10vw、サイドレイアウト見出しは >=10vw、サブタイトルは >=4.5vw でなければならない
• vw または clamp() は、計算されたサイズがターゲットキャンバス上の最小値をクリアする場合のみ使用
• コントラストスライドまたはクロージングスライドでは、コンテンツクラスターはキャンバス高さの60%以上を占有しなければならない

強いデフォルト

• 連続するスライドで同じ直立した中央揃えの電話構成を使用しない
• 見出しとデバイスの間に大きな空のバンド（キャンバス高さの15%以上）を残さない
• 中央揃えのデバイスで rotate() + translate() を組み合わせるのは避ける（レンダリング後に視覚的な中心が意図的だと感じられる場合を除く）
• スライドにオーバーラップ、エッジを破るクロップ、またはレイヤー構成が必要な場合、単純な中央揃えのフレックスカラムを使用しない
• CSSを書く前にテキスト/デバイスゾーンを計画（design-guide.mdのデバイス-テキストゾーンプランニングを参照）
• カードグリッドを使用する場合、厳密なグリッドがコンセプトに本当に役立つ場合を除き、ずらしたり、強調したり、簡略化する

コンテンツ

• デフォルトで小さなトップラベル、カテゴリラベル、またはアプリ名ヘッダーを追加しない
• 明確に読める場合を除き、アプリ名を小さな装飾テキストとしてレンダリングしない