Optimal mit KI arbeiten – Teil 2: Skills, Agents & Automatisierung

Im ersten Teil dieser Reihe hast du gelernt, wie du mit klaren Prompts, Kontext-Management und den richtigen Modellen eine solide Grundlage für produktives KI-Arbeiten legst. Jetzt gehen wir einen Schritt weiter: Wie skalierst du deine KI-Workflows über einzelne Chat-Interaktionen hinaus? Wiederverwendbare Skills, externe Tool-Anbindungen via MCP und parallelisierte Subagenten sind der Schlüssel — und genau das schauen wir uns in diesem Teil an.

Voraussetzungen

• Du hast Teil 1 der Reihe gelesen und kennst die Grundlagen von Prompt-Engineering, Kontext und Modellwahl.
• Claude Code (Anthropics offizielles CLI) ist installiert (npm install -g @anthropic-ai/claude-code).
• Du hast Grundkenntnisse in der Kommandozeile und weißt, was ein API-Key ist.
• Optional, aber hilfreich: ein bestehendes Projekt-Repository, an dem du die Konzepte direkt ausprobieren kannst.

Warum einfache Prompts an ihre Grenzen stoßen

Ein einzelner Prompt ist wie ein Handwerker mit einem einzigen Werkzeug: für viele Aufgaben ausreichend, aber sobald das Projekt komplexer wird, brauchst du mehr. Drei typische Grenzen treten regelmäßig auf:

Wiederholung ohne Struktur. Du schreibst denselben Kontext immer wieder neu — was das Modell über dein Projekt wissen muss, welche Code-Konventionen gelten, welche Tools erlaubt sind.

Isoliertes Wissen. Das Modell kennt nur, was du in den Chat schreibst. Externe Datenbanken, APIs, aktuelle Dokumentationen — alles bleibt unsichtbar.

Sequentielle Engpässe. Komplexe Aufgaben (recherchiere drei Themen, fasse sie zusammen, schreib einen Report) laufen nacheinander, obwohl sie parallel erledigt werden könnten.

Die Antwort auf alle drei Probleme steckt im Rest dieses Artikels.

Wiederverwendbare Prompts und Templates

Der einfachste Skalierungsschritt ist Systematisierung: Prompts, die du häufig brauchst, werden zu Templates. In Claude Code heißen diese wiederverwendbaren Einheiten Skills — Slash-Commands, die du einmal definierst und dann per /mein-skill aufrufst.

Skills als spezialisierte Fähigkeiten

Ein Skill ist konzeptuell eine Datei mit klaren Anweisungen, die ein Agent bei Bedarf lädt. Statt bei jeder Code-Review-Anfrage denselben langen System-Prompt zu schreiben, rufst du einfach /code-review auf. Der Skill enthält bereits: Analyse-Tiefe, Ausgabeformat, Kriterien.

Das Prinzip dahinter ist lazy loading für Kontext: Das Modell lädt spezialisiertes Wissen erst dann, wenn es gebraucht wird — das spart Tokens und hält den Kontext sauber.

Einige Skills, die sich in der Praxis bewährt haben:

• /code-review — prüft Diff auf Bugs, Sicherheitslücken, Vereinfachungspotenzial
• /deep-research — Fan-out über mehrere Web-Quellen, adversarielle Verifikation, Bericht
• /security-review — fokussierter Sicherheits-Audit des aktuellen Branches
• /simplify — Refactoring ohne Bug-Suche, rein auf Vereinfachung ausgerichtet

Projekt-Konfiguration mit CLAUDE.md

Die mächtigste Form wiederverwendbarer Konfiguration ist eine CLAUDE.md-Datei im Repo-Root. Sie wird bei jedem Start einer Claude-Code-Session automatisch geladen und gibt dem Agenten Kontext über dein Projekt — ohne dass du ihn jedes Mal neu erklären musst.

# CLAUDE.md — Mein Projekt

## Tech-Stack
- Next.js 14 (App Router), TypeScript, Tailwind CSS
- Backend: Supabase (self-hosted), Edge Functions

## Konventionen
- Commits: Conventional Commits (feat/fix/chore/docs)
- Branches: feature/<ticket-nr>-kurzbeschreibung
- Keine `any`-Types in TypeScript ohne Kommentar

## Wichtige Befehle
- `npm run dev` — lokaler Dev-Server (Port 3000)
- `npm run test` — Vitest Unit-Tests
- `npm run lint` — ESLint + TypeScript-Check

## Verbotenes
- Keine direkten DB-Zugriffe aus Client-Components
- Keine Secrets in Code committen (.env.example statt .env)

Diese Datei ist dein Dauergedächtnis für den Agenten. Alles, was du hier definierst, muss kein Mensch mehr erklären.

Tipp: Halte CLAUDE.md aktuell wie dein README. Wenn sich Konventionen ändern, ändere die Datei — nicht die Köpfe.

MCP: Externe Tools und Datenquellen anbinden

MCP (Model Context Protocol) ist der offene Standard, über den Claude und andere Agenten-Systeme externe Tools und Datenquellen einbinden. Statt das Modell mit statischen Informationen zu füttern, bekommt es die Möglichkeit, aktiv Daten abzufragen — aus Datenbanken, APIs, Dateisystemen, Versionskontrollsystemen.

Wie MCP funktioniert

MCP definiert drei Typen von Erweiterungen:

• Tools — Funktionen, die der Agent aufrufen kann (z. B. SQL-Query ausführen, HTTP-Request senden)
• Resources — strukturierte Datenquellen, die der Agent lesen kann (z. B. Datenbankschemas, Dokumentationen)
• Prompts — vordefinierte Prompt-Templates, die über MCP bereitgestellt werden

Ein MCP-Server ist ein lokaler Prozess (oder Remote-Endpunkt), der diese Kapazitäten über ein standardisiertes JSON-RPC-Protokoll exponiert. Claude Code verbindet sich mit konfigurierten MCP-Servern beim Start.

MCP in der Praxis: Supabase-Anbindung

# MCP-Server für Supabase lokal starten
npx @supabase/mcp-server-supabase \
  --supabase-url https://deine-instanz.supabase.co \
  --service-role-key $SUPABASE_SERVICE_KEY

Sobald der Server läuft und in deiner Claude-Code-Konfiguration eingetragen ist, kann der Agent direkt Fragen stellen wie: "Welche Tabellen hat meine Datenbank?" oder "Zeig mir die letzten 10 Einträge in der leads-Tabelle" — ohne dass du SQL-Schemas manuell einfügen musst.

# .claude/settings.json (vereinfacht)
{
  "mcpServers": {
    "supabase": {
      "command": "npx",
      "args": [
        "@supabase/mcp-server-supabase",
        "--supabase-url", "https://deine-instanz.supabase.co"
      ],
      "env": {
        "SUPABASE_SERVICE_KEY": "${SUPABASE_SERVICE_KEY}"
      }
    }
  }
}

Welche MCP-Server existieren?

Das Ökosystem wächst schnell. Etablierte Server gibt es für: GitHub (Repos, Issues, PRs), Stripe (Zahlungen, Kunden), Dateisystemzugriff, Web-Fetch, Playwright (Browser-Automatisierung) und viele mehr. Anthropic selbst pflegt eine Referenzliste auf modelcontextprotocol.io.

Subagenten und parallele Ausführung

Für Aufgaben, die sich sinnvoll aufteilen lassen, ist Fan-out der entscheidende Hebel: Statt einen Agenten sequentiell durch fünf Recherche-Themen zu schicken, startest du fünf Subagenten parallel.

Das Konzept

Ein Orchestrator-Agent zerlegt eine komplexe Aufgabe in Teilaufgaben und verteilt sie. Jeder Subagent ist spezialisiert oder bekommt einen klar definierten Scope. Die Ergebnisse werden zurück an den Orchestrator gegeben, der sie zusammenführt.

Nutzer-Anfrage
     │
     ▼
[Orchestrator-Agent]
     │
     ├──► [Subagent A: Recherche Thema 1]
     ├──► [Subagent B: Recherche Thema 2]
     └──► [Subagent C: Code-Analyse]
               │
               ▼
     [Orchestrator: Zusammenfassung + Report]

Wann Subagenten Sinn ergeben

Nicht jede Aufgabe profitiert von Parallelisierung. Die Faustregel: Wenn Teilaufgaben unabhängig voneinander sind und ähnlich viel Zeit brauchen, lohnt Fan-out. Wenn Schritt 2 das Ergebnis von Schritt 1 braucht, bleib bei sequentiellem Ablauf.

Der /deep-research-Skill in Claude Code implementiert genau dieses Muster intern: mehrere Web-Quellen werden parallel gefetcht, adversarial verifiziert, dann zu einem Bericht zusammengeführt.

Skill vs. MCP vs. Subagent — Entscheidungshilfe

Szenario	Beste Lösung	Warum
Gleiche Aufgabe täglich wiederholen	Skill / Template	Einmal definieren, immer wieder nutzen
Echtzeit-Daten aus DB / API brauchen	MCP	Direkter Zugriff ohne manuellen Copy-Paste
Mehrere unabhängige Themen recherchieren	Subagenten (Fan-out)	Parallelisierung spart Zeit
Komplexer mehrstufiger Workflow	Orchestrator + Subagenten	Klare Arbeitsteilung, besser kontrollierbar
Projekt-Konventionen für alle Sessions	CLAUDE.md	Persistenter Kontext ohne Token-Overhead
Spezialisiertes Domain-Wissen laden	Skill	Lazy loading, nur wenn gebraucht
Browser-Interaktion / UI-Test automatisieren	MCP (Playwright)	Agent kann UI direkt steuern

Modellwahl für komplexe Workflows

Beim Orchestrieren mehrerer Agenten ist Modellwahl kritisch — sowohl für Qualität als auch für Kosten.

claude-opus-4-8 (Opus 4.8) ist das stärkste Modell und eignet sich als Orchestrator: es plant, entscheidet und integriert. Für aufwändige Reasoning-Aufgaben und Entscheidungen unter Unsicherheit ist es die richtige Wahl.

claude-sonnet-4-6 (Sonnet 4.6) ist schnell und stark — ideal für Subagenten, die konkrete Teilaufgaben erledigen: Code schreiben, Texte zusammenfassen, Daten analysieren. Das beste Preis-Leistungs-Verhältnis für die meisten produktiven Aufgaben.

claude-haiku-4-5 (Haiku 4.5) ist am günstigsten und schnellsten — perfekt für einfache Klassifikationen, kurze Extraktionen oder wenn du viele parallele Subagenten auf günstige Weise skalieren willst.

# Pseudocode: Orchestrator wählt Modell nach Aufgabe
def choose_model(task_type: str) -> str:
    if task_type == "planning" or task_type == "complex_reasoning":
        return "claude-opus-4-8"
    elif task_type == "code_generation" or task_type == "summarization":
        return "claude-sonnet-4-6"
    elif task_type == "classification" or task_type == "simple_extraction":
        return "claude-haiku-4-5"
    else:
        return "claude-sonnet-4-6"  # sicherer Default

Ein typisches Setup: Opus 4.8 als Orchestrator, Sonnet 4.6 für Code-Subagenten, Haiku 4.5 für Klassifikations-Routinen. So hältst du Kosten und Latenz im Griff, ohne auf Qualität zu verzichten.

Workflows orchestrieren: Ein reales Beispiel

Angenommen, du willst täglich einen Wettbewerbs-Report über drei Konkurrenten erstellen — automatisiert, strukturiert, versioniert.

#!/bin/bash
# daily-competitor-report.sh
# Wird z.B. per Cron täglich um 07:00 ausgeführt

REPORT_DATE=$(date +%Y-%m-%d)
OUTPUT_DIR="./reports/$REPORT_DATE"
mkdir -p "$OUTPUT_DIR"

# Fan-out: drei Subagenten parallel
for COMPETITOR in "CompetitorA" "CompetitorB" "CompetitorC"; do
  claude --model claude-sonnet-4-6 \
    --system "Du bist ein Marktforscher. Recherchiere kompakte, faktische Updates." \
    "Recherchiere aktuelle Neuigkeiten über $COMPETITOR: neue Features, Pricing-Änderungen, Blog-Posts der letzten 7 Tage. Fasse in 300 Wörtern zusammen." \
    > "$OUTPUT_DIR/${COMPETITOR}.md" &
done

# Warten, bis alle Subagenten fertig sind
wait

# Orchestrator: Gesamtreport zusammenführen
claude --model claude-opus-4-8 \
  --system "Du bist ein Senior-Analyst. Fasse drei Einzelreports zu einem Executive Summary zusammen." \
  "Hier sind drei Wettbewerber-Reports vom $REPORT_DATE:

$(cat $OUTPUT_DIR/*.md)

Erstelle ein Executive Summary (max. 500 Wörter): wichtigste Trends, strategische Implikationen, empfohlene Handlungen." \
  > "$OUTPUT_DIR/executive-summary.md"

echo "Report fertig: $OUTPUT_DIR/executive-summary.md"

Dieser Workflow läuft vollautomatisch, nutzt parallele Subagenten für Recherche und einen stärkeren Orchestrator für die Synthese.

Häufige Fehler

1. Zu viel Kontext auf einmal injizieren. CLAUDE.md mit 5000 Zeilen Dokumentation befüllen, die bei jeder Session vollständig geladen wird — das verbrennt Token und verwässert den Fokus. Halte die Datei prägnant; lagere umfangreiche Referenzen in separate Dateien aus, die nur bei Bedarf gelesen werden.

2. MCP-Server ohne Zugriffskontrolle betreiben. Ein MCP-Server mit service-role-Key, der beliebige SQL-Queries ausführen darf, ist ein Sicherheitsrisiko. Setze Read-only-Verbindungen für Recherche-Tasks, schreibe nur dort, wo es explizit nötig ist.

3. Subagenten ohne klare Abgrenzung starten. Wenn zwei parallele Subagenten dieselbe Datei schreiben sollen, entsteht ein Race Condition. Gib jedem Subagenten eindeutige Output-Pfade und lass den Orchestrator die Zusammenführung übernehmen.

4. Modell-Overkill für einfache Tasks. Opus 4.8 für jede Klassifikation zu nutzen ist wie einen Sportwagen für den Supermarkt zu nehmen — teuer und langsam. Haiku 4.5 reicht für einfache Routing- und Klassifikationsaufgaben vollkommen aus.

5. Skill-Proliferation ohne Pflege. Zehn verschiedene "fast identische" Code-Review-Skills anlegen, weil jeder Entwickler seinen eigenen gebaut hat. Maintainabilität leidet — konsolidiere und versioniere Skills wie normalen Code.

6. CLAUDE.md nicht im Repo versionieren. Die Datei gehört ins Repository und damit in Code Review. Wenn jemand die KI-Konfiguration ändert, soll das genauso sichtbar sein wie eine Änderung am Produktionscode.

Nächste Schritte

Du weißt jetzt, wie du KI systematisch skalierst — von wiederverwendbaren Skills über MCP-Anbindungen bis zu parallelen Subagenten. Im dritten und letzten Teil dieser Reihe geht es ans Eingemachte: Coden mit KI.

Wir schauen uns an, wie Claude Code in einem echten Entwickler-Workflow eingesetzt wird — Test-Driven Development mit KI-Unterstützung, automatische Code-Reviews im CI/CD-Pipeline, Refactoring-Workflows und wie du sicherstellst, dass die KI deinen Code verbessert, statt ihn zu verschlechtern. Außerdem: wann du der KI vertrauen solltest und wann du lieber zweimal hinschaust.

Teil 3 erscheint in Kürze — abonniere den Newsletter, um keine Episode zu verpassen.