webflow/webflow-skills

Applications Webflow Cloud

Utilisez data_apps_tool pour créer des applications à partir de GitHub, répondre à des questions opérationnelles et gérer les environnements des applications Webflow Cloud. Partez du résultat souhaité par l'utilisateur, rassemblez uniquement les preuves nécessaires et distinguez les observations des conclusions.

Utilisez la compétence webflow-cli:cloud lorsque la tâche nécessite la création ou le déploiement d'une application via CLI/source locale, ou la création ou la mise à jour de variables d'environnement. La sortie de build côté client n'est pas envoyée à Webflow et ne peut pas être récupérée via MCP.

Instructions

1. Établir la portée

Utilisez la connexion MCP Webflow établie par la demande de l'utilisateur ou le contexte de la tâche existante. Si une seule connexion est active, utilisez-la sans demander à l'utilisateur de choisir ou de reconfirmer une région. Si plusieurs connexions sont actives et que la cible prévue reste ambiguë, demandez à l'utilisateur de lever l'ambiguïté avant de procéder à des opérations dépendantes de la cible. Ne changez pas de région pour récupérer des ressources manquantes ou des erreurs d'accès.

Avant de confier une application ou un environnement MCP existant à la CLI pour des écritures de configuration ou un déploiement, comparez leurs régions configurées. Si elles diffèrent, ne supposez pas que l'une ou l'autre est correcte et ne reciblez pas silencieusement l'un des outils. Résolvez la cible prévue à partir du contexte explicite de la tâche ; si cela ne résout pas le conflit, demandez à l'utilisateur. Mettez en pause les mutations dépendantes jusqu'à ce que le conflit soit résolu.

Une fois la région prévue établie, vérifiez que la CLI peut lire les ID exacts de l'application et de l'environnement MCP, et transportez cette région et ces ID explicitement dans les mutations suivantes. L'état de connexion ou une étiquette de région seul est insuffisant. Si la vérification échoue, signalez l'échec sans en déduire la cause et mettez en pause les mutations dépendantes. Continuez le travail indépendant dont la cible est établie.

1. Appelez webflow_guide_tool avant tout autre outil MCP Webflow. Le guide en direct et les schémas d'action sont faisant autorité pour les arguments et réponses actuels.
2. Utilisez les outils MCP Webflow pour les opérations Webflow, à l'exception du transfert explicite vers la CLI pour les valeurs de variables d'environnement. N'appelez jamais directement les API Webflow.
3. Incluez le paramètre context requis dans chaque appel d'outil. Écrivez 15 à 25 mots en perspective à la troisième personne.
4. Acheminez en fonction de la capacité requise par la tâche :
   • Utilisez data_apps_tool pour créer des applications à partir de GitHub ; inspecter les applications, les environnements, les domaines, les enregistrements de déploiement, les journaux et les métadonnées de variables ; gérer les sources GitHub et les environnements ; et mettre en file d'attente les déploiements GitHub.
   • Utilisez data_variable_tool pour les variables de couleur, de taille, de police et CSS du Designer.
   • Utilisez webflow-cli:cloud pour les applications CLI/source locale, les builds et déploiements locaux, ou la création et la mise à jour de valeurs de variables d'environnement.
5. Si data_apps_tool n'est pas disponible, signalez que la capacité Cloud Apps MCP n'est pas activée. Ne la contournez pas avec une demande d'API directe.

Ne demandez jamais à l'utilisateur de coller une valeur de variable d'environnement ou un secret dans le chat. Pour une création ou une mise à jour, déléguez à webflow-cli:cloud et exigez une invite cachée, stdin ou un fichier protégé. Ne passez jamais un secret comme argument positionnel.

2. Résoudre la cible

Découvrez les identifiants dans cet ordre :

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

Les noms d'application sont uniques uniquement dans un site, résolvez donc une application nommée avec site_id + name. Si plusieurs ressources correspondent, présentez les métadonnées de distinction et demandez à l'utilisateur d'en sélectionner une avant toute mutation. Utilisez le guide en direct pour les mécanismes de filtre, pagination, curseur et traitement par lots d'actions.

3. Suivre le scénario utilisateur correspondant

Créer une application à partir de GitHub

1. Établissez le nom de l'application, l'URL du dépôt GitHub canonique, la branche, la description facultative, et si elle est autonome ou attachée à un site existant.
2. Pour une application attachée à un site, résolvez l'ID du site. Omettez site_id pour une application autonome.
3. Appliquez le contrat de montage avant la prévisualisation :
   • Une application autonome se monte toujours à / ; omettez mount ou utilisez /.
   • Une application attachée à un site a par défaut /app, rejette /, et nécessite un montage non racine valide lors du remplacement du défaut.
4. Expliquez que la création autonome nécessite un jeton utilisateur à portée d'espace de travail. Webflow dérive l'installation GitHub et valide l'accès au dépôt ; ne demandez pas d'ID d'installation.
5. Appelez create_app avec son exécution à sec par défaut. Montrez le dépôt, la branche, l'attachement, le site le cas échéant, le montage et la tentative de déploiement initial.
6. Exigez confirm. Immédiatement après la confirmation et avant l'exécution, enregistrez l'heure de début et générez une idempotency_key stable ; exécutez avec dry_run: false, puis enregistrez l'heure de fin. Réutilisez cette clé uniquement pour des relances exactes de cette création.
7. Traitez la création et le déploiement initial comme des résultats séparés. Une application renvoyée signifie que la création a réussi même si deployStatus est skipped ou failed. Pour triggered, inspectez l'environnement et le déploiement ; pour skipped, vérifiez la branche ou poussez un commit ; pour failed, conservez l'application et inspectez ou relancez le déploiement séparément.
8. Si l'application ou le résultat est illisible, réconciliez avant de réessayer :
   • Pour une application attachée à un site, collectez les candidats avec site_id + name ; pour une application autonome, collectez les candidats par nom.
   • Dans les deux cas, comparez le nom, sourceUrl et createdAt de chaque candidat avec le dépôt demandé et la fenêtre d'exécution enregistrée.
   • Continuez vers les environnements et les déploiements uniquement lorsqu'exactement un candidat correspond. Ne réessayez pas tant que l'application créée reste ambiguë.
9. Ne supprimez jamais automatiquement une application créée parce que le déploiement a échoué. Ne traitez pas un lien de tableau de bord de déploiement initial comme l'URL publique de l'environnement.

Quelle application et quel environnement suis-je en train de consulter ?

1. Utilisez list_apps pour trouver l'application et get_app pour ses métadonnées, y compris sourceUrl et siteAttached.
2. Utilisez list_environments pour signaler la branche, le montage, publicUrl et le dernier état de déploiement. Si publicUrl est nul, signalez qu'aucune adresse d'environnement accessible à l'utilisateur n'est disponible ; n'en construisez pas une.
3. Utilisez get_app_domains lorsque l'utilisateur demande où l'application est accessible.
4. Expliquez que les résultats de domaine personnalisé excluent le nom d'hôte par défaut *.webflow.io. Les domaines pour une application attachée à un site Webflow classique peuvent appartenir au site parent et être partagés par des applications sœurs.

Qu'est-ce qui est déployé, et est-ce sain ?

1. Utilisez list_environments pour le dernier état de déploiement de l'environnement.
2. Utilisez list_deployments, du plus récent au plus ancien, puis get_deployment pour la chronologie détaillée du déploiement sélectionné et les métadonnées de version.
3. Traitez starting, building et deploying comme des états actifs. Signalez tout autre état exactement plutôt que de deviner sa signification.
4. Une phase échouée définit buildFailedAt ou deployFailedAt tandis que son horodatage de fin correspondant reste nul. Un horodatage de fin nul en soi ne prouve pas que la phase est toujours en cours d'exécution.
5. Signalez ce qui est observable : application et environnement sélectionnés, état de déploiement, version ou métadonnées de commit si renvoyées, horodatages des phases et lacunes de preuve.

Pourquoi le déploiement a-t-il échoué ?

1. Récupérez le déploiement avec get_deployment et identifiez la phase échouée à partir de son état et de ses horodatages.
2. Appelez get_build_logs uniquement lorsque logsAvailable est vrai. Commencez avec une fenêtre since ou un filtre q étroit, puis élargissez uniquement si nécessaire.
3. Paginez jusqu'à ce que nextCursor soit nul lorsqu'un résultat complet est requis.
4. Traitez logsAvailable comme un signal de rétention et de récupération, pas comme une preuve que chaque phase a produit des entrées de journal.
5. Traitez un résultat vide comme « aucun journal récupérable côté serveur correspondant », pas comme une preuve que la construction a réussi ou n'a produit aucune erreur.
6. La sortie de build produite sur une machine d'utilisateur est en dehors de MCP. Mentionnez cela uniquement lorsque l'utilisateur indique que le déploiement a été construit avec la CLI ; dirigez-le vers la sortie CLI d'origine pour les échecs de build locaux.
7. Signalez la phase échouée, les horodatages pertinents, les plus petites preuves utiles, la cause déduite et toute incertitude. Ne vous contentez pas de reformuler les journaux bruts.

Pourquoi l'application en cours d'exécution échoue-t-elle ?

1. Résolvez l'environnement exact et appelez get_runtime_logs.
2. Réduisez par since et q avant de récupérer une large fenêtre. Paginez complètement lorsque la conclusion dépend de l'absence.
3. Les journaux d'exécution peuvent être indisponibles en raison de la rétention. Traitez un résultat vide comme aucun journal récupérable et signalez la limitation.
4. Corrélez les preuves d'exécution avec le dernier enregistrement de déploiement lorsque cela est utile, mais ne prétendez pas à la causalité à partir du seul moment.
5. Signalez le motif d'erreur observé, l'intervalle affecté, la cause probable, les preuves et les limitations.

La configuration requise est-elle présente ?

1. Établissez l'ensemble de clés requis à partir d'une source faisant autorité : une liste de clés fournie par l'utilisateur, un schéma de configuration de projet ou une exigence documentée, ou un environnement de référence que l'utilisateur désigne explicitement comme complet.
2. Si la source est un fichier protégé contenant des valeurs, effectuez une extraction locale déterministe des clés uniquement et émettez uniquement les noms de clés. N'ouvrez jamais la source via une lecture visible par le modèle et n'incluez pas ses valeurs dans le chat ou la sortie de l'outil.
3. Obtenez une désignation de secret faisant autorité pour chaque clé requise auprès de l'utilisateur, d'un schéma de projet ou d'une exigence documentée, ou d'un environnement de référence explicitement désigné comme faisant autorité pour le secret. Un fichier .env ou une liste de clés en clair établit uniquement les noms ; ne déduisez jamais le secret des noms de clés.
4. Résolvez l'environnement, appelez list_variables et comparez ses clés et métadonnées de secret avec les exigences établies. Cela prouve ce qui est configuré, pas ce qui est requis. Épuisez la pagination avant de conclure qu'une clé est manquante.
5. Signalez uniquement les clés et les métadonnées. Les entrées secrètes ont isSecret: true et aucune valeur ; une valeur secrète manquante est attendue.
6. Si l'ensemble requis ou une désignation de secret n'est pas résolu, arrêtez-vous avant une mutation CLI ou un déploiement dépendant, à moins que l'utilisateur n'établisse explicitement qu'aucune configuration n'est requise.
7. Pour les clés manquantes ou mal classifiées, acheminez vers webflow-cli:cloud sans demander de valeurs dans le chat. Après l'écriture, vérifiez les clés requises et le secret avec list_variables. Si cela échoue partiellement, signalez les clés échouées sans valeurs et arrêtez-vous avant le déploiement ; conservez les clés réussies et l'environnement.

Pourquoi cet environnement sert-il la mauvaise branche ou la mauvaise route ?

1. Résolvez l'environnement exact et signalez sa branche actuelle, son montage, publicUrl et le dernier état de déploiement. Signalez un publicUrl nul sans construire d'adresse.
2. Comparez la branche et le montage actuels avec le mappage prévu par l'utilisateur. Si la demande est uniquement diagnostique, arrêtez-vous après avoir signaler la discordance.
3. Si la correction modifie le montage, appelez get_app et utilisez siteAttached : / est valide uniquement lorsqu'il est faux ; une application attachée à un site nécessite un montage non racine. Ne déduisez pas l'attachement de siteId.
4. Pour une correction, montrez le mappage exact avant et après. Expliquez que update_environment est immédiat, n'a pas d'exécution à sec et ne déploie pas de code.
5. Exigez confirm, appelez update_environment une fois et signalez l'environnement renvoyé, publicUrl et mountRefreshStatus.
6. Pour un résultat illisible ou incertain, localisez l'env_id d'origine. Si vous utilisez la nouvelle branche prévue comme filtre, acceptez un environnement renvoyé uniquement lorsque son ID est égal à cet env_id d'origine, puis comparez sa branche et son montage avec les valeurs demandées. Un ID différent ou aucune cible d'origine unique correspondante est ambigu : ne continuez pas et ne réessayez pas. Ne réutilisez jamais l'ancien filtre de branche après une mise à jour changeant de branche.
7. Un rafraîchissement de montage échoué ou inconnu ne signifie pas que la mise à jour de l'environnement a été annulée. Signalez le routage comme incertain et ne réessayez pas uniquement parce que le rafraîchissement a échoué.
8. Si la branche a changé et que l'utilisateur souhaite que son code soit déployé, traitez trigger_deployment comme une mutation distincte prévisualisée et confirmée.

Créer un environnement isolé pour une branche et le déployer

1. Résolvez l'application existante, appelez get_app et validez le montage proposé avec siteAttached avant de prévisualiser la mutation.
2. Parcourez list_environments pour vérifier si la branche ou le montage demandé est déjà utilisé.
3. Montrez la branche et le montage proposés. Expliquez que create_environment est immédiat, n'a pas d'exécution à sec et crée un mappage sans déployer de code.
4. Générez une idempotency_key stable, exigez confirm et appelez create_environment. Réutilisez cette clé uniquement pour des relances exactes.
5. Signalez l'environnement renvoyé, publicUrl et mountRefreshStatus. Si le résultat est incertain, recherchez la branche prévue et comparez l'ID de l'environnement, la branche et le montage ; utilisez un ID renvoyé pour distinguer les créations simultanées. Ne réessayez pas tant que l'environnement créé reste ambigu.
6. Un rafraîchissement échoué signifie que la création a réussi mais que le routage peut être incomplet. Ne réessayez pas la création et ne supprimez pas l'environnement automatiquement.
7. Avant de déployer ce nouvel environnement, suivez « La configuration requise est-elle présente ? » comme une porte obligatoire. Continuez uniquement après que les exigences et le secret sont vérifiés, ou que l'utilisateur établit explicitement qu'aucun n'est requis. Ensuite, utilisez le flux de travail de déploiement ci-dessous pour la prévisualisation, la confirmation, l'attribution et la surveillance.

Ce déploiement peut-il être relancé, annulé ou reconstruit à partir de la tête de branche ?

Utilisez l'exécution à sec par défaut de la mutation comme vérification de capacité. Ne déduisez pas l'éligibilité à partir de journaux manquants, de métadonnées d'application ou de métadonnées de déploiement.

Pour un nouveau déploiement à partir de la branche connectée ou d'un commit exact antérieur :

1. Résolvez l'environnement. Pour une relance ou un rollback, résolvez également le déploiement antérieur exact.
2. Effectuez la découverte de configuration uniquement lorsque l'utilisateur la demande, les preuves de déploiement indiquent des variables manquantes ou mal classifiées, le commit sélectionné a des exigences de configuration documentées, ou le serveur rejette le déploiement pour une raison de configuration.