Créer des skills Google Antigravity

1. Introduction

Google Antigravity est un IDE agentique de Google. Dans cet atelier de programmation, nous allons utiliser Antigravity pour créer des compétences agentiques, un format ouvert et léger permettant d'étendre les capacités des agents IA avec des connaissances et des workflows spécialisés. Vous découvrirez ce que sont les compétences agentiques, leurs avantages et comment elles sont construites. Vous créerez ensuite plusieurs compétences agentiques, allant d'un formateur Git à un générateur de modèles, en passant par un échafaudage de code d'outil, et bien plus encore, le tout utilisable dans Antigravity.

Prérequis :

  • Google Antigravity est installé et configuré.
  • Vous avez des connaissances de base sur Google Antigravity. Nous vous recommandons de suivre l'atelier de programmation Premiers pas avec Google Antigravity.

2. Pourquoi des compétences ?

Les agents IA modernes sont passés de simples auditeurs à des raisonneurs complexes qui s'intègrent aux systèmes de fichiers locaux et aux outils externes (via des serveurs MCP). Toutefois, le chargement indiscriminé d'un agent avec des bases de code entières et des centaines d'outils entraîne une saturation du contexte et un "gonflement des outils". Même avec de grandes fenêtres de contexte, le vidage de 40 à 50 000 jetons d'outils inutilisés dans la mémoire active entraîne une latence élevée, un gaspillage financier et une "dégradation du contexte", où le modèle est confus par des données non pertinentes.

La solution : les compétences agentiques

Pour résoudre ce problème, Anthropic a introduit les compétences agentiques, en passant d'une architecture de chargement de contexte monolithique à une divulgation progressive. Au lieu de forcer le modèle à "mémoriser" chaque workflow spécifique (comme les migrations de base de données ou les audits de sécurité) au début d'une session, ces fonctionnalités sont regroupées dans des unités modulaires et détectables.

Fonctionnement

Le modèle n'est initialement exposé qu'à un "menu" léger de métadonnées. Il ne charge les connaissances procédurales lourdes (instructions et scripts) que lorsque l'intention de l'utilisateur correspond spécifiquement à une compétence. Ainsi, un développeur qui demande à refactoriser un middleware d'authentification obtient un contexte de sécurité sans charger de pipelines CSS non liés, ce qui permet de maintenir un contexte léger, rapide et économique.

d3f4bcb065a19fea.png

3. Compétences agentiques et Antigravity

Dans l'écosystème Antigravity, si l'Agent Manager est le cerveau et l'éditeur le canevas, les compétences agissent comme des modules de formation spécialisés qui comblent le fossé entre le modèle généraliste Gemini 3 et votre contexte spécifique. Elles permettent à l'agent de "s'équiper" d'un ensemble défini d'instructions et de protocoles (tels que les normes de migration de base de données ou les contrôles de sécurité) uniquement lorsqu'une tâche pertinente est demandée. En chargeant dynamiquement ces protocoles d'exécution, les compétences transforment efficacement l'IA d'un programmeur générique en un spécialiste qui respecte rigoureusement les bonnes pratiques et les normes de sécurité codifiées d'une organisation.

Qu'est-ce qu'une compétence dans Antigravity ?

Dans le contexte de Google Antigravity, une compétence est un package basé sur un répertoire contenant un fichier de définition (SKILL.md) et des éléments de support facultatifs (scripts, références, modèles).

Il s'agit d'un mécanisme d'extension de capacité à la demande.

  • À la demande : contrairement à un prompt système (qui est toujours chargé), une compétence n'est chargée dans le contexte de l'agent que lorsque celui-ci détermine qu'elle est pertinente pour la requête actuelle de l'utilisateur. Cela optimise la fenêtre de contexte et empêche l'agent d'être distrait par des instructions non pertinentes. Dans les grands projets comportant des dizaines d'outils, ce chargement sélectif est essentiel pour les performances et la précision du raisonnement.
  • Extension de capacité : les compétences ne se limitent pas à donner des instructions, elles peuvent aussi exécuter des tâches. En regroupant des scripts Python ou Bash, une compétence peut permettre à l'agent d'effectuer des actions complexes en plusieurs étapes sur la machine locale ou sur des réseaux externes sans que l'utilisateur ait besoin d'exécuter manuellement des commandes. L'agent passe ainsi d'un générateur de texte à un utilisateur d'outils.

Compétences par rapport à l'écosystème (outils, règles et workflows)

Alors que le Model Context Protocol (MCP) fonctionne comme les "mains" de l'agent (fournissant des connexions persistantes et robustes à des systèmes externes tels que GitHub ou PostgreSQL), les compétences agissent comme le "cerveau" qui les dirige.

Le MCP gère l'infrastructure avec état, tandis que les compétences sont des définitions de tâches légères et éphémères qui regroupent la méthodologie d'utilisation de ces outils. Cette approche sans serveur permet aux agents d'exécuter des tâches ad hoc (comme la génération de journaux de modifications ou de migrations) sans la surcharge opérationnelle liée à l'exécution de processus persistants, en chargeant le contexte uniquement lorsque la tâche est active et en le libérant immédiatement après.

Sur le plan fonctionnel, les compétences occupent une position intermédiaire unique entre les "règles" (garde-fous passifs et toujours actifs) et les "workflows" (macros actives et déclenchées par l'utilisateur). Contrairement aux workflows qui nécessitent des commandes spécifiques (par exemple, /test), les compétences sont déclenchées par l'agent : le modèle détecte automatiquement l'intention de l'utilisateur et s'équipe dynamiquement de l'expertise spécifique requise. Cette architecture permet une puissante composabilité. Par exemple, une règle globale peut appliquer l'utilisation d'une compétence "Safe-Migration" lors des modifications de la base de données, ou un seul workflow peut orchestrer plusieurs compétences pour créer un pipeline de déploiement robuste.

4. Créer des compétences

La création d'une compétence dans Antigravity suit une structure de répertoire et un format de fichier spécifiques. Cette normalisation garantit que les compétences sont portables et que l'agent peut les analyser et les exécuter de manière fiable. La conception est intentionnellement simple et repose sur des formats largement compris tels que Markdown et YAML, ce qui réduit la barrière à l'entrée pour les développeurs souhaitant étendre les capacités de leur IDE.

Structure des répertoires

Les compétences peuvent être définies sur deux niveaux d'accès, ce qui permet des personnalisations spécifiques au projet et à l'utilisateur :

  1. Niveau d'accès à l'espace de travail : situé dans <workspace-root>/.agent/skills/. Ces compétences ne sont disponibles que dans le projet spécifique. Elles sont idéales pour les scripts spécifiques au projet, tels que le déploiement dans un environnement spécifique, la gestion de la base de données pour cette application ou la génération de code boilerplate pour un framework propriétaire.
  2. Niveau d'accès global : situé dans ~/.gemini/antigravity/skills/. Ces compétences sont disponibles dans tous les projets de la machine de l'utilisateur. Elles conviennent aux utilitaires généraux tels que "Format JSON", "Generate UUIDs", "Review Code Style" ou à l'intégration avec des outils de productivité personnelle.

Un répertoire de compétences type se présente comme suit :

my-skill/
├── SKILL.md # The definition file
├── scripts/ # [Optional] Python, Bash, or Node scripts
     ├── run.py
     └── util.sh
├── references/ # [Optional] Documentation or templates
     └── api-docs.md
└── assets/ # [Optional] Static assets (images, logos)

Cette structure sépare efficacement les préoccupations. La logique (scripts) est séparée de l'instruction (SKILL.md) et des connaissances (references), ce qui reflète les pratiques standards d'ingénierie logicielle.

Le fichier de définition SKILL.md

Le fichier SKILL.md est le cerveau de la compétence. Il indique à l'agent ce qu'est la compétence, quand l'utiliser et comment l'exécuter.

Il se compose de deux parties :

  • Frontmatter YAML
  • Corps Markdown.

Frontmatter YAML

Il s'agit de la couche de métadonnées. C'est la seule partie de la compétence qui est indexée par le routeur de haut niveau de l'agent. Lorsqu'un utilisateur envoie un prompt, l'agent fait correspondre sémantiquement le prompt aux champs de description de toutes les compétences disponibles.

---
name: database-inspector
description: Use this skill when the user asks to query the database, check table schemas, or inspect user data in the local PostgreSQL instance.
---

Principaux champs :

  • name : ce champ n'est pas obligatoire. Il doit être unique dans le champ d'application. Il doit être en minuscules et peut contenir des traits d'union (par exemple, postgres-query, pr-reviewer). S'il n'est pas fourni, il est défini par défaut sur le nom du répertoire.
  • description: ce champ est obligatoire et le plus important. Il fonctionne comme une "phrase de déclenchement". Il doit être suffisamment descriptif pour que le LLM puisse reconnaître la pertinence sémantique. Une description vague comme "Outils de base de données" est insuffisante. Une description précise comme "Exécute des requêtes SQL en lecture seule sur la base de données PostgreSQL locale pour récupérer les données utilisateur ou de transaction. Utilisez-la pour déboguer les états des données" garantit que la compétence est correctement sélectionnée.

Corps Markdown

Le corps contient les instructions. Il s'agit d'un "prompt engineering" persistant dans un fichier. Lorsque la compétence est activée, ce contenu est injecté dans la fenêtre de contexte de l'agent.

Le corps doit inclure les éléments suivants :

  1. Objectif : une déclaration claire de ce que la compétence permet d'accomplir.
  2. Instructions : logique pas à pas.
  3. Exemples : quelques exemples d'entrées et de sorties pour guider les performances du modèle.
  4. Contraintes : règles "Ne pas" (par exemple, "N'exécutez pas de requêtes DELETE").

Exemple de corps SKILL.md :

Database Inspector

Goal
To safely query the local database and provide insights on the current data state.

Instructions
- Analyze the user's natural language request to understand the data need.
- Formulate a valid SQL query.
 - CRITICAL: Only SELECT statements are allowed.
- Use the script scripts/query_runner.py to execute the SQL.
 - Command: python scripts/query_runner.py "SELECT * FROM..."
- Present the results in a Markdown table.

Constraints
- Never output raw user passwords or API keys.
- If the query returns > 50 rows, summarize the data instead of listing it all.

Intégration de scripts

L'une des fonctionnalités les plus puissantes des compétences est la possibilité de déléguer l'exécution à des scripts. Cela permet à l'agent d'effectuer des actions difficiles, voire impossibles, pour un LLM (comme l'exécution binaire, le calcul mathématique complexe ou l'interaction avec des systèmes existants).

Les scripts sont placés dans le sous-répertoire scripts/. Le fichier SKILL.md les référence par chemin relatif.

5. Créer des compétences

L'objectif de cette section est de créer des compétences qui s'intègrent à Antigravity et d'afficher progressivement diverses fonctionnalités telles que des ressources, des scripts, etc.

Vous pouvez télécharger les compétences à partir du dépôt GitHub en cliquant ici : https://github.com/rominirani/antigravity-skills.

Nous pouvons envisager de placer chacune de ces compétences dans le dossier ~/.gemini/antigravity/skills ou dans le dossier /.agent/skills.

Niveau 1 : Le routeur de base ( git-commit-formatter )

Considérons cela comme le "Hello World" des compétences.

Les développeurs écrivent souvent des messages de commit paresseux, par exemple "wip", "fix bug" ou "updates". L'application manuelle des "commits conventionnels" est fastidieuse et souvent oubliée. Implémentons une compétence qui applique la spécification des commits conventionnels. En indiquant simplement les règles à l'agent, nous lui permettons d'agir en tant qu'application.

git-commit-formatter/
└── SKILL.md  (Instructions only)

Le fichier SKILL.md est présenté ci-dessous :

---
name: git-commit-formatter
description: Formats git commit messages according to Conventional Commits specification. Use this when the user asks to commit changes or write a commit message.
---

Git Commit Formatter Skill

When writing a git commit message, you MUST follow the Conventional Commits specification.

Format
`<type>[optional scope]: <description>`

Allowed Types
- **feat**: A new feature
- **fix**: A bug fix
- **docs**: Documentation only changes
- **style**: Changes that do not affect the meaning of the code (white-space, formatting, etc)
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **perf**: A code change that improves performance
- **test**: Adding missing tests or correcting existing tests
- **chore**: Changes to the build process or auxiliary tools and libraries such as documentation generation

Instructions
1. Analyze the changes to determine the primary `type`.
2. Identify the `scope` if applicable (e.g., specific component or file).
3. Write a concise `description` in an imperative mood (e.g., "add feature" not "added feature").
4. If there are breaking changes, add a footer starting with `BREAKING CHANGE:`.

Example
`feat(auth): implement login with google`

Exécution de cet exemple :

  1. Apportez une petite modification à n'importe quel fichier de votre espace de travail.
  2. Ouvrez la discussion et saisissez : Commit these changes.
  3. L'agent n'exécutera pas seulement git commit. Il activera d'abord la compétence git-commit-formatter.
  4. Résultat : un message de commit Git conventionnel sera proposé.

Par exemple, j'ai demandé à Antigravity d'ajouter des commentaires à un exemple de fichier Python, et j'ai obtenu un message de commit Git comme docs: add detailed comments to demo_primes.py.

Niveau 2 : Utilisation des éléments (license-header-adder)

Il s'agit du modèle "Référence".

Chaque fichier source d'un projet d'entreprise peut nécessiter un en-tête de licence Apache 2.0 spécifique de 20 lignes. Placer ce texte statique directement dans le prompt (ou SKILL.md) est un gaspillage. Il consomme des jetons chaque fois que la compétence est indexée, et le modèle peut "halluciner" des fautes de frappe dans le texte juridique.

Déchargez le texte statique dans un fichier texte brut dans un dossier resources/. La compétence indique à l'agent de lire ce fichier uniquement en cas de besoin.

license-header-adder/
├── SKILL.md
└── resources/
   └── HEADER_TEMPLATE.txt  (The heavy text)

Le fichier SKILL.md est présenté ci-dessous :

---
name: license-header-adder
description: Adds the standard open-source license header to new source files. Use involves creating new code files that require copyright attribution.
---

# License Header Adder Skill

This skill ensures that all new source files have the correct copyright header.

## Instructions

1. **Read the Template**:
  First, read the content of the header template file located at `resources/HEADER_TEMPLATE.txt`.

2. **Prepend to File**:
  When creating a new file (e.g., `.py`, `.java`, `.js`, `.ts`, `.go`), prepend the `target_file` content with the template content.

3. **Modify Comment Syntax**:
  - For C-style languages (Java, JS, TS, C++), keep the `/* ... */` block as is.
  - For Python, Shell, or YAML, convert the block to use `#` comments.
  - For HTML/XML, use `<!-- ... -->`.

Exécution de cet exemple :

  1. Créez un fichier Python factice : touch my_script.py
  2. Saisissez : Add the license header to my_script.py.
  3. L'agent lira license-header-adder/resources/HEADER_TEMPLATE.txt.
  4. Il collera le contenu exactement, mot pour mot, dans votre fichier.

Niveau 3 : Apprendre par l'exemple (json-to-pydantic)

Il s'agit du modèle "Few-Shot".

La conversion de données non structurées (comme une réponse d'API JSON) en code strict (comme des modèles Pydantic) implique des dizaines de décisions. Comment nommer les classes ? Faut-il utiliser Optional ? snake_case ou camelCase ? Écrire ces 50 règles en anglais est fastidieux et sujet aux erreurs.

Les LLM sont des moteurs de correspondance de schémas.

Leur montrer un exemple parfait (Input -> Output) est souvent plus efficace que des instructions détaillées.

json-to-pydantic/
├── SKILL.md
└── examples/
   ├── input_data.json   (The Before State)
   └── output_model.py   (The After State)

Le fichier SKILL.md est présenté ci-dessous :

---
name: json-to-pydantic
description: Converts JSON data snippets into Python Pydantic data models.
---

# JSON to Pydantic Skill

This skill helps convert raw JSON data or API responses into structured, strongly-typed Python classes using Pydantic.

Instructions

1. **Analyze the Input**: Look at the JSON object provided by the user.
2. **Infer Types**:
  - `string` -> `str`
  - `number` -> `int` or `float`
  - `boolean` -> `bool`
  - `array` -> `List[Type]`
  - `null` -> `Optional[Type]`
  - Nested Objects -> Create a separate sub-class.
 
3. **Follow the Example**:
  Review `examples/` to see how to structure the output code. notice how nested dictionaries like `preferences` are extracted into their own class.
 
  - Input: `examples/input_data.json`
  - Output: `examples/output_model.py`

Style Guidelines
- Use `PascalCase` for class names.
- Use type hints (`List`, `Optional`) from `typing` module.
- If a field can be missing or null, default it to `None`.

Dans le dossier /examples, vous trouverez le fichier JSON et le fichier de sortie, c'est-à-dire le fichier Python. Les deux sont présentés ci-dessous :

input_data.json

{
   "user_id": 12345,
   "username": "jdoe_88",
   "is_active": true,
   "preferences": {
       "theme": "dark",
       "notifications": [
           "email",
           "push"
       ]
   },
   "last_login": "2024-03-15T10:30:00Z",
   "meta_tags": null
}

output_model.py

from pydantic import BaseModel, Field
from typing import List, Optional

class Preferences(BaseModel):
   theme: str
   notifications: List[str]

class User(BaseModel):
   user_id: int
   username: str
   is_active: bool
   preferences: Preferences
   last_login: Optional[str] = None
   meta_tags: Optional[List[str]] = None

Exécution de cet exemple :

  1. Fournissez à l'agent un extrait de code JSON (collez-le dans la discussion ou pointez vers un fichier).

{ "product": "Widget", "cost": 10.99, "stock": null }

  1. Saisissez : Convert this JSON to a Pydantic model.
  2. L'agent examine la paire examples dans le dossier de compétences.
  3. Il génère une classe Python qui imite parfaitement le style de codage, les importations et la structure de output_model.py, y compris la gestion du stock nul en tant qu'optionnel.

Un exemple de sortie (product_model.py) est présenté ci-dessous :

from pydantic import BaseModel
from typing import Optional

class Product(BaseModel):
   product: str
   cost: float
   stock: Optional[int] = None

Niveau 4 : Logique procédurale (database-schema-validator)

Il s'agit du modèle "Utilisation d'outils".

Si vous demandez à un LLM "Ce schéma est-il sûr ?", il peut répondre que tout va bien, même si une clé primaire essentielle est manquante, simplement parce que le code SQL semble correct.

Déléguez cette vérification à un script déterministe. Nous utilisons la compétence pour acheminer l'agent afin qu'il exécute un script Python que nous avons écrit. Le script fournit une vérité binaire (True/False).

database-schema-validator/
├── SKILL.md
└── scripts/
   └── validate_schema.py  (The Validator)

Le fichier SKILL.md est présenté ci-dessous :

---
name: database-schema-validator
description: Validates SQL schema files for compliance with internal safety and naming policies.
---

# Database Schema Validator Skill

This skill ensures that all SQL files provided by the user comply with our strict database standards.

Policies Enforced
1. **Safety**: No `DROP TABLE` statements.
2. **Naming**: All tables must use `snake_case`.
3. **Structure**: Every table must have an `id` column as PRIMARY KEY.

Instructions

1. **Do not read the file manually** to check for errors. The rules are complex and easily missed by eye.
2. **Run the Validation Script**:
  Use the `run_command` tool to execute the python script provided in the `scripts/` folder against the user's file.
 
  `python scripts/validate_schema.py <path_to_user_file>`

3. **Interpret Output**:
  - If the script returns **exit code 0**: Tell the user the schema looks good.
  - If the script returns **exit code 1**: Report the specific error messages printed by the script to the user and suggest fixes.

Le fichier validate_schema.py est présenté ci-dessous :

import sys
import re

def validate_schema(filename):
   """
   Validates a SQL schema file against internal policy:
   1. Table names must be snake_case.
   2. Every table must have a primary key named 'id'.
   3. No 'DROP TABLE' statements allowed (safety).
   """
   try:
       with open(filename, 'r') as f:
           content = f.read()
          
       lines = content.split('\n')
       errors = []
      
       # Check 1: No DROP TABLE
       if re.search(r'DROP TABLE', content, re.IGNORECASE):
           errors.append("ERROR: 'DROP TABLE' statements are forbidden.")
          
       # Check 2 & 3: CREATE TABLE checks
       table_defs = re.finditer(r'CREATE TABLE\s+(?P<name>\w+)\s*\((?P<body>.*?)\);', content, re.DOTALL | re.IGNORECASE)
      
       for match in table_defs:
           table_name = match.group('name')
           body = match.group('body')
          
           # Snake case check
           if not re.match(r'^[a-z][a-z0-9_]*$', table_name):
               errors.append(f"ERROR: Table '{table_name}' must be snake_case.")
              
           # Primary key check
           if not re.search(r'\bid\b.*PRIMARY KEY', body, re.IGNORECASE):
               errors.append(f"ERROR: Table '{table_name}' is missing a primary key named 'id'.")

       if errors:
           for err in errors:
               print(err)
           sys.exit(1)
       else:
           print("Schema validation passed.")
           sys.exit(0)
          
   except FileNotFoundError:
       print(f"Error: File '{filename}' not found.")
       sys.exit(1)

if __name__ == "__main__":
   if len(sys.argv) != 2:
       print("Usage: python validate_schema.py <schema_file>")
       sys.exit(1)
      
   validate_schema(sys.argv[1])

Exécution de cet exemple :

  1. Créez un fichier SQL incorrect bad_schema.sql : CREATE TABLE users (name TEXT);
  2. Saisissez : Validate bad_schema.sql.
  3. L'agent ne devine pas. Il appelle le script, qui échoue (code de sortie 1) et nous indique que "La validation a échoué, car la table 'users' ne comporte pas de clé primaire."

Niveau 5 : L'architecte (adk-tool-scaffold)

Ce modèle couvre la plupart des fonctionnalités disponibles dans les compétences.

Les tâches complexes nécessitent souvent une séquence d'opérations combinant tout ce que nous avons vu : création de fichiers, suivi de modèles et écriture de logique. La création d'un outil pour l'ADK (Agent Development Kit) nécessite tout cela.

Nous combinons les éléments suivants :

  • Script (pour gérer la création/l'échafaudage de fichiers)
  • Modèle (pour gérer le boilerplate dans les ressources)
  • Exemple (pour guider la génération de logique).
adk-tool-scaffold/
├── SKILL.md
├── resources/
   └── ToolTemplate.py.hbs (Jinja2 Template)
├── scripts/
   └── scaffold_tool.py    (Generator Script)
└── examples/
    └── WeatherTool.py      (Reference Implementation)

Le fichier SKILL.md est présenté ci-dessous. Vous pouvez consulter le dépôt de compétences pour vérifier les fichiers dans les dossiers scripts, ressources et exemples. Pour cette compétence spécifique, accédez à la compétence adk-tool-scaffold.

---
name: adk-tool-scaffold
description: Scaffolds a new custom Tool class for the Agent Development Kit (ADK).
---

# ADK Tool Scaffold Skill

This skill automates the creation of standard `BaseTool` implementations for the Agent Development Kit.

Instructions

1. **Identify the Tool Name**:
  Extract the name of the tool the user wants to build (e.g., "StockPrice", "EmailSender").
 
2. **Review the Example**:
  Check `examples/WeatherTool.py` to understand the expected structure of an ADK tool (imports, inheritance, schema).

3. **Run the Scaffolder**:
  Execute the python script to generate the initial file.
 
  `python scripts/scaffold_tool.py <ToolName>`

4. **Refine**:
  After generation, you must edit the file to:
  - Update the `execute` method with real logic.
  - Define the JSON schema in `get_schema`.
 
Example Usage
User: "Create a tool to search Wikipedia."
Agent:
1. Runs `python scripts/scaffold_tool.py WikipediaSearch`
2. Editing `WikipediaSearchTool.py` to add the `requests` logic and `query` argument schema.

Exécution de cet exemple :

  1. Saisissez : Create a new ADK tool called StockPrice to fetch data from an API.
  2. Étape 1 (échafaudage) : l'agent exécute le script Python. Cela crée instantanément StockPriceTool.py avec la structure de classe, les importations et le nom de classe StockPriceTool appropriés.
  3. Étape 2 (implémentation) : l'agent "lit" le fichier qu'il vient de créer. Il voit # TODO: Implement logic.
  4. Étape 3 (guidage) : il ne sait pas comment définir le schéma JSON pour les arguments de l'outil. Il vérifie examples/WeatherTool.py.
  5. Finalisation : il modifie le fichier pour ajouter requests.get(...) et définit l'argument du symbole boursier dans le schéma, en respectant exactement le style ADK.

6. Félicitations

Vous avez terminé l'atelier sur les compétences Antigravity et créé les compétences suivantes :

  • Formateur de commit Git.
  • Outil d'ajout d'en-tête de licence.
  • JSON vers Pydantic.
  • Validateur de schéma de base de données.
  • Échafaudage d'outil ADK.

Les compétences agentiques sont un excellent moyen d'utiliser Antigravity pour écrire du code à votre manière, suivre des règles et utiliser vos outils.

Documents de référence