5 Design-Muster für Agent-Skills, die jeder ADK-Entwickler kennen sollte

𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 – Die fünf Design Patterns, die du kennen musst

Wenn es um 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍 geht, konzentrieren sich Entwickler meist auf das Format – das YAML richtig hinzubekommen, Verzeichnisse strukturieren und die Spezifikation einhalten. Aber da sich mittlerweile mehr als 30 Agent-Tools (wie Claude Code, Gemini CLI und Cursor) auf dasselbe Layout standardisieren, ist das Formatierungsproblem praktisch obsolet.

Die eigentliche Herausforderung liegt jetzt im Content-Design. Die Spezifikation erklärt zwar, wie man eine Fähigkeit (Skill) verpackt, gibt aber keinerlei Anleitung, wie die Logik darin strukturiert sein sollte. Ein Skill, der FastAPI-Konventionen kapselt, funktioniert beispielsweise völlig anders als eine vierstufige Dokumentations-Pipeline – auch wenn ihre 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍-Dateien von außen identisch aussehen.

Durch die Analyse, wie Skills im gesamten Ökosystem gebaut werden – von Anthropics Repositories bis zu Vercels und Googles internen Richtlinien – haben sich fünf wiederkehrende Design-Muster herauskristallisiert, die Entwicklern beim Bau von Agents helfen.

Von @Saboo_Shubham_ und @lavinigam

Dieser Artikel behandelt jedes Muster mit funktionierendem ADK-Code:

• Tool Wrapper: Mache deinen Agent zum Sofort-Experten für jede Bibliothek
• Generator: Erstelle strukturierte Dokumente aus einer wiederverwendbaren Vorlage
• Reviewer: Bewerte Code anhand einer Checkliste nach Schweregrad
• Inversion: Der Agent interviewt dich, bevor er handelt
• Pipeline: Erzwinge einen strengen mehrstufigen Workflow mit Prüfpunkten

Pattern 1: Der Tool Wrapper

Ein Tool Wrapper gibt deinem Agent bei Bedarf Kontext für eine bestimmte Bibliothek. Anstatt API-Konventionen fest in deinen System-Prompt einzubauen, verpackst du sie in einen Skill. Dein Agent lädt diesen Kontext nur dann, wenn er tatsächlich mit dieser Technologie arbeitet.

Es ist das am einfachsten zu implementierende Muster. Die 𝚂𝙺𝙸𝙻𝙻.𝚖𝚍-Datei horcht auf bestimmte Bibliotheks-Keywords in der Benutzeranfrage, lädt dynamisch deine interne Dokumentation aus dem Verzeichnis 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ und wendet diese Regeln als absolute Wahrheit an. Dies ist genau der Mechanismus, mit dem du die internen Codierungsrichtlinien deines Teams oder spezifische Framework-Best-Practices direkt in die Workflows deiner Entwickler einfließen lässt.

Hier ist ein Beispiel eines Tool Wrappers, der einem Agent beibringt, wie man FastAPI-Code schreibt. Beachte, wie die Anweisungen dem Agent explizit sagen, die Datei 𝚌𝚘𝚗𝚟𝚎𝚗𝚝𝚒𝚘𝚗𝚜.𝚖𝚍 erst dann zu laden, wenn er mit dem Review oder Schreiben von Code beginnt:

1# skills/api-expert/SKILL.md
2---
3name: api-expert
4description: FastAPI-Entwicklungs-Best-Practices und Konventionen. Verwenden beim Erstellen, Überprüfen oder Debuggen von FastAPI-Anwendungen, REST-APIs oder Pydantic-Modellen.
5metadata:
6  pattern: tool-wrapper
7  domain: fastapi
8---
9
10Du bist ein Experte für FastAPI-Entwicklung. Wende diese Konventionen auf den Code oder die Frage des Benutzers an.
11
12## Kernkonventionen
13
14Lade 'references/conventions.md' für die vollständige Liste der FastAPI-Best-Practices.
15
16## Beim Überprüfen von Code
171. Lade die Konventionen-Referenz
182. Prüfe den Code des Benutzers gegen jede Konvention
193. Gib bei jeder Verletzung die spezifische Regel an und schlage die Korrektur vor
20
21## Beim Schreiben von Code
221. Lade die Konventionen-Referenz
232. Befolge jede Konvention genau
243. Füge Typannotationen zu allen Funktionssignaturen hinzu
254. Verwende den Annotated-Stil für Dependency Injection

Pattern 2: Der Generator

Während der Tool Wrapper Wissen anwendet, erzwingt der Generator konsistente Ausgaben. Wenn du damit kämpfst, dass ein Agent bei jeder Ausführung unterschiedliche Dokumentstrukturen erzeugt, löst der Generator dieses Problem, indem er einen Lückentext-Prozess orchestriert.

Er nutzt zwei optionale Verzeichnisse: 𝚊𝚜𝚜𝚎𝚝𝚜/ enthält deine Ausgabevorlage, und 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/ enthält deinen Style Guide. Die Anweisungen fungieren als Projektmanager. Sie sagen dem Agent, die Vorlage zu laden, den Style Guide zu lesen, den Benutzer nach fehlenden Variablen zu fragen und das Dokument zu befüllen. Dies ist praktisch für die Erstellung vorhersagbarer API-Dokumentation, die Standardisierung von Commit-Nachrichten oder das Gerüst von Projektarchitekturen.

In diesem Beispiel eines technischen Report-Generators enthält die Skill-Datei weder das eigentliche Layout noch die Grammatikregeln. Sie koordiniert lediglich den Abruf dieser Ressourcen und zwingt den Agent, sie Schritt für Schritt auszuführen:

1# skills/report-generator/SKILL.md
2---
3name: report-generator
4description: Erzeugt strukturierte technische Berichte in Markdown. Verwenden, wenn der Benutzer darum bittet, einen Bericht, eine Zusammenfassung oder ein Analyse-Dokument zu schreiben, zu erstellen oder zu entwerfen.
5metadata:
6  pattern: generator
7  output-format: markdown
8---
9
10Du bist ein Generator für technische Berichte. Führe diese Schritte genau aus:
11
12Schritt 1: Lade 'references/style-guide.md' für Ton und Formatierungsregeln.
13
14Schritt 2: Lade 'assets/report-template.md' für die erforderliche Ausgabestruktur.
15
16Schritt 3: Frage den Benutzer nach fehlenden Informationen, die zum Befüllen der Vorlage benötigt werden:
17- Thema oder Gegenstand
18- Wichtigste Erkenntnisse oder Datenpunkte
19- Zielgruppe (technisch, Führungskraft, allgemein)
20
21Schritt 4: Befülle die Vorlage gemäß den Style-Guide-Regeln. Jeder Abschnitt der Vorlage muss in der Ausgabe vorhanden sein.
22
23Schritt 5: Gib den fertigen Bericht als einzelnes Markdown-Dokument zurück.

Pattern 3: Der Reviewer

Das Reviewer-Muster trennt, was geprüft wird, von der Art und Weise, wie geprüft wird. Anstatt einen langen System-Prompt zu schreiben, der jeden Code-Geruch detailliert beschreibt, speicherst du eine modulare Bewertungsmatrix in einer Datei 𝚛𝚎𝚏𝚎𝚛𝚎𝚗𝚌𝚎𝚜/𝚛𝚎𝚟𝚒𝚎𝚠-𝚌𝚑𝚎𝚌𝚔𝚕𝚒𝚜𝚝.𝚖𝚍.

Wenn ein Benutzer Code einreicht, lädt der Agent diese Checkliste, bewertet die Einreichung methodisch und gruppiert seine Ergebnisse nach Schweregrad. Wenn du eine Python-Style-Checkliste gegen eine OWASP-Sicherheitscheckliste austauschst, erhältst du ein völlig anderes, spezialisiertes Audit mit derselben Skill-Infrastruktur. Es ist eine äußerst effektive Methode, um PR-Reviews zu automatisieren oder Schwachstellen zu erkennen, bevor ein Mensch den Code ansieht.

Der folgende Code-Reviewer-Skill demonstriert diese Trennung. Die Anweisungen bleiben statisch, aber der Agent lädt dynamisch die spezifischen Review-Kriterien aus einer externen Checkliste und erzwingt eine strukturierte, schweregradbasierte Ausgabe:

1# skills/code-reviewer/SKILL.md
2---
3name: code-reviewer
4description: Überprüft Python-Code auf Qualität, Stil und häufige Fehler. Verwenden, wenn der Benutzer Code zur Überprüfung einreicht, Feedback zu seinem Code anfordert oder ein Code-Audit wünscht.
5metadata:
6  pattern: reviewer
7  severity-levels: error,warning,info
8---
9
10Du bist ein Python-Code-Reviewer. Befolge dieses Review-Protokoll genau:
11
12Schritt 1: Lade 'references/review-checklist.md' für die vollständigen Review-Kriterien.
13
14Schritt 2: Lies den Code des Benutzers sorgfältig. Verstehe seinen Zweck, bevor du kritisierst.
15
16Schritt 3: Wende jede Regel aus der Checkliste auf den Code an. Gib für jede gefundene Verletzung an:
17- Die Zeilennummer (oder ungefähre Position)
18- Klassifiziere den Schweregrad: error (muss behoben werden), warning (sollte behoben werden), info (erwägenswert)
19- Erkläre, WARUM es ein Problem ist, nicht nur, WAS falsch ist
20- Schlage eine spezifische Korrektur mit verbessertem Code vor
21
22Schritt 4: Erstelle ein strukturiertes Review mit diesen Abschnitten:
23- **Zusammenfassung**: Was der Code tut, allgemeine Qualitätsbewertung
24- **Ergebnisse**: Gruppiert nach Schweregrad (zuerst errors, dann warnings, dann info)
25- **Punktzahl**: Bewertung von 1-10 mit kurzer Begründung
26- **Top 3 Empfehlungen**: Die wirkungsvollsten Verbesserungen

Pattern 4: Inversion (Umkehrung)

Agents neigen von Natur aus dazu, sofort zu raten und zu generieren. Das Inversion-Muster kehrt diese Dynamik um. Anstatt dass der Benutzer den Prompt vorgibt und der Agent ausführt, agiert der Agent als Interviewer.

Inversion beruht auf expliziten, nicht verhandelbaren Gating-Anweisungen (wie „Beginne NICHT mit dem Bauen, bis alle Phasen abgeschlossen sind"), um den Agent zu zwingen, zuerst Kontext zu sammeln. Er stellt strukturierte Fragen nacheinander und wartet auf deine Antworten, bevor er zur nächsten Phase übergeht. Der Agent weigert sich, ein endgültiges Ergebnis zu synthetisieren, bis er ein vollständiges Bild deiner Anforderungen und der bereitzustellenden Einschränkungen hat.

Um dies in Aktion zu sehen, sieh dir diesen Projektplaner-Skill an. Das entscheidende Element hier ist die strenge Phaseneinteilung und der explizite Gatekeeping-Prompt, der den Agent daran hindert, den endgültigen Plan zu synthetisieren, bis alle Benutzerantworten gesammelt sind:

1# skills/project-planner/SKILL.md
2---
3name: project-planner
4description: Plant ein neues Softwareprojekt, indem durch strukturierte Fragen Anforderungen gesammelt werden, bevor ein Plan erstellt wird. Verwenden, wenn der Benutzer sagt "Ich möchte bauen", "hilf mir zu planen", "entwirf ein System" oder "starte ein neues Projekt".
5metadata:
6  pattern: inversion
7  interaction: multi-turn
8---
9
10Du führst ein strukturiertes Anforderungsinterview. Beginne NICHT mit dem Bauen oder Entwerfen, bis alle Phasen abgeschlossen sind.
11
12## Phase 1 — Problemfindung (stelle jeweils eine Frage, warte auf jede Antwort)
13
14Stelle diese Fragen in der angegebenen Reihenfolge. Überspringe keine.
15
16- F1: "Welches Problem löst dieses Projekt für seine Benutzer?"
17- F2: "Wer sind die primären Benutzer? Welches technische Niveau haben sie?"
18- F3: "Welche Größenordnung wird erwartet? (Benutzer pro Tag, Datenvolumen, Anfragenrate)"
19
20## Phase 2 — Technische Einschränkungen (nur nachdem Phase 1 vollständig beantwortet ist)
21
22- F4: "Welche Bereitstellungsumgebung wirst du verwenden?"
23- F5: "Hast du Anforderungen oder Präferenzen bezüglich des Technologie-Stacks?"
24- F6: "Was sind die nicht verhandelbaren Anforderungen? (Latenz, Verfügbarkeit, Compliance, Budget)"
25
26## Phase 3 — Synthese (nur nachdem alle Fragen beantwortet sind)
27
281. Lade 'assets/plan-template.md' für das Ausgabeformat
292. Befülle jeden Abschnitt der Vorlage mit den gesammelten Anforderungen
303. Präsentiere dem Benutzer den fertigen Plan
314. Frage: "Erfasst dieser Plan deine Anforderungen genau? Was würdest du ändern?"
325. Iteriere auf der Grundlage des Feedbacks, bis der Benutzer bestätigt

Pattern 5: Die Pipeline

Bei komplexen Aufgaben kannst du dir keine übersprungenen Schritte oder ignorierte Anweisungen leisten. Das Pipeline-Muster erzwingt einen strengen, sequenziellen Workflow mit harten Prüfpunkten.

Die Anweisungen selbst dienen als Workflow-Definition. Durch die Implementierung expliziter Diamant-Gate-Bedingungen (wie die Anforderung einer Benutzerfreigabe, bevor von der Docstring-Generierung zur endgültigen Zusammenstellung übergegangen wird) stellt die Pipeline sicher, dass ein Agent keine komplexe Aufgabe umgehen und ein nicht validiertes Endergebnis präsentieren kann.

Dieses Muster nutzt alle optionalen Verzeichnisse und zieht verschiedene Referenzdateien und Vorlagen nur in dem spezifischen Schritt heran, in dem sie benötigt werden, wodurch der Kontextfenster sauber bleibt.

In diesem Beispiel einer Dokumentations-Pipeline beachte die expliziten Gate-Bedingungen. Dem Agent ist es ausdrücklich verboten, zur Zusammenstellungsphase überzugehen, bis der Benutzer die generierten Docstrings aus dem vorherigen Schritt bestätigt hat:

1# skills/doc-pipeline/SKILL.md
2---
3name: doc-pipeline
4description: Erzeugt API-Dokumentation aus Python-Quellcode durch eine mehrstufige Pipeline. Verwenden, wenn der Benutzer darum bittet, ein Modul zu dokumentieren, API-Dokumente zu generieren oder Dokumentation aus Code zu erstellen.
5metadata:
6  pattern: pipeline
7  steps: "4"
8---
9
10Du führst eine Dokumentationsgenerierungs-Pipeline aus. Führe jeden Schritt in der angegebenen Reihenfolge aus. Überspringe KEINE Schritte und fahre nicht fort, wenn ein Schritt fehlschlägt.
11
12## Schritt 1 — Analysieren & Inventarisieren
13Analysiere den Python-Code des Benutzers, um alle öffentlichen Klassen, Funktionen und Konstanten zu extrahieren. Präsentiere das Inventar als Checkliste. Frage: "Ist dies die vollständige öffentliche API, die du dokumentiert haben möchtest?"
14
15## Schritt 2 — Docstrings generieren
16Für jede Funktion ohne Docstring:
17- Lade 'references/docstring-style.md' für das erforderliche Format
18- Generiere einen Docstring, der dem Style Guide genau folgt
19- Präsentiere jeden generierten Docstring zur Freigabe durch den Benutzer
20Fahre NICHT mit Schritt 3 fort, bis der Benutzer bestätigt.
21
22## Schritt 3 — Dokumentation zusammenstellen
23Lade 'assets/api-doc-template.md' für die Ausgabestruktur. Stelle alle Klassen, Funktionen und Docstrings in einem einzigen API-Referenzdokument zusammen.
24
25## Schritt 4 — Qualitätsprüfung
26Überprüfe anhand von 'references/quality-checklist.md':
27- Jedes öffentliche Symbol ist dokumentiert
28- Jeder Parameter hat einen Typ und eine Beschreibung
29- Mindestens ein Verwendungsbeispiel pro Funktion
30Melde die Ergebnisse. Behebe Probleme, bevor du das endgültige Dokument präsentierst.

Das richtige Agent-Skill-Pattern auswählen

Jedes Pattern beantwortet eine andere Frage. Verwende diesen Entscheidungsbaum, um das richtige Pattern für deinen Anwendungsfall zu finden:

Und schließlich: Patterns lassen sich kombinieren

Diese Patterns schließen sich nicht gegenseitig aus. Sie lassen sich kombinieren.

Ein Pipeline-Skill kann am Ende einen Reviewer-Schritt enthalten, um seine eigene Arbeit gegenzuprüfen. Ein Generator kann ganz zu Beginn auf Inversion setzen, um die notwendigen Variablen zu sammeln, bevor er seine Vorlage befüllt. Dank ADKs 𝚂𝚔𝚒𝚕𝚕𝚃𝚘𝚘𝚕𝚜𝚎𝚝 und der progressiven Offenlegung verbraucht dein Agent nur zur Laufzeit Kontext-Token für die genau benötigten Patterns.

Hör auf, zu versuchen, komplexe und fragile Anweisungen in einen einzigen System-Prompt zu zwängen. Zerlege deine Workflows, wende das richtige strukturelle Pattern an und baue zuverlässige Agents.

Heute noch loslegen

Die Agent Skills-Spezifikation ist Open-Source und wird nativ von ADK unterstützt. Du weißt bereits, wie du das Format verpackst. Jetzt weißt du auch, wie du den Inhalt gestaltest. Baue intelligentere Agents mit dem Google Agent Development Kit.