Donner un « cerveau expert » à l'agent : écrire des Agent Skills Antigravity sur mesure

La semaine dernière, un collègue m’a encore demandé pour la énième fois : « C’est quoi exactement le flux d’authentification de cette API ? »

J’ouvre la page Confluence poussiéreuse : dernière mise à jour il y a six mois. La doc et le code ne sont plus alignés. Je soupire et retape l’explication que j’ai déjà donnée cent fois.

Ce soir-là, en bidouillant Antigravity, je tombe sur le système Skills. En bref : on peut greffer un « cerveau expert » à l’agent — mémoriser des savoirs, exécuter des processus, appeler des outils précis.

Deux heures plus tard, j’avais écrit un Skill pour notre API interne. Le lendemain, un nouveau pose la même question ; dans Antigravity, je tape : « Consulte le flux d’authentification du service utilisateurs. »

L’agent appelle mon Skill. Trente secondes plus tard : explication exacte, avec extraits de code. Il hoche la tête et part tester seul.

Là, j’ai compris : les Skills ne sont pas qu’une extension — ils changent la façon dont l’équipe collabore.

Ce guide explique comment écrire des Skills Antigravity sur mesure : concepts, cas pratiques, intégration d’API externes et connexion à une base de connaissances privée.

Qu’est-ce qu’un Antigravity Skill

Posons les bases.

Le système Skills d’Antigravity est un format d’extension léger et ouvert. Voyez-le comme une « application » installée sur l’agent : chaque Skill définit un ensemble de capacités pour le rendre plus professionnel dans certains scénarios.

Selon les Google Codelabs, un Skill est un paquet structuré en répertoires, au format standardisé que l’agent peut analyser et exécuter de façon fiable. Un Skill typique contient :

Vultr - Serveur cloud NVMe haute performance, 32 emplacements mondiaux, déploiement Docker en un clic

Voir les tarifs →Pub

• skill.yaml : métadonnées, description des capacités, scénarios d’usage
• README.md : fonctionnement détaillé et mode d’emploi
• scripts/ : scripts exécutables (Python, Bash, etc.)
• templates/ : modèles de prompt ou de sortie

Deux périmètres possibles :

• Global (~/.gemini/antigravity/skills/) : transversal, ex. « formater du JSON », « revue de code générique »
• Projet (.agent/skills/) : limité au dépôt, ex. « conventions API de l’équipe », « gabarits métier »

Utile : l’universel en global, le métier dans le projet.

Écrire votre premier Skill

On passe à la pratique.

Exemple simple : un Skill qui formate automatiquement les messages de commit Git.

Étape 1 : structure de répertoires

mkdir -p ~/.gemini/antigravity/skills/git-commit-formatter

Étape 2 : skill.yaml

name: git-commit-formatter
description: Format Git commit messages following Conventional Commits spec
version: 1.0.0
author: your-name
triggers:
  - commit
  - git message
  - format commit
actions:
  - name: format_commit
    description: Format a raw commit message to Conventional Commits format
    input:
      raw_message: string
      type: enum[feat, fix, docs, style, refactor, test, chore]
    output:
      formatted_message: string

Ce YAML fixe l’identité du Skill, les mots-clés de déclenchement et le schéma entrée/sortie.

Étape 3 : script d’exécution

Créez scripts/format_commit.py :

#!/usr/bin/env python3
import sys
import re

def format_commit(raw_message, commit_type):
    # 解析原始消息
    scope_match = re.search(r'\(([^)]+)\)', raw_message)
    scope = f"({scope_match.group(1)})" if scope_match else ""

    # 提取描述
    desc = re.sub(r'\([^)]+\):?\s*', '', raw_message).strip()

    # 格式化
    formatted = f"{commit_type}{scope}: {desc}"
    return formatted

if __name__ == "__main__":
    raw = sys.argv[1]
    ctype = sys.argv[2]
    print(format_commit(raw, ctype))

Étape 4 : test

Redémarrez Antigravity, puis essayez :

« Utilise git-commit-formatter pour formater ce commit : correction du bug de connexion utilisateur »

Si tout va bien, l’agent appelle le Skill et renvoie par exemple : fix(auth): correction du bug de connexion utilisateur

Voilà le squelette d’un Skill.

Intégrer des API externes : GitHub + Jira en pratique

Un Skill local seul reste un jouet ; la vraie valeur vient des systèmes externes.

Exemple : automatiser la gestion des tickets Jira.

Scénario : l’équipe passe des heures chaque jour à mettre à jour Jira et saisir le temps. Confions ces tâches répétitives à l’agent.

Étape 1 : authentification API

Token Jira, domaine, e-mail — stockez les secrets en variables d’environnement :

export JIRA_API_TOKEN="your-token"
export JIRA_DOMAIN="your-domain.atlassian.net"
export JIRA_EMAIL="[email protected]"

Étape 2 : configuration du Skill

name: jira-assistant
description: Automate Jira workflows - search issues, update status, add worklogs
triggers:
  - jira
  - ticket
  - issue
  - worklog
actions:
  - name: search_issues
    description: Search Jira issues by JQL query
  - name: add_worklog
    description: Add time spent to an issue
  - name: transition_issue
    description: Move issue to a different status

Étape 3 : script principal

#!/usr/bin/env python3
import os
import requests
from base64 import b64encode

class JiraClient:
    def __init__(self):
        self.domain = os.getenv('JIRA_DOMAIN')
        self.email = os.getenv('JIRA_EMAIL')
        self.token = os.getenv('JIRA_API_TOKEN')
        self.auth = self._get_auth()

    def _get_auth(self):
        credentials = f"{self.email}:{self.token}"
        return b64encode(credentials.encode()).decode()

    def search(self, jql):
        url = f"https://{self.domain}/rest/api/2/search"
        headers = {
            "Authorization": f"Basic {self.auth}",
            "Content-Type": "application/json"
        }
        response = requests.get(url, headers=headers, params={"jql": jql})
        return response.json()

    def add_worklog(self, issue_key, time_spent, comment):
        url = f"https://{self.domain}/rest/api/2/issue/{issue_key}/worklog"
        headers = {
            "Authorization": f"Basic {self.auth}",
            "Content-Type": "application/json"
        }
        data = {
            "timeSpent": time_spent,
            "comment": comment
        }
        return requests.post(url, headers=headers, json=data)

# CLI入口
if __name__ == "__main__":
    import sys
    client = JiraClient()

    if sys.argv[1] == "search":
        result = client.search(sys.argv[2])
        for issue in result.get('issues', []):
            print(f"{issue['key']}: {issue['fields']['summary']}")

    elif sys.argv[1] == "worklog":
        client.add_worklog(sys.argv[2], sys.argv[3], sys.argv[4])
        print(f"Worklog added to {sys.argv[2]}")

Étape 4 : utilisation

Dans Antigravity, vous pouvez dire :

« Liste tous mes tickets Jira en In Progress »

« Ajoute 2 h de worklog sur PROJ-123, commentaire : refactor du module utilisateur terminé »

« Passe PROJ-456 au statut Done »

L’agent appelle l’API Jira — plus besoin d’ouvrir l’interface lente.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Pour GitHub, même logique avec PyGithub ou requests : Skill pour créer des PR, vérifier la CI, voire faire de la revue de code.

Relier une base privée : NotebookLM + Antigravity

C’est la partie qui m’enthousiasme le plus.

Un cas XDA Developers illustre bien l’idée : nourrir NotebookLM avec la doc projet, générer des spécifications techniques, puis les convertir en Skill Antigravity — l’agent code alors en s’appuyant sur la documentation.

Principe :

NotebookLM exporte des conversations en documents structurés. Workflow possible :

1. Créer dans NotebookLM la base projet (design, API, décisions d’architecture)
2. Utiliser le Q&R pour produire des « résumés de savoir »
3. Les transformer en context ou templates du Skill

Ou, plus direct : relier NotebookLM via MCP (Model Context Protocol).

Le dépôt open source notebooklm-antigravity-skill s’appuie sur nlm CLI :

name: notebooklm-knowledge
description: Query project knowledge from NotebookLM
triggers:
  - consulter doc
  - voir normes
  - connaissances projet
actions:
  - name: query_knowledge
    description: Query NotebookLM for project-specific knowledge

Avec un script qui appelle l’API NotebookLM, l’agent interroge votre base en temps réel.

Scénario typique :

Nouveau : « Quelle est notre norme de gestion des erreurs ? »
Vous (dans Antigravity) : « Interroge NotebookLM sur la norme de gestion des erreurs »
Agent : « D’après la doc projet : 1. classes d’exception personnalisées… 2. logs avec traceback… 3. erreurs visibles utilisateur à internationaliser… »

La documentation ne dort plus dans un coin : elle devient le « cerveau expert » de l’agent.

Astuce avancée : combiner Rules et Skills

Antigravity propose aussi un système Rules. Ensemble, l’effet est multiplié.

Les Rules sont des contraintes globales ou projet, par exemple :

# .agent/rules/code-review.md

Lors d'une revue de code :
1. Vérifier une couverture de tests suffisante
2. Confirmer l'absence d'informations sensibles en dur
3. Valider la gestion des erreurs
4. Vérifier le respect des conventions TypeScript de l'équipe

La Rule dit quand et selon quels critères ; le Skill dit comment exécuter.

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

Les ingénieurs Atlassian ont décrit un cas : règle app-deployment + Skills Jira pour automatiser le déploiement.

Quand l’agent détecte un merge sur main :

1. La Rule déclenche : « exécuter les contrôles pré-déploiement »
2. Skill : vérifier l’état des tickets Jira liés
3. Skill : lancer la suite de tests
4. Skill : si OK, mettre à jour Jira et journaliser le déploiement

Une douzaine d’étapes manuelles devient une phrase.

Conclusion

En une phrase : les Skills transforment Antigravity d’outil générique en assistant spécialisé.

L’IA générique sait coder, pas votre métier. Avec des Skills, vous injectez savoir métier, normes d’équipe et outils internes — l’agent devient un membre de l’équipe.

J’ai commencé par un formateur de commit Git ; aujourd’hui nous en avons plus de vingt en interne. Doc API, revue de code, Jira, onboarding des nouveaux — le répétitif part vers l’agent.

Ce n’est pas de la paresse : on libère du temps pour l’architecture, les problèmes difficiles, les nouveaux produits. Requêtes de savoir et procédures répétitives ? À l’agent.

Pour essayer : partez d’une petite friction. La question posée cent fois, ou l’opération répétée dix fois par jour — un Skill peut la résoudre.

L’agent n’est pas qu’un outil : c’est une extension de l’équipe.

Et les Skills sont la clé qui lui donne une vraie expertise.