Premiers pas avec les compétences dans Google Antigravity

1. Introduction

Google Antigravity (appelé "Antigravity" dans le reste du document) est un IDE agentique de Google. Dans l'atelier de programmation sur les premiers pas avec Antigravity, vous pouvez découvrir les bases d'Antigravity. Dans cet atelier de programmation, nous allons utiliser Antigravity pour créer des compétences d'agent, un format ouvert et léger permettant d'étendre les capacités des agents d'IA avec des connaissances et des workflows spécialisés. Vous découvrirez ce que sont les compétences d'agent, leurs avantages et comment elles sont construites. Vous allez ensuite créer plusieurs compétences d'agent, allant d'un outil de mise en forme Git à un générateur de modèles, en passant par un échafaudage de code d'outil et plus encore, le tout utilisable dans Antigravity.

Prérequis :

  • Google Antigravity est installé et configuré.
  • Connaissances de base de Google Antigravity. Nous vous recommandons de suivre l'atelier de programmation Premiers pas avec Google Antigravity.

2. Pourquoi les compétences ?

Les agents d'IA modernes sont passés de simples écouteurs à des raisonneurs complexes qui s'intègrent aux systèmes de fichiers locaux et aux outils externes (via les 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 fait de déverser 40 000 à 50 000 jetons d'outils inutilisés dans la mémoire active entraîne une latence élevée, un gaspillage financier et une "détérioration du contexte", où le modèle est perturbé par des données non pertinentes.

La solution : les compétences des agents

Pour résoudre ce problème, Anthropic a introduit les compétences d'agent, en passant d'une architecture de chargement de contexte monolithique à une architecture de divulgation progressive. Au lieu de forcer le modèle à "mémoriser" chaque workflow spécifique (comme les migrations de bases de données ou les audits de sécurité) au début d'une session, ces capacité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 charge les connaissances procédurales lourdes (instructions et scripts) uniquement lorsque l'intention de l'utilisateur correspond spécifiquement à une compétence. Cela garantit qu'un développeur qui demande à refactoriser le middleware d'authentification obtient un contexte de sécurité sans charger de pipelines CSS non liés, ce qui permet de maintenir le contexte léger, rapide et économique.

d3f4bcb065a19fea.png

3. Compétences d'agent et antigravité

Dans l'écosystème Antigravity, si l'Agent Manager est le cerveau et l'éditeur le canevas, les compétences agissent comme des modules d'entraînement spécialisés qui comblent le fossé entre le modèle généraliste Gemini 3 et votre contexte spécifique. Ils permettent à l'agent d'"équiper" 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 d'assistance facultatifs (scripts, références, modèles).

Il s'agit d'un mécanisme d'extension des fonctionnalités à la demande.

  • À la demande : contrairement à une invite système (qui est toujours chargée), 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 permet d'optimiser la fenêtre de contexte et d'empêcher 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 des capacités : les skills peuvent faire plus que donner des instructions, ils peuvent 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 les réseaux externes sans que l'utilisateur ait besoin d'exécuter manuellement des commandes. L'agent passe alors du statut de générateur de texte à celui d'utilisateur d'outils.

Compétences vs écosystème (outils, règles et workflows)

Alors que le protocole MCP (Model Context Protocol) sert de "mains " à l'agent en 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.

MCP gère l'infrastructure avec état, tandis que les compétences sont des définitions de tâches éphémères et légères qui regroupent la méthodologie d'utilisation de ces outils. Cette approche sans serveur permet aux agents d'exécuter des tâches ponctuelles (comme la génération de journaux des 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.

D'un point de vue fonctionnel, les compétences occupent une place intermédiaire unique entre les "Règles" (garde-fous passifs et toujours actifs) et les "Workflows" (macros actives 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 composabilité puissante. Par exemple, une règle globale peut imposer 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 skill dans Antigravity suit une structure de répertoire et un format de fichier spécifiques. Cette standardisation garantit la portabilité des compétences et permet à l'agent de les analyser et de les exécuter de manière fiable. La conception est intentionnellement simple et s'appuie sur des formats largement compris comme Markdown et YAML, ce qui réduit la barrière à l'entrée pour les développeurs qui souhaitent étendre les capacités de leur IDE.

Structure des répertoires

Les compétences peuvent être définies dans deux champs d'application, ce qui permet des personnalisations spécifiques au projet et à l'utilisateur :

  1. Champ d'application Workspace : situé dans <workspace-root>/.agent/skills/. Ces compétences ne sont disponibles que dans le projet spécifique. C'est idéal pour les scripts spécifiques à un 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 standard pour un framework propriétaire.
  2. Champ d'application mondial : situé dans ~/.gemini/antigravity/skills/. Ces compétences sont disponibles dans tous les projets sur la machine de l'utilisateur. Cela convient aux utilitaires généraux tels que "Mettre en forme le JSON", "Générer des UUID", "Vérifier le style du code" ou l'intégration aux outils de productivité personnelle.

Voici à quoi ressemble un répertoire de skills type :

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 de la connaissance (references), ce qui reflète les pratiques standards de l'ingénierie logicielle.

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. Il s'agit de la seule partie de la compétence indexée par le routeur de haut niveau de l'agent. Lorsqu'un utilisateur envoie une requête, l'agent effectue une correspondance sémantique entre la requête et les 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. Doit être unique dans le champ d'application. Lettres minuscules et traits d'union autorisés (par exemple, postgres-query, pr-reviewer). S'il n'est pas fourni, le nom du répertoire sera utilisé par défaut.
  • description : ce champ est obligatoire et le plus important. Elle sert de "phrase de déclenchement". Elle doit être suffisamment descriptive 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. L'option "Utiliser pour le débogage des états de données" permet de s'assurer que la compétence est correctement sélectionnée.

Corps Markdown

Le corps contient les instructions. Il s'agit d'une "ingénierie des requêtes" persistante 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 : indiquez clairement ce que la compétence permet d'accomplir.
  2. Instructions : logique étape par étape.
  3. Exemples : exemples few-shot 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 de fichier 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 script

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 ou impossibles à réaliser directement par un LLM (comme l'exécution binaire, les calculs mathématiques complexes ou l'interaction avec des systèmes existants).

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

5. Compétences de création

L'objectif de cette section est de développer 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 à l'adresse https://github.com/rominirani/antigravity-skills.

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

Niveau 1 : Routeur de base ( git-commit-formatter )

Considérons cela comme le "Hello World" des skills.

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

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écuter cet exemple :

  1. Apportez une petite modification à un fichier de votre espace de travail.
  2. Ouvrez la discussion et saisissez "Valide ces modifications".
  3. L'agent ne se contentera pas d'exécuter la commande "git commit". Il activera d'abord la skill git-commit-formatter.
  4. Résultat : un message de commit Git conventionnel est proposé.

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

Niveau 2 : Utilisation des composants (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. Il est inutile de placer ce texte statique directement dans la requête (ou SKILL.md). Elle consomme des jetons chaque fois que la skill est indexée, et le modèle peut "halluciner" des fautes de frappe dans le texte juridique.

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

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 source d'erreurs.

Les LLM sont des moteurs de reconnaissance de formes.

Il est souvent plus efficace de leur montrer un exemple parfait (entrée → sortie) que de leur donner des instructions détaillées.

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écuter cet exemple :

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

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

Le 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 source d'erreurs.

Les LLM sont des moteurs de reconnaissance de formes. Il est souvent plus efficace de leur montrer un exemple parfait (entrée → sortie) que de leur donner 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écuter cet exemple :

  1. Fournissez à l'agent un extrait JSON (collez-le dans le chat ou indiquez un fichier).

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

  1. Type : Convert this JSON to a Pydantic model.
  2. L'agent examine la paire examples dans le dossier de la compétence.
  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.

Voici un exemple de résultat (product_model.py) :

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 vous répondre que tout va bien, même s'il manque une clé primaire essentielle, simplement parce que le code SQL semble correct.

Délégons cette vérification à un script déterministe. Nous utilisons la compétence pour que l'agent 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écuter cet exemple :

  1. Créez un fichier SQL incorrect bad_schema.sql : CREATE TABLE users (name TEXT);
  2. Type : Validate bad_schema.sql.
  3. L'agent ne devine pas. Le script sera appelé, mais échouera (code d'exit 1). Le message "La validation a échoué, car la table "users" ne comporte pas de clé primaire." s'affichera.

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

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

Les tâches complexes nécessitent souvent une séquence d'opérations combinant tout ce que nous avons vu : créer des fichiers, suivre des modèles et écrire de la logique. Pour créer un outil pour l'ADK (Agent Development Kit), vous devez effectuer toutes ces étapes.

Nous combinons :

  • Script (pour gérer la création/l'échafaudage du fichier)
  • Modèle (pour gérer les modèles dans les ressources)
  • Un exemple (pour guider la génération de la 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", "resources" et "examples". Pour cette skill spécifique, accédez à la skill 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écuter cet exemple :

  1. Type : 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 (Conseils) : Je ne sais pas comment définir le schéma JSON pour les arguments de l'outil. Il vérifie examples/WeatherTool.py.
  5. Complétion : il modifie le fichier pour ajouter requests.get(...) et définit l'argument du code boursier dans le schéma, en respectant exactement le style de l'ADK.

6. Félicitations

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

  • Outil de mise en forme des commits Git.
  • Ajout d'un en-tête de licence.
  • JSON vers Pydantic.
  • Validateur de schéma de base de données.
  • Structure de l'outil ADK.

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

Documents de référence