webflow/webflow-skills

Webflow Cloud Apps

data_apps_toolを使用して、GitHubソースのアプリを作成し、運用に関する質問に回答し、Webflow Cloudアプリの環境を管理します。ユーザーの目的から開始し、必要な証拠のみを収集し、観察結果と結論を区別します。

CLI/ローカルソースアプリの作成やデプロイ、環境変数の作成や更新が必要なタスクには、webflow-cli:cloudスキルを使用してください。クライアント側のビルド出力はWebflowに送信されず、MCPを通じて回復できません。

手順

1. スコープを確立する

ユーザーのリクエストまたは既存のタスクコンテキストによって確立されたWebflow MCP接続を使用します。アクティブな接続が1つだけの場合は、ユーザーにリージョンの選択や再確認を求めずにそれを使用します。複数の接続がアクティブで、対象が不明確な場合は、対象に依存する操作に進む前にユーザーに明確化を依頼します。リソース不足やアクセスエラーを回復するためにリージョンを切り替えないでください。

既存のMCPアプリや環境を設定の書き込みやデプロイのためにCLIに引き渡す前に、設定されたリージョンを比較します。それらが異なる場合は、どちらかが正しいと想定したり、黙ってターゲットを変更したりしないでください。タスクコンテキストから目的のターゲットを解決します。それでも競合が解決しない場合は、ユーザーに問い合わせます。競合が解決されるまで、依存する変更を一時停止します。

目的のリージョンが確立されたら、CLIが正確なMCPアプリと環境IDを読み取れることを確認し、そのリージョンとIDを後続の変更に明示的に引き継ぎます。ログインステータスやリージョンラベルのみでは不十分です。確認が失敗した場合は、原因を推測せずに失敗を報告し、依存する変更を一時停止します。ターゲットが確立されている独立した作業を続行します。

1. 他のWebflow MCPツールの前にwebflow_guide_toolを呼び出します。ライブガイドとアクションスキーマは、現在の引数とレスポンスにとって信頼できる情報源です。
2. 環境変数の値に関する明示的なCLIハンドオフを除き、Webflow操作にはWebflow MCPツールを使用します。Webflow APIを直接呼び出さないでください。
3. すべてのツールコールに必須のcontextパラメータを含めます。三人称で15〜25語で記述します。
4. タスクが必要とする機能に応じてルーティングします：
   • data_apps_toolを使用して、GitHubソースのアプリを作成します。アプリ、環境、ドメイン、デプロイメントレコード、ログ、変数メタデータを検査します。GitHubソースと環境を管理し、GitHubデプロイメントをエンキューします。
   • data_variable_toolは、Designerの色、サイズ、フォント、CSS変数に使用します。
   • webflow-cli:cloudは、CLI/ローカルソースアプリ、ローカルビルドとデプロイ、または環境変数値の作成と更新に使用します。
5. data_apps_toolが利用できない場合は、Cloud Apps MCP機能が有効になっていないことを報告します。直接APIリクエストでバイパスしないでください。

環境変数の値やシークレットをチャットに貼り付けるようユーザーに依頼しないでください。作成または更新の場合は、webflow-cli:cloudに委任し、非表示プロンプト、標準入力、または保護されたファイルを必須にします。シークレットを位置引数として渡さないでください。

2. ターゲットを解決する

次の順序で識別子を発見します：

list_apps -> app_id
list_environments(app_id) -> env_id
list_deployments(app_id, env_id) -> deployment_id

アプリ名はサイト内でのみ一意であるため、名前付きアプリはsite_id + nameで解決します。複数のリソースが一致する場合は、識別メタデータを提示し、変更の前にユーザーに1つを選択するよう要求します。フィルター、ページネーション、カーソル、アクションバッチメカニズムについては、ライブガイドを使用してください。

3. 対応するユーザーストーリーに従う

GitHubソースアプリを作成する

1. アプリ名、正規のGitHubリポジトリURL、ブランチ、オプションの説明、およびスタンドアロンか既存のサイトにアタッチするかを確立します。
2. サイトアタッチアプリの場合は、サイトIDを解決します。スタンドアロンの場合はsite_idを省略します。
3. プレビューの前にマウント契約を適用します：
   • スタンドアロンアプリは常に/にマウントされます。mountを省略するか、/を使用します。
   • サイトアタッチアプリのデフォルトは/appで、/は拒否され、デフォルトをオーバーライドする場合は有効なルート以外のマウントが必要です。
4. スタンドアロン作成にはワークスペーススコープのユーザートークンが必要であることを説明します。WebflowがGitHubインストールを導出し、リポジリアクセスを検証します。インストールIDを要求しないでください。
5. デフォルトのドライランでcreate_appを呼び出します。リポジトリ、ブランチ、アタッチメント、該当するサイト、マウント、および最初のデプロイ試行を表示します。
6. confirmを要求します。確認の直後、実行の前に、開始時刻を記録し、1つの安定したidempotency_keyを生成します。dry_run: falseで実行し、完了時刻を記録します。そのキーを、この作成の正確な再試行にのみ再利用します。
7. 作成と最初のデプロイを別々の結果として扱います。返されたアプリは、deployStatusがskippedまたはfailedであっても、作成が成功したことを意味します。triggeredの場合は、環境とデプロイを検査します。skippedの場合は、ブランチを確認するか、コミットをプッシュします。failedの場合は、アプリを保持し、デプロイを個別に検査または再試行します。
8. アプリまたは結果が読み取れない場合は、再試行する前に調整します：
   • サイトアタッチアプリの場合は、site_id + nameで候補を収集します。スタンドアロンアプリの場合は、名前で候補を収集します。
   • どちらの場合も、各候補の名前、sourceUrl、createdAtを、要求されたリポジトリと記録された実行ウィンドウと比較します。
   • 正確に1つの候補が一致する場合にのみ、環境とデプロイに進みます。作成されたアプリがあいまいな間は再試行しないでください。
9. デプロイが失敗したため、作成されたアプリを自動的に削除しないでください。最初のデプロイダッシュボードリンクを環境の公開URLとして扱わないでください。

どのアプリと環境を見ていますか？

1. list_appsを使用してアプリを検索し、get_appでsourceUrlやsiteAttachedを含むメタデータを取得します。
2. list_environmentsを使用して、ブランチ、マウント、publicUrl、最新のデプロイステータスを報告します。publicUrlがnullの場合は、ユーザー向けの環境アドレスが利用できないことを報告します。自分で作成しないでください。
3. ユーザーがアプリにアクセスできる場所を尋ねた場合は、get_app_domainsを使用します。
4. カスタムドメインの結果には、デフォルトの*.webflow.ioホスト名が含まれないことを説明します。通常のWebflowサイトにアタッチされたアプリのドメインは、親サイトに属し、兄弟アプリで共有される場合があります。

何がデプロイされていて、それは正常ですか？

1. list_environmentsを使用して、環境の最新のデプロイステータスを取得します。
2. list_deploymentsを最新から順に使用し、次にget_deploymentで選択したデプロイの詳細なタイムラインとバージョンメタデータを取得します。
3. starting、building、deployingをアクティブな状態として扱います。その他のステータスは正確に報告し、意味を推測しないでください。
4. 失敗したフェーズは、buildFailedAtまたはdeployFailedAtを設定しますが、対応する完了タイムスタンプはnullのままです。nullの完了タイムスタンプだけでは、フェーズがまだ実行中であることは証明されません。
5. 観察可能なものを報告します：選択したアプリと環境、デプロイステータス、バージョンまたはコミットメタデータ（返された場合）、フェーズタイムスタンプ、および証拠のギャップ。

なぜデプロイは失敗したのですか？

1. get_deploymentでデプロイを取得し、ステータスとタイムスタンプから失敗したフェーズを特定します。
2. logsAvailableがtrueの場合にのみget_build_logsを呼び出します。狭いsinceウィンドウまたはqフィルターから開始し、必要に応じて拡大します。
3. 完全な結果が必要な場合は、nextCursorがnullになるまでページングします。
4. logsAvailableを保持と取得のシグナルとして扱います。すべてのフェーズがログエントリを生成した証拠としては扱いません。
5. 空の結果は、「一致する取得可能なサーバー側ログがない」として扱います。ビルドが成功した、またはエラーが発生しなかった証拠としては扱いません。
6. ユーザーのマシンで生成されたビルド出力はMCPの範囲外です。これは、ユーザーがデプロイがCLIでビルドされたと言った場合にのみ言及します。ローカルビルドの失敗については、元のCLI出力に誘導します。
7. 失敗したフェーズ、関連するタイムスタンプ、最小限の有用な証拠、推定される原因、および不確実性を報告します。生のログをそのまま繰り返さないでください。

実行中のアプリが失敗するのはなぜですか？

1. 正確な環境を解決し、get_runtime_logsを呼び出します。
2. 広いウィンドウを取得する前に、sinceとqで絞り込みます。結論が不在に依存する場合は、完全にページングします。
3. ランタイムログは、保持期間のために利用できない場合があります。空の結果は取得可能なログがないとして扱い、制限を報告します。
4. ランタイムの証拠を最新のデプロイメントレコードと関連付けることは有用ですが、タイミングだけから因果関係を主張しないでください。
5. 観察されたエラーパターン、影響を受けた期間、考えられる原因、証拠、および制限を報告します。

必要な設定は存在しますか？

1. 信頼できるソースから必要なキーセットを確立します：ユーザー提供のキーリスト、プロジェクト構成スキーマや文書化された要件、またはユーザーが完全として明示的に指定した参照環境。
2. ソースが値を含む保護されたファイルの場合、キーのみの抽出をローカルで決定論的に実行し、キー名のみを出力します。モデルが読み取り可能な方法でソースを開いたり、その値をチャットやツール出力に含めたりしないでください。
3. 必要なすべてのキーについて、ユーザー、プロジェクトスキーマや文書化された要件、または機密性に関して信頼できると明示的に指定された参照環境から、信頼できる機密性の指定を取得します。.envファイルやプレーンなキーリストは名前のみを確立します。キー名から機密性を推測しないでください。
4. 環境を解決し、list_variablesを呼び出し、そのキーと機密性メタデータを確立された要件と比較します。これは何が構成されているかを証明しますが、何が必要かを証明するものではありません。キーが欠落していると結論付ける前に、ページネーションを完了します。
5. キーとメタデータのみを報告します。シークレットエントリはisSecret: trueで値がありません。シークレット値の欠落は想定内です。
6. 必要なセットまたは機密性の指定が解決されない場合は、ユーザーが設定が不要であると明示的に確立しない限り、CLIの変更または依存するデプロイの前に停止します。
7. 欠落または誤分類されたキーの場合は、チャットで値を要求せずにwebflow-cli:cloudにルーティングします。書き込み後、list_variablesで必要なキーと機密性を確認します。部分的に失敗した場合は、値を含めずに失敗したキーを報告し、デプロイの前に停止します。成功したキーと環境は保持します。

この環境が間違ったブランチやルートを提供しているのはなぜですか？

1. 正確な環境を解決し、現在のブランチ、マウント、publicUrl、最新のデプロイステータスを報告します。nullのpublicUrlを報告します。アドレスを作成しないでください。
2. 現在のブランチとマウントを、ユーザーの意図したマッピングと比較します。リクエストが診断のみの場合は、不一致を報告した後に停止します。
3. 修正によってマウントが変更される場合は、get_appを呼び出し、siteAttachedを使用します。/はfalseの場合にのみ有効です。サイトアタッチアプリにはルート以外のマウントが必要です。siteIdからアタッチメントを推測しないでください。
4. 修正の場合は、変更前と変更後の正確なマッピングを表示します。update_environmentは即時であり、ドライランがなく、コードをデプロイしないことを説明します。
5. confirmを要求し、update_environmentを1回呼び出し、返された環境、publicUrl、mountRefreshStatusを報告します。
6. 結果が読み取れない、または不確かな場合は、元のenv_idを特定します。期待される新しいブランチをフィルターとして使用する場合、返された環境のIDが元のenv_idと等しい場合にのみ受け入れ、その後、そのブランチとマウントを要求された値と比較します。異なるID、または一意に一致する元のターゲットがない場合は、あいまいです。続行したり再試行したりしないでください。ブランチを変更する更新の後で、古いブランチフィルターを再利用しないでください。
7. マウントリフレッシュが失敗した、または不明であっても、環境の更新がロールバックされたことを意味しません。ルーティングが不確かであると報告し、リフレッシュが失敗したという理由だけで再試行しないでください。
8. ブランチが変更され、ユーザーがそのコードをデプロイしたい場合は、trigger_deploymentを個別にプレビューおよび確認された変更として扱います。

ブランチ用の分離された環境を作成してデプロイする

1. 既存のアプリを解決し、get_appを呼び出し、変更をプレビューする前にsiteAttachedで提案されたマウントを検証します。
2. list_environmentsをページングして、要求されたブランチまたはマウントがすでに使用されているかどうかを確認します。
3. 提案されたブランチとマウントを表示します。create_environmentは即時であり、ドライランがなく、コードをデプロイせずにマッピングを作成することを説明します。
4. 1つの安定したidempotency_keyを生成し、confirmを要求し、create_environmentを呼び出します。そのキーを正確な再試行にのみ再利用します。
5. 返された環境、publicUrl、mountRefreshStatusを報告します。結果が不確かな場合は、予想されるブランチを検索し、環境ID、ブランチ、マウントを比較します。返されたIDを使用して同時作成を区別します。作成された環境があいまいな間は再試行しないでください。
6. リフレッシュが失敗した場合は、作成は成功したがルーティングが不完全である可能性があることを意味します。作成を再試行したり、環境を自動的に削除したりしないでください。
7. この新しい環境をデプロイする前に、「必要な設定は存在しますか？」を必須のゲートとして実行します。要件と機密性が確認されるか、ユーザーが不要であると明示的に確立した場合にのみ続行します。次に、プレビュー、確認、属性、監視のために以下のデプロイワークフローを使用します。

このデプロイは再試行、ロールバック、またはブランチHEADから再構築できますか？

変更のデフォルトのドライランを機能チェックとして使用します。欠落したログ、アプリメタデータ、またはデプロイメタデータから適格性を推測しないでください。

接続されたブランチまたは以前の正確なコミットからの新しいデプロイの場合：

1. 環境を解決します。再試行またはロールバックの場合は、正確な以前のデプロイも解決します。
2. 構成の検出は、ユーザーが要求した場合、デプロイの証拠が欠落または誤分類された変数を示している場合、選択したコミットに文書化された構成要件がある場合、またはサーバーが構成のためにデプロイを拒否した場合にのみ実行します。