App Launch Neo Kit

App Launch Kit: アイコン・LP・フィーチャーグラフィック・ストア文章・プライバシーポリシーの一気通貫制作

アプリのリリース素材を「アイコン → LP → フィーチャーグラフィック → ストア文章 → プライバシーポリシー」の順で制作するルーチン。 順番に意味がある: アイコンで決めた色・モチーフがLP/フィーチャーグラフィック/プライバシーポリシーのデザイントークンになり、LPで磨いたコピーがストア文章の骨格になる。途中から頼まれた場合も、すでにある素材(既存アイコンの色など)を必ず引き継ぐこと。

共通ルール(全STEPで参照)

• 公開URLの規約: アプリ1個 = {SITE_BASE_URL}/app//(` は com.example.` と統一)。
• 生成スクリプト(アイコン・フィーチャーグラフィック)はこの環境で都度書き起こす。スキルに同梱しない。ネットワーク無効でも動くよう外部依存は Pillow のみ、フォントは任意。
• 画像成果物は納品前に必ず view で目視確認(テキスト重なり・カード切れ・グリフ崩れ)。フォントは fc-list で実在確認してから使う(日本語は Noto Sans CJK JP = .ttc の index 0)。
• 開発者向け識別子(パッケージ名など)はエンドユーザー向けの公開面(LP等)には載せない。

STEP 0: 情報収集

ユーザーに質問する前に、アップロードされた資料(APPEAL.md、ROADMAP.md、企画書など)を最優先の情報源とし、会話履歴とあわせて埋められる項目をすべて埋める。 足りない項目だけを1回にまとめて質問する。

必須情報

| 項目 | 用途 | 例 | |---|---|---| | アプリ名(正式名称) | 全成果物 | マイスケール | | アプリの目的・コア機能 | LP・ストア文章 | 生活圏の円を旅先の地図に重ねて距離感をつかむ | | ターゲット層 | コピーの語り口 | 旅行者 | | 対象プラットフォーム | アイコン書き出し形式 | Android / iOS / 両方 | | ブランドカラーの希望 | アイコン・LP | グリーン系 |

命名とパッケージ名(このステップで正式決定する)

• アプリ名を正式名称として確定する。 未確定ならコンセプトに沿う候補を複数提案し、選ばれた名前を全成果物で一貫して使う(以後変えない)。
• パッケージ名は com.example.。 ` はアプリ名にちなんだ英小文字(記号・スペースなし。例: マイスケール → com.example.myscale)。このスラッグを公開フォルダ app//・app.env の SLUG`・ファイル配置すべてで統一する。

あれば品質が上がる情報(なければ聞くか、仮置きして明示)

• 差別化ポイント・UXのこだわり(LPの「こだわり」セクションの材料)
• 価格・広告・アプリ内課金の有無(ストア記載に必要。不明なら断定して書かない)
• プライバシーポリシーURL・サポート連絡先(ストア公開の必須要件。なければ「要準備」とTODOで明示)
• スクリーンショットの有無(なければLPはCSSモックで代替)
• ストアの既存掲載文(リライト案件の場合)

STEP 1: アプリアイコン

1. 3案提案: コンセプトの異なる3案をSVGで並べて見せる(Visualizerが使える環境ではインライン表示、なければSVG/PNGファイル)。各案に短い名前とコンセプト説明を付け、何を伝える案かを言語化する。
2. 収束: 選ばれた案のタイポグラフィ・配色・レイヤー順のバリエーションを2〜3案出して微調整する。1回で決まらなければ繰り返す(モチーフ自体の作り直し要望にも応じる)。
3. 書き出し: 確定後、Pillow で実ファイルを生成する(生成スクリプトの扱い・目視確認・フォントは共通ルール参照)。

• 確定デザインに合わせて描画関数(背景・図形・文字)を書く。図形だけで表現できるならフォント不要
• グリフ崩れの確認は512px版で行う。白い図形は白背景ビューアで見えないので、必要なら背景合成して確認する
• Android: mipmap各密度 + アダプティブアイコン前景/背景(+モノクロ) + Play Store用512px + README(XML設定とflutterlaunchericons手順)
• アダプティブ前景は中央約72%の安全領域に収める(円マスクで切れないか合成確認)
• iOSも対象なら 1024px(角丸なし・透過なし)を追加
• zip化して present_files で渡す

STEP 2: ランディングページ

着手前に {FRONTEND_DESIGN_GUIDE} を必ず読む(STEP 5 でも同じ指針を再利用する)。

• 単一HTMLファイル(CSS/JS同梱)で {OUTPUT_DIR}/ に出力
• アイコンの色をそのままCSS変数に: 背景色・影色・アクセント色を引き継ぎ、ヘッダーとCTA付近にアイコンSVGをインラインで埋め込む
• 構成の基本形(アプリの性質に合わせて取捨選択):

1. ヒーロー: キャッチコピー + アプリ体験を再現する動くデモ(CSSスマホモック+JS)。スクリーンショットがあればそれを使う
2. 問題提起: ターゲットの悩みと、アプリが解く理由
3. 機能紹介: コア機能をカードで(順序性があるならSTEP表記、なければ並列)
4. こだわり: 差別化ポイントを短い言葉で(トーンを変えたバンドセクションが効く)
5. 最終CTA + フッター(コピーライト・ブログリンク・ポリシーリンク)

• フッターに開発者のブログ {SITE_BASE_URL}/ へのリンクを必ず入れる(LP/ポリシーの公開先ブログ)
• ストアバッジ(Google Play / App Store)はリンク先未定ならリンク化せず、公開予定のステータス表示にする。納品時に、ストアURLが確定したら差し替えることを伝える
• 品質の床: モバイル対応、prefers-reduced-motion 対応、フォーカスリング、価格や効果を断定する根拠のないコピーを書かない
• 環境で Chromium(playwright)が使えるなら、デスクトップ/モバイル/各セクションを view で目視確認してから納品する(スクロール演出は一括撮影で発火しないので、各セクションへ scrollIntoView してから撮る)

Formspreeウェイティングリストフォーム(ストア公開前のリリース前LPに必ず組み込む)

ストアURLが未確定の段階では Google Play バッジの代わりにメール登録フォームを置く。Formspreeを使うとバックエンド不要で実装できる。ユーザーから Formspree の FORM_ID をもらえている場合は、その場で2か所に埋め込んで差し替え不要にする。

実装パターン

  
  登録する

JS: ページリロードなしの非同期送信(必ずこちらを使う)

form.addEventListener('submit', function(e) {
  e.preventDefault();
  fetch(form.action, {
    method: 'POST',
    body: new FormData(form),
    headers: { 'Accept': 'application/json' }
  }).then(function(res) {
    if (res.ok) {
      form.style.display = 'none';
      document.getElementById('wl-success').classList.add('show');
    } else { throw new Error(); }
  }).catch(function() {
    document.getElementById('wl-error').classList.add('show');
    btn.disabled = false;
  });
});

必須のUX要件

• 送信中はボタンを disabled にして「送信中…」と表示(二重送信防止)
• 成功後はフォームごと非表示にして「✓ 登録完了!」メッセージを表示
• エラー時はボタンを復活させてリトライできるようにする
• モバイルではフォームを縦積みレイアウトに切り替える(flex-direction:column)
• フォームが複数(ヒーロー＋最終CTA)あるときは、クラスで一括ハンドリングし各フォームの成功/エラー要素を個別に扱う

納品時に必ず伝えること

1. Formspreeアカウントを作成して New Form を作り、発行された FORM_ID を action の YOUR_FORM_ID と差し替える(FORM_IDを既にもらっていれば差し替え済みと伝える)
2. 無料プランは月50件まで。超える場合は有料プランへ
3. ストアが公開されたらフォームを Play Store バッジに差し替える(またはバッジとフォームを並列表示にする)

STEP 3: フィーチャーグラフィック(Google Play)

サイズ: 1024×500px、PNG/JPG、透過なし(Playストアのページ最上部に表示される横長バナー)。

Pillow で生成する(生成スクリプトの扱いは共通ルール参照)。配色はアイコン＝ブランドカラーに必ず合わせる(テンプレの色名に引きずられない。例: ブランドがオレンジならグラフィックもオレンジ系にする)。

レイアウト構成(3ゾーン)

[ アイコン(左) | アプリ名+キャッチ+サブコピー(中央) | 数値パネル群(右端) ]

• 左ゾーン(約28%幅): STEPで確定したアイコンと同デザインを isz = sh * 0.52 のサイズで中央に配置。アイコンの角丸・色・グリフを完全に引き継ぐ
• 中央ゾーン(約42%幅): アプリ名(Noto Sans CJK Black)→ キャッチコピー → サブコピーの3行構成。**右端パネルと被らないよう右端は sw0.75 を超えないこと。* 長い日本語名・長いキャッチは行幅を実測し、被るならフォントを下げるか改行する
• 右ゾーン(約20%幅): アプリを象徴する数値や画面の抜粋を小カード(角丸矩形)で縦並びに配置。強調したい1枚だけ反転(白地+ブランド色文字)でハイライト、他は半透明白の背景+白文字

背景

• 縦方向グラデーション(ブランド色の濃→淡など)をピクセル単位で描画
• 右奥に大きな半透明円を重ねて奥行き感を出す
• 外周に余白を設けず全面塗り(透過なし)

品質チェック

• スーパーサンプリング SS=3 以上で生成し、resize(LANCZOS) で最終サイズに落とす
• 目視確認(共通ルール)では特にテキスト重なり・カード切れ・グリフ崩れを見る

STEP 4: ストア掲載文(Google Play)

• LPのコピーを骨格に流用しつつ、ストアは検索流入が前提なのでキーワードを自然に織り込む
• 出力は1つのMarkdownファイルにまとめ、各項目に文字数カウントを添える(タイトル30字・簡潔な説明80字は超過しやすい)
• 未確定事項(価格・広告・ポリシーURL・カテゴリ・連絡先・スクショ・レーティング)は「要確認TODO」として末尾にチェックリスト化する
• 医療・健康系は効果効能を断定しない。免責(医師・薬剤師の指示に従う旨)を本文に入れる

STEP 5: プライバシーポリシー(HTML・ホスティングしてURL化)

Google Play 公開にはプライバシーポリシーのURLが必須。アプリの実際のデータの扱いに準じた内容で、LPと同じブランドの単一HTMLとして {OUTPUT_DIR}/ に出力し、他の成果物と一緒に納品する。デザイン指針は STEP 2 で読んだ frontend-design をそのまま再利用する(再読込は不要)。

• 内容はアプリ構成から導く: 技術スタック・権限・保存先を棚卸しし、該当するものだけ書く。取得しない情報は書かない。よくある観点:
• 位置情報／カメラ・写真／連絡先／通知・アラーム・端末起動時処理 等の権限
• ユーザーが端末内に保存するデータ(設定・スケジュールなど。機微なら明記)
• アプリ内課金(Google Play 決済。決済情報は開発者が取得しない旨)
• 第三者SDK・サービス(地図、Firebase、分析・クラッシュ収集など)。使うなら各社ポリシーへのリンク、使わないなら「使用しない方針」と明記し将来導入時に追記する旨
• Webサイト(LP)の登録フォームで取得するメール(Formspree 経由、リリース案内のみ)
• デザイン: LPのCSS変数(色)とロゴSVGを引き継ぐ。読みやすい本文レイアウト(幅760px前後)＋見出し・注記。
• 未確定箇所は 【要記入：…】/【要確認：…】 でハイライト表示し、ユーザーが埋める前提にする(事業者名・連絡先メール・最終更新日・分析SDKの有無・対象年齢に子どもを含むか 等)。
• 冒頭に原案バナー: 「これは公開前の原案(雛形)。法的助言ではない。専門家の確認を受け、Google Play『データセーフティ』フォームの回答と一致させること」を明記。
• LP側フッターのポリシーリンクを privacy-policy.html に向ける(相対リンク)。
• 公開先は共通ルールのURL規約に従う(静的ファイルとして設置)。次の「公開」セクションの手順でアップロードする。
• あなたは弁護士ではないので、雛形であることと専門家レビュー推奨を必ず一言添える。

公開: LP・ポリシーを静的ファイルとして設置

前提: 全画面レイアウトのLPを WordPress の投稿に貼ると、テーマ(Cocoon)の枠・本文カラム幅に押し込まれてデザインが崩れる。LPとプライバシーポリシーは WordPress 投稿にせず、静的ファイルとして設置する。

公開ツールはユーザーのローカル {DEPLOY_KIT_DIR}/ に常駐(スキルは同梱・生成しない)

同梱してもこのビルド環境(ネットワーク無効)では実行できずトークンを食うだけなので、スクリプトはユーザーPCの {DEPLOY_KIT_DIR}/ に置きっぱなしで運用する。構成:

• deploy_lp.py … FTP/FTPS で app// に静的設置(標準ライブラリのみ)
• wp_publish.py … WordPress REST API でブログ記事を投稿(pip install requests)
• publish.sh / publish.bat … 上記2本を順に起動するランチャー
• 認証情報・個人情報は一切ハードコードしない(すべて環境変数経由。表示URLは SITE_BASE_URL から組み立てる)

環境変数は2ファイルに分離

• .env(固定・一度だけ設定・更新不要): FTP_HOST / FTP_USER / FTP_PASSWORD / FTP_PORT / FTP_TLS / FTP_REMOTE_ROOT / SITE_BASE_URL(例 {SITE_BASE_URL})/ WP_URL / WP_USERNAME / WP_APP_PASSWORD。FTP_REMOTE_ROOT はまず空で試し、/app// が 404 なら公開ルートを入れる。
• app.env(アプリごとに変わる): SLUG= / FILES=index.html privacy-policy.html / POST_FILE=(空ならブログ投稿はスキップ)/ WP_TITLE=。
• 両スクリプトは起動時に .env → app.env の順で自動読み込みする。

このスキルがアプリごとに出力するもの = 成果物 + app.env だけ

成果物(アイコン/LP/グラフィック/ストア文/ポリシー)に加えて、app.env(SLUG を当該スラッグにしたもの)を出力する。 スクリプト本体・固定 .env は出力しない(ユーザーが既に {DEPLOY_KIT_DIR}/ に常駐させている前提)。

ユーザー側の実行手順(このビルド環境はネットワーク無効なので実行はローカル)

1. index.html / privacy-policy.html / app.env を {DEPLOY_KIT_DIR}/ に置く。
2. ./publish.sh(Windows は publish.bat)を実行 → deploy_lp.py と wp_publish.py が順に起動。公開URL規約のパスに LP 一式を設置。POST_FILE が空ならブログ投稿はスキップ。
3. 初回のみ app/.htaccess に RewriteEngine Off(WordPress の書き換え干渉防止。publish.sh に同梱済み)。

• LP内のポリシーリンクは相対(privacy-policy.html)のままで繋がる。

WAF 注意(wp_publish.py 利用時)

ConoHa WING の WAF は CSS の /* */ などを「SQLインジェクション防御」と誤検知して 403 を返すことがある。コントロールパネル > サイト管理 > サイトセキュリティ > WAF で該当ログを「除外」するか、一時的にWAFをOFFにする。静的ファイルのFTP設置(deploy_lp.py)はWAFに当たらない。.env はコミット/共有/スキルに入れない。

納品

最後に全成果物(アイコン一式・LP・フィーチャーグラフィック・ストア文章・プライバシーポリシー)と app.env を present_files でまとめて渡し、「公開前に差し替え・準備が必要なもの」を箇条書きで案内する: Formspree フォームID(LPの YOUR_FORM_ID ×2。もらっていれば差し替え済み)、ローカルの {DEPLOY_KIT_DIR}/ に成果物と app.env を置いて publish.sh/publish.bat で公開URL規約のパスへ設置、プライバシーポリシーの空欄記入とURLのデータセーフティ登録、ストアURL、実機スクリーンショット、ストア文章の要確認TODO、com.example. のパッケージ名・事業者名・連絡先メール等。途中ステップだけ頼まれた場合も、次のステップに進めることを一言添える。

Public template notes

This is a sanitized public template. Replace placeholders such as {SITE_NAME}, {SITE_BASE_URL}, {SITE_DOMAIN}, {OUTPUT_DIR}, {DEPLOY_KIT_DIR}, and package IDs like com.example. with your own project values. Keep FTP, WordPress, and form IDs as environment variables or placeholders; do not commit actual credentials.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: hayama20974
• Source: hayama20974/claude-skills
• License: MIT

Install and usage instructions live in the source repository linked above.