Que sont les workflows Antigravity ?
Les workflows Antigravity sont des façons répétables de passer d’un objectif de développement à un résultat contrôlé. Un workflow peut utiliser l’éditeur, le terminal, le navigateur, un Skill, un serveur MCP ou plusieurs surfaces ensemble. Ce n’est pas seulement un prompt : il comprend l’état de départ, les actions autorisées, les pauses et les preuves qui montrent que la tâche est terminée.
Les meilleurs workflows Antigravity sont assez étroits pour être testés. « Améliore ce projet » n’a pas de ligne d’arrivée. « Lis le test en échec, modifie seulement le parseur, lance le test ciblé, montre le diff et arrête-toi avant le commit » produit une sortie claire et un arrêt sûr. Utilisez les guides CLI, Skills et MCP pour les détails propres à chaque surface.
Préparer l’espace de travail avant un workflow
Ouvrez le dépôt, confirmez la branche et vérifiez les fichiers concernés. Exécutez une fois la commande prévue pour connaître son nom, son code de sortie et son environnement. Pour navigateur ou MCP, commencez par une lecture.
Décrivez clairement entrée et sortie : cible, outils, limites et décision humaine. Gardez mots de passe, tokens et données privées hors des prompts et journaux. Utilisez une branche de test au premier essai.
| Surface | Premier usage | À vérifier avant d’élargir |
|---|---|---|
| Éditeur | Lire -> planifier -> modifier -> inspecter le diff | Confirmez les fichiers cibles et gardez le premier patch réduit. |
| Terminal | Lancer une commande connue et conserver le résultat | Vérifiez PATH, politique du shell, code de sortie et portée d’écriture. |
| Navigateur / MCP | Lire une donnée publique ou tester un endpoint | Confirmez domaine, compte, délai et arrêt manuel. |
- 1. Figer le départNotez dépôt, branche, version et fichiers ou comptes que le workflow peut toucher.
- 2. Choisir une sortieSélectionnez un artefact, résultat de test, état de page ou rapport pour rendre l’échec visible.
- 3. Répéter en lecture seuleInspectez et expliquez le chemin avant d’éditer, d’envoyer des données ou de modifier un compte.
- 4. Ajouter un point de contrôleFaites une pause avant dépendance, écriture réseau, publication, suppression ou déploiement.
Cette page ne promet ni format de fichier fixe ni option permanente. Vérifiez la documentation officielle avant d’automatiser une nouvelle intégration.
Prompts et commandes utiles pour les workflows Antigravity
Un prompt précise rôle, contexte, actions permises et preuves. Par exemple : « Inspecte X, planifie le changement minimal, modifie seulement Y, lance Z, montre le résultat et arrête-toi avant W ». Demandez le nom exact du moyen utilisé.
Séparez commande interactive et commande shell. Aide CLI, session, test terminal et appel MCP ont des portées différentes. Nommez la surface pour rendre le workflow reproductible.
inspecter -> planifier -> confirmerTravailler en trois temps
Exigez inspection et plan court avant l’édition, puis confirmez la liste de fichiers.
lancer un contrôle cibléValider étroitement
Exécutez le test, l’aperçu ou la vérification d’URL la plus petite qui puisse réfuter le changement.
afficher diff et statutRendre les changements visibles
Retournez fichiers modifiés, résumé du diff, code de sortie et sorties générées.
s’arrêter pour approbationCréer un arrêt humain
Mettez en pause avant publication, déploiement, suppression, installation ou changement de compte.
réessayer une fois avec preuveBorner les reprises
Conservez le timeout et ne réessayez qu’avec une hypothèse explicitement différente.
retourner le chemin de l’artefactPointer vers la sortie
Un rapport, une capture, un log ou une page construite rend le contrôle reproductible.
Portée, permissions et réglages du workflow
La sécurité vient surtout de la portée. Gardez les commandes près du dépôt, les préférences séparées et les permissions explicites. Lire n’est pas écrire, tester n’est pas installer, vérifier une page ne modifie pas un compte.
Un Skill testé doit préciser prérequis, entrées, sorties, erreurs et vérification. Ne cachez pas commande shell large ni écriture réseau derrière un nom rassurant.
workflow:
goal: "mettre à jour un parseur et prouver le test ciblé"
allowed: [read_files, edit_target, run_focused_test]
review_before: [install_package, network_write, delete, publish]
output: [diff_summary, test_result, remaining_risks]- Portée du projet — Utilisez les règles du dépôt afin que commandes et limites de fichiers soient reproductibles.
- Portée utilisateur — Gardez préférences personnelles de modèle, terminal et affichage hors du comportement partagé.
- Portée outil — Nommez le serveur MCP, le domaine navigateur ou la commande exacte plutôt qu’un joker.
- Portée de revue — Listez les actions qui exigent toujours une personne, même après des étapes automatiques.
Un workflow Antigravity répétable en cinq passes
La première passe découvre : lisez fichiers ou tests et reformulez le but. La deuxième planifie le changement minimal et nomme les outils. Arrêtez-vous si le plan comprend mal la demande.
La troisième exécute ; la quatrième compare un contrôle ciblé à la règle d’acceptation ; la cinquième rapporte chemins, preuves, risques et prochaine décision. La méthode convient au contenu, à CLI, au navigateur et à MCP.
Découvrir
Lisez le contexte et énoncez but, contraintes et inconnues.
Planifier et exécuter
Validez une petite liste d’actions puis utilisez seulement outils et fichiers nommés.
Vérifier et transmettre
Contrôlez la sortie, consignez preuves et risques, puis arrêtez-vous avant la prochaine décision sensible.
Garder les workflows à jour quand Antigravity change
Les produits d’agents évoluent. Une commande, une permission, un modèle ou une sortie d’intégration peut changer après une mise à jour. Revoyez un workflow après une modification d’Antigravity, du modèle, du shell ou d’un serveur MCP ; une réussite le mois dernier ne prouve pas la sécurité aujourd’hui.
Notez la date, le build ou la page documentaire consultée et l’étape vérifiée. Si le comportement actuel est incertain, gardez le workflow en lecture seule ou manuel jusqu’à résolution.
Règles de sécurité des workflows Antigravity
Traitez le workflow comme un document de permissions. Avant de le partager, vérifiez fichiers lisibles, commandes, domaines externes et effets secondaires possibles.
Examinez arguments, répertoire, réseau, scripts, variables et chemins de suppression ou publication. Gardez les secrets hors des prompts, utilisez un compte de test et révoquez les permissions ensuite.
- Ne mettez jamais mots de passe, clés API, codes de récupération ou données client dans le texte et les preuves.
- Vérifiez manuellement installations, téléchargements, webhooks et messages externes.
- Utilisez un profil navigateur ou un compte de test pour les parcours authentifiés.
- Laissez les opérations destructrices de fichiers et Git hors du chemin automatique.
- Partagez prérequis et plan de retour avec la personne qui exécutera le workflow.
Dépanner un workflow qui échoue
Réduisez l’échec à la plus petite passe. Comparez état initial, appel, sortie et règle d’acceptation avant de changer les permissions.
L’agent propose un autre plan
Reformulez fichier cible, sortie et condition d’arrêt. Demandez un plan seul, puis corrigez la limite.
Commande introuvable
Lancez-la dans un terminal normal, vérifiez PATH et politique du shell et notez la version installée.
Données partielles
Sauvegardez la réponse, marquez les champs manquants et arrêtez-vous. Ne réessayez que si l’erreur transitoire est certaine.
Résultat plausible mais faux
Comparez URL, chemin, test ou état final à la règle d’acceptation. Une sortie ancienne ou partielle est un échec.
Les demandes de permission reviennent
Vérifiez changement de commande, chemin, compte ou outil. Resserrez la règle plutôt que d’accorder un joker.
FAQ sur les workflows Antigravity
Que sont les workflows Antigravity ?
Ce sont des séquences répétables qui relient un objectif de développement borné à un résultat vérifié. Elles définissent contexte, outils autorisés, contrôles, sortie et règle d’arrêt ou de retour.
Comment créer des workflows Antigravity sûrs ?
Commencez par un dépôt et une sortie. Écrivez but, cible, actions autorisées, points de revue manuelle et test d’acceptation. Répétez en lecture seule, autorisez la plus petite modification et inspectez le résultat.
Faut-il utiliser Skill, CLI ou MCP ?
Choisissez Skill pour des instructions et contrôles réutilisables, CLI comme entrée de terminal et MCP pour un outil ou une source externe nommée. Une combinaison reste possible si chaque surface garde son rôle.
Un workflow Antigravity peut-il exécuter des commandes automatiquement ?
Oui lorsque les réglages et permissions actuels le permettent. Limitez l’automatisation aux commandes connues et vérifiez manuellement arguments, réseau, installations, suppressions, publications et comptes.
Comment tester un workflow avant de le partager ?
Lancez-le dans un dossier jetable ou une branche de test propre. Confirmez prérequis, commandes et appels, contrôlez la sortie et essayez un cas d’échec avant de transmettre le plan de retour.
Pourquoi un workflow s’est-il arrêté après une mise à jour ?
Une mise à jour peut modifier noms de commandes, permissions, accès modèle, emplacement d’interface ou sortie d’intégration. Revoyez documentation officielle, build installé et plus petite étape de lecture.
Quelles preuves un workflow doit-il retourner ?
Retournez chemins modifiés ou URL finale, état de l’outil, résultat du test ciblé et risques ouverts. Ne retournez jamais mots de passe, tokens, données privées ou transcription non expurgée.
Sources Antigravity officielles et associées
- Page produit Google Antigravity 2.0 — Contexte officiel et terminologie.
- Page produit Google Antigravity CLI — Référence officielle de la surface CLI.
- Guide Antigravity Skills — Transformer une procédure testée en Skill réutilisable.
- Guide de sécurité Auto Accept — Examiner limites de commandes et permissions.