Cadrer un agent avec des instructions a une limite : on lui dit quoi faire, pas comment faire une chose qu’il ne sait pas encore faire. Pour étendre réellement les capacités d’un agent Antigravity, deux mécanismes existent : les Skills, qui lui ajoutent du savoir-faire spécialisé chargé seulement quand c’est utile, et les serveurs MCP, qui lui ouvrent de nouveaux outils. Ce tutoriel vous fait créer votre première Skill pour l’application Suivi, puis brancher un serveur MCP.
🎯 Ce que vous allez apprendre
- Comprendre ce qu’est une Skill et le principe de divulgation progressive.
- Écrire un fichier
SKILL.mdbien décrit pour qu’il se déclenche au bon moment. - Organiser une Skill avec ses scripts et ses références.
- Brancher un serveur MCP pour donner un nouvel outil à l’agent.
🛠️ Ce que vous allez construire
Nous capitalisons sur tout le travail fait sur Suivi. Vous allez empaqueter notre manière d’ajouter une route d’API dans une Skill réutilisable, baptisée « convention-api-suivi », pour que l’agent l’applique automatiquement dès qu’il touche à l’API. Puis vous connecterez un serveur MCP de système de fichiers, afin que l’agent puisse explorer un dossier de documentation de façon structurée. À la fin, votre agent sera plus compétent et mieux outillé, sans que son contexte soit alourdi en permanence.
Prérequis
- L’application Suivi et un
AGENTS.mden place — voir Cadrer un agent : AGENTS.md, Rules et Workflows. - Antigravity connecté ; notions de JSON.
- Niveau : intermédiaire débutant.
- ⏱️ Temps estimé : ~40 minutes.
Étape 1 — Saisir le principe d’une Skill
Le problème que résolvent les Skills est celui de la surcharge. Si vous donniez à l’agent, en permanence, toutes les procédures qu’il pourrait un jour avoir besoin de connaître, son contexte exploserait et sa précision chuterait. Une Skill renverse cette logique : c’est un paquet de connaissances spécialisé qui reste dormant jusqu’au moment où votre demande correspond à sa description. C’est ce qu’on appelle la divulgation progressive : le savoir n’est chargé dans le contexte de l’agent que lorsqu’il devient pertinent.
Concrètement, chaque Skill possède une description courte. Lorsque votre requête correspond à cette description, Antigravity charge la Skill et son savoir-faire devient disponible ; sinon, elle reste de côté. Le bénéfice est double : l’agent dispose potentiellement de dizaines de compétences pointues, mais n’en mobilise que ce dont il a besoin à l’instant T. On évite ainsi l’écueil du « tout charger en permanence », qui dilue l’attention du modèle et fait baisser la qualité des réponses.
Une Skill se matérialise par un dossier contenant au minimum un fichier SKILL.md. Ce dossier peut vivre au niveau du projet, dans le sous-dossier des skills de la configuration du dépôt, ou au niveau global de votre machine pour être disponible partout. Pour Suivi, nous restons au niveau du projet : la compétence est spécifique à cette application.
Pour bien mesurer l’intérêt, comparons avec ce que nous savons déjà faire. Au tutoriel précédent, nous avons appris à cadrer l’agent avec un AGENTS.md et des règles. Mais ces instructions sont lues à chaque tâche : on ne peut pas y entasser le mode d’emploi de tout ce que le projet pourrait un jour demander, sous peine de saturer le contexte. Les Skills résolvent exactement ce dilemme. Elles permettent d’accumuler un grand nombre de procédures spécialisées, chacune endormie par défaut, et de n’en réveiller qu’une poignée selon la tâche du moment. C’est la différence entre garder en permanence toute une bibliothèque ouverte sur son bureau et savoir aller chercher le bon livre quand on en a besoin.
Étape 2 — Écrire le fichier SKILL.md
Le cœur d’une Skill est son SKILL.md. Il commence par un en-tête de métadonnées dont le champ réellement essentiel est description : c’est le seul à être obligatoire. La description est l’élément le plus important de tout le fichier, car c’est elle qui déclenche — ou non — le chargement de la Skill ; Antigravity compare sémantiquement votre demande à cette description pour décider de la charger. Une description vague ne se déclenchera jamais au bon moment. Le champ name, lui, est optionnel : s’il est omis, il prend par défaut le nom du dossier. Quand vous le précisez, gardez-le en minuscules, avec des traits d’union, et unique dans son périmètre — le faire coïncider avec le nom du dossier reste une bonne habitude de lisibilité.
---
name: convention-api-suivi
description: A utiliser pour ajouter ou modifier une route de l'API
Express du projet Suivi. Decrit la structure attendue d'une route,
la gestion des erreurs et le format des reponses JSON.
---
# Convention d'ajout d'une route a l'API Suivi
Quand on ajoute une route a l'API Suivi, suivre cette procedure :
1. Declarer la route dans server.js, groupee avec les routes /tasks.
2. Valider les entrees : si un champ obligatoire manque, renvoyer 400
avec un corps { erreur: "message" }.
3. Si la route cible une tache par identifiant et qu'elle est
introuvable, renvoyer 404 avec { erreur: "tache introuvable" }.
4. Toujours repondre en JSON.
5. Proposer une commande curl de verification de la nouvelle route.
Enregistrez ce fichier dans un dossier convention-api-suivi au sein du sous-dossier des skills du projet. Notez à quel point la description est explicite sur le quand : « à utiliser pour ajouter ou modifier une route de l’API Express du projet Suivi ». C’est cette phrase qui permettra à Antigravity de réveiller la Skill au bon moment.
✅ Point d’étape — Lancez un agent avec « Ajoute une route pour compter les tâches en cours ». Si la Skill est bien décrite, l’agent doit charger votre procédure et l’appliquer : validation, format JSON, gestion d’erreur et commande de test. Vous pouvez souvent voir, dans le fil ou les livrables, qu’une compétence a été activée.
Étape 3 — Structurer une Skill plus riche
Une Skill ne se limite pas à un fichier de texte. Le dossier peut accueillir des éléments complémentaires qui lui donnent de la profondeur. Un sous-dossier scripts/ peut contenir des exécutables (par exemple un petit script Python ou Bash) que l’agent lance au besoin ; un sous-dossier references/ regroupe documentation et modèles ; un sous-dossier assets/ stocke des ressources comme des images ou des gabarits.
L’intérêt de cette structure est que tout ce contenu reste, lui aussi, soumis à la divulgation progressive : il n’est consulté que lorsque la Skill est active et que l’agent en a besoin. Vous pouvez donc constituer une compétence très complète — une procédure, des scripts utilitaires, des exemples de référence — sans craindre d’alourdir chaque conversation. Pour Suivi, vous pourriez par exemple ajouter dans references/ un exemple complet de route bien écrite, que l’agent prendra comme modèle. La Skill devient alors un véritable petit manuel opérationnel, activé à la demande.
Étape 4 — Comprendre les serveurs MCP
Les Skills ajoutent du savoir ; les serveurs MCP ajoutent du pouvoir d’agir. MCP, pour Model Context Protocol, est un standard ouvert qui permet de connecter un agent à des outils externes via un petit serveur dédié. Un serveur MCP expose des outils — lire des fichiers d’un dossier, interroger une base, appeler une API — que l’agent peut alors utiliser comme s’ils faisaient partie de ses capacités natives.
L’image utile est celle d’une prise universelle. Plutôt que d’intégrer en dur chaque outil possible, Antigravity sait parler le protocole MCP, et n’importe quel serveur compatible peut s’y brancher. Cela ouvre un écosystème : serveurs de système de fichiers, serveurs de recherche documentaire, serveurs reliés à vos propres services. Pour notre exemple, nous brancherons un serveur de système de fichiers, qui donne à l’agent une vue structurée d’un dossier de documentation.
On confond souvent Skills et MCP au début, alors que les deux sont complémentaires et de nature différente. Une Skill enrichit la connaissance de l’agent : elle lui dit comment faire, avec quelles conventions, en s’appuyant sur du texte et éventuellement des scripts. Un serveur MCP, lui, branche un outil concret que l’agent actionne pour interagir avec le monde extérieur. Une bonne façon de retenir la nuance : la Skill répond à « comment dois-je m’y prendre ? », le serveur MCP à « avec quoi puis-je agir ? ». Sur un projet mature, les deux cohabitent : des Skills qui encodent vos méthodes, et des serveurs MCP qui relient l’agent à vos données et services.
Étape 5 — Brancher un serveur MCP
La configuration d’un serveur MCP se fait en déclarant comment le lancer. Antigravity propose une interface de gestion des serveurs MCP dans ses réglages ; en coulisses, chaque serveur est décrit par une commande de démarrage et ses paramètres. Voici à quoi ressemble une déclaration type pour un serveur de système de fichiers limité à un dossier de documentation :
{
"mcpServers": {
"docs-suivi": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "./docs"]
}
}
}
Cette déclaration indique à Antigravity de lancer, via npx, un serveur de système de fichiers borné au dossier ./docs du projet. Une fois le serveur enregistré et démarré, l’agent dispose d’outils pour lister et lire les fichiers de ce dossier de façon fiable. Vous pouvez alors lui demander, par exemple, « Résume les décisions techniques consignées dans la documentation du projet », et il utilisera l’outil MCP pour parcourir le dossier au lieu de deviner.
✅ Point d’étape — Après avoir ajouté et démarré le serveur, vérifiez dans les réglages MCP qu’il apparaît comme actif. Lancez ensuite une tâche qui nécessite de lire la documentation : dans le fil de l’agent, vous devez voir l’appel à l’outil du serveur
docs-suivi, preuve que la connexion fonctionne.
Un mot de prudence indispensable : un serveur MCP étend ce que l’agent peut atteindre. Ne branchez que des serveurs dont vous comprenez la portée, bornez-les au strict nécessaire — ici, un seul dossier — et appliquez la même logique de moindre privilège que pour les permissions. Un outil puissant relié à un agent autonome mérite la même attention qu’une clé que l’on confie.
Ce branchement a une conséquence très concrète sur la fiabilité. Sans outil de système de fichiers, un agent à qui l’on demande de s’appuyer sur une documentation peut être tenté de deviner ou d’inventer son contenu. Avec un serveur MCP borné à un dossier précis, il lit réellement les fichiers, ce qui ancre ses réponses dans des faits vérifiables. C’est un gain de justesse autant que de confiance : vous savez que l’agent travaille sur la vraie documentation, pas sur une reconstruction approximative. Cette idée — donner à l’agent un accès fiable plutôt que de le laisser improviser — est l’un des grands principes du travail agentique sérieux.
🐞 Pièges fréquents
| Symptôme | Cause probable | Correctif |
|---|---|---|
| La Skill ne se déclenche jamais | Description trop vague ou hors sujet | Réécrire la description en précisant le « quand » et les mots-clés du contexte |
| La Skill n’est pas trouvée | Dossier placé hors du répertoire des skills reconnu | Vérifier l’emplacement (.agents/skills/ du projet) puis relancer l’agent |
| Le serveur MCP ne démarre pas | Commande introuvable ou paramètres erronés | Vérifier que npx fonctionne et que le chemin du dossier existe |
| L’agent n’utilise pas l’outil MCP | Serveur non démarré ou tâche ne le nécessitant pas | Confirmer l’état « actif » et formuler une demande qui appelle clairement l’outil |
✅ Récapitulatif
Vous savez désormais étendre un agent dans ses deux dimensions. Les Skills lui ajoutent du savoir-faire ciblé, chargé par divulgation progressive grâce à une description précise et à un SKILL.md bien rédigé, éventuellement enrichi de scripts et de références. Les serveurs MCP lui ajoutent des outils, en branchant des capacités externes via un protocole standard. Ensemble, ils transforment un agent généraliste en assistant taillé pour votre projet — tout en gardant le contexte léger et les droits sous contrôle.
🧾 Aide-mémoire
| Élément | Rôle |
|---|---|
SKILL.md |
Métadonnées (name, description) + procédure |
| Divulgation progressive | La Skill se charge quand la demande correspond à sa description |
scripts/, references/, assets/ |
Contenu complémentaire d’une Skill |
| Serveur MCP | Ajoute des outils externes à l’agent |
| Moindre privilège | Borner Skills et serveurs au strict nécessaire |
💪 À vous de jouer
Créez une seconde Skill « doc-route » dont la description cible la rédaction de documentation d’API, et qui impose un format de section par route. Vérifiez qu’elle se déclenche quand vous demandez de documenter une route, mais pas quand vous demandez d’en coder une.
Voir une piste de solution
Dans la description, soyez explicite sur le déclencheur : « À utiliser pour rédiger ou mettre à jour la documentation d’une route de l’API Suivi. » Puis testez les deux cas : « Documente la route PATCH /tasks/:id » doit activer la Skill ; « Ajoute une route PATCH /tasks/:id » doit plutôt activer « convention-api-suivi ». Cette distinction prouve que vos descriptions sont assez nettes pour ne pas se chevaucher.
À lire aussi
- Piloter Antigravity depuis le terminal : la CLI agy — pour retrouver Skills et MCP côté ligne de commande.
- Cadrer un agent : AGENTS.md, Rules et Workflows — la base de configuration sur laquelle s’appuient les Skills.
Ressources officielles
- Tutoriel Google : Getting Started with Google Antigravity
- Protocole MCP : modelcontextprotocol.io
FAQ
Quelle différence entre une Skill et une règle ?
Une règle est une contrainte permanente et brève (« documente les fonctions exportées »). Une Skill est un paquet de savoir-faire plus riche, chargé à la demande quand la tâche correspond à sa description. La règle contraint ; la Skill outille.
Un serveur MCP est-il spécifique à Antigravity ?
Non. MCP est un protocole ouvert : un même serveur peut être utilisé par différents outils compatibles. C’est l’un de ses grands intérêts — on capitalise sur des serveurs réutilisables plutôt que sur des intégrations propriétaires.
Faut-il savoir programmer pour créer une Skill ?
Pas nécessairement. Une Skill peut se réduire à un SKILL.md en texte clair décrivant une procédure. Les scripts sont optionnels et n’interviennent que pour des compétences qui exécutent réellement du code.