Google Antigravity-Skills erstellen

1. Einführung

Google Antigravity ist eine agentische IDE von Google. In diesem Codelab verwenden wir Antigravity, um Agent Skills zu erstellen. Das ist ein leichtgewichtiges, offenes Format, mit dem die Funktionen von KI-Agenten mit spezialisiertem Wissen und spezialisierten Workflows erweitert werden können. Sie erfahren, was Agent Skills sind, welche Vorteile sie bieten und wie sie aufgebaut sind. Anschließend erstellen Sie mehrere Agent Skills, darunter einen Git-Formatter, einen Vorlagengenerator und ein Tool-Code-Scaffolding. Alle diese Skills können in Antigravity verwendet werden.

Voraussetzungen :

2. Warum Skills?

Moderne KI-Agenten haben sich von einfachen Zuhörern zu komplexen Denkmaschinen entwickelt, die in lokale Dateisysteme und externe Tools (über MCP-Server) eingebunden werden können. Wenn Sie einen Agenten jedoch wahllos mit gesamten Codebasen und Hunderten von Tools beladen, führt das zu einer Kontextübersättigung und einem „Tool-Bloat“. Selbst bei großen Kontextfenstern verursacht das Speichern von 40.000 bis 50.000 Tokens ungenutzter Tools im aktiven Speicher eine hohe Latenz, finanzielle Verschwendung und „Kontextverfall“, bei dem das Modell durch irrelevante Daten verwirrt wird.

Die Lösung: Agent Skills

Um dieses Problem zu lösen, hat Anthropic Agent Skills eingeführt und die Architektur von einem monolithischen Kontextladen zu einer progressiven Offenlegung verlagert. Anstatt das Modell zu zwingen, sich zu Beginn einer Sitzung jeden spezifischen Workflow (z. B. Datenbankmigrationen oder Sicherheitsaudits) zu „merken“, werden diese Funktionen in modulare, auffindbare Einheiten verpackt.

Funktionsweise

Das Modell wird zunächst nur einem leichtgewichtigen „Menü“ mit Metadaten ausgesetzt. Das umfangreiche prozedurale Wissen (Anweisungen und Skripts) wird nur geladen, wenn die Absicht des Nutzers genau mit einem Skill übereinstimmt. So erhält ein Entwickler, der die Authentifizierungsmiddleware refaktorieren möchte, den Sicherheitskontext, ohne dass nicht verwandte CSS-Pipelines geladen werden. Der Kontext bleibt also schlank, schnell und kostengünstig.

d3f4bcb065a19fea.png

3. Agent Skills und Antigravity

Im Antigravity-Ökosystem fungiert der Agent Manager als Gehirn und der Editor als Leinwand. Skills sind spezialisierte Trainingsmodule, die die Lücke zwischen dem generalistischen Gemini 3-Modell und Ihrem spezifischen Kontext schließen. Sie ermöglichen es dem Agenten, nur dann einen definierten Satz von Anweisungen und Protokollen zu „verwenden“ – z. B. Standards für die Datenbankmigration oder Sicherheitsprüfungen –, wenn eine entsprechende Aufgabe angefordert wird. Durch das dynamische Laden dieser Ausführungsprotokolle verwandeln Skills die KI effektiv von einem generischen Programmierer in einen Spezialisten, der sich strikt an die kodifizierten Best Practices und Sicherheitsstandards eines Unternehmens hält.

Was ist ein Skill in Antigravity?

Im Kontext von Google Antigravity ist ein Skill ein verzeichnisbasiertes Paket, das eine Definitionsdatei (SKILL.md) und optionale unterstützende Assets (Skripts, Referenzen, Vorlagen) enthält.

Es ist ein Mechanismus zur bedarfsgerechten Erweiterung der Funktionen.

  • Bedarfsgerecht: Im Gegensatz zu einem System-Prompt, der immer geladen wird, wird ein Skill nur dann in den Kontext des Agenten geladen, wenn der Agent feststellt, dass er für die aktuelle Anfrage des Nutzers relevant ist. So wird das Kontextfenster optimiert und der Agent wird nicht durch irrelevante Anweisungen abgelenkt. In großen Projekten mit Dutzenden von Tools ist dieses selektive Laden entscheidend für die Leistung und die Genauigkeit der Schlussfolgerungen.
  • Erweiterung der Funktionen: Skills können mehr als nur Anweisungen geben. Sie können auch ausgeführt werden. Durch das Bündeln von Python- oder Bash-Skripts kann ein Skill dem Agenten die Möglichkeit geben, komplexe, mehrstufige Aktionen auf dem lokalen Computer oder in externen Netzwerken auszuführen, ohne dass der Nutzer Befehle manuell ausführen muss. So wird der Agent von einem Textgenerator zu einem Tool-Nutzer.

Skills im Vergleich zum Ökosystem (Tools, Regeln und Workflows)

Während das Model Context Protocol (MCP) als „Hände“ des Agenten fungiert und robuste, dauerhafte Verbindungen zu externen Systemen wie GitHub oder PostgreSQL bereitstellt, fungieren Skills als „Gehirn“, das sie steuert.

MCP verwaltet die zustandsbehaftete Infrastruktur, während Skills leichtgewichtige, kurzlebige Aufgabendefinitionen sind, die die Methodik für die Verwendung dieser Tools enthalten. Dieser serverlose Ansatz ermöglicht es Agenten, Ad-hoc-Aufgaben auszuführen (z. B. Changelogs oder Migrationen zu generieren), ohne den betrieblichen Aufwand für die Ausführung dauerhafter Prozesse. Der Kontext wird nur geladen, wenn die Aufgabe aktiv ist, und sofort wieder freigegeben.

Funktional nehmen Skills eine einzigartige Mittelstellung zwischen „Regeln“ (passive, immer aktive Schutzmaßnahmen) und „Workflows“ (aktive, nutzergesteuerte Makros) ein. Im Gegensatz zu Workflows, die bestimmte Befehle erfordern (z.B. /test), werden Skills vom Agenten ausgelöst: Das Modell erkennt automatisch die Absicht des Nutzers und stellt dynamisch das erforderliche Fachwissen bereit. Diese Architektur ermöglicht eine leistungsstarke Zusammensetzung. So kann beispielsweise eine globale Regel die Verwendung eines „Safe-Migration“-Skills bei Datenbankänderungen erzwingen oder ein einzelner Workflow kann mehrere Skills orchestrieren, um eine robuste Bereitstellungspipeline zu erstellen.

4. Skills erstellen

Das Erstellen eines Skills in Antigravity folgt einer bestimmten Verzeichnisstruktur und einem bestimmten Dateiformat. Diese Standardisierung sorgt dafür, dass Skills portabel sind und der Agent sie zuverlässig parsen und ausführen kann. Das Design ist bewusst einfach und basiert auf weit verbreiteten Formaten wie Markdown und YAML. So wird die Einstiegshürde für Entwickler gesenkt, die die Funktionen ihrer IDE erweitern möchten.

Verzeichnisstruktur

Skills können in zwei Bereichen definiert werden, um sowohl projektspezifische als auch nutzerspezifische Anpassungen zu ermöglichen :

  1. Arbeitsbereichsbereich: Befindet sich in <workspace-root>/.agent/skills/. Diese Skills sind nur innerhalb des jeweiligen Projekts verfügbar. Das ist ideal für projektspezifische Skripts, z. B. für die Bereitstellung in einer bestimmten Umgebung, die Datenbankverwaltung für diese App oder das Generieren von Boilerplate-Code für ein proprietäres Framework.
  2. Globaler Bereich: Befindet sich in ~/.gemini/antigravity/skills/. Diese Skills sind in allen Projekten auf dem Computer des Nutzers verfügbar. Das ist für allgemeine Dienstprogramme wie „JSON formatieren“, „UUIDs generieren“, „Code-Stil überprüfen“ oder die Integration mit persönlichen Produktivitätstools geeignet.

Ein typisches Skill-Verzeichnis sieht so aus:

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)

Diese Struktur trennt die Zuständigkeiten effektiv. Die Logik (scripts) ist von der Anweisung (SKILL.md) und dem Wissen (references) getrennt, was den Standardpraktiken der Softwareentwicklung entspricht.

Die Definitionsdatei SKILL.md

Die Datei SKILL.md ist das Gehirn des Skills. Sie teilt dem Agenten mit, was der Skill ist, wann er verwendet werden soll und wie er ausgeführt wird.

Sie besteht aus zwei Teilen:

  • YAML-Frontmatter
  • Markdown-Body.

YAML-Frontmatter

Das ist die Metadatenebene. Sie ist der einzige Teil des Skills, der vom übergeordneten Router des Agenten indexiert wird. Wenn ein Nutzer einen Prompt sendet, gleicht der Agent den Prompt semantisch mit den Beschreibungsfeldern aller verfügbaren Skills ab.

---
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.
---

Wichtige Felder:

  • name: Das ist nicht obligatorisch. Muss innerhalb des Bereichs eindeutig sein. Kleinbuchstaben, Bindestriche sind zulässig (z.B. postgres-query, pr-reviewer). Wenn kein Name angegeben wird, wird standardmäßig der Verzeichnisname verwendet.
  • description: Das ist ein Pflichtfeld und das wichtigste Feld. Es fungiert als „Triggerphrase“. Sie muss aussagekräftig genug sein, damit das LLM die semantische Relevanz erkennen kann. Eine vage Beschreibung wie „Datenbanktools“ reicht nicht aus. Eine genaue Beschreibung wie „Führt schreibgeschützte SQL-Abfragen für die lokale PostgreSQL-Datenbank aus, um Nutzer- oder Transaktionsdaten abzurufen. Verwenden Sie diese Option, um Datenzustände zu debuggen“ sorgt dafür, dass der Skill korrekt ausgewählt wird.

Der Markdown-Body

Der Body enthält die Anweisungen. Das ist „Prompt Engineering“, das in einer Datei gespeichert wird. Wenn der Skill aktiviert wird, wird dieser Inhalt in das Kontextfenster des Agenten eingefügt.

Der Body sollte Folgendes enthalten:

  1. Ziel: Eine klare Aussage darüber, was der Skill erreicht.
  2. Anweisungen: Schrittweise Logik.
  3. Beispiele: Wenige Beispiele für Eingaben und Ausgaben, um die Leistung des Modells zu steuern.
  4. Einschränkungen: „Nicht“-Regeln (z.B. „Keine DELETE-Abfragen ausführen“).

Beispiel für einen SKILL.md-Body :

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.

Skriptintegration

Eine der leistungsstärksten Funktionen von Skills ist die Möglichkeit, die Ausführung an Skripts zu delegieren. So kann der Agent Aktionen ausführen, die für ein LLM schwierig oder unmöglich sind (z. B. binäre Ausführung, komplexe mathematische Berechnungen oder die Interaktion mit Legacy-Systemen).

Skripts werden im Unterverzeichnis scripts/ platziert. In der Datei SKILL.md wird über den relativen Pfad auf sie verwiesen.

5. Skills erstellen

In diesem Abschnitt erstellen wir Skills, die in Antigravity integriert werden können, und zeigen schrittweise verschiedene Funktionen wie Ressourcen und Skripts.

Sie können die Skills hier aus dem GitHub-Repository herunterladen: https://github.com/rominirani/antigravity-skills.

Wir können jeden dieser Skills entweder im Ordner ~/.gemini/antigravity/skills oder im Ordner /.agent/skills platzieren.

Level 1 : Der grundlegende Router ( git-commit-formatter )

Das ist sozusagen das „Hello World“ der Skills.

Entwickler schreiben oft faule Commit-Nachrichten, z.B. „wip“, „fix bug“ oder „updates“. Die manuelle Durchsetzung von „Conventional Commits“ ist mühsam und wird oft vergessen. Wir implementieren einen Skill, der die Spezifikation für Conventional Commits erzwingt. Indem wir den Agenten einfach über die Regeln informieren, können wir ihn als Durchsetzer einsetzen.

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

Die Datei SKILL.md sieht so aus:

---
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`

So führen Sie dieses Beispiel aus :

  1. Nehmen Sie eine kleine Änderung an einer beliebigen Datei in Ihrem Arbeitsbereich vor.
  2. Öffnen Sie den Chat und geben Sie Folgendes ein: Commit these changes.
  3. Der Agent führt nicht nur „git commit“ aus. Er aktiviert zuerst den Skill „git-commit-formatter“.
  4. Ergebnis: Es wird eine konventionelle Git-Commit-Nachricht vorgeschlagen.

Ich habe Antigravity beispielsweise einige Kommentare zu einer Python-Beispieldatei hinzufügen lassen. Das Ergebnis war eine Git-Commit-Nachricht wie docs: add detailed comments to demo_primes.py.

Level 2: Asset-Nutzung (license-header-adder)

Das ist das Muster „Referenz“.

Jede Quelldatei in einem Unternehmensprojekt benötigt möglicherweise einen bestimmten 20-zeiligen Apache 2.0-Lizenzheader. Diesen statischen Text direkt in den Prompt (oder in die Datei SKILL.md) einzufügen, ist verschwenderisch. Jedes Mal, wenn der Skill indexiert wird, werden Tokens verbraucht und das Modell kann Tippfehler im Rechtstext „halluzinieren“.

Lagern Sie den statischen Text in eine Nur-Text-Datei im Ordner resources/ aus. Der Skill weist den Agenten an, diese Datei nur bei Bedarf zu lesen.

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

Die Datei SKILL.md sieht so aus:

---
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 `<!-- ... -->`.

So führen Sie dieses Beispiel aus :

  1. Erstellen Sie eine neue Dummy-Python-Datei: touch my_script.py
  2. Geben Sie Folgendes ein: Add the license header to my_script.py.
  3. Der Agent liest license-header-adder/resources/HEADER_TEMPLATE.txt.
  4. Er fügt den Inhalt genau so, wortwörtlich, in Ihre Datei ein.

Level 3: Lernen anhand von Beispielen (json-to-pydantic)

Das Muster „Few-Shot“.

Das Konvertieren von losen Daten (z. B. einer JSON-API-Antwort) in strengen Code (z. B. Pydantic-Modelle) erfordert Dutzende von Entscheidungen. Wie sollen wir die Klassen benennen? Sollen wir Optional verwenden? snake_case oder camelCase? Diese 50 Regeln auf Englisch zu formulieren, ist mühsam und fehleranfällig.

LLMs sind Mustererkennungs-Engines.

Ein gutes Beispiel (Input -> Output) ist oft effektiver als ausführliche Anweisungen.

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

Die Datei SKILL.md sieht so aus:

---
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`.

Im Ordner /examples befinden sich die JSON-Datei und die Ausgabedatei , also die Python-Datei. Beide werden unten dargestellt:

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

So führen Sie dieses Beispiel aus :

  1. Geben Sie dem Agenten einen JSON-Snippet (fügen Sie ihn in den Chat ein oder verweisen Sie auf eine Datei).

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

  1. Geben Sie Folgendes ein: Convert this JSON to a Pydantic model.
  2. Der Agent sieht sich das Paar examples im Skill-Ordner an.
  3. Er generiert eine Python-Klasse, die den Codierungsstil, die Importe und die Struktur von output_model.py perfekt nachahmt, einschließlich der Behandlung des Null-Bestands als „Optional“.

Eine Beispielausgabe (product_model.py) sieht so aus:

from pydantic import BaseModel
from typing import Optional

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

Level 4: Prozedurale Logik (database-schema-validator)

Das ist das Muster „Tool-Nutzung“.

Wenn Sie ein LLM fragen, ob ein Schema sicher ist, wird es möglicherweise sagen, dass alles in Ordnung ist, auch wenn ein kritischer Primärschlüssel fehlt. Das liegt daran, dass der SQL-Code korrekt aussieht.

Delegieren wir diese Prüfung an ein deterministisches Skript. Wir verwenden den Skill, um den Agenten so zu steuern, dass er ein von uns geschriebenes Python-Skript ausführt. Das Skript liefert eine binäre (wahr/falsch) Antwort.

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

Die Datei SKILL.md sieht so aus:

---
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.

Die Datei validate_schema.py sieht so aus:

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])

So führen Sie dieses Beispiel aus :

  1. Erstellen Sie eine fehlerhafte SQL-Datei bad_schema.sql: CREATE TABLE users (name TEXT);
  2. Geben Sie Folgendes ein: Validate bad_schema.sql.
  3. Der Agent rät nicht. Er ruft das Skript auf, das fehlschlägt (Exit-Code 1), und meldet uns, dass die Validierung fehlgeschlagen ist, weil die Tabelle „users“ keinen Primärschlüssel hat.

Level 5: Der Architekt (adk-tool-scaffold)

Dieses Muster deckt die meisten Funktionen ab, die in Skills verfügbar sind.

Komplexe Aufgaben erfordern oft eine Abfolge von Operationen, die alles kombinieren, was wir bisher gesehen haben: Dateien erstellen, Vorlagen verwenden und Logik schreiben. Das Erstellen eines neuen Tools für das ADK (Agent Development Kit) erfordert all das.

Wir kombinieren:

  • Skript (zur Verarbeitung der Dateierstellung/des Scaffolding)
  • Vorlage (zur Verarbeitung von Boilerplate-Code in Ressourcen)
  • Ein Beispiel (zur Steuerung der Logikgenerierung).
adk-tool-scaffold/
├── SKILL.md
├── resources/
│   └── ToolTemplate.py.hbs (Jinja2 Template)
├── scripts/
│   └── scaffold_tool.py    (Generator Script)
└── examples/
    └── WeatherTool.py      (Reference Implementation)

Die Datei SKILL.md sieht so aus. Im Repository der Skills können Sie die Dateien in den Ordnern „scripts“, „resources“ und „examples“ überprüfen. Für diesen speziellen Skill rufen Sie den Skill adk-tool-scaffold auf.

---
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.

So führen Sie dieses Beispiel aus :

  1. Geben Sie Folgendes ein: Create a new ADK tool called StockPrice to fetch data from an API.
  2. Schritt 1 (Scaffolding): Der Agent führt das Python-Skript aus. Dadurch wird sofort StockPriceTool.py mit der richtigen Klassenstruktur, den richtigen Importen und dem richtigen Klassennamen StockPriceTool erstellt.
  3. Schritt 2 (Implementierung): Der Agent „liest“ die gerade erstellte Datei. Er sieht # TODO: Implement logic.
  4. Schritt 3 (Anleitung): Er ist sich nicht sicher, wie das JSON-Schema für die Tool-Argumente definiert werden soll. Er überprüft examples/WeatherTool.py.
  5. Abschluss: Er bearbeitet die Datei, um requests.get(...) hinzuzufügen, und definiert das Ticker-Argument im Schema, genau wie im ADK-Stil.

6. Glückwunsch

Sie haben das Lab zu Antigravity Skills erfolgreich abgeschlossen und die folgenden Skills erstellt:

  • Git-Commit-Formatter
  • Lizenzheader-Adder
  • JSON zu Pydantic
  • Datenbankschema-Validator
  • ADK-Tool-Scaffolding

Agent Skills sind eine hervorragende Möglichkeit, Antigravity so zu nutzen, dass Code auf Ihre Weise geschrieben wird, Regeln eingehalten werden und Ihre Tools verwendet werden.

Referenzdokumente