Erste Schritte mit Skills in Google Antigravity

1. Einführung

Google Antigravity (im restlichen Dokument als Antigravity bezeichnet) ist eine agentenbasierte IDE von Google. Im Codelab „Erste Schritte mit Antigravity“ können Sie die Grundlagen von Antigravity kennenlernen. In diesem Codelab verwenden wir Antigravity, um Agent Skills zu erstellen. Das ist ein einfaches, offenes Format, mit dem die Funktionen von KI-Agenten mit spezialisiertem Wissen und 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, die von einem Git-Formatierungstool über einen Vorlagengenerator bis hin zu Tool-Code-Scaffolding reichen und alle in Antigravity verwendet werden können.

Voraussetzungen:

  • Google Antigravity ist installiert und konfiguriert.
  • Grundlegendes Verständnis von Google Antigravity. Wir empfehlen, das Codelab Erste Schritte mit Google Antigravity durchzuarbeiten.

2. Warum Skills?

Moderne KI-Agenten haben sich von einfachen Zuhörern zu komplexen Denkern entwickelt, die sich in lokale Dateisysteme und externe Tools (über MCP-Server) integrieren lassen. Wenn Sie einen Agenten jedoch wahllos mit ganzen Codebases und Hunderten von Tools laden, führt das zu Context Saturation und „Tool Bloat“. Selbst bei großen Kontextfenstern führt das Speichern von 40.000 bis 50.000 Tokens ungenutzter Tools im aktiven Arbeitsspeicher zu hoher Latenz, finanzieller 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 vom monolithischen Kontextladen auf Progressive Disclosure umgestellt. Anstatt das Modell zu zwingen, sich zu Beginn einer Sitzung jeden spezifischen Workflow (z. B. Datenbankmigrationen oder Sicherheitsüberprüfungen) zu „merken“, werden diese Funktionen in modulare, auffindbare Einheiten verpackt.

Funktionsweise

Das Modell wird anfangs nur mit einem einfachen „Menü“ von Metadaten konfrontiert. Das umfangreiche prozedurale Wissen (Anleitungen und Skripts) wird nur geladen, wenn die Absicht des Nutzers genau mit einem Skill übereinstimmt. So wird dafür gesorgt, dass ein Entwickler, der eine Refaktorierung der Authentifizierungs-Middleware anfordert, den Sicherheitskontext erhält, ohne dass nicht zugehörige CSS-Pipelines geladen werden. Der Kontext bleibt also schlank, schnell und kostengünstig.

d3f4bcb065a19fea.png

3. Agenten-Skills und Antigravity

Im Antigravity-Ökosystem sind Skills spezialisierte Trainingsmodule, die die Lücke zwischen dem Generalistenmodell Gemini 3 und Ihrem spezifischen Kontext schließen. Der Agent Manager ist das Gehirn und der Editor die Leinwand. So kann der Agent nur dann einen bestimmten Satz von Anweisungen und Protokollen „ausführen“, wenn eine entsprechende Aufgabe angefordert wird. Beispiele hierfür sind Datenbankmigrationsstandards oder Sicherheitsprüfungen. Durch das dynamische Laden dieser Ausführungsprotokolle werden Skills effektiv von einer generischen KI zu einem Spezialisten, der sich strikt an die kodifizierten Best Practices und Sicherheitsstandards einer Organisation hält.

Was ist eine Fähigkeit 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 handelt sich um einen Mechanismus zur On-Demand-Erweiterung von Funktionen.

  • Bei Bedarf: Im Gegensatz zu einem System-Prompt, der immer geladen wird, wird ein Skill nur in den Kontext des Agents geladen, wenn der Agent feststellt, dass er für die aktuelle Anfrage des Nutzers relevant ist. Dadurch 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.
  • Capability Extension: Skills können mehr als nur Anweisungen geben; sie können auch Aktionen ausführen. Durch das Bündeln von Python- oder Bash-Skripts kann ein Skill dem Agent 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. Dadurch wird der Agent von einem Textgenerator zu einem Tool-Nutzer.

Fähigkeiten im Vergleich zum Ökosystem (Tools, Regeln und Workflows)

Das Model Context Protocol (MCP) fungiert als „Hände“ des Agents und stellt leistungsstarke, dauerhafte Verbindungen zu externen Systemen wie GitHub oder PostgreSQL bereit. Skills fungieren als „Gehirn“, das die Aktionen des Agents steuert.

MCP verwaltet die zustandsorientierte Infrastruktur, während Skills einfache, kurzlebige Aufgabendefinitionen sind, die die Methodik für die Verwendung dieser Tools enthalten. Dieser serverlose Ansatz ermöglicht es Agents, Ad-hoc-Aufgaben wie das Generieren von Changelogs oder Migrationen auszuführen, ohne dass der operative Aufwand für die Ausführung persistenter Prozesse entsteht. Der Kontext wird nur geladen, wenn die Aufgabe aktiv ist, und sofort wieder freigegeben.

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

4. Skills erstellen

Beim Erstellen eines Skills in Antigravity müssen Sie eine bestimmte Verzeichnisstruktur und ein bestimmtes Dateiformat einhalten. Diese Standardisierung sorgt dafür, dass Skills portierbar sind und der Agent sie zuverlässig parsen und ausführen kann. Das Design ist bewusst einfach gehalten 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, sodass sowohl projektspezifische als auch nutzerspezifische Anpassungen möglich sind :

  1. Workspace-Bereich: 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 Umfang: Befindet sich in ~/.gemini/antigravity/skills/. Diese Skills sind für alle Projekte auf dem Computer des Nutzers verfügbar. Dies eignet sich für allgemeine Dienstprogramme wie „JSON formatieren“, „UUIDs generieren“, „Code-Stil überprüfen“ oder die Integration in persönliche Produktivitätstools.

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 Anliegen effektiv. Die Logik (scripts) ist von der Anweisung (SKILL.md) und dem Wissen (references) getrennt, was den Standardverfahren der Softwareentwicklung entspricht.

Die Definitionsdatei SKILL.md

Die Datei SKILL.md ist das Gehirn des Skills. Sie geben dem Agenten Informationen dazu, 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

Dies ist die Metadatenebene. Es ist der einzige Teil des Skill, der vom High-Level-Router des Agents indexiert wird. Wenn ein Nutzer einen Prompt sendet, vergleicht der Agent den Prompt semantisch mit den Beschreibungsfeldern aller verfügbaren Skills.

---
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: Dies ist nicht obligatorisch. Muss innerhalb des Bereichs eindeutig sein. Kleinbuchstaben und Bindestriche sind zulässig (z.B. postgres-query, pr-reviewer). Wenn sie nicht angegeben wird, wird standardmäßig der Verzeichnisname verwendet.
  • description: Dieses Feld ist obligatorisch und das wichtigste. Sie fungiert als „Auslösephrase“. 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. „Use this for debugging data states“ (Verwende dies zum Debuggen von Datenstatus) sorgt dafür, dass der Skill richtig erkannt wird.

Der Markdown-Text

Der Textkörper enthält die Anleitung. Hierbei handelt es sich um „Prompt Engineering“, das in einer Datei gespeichert wird. Wenn der Skill aktiviert ist, werden diese Inhalte in das Kontextfenster des Agent eingefügt.

Der Body sollte Folgendes enthalten:

  1. Ziel: Eine klare Aussage dazu, was mit dem Skill erreicht werden soll.
  2. Anleitung: Schrittweise Logik.
  3. Beispiele: Beispiele für Eingaben und Ausgaben, die das Modell bei der Leistung unterstützen.
  4. Einschränkungen: „Nicht“-Regeln (z.B. „DELETE-Abfragen nicht ausführen“).

Beispiel für den Text von 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.

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 direkt schwierig oder unmöglich sind, z. B. die Ausführung von Binärdateien, komplexe mathematische Berechnungen oder die Interaktion mit Legacy-Systemen.

Skripts werden im Unterverzeichnis scripts/ abgelegt. Im SKILL.md wird mit einem relativen Pfad auf sie verwiesen.

5. Fähigkeiten zur Erstellung von Inhalten

In diesem Abschnitt geht es darum, Skills zu entwickeln, die in Antigravity integriert werden, und nach und nach verschiedene Funktionen wie Ressourcen/Scripts usw. zu präsentieren.

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

Wir können jede dieser Fähigkeiten entweder im Ordner ~/.gemini/antigravity/skills oder im Ordner /.agent/skills platzieren.

Stufe 1 : Der Basic Router ( git-commit-formatter )

Das ist sozusagen das „Hallo Welt“ der Skills.

Entwickler schreiben oft unzureichende Commit-Nachrichten, z.B. „wip“ (work in progress), „fix bug“ (Fehler beheben) oder „updates“ (Aktualisierungen). Die manuelle Durchsetzung von „Conventional Commits“ ist mühsam und wird oft vergessen. Wir implementieren einen Skill, der die Conventional Commits-Spezifikation erzwingt. Indem wir den Agenten einfach über die Regeln informieren, kann er sie auch durchsetzen.

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

Die SKILL.md-Datei wird unten angezeigt:

---
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.“ (Übernehme diese Änderungen per Commit.)
  3. Der Agent führt nicht nur „git commit“ aus. Zuerst wird der Skill „git-commit-formatter“ aktiviert.
  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)

Dies ist das Muster „Referenz“.

Für jede Quellcodedatei in einem Unternehmensprojekt ist möglicherweise eine bestimmte 20-zeilige Apache 2.0-Lizenzkopfzeile erforderlich. Es ist ineffizient, diesen statischen Text direkt in den Prompt (oder SKILL.md) einzufügen. Bei jeder Indexierung des Skills werden Tokens verbraucht und das Modell kann Tippfehler in Rechtstexten „halluzinieren“.

Statischen Text in eine Nur-Text-Datei in einem resources/-Ordner auslagern. Der Skill weist den Agenten an, diese Datei nur bei Bedarf zu lesen.

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? Sollten wir Optional verwenden? snake_case oder camelCase? Diese 50 Regeln auf Englisch zu formulieren, ist mühsam und fehleranfällig.

LLMs sind Engines zum Abgleich von Mustern.

Ein gutes Beispiel (Eingabe –> Ausgabe) ist oft effektiver als ausführliche Anweisungen.

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

Die SKILL.md-Datei wird unten angezeigt:

---
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. Typ: Add the license header to my_script.py.
  3. Der Kundenservicemitarbeiter liest license-header-adder/resources/HEADER_TEMPLATE.txt vor.
  4. Der Inhalt wird genau und wortwörtlich in Ihre Datei eingefügt.

Stufe 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? Sollten wir Optional verwenden? snake_case oder camelCase? Diese 50 Regeln auf Englisch zu formulieren, ist mühsam und fehleranfällig.

LLMs sind Engines zum Abgleich von Mustern. Ein gutes Beispiel (Eingabe –> Ausgabe) 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 SKILL.md-Datei wird unten angezeigt:

---
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 , d.h. 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. Stellen Sie dem Agenten ein JSON-Snippet zur Verfügung (fügen Sie es in den Chat ein oder verweisen Sie auf eine Datei).

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

  1. Typ: Convert this JSON to a Pydantic model.
  2. Der Agent sieht sich das examples-Paar im Skill-Ordner an.
  3. Es wird eine Python-Klasse generiert, die den Codierungsstil, die Importe und die Struktur von output_model.py perfekt nachahmt, einschließlich der Behandlung des Nullbestands als Optional.

Hier sehen Sie ein Beispiel für eine Ausgabe (product_model.py):

from pydantic import BaseModel
from typing import Optional

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

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

Dies ist das Muster „Tool Use“.

Wenn Sie ein LLM fragen: „Ist dieses Schema sicher?“, antwortet es möglicherweise, dass alles in Ordnung ist, auch wenn ein wichtiger Primärschlüssel fehlt, einfach weil der SQL-Code korrekt aussieht.

Wir delegieren diese Prüfung an ein deterministisches Script. Wir verwenden den Skill, um den Agenten so zu routen, dass er ein von uns geschriebenes Python-Skript ausführt. Das Skript liefert binäre (True/False) Wahrheitswerte.

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

Die SKILL.md-Datei wird unten angezeigt:

---
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 validate_schema.py-Datei wird unten angezeigt:

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. Typ: Validate bad_schema.sql.
  3. Der KI-Agent rät nicht. Dadurch wird das Script aufgerufen, das fehlschlägt (Exit-Code 1). Wir erhalten dann die Meldung, dass die Validierung fehlgeschlagen ist, weil in der Tabelle „users“ kein Primärschlüssel vorhanden ist.

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

Dieses Muster deckt die meisten in Skills verfügbaren Funktionen ab.

Komplexe Aufgaben erfordern oft eine Reihe von Vorgängen, die alles kombinieren, was wir bisher gesehen haben: Dateien erstellen, Vorlagen folgen und Logik schreiben. Um ein neues Tool für das ADK (Agent Development Kit) zu erstellen, ist all das erforderlich.

Wir kombinieren:

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

Die SKILL.md-Datei wird unten angezeigt. Im Repository für Skills finden Sie die Dateien in den Ordnern „scripts“, „resources“ und „examples“. Rufen Sie für diesen Skill 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. Typ: 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. Es sieht # TODO: Implement logic.
  4. Schritt 3 (Anleitung): Es ist unklar, wie das JSON-Schema für die Tool-Argumente definiert werden soll. Dabei wird examples/WeatherTool.py geprüft.
  5. Vervollständigung: Die Datei wird bearbeitet, um requests.get(...) hinzuzufügen, und das Ticker-Argument wird im Schema definiert, genau wie im ADK.

6. Glückwunsch

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

  • Git-Commit-Formatierungsprogramm.
  • Tool zum Hinzufügen von Lizenzheadern.
  • JSON zu Pydantic.
  • Datenbankschema-Validator.
  • ADK-Tool-Scaffolding.

Agent-Skills sind eine hervorragende Möglichkeit, Antigravity dazu zu bringen, Code auf Ihre Weise zu schreiben, Regeln zu befolgen und Ihre Tools zu verwenden.

Referenzdokumente