+220 XP

Capstone: ein echter End-to-End-Workflow mit Claude

# Capstone: ein echter End-to-End-Workflow mit Claude

Sie bauen einen Research-to-Report-Assistenten, der jeden Montag aufwacht, frische Daten aus Ihren Live-Quellen zieht, einen strukturierten Report in Ihrer Hausstimme entwirft und ihn dort ablegt, wo Ihr Team schon arbeitet. Kein Copy-Paste, kein Babysitten eines Chatfensters. In dieser Lektion geht es um Architekturentscheidungen, nicht um Tastenanschläge, damit Sie Ihre eigene Domäne einsetzen können (Competitive Intelligence, Wochenmetriken, Regulatory Monitoring), ohne irgendetwas umzuschreiben.

Wir setzen das aus Bausteinen zusammen, die Sie bereits kennen: Projects, Connectors, MCP, Claude Code, die Messages API und einen Schedule. Die Kunst besteht darin, für jede Aufgabe den *richtigen* Baustein zu wählen.

Der Workflow, end to end

So sieht das aus, was wir bauen:

1. Der Kontext liegt in einem Project, damit jeder Run mit demselben Hintergrund, denselben Quellen und denselben Instruktionen startet.

2. Live-Daten kommen über Connectors oder einen eigenen MCP-Server herein, nicht über ein veraltetes Paste.

3. Die schwere Arbeit (mehrstufiges Reasoning, Dateierzeugung) läuft über Claude Code oder die Messages API.

4. Stimme und Format werden über einen Style und ein wiederverwendbares Skill erzwungen.

5. Ein Schedule triggert das Ganze, damit es ohne Sie läuft.

Der Fehler, den die meisten machen: Sie pressen alle fünf in einen einzigen riesigen Prompt. Halten Sie sie getrennt. Jede Schicht hat eine andere Änderungsrate: Ihr Kontext entwickelt sich langsam, Ihre Daten ändern sich täglich, Ihr Format fast nie. Die Trennung ist das, was die Sache wartbar macht.

Schicht 1: Das Project als Kontext-Rückgrat

Starten Sie in der Claude-App und erstellen Sie ein Project für diesen Assistenten. Ein Project ist ein Workspace, der persistente Instruktionen plus eine Wissensbasis aus Dateien in jede Konversation darin mitträgt.

Packen Sie drei Dinge in die Custom Instructions des Projects:

  • Die Aufgabe: „Du erstellst einen wöchentlichen Competitive-Intelligence-Report zum Markt für EV-Ladeinfrastruktur.“
  • Zielgruppe und Rahmenbedingungen: wer liest es, wie lang soll es sein, was darf niemals vorkommen.
  • Den Output-Vertrag: die exakten Abschnittsüberschriften, die der Report immer haben muss.

Laden Sie Ihre Referenzdateien in das Project-Knowledge: die Reports des letzten Quartals, Ihre Wettbewerber-Taxonomie, ein Glossar. Das ist der langsam wechselnde Kontext. Sie setzen ihn einmal, und er grundiert jeden Run.

Warum ein Project und nicht einfach ein System-Prompt in der API? Weil Sie auch eine für Menschen nutzbare Oberfläche wollen. Wenn der geplante Run etwas Seltsames produziert, öffnen Sie das Project, stellen Rückfragen gegen denselben Kontext und debuggen interaktiv. Project und Automatisierung teilen dasselbe Gehirn.

Die aktuellen Fähigkeiten finden Sie in der Projects-Dokumentation.

Schicht 2: Live-Daten über Connectors und MCP

Ein Report ist nur so gut wie sein frischester Input. Hier verdient MCP (Model Context Protocol) seinen Platz. MCP ist ein offener Standard, über den Claude mit externen Tools und Datenquellen über eine einheitliche Schnittstelle spricht, sodass Sie nicht für jede Quelle eine eigene Integration von Hand bauen.

Sie haben zwei Wege:

Connectors sind vorgebaute MCP-Integrationen, die Sie aus dem Connector-Directory in den Claude-Apps aktivieren: etwa Google Drive, Websuche und ein wachsender Marketplace von Drittanbieter-Diensten. Wenn Ihre Daten schon irgendwo liegen, wo es einen offiziellen Connector gibt, nutzen Sie ihn. Kein Code.

Einen eigenen MCP-Server bauen Sie, wenn Ihre Daten an einem maßgeschneiderten Ort liegen: eine interne Preisdatenbank, eine Partner-API, eine Scraping-Pipeline. Sie exponieren diese Quelle als kleinen Server, der MCP spricht, und Claude kann sie dann wie jedes andere Tool aufrufen.

Für unseren EV-Report nehmen wir an, wir brauchen live Zahlen zum Ausbau der Ladepunkte aus einer internen API. Ein minimales MCP-Server-Tool sieht so aus:

python
from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("ev-data")

@mcp.tool()
async def get_deployments(region: str, since_days: int = 7) -> dict:
    """Fetch new charger deployments for a region in the last N days."""
    url = f"https://internal.example.com/deployments"
    params = {"region": region, "since_days": since_days}
    async with httpx.AsyncClient() as client:
        resp = await client.get(url, params=params, timeout=30)
        resp.raise_for_status()
        return resp.json()

if __name__ == "__main__":
    mcp.run()

Das ist das ganze Muster. Eine dekorierte Funktion wird zu einem Tool, das Claude namentlich aufrufen kann, wobei der Docstring als Beschreibung dient, die das Modell liest, um zu entscheiden, wann es aufgerufen wird. Schreiben Sie knappe Docstrings: sie sind Prompt-Fläche, nicht bloß Kommentare.

Starten Sie bei modelcontextprotocol.io für Spezifikation und SDKs.

Entscheidungsregel: Greifen Sie zuerst zum Connector. Bauen Sie einen eigenen MCP-Server nur, wenn kein Connector existiert oder Ihre Quelle privat ist. Bauen Sie nicht, was Sie aktivieren können.

Schicht 3: die Engine, Claude Code vs. API

Jetzt die schwere Arbeit: Daten lesen, über Quellen hinweg schlussfolgern, den Report schreiben, eine Datei speichern. Sie haben zwei Engines, und die Wahl macht einen Unterschied.

Claude Code ist Anthropics agentisches Coding-Tool, das in Ihrem Terminal läuft. Es ist nicht nur zum Schreiben von Software da. Es kann Dateien in einem Arbeitsverzeichnis lesen und schreiben, Befehle ausführen und Ihre MCP-Server aufrufen, was es zu einem fähigen *Workflow*-Runner macht. Für unseren Report kann Claude Code Daten ziehen, synthetisieren und report-2026-W12.md in einem agentischen Loop auf die Platte schreiben.

Die Messages API (oder das Claude Agent SDK darauf) nutzen Sie, wenn Sie das in Ihren eigenen Service einbetten wollen: eine Web-App, ein Lambda, eine bestehende Datenpipeline. Mehr Kontrolle, mehr Code.

Für ein Capstone, das Sie für sich selbst oder ein kleines Team betreiben, ist Claude Code der schnellere Weg. Es erledigt den Agent-Loop, File-I/O und Tool-Calls schon. Sie konfigurieren Ihre MCP-Server einmal in seinen Settings und richten es auf einen Prompt.

Hier die MCP-Konfiguration auf Projektebene, die Claude Code liest:

json
{
  "mcpServers": {
    "ev-data": {
      "command": "python",
      "args": ["./servers/ev_data.py"]
    }
  }
}

Damit läuft eine einzige Anweisung wie „Erzeuge den Report dieser Woche mit dem ev-data-Tool für die Regionen West und Northeast, halte den Abschnittsvertrag des Projects ein und speichere ihn als datierte Markdown-Datei“ die gesamte Kette ab.

Das Agent SDK ist später die richtige Wahl, wenn Sie das headless in Produktionsinfrastruktur betreiben wollen, mit eigener Retry-Logik, Logging und Guardrails. Ansehen können Sie es bei github.com/anthropics.

🎬 [VIDEO: "Building Agents with Claude Code and MCP" - youtube.com/results?search_query=claude+code+mcp+agents - ein Walkthrough zum Verdrahten von MCP-Servern mit Claude Code für mehrstufige automatisierte Workflows]

Schicht 4: Stimme und Struktur mit Styles und Skills

Ihr Report darf nicht wie generische KI-Prosa klingen. Zwei Features lösen das.

Styles steuern Tonalität und Schreibkonventionen. Erstellen Sie einen eigenen Style, trainiert auf einigen Ihrer früheren Reports, damit der Output Ihrer Hausstimme entspricht: knapp, ohne Absicherungsfloskeln, bullet-lastig. Der Style reist mit dem Project.

Skills sind verpackte, wiederverwendbare Instruktionen plus optionale Ressourcen, die Claude lädt, wenn sie relevant sind. Für unseren Report bauen Sie ein Skill, das die *Report-Erzeugungsprozedur* kodiert: wie Quellen gewichtet werden, wie Aussagen mit geringer Konfidenz markiert werden, das exakte Tabellenformat für die Ausbauzahlen. Ein Skill ist haltbarer, als all das in einen Prompt zu stopfen, und Sie können es versionieren.

Die Aufteilung ist klar: der Style regelt, *wie es klingt*, das Skill regelt, *wie es gebaut wird*. Halten Sie Formatierungslogik aus Ihrer Datenschicht und aus Ihrer Engine heraus. Wenn Ihr Chef nächstes Quartal einen neuen Abschnitt will, ändern Sie das Skill, nichts anderes.

Wissenscheck

1. Warum argumentiert die Lektion dagegen, alle fünf Schichten (Kontext, Daten, Reasoning, Formatierung, Scheduling) in einen einzigen riesigen Prompt zu pressen?

2. Was ist laut Lektion der Hauptzweck eines Projects als „Kontext-Rückgrat“ des Assistenten?

3. Warum werden im Workflow Live-Daten über Connectors oder einen eigenen MCP-Server hereingeholt, statt sie ins Project zu pasten?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Elemente aus, die die Lektion für die Custom Instructions des Projects empfiehlt.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen aus, die die Begründung der Schichtenarchitektur in diesem Capstone-Workflow korrekt beschreiben.

Wählen Sie alle richtigen Antworten aus.

Schicht 5: Der Schedule

Ein Assistent, den Sie per Hand starten müssen, ist keine Automatisierung. Sie brauchen einen Trigger.

Claude Code läuft als Befehl, also ist der Scheduler einfach Ihr Betriebssystem oder Ihre CI. Am saubersten ist ein Cron-Job (ein Unix-Scheduler, der einen Befehl nach einem Zeitmuster ausführt) oder ein GitHub-Actions-Workflow.

Ein Cron-Eintrag für jeden Montag um 7 Uhr:

bash
0 7 * * 1 cd ~/ev-report && claude -p "Generate this week's report using the prompt in run.md" >> run.log 2>&1

Das Flag -p führt Claude Code im nicht-interaktiven („print“) Modus aus: es führt den Prompt aus, macht seine agentische Arbeit und beendet sich. Das macht es skriptfähig. Ihre run.md hält die Standinganweisung, damit die Cron-Zeile stabil bleibt.

Für ein Team schieben Sie das stattdessen in GitHub Actions. Ein geplanter Workflow führt denselben Befehl auf Anthropic-gehosteten oder Ihren eigenen Runnern aus, committet den erzeugten Report ins Repo, und die GitHub-Integration lässt das Modell einen Pull Request mit dem Entwurf für die menschliche Prüfung eröffnen, bevor irgendetwas rausgeht. Dieses Review-Gate ist wichtig: Sie wollen, dass ein Mensch den Report freigibt, nicht dass ein Roboter ungelesene Aussagen an Stakeholder publiziert.

Die Nahtstellen zusammensetzen

Treten Sie einen Schritt zurück und sehen Sie, wie die Schichten übergeben:

  • Das Project hält langsamen Kontext und gibt Ihnen eine menschliche Debugging-Oberfläche.
  • MCP/Connectors spielen frische Daten über eine einheitliche Schnittstelle ein.
  • Claude Code orchestriert den agentischen Loop und schreibt Dateien.
  • Styles + Skills erzwingen Stimme und Struktur unabhängig voneinander.
  • Cron oder GitHub Actions zündet das Ganze nach Plan, mit einem menschlichen Approval-Gate.

Jede Nahtstelle ist ein Ort, an dem Sie ein Teil austauschen können, ohne den Rest anzufassen. Datenquellen wechseln? Neuer MCP-Server, gleiche Engine. Die Engine für die Produktion auf das Agent SDK umstellen? Gleiche MCP-Config, gleiches Skill. Das ist die eigentliche Lehre des Capstone: gute KI-Workflows sind *aus austauschbaren Teilen zusammengesetzt*, nicht monolithische Prompts.

Eine Anmerkung zu Failure Modes

Zwei Dinge gehen zuerst kaputt, also designen Sie jetzt dafür.

Veraltete oder leere Daten. Ihr MCP-Tool sollte ein klares Signal zurückgeben, wenn eine Quelle ausgefallen ist, und Ihr Skill sollte Claude anweisen, einen degradierten Report zu kennzeichnen, statt um fehlende Zahlen herum zu halluzinieren. Ein Report, der sagt „Ausbaudaten diese Woche nicht verfügbar“, ist korrekt. Einer, der Zahlen erfindet, ist gefährlich.

Stiller Drift. Planen Sie monatlich eine menschliche Lektüre eines vollständigen Outputs, end to end. Automatisierung verbirgt langsamen Verfall. Die Project-Oberfläche ist genau der Ort für dieses Audit, weil sie den Kontext mit dem automatisierten Run teilt.

Die wichtigsten Erkenntnisse

  • Trennen Sie die fünf Schichten (Kontext, Daten, Engine, Formatierung, Schedule) nach ihrer Änderungsrate. Langsamer Kontext gehört in ein Project, tägliche Daten laufen über MCP, haltbare Formatierung gehört in ein Skill.
  • Aktivieren Sie einen Connector, bevor Sie einen MCP-Server bauen. Bauen Sie einen Server nur für private oder maßgeschneiderte Quellen von Hand, und schreiben Sie knappe Tool-Docstrings, weil Claude sie als Prompt liest.
  • Nutzen Sie Claude Code mit -p für das Capstone und wechseln Sie erst zum Claude Agent SDK, wenn Sie headless Produktionskontrolle brauchen.
  • Behalten Sie ein menschliches Approval-Gate. Lassen Sie die GitHub-Integration einen Pull Request mit dem Entwurf eröffnen, damit ein Mensch abzeichnet, bevor Stakeholder ihn sehen.
  • Bauen Sie für den Fehlerfall: machen Sie fehlende Daten explizit sichtbar und planen Sie ein regelmäßiges menschliches Audit über das gemeinsame Project, um stillen Drift zu erkennen.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

  • Jeden geplanten Run idempotent machen: datierte Outputs und Done-Checks
Vollständiges Action Playbook ansehen