integrate-revenuecat

integrate-revenuecat：RevenueCat のエンドツーエンド統合

ユーザーがプロジェクトに初めて RevenueCat を追加したい場合、または公開 API キーを使って SDK を再設定したい場合に、このスキルを使用します。このスキルでは、次の 2 つの作業を扱います。

1. ダッシュボード側 — RevenueCat MCP サーバーまたは rc CLI を使って、プロジェクトを設定し、アプリを登録して、公開 API キーを取得します。
2. アプリ側 — Purchases SDK をインストールし、アプリのエントリーポイントで Purchases.configure(…) を呼び出して、ログで設定バナーを確認します。

SDK の設定後、ペイウォールの構築方法を決めてから（セクション 5c）、ペイウォールのコードを記述します。

順番に進めてください。ユーザーが「SDK をインストールするだけ」と希望している場合でも、ほとんどの統合では両方の作業が必要です。SDK にはダッシュボードから取得した API キーが必要です。

プロジェクトとアプリがすでに存在し、ユーザーがコードへの SDK の組み込みだけを希望している場合は、以下のセクション 3に進んでください。 ユーザーが RevenueCat の新規プロジェクト（アプリ、商品、エンタイトルメント、オファリング）を立ち上げたい場合は、代わりに create-revenuecat-project スキルを使用してから、ここに戻って SDK をインストールしてください。

引数

スラッシュコマンドとして呼び出すと、$ARGUMENTS から次の値を使用できます。

• platform（任意）：ios、android、kmp、flutter、react-native のいずれかです。省略した場合は、セクション 3a の検出アルゴリズムを実行します。
• app_identifier（任意）：バンドル ID（iOS）またはパッケージ名（Android）です。省略した場合は、プロジェクトファイル（Info.plist、AndroidManifest.xml、app.json、pubspec.yaml）から読み取ります。
• project_name（任意）：使用する RevenueCat プロジェクトの名前です。省略した場合は、プロジェクト一覧を取得して（MCP または rc projects list）、ユーザーに確認します。

1. 現状を把握する

ダッシュボードを操作する前に、必要な情報を集めます。

• 対象プラットフォーム：iOS／Apple App Store、Android／Google Play、または両方です。質問する前に作業ディレクトリを調べてください。ほとんどのプロジェクトでは、セクション 3 の検出アルゴリズムで明らかになります。
• テクノロジー：ネイティブ iOS（Swift）、ネイティブ Android（Kotlin／Java）、React Native、Flutter、Kotlin Multiplatform。SDK の一覧：https://www.revenuecat.com/docs/getting-started/installation.md。
• アプリ識別子：バンドル ID（iOS）、パッケージ名（Android）。ユーザーに尋ねるのではなく、Info.plist／AndroidManifest.xml／app.json／pubspec.yaml から取得します。

2. ダッシュボード側

ユーザーが利用できる方法として、RevenueCat MCP サーバーまたは rc CLI のいずれかを使用します（CLI の確認方法と規約については revenuecat-cli スキルを参照してください）。この手順では、どちらの方法でも同じ操作を行えます。各手順には MCP ツールと rc コマンドが記載されています。

2a. プロジェクトを取得または作成する

• アクセス可能なプロジェクトを一覧表示します：list-projects（MCP）または rc projects list。複数ある場合は、このアプリに対応するものをユーザーに確認するか、新しいプロジェクトの作成を提案します（create-project／rc projects create）。
• プロジェクトがない場合は、create-revenuecat-project スキルに引き継いでから、ここに戻ります。
• 残りの手順で使う project_id を保存します。

2b. アプリを取得または作成する

• プロジェクトですでに設定されているアプリを確認します（list-apps／rc apps list）。test_store アプリは常に存在します。app_store アプリと play_store アプリは、ユーザーがストア側の設定を完了している場合にのみ存在します。
• ユーザーに、アプリが App Store Connect（iOS）または Google Play Console（Android）ですでに設定済みか確認します。ストア側の設定は後からでも行えること、統合の開始には test_store アプリで十分であることを伝えてください。
• ユーザーがストア側の設定は完了済みと回答した場合は、create-app（または rc apps create）を呼び出します。
  • iOS：type: "app_store" を指定し、bundle_id にはセクション 1 の値を使います。
  • Android：type: "play_store" を指定し、package_name にはセクション 1 の値を使います。
  • name は識別子から決めるか、ユーザーに確認します。

2c. 公開 API キーを取得する

• 該当するアプリ ID の公開キーを一覧表示します。list-public-api-keys（MCP）または rc apps keys <app-id> を使用します。
  • ストア側のアプリが存在する場合は、app_store / play_store を指定します。
  • それ以外の場合は、test_store アプリを指定します。
• 返されるキーは公開キーであり、クライアントアプリのコードに埋め込んでも安全です。iOS のキーには appl_…、Android のキーには goog_…、Amazon のキーには amzn_… が先頭に付きます。

クライアントコードでシークレット API キーを使用しないでください。 シークレットキーはサーバー側専用です。

3. アプリ側 — SDK をインストールして設定する

3a. プラットフォームを検出する

作業ディレクトリを調べ、上から順に最初に一致したものを選びます。

1. React Native：package.json に react-native-purchases のエントリーがある、または依存関係に react-native が含まれている場合 → platforms/react-native.md を読みます。expo も依存関係に含まれている場合は、Expo プロジェクトとして扱います。
2. Flutter：プロジェクトルートに pubspec.yaml が存在する場合 → platforms/flutter.md を読みます。
3. Kotlin Multiplatform：build.gradle.kts に kotlin { … } のマルチプラットフォームソースセットブロックが含まれている、または com.revenuecat.purchases:purchases-kmp* に依存している場合 → platforms/kmp.md を読みます。
4. Android（ネイティブ）：build.gradle(.kts) で com.android.application を適用しており、KMP ではない場合 → platforms/android.md を読みます。
5. iOS（ネイティブ）：プロジェクトルートに Package.swift、*.xcodeproj、*.xcworkspace、または Podfile が存在する場合 → platforms/ios.md を読みます。

複数の条件に一致する場合（例：Flutter プロジェクト内の ios/ フォルダー）は、ビルドを所有する最も外側のプロジェクトを選びます。それでも判断できない場合は、設定したいプラットフォームをユーザーに確認します。

3b. 共通概念（すべてのプラットフォーム）

• シークレットキーではなく、公開 SDK キーを使用します。 RevenueCat はストア／プラットフォームごとに個別の公開 SDK キーを発行します。iOS アプリでは appl_… キー、Android アプリでは goog_… キーを使用します（Amazon では amzn_… を使用します）。サーバー側のシークレットキーをクライアントアプリに含めてはいけません。
• アプリの起動ごとに一度だけ設定します。 Purchases.configure(…) はアプリのエントリーポイントで、できるだけ早く、正確に一度だけ呼び出します。以降の呼び出しは何も行わないか、警告を出します。
• デフォルトでは匿名ユーザーを使用します。 appUserID を渡さない場合、RevenueCat は固定の匿名 ID を作成します。起動時に認証済みユーザーがいる場合に限り appUserID を渡します。それ以外の場合は、後で logIn(…) を呼び出します（revenuecat-identify-user スキルを参照）。
• 統合中はデバッグログを有効にします。 方法は各プラットフォームのファイルに記載されています。リリースビルドでは無効にしてください。
• キーをソース管理に含めないでください。 ユーザーがシークレットの管理方法について尋ねた場合は、.env（RN）、xcconfig（iOS）、local.properties / gradle.properties（Android）、または dart-define（Flutter）を推奨します。

3c. 実装

検出結果に一致するプラットフォームのファイルを読みます。

• platforms/ios.md
• platforms/android.md
• platforms/kmp.md
• platforms/flutter.md
• platforms/react-native.md

各プラットフォームのファイルには、インストールコマンド、正確な configure のスニペット、アプリのエントリーポイント内での配置場所がすべて記載されています。

4. 検証する

次の条件を満たすまでは、セットアップが完了したと断言しないでください。

1. プロジェクトがビルドできること（Xcode ビルド、./gradlew assembleDebug、flutter run、npx react-native run-ios、または KMP に相当するコマンド）。
2. アプリが起動し、RevenueCat SDK の設定バナーがコンソール／logcat／Metro の出力に表示されること（期待されるログ行は各プラットフォームのファイルに記載されています）。
3. SDK による最初のネットワーク呼び出しで認証エラーが発生しないこと。API キーが間違っている場合、アプリがオファリングを取得した時点で認証エラーのログが表示されます。

ユーザーがアプリを実行せずに「インストール」だけを依頼した場合は、実行時にログで確認する内容を伝えます。

5. 次のステップ

5a. 商品、エンタイトルメント、オファリング

商品、エンタイトルメント、オファリングがプロジェクトですでに設定されているか確認します。まだ設定されていない場合は、create-revenuecat-project スキルを使ったサポートを申し出ます。

5b. ストア側のセットアップ

iOS（App Store Connect）

1. アプリ内課金キー（StoreKit 2 での使用を推奨） — App Store Connect → Users and Access → Integrations → In-App Purchase に移動します。キーを生成し、.p8 ファイルをダウンロードします。Key ID と Issuer ID を控えておきます。
2. 共有シークレット（従来の StoreKit 1） — App Store Connect → App → App Information → App-Specific Shared Secret に移動します。
3. ユーザーからこの情報が提供された場合は、create-app / update-app を使って RevenueCat 側に登録します。

Android（Google Play Console）

1. サービスアカウントの認証情報 — Google Cloud Console でサービスアカウントを作成します。「Service Account User」ロールを付与し、JSON キーを作成します。Play Console で「View financial data」権限を付与して、サービスアカウントへのアクセスを許可します。
2. リアルタイムデベロッパー通知（RTDN） — Cloud Pub/Sub トピックをセットアップします。Play Console → Monetization setup で設定します。
3. ユーザーからこの情報が提供された場合は、create-app / update-app を使って登録します。

5c. ペイウォールの構築方法を選ぶ

アプリには引き続きペイウォールが必要で、構築方法は 2 つあります。これは実装の詳細ではなく、製品上の判断事項です。そのため、ペイウォールのコードを書く前に決めてください。

• RevenueCat Paywall（デフォルトで推奨）。 RevenueCat がホストし、RevenueCatUI が表示します。ペイウォールは自分で作成します。revenuecat-paywall-design スキルを読み込み、その作成ワークフローに従います（MCP 経由の create-paywall-ai または CLI 経由の rc paywalls generate を使用し、現在のオファリングに紐付けて、アプリのコードベースを参考にします）。その後、revenuecat-paywall を使って表示します。ユーザーがダッシュボードでデザインする必要はありません。後からペイウォールビルダーで調整できます。アプリをリリースしなくてもデザイン、コピー、パッケージを変更でき、RevenueCat Experiments でペイウォールのバリアントを A/B テストできます。
• コードで実装するカスタムペイウォール。 アプリ独自の UI を使い、getOfferings() からパッケージと価格を取得し、revenuecat-purchase-flow で購入を処理します。見た目を完全に制御できますが、デザインを変更するたびにアプリのリリースが必要で、ペイウォールのデザインを A/B テストすることはできません。パッケージはオファリングから取得されるため、価格とオファリングのテストは引き続き機能します。

どちらにするか選びます。

1. ユーザーがすでに希望を伝えている場合。 その希望に従います。
2. アプリにまだペイウォール画面がない場合。 RevenueCat Paywall を推奨します。
3. アプリにすでにペイウォールまたはサブスクリプション画面がある場合（プランや価格の一覧、購読またはアップグレードボタン、ハードコードされた価格や商品 ID がある画面）。ユーザーはおそらく、その画面をオファリングに接続したいと考えています。既存の画面を維持することを推奨し、RevenueCat Paywall に置き換えることもできると伝えます。

ユーザーに質問できる場合は、両方の選択肢を含む質問を 1 つします。推奨する選択肢を先にし、それぞれにトレードオフを 1 行で説明します。質問できない場合（たとえば、非対話形式で実行している場合）も、作業を止めないでください。上記の推奨に従い、まとめで選んだ方法と、もう一方に切り替える方法を伝えます。

コード内で作業を完結できるという理由だけで、デフォルトでペイウォール画面を手作業で実装しないでください。新しい RevenueCat Paywall は未公開のドラフトです。ペイウォールビルダーで確認するようユーザーに伝え、ユーザーから依頼があった場合にのみ公開してください。ペイウォールを公開してオファリングに紐付けるまでは、アプリにデフォルトのフォールバックレイアウトが表示されます。

5d. 以降に使用するスキル

integrate-revenuecat の後によく使われるスキルは次のとおりです。

• revenuecat-paywall-design — ダッシュボードのペイウォールを作成または編集します。
• revenuecat-paywall — ダッシュボードで設定したペイウォールを表示します。
• revenuecat-purchase-flow — カスタムペイウォールの購入と復元を実装します。
• revenuecat-entitlements-gate — 有効なエンタイトルメントに基づいて機能へのアクセスを制限します。
• revenuecat-identify-user — アプリの認証システムに logIn / logOut を接続します。
• revenuecat-testing-setup — サンドボックスのテストチャネルをセットアップします。
• revenuecat-troubleshoot — オファリング、商品、エンタイトルメントに関する不具合を診断します。