capgo-cloud-migration

Capgo Cloud への移行

既存の Capacitor プロジェクトを Capgo から Capawesome Cloud に移行します。

前提条件

1. ライブアップデートに現在 Capgo を使用している Capacitor 6、7、または 8 のアプリ。
2. Node.js 18 以降と npm がインストールされていること。
3. プロジェクトのソースコードリポジトリにアクセスできること。
4. Capawesome Cloud のアカウントと組織。

一般的なルール

• @capawesome/cli コマンドを初めて実行する前に、--help フラグを付けて実行し、利用可能なオプションをすべて確認してください。
• 対応する Capawesome Cloud の機能を完全に設定して検証するまでは、Capgo の設定、パッケージ、署名キーを削除しないでください。
• 変更を加える前に、package.json の @capacitor/core から Capacitor のバージョンを確認してください。使用するプラグインのバージョンとアップデート戦略に影響します。
• Capgo アプリ ID はネイティブのバンドル ID（例：com.example.app）ですが、Capawesome Cloud のアプリ ID は UUID です。Capgo アプリ ID を Capawesome の設定にコピーしないでください。

MCP サーバー

Capawesome MCP サーバー は最新の Capawesome ドキュメントを提供するため、このスキルに含まれるガイダンスより常に新しい情報を参照できます。API トークンを使用すると、Capawesome Cloud 管理 API も利用できます。

• Capawesome MCP ツールを利用できる場合は、search_docs を呼び出してトピックを検索し、該当するページを get_doc_page で読んでから、以下のガイダンスを適用してください。両者の内容が異なる場合は、ドキュメントに従ってください。cloud_* ツールを使えば、このスキルに記載された Capawesome Cloud の手順（アプリの作成、ビルドの開始、チャンネルやストアへのデプロイ、ロールバック、失敗したジョブの診断）を Capawesome CLI の代わりに直接実行できます。
• 利用できない場合は、以下のコマンドでサーバーを追加できることを一度だけ伝えてから、このスキルに従って作業を続けてください。利用できるようになるまで作業を止めてはいけません。

claude mcp add --transport http capawesome "https://mcp.capawesome.io/mcp"

ドキュメントツールの利用にアカウントやトークンは必要ありません。Capawesome Cloud ツールを含む完全なセットアップ方法については、capawesome-mcp スキルを参照してください。

手順

ステップ 1：Capgo の使用状況を確認する

プロジェクトをスキャンして、使用中の Capgo の機能を特定します。

1.1 Capgo Updater プラグインを確認する

次の兆候を検索します。

1. package.json（dependencies または devDependencies）内の @capgo/capacitor-updater。
2. capacitor.config.ts または capacitor.config.json の plugins オブジェクト内の CapacitorUpdater キー。
3. TypeScript／JavaScript のソースファイル内での @capgo/capacitor-updater のインポート。

いずれかの兆候が見つかった場合は、ライブアップデートを使用中として記録します。

CapacitorUpdater の設定値（すべて任意）を記録します。

• appId（Capgo アプリ ID。com.example.app のようなバンドル ID）
• autoUpdate（true、false、'off'、'atBackground'、'atInstall'、'onLaunch'、'always'、または 'onlyDownload'。デフォルトは true）
• directUpdate（true、'atInstall'、'onLaunch'、または 'always'。デフォルトは false）
• defaultChannel
• appReadyTimeout（ミリ秒。デフォルトは 10000）
• autoDeletePrevious（デフォルトは true）
• publicKey（エンドツーエンド暗号化を使用していることを示します）
• periodCheckDelay（秒）
• responseTimeout（秒。デフォルトは 20）
• updateUrl / statsUrl / channelUrl（セルフホストの Capgo バックエンドを使用していることを示します）
• autoSplashscreen（デフォルトは false）

1.2 CI/CD での Capgo CLI の使用状況を確認する

次の兆候を検索します。

1. package.json（通常は devDependencies）内の @capgo/cli。
2. CI/CD 設定ファイル（例：.github/workflows/*.yml、.gitlab-ci.yml、bitrise.yml、Jenkinsfile、azure-pipelines.yml）および npm スクリプト内の capgo または @capgo/cli コマンド（例：bundle upload、channel set）。
3. CI/CD ファイルで参照されている CAPGO_API_KEY（または類似の）シークレット。

いずれかの兆候が見つかった場合は、CI/CDを使用中として記録し、オプションを含む Capgo CLI コマンドをすべて記録します。

1.3 コード署名／暗号化を確認する

次の手がかりを検索します。

1. プロジェクトのルートにある .capgo_key_v2 または .capgo_key_v2.pub ファイル（npx @capgo/cli key create によって作成されます）。
2. CapacitorUpdater 設定内の publicKey の値。
3. CI/CD の bundle upload コマンドにある --key-v2 または --key-data-v2 フラグ。

いずれかの手がかりが見つかった場合、コード署名を使用中としてマークします。

1.4 Capgo ネイティブビルドを確認する

CI/CD ファイルまたは npm スクリプト内の capgo build コマンド（例：build request、build credentials）を検索します。見つかった場合、ネイティブビルドを使用中としてマークします。

1.5 チャネルを記録する

Capawesome Cloud で再作成できるように、既存の Capgo チャネルを一覧表示します。

npx @capgo/cli channel list <CAPGO_APP_ID>

コマンドが失敗した場合（例：API キーを利用できない場合）は、代わりに Capgo Console でチャネルを一覧表示するようユーザーに依頼します。

1.6 調査結果を提示する

検出された機能（Live Updates、CI/CD、コード署名、ネイティブビルド）と記録された設定をユーザーに提示します。移行する機能を確認するようユーザーに依頼します。

ステップ 2：Capawesome Cloud をセットアップする

2.1 認証する

npx @capawesome/cli login

2.2 アプリを作成する

ユーザーがすでに Capawesome Cloud のアプリ ID を持っている場合はスキップします。

npx @capawesome/cli apps:create

後続の手順で使用するため、返されたアプリ ID（UUID）を保存します。これは Capgo のアプリ ID をすべて置き換えますが、形式が異なり、ネイティブのバンドル ID ではありません。

2.3 チャネルを再作成する

ステップ 1.5 で記録した各 Capgo チャネルに対応する Capawesome Cloud チャネルを作成します。

npx @capawesome/cli apps:channels:create --app-id <APP_ID> --name <CHANNEL_NAME>

--self-assign、--disable-auto-update、デバイスターゲティング（--ios／--android）などの Capgo のチャネル設定に相当する Capawesome Cloud のチャネルレベル設定はありません。

• デバイスの自己割り当ては不要です。Live Update SDK は、サーバー側でオプトインしなくても、sync({ channel }) または setChannel() を使って任意のチャネルをリクエストできます。
• ネイティブバージョンによるアップデートのブロックは、アップロード時にバンドルごとに設定します（--android-min、--ios-min および関連するフラグ）。

ステップ 3：プラグインを置き換える

Live Updates が検出されなかった場合、またはユーザーが移行しないことを選択した場合は、このステップをスキップします。

3.1 Capgo Updater プラグインを削除する

npm uninstall @capgo/capacitor-updater

3.2 Capawesome Live Update プラグインをインストールする

プロジェクトの Capacitor バージョンに合ったバージョンをインストールします。

• Capacitor 8：npm install @capawesome/capacitor-live-update@latest
• Capacitor 7：npm install @capawesome/capacitor-live-update@v7-lts
• Capacitor 6：npm install @capawesome/capacitor-live-update@v6-lts

ステップ 4：Capacitor の設定を更新する

capacitor.config.ts（または .json）で、CapacitorUpdater プラグインの設定を LiveUpdate に置き換えます。設定オプションを次のように対応付けます。

Capgo（CapacitorUpdater）	Capawesome（LiveUpdate）	備考
appId	appId	値が異なります — ステップ 2 の Capawesome Cloud アプリ ID（UUID）を使用します
appReadyTimeout	readyTimeout	どちらもミリ秒単位です。Capgo のデフォルトは 10000、Capawesome のデフォルトは 0（無効）です。ロールバック保護を維持するには、readyTimeout: 10000 を明示的に設定します
autoDeletePrevious	autoDeleteBundles	Capgo のデフォルトは true、Capawesome のデフォルトは false です。autoDeleteBundles: true を明示的に設定します
autoDeleteFailed	（削除）	ロールバックの原因となったバンドルが再インストールされないよう、autoBlockRolledBackBundles: true を使用します
autoUpdate	autoUpdateStrategy またはコード	戦略の対応付けについては、ステップ 6 を参照してください
autoSplashscreen（および autoSplashscreenLoader、autoSplashscreenTimeout）	（削除）	コードで処理します。ステップ 6 の Force Update パターンを参照してください
defaultChannel	defaultChannel	同じ値です
directUpdate	（削除）	コードで処理します。ステップ 6 を参照してください
periodCheckDelay	（削除）	コードで処理します。ステップ 6 のとおり、代わりに App の resume イベントで同期します
publicKey	publicKey	新しい値が必要です — ステップ 7 で新しい鍵ペアを生成します。Capgo の鍵を再利用しないでください
resetWhenUpdate	（削除）	SDK が自動的に処理します
responseTimeout	httpTimeout	単位が変わります：Capgo は秒単位（デフォルトは 20）、Capawesome はミリ秒単位（デフォルトは 60000）です。1000 を掛けます
statsUrl	（削除）	不要です
updateUrl / channelUrl	serverDomain	EU ホスティング（api.cloud.capawesome.eu）の場合のみ設定します。スキームやパスを含めず、ドメインのみを指定します。デフォルトは api.cloud.capawesome.io です
version	（削除）	SDK はネイティブのバージョンコードを使用します

ほかのすべての Capgo オプション（allowModifyUrl、allowModifyAppId、allowManualBundleError、allowPreview、persistCustomId、persistModifyUrl、allowSetDefaultChannel、keepUrlPathAfterReload、disableJSLogging、osLogging、shakeMenu、shakeMenuGesture、allowShakeChannelSelector、localS3、localHost、localWebHost、localSupa、localSupaAnon、localApi、localApiFiles）には対応するオプションがありません。削除してください。

例：

 // capacitor.config.ts
 const config: CapacitorConfig = {
   plugins: {
-    CapacitorUpdater: {
-      appId: 'com.example.app',
-      autoUpdate: true,
-      defaultChannel: 'production',
-      appReadyTimeout: 10000,
-      autoDeletePrevious: true,
-      responseTimeout: 20
-    }
+    LiveUpdate: {
+      appId: '<CAPAWESOME_APP_ID>',
+      autoUpdateStrategy: 'background',
+      defaultChannel: 'production',
+      readyTimeout: 10000,
+      autoDeleteBundles: true,
+      autoBlockRolledBackBundles: true,
+      httpTimeout: 20000
+    }
   }
 };

ステップ 5：インポートと API 呼び出しを更新する

すべての TypeScript／JavaScript ファイルで @capgo/capacitor-updater のインポートを検索し、次のように置き換えます。

-import { CapacitorUpdater } from '@capgo/capacitor-updater';
+import { LiveUpdate } from '@capawesome/capacitor-live-update';

CapacitorUpdater クラスへのすべての参照を LiveUpdate に置き換え、以下のメソッド対応表を適用します。メソッド、イベント、結果フィールドの完全な対応表については、references/api-mapping.md を参照してください。よく使われる置き換えは次のとおりです。

アプリの準備完了通知 — notifyAppReady() は ready() に置き換えます。アプリの起動時にできるだけ早く呼び出してください。

-import { CapacitorUpdater } from '@capgo/capacitor-updater';
+import { LiveUpdate } from '@capawesome/capacitor-live-update';

-CapacitorUpdater.notifyAppReady();
+void LiveUpdate.ready();

アップデートの確認 — getLatest() は fetchLatestBundle() に置き換えます。結果のフィールドも変わります（version → bundleId、url → downloadUrl）。

-const latest = await CapacitorUpdater.getLatest();
-if (latest.url) {
-  console.log('Update available:', latest.version);
+const result = await LiveUpdate.fetchLatestBundle();
+if (result.downloadUrl) {
+  console.log('Update available:', result.bundleId);
 }

バンドルのダウンロード — download() は downloadBundle() に置き換えます。

-const bundle = await CapacitorUpdater.download({
-  url: latest.url,
-  version: latest.version
-});
+await LiveUpdate.downloadBundle({
+  url: result.downloadUrl,
+  bundleId: result.bundleId
+});

次のバンドルの設定 — next() は setNextBundle() に置き換えます。Capgo の set()（即時適用）は、setNextBundle() の後に reload() を呼び出す形に置き換えます。

-await CapacitorUpdater.next({ id: bundle.id });
+await LiveUpdate.setNextBundle({ bundleId: result.bundleId });

-await CapacitorUpdater.set({ id: bundle.id });
+await LiveUpdate.setNextBundle({ bundleId: result.bundleId });
+await LiveUpdate.reload();

チャネルの切り替え — チャネルを永続化する代わりに、sync(...) または fetchLatestBundle(...) にチャネルを直接渡すことをおすすめします。

-await CapacitorUpdater.setChannel({ channel: 'beta', triggerAutoUpdate: true });
+await LiveUpdate.sync({ channel: 'beta' });

チャネルの割り当てをアプリの再起動後も保持する必要がある場合にのみ setChannel({ channel }) を使用します。また、Capgo の unsetChannel() の置き換えには setChannel({ channel: null }) を使用します。

ステップ 6：アップデート戦略を移行する

記録した autoUpdate と directUpdate の値を、Capawesome のアップデート戦略に対応付けます。

6.1 バックグラウンド更新（Capgo のデフォルト）

autoUpdate: true、'atBackground'、'atInstall'、または directUpdate を指定しない 'onLaunch' の場合は、バックグラウンド方式を使用します。設定で autoUpdateStrategy: 'background' を指定します（ステップ 4 で設定済みです）。同期コードは必要ありません。ダウンロードされた更新は、次回のアプリ起動時に適用されます。

6.2 常に最新にする（Capgo の autoUpdate: 'always'）

バックグラウンド方式に nextBundleSet リスナーを組み合わせ、更新をすぐに適用するようユーザーに促します。アプリの初期化の早い段階で、次のコードを追加します。

import { LiveUpdate } from '@capawesome/capacitor-live-update';

LiveUpdate.addListener('nextBundleSet', async (event) => {
  if (event.bundleId) {
    const shouldReload = confirm('A new update is available. Install now?');
    if (shouldReload) {
      await LiveUpdate.reload();
    }
  }
});

このスニペットをそのままコピーしてください。confirm() ダイアログを簡略化したり、省略したりしないでください。

6.3 強制更新（Capgo の directUpdate ／ autoSplashscreen）

Capgo で directUpdate（false 以外の値）が設定されていた場合は、同期が完了するまでスプラッシュ画面を表示することで再現します。設定から autoUpdateStrategy を省略し、次を追加します。

import { SplashScreen } from '@capacitor/splash-screen';
import { LiveUpdate } from '@capawesome/capacitor-live-update';

const initializeApp = async () => {
  const { nextBundleId } = await LiveUpdate.sync();
  if (nextBundleId) {
    await LiveUpdate.reload();
  } else {
    await SplashScreen.hide();
  }
};

initializeApp();

これにより、directUpdate と autoSplashscreen の両方を置き換えられます。個別のスプラッシュ画面設定は必要ありません。この方法は、接続が遅い場合にユーザー体験へ影響することがあります。代わりにバックグラウンド方式をご検討ください。

6.4 手動／ダウンロードのみ（Capgo の autoUpdate: 'off' または 'onlyDownload'）

autoUpdateStrategy は未設定のままにし、ステップ 5 のメソッド対応表を使って既存の手動による getLatest()／download()／next() のフローを移行するか、フロー全体を単一の sync() 呼び出しに置き換えます。よく使われる方法は、App の resume イベントで同期することです。

import { App } from '@capacitor/app';
import { LiveUpdate } from '@capawesome/capacitor-live-update';

void LiveUpdate.ready();

App.addListener('resume', async () => {
  await LiveUpdate.sync();
});

この方法では、ダウンロードされた更新は次回のアプリ起動時に適用されます。

6.5 定期チェック（Capgo の periodCheckDelay）

インターバルベースのチェックオプションはありません。バックグラウンド方式では、アプリの起動時と再開時に更新がすでにチェックされます（15 分に 1 回までに制限されます）。カスタム間隔を設定するには、App の resume イベントで同期する（6.4 を参照）か、sync() を呼び出す JavaScript タイマーを実装します。

6.6 Capacitor プロジェクトを同期する

npx cap sync

ステップ 7：コード署名を移行する

コード署名が検出されなかった場合は、このステップをスキップしてください。

Capgo のキーシステム（.capgo_key_v2）はエンドツーエンド暗号化を提供し、Capawesome Cloud はバンドルの完全性検証に RSA 署名を使用します。キーは互換性がありません。新しいキーペアを生成してください。

npx @capawesome/cli apps:liveupdates:generatesigningkey --app-type capacitor

このコマンドは、capacitor.config.ts 用の publicKey 設定スニペットを出力します。秘密鍵は安全に保管し（CI/CD シークレットなど）、決してコミットしないでください。--private-key を指定してすべてのアップロードに署名します（ステップ 8 を参照）。

移行が検証されるまでは .capgo_key_v2 ファイルを保持し、検証後に削除してください（ステップ 9）。

ステップ 8：CI/CD パイプラインを更新する

CI/CD が検出されなかった場合は、このステップをスキップしてください。

8.1 認証を置き換える

Capawesome Cloud Console でトークンを生成し、CAPAWESOME_CLOUD_TOKEN という名前の CI/CD シークレットとして保存します。その後、Capgo API キーを置き換えます。

-- run: npx @capgo/cli@latest login "$CAPGO_API_KEY"
+- run: npx @capawesome/cli login --token ${{ secrets.CAPAWESOME_CLOUD_TOKEN }}

Capgo のコマンドでは、login を使用せずに --apikey（または -a）をインラインで渡すことがよくあります。これらのフラグを削除してください。Capawesome CLI は login --token のトークンを使用します。

8.2 CLI コマンドを置き換える

次のコマンド対応表を使用してください（Capgo はバンドル ID を位置引数としてアプリを識別し、Capawesome は --app-id <UUID> を使用します）。

Capgo CLI	Capawesome CLI の同等コマンド
npx @capgo/cli login <API_KEY>	npx @capawesome/cli login --token <TOKEN>
npx @capgo/cli init <API_KEY> <BUNDLE_ID>	同等のコマンドはありません。このスキルの手順に従ってください
npx @capgo/cli app add <BUNDLE_ID>	npx @capawesome/cli apps:create --name <NAME>
npx @capgo/cli app list	npx @capawesome/cli apps:list
npx @capgo/cli app delete <BUNDLE_ID>	npx @capawesome/cli apps:delete --app-id <APP_ID>
npx @capgo/cli bundle upload <BUNDLE_ID> --path <PATH> --channel <CH>	npx @capawesome/cli apps:liveupdates:upload --app-id <APP_ID> --path <PATH> --channel <CH>
bundle upload --delta / --delta-only	apps:liveupdates:upload --artifact-type manifest
bundle upload --key-v2 <KEY_PATH>	apps:liveupdates:upload --private-key <KEY_PATH>
bundle upload --rollout <PCT>	apps:liveupdates:upload --rollout-percentage <PCT>
bundle upload --min-update-version <V>	--android-min/--ios-min フラグ（バンドルのバージョンではなく、ネイティブのバージョン制約）
bundle upload -e <URL>（外部／セルフホスト可能）	apps:liveupdates:register --url <URL>
bundle zip	apps:liveupdates:bundle
bundle list / bundle delete / bundle cleanup	Console でバンドルを管理します。自動クリーンアップのため、チャンネルごとにバンドルの上限を設定します
channel add <CH> <BUNDLE_ID>	apps:channels:create --app-id <APP_ID> --name <CH>
channel delete <CH> <BUNDLE_ID>	apps:channels:delete --app-id <APP_ID> --name <CH>
channel list <BUNDLE_ID>	apps:channels:list --app-id <APP_ID>
channel set <CH> <BUNDLE_ID> --bundle <V>	apps:liveupdates:rollback --app-id <APP_ID> --channel <CH>（前のバンドル）または希望するバンドルを再アップロードします
channel set <CH> <BUNDLE_ID> --rollout-percentage <PCT>	apps:liveupdates:rollout --app-id <APP_ID> --channel <CH> --percentage <PCT>
key create	apps:liveupdates:generatesigningkey
build request（Capgo ネイティブビルド）	apps:builds:create — capawesome-cloud スキルの「Native Builds」セクションを使用してください
doctor	doctor

アップロードコマンドの置き換え例：

-npx @capgo/cli@latest bundle upload com.example.app --apikey "$CAPGO_API_KEY" --path ./dist --channel production
+npx @capawesome/cli apps:liveupdates:upload --app-id <APP_ID> --path ./dist --channel production

Capgo の --bundle <VERSION> フラグに相当するものはありません。Capawesome Cloud がバンドル ID を自動的に割り当てます。Git の参照を関連付けるには --git-ref を、カスタムメタデータには --custom-property key=value を使用してください。

ステップ 9：テストと検証

9.1 Live Updates を検証する

Live Update 機能をテストするか、ユーザーに確認してください。承諾された場合：

1. アプリに小さく目に見える変更を加えます（例：見出しの末尾に「 - Migration Test」を追加します）。
2. Web アセットをビルドします：npm run build。
3. バンドルをアップロードします：

   npx @capawesome/cli apps:liveupdates:upload --app-id <APP_ID> --channel <CHANNEL_NAME>
   

4. 目に見える変更を元に戻し、再ビルドして同期します：

   npm run build && npx cap sync
   

5. ネイティブプロジェクト（npx cap open ios または npx cap open android）を開き、デバイスまたはエミュレーターで実行します。
6. Live Update が適用されたことを確認します。autoUpdateStrategy: "background" の場合は、アプリを強制終了して再度開くか、アプリから離れて15分以上経過してから戻り、チェックを実行します。

9.2 クリーンアップ

すべての機能を検証した後：

1. @capgo/capacitor-updater と @capgo/cli が package.json から削除されていることを確認します。
2. CapacitorUpdater の設定が capacitor.config.ts/capacitor.config.json から削除されていることを確認します。
3. プロジェクトのルートから .capgo_key_v2 と .capgo_key_v2.pub を削除します（存在する場合）。
4. Capgo の CI/CD シークレット（例：CAPGO_API_KEY）と、残っている @capgo/cli コマンドを削除します。
5. Capgo を使用しているすべてのアプリのバージョンへの移行が完了したら、Capgo のサブスクリプションを解約するようユーザーに伝えます。

エラー処理

• プラグインの入れ替え後に npx cap sync が失敗する → インストールされている @capawesome/capacitor-live-update のバージョンが、package.json の Capacitor のバージョンと一致していることを確認してください（8 では @latest、7 では @v7-lts、6 では @v6-lts）。
• CapacitorUpdater is not defined などの実行時エラーが発生する → すべてのインポートが @capgo/capacitor-updater から @capawesome/capacitor-live-update に更新され、クラス名が CapacitorUpdater から LiveUpdate に変更されていることを確認してください。
• アップデート後にアプリが以前のバンドルに戻る → LiveUpdate.ready() が十分早いタイミングで呼び出されていません（Capgo の notifyAppReady() に相当）。アプリの初期化処理で最初に呼び出すか、readyTimeout を増やしてください。
• バンドルをアップロードしたのにアップデートが適用されない → 設定の appId に Capawesome Cloud の UUID（Capgo のバンドル ID ではありません）が設定されていること、およびデバイスが解決するチャンネルをアップロード先に指定したことを確認してください（getChannel() で確認できます）。
• autoUpdateStrategy: "background" でアップデートが検出されない → 前回のチェックから 15 分以上経過している場合にのみ、アップデートがチェックされます。アプリを強制終了して再起動してください。
• コード署名を有効にした後、署名の検証に失敗する → Capgo の鍵ペアを再利用しています。apps:liveupdates:generatesigningkey で新しい鍵ペアを生成し、設定の publicKey を更新してから、--private-key を指定して再アップロードしてください。
• setConfig is not a function → インストールされているプラグインのリリースが古くなっています。該当する dist-tag の最新リリースに更新してください（Capacitor 8 では @latest、7 では @v7-lts、6 では @v6-lts）。現在のタグ付きリリースにはすべて setConfig() が含まれています。
• fetchChannels() がエラーを返す → Capawesome Cloud Console で、アプリのチャンネル検出を有効にする必要があります。
• 移行後に CI/CD パイプラインが失敗する → CAPAWESOME_CLOUD_TOKEN シークレットが設定されていること、ほかのコマンドより前に login --token が実行されること、およびすべてのコマンドに Capawesome Cloud の UUID を指定した --app-id が渡されることを確認してください。

関連スキル

• capawesome-cloud — Live Updates、Native Builds、App Store Publishing に関する Capawesome Cloud の詳細なセットアップ手順です。
• capawesome-cli — Capawesome CLI のインストール、設定、使用方法です。
• ionic-appflow-migration — プロジェクトの移行元が Capgo ではなく Ionic Appflow の場合は、代わりにこのスキルを使用してください。
• capawesome-mcp — MCP クライアントをホスト型 Capawesome MCP サーバーに接続し、常に最新のドキュメントと Capawesome Cloud の管理機能を利用します。