Claude Code, MCP & Integration — Claude Certified Developer Foundations Prep Course

Screen 1: Was du am Ende können wirst

ORIENTIERUNG · 2 MIN Was du am Ende können wirst

Claude Code ist dein terminalgestützter Entwicklungspartner.

In vorherigen Modulen hast du wesentliche API-Komponenten eingerichtet: Prompts, Tool-Schemas, Context Engineering, Agent Loops und multimodale Erfassung; dieses Modul baut direkt auf dieser Grundlage auf. Claude Code ermöglicht es dir, dasselbe Modell in deiner Terminal-Umgebung zu betreiben und führt eine Berechtigungsebene, ein Konfigurationssystem und teamorientierte Sharing-Funktionen ein. Das MCP-Protokoll ermöglicht sichere Integration mit externen Diensten. In diesem Modul lernst du, Claude Code und MCP für robuste Sicherheit und effektive Bereitstellung zu konfigurieren.

Am Ende dieses Moduls wirst du in der Lage sein: 1 Claude Code durch die Explore-, Plan- und Code-Schleife auszuführen und einen Berechtigungsmodus auszuwählen, der dem Risikostufe der Arbeit entspricht, damit der Agent produktiv bleibt, ohne mehr Autorität zu erhalten als die Aufgabe erfordert. 2 Von KI generierte Code zu lesen, Ausgaben mit kalibriertem Vertrauen zu überprüfen und auf die Erkenntnisse zu reagieren, die zuverlässig sind, die zu überprüfen, die nicht sind, und ein menschliches Review-Gate dort zu platzieren, wo die Kosten eines falschen Aufrufs hoch sind. 3 Claude Code dauerhaften Projektkontext mit CLAUDE. md, Rules-Anweisungsdateien, Hooks und Subagenten zu geben. 4 Einen Workflow als Skills, benutzerdefinierte Befehle und ein Plugin zu verpacken. Einen Skill einmal zu schreiben, der auf die gleiche Weise über Claude Code, die Messages API und das Agent SDK läuft. 5 Einen MCP-Server zu erstellen, der die Tools, Ressourcen und Prompts für Claude verfügbar macht, den Transport auszuwählen, der der Kommunikation zwischen Client und Server entspricht, und den Konfigurationsumfang festzulegen, der steuert, wer ihn lädt. 6 Claude mit Unternehmenssystemen zu verbinden, diese Verbindungen mit Mustern zu authentifizieren, die ein regulierter Kunde akzeptiert, und ein Code-Modernisierungsprojekt so zu gestalten, dass die Arbeit einer Sicherheitsüberprüfung standhält.

Dieses Modul ist für den Developer, der Claude bereits in Code zum Laufen gebracht hat und diese Arbeit nun konfigurierbar, teilbar und sicher für die Verbindung mit echten Systemen machen muss. Du bist praktisch, codeorientiert und musterorientiert. Dieses Modul setzt voraus, dass du mit den API-Mustern aus Modul 2 vertraut bist. Es unterrichtet die Agent-Schleife, Tool-Schemas oder Context Engineering nicht erneut. Es unterrichtet die Engineering-Entscheidungen, die um eine funktionierende Integration herum sitzen: wie man Claude Code in deinem Terminal unter einem Berechtigungsmodell ausführt, wie man ihm dauerhaften Projektkontext gibt, wie man einen Workflow verpackt, damit ein Teamkollege ihn installieren kann, und wie man Claude über MCP mit externen und Unternehmenssystemen verbindet, ohne Anmeldedaten zu lecken oder eine Sicherheitsüberprüfung zu bestehen.

„DER BUILD" IN DIESEM MODUL

Alles in diesem Modul ist um ein wiederkehrendes Problem herum aufgebaut: Code, der auf deinem Computer, in deiner Sitzung oder im Staging funktioniert, muss jetzt bestehen, wenn jemand anderes ihn ausführt, in der Produktion, gegen echte Unternehmenssysteme. Auf deinem Computer fühlte sich der Berechtigungsmodus sicher an, die Projektregeln waren klein genug zum Befolgen, der Skill fand sein Skript, die Anmeldedaten waren direkt in der Konfigurationsdatei, und die Verbindung funktionierte im Staging-Test. In dem Moment, in dem die Arbeit deinen Computer verlässt, könnte jede dieser Annehmlichkeiten zu einem Fehler werden: Ein Berechtigungsmodus löscht eine Datei, die nie im Umfang war, eine Regel wird unter Hunderten von Zeilen begraben, ein Skill zeigt auf einen Pfad, der auf keinem anderen Computer existiert, ein committed Key leckt innerhalb von Stunden, und ein Staging-only-Konfigurationsschritt bricht die Produktionsverbindung. Die Arbeit in diesem Modul besteht darin, zu lernen, welche Konfigurationsentscheidung welchen dieser Fehler verhindert, bevor sie vor einem Teamkollegen oder einem Auditor auftauchen.

HAFTUNGSAUSSCHLUSS / HINWEIS FÜR BILDUNGSINHALTE

Wir haben diesen Developer-Kurs Modul 3: Claude Code, MCP & Integration erstellt, um dir zu helfen, echte Arbeit mit Claude zu erledigen. Behandle ihn als Bildungsinhalte. Er stellt keine rechtliche, finanzielle oder andere professionelle Beratung dar, daher solltest du das, was du lernst, an deine eigene Situation anpassen. Unsere Produkte und Dienstleistungen entwickeln sich schnell, daher können bestimmte Inhalte Fehler enthalten oder veraltet sein; denke daran, auf der Website oder in der Dokumentation von Anthropic zu überprüfen. Beispiele und Szenarien, die im Kurs verwendet werden, sind illustrativ und oft fiktiv. Wenn das Kursmaterial ein Unternehmen oder Produkt erwähnt, bedeutet das nicht, dass Anthropic es unterstützt, sie Anthropic unterstützen oder dass wir verbunden sind. Beachte auch, dass deine Nutzung von Anthropic-Produkten und -Dienstleistungen durch unsere Bedingungen, Richtlinien und Dokumentation abgedeckt ist; wenn etwas in diesem Kurs damit in Konflikt steht, haben diese Vorrang.

Screen 2: Claude Code Agent Loop, Berechtigungsmodi, Einstellungen und wo ein menschliches Gate sitzt

TeachingBerechtigungsmodi & menschliche Gates·17 min Claude Code Agent Loop, Berechtigungsmodi, Einstellungen und wo ein menschliches Gate sitzt Modul 2 hat etabliert, wie die Agent-Schleife auf API-Ebene funktioniert: Das Modell ruft Tools auf, erhält Ergebnisse zurück und setzt fort, bis die Aufgabe erledigt ist. Claude Code führt diese gleiche Schleife in deinem Terminal aus, fügt aber eine zusätzliche Ebene hinzu: ein Berechtigungssystem, das jede Aktion, die der Agent ausführen möchte, kontrolliert. Bevor du etwas konfigurieren kannst, musst du verstehen, wie die Schleife läuft und was die Berechtigungsmodi kontrollieren.

Wie Claude Code eine Aufgabe durcharbeitet: Explore, Plan und Code Wenn du Claude Code eine Aufgabe gibst, beginnt es nicht sofort zu schreiben. Es liest Dateien, verfolgt die relevante Logik und erstellt zunächst ein Bild der Codebasis; dies ist die Explorationsphase. Dann, sobald es genug versteht, um eine Änderung vorzuschlagen, erstellt es einen Plan. Ein Plan ist eine strukturierte Beschreibung der Änderungen, die es vornehmen möchte. Erst nachdem du den Plan überprüft und genehmigt hast, geht es in die Code-Phase über, in der es die Änderungen schreibt und ausführt. Diese Reihenfolge ist aus zwei Gründen wichtig. Erstens erzeugt sie bessere Ausgaben: Claude Code versteht die Codebasis, bevor es etwas anfasst, daher macht es weniger Annahmen und erfasst mehr nachgelagerte Effekte. Zweitens ist es dort, wo die Berechtigungsmodi anschließen: Der Plan-Modus hält Claude Code in der Explorationsphase, blockiert alle Dateiänderungen und Shell-Befehle, bis du ihn freigibst, was ihn zu einem nützlichen Standard für unbekannte Codebases oder hochriskante Arbeit macht.

Berechtigungsmodi: Genehmigungen, Gates und Einschränkungen Berechtigungsmodi steuern, wie oft Claude Code stoppt, um eine Bestätigung zu fordern. Jeder Modus macht einen anderen Kompromiss zwischen Geschwindigkeit und Überwachung. Die richtige Wahl hängt davon ab, wie gut du die Codebasis kennst und wie reversibel die Änderungen sind. Wähle jeden Tab aus, um zu sehen, was dieser Modus automatisch genehmigt, was er noch kontrolliert und seine Einschränkungen.

default acceptEdits plan auto dontAsk bypassPermissions

Was es automatisch genehmigt: Nur Lesevorgänge. Fordert vor fast jeder Änderung oder jedem Befehl auf. Was es noch kontrolliert: Alle Dateiänderungen und Shell-Befehle erfordern Bestätigung. Einschränkungen: Sicher, aber langsam bei vertrauenswürdiger Arbeit. Die Grundlage für jedes neue Projekt oder unbekannte Codebasis.

Was es automatisch genehmigt: Lesevorgänge, Dateiänderungen und häufige Dateisystembefehle (mkdir, touch, rm, rmdir, mv, cp und sed) im Arbeitsverzeichnis. Die automatische Genehmigung ist auf Pfade im Arbeitsverzeichnis beschränkt, und geschützte Pfade fordern weiterhin auf. Was es noch kontrolliert: Alle anderen Shell-Befehle; Schreibvorgänge außerhalb des Arbeitsverzeichnisses; Schreibvorgänge auf geschützte Pfade. Einschränkungen: Vertrauenswürdige lokale Arbeit, bei der die Shell-Ausführung immer noch ein menschliches Auge braucht. Nicht geeignet, wenn der Agent Skripte ausführen muss.

Was es automatisch genehmigt: Nur Lesevorgänge. Recherche und Vorschlag; macht keine Änderungen. Was es noch kontrolliert: Alle Dateiänderungen und Shell-Befehle, bis du einen Plan genehmigst. Einschränkungen: Exploration und Planung bei sensiblen oder unbekannten Codebases. Nicht geeignet für Aufgaben, die Ausgaben schreiben müssen.

Was es automatisch genehmigt: Alles, aber ein separater Klassifizierer überprüft zunächst jede Aktion und blockiert alles, das über deine Anfrage hinausgeht, auf unbekannte Infrastruktur abzielt oder von feindseligem oder unangemessenem Inhalt getrieben zu sein scheint. Was es noch kontrolliert: Produktionsbereitstellungen und Migrationen, Massenlöschungen, Credential-Exfiltration und Force-Push zu Main werden standardmäßig blockiert. Einschränkungen: Reduziert Aufforderungen, garantiert aber keine Sicherheit; dies ist eine Forschungsvorschau, kein Ersatz für die Überprüfung sensibler Operationen. Die Verfügbarkeit hängt von Plan, Modellversion und Admin-Einstellungen ab. Überprüfe immer die aktuellen Anforderungen vor dem Build.

Was es automatisch genehmigt: Nur Tools, die du in einer Allow-Regel vorab genehmigt hast, plus schreibgeschützte Befehle. Automatisch ABLEHNEN alles andere. Was es noch kontrolliert: Jeder Tool-Aufruf, der nicht auf der Allow-Liste steht, wird abgelehnt. Es gibt keine Warteschlange für Bestätigung. Einschränkungen: Gebaut für gesperrte CI und Skripte. Es schränkt gut ein, ist aber kein Weg, um Reibung bei lokaler interaktiver Arbeit zu reduzieren.

Was es automatisch genehmigt: Alle Tool-Aufrufe. Keine Bestätigungsaufforderungen und keine Sicherheitsprüfungen. Was es noch kontrolliert: Nichts im normalen Betrieb. Die Standard-Berechtigungsprüfungen werden umgangen; nur katastrophale Löschbefehle wie rm -rf / und rm -rf ~ lösen immer noch eine letzte Aufforderung aus. Einschränkungen: Nur in einem isolierten Container oder einer VM, wo die Umgebung disposabel ist. Niemals auf einer Entwickler-Workstation gegen eine Live-Codebasis.

Wo die Konfiguration lebt und wer sie anwendet Einstellungen können auf mehreren Ebenen platziert werden, und jede Ebene bestimmt den Umfang der Regeln, die sie enthält.

Benutzerebene (~/. claude/settings. json): Gilt für jedes Projekt auf dem Computer. Dies ist der richtige Ort für Voreinstellungen, die dich überall begleiten sollten, wie ein bevorzugter Standardmodus für Explorationsarbeit. Projektebene (. claude/settings. json, committed zum Repo): Gilt für jeden, der das Repository klont. Dies ist der richtige Ort für teamweite Konventionen, Allow-Regeln für die Tools, die dein Projekt verwendet, und Deny-Regeln für Pfade, die nicht berührt werden sollten. Lokale Projektebene (. claude/settings. local. json): Persönliche Overrides für ein Projekt, automatisch git-ignoriert. Dies ist der richtige Ort für deine eigenen Voreinstellungen, die nicht für das ganze Team committed werden sollten. Unternehmensebene (managed-settings. json, von Administratoren gesetzt): Kann nicht von Benutzern oder Projektdateien überschrieben werden. Der richtige Ort für organisationsweite Sicherheitskontrollen wie das Verbieten von Änderungen an Umgebungsdateien oder das Blockieren bestimmter Shell-Befehle über alle Projekte hinweg.

Allow- und Deny-Regeln lagern sich auf dem ausgewählten Modus auf. Eine Deny-Regel gewinnt immer über eine Allow-Regel, unabhängig vom aktiven Modus. Die dauerhafteste Governance-Kontrolle ist eine Deny-Regel auf Unternehmensebene: Sie kann von keinem einzelnen Developer entfernt werden und gilt auch, wenn ein Bypass-Modus gesetzt ist.

Wo ein Mensch immer noch schauen muss: Das Review-Gate nach Worst-Case-Kosten platzieren Berechtigungsmodi und Deny-Regeln entscheiden, was der Agent ohne zu fragen tun kann. Sie entscheiden nicht, wo du, der Mensch, immer noch schauen musst, bevor eine Aktion landet. Diese Entscheidung ruht auf einer Frage, der gleichen, die einen sicheren Modus von einem riskanten unterscheidet: Was ist das schlimmste Ergebnis, wenn diese Aktion ohne Personenprüfung läuft? Je niedriger die Kosten, falsch zu liegen, desto mehr kannst du durchlassen. Je höher die Kosten und je schwerer es ist, rückgängig zu machen, desto mehr braucht ein Schritt ein menschliches Gate, bevor es ausgeführt wird.

Diese gleiche Worst-Case-Frage platziert das Gate, ob der Agent Code schreibt oder unbeaufsichtigt in einem automatisierten Schritt läuft, wie ein Bot, der auf einen Pull Request kommentiert oder ihn blockiert. Drei Platzierungen folgen daraus:

Lass niedrig-riskante, reversible Aktionen ohne Gate durch. Eine Formatierungskorrektur oder eine Änderung, die auf das Arbeitsverzeichnis beschränkt ist, hat wenig Kosten, wenn sie falsch ist, daher bringt das Verlangen einer menschlichen Genehmigung für jede einzelne Überwachung, die du nicht brauchst, und verlangsamt die Arbeit. Dies ist der Fall, für den acceptEdits gebaut ist. Gate jede Aktion, die schwer rückgängig zu machen ist oder einen sensiblen Pfad erreicht: ein Schreibvorgang außerhalb des Arbeitsverzeichnisses, ein destruktiver Shell-Befehl oder eine Änderung an einer sicherheitsrelevanten oder geschützten Datei. Die Kosten eines falschen Aufrufs dort sind hoch, daher sollte der Agent pausieren und die Aktion für eine Person zur Überprüfung anzeigen, bevor sie läuft. Eine Deny-Regel erzwingt dies deterministisch, und default oder plan Modus halten die Aufforderung in Kraft, während du entscheidest. Lass den Agent niemals das einzige Gate bei einer Änderung an Code sein, den dein Team als sensibel markiert hat. Dort ist die Arbeit des Agenten ein Input zu einer menschlichen Entscheidung, kein Ersatz für eine, daher muss eine Person die Änderung überprüfen, bevor sie merged, egal wie zuversichtlich der Agent oder seine eigene Überprüfung klingt.

Die Platzierung des Gates und die Wahl des Berechtigungsmodus sind die gleiche Entscheidung von zwei Seiten betrachtet. Der Modus setzt den Standard für eine ganze Sitzung, und das Gate ist dort, wo du diesen Standard für die eine Aktion überschreibst, deren Kosten zu hoch sind, um sie dem Standard zu überlassen; beide kommen aus der Frage, was bricht, wenn dies unkontrolliert läuft.

Kosten · Komplexität · Risiko Kosten: Das Ausführen im default-Modus bei vertrauenswürdiger Arbeit fügt Aufforderungs-Latenz zu jedem Tool-Aufruf hinzu, und dies summiert sich bei einem langen Refactor. Komplexität: Mehrere Ebenen von Einstellungen und Dateien mit einer Override-Hierarchie erfordern konsistente Sorgfalt. Eine Deny-Regel auf Unternehmensebene, die einer Allow-Regel auf Projektebene widerspricht, muss von jedem verstanden werden, der die Projektkonfiguration verwaltet. Risiko: Das Risiko liegt in der Verwendung des falschen Modus für den Kontext. Zum Beispiel, ein Bypass-Modus aus Ungeduld auf einer nicht isolierten Maschine gesetzt, entfernt jeden Sicherheitsprompt zwischen dem Agent und deinen Live-Dateien, und, anders als die anderen Modi, entfernt auch den geschützten Pfad-Guard.

Screen 3: Der Bypass-Modus, der den einen Prompt entfernte, der wichtig war

Watch OutBerechtigungsmodi & menschliche Gates·3 min Der Bypass-Modus, der den einen Prompt entfernte, der wichtig war

Setup Du hast zu bypassPermissions gewechselt, um die konstanten Aufforderungen zu stoppen, weil die Arbeit sich routinemäßig anfühlte. Der Agent war tagelang gut verhalten, die Cleanup-Aufgabe war einfach, und das Prompt-vor-jedem-Tool-Aufruf-Verhalten fühlte sich wie unnötige Reibung an.

Das Transkript Die folgende Pairing-Sitzung fand bei einem Codebasis-Cleanup statt, das drei Tage lang ohne Zwischenfälle läuft. Dev: „Okay, ich wechsle zu bypassPermissions für diesen. Es ist nur das Umbenennen alter API-Endpoint-Referenzen. Nichts Riskantes. " Claude Code: [Scanning files matching pattern /v1/legacy/ ... 47 files found] Claude Code: [Updating endpoint references ... ] Claude Code: [Running post-rename cleanup. sh script ... ] Claude Code: [Deleted 3 files matching /v1/legacy/ in /deploy/config/prod/ ... ] Dev: „Warte. Was war in /deploy/config/prod/? " Claude Code: [Files contained environment-specific endpoint overrides for the production deployment. They have been removed. ] Dev: „Dieses Verzeichnis sollte nicht im Umfang sein. Ich habe an /src/ gearbeitet. " Claude Code: [The pattern /v1/legacy/ matched files in both /src/ and /deploy/config/prod/. In bypassPermissions mode, no confirmation was requested before the deletions. ] Der Prompt, der diesen Fehler hätte gefangen, wurde ausgeschaltet, als bypassPermissions eingeschaltet wurde. Im default oder acceptEdits Modus hätte das Cleanup-Skript nicht ohne Bestätigung gelaufen, und der Benutzer hätte die Löschung stoppen können, bevor sie die Produktionskonfigurationsdateien erreichte. Im bypassPermissions war die Pattern-Übereinstimmung breiter als beabsichtigt, und kein Prompt stand zwischen dem Skript und den Dateien, die es löschte.

Beachte die genaue Lage des Gates: Es war der Skript-Aufruf, der aufgefordert hätte, nicht rm-Löschbefehle selbst. acceptEdits genehmigt automatisch häufige Dateisystembefehle, einschließlich rm auf Pfaden im Arbeitsverzeichnis. Hätte Claude die Löschungen direkt als rm-Befehle ausgegeben, hätte acceptEdits sie stillschweigend durchgelassen; nur default-Modus fordert dafür auf.

Was du beachten solltest Ein Bypass-Modus stellt alle Bestätigungsaufforderungen stumm, einschließlich der, die du möglicherweise nicht erwartet hast. Das Fehlermuster hier ist ein Agent, der eine breitere Menge von Dateien als beabsichtigt abgleicht, läuft in einem Modus ohne Checkpoints. BypassPermissions überspringt auch den geschützten Pfad-Guard, den die anderen Modi behalten, daher verlieren sogar Repo-Status und Claudes eigene Konfiguration ihren automatischen Prompt. Um diese Lücke zu schließen, musst du eine Deny-Regel auf sensiblen Verzeichnissen setzen, bevor du Modi wechselst. Wenn du weniger Aufforderungen ohne den Sicherheitsnetz willst, verwende einen Klassifizierer-gated-Modus (z. B. auto) statt eines vollständigen Bypass.

Screen 4: Checkpoint 1: Assembliere die Einstellungsdatei und platziere das menschliche Gate

CheckpointBerechtigungsmodi & menschliche Gates·4 min Checkpoint 1: Assembliere die Einstellungsdatei und platziere das menschliche Gate Versuche es jetzt. Du konfigurierst Claude Code für einen vertrauenswürdigen lokalen Refactor des Payments-Moduls. Der Refactor sollte Dateiänderungen automatisch genehmigen, darf aber niemals destruktive Shell-Befehle ausführen, und die Datei . env. production darf niemals vom Agent lesbar sein. Unten sind settings. json-Teile.

Teil 1: Wähle die settings. json-Teile aus, die die richtige Konfiguration zusammenstellen Wähle zwei Teile aus. ✓Piece A. { "permissions": { "defaultMode": "default"} }✓Piece B. { "permissions": { "defaultMode": "bypassPermissions" } }✓Piece C. { "permissions": { "allow": ["Bash(npm run:)"], "deny": ["Bash(rm:)", "Bash(git push:*)"] } }✓Piece D. { "permissions": { "deny": ["Read(. env. production)"] } }✓Piece E. { "permissions": { "allow": ["Bash()", "Edit()"] } }

Teil 2 Deine Einstellungen erlauben dem Agent, Dateien automatisch zu bearbeiten. Während des Refactors schlägt der Agent eine Änderung an einer Bereitstellungskonfigurationsdatei vor, die mehrere Produktionsdienste lesen. Wo sollte ein menschliches Gate für diese eine Aktion sitzen? Wähle die beste einzelne Antwort. aNirgendwo: Die Einstellungen genehmigen bereits Änderungen automatisch, also lass es laufen. bEin Mensch überprüft und genehmigt die Änderung an der Bereitstellungskonfigurationsdatei, bevor der Schreibvorgang ausgeführt wird, weil ein falscher Wert dort schwer rückgängig zu machen ist und Systeme außerhalb der Datei erreicht. cFüge bypassPermissions hinzu, damit der Agent niemals pausiert. dÜberprüfe die Änderung nur nach dem Schreibvorgang, während des nächsten Pull Requests.

Absenden Jetzt überspringen

Screen 5: Dauerhafter Projektkontext mit CLAUDE.md, Rules-Dateien, Hooks und Subagenten

TeachingDauerhafter Projektkontext·20 min Dauerhafter Projektkontext mit CLAUDE. md, Rules-Dateien, Hooks und Subagenten Zuvor haben wir gesehen, wie Claude Code Aktionen durch Berechtigungsmodi und Einstellungsdateien kontrolliert. Diese Konfigurationsebene steuert, was der Agent tun darf. Dieser Cluster baut darauf auf: Jetzt lernst du, wie du konfigurierst, was der Agent weiß und wie er sich verhält, damit die Regeln und der Projektkontext, die du in einer Sitzung definierst, am Anfang der nächsten noch in Kraft sind.

CLAUDE. md: die Projektdatei, die in jede Sitzung lädt Jedes Mal, wenn Claude Code in einem Projektverzeichnis startet, sucht es nach einer Datei namens CLAUDE. md in der Root und liest sie. Der Inhalt wird deinem Prompt angehängt, bevor eine Nachricht von dir ankommt. Das bedeutet, dass jede Konvention, Einschränkung und jeder Befehl, den du in CLAUDE. md einfügst, von der ersten Aufforderung jeder Sitzung an vorhanden ist, ohne dass du ihn erneut angeben musst. Der /init-Befehl scannt deine Codebasis und generiert eine Starter-CLAUDE. md. Die generierte Datei ist eine großartige Grundlage, sollte aber vor der Verwendung validiert werden. Verfeinere sie, um die Regeln zu halten, die das Ergebnis deiner Aufforderungen steuern: deine Test-Befehle, deine Framework-Konventionen, die Pfade, die der Agent nicht berühren sollte, und die Style-Entscheidungen, die von Defaults abweichen. Größe ist der Hauptfehlermodus. Eine CLAUDE. md, die mit jeder neuen Anweisung wächst, kann die Regeln verwässern, die am wichtigsten sind. Eine größere Datei verbraucht mehr des Context-Fensters, was jede einzelne Anweisung zu einem kleineren Bruchteil dessen macht, was lädt, und das reduziert die Chance, dass der Agent die eine Regel befolgt, die einen echten Fehler erfasst. Halte CLAUDE. md auf die Einschränkungen, die Verhalten ändern, und verschiebe alles andere in Skills, die bei Bedarf laden.

Rules-Anweisungsdateien: Scoping-Anleitung, wo sie anwendbar ist Im vorherigen Abschnitt haben wir festgestellt, dass CLAUDE. md in jede Sitzung lädt und die Anweisungen halten sollte, die über das ganze Projekt anwendbar sind. Die nächste Frage ist, was man mit Anleitung tut, die nur in einem Teil der Codebasis wichtig ist. Dort kommen Rules-Anweisungsdateien ins Spiel: Sie lassen dich Anweisungen nur dort anwenden, wo sie relevant sind, statt sie in jede Sitzung zu laden.

CLAUDE. md ist immer an, und Rules-Dateien fügen eine engere Ebene darauf auf. Sie leben im . claude/rules/-Verzeichnis des Projekts und können mit einem Paths-Glob in ihrem YAML-Frontmatter auf spezifische Pfade beschränkt werden. Eine auf diese Weise beschränkte Regel lädt in den Kontext nur, wenn Claude Code mit Dateien arbeitet, die dem Muster entsprechen, dies erlaubt einer Regel, auf einen Teil der Codebasis angewendet zu werden, ohne den Rest des Kontexts zu verstopfen.

Beachte, dass das Scoping vom Frontmatter kommt, nicht von der Dateiplatzierung. Rules-Dateien können in Unterverzeichnisse von . claude/rules/ organisiert werden (z. B. . claude/rules/database/), aber diese Struktur ist nur organisatorisch; eine Rules-Datei ohne ein Paths-Feld lädt bedingungslos beim Start, mit der gleichen Priorität wie CLAUDE. md, egal wo sie in . claude/rules/ sitzt.

In der Praxis: Breite Projektgedächtnis und universelle Einschränkungen in CLAUDE. md, und enge, pfadspezifische Anleitung in Rules-Dateien mit Paths-Scoping. Eine Einschränkung wie „niemals das Datenbankschema ändern" lebt in CLAUDE. md, weil sie überall anwendbar ist. Eine Einschränkung wie „alle SQL im Datenbankmodul müssen eine explizite Transaktionsgrenze enthalten" lebt in . claude/rules/database. md mit Frontmatter wie: --- paths:

"src/db/*/. sql"

--- damit sie nur in den Kontext eintritt, wenn Claude mit diesen Dateien arbeitet.

Hooks: Ausführen deiner eigenen Skripte an festen Punkten im Lebenszyklus Ein Hook ermöglicht es dir, Tool-Aufrufe vor oder nach ihrer Ausführung abzufangen und zu kontrollieren. Wenn du eine spezifische Regel in CLAUDE. md schreibst, die dem Agent sagt, Prettier nach jeder bearbeiteten Datei auszuführen, wird der Agent sie die meiste Zeit befolgen. Alternativ macht ein Hook es jedes Mal passieren, ohne Ausnahmen, weil der Hook unabhängig davon feuert, was das Modell entscheidet zu tun.

Hooks werden in Einstellungsdateien definiert und mit dem /hooks-Befehl konfiguriert. Jeder Hook ist an ein Lebenszyklusereignis, einen optionalen Matcher, der ihn auf spezifische Tool-Typen beschränkt, und einen Befehl gebunden, der feuert, wenn das Ereignis auftritt. Die Kern-Ereignisse für die meisten Guardrail- und Automatisierungsanwendungsfälle sind:

PreToolUse: Läuft vor einem Tool-Aufruf. Weil es zuerst läuft, kann ein PreToolUse-Hook den Tool-Aufruf untersuchen und mit Code 2 beenden, um ihn zu blockieren, und den Grund als Feedback schreiben, das der Agent sieht. So erzwingst du Zugriffskontrolle auf der Konfigurationsebene, statt zu hoffen, dass der Agent eine CLAUDE. md-Anweisung respektiert. PostToolUse: Läuft nach einem Tool-Aufruf. Da der Aufruf bereits passiert ist, kann dieses Ereignis ihn nicht blockieren, was es zum richtigen Ort für automatisierte Nebeneffekte macht: Einen Code-Formatter nach einer Änderung ausführen, Tests nach einer Dateiänderung auslösen oder die Operation für ein Audit-Trail protokollieren. UserPromptSubmit: Läuft, wenn du einen Prompt einreichst, bevor das Modell ihn verarbeitet. Verwende ihn, wenn du Kontext injizieren oder die Anfrage validieren musst, bevor irgendwelche Arbeiten beginnen. Stop: Läuft, wenn das Modell mit der Antwort fertig ist. Verwende es für Folgemaßnahmen, die am Ende einer Runde gehören, wie Benachrichtigungen, Cleanup-Aufgaben oder das Committen des Audit-Logs. Notification: Läuft, wenn Claude Code eine Benachrichtigung sendet, was auftritt, wenn Claude die Berechtigung zur Verwendung eines Tools benötigt oder nachdem Claude Code 60 Sekunden untätig war. Verwende es, um diese Signale zu einem externen Kanal oder Logging-System zu leiten. SessionStart: Läuft, wenn eine Sitzung startet oder fortgesetzt wird. Verwende es, um den Zustand zu initialisieren, Umgebungsvariablen zu validieren oder zu bestätigen, dass erforderliche Dienste erreichbar sind, bevor der Agent mit der Arbeit beginnt. SessionEnd: Läuft, wenn eine Sitzung endet. Verwende es für Teardown-Aufgaben, letzte Audit-Schreibvorgänge oder Benachrichtigungen, dass die Sitzung geschlossen wurde.

Ein Hook, der Änderungen an einem Produktionskonfigurationspfad mit einem PreToolUse-Ereignis blockiert, erzwingt diese Einschränkung bei jedem Tool-Aufruf während jeder Sitzung, unabhängig vom Berechtigungsmodus. Das ist der Unterschied zwischen einem Guardrail und einer Konvention.

Subagenten: Delegieren von Arbeit an einen isolierten Kontext Ein Subagent ist ein spezialisierter Assistent, an den Claude Code Aufgaben delegieren kann, und jeder Assistent führt eine Aufgabe in seinem eigenen separaten Kontext aus und gibt nur seine Ausgabe zurück. Er erbt nicht deine Hauptgesprächshistorie, die Dateien, die du im Kontext angesammelt hast, oder deinen aktuellen Sitzungszustand. Wenn du eine Aufgabe an einen Subagent sendest, startet er von vorne, macht die Arbeit und gibt das Ergebnis zurück.

Die eingebauten Subagenten unterscheiden sich darin, was sie beim Start laden; dieser Unterschied bestimmt, wie deine Projektregeln angewendet werden. Überprüfe immer die aktuelle Liste in der Claude Code-Dokumentation, weil die Menge im Laufe der Zeit gewachsen ist, aber wisse, dass die spezifische Aufteilung, die deine Projektregeln beeinflusst, über Versionen hinweg hält. Die Explore- und Plan-eingebauten Subagenten überspringen CLAUDE. md und Git-Status, um Forschung schnell und billig zu halten. Sie sind für Geschwindigkeit optimiert, daher sind Projektebenen-Regeln und Repository-Zustand, die in CLAUDE. md definiert sind, nicht in ihrem Kontext, wenn sie laufen. Der allgemeine Subagent lädt beide. Wenn du eine Aufgabe an Explore oder Plan delegierst und eine Regel aus deiner CLAUDE. md anwendbar ist, ist es, weil dieser Kontext nicht geladen wurde. Für Aufgaben, bei denen deine Projekteinschränkungen respektiert werden müssen, verwende den allgemeinen Subagent oder einen benutzerdefinierten Subagent, der die Regeln, die er braucht, explizit lädt.

Benutzerdefinierte Subagenten sehen auch nicht automatisch deine Skills. Wenn du einen benutzerdefinierten Subagent in . claude/agents definierst und er braucht einen spezifischen Skill, musst du diesen Skill explizit im Frontmatter des Agenten auflisten. Eingebaute Agenten haben keine vorgeladenen Skills. Wenn ein eingebauter Agent Skill-gestützte Verhaltensweise braucht, ist der richtige Weg, einen benutzerdefinierten Subagent mit diesen Skills in seiner Konfiguration aufgelistet zu erstellen.

Die Karte unten benennt jeden Mechanismus, was er lädt, wann er läuft, seine Kontextkosten und was darin gehört. Verwende sie, um zu entscheiden, welcher Mechanismus ein spezifisches Stück Projektwissen trägt, da jeder einen anderen Kompromiss zwischen Kontextkosten und wie zuverlässig er anwendbar ist, macht. Flip jede Karte für das vollständige Bild.

MechanismusCLAUDE. mdFlip ↻ Was es lädt: Vollständiger Dateiinhalt, dem Kontext beim Sitzungsstart vorangestellt. Wann es läuft: Jede Sitzung, bedingungslos. Kontextkosten: Persistent pro Sitzung. Verdünnt sich mit Größe. Gehört hier hin: Universelle Projekteinschränkungen, Befehle und Framework-Entscheidungen.

MechanismusRules-DateiFlip ↻ Was es lädt: Dateiinhalt. Mit einem Paths-Glob im YAML-Frontmatter beschränkt; ohne Paths lädt wie CLAUDE. md. Wann es läuft: Wenn Claude eine Datei liest, die den Regelmustern entspricht. Unbeschränkte Regeln laden beim Sitzungsstart. Kontextkosten: Pfad-beschränkt: fügt Kontext nur hinzu, wenn ausgelöst. Unbeschränkt: gleiche persistente Kosten wie CLAUDE. md. Gehört hier hin: Pfadspezifische Anleitung, die überall sonst Lärm wäre.

MechanismusHookFlip ↻ Was es lädt: Führe dein Skript beim Lebenszyklusereignis aus. Kein Inhalt wird zum Kontext hinzugefügt. Wann es läuft: Beim konfigurierten Ereignis (PreToolUse, PostToolUse, etc. ). Kontextkosten: Minimal: nur die Skriptausgabe, wenn zum Claude zurückgeleitet. Gehört hier hin: Erzwungene Guardrails, automatisierte Nebeneffekte, Audit-Protokollierung.

MechanismusSubagentFlip ↻ Was es lädt: Nur Aufgabenkontext. Isoliert von der Hauptsitzung. Wann es läuft: Wenn von der Hauptsitzung für eine delegierte Aufgabe versendet. Kontextkosten: Gibt eine Zusammenfassung zurück, nicht die vollständige Aufgabenhistorie. Gehört hier hin: Exploration, Untersuchung und Aufgaben, deren Ausgabe sonst den Hauptkontext aufblähen würde. Auch nützlich für Aufgaben, die aufgeteilt und parallelisiert werden können.

Funktioniert gutProjekte, zu denen du über viele Sitzungen zurückkehrst, wo ein stabiler Satz von Regeln, Pro-Verzeichnis-Variation oder bedingungslose Guardrails die Einrichtung rechtfertigt. Verwende einen anderen AnsatzEinmalige Aufgaben, zu denen du nicht zurückkehrst. Für eine schnelle Exploration einer unbekannten Codebasis ist der Einrichtungsaufwand nicht gerechtfertigt.

Screen 6: Die CLAUDE.md, die wuchs, bis die Regeln nicht mehr landeten

Watch OutDauerhafter Projektkontext·4 min Die CLAUDE. md, die wuchs, bis die Regeln nicht mehr landeten

Setup Deine CLAUDE. md wuchs weiter, weil jede neue Regel sich lohnte hinzugefügt zu werden. Jede Addition war einzeln vernünftig, und die Datei schien der richtige Ort für jede Regel zu sein. Aber über ein paar Wochen wuchs die Datei auf über 800 Zeilen.

Die Spur Das Folgende ist ein Sitzungsprotokoll-Auszug aus einem Projekt mit einer CLAUDE. md, die sich über zwei Monate von Team-Ergänzungen angesammelt hat. Sitzungskontext-Fenster geladen: CLAUDE. md: 847 Zeilen Inhalte enthalten: Framework-Voreinstellungen (Zeilen 1–40), Test-Konventionen (Zeilen 41–90), Style-Guide (Zeilen 91–210), Abhängigkeitsregeln (Zeilen 211–320), Pfad-Einschränkungen (Zeilen 321–360), Historisches Entscheidungsprotokoll (Zeilen 361–700), Archivierte Notizen (Zeilen 701–847) Benutzer-Aufforderung: „Refaktoriere das Auth-Modul, um den neuen Token-Service zu verwenden. Ändere nicht das /legacy/tokens/-Verzeichnis. " Claude Code-Aktion: [Reading auth module ... ] Claude Code-Aktion: [Editing auth/service. ts ... ] Claude Code-Aktion: [Reading /legacy/tokens/store. ts for reference ... ] Claude Code-Aktion: [Editing /legacy/tokens/store. ts to update token interface ... ] Pfad-Einschränkung aus CLAUDE. md (Zeile 347): „Ändere keine Dateien in /legacy/tokens/. " Benutzer: „Du hast gerade /legacy/tokens/store. ts bearbeitet. Ich sagte, dieses Verzeichnis nicht anzufassen. " Claude Code: „Entschuldigung. Die /legacy/tokens/-Einschränkung ist in den Projektanweisungen. Die Änderung wurde im Zuge der Aktualisierung der Token-Schnittstelle vorgenommen. Ich habe den Konflikt nicht vor dem Fortfahren gekennzeichnet. " Die Regel war in der Datei; der Agent hatte Zugriff darauf. Der Fehler war jedoch Verdünnung: 846 andere Zeilen reduzierten das effektive Gewicht der einen Anweisung, die wichtig war. Das Historische Entscheidungsprotokoll und archivierte Notizen sollten irgendwo notiert werden, gehörten aber nicht in die CLAUDE. md.

Was du beachten solltest CLAUDE. md ist ein funktionierendes Regelwerk, das das Verhalten für die aktuelle Sitzung ändert, nicht ein wachsendes Append-Log. Jede Zeile, die du hinzufügst, reduziert das Gewicht jeder anderen Zeile. Wenn eine Regel pfadspezifisch ist, gehört sie in eine Rules-Datei. Wenn eine Regel historischer Kontext ist, gehört sie in ein separates Referenzdokument, das der Agent bei Bedarf liest. Wenn deine CLAUDE. md über ein paar hundert Zeilen wächst, überprüfe sie: Identifiziere, welche Regeln wirklich sitzungskritisch sind, und verschiebe den Rest. Die eine Regel, die du nicht verdünnen kannst, sollte der kürzeste Weg zu einem Hook sein.

Screen 7: Checkpoint 2: Ziehe den richtigen Wert

CheckpointDauerhafter Projektkontext·3 min Checkpoint 2: Ziehe den richtigen Wert Versuche es jetzt. Du richtest einen Hook ein, der eine Pfad-Einschränkung erzwingt, und die Konfiguration unten hat zwei Lücken. Wähle die richtige aus: das Lebenszyklusereignis, das vor einem Tool-Aufruf läuft, und den Befehl, den der Hook ausführt, um Lesevorgänge von . env. production zu blockieren. { "hooks": { "__": [ { "matcher": "Read", "hooks": [{ "type": "command", "command": "__" }] } ] } }

Lücke 1: das Lebenszyklusereignis PreToolUsePostToolUseUserPromptSubmitSessionStart Lücke 2: der Befehl Ein Skript, das den Tool-Aufruf von stdin liest, den Dateipfad überprüft und mit Code 2 beendet, wenn der Pfad . env. production ist (den Grund zu stderr schreibend). Ein Skript, das den Tool-Aufruf in eine Audit-Datei protokolliert und 0 beendet. Ein Skript, das bedingungslos eine Warnung ausgibt und 0 beendet.

Absenden Jetzt überspringen

Screen 8: Einen Workflow als Plugin verpacken: Skills, benutzerdefinierte Befehle und Marketplace-Installation

TeachingWorkflows verpacken·8 min Einen Workflow als Plugin verpacken: Skills, benutzerdefinierte Befehle und Marketplace-Installation Zuvor haben wir die Mechanismen behandelt, die Claude Code dauerhaften Kontext und erzwungenes Verhalten geben: CLAUDE. md für immer-an Projektgedächtnis, Rules-Dateien für beschränkte Anleitung, Hooks für deterministische Guardrails und Subagenten für isolierte Task-Delegation.

Diese Mechanismen leben in deinem . claude-Verzeichnis und sind versionskontrolliert mit dem Projekt. Jetzt wenden wir uns der nächsten Frage zu: Wie kannst du diese Einrichtung verpacken, damit ein Teamkollege sie in einem Schritt einfach installieren kann, statt deine manuelle Konfiguration von Hand zu wiederholen?

Skills sind wiederverwendbare Workflows, die der Agent bei Bedarf lädt Ein Skill ist eine tragbare Markdown-Datei (SKILL. md-Datei), die in . claude/skills platziert ist. Das Frontmatter identifiziert den Skill und beschreibt, wann er anwendbar ist, und der Body hält die Schritte. Der gleiche Skill kann in Claude Code laufen, über Messages API aufgerufen werden oder vom Agent SDK geladen werden. Was sich über die drei ändert, ist nicht die Datei selbst; es ist, wo der Skill läuft, wie er geladen wird und was er berühren darf. Ein Developer, der Skills nur in Claude Code gesehen hat, kann Dinge annehmen, die auf der API nicht wahr sind, daher skizziert dieser Abschnitt die Unterschiede.

Wie der Skill in jedem lädt und läuft Wähle jeden Tab aus, um zu sehen, wie der Skill lädt, wo die Schritte laufen und was du wissen musst.

Claude Code Messages API Agent SDK Claude Managed Agents

Wie der Skill lädt: Entdeckt aus . claude/skills im Dateisystem. Lädt bei einer Beschreibungsübereinstimmung oder wenn du ihn nach Name aufgerufen hast. Wo die Schritte laufen: In deiner Terminal-Sitzung, gegen deine lokalen Dateien, unter dem aktiven Berechtigungsmodus und Deny-Regeln. Was du wissen musst: Es ist dateisystembasiert und wird von der Einstellungsebene kontrolliert.

Wie der Skill lädt: Mit der Anfrage gesendet und im Code-Ausführungs-Container ausgeführt, nicht in deiner Anwendungsumgebung. Erfordert Code-Ausführungs- und Skills-Beta-Header. Wo die Schritte laufen: Im Anthropic-Code-Ausführungs-Container, nicht auf deinem Computer. Das Dateisystem und die Tool-Zugriffe des Skills sind, was dieser Container bietet. Was du wissen musst: Ein Skill, der lokale Dateien oder lokale Tools annimmt, verhält sich nicht gleich hier, weil er nicht dort läuft, wo diese Dateien sind.

Wie der Skill lädt: Vom Agent geladen, den das SDK ausführt, aber ob Dateisystem-Einstellungen (CLAUDE. md, Skills) laden, wird durch die settingSources-Konfiguration kontrolliert. Verlasse dich nicht auf einen Standard: Stelle ihn immer explizit auf die Quellen ein, die du beabsichtigst, und bestätige das aktuelle Standard-Verhalten gegen die Agent SDK-Referenz beim Build. Du stellst es durch die „settingSources" (TypeScript) / „setting_sources" (Python) ein. Wo die Schritte laufen: Im Prozess, den das SDK ausführt, was deine Umgebung ist, sobald du ihm gesagt hast, Dateisystem-Quellen zu laden. Was du wissen musst: Die häufige Überraschung: Ein Skill, der in Claude Code funktionierte, tut nichts unter dem SDK, weil settingSources nie gesetzt wurde, daher wurde der Skill nie geladen.

Wie der Skill lädt: Einmal als API-Ressource definiert, die das Modell, den System-Prompt, Tools, MCP-Server und Skills benennt. Anthropic lädt den Skill-Server-seitig, wenn der Agent läuft, daher gibt es keinen Dateisystem-Entdeckungsschritt auf deiner Seite. Wo die Schritte laufen: In einer Sandbox, die Anthropic bereitstellt und läuft, nicht deine Umgebung. Deine Anwendung sendet Benutzer-Events und liest gestreamte Ergebnisse zurück. Der Skill hat Zugriff auf, was diese verwaltete Sandbox bietet, nicht deine lokalen Dateien. Was du wissen musst: Derzeit eine öffentliche Beta, die den managed-agents-2026-04-01-Beta-Header erfordert, und Sitzungen werden Server-seitig gespeichert, was bedeutet, dass Managed Agents derzeit nicht für Zero Data Retention oder HIPAA BAA-Abdeckung berechtigt sind. Skills werden beim Definieren der Agent-Ressource angehängt, nicht zur Sitzungszeit. Aktualisiere die Agent-Definition, um zu ändern, welche Skills verfügbar sind.

Drei Portabilitätsregeln

Schreibe die Beschreibung als Matching-Kriterium. Das Modell lädt einen Skill, indem es deine Anfrage mit seiner Beschreibung vergleicht, daher funktioniert eine Beschreibung, die identifiziert, wann der Skill anwendbar ist, in jeder Runtime, aber eine vage funktioniert nicht in allen. Nimm nicht an, dass ein lokales Dateisystem oder lokale Tools im Skill-Body existieren. Ein Skill, der zu einem lokalen Befehl ausführt, funktioniert in Claude Code, aber bricht auf der Messages API, wo er in einem Container ohne einen Befehl läuft. Halte die Schritte des Skills auf das beschränkt, was die Runtime garantiert bietet, oder dokumentiere die Abhängigkeit. Denke daran, dass Subagenten Skills nicht erben. Dies war in Modul 2 wahr und ist hier immer noch wahr: Ein Subagent startet sauber, daher muss ein Skill, auf den das Parent sich verließ, für den Subagent explizit aufgelistet werden, in jeder Runtime, die Subagenten unterstützt.

Der praktische Takeaway ist, dass du einen Skill einmal schreiben und wiederverwenden kannst, aber du musst speziell für die Fähigkeit entwerfen, ihn über Terminals zu verwenden. Ein Skill, der auf eine klare Beschreibung beschränkt ist und frei von lokalen Umgebungsannahmen ist, portiert sauber über Runtimes, aber einer, der eine spezifische lokale Umgebung annimmt, nicht.

Funktioniert gutFügt Komplexität hinzuVerwende einen anderen Ansatz

Eine aufgabenspezifische Prozedur, die einmal geschrieben und über das interaktive Terminal, eine API-Integration und einen headless SDK-Job wiederverwendet wird. Jede Runtime lädt und sandboxed den Skill anders, daher musst du Beta-Header auf der API und settingSources auf dem SDK berücksichtigen. Für Anweisungen, die auf jede Sitzung in einem Projekt angewendet werden müssen, ist CLAUDE. md immer noch das richtige Tool. Skills sind für On-Demand-, tragbare Prozeduren.

Einem Workflow einen expliziten Einstiegspunkt geben Ein benutzerdefinierter Befehl ist eine Abkürzung für eine definierte Prozedur. Im aktuellen Claude Code sind Skills das empfohlene Format für sowohl explizite als auch automatische Aufrufe: Du rufst einen Skill direkt mit /skill-name auf, oder Claude lädt ihn automatisch, wenn relevant. Das ältere . claude/commands/-Verzeichnisformat funktioniert immer noch, ist aber ein Legacy-Prozess. Verwende Skills mit disable-model-invocation: true im Frontmatter, wenn du einen Workflow möchtest, der nur läuft, wenn du ihn explizit aufrufst.

Plugin-Befehle werden automatisch namensgebunden: Der Name des Plugins wird zum Präfix, daher wird ein run-tests-Befehl in einem Plugin namens payments als /payments:run-tests aufgerufen. Dies ist, warum zwei Plugins beide einen run-tests-Befehl versenden können, ohne zu kollidieren. Autoren sollten den Plugin-Namen als Teil der Schnittstelle behandeln, da er jeden Befehl präfixiert, den du versendest, und sich bewusst sein, dass das Umbenennen des Plugins sie alle umbenennt.

Die Verpackungsebene, die eine Einrichtung installierbar macht Ein Plugin bündelt Skills, Hooks, Subagenten und MCP-Server-Konfigurationen in eine einzelne installierbare Einheit. Plugins können verpackt und über einen Marketplace verteilt werden, der ein Katalog von Plugins ist, die jemand anderes erstellt und geteilt hat. Der offizielle Anthropic-Marketplace ist automatisch verfügbar, wenn du Claude Code startest, und du kannst Drittanbieter-Marketplaces, die in einem GitHub-Repository gehostet werden, mit einem Befehl wie /plugin marketplace add <owner/repo> hinzufügen. Teamkollegen können dann einen einfachen Install-Befehl ausführen, um die gleiche Einrichtung zu bekommen. Das Plugin ersetzt eine Seite manueller Einrichtungsschritte durch ein versioniertes, überprüfbares Install. Das Plugin platziert Komponenten wie folgt:

Skills gehen in ein Skills-Verzeichnis. Hooks, Subagenten und Einstellungen gehen an ihre jeweiligen Orte.

Das Plugin-Manifest beschreibt das Bundle, und der Install-Befehl verdrahtet es in die Zielinstallation. Plugins können von Einzelnen oder auf Unternehmensebene heruntergeladen werden.

Unternehmensadministratoren können Plugins organisationsweit durch verwaltete Einstellungen bereitstellen. Eine verwaltete Marketplace-Allowlist kontrolliert, welche Marketplace-Quellen Benutzer hinzufügen dürfen, daher kontrolliert die Organisation, woher Plugins kommen können. Die Allowlist beschränkt, was Benutzer hinzufügen können, registriert aber Marketplaces nicht automatisch. Wenn du einen Marketplace an alle Benutzer pushen möchtest, ohne dass sie den Add-Befehl selbst ausführen müssen, kombiniere die Allowlist-Einstellung mit extraKnownMarketplaces in verwalteten Einstellungen. Die Vorrangigkeit kommt vom Bereitstellungsumfang: Weil verwaltete Einstellungen in der Konfigurationshierarchie über Benutzer- und Projekteinstellungen sitzen, hat ein Plugin, das im verwalteten Umfang bereitgestellt wird, Vorrang und kann nicht von Benutzern oder Projektdateien überschrieben werden. Überprüfe die Referenzebene für die genauen Einstellungsnamen.

Die Verpackungsentscheidungstabelle Die Tabelle unten identifiziert jede Ebene, wer sie ist, und wann man sie erreicht.

EbeneWas es istWer es istWann man es erreicht

SkillEine Markdown-Datei in . claude/skills, die lädt, wenn ihre Beschreibung der Aufgabe entspricht oder wenn du sie nach Name aufgerufen hast. Ein einzelner Developer oder Team, das Claude Code interaktiv verwendet. Erreiche einen Skill, wenn eine aufgabenspezifische Prozedur aus dem Kontext bleiben sollte, bis sie benötigt wird, wie eine PR-Überprüfung oder eine Bereitstellungs-Checkliste, die nur lädt, wenn die Arbeit danach verlangt. Benutzerdefinierter BefehlEine benannte Abkürzung, die eine definierte Prozedur ausführt, wenn du sie explizit aufgerufen hast. Developer, die einen vorhersehbaren, expliziten Einstiegspunkt für häufige Prozeduren möchten. Erreiche einen benutzerdefinierten Befehl, wenn die Prozedur einen klaren Namen hat und du sie direkt auslösen möchtest, statt dich auf die Beschreibung zu verlassen, um die Aufgabe zu treffen. PluginEin versioniertes Bundle von Skills, Hooks, Subagenten und MCP-Server-Konfigurationen, das über einen Marketplace verteilt wird. Ein Team, das eine One-Step-Installation einer gemeinsamen, versionierten Einrichtung möchte. Erreiche ein Plugin, wenn eine funktionierende Einrichtung derzeit auf einer Maschine lebt und über ein Team geteilt, versioniert und konsistent gehalten werden muss.

Kosten · Komplexität · Risiko Kosten: Skills fügen Kontextkosten bei Aktivierung hinzu, aber ein Plugin fügt Installations- und Wartungsaufwand hinzu. Die Frage, die man stellen sollte, ist, ob man die Einrichtungskosten einmal zahlen möchte, wie man es mit einer Plugin-Installation tut, oder wiederholt, wie man es tut, wenn jeder Developer die gleichen manuellen Schritte von Hand ausführt. Komplexität: Ein Plugin, das absolute Pfade im Home-Verzeichnis des Autors hart codiert, installiert sich korrekt für den Autor und schlägt für alle anderen fehl, weil jede Pfad- oder Umgebungsannahme, die in einen Skill oder Hook-Befehl gebacken ist, das ist, was am wahrscheinlichsten über Maschinen bricht. Risiko: Ein Plugin trägt die Komponenten, die es bündelt, in jede Installation. Es ist wichtig zu denken, dass eine Deny-Regel oder ein Hook, auf den sich der Autor lokal verließ, nicht enthalten ist, es sei denn, er ist explizit als Teil des Bundles aufgelistet. Wenn die Skills oder Hooks an einen Guardrail gebunden sind, der nicht im Bundle enthalten ist, dann trägt der Schutz nicht zu der Maschine eines Teamkollegen über.

Screen 9: Checkpoint 3: Platziere den Skill in der richtigen Runtime

CheckpointWorkflows verpacken·3 min Checkpoint 3: Platziere den Skill in der richtigen Runtime Versuche es jetzt. Drei Teams möchten den gleichen review-checklist-Skill an verschiedenen Orten wiederverwenden.

Für jeden, match, was konfiguriert werden muss, damit der Skill lädt und läuft. Hinweis: Die Quelle präsentiert vier Runtime-Situationen. Alle vier sind hier enthalten, damit das Match vollständig bleibt. Ein Developer möchte, dass der Skill lädt, wenn er um eine Überprüfung in dem Claude Code-Terminal bittet. Aktiviere Dateisystem-Quellen, indem du settingSources explizit stellst, damit der Agent Skills aus dem Projekt lädt. Verlasse dich nicht auf einen Standard, und bestätige das aktuelle Standard-Verhalten gegen die Agent SDK-Referenz beim Build. Platziere SKILL. md in . claude/skills mit einer Beschreibung, die Überprüfungsanfragen entspricht. Definiere den Agent als API-Ressource, die den Skill auflistet, und stelle den managed-agents-2026-04-01-Beta-Header auf den Aufrufen ein. Schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien abhängen, weil er in Anthropics Sandbox läuft. Sende die Code-Ausführungs- und Skills-Beta-Header und schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien oder lokalen Tools abhängen. Ein Service ruft die Messages API auf und möchte, dass der Skill als Teil der Anfrage läuft. Aktiviere Dateisystem-Quellen, indem du settingSources explizit stellst, damit der Agent Skills aus dem Projekt lädt. Verlasse dich nicht auf einen Standard, und bestätige das aktuelle Standard-Verhalten gegen die Agent SDK-Referenz beim Build. Platziere SKILL. md in . claude/skills mit einer Beschreibung, die Überprüfungsanfragen entspricht. Definiere den Agent als API-Ressource, die den Skill auflistet, und stelle den managed-agents-2026-04-01-Beta-Header auf den Aufrufen ein. Schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien abhängen, weil er in Anthropics Sandbox läuft. Sende die Code-Ausführungs- und Skills-Beta-Header und schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien oder lokalen Tools abhängen. Ein geplanter headless Job verwendet Agent SDK und erwartet den Skill aus dem Repo zu laden. Aktiviere Dateisystem-Quellen, indem du settingSources explizit stellst, damit der Agent Skills aus dem Projekt lädt. Verlasse dich nicht auf einen Standard, und bestätige das aktuelle Standard-Verhalten gegen die Agent SDK-Referenz beim Build. Platziere SKILL. md in . claude/skills mit einer Beschreibung, die Überprüfungsanfragen entspricht. Definiere den Agent als API-Ressource, die den Skill auflistet, und stelle den managed-agents-2026-04-01-Beta-Header auf den Aufrufen ein. Schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien abhängen, weil er in Anthropics Sandbox läuft. Sende die Code-Ausführungs- und Skills-Beta-Header und schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien oder lokalen Tools abhängen. Ein Produktteam möchte den gleichen review-checklist-Skill in einem langfristigen Agent ausführen, den Anthropic hostet, erreichbar durch eine Agent-ID über Sitzungen. Aktiviere Dateisystem-Quellen, indem du settingSources explizit stellst, damit der Agent Skills aus dem Projekt lädt. Verlasse dich nicht auf einen Standard, und bestätige das aktuelle Standard-Verhalten gegen die Agent SDK-Referenz beim Build. Platziere SKILL. md in . claude/skills mit einer Beschreibung, die Überprüfungsanfragen entspricht. Definiere den Agent als API-Ressource, die den Skill auflistet, und stelle den managed-agents-2026-04-01-Beta-Header auf den Aufrufen ein. Schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien abhängen, weil er in Anthropics Sandbox läuft. Sende die Code-Ausführungs- und Skills-Beta-Header und schreibe den Skill so, dass seine Schritte nicht von lokalen Dateien oder lokalen Tools abhängen.

Absenden Jetzt überspringen

Screen 10: Das Plugin, das auf deinem Computer installiert wurde und auf allen anderen fehlschlug

Watch OutWorkflows verpacken·3 min Das Plugin, das auf deinem Computer installiert wurde und auf allen anderen fehlschlug

Setup Ein Plugin, das sauber installiert, sagt dir, dass das Paket korrekt zusammengestellt wurde; es sagt dir jedoch nicht, dass das Plugin effektiv läuft, weil Installation und Ausführung verschiedene Dinge sind. Die Installation kopiert Dateien an ihren Platz. Die Ausführung löst die Pfade und Variablen auf, auf die diese Dateien zeigen, gegen die Maschine, auf der sie laufen. Wenn ein Plugin-Autor das Layout seiner eigenen Maschine in einen Skill hart codiert, installiert sich das Plugin immer noch überall erfolgreich, aber die Ausführung schlägt überall außer auf der Einrichtung des Autors fehl. Diese Lücke tritt auf, weil es etwas ist, das der Autor nicht sehen kann.

Was passierte Ein Developer baute einen Bereitstellungs-Workflow-Skill, verpackte ihn als Plugin und testete ihn lokal. Lokale Tests bestanden, das Plugin ging an das Team über den internen Marketplace, und jede Teamkollege-Installation war erfolgreich, aber in dem Moment, in dem ein Teamkollege den Skill ausführte, schlug er fehl.

Die Grundursache saß im SKILL. md des Skills, in einem Befehl, der auf /Users/alexmorgan/projects/deploy-utils/validate. sh zeigte.

Dieses Verzeichnis existierte auf der Maschine des Autors und nirgendwo sonst. Der Skill trug einen absoluten Pfad zum Home-Verzeichnis des Autors, daher suchte jede Teamkollege-Ausführung nach einer Datei, die auf ihrem System war oder im Skill enthalten war.

Ein zweiter Skill im gleichen Plugin lehnte sich auf eine Umgebungsvariable, DEPLOY_TOKEN, an, die der Autor in seinem eigenen Shell-Profil gesetzt hatte, und das Plugin-README erwähnte es nie. Drei Teamkollegen verbrachten zwei Stunden mit Debugging, bevor sie den zweiten Fehler auf die fehlende Variable zurückführten.

Das Plugin behandelte die Maschine des Autors falsch als die Maschine des Teams, was den Break verursachte. Beide Fehler im Beispiel oben haben die gleiche Grundursache und den gleichen absoluten Pfad. Er sitzt im SKILL. md als Klartext, und ein Reviewer, der die Datei liest, kann ihn erfassen. Die Umgebungsvariable kann gefährlich sein, weil nichts im Paket die zugehörige Abhängigkeit ankündigt, was bedeutet, dass der Skill fein läuft, bis zum Schritt, der die Variable braucht, und nur dann schlägt er fehl. Dies ist, warum es drei Personen zwei Stunden kosten kann, um es zu beheben.

Was du beachten solltest Jede Pfad-Referenz in einem Skill, Hook-Befehl oder Plugin-Komponente muss relativ zum Projekt-Root sein oder eine Umgebungsvariable für den Basis-Pfad verwenden. Verwende $CLAUDE_PROJECT_DIR, um Skripte zu referenzieren, die im Projekt gespeichert sind, und ${CLAUDE_PLUGIN_ROOT} für Skripte, die im Plugin selbst gebündelt sind, damit der Pfad korrekt auflöst, egal auf wessen Maschine er läuft oder in welchem Verzeichnis die Sitzung gestartet wurde. Stelle sicher, dass alle Skripte, Konfigurationsdateien oder andere Assets, auf die das Plugin angewiesen ist, entweder im Plugin gebündelt oder an einem gemeinsamen Projektort enthalten sind, damit jeder Teamkollege nach der Installation auf die gleichen Dateien zugreifen kann. Dokumentiere jede Umgebungsvariable, die das Plugin benötigt, und validiere sie zur Installationszeit, damit eine fehlende sofort auftaucht, statt mitten im Lauf. Teste dann die Installation auf einer sauberen Maschine vor der Verteilung; dies wird alle Probleme erfassen, die die Build-Maschine möglicherweise versteckt.

Screen 11: Checkpoint 4: Behebe die fehlerhafte Plugin-Definition

CheckpointWorkflows verpacken·4 min Checkpoint 4: Behebe die fehlerhafte Plugin-Definition Versuche es jetzt. Das folgende SKILL. md funktioniert auf der Maschine des Autors, schlägt aber fehl, wenn ein Teamkollege das Projekt klont und das Plugin installiert.

Wähle den einzelnen Defekt aus, dann wähle die richtige Behebung aus. --- name: deploy-validate description: Validates a deployment configuration before release. ---

Steps

Run the validation script: /Users/alexmorgan/projects/deploy-utils/validate. sh absoluter Pfad
If the script exits with a non-zero code, report the error to the developer.
If validation passes, confirm the deployment configuration is safe to proceed.

Teil 1 · Welcher ist der Defekt? ADer Skill-Name entspricht nicht dem Plugin-Namen. BDie Beschreibung ist zu kurz, damit das Modell sie abgleicht. CDer absolute Pfad /Users/alexmorgan/projects/deploy-utils/validate. sh in Schritt 1. DSchritt 2 sollte dem Benutzer berichten, nicht dem Developer. Teil 2 · Welche ist die richtige Behebung? AReferenziere das Skript vom Projekt-Root mit CLAUDE_PROJECT_DIR, damit es auflöst, egal wo das Projekt geklont wird. BErsetze den Pfad mit einem anderen absoluten Pfad, der auf ein gemeinsames Netzwerk-Laufwerk zeigt. CErsetze den Pfad mit einer Home-Verzeichnis-Abkürzung: ~/projects/deploy-utils/validate. sh. DEntferne Schritt 1, damit der Skill nicht mehr ein externes Skript aufgerufen hat.

Absenden Jetzt überspringen

Screen 12: Einen MCP-Server bauen und konfigurieren: Transport, Umfang und der GitHub-Server

TeachingMCP-Server·21 min Einen MCP-Server bauen und konfigurieren: Transport, Umfang und der GitHub-Server Frühere Abschnitte führten Plugins als die Verpackungsebene ein, die Skills, Hooks, Subagenten und MCP-Server in eine einzelne installierbare Einheit bündelt.

Dieser Abschnitt erklärt weiter, was MCP-Server-Bundles sind und wie man sie baut. Beim Bauen eines MCP-Servers ist eine der ersten Entscheidungen die Bestimmung des angemessenen Transport-Mechanismus und die Definition des Umfangs des Servers.

Was ist ein MCP-Server und warum ist er anders als das direkte Verdrahten eines Tools? Beim direkten Verdrahten eines Tools in eine Anwendung bist du verantwortlich für die Definition des Tool-Schemas und seiner Funktionalität. Beide leben im Code dieser Anwendung. Wenn drei verschiedene Anwendungen Zugriff auf den gleichen externen Service brauchen, verwaltet jede ihre eigene Integration. Model Context Protocol, oder MCP, trennt Tool-Definitionen von einzelnen Anwendungen und verwandelt sie in einen Prozess namens Server.

Ein MCP-Server ist ein Prozess, der Tools, Ressourcen und Prompts exponiert, die MCP-Clients verwenden können. Claude Code hat einen eingebauten MCP-Client. Wenn du dich mit einem MCP-Server verbindest, entdeckt Claude Code die Tools, die er bietet, und kann sie während einer Sitzung aufgerufen. Mit einem MCP-Server baust du die Fähigkeit einmal, und jeder MCP-Client, der sich verbindet, bekommt Zugriff, ohne die Integration erneut zu implementieren.

MCP-Server exponieren auch Ressourcen und Prompts Ein MCP-Server exponiert Tools, Ressourcen und Prompts. Wir haben bereits über Tools gelernt: Aktionen, die das Modell aufgerufen kann. Die anderen zwei decken Fälle ab, wo ein Tool-Aufruf dir nicht gibt, was du brauchst.

Eine Ressource ist schreibgeschützte Daten, die der Server exponiert, damit der Client sie abruft und direkt in den Kontext platziert, statt dass das Modell einen Tool-Aufruf macht, um sie zu bekommen. Der Client fordert eine Ressource nach ihrer Adresse an, und der Server gibt die Daten zurück. Ressourcen kommen in zwei Formen: eine direkte Ressource hat eine feste Adresse für Daten, die keine Parameter brauchen, wie eine Liste verfügbarer Dokumente, und eine templated Ressource setzt einen Parameter in die Adresse, wie eine Dokument-Adresse, die eine Dokument-ID braucht. Erreiche eine Ressource, wenn du bekannte Daten vom Anfang einer Runde im Kontext haben möchtest. Du möchtest dies, wenn das Abrufen einer Ressource direkt billiger und vorhersehbarer ist als die Verwendung eines Tool-Aufrufs, um sie zu holen. Ressourcen-Unterstützung variiert über MCP-Clients; überprüfe, dass dein Client einen Mechanismus hat, um Ressourcen in den Kontext zu injizieren, bevor du dich auf dieses Muster verlässt.

Ein Prompt ist eine vorgefertigte Anweisungs-Template, die der Server exponiert, damit ein Client einen überprüften Prompt nach Name aufgerufen kann, statt dass jeder Benutzer seinen eigenen schreibt. Ein Benutzer kann bereits das Modell bitten, die meisten Aufgaben in seinen eigenen Worten zu tun, daher ist ein Prompt nützlich, wenn spezifische Wortlaut benötigt wird: eine Aufgabe, wo eine sorgfältig gebaute Anweisung materiell bessere Ergebnisse erzeugt als was ein Benutzer tippen würde, und wo du möchtest, dass jeder Client die gleiche Qualität bekommt. Das Verpacken der Anweisung auf dem Server bedeutet, dass der Prompt an einem Ort verwaltet wird und überall dort wiederverwendet wird, wo der Server verbunden ist.

Transport: Wie Claude Code mit dem Server spricht Transport ist der Kommunikationskanal zwischen dem MCP-Client und dem MCP-Server. Der richtige Transport hängt davon ab, wo der Server läuft. Wähle jeden Tab aus, um zu sehen, was es ist und wann man es verwendet.

stdio HTTP SSE

stdio führt den Server als lokalen Prozess auf der gleichen Maschine wie der Client aus. Der Client startet den Server als Subprocess und kommuniziert über Standard-Input und Output. Dies ist die richtige Wahl für ein lokales Tool, ein persönliches Skript oder einen Entwicklungs-Server, den du auf deiner eigenen Maschine läufst. Es funktioniert nicht für einen Server, den du über dein Team teilen möchtest oder remote hosten möchtest.

HTTP ist die empfohlene Form des Transports für jeden Server, der nicht lokal läuft. Es verbindet sich über eine Standard-HTTP-Verbindung und unterstützt Server, die auf einer anderen Maschine gehostet werden. Wenn du einen HTTP-Server registrierst, gibst du die URL an und der Client verbindet sich über das Netzwerk. Gemeinsame Team-Server und gehostete Integrationen verwenden HTTP.

SSE (Server-Sent Events) ist ein älteres Mittel des Transports, das dem aktuellen HTTP-Transport vorausgeht. Es wurde durch HTTP-Transport ersetzt und wird nicht mehr für neue Server empfohlen. Wenn du SSE in bestehender Konfiguration oder Dokumentation triffst, behandle es als Legacy-Option statt einer aktuellen Empfehlung.

Kontextkosten Jeder verbundene MCP-Server trägt Tool-Definitionen bei, die den Context-Fenster besetzen würden, wenn sie upfront geladen würden. Standardmäßig verschiebt Claude Code diese Definitionen, statt sie upfront zu laden, und verwendet einen Suchschritt, um nur die relevanten Tools zu entdecken und zu laden, wenn eine Aufgabe danach verlangt. Nur die aufgerufenen Tools treten in den Kontext ein.

Ein Opt-in-Modus lädt Tool-Definitionen upfront, wenn sie in ungefähr 10 Prozent des Context-Fensters passen, verschiebend nur, wenn dieses Limit überschritten wird. Entweder Weg, das Verbinden nur der Server, die du brauchst, hält jede Anfrage schlank, weil jeder verbundene Server zum Pool von Definitionen hinzufügt, die das Modell berücksichtigen muss.

Prompt-Caching: Einmal zahlen für wiederverwendbare Anfragen Das Context-Cost-Problem, das du gerade mit MCP-Servern gesehen hast, hat sowohl eine Kosten- als auch eine Fenster-Dimension. Jede Anfrage verarbeitet ihre Eingabe von Grund auf neu, einschließlich der Teile, die auf der letzten Anfrage identisch waren, was bedeutet, dass du jedes Mal für die Neuverarbeitung der gleichen Tokens zahlst. Prompt-Caching kann dich davon abhalten, zweimal für den gleichen stabilen Inhalt zu zahlen.

Caching speichert die Verarbeitungsarbeit, die auf einem stabilen Präfix deiner Anfrage geleistet wurde, damit eine Folgeanfrage sie wiederverwenden kann, statt die gleichen Tokens neu zu verarbeiten. Die erste Anfrage schreibt das Präfix in den Cache, und Folgeanfragen senden identischen Inhalt bis zum gleichen Punkt im Cache zu einem Bruchteil der Kosten. Der Inhalt muss genau übereinstimmen: ein einzelnes geändertes Zeichen vor dem Cache-Punkt invalidiert diesen Cache und erzwingt einen frischen Schreib. Dies ist, warum die stärksten Kandidaten für Caches die Teile einer Anfrage sind, die sich selten ändern, wie ein langer System-Prompt, ein großer Satz von Tool-Definitionen oder ein Referenzdokument, das du mehrere Fragen über stellst.

Du schaltest Caching ein, indem du einen Cache-Breakpoint markierst; es gibt keine globale Einstellung, die Caching einschaltet. In der Messages API fügst du ein cache_control-Feld vom Typ ephemeral zum letzten Block hinzu, den du gecacht haben möchtest; dies cachet alles bis zu und einschließlich dieses Blocks. Du kannst bis zu vier Breakpoints platzieren. Die Anfrage wird in einer festen Reihenfolge von Tools, System-Prompt und Nachrichten verarbeitet, daher cachet ein Breakpoint nach den Tools die Tool-Definitionen, während die Nachrichten dynamisch bleiben.

Der Cache hat ein Zeitlimit. Die Standard-Cache-Lebensdauer ist fünf Minuten ab dem letzten Lesen. Eine Opt-in-Einstunden-Lebensdauer ist verfügbar, indem du ein ttl von 1h auf dem Breakpoint stellst. Die fünf-Minuten-Standard passt zu einem Back-and-Forth-Modell, wo Anfragen alle paar Minuten ankommen, da jedes Lesen die Uhr zurückstellt. Die Einstunden-Option passt zu einer Workload mit längeren Lücken zwischen Anfragen, wie ein Agent, der zwischen Schritten pausiert, wo das fünf-Minuten-Fenster vor der nächsten Anfrage ablaufen würde. Wenn das Fenster vor der nächsten Anfrage abläuft, zahlst du die Schreib-Kosten erneut für keinen Lese-Vorteil. Bitte beachte, dass Caching nur über einem Mindest-Token-Schwellenwert anwendbar ist (1. 024 Tokens für die meisten aktuellen Modelle), daher werden kurze Prompts nicht gecacht, auch wenn ein Breakpoint gesetzt ist.

Retrieval-augmented generation: Wie Claude nur das Wissen zieht, das eine Anfrage braucht Das Context-Cost-Problem, das du gerade mit MCP-Servern gesehen hast, ist das gleiche, das ein großer Körper von Referenzmaterial erzeugt. Ein Modell liest alles in seinem Context-Fenster für jede Anfrage, daher je mehr Dokumente du upfront lädst, desto mehr Kontext wird verwendet, und desto weniger Platz bleibt für die Arbeit. Retrieval-augmented generation, normalerweise RAG abgekürzt, ist das Muster, das dies auflöst. Statt jedes Dokument in den Kontext zu laden, speichert das System das Material außerhalb des Context-Fensters, findet die Teile, die am relevantesten zur aktuellen Anfrage sind, und liefert nur diese Teile dem Modell zur Anfrage-Zeit. Das Modell generiert dann seine Antwort aus diesem abgerufenen Slice, statt aus der ganzen Bibliothek.

RAG kommt in zwei Formen: Classical RAG macht die harte Arbeit upfront. Bevor jemand eine Frage stellt, wird das Quellmaterial in Chunks aufgeteilt, und jeder Chunk wird in einen Satz von Zahlen (genannt ein Embedding) konvertiert, der seine Bedeutung mathematisch erfasst. Diese Zahlen werden in einer Datenbank gespeichert. Wenn ein Benutzer eine Frage stellt, konvertiert das System die Frage in die gleiche Art von Zahlen, dann findet, welche Chunks die ähnlichsten Zahlen haben. Denke daran wie ein Bibliothekar, der, bevor die Bibliothek öffnet, bereits jedes Buch gelesen und eine präzise Zusammenfassungskarte für jedes Kapitel geschrieben hat, daher wenn du mit einer Frage ankommst, können sie die richtigen Karten sofort ziehen. Agentic search überspringt die upfront-Indexierung ganz. Es gibt keine vorgefertigte Datenbank. Stattdessen findet das Modell heraus, was es braucht, in dem Moment, in dem du fragst, dann geht und holt es: Sucht Live-Quellen, liest Dokumente bei Bedarf, zieht Ergebnisse, während die Aufgabe entfaltet. Denke daran wie ein Forscher, der, wenn du eine Frage stellst, geht und die Antwort selbst findet, statt vorgefertigte Karten zu konsultieren. Du bist möglicherweise bereits auf agentic search gestoßen, ohne seinen Namen zu kennen. In Claude Code, wenn du mit vielen externen Tools verbunden bist (MCP-Server), lädt Claude nicht jede Tool-Definition upfront; das wäre zu viel zum Halten auf einmal. Stattdessen entdeckt und lädt es nur die Tools, die es für die aktuelle Aufgabe braucht. Claude. ai Projects funktioniert gleich für hochgeladene Dokumente: wenn die Wissensbasis eines Projekts größer wird als in das aktive Fenster passt, zeigt es nur die Dokument-Abschnitte, die am relevantesten zu jeder Frage sind, statt alles zu laden. Beide Ansätze tun das gleiche fundamentale Ding; sie finden beide einen relevanten Slice von Material und generieren daraus. Der Unterschied ist Timing: Classical RAG findet den Slice durch Abgleich gegen einen Index, der im Voraus gebaut wurde; agentic search findet ihn durch Suche im Moment der Notwendigkeit.

Zwei Eigenschaften des Abrufs sind es wert, verstanden zu werden, bevor du danach greifst:

Es skaliert. Wenn dein Quellmaterial wächst, bleiben die Kosten jeder Anfrage flach, weil das Modell nur den Slice erhält, der für diese Frage relevant ist, nicht die ganze Bibliothek. Eine Wissensbasis kann auf Tausende von Dokumenten wachsen und eine einzelne Frage zieht immer noch ungefähr die gleiche Menge Text zurück. Das ist, was Abruf in Skala funktionieren lässt: Die Quelle kann weiter wachsen, ohne dass die Anfrage mit ihr wächst. Es ist nur so gut wie das, was es findet. Das Modell argumentiert über den Slice, den es erhält. Wenn der Abruf-Schritt das Dokument verpasst, das du brauchtest, sieht das Modell es nie. Dies bedeutet, dass wie du dein Material organisierst, wichtig ist: Dateien mit vagen Namen („notes_final_v3. pdf") sind schwerer zu oberflächlich als Dateien mit beschreibenden Namen („Q3 Rückerstattungs-Richtlinie, aktualisiert August 2024"). Verwandte Dateien zusammenzugruppieren hilft auch. Guter Abruf beginnt mit einer gut organisierten Quelle.

Konfigurationsumfang: Wer lädt den Server Der Umfang bestimmt, welche Benutzer und Projekte den Server laden. Jeder Umfang entspricht einem anderen Konfigurationsort.

Lokaler Umfang speichert die Server-Konfiguration in ~/. claude. json unter dem Pfad des aktuellen Projekts. Er gilt nur für das Projekt, an dem du gerade arbeitest, und wird nicht mit Teamkollegen geteilt. Dies ist der richtige Umfang für einen Server, der an einen spezifischen Projekt-Kontext gebunden ist, den du nicht zum Repository committen bereit bist, oder für Tooling, das nur in einem Projekt Sinn macht. Benutzer-Umfang speichert die Server-Konfiguration in deinen persönlichen Claude-Einstellungen und macht sie über alle deine Projekte verfügbar. Es ist immer noch persönlich: Teamkollegen sehen es nicht, und es wird nicht ins Repository geschrieben. Dies ist der richtige Umfang für ein persönliches Utility, das du in jedem Projekt verwendest, wie ein lokales Datenbank-Tool oder ein Skript, auf das du dich unabhängig davon verlässt, welche Codebasis du arbeitest. Projekt-Umfang schreibt die Server-Konfiguration in eine . mcp. json-Datei an der Root des Repositorys. Wenn diese Datei zur Versionskontrolle committed wird, bekommt jeder, der das Repository klont, den gleichen Server automatisch. Dies ist der richtige Umfang für einen Server, auf den das ganze Team zugreifen kann, weil die Konfiguration mit dem Code reist. Eine Sache, die man im Hinterkopf behalten sollte: Ein Projekt-Umfang-Server läuft von der Maschine jedes Teamkollegen. Für einen stdio-Server speichert die committed Konfiguration den Launch-Befehl, und jeder Klon spawnt seinen eigenen lokalen Subprocess, daher braucht jeder Teamkollege die Runtime (wie Node für einen npx-gestarteten Server) lokal installiert. Unternehmens-Umfang wird durch eine zentral verwaltete Konfiguration bereitgestellt, die von einem Administrator kontrolliert wird. Administratoren können Server an alle Benutzer in der Organisation pushen, ohne einzelne Konfigurationsschritte. Dies ist der richtige Umfang für gemeinsame interne Dienste, Sicherheits-Tooling oder jeden Server, der über die Organisation vorhanden sein muss und nicht einzelnen Developern zur Konfiguration überlassen werden kann.

Berechtigungsregeln, die ein einzelnes MCP-Tool ansprechen, nicht den ganzen Server Das Verbinden eines Servers exponiert seine volle Tool-Liste, aber du möchtest selten, dass der Agent jedes dieser Tools ohne Überprüfung erreicht. Die Berechtigungsebene aus dem Berechtigungsmodi-Abschnitt erstreckt sich auf MCP-Tools, und die Regeln können ein einzelnes Tool benennen, statt den ganzen Server.

Ein MCP-Tool wird in einer Berechtigungsregel durch seinen Server und Tool-Namen identifiziert: mcpservertool. Eine Allow-Regel auf mcpgithubcreate_issue lässt dieses eine Tool ohne Aufforderung laufen, während jedes andere Tool auf dem GitHub-Server immer noch auffordert. Eine Deny-Regel auf einem schreib-fähigen Tool blockiert es, während schreibgeschützte Tools auf dem gleichen Server verfügbar bleiben. Dies ist, wie du einen breiten Server verbindest, aber den Agent in einem engen Slice von dem, was er tun kann, hältst. Eine Deny auf einem Tool überschreibt eine Allow auf dem Server.

Der API MCP-Connector ist eine andere nützliche Kontrolle. Wenn du den Server durch den API MCP-Connector erreichst, lässt ein mcp_toolset-Objekt dich ein enabled-Flag pro Tool setzen. Dieses enabled-Flag lässt dich einen Server registrieren, aber nur die spezifischen Tools exponieren, die du das Modell sehen möchtest. Eine Berechtigungsregel entscheidet, ob ein exponiertes Tool läuft; das enabled-Flag entscheidet, ob das Modell das Tool überhaupt sieht. Der erste ist eine Governance-Kontrolle, der zweite ist eine Kontext-Kosten- und Umfang-Kontrolle. Diese Kontrollen werden oft zusammen verwendet. Überprüfe immer die genaue Regel-Syntax und den Connector-Beta-Header gegen die Dokumentation, bevor du veröffentlichst.

Der GitHub MCP-Server: Transport, Umfang und Authentifizierung in einem konkreten Beispiel Der GitHub MCP-Server ist ein Remote-Server, der von GitHub verwaltet wird und Tools für Repository-Management exponiert, einschließlich Pull-Request-Überprüfung, Öffnen von Issues, Code-Suche und mehr. Durch das Durchgehen des Verbindungsprozesses kannst du sehen, wie Transport, Umfang und Authentifizierung zusammen in einem Server funktionieren, der von jemand anderem verwaltet wird.

Der GitHub-Server verwendet HTTP-Transport, weil er remote von GitHub gehostet wird. Du registrierst ihn, indem du die Server-URL bereitstellst, und der Client verbindet sich über das Netzwerk. Für Umfang wähle Projekt-Umfang, wenn dein ganzes Team Zugriff auf die gleiche Repository-Tooling braucht, und lokalen Umfang, wenn nur du Zugriff auf den Server brauchst.

Authentifizierung für den GitHub MCP-Server verwendet ein Personal Access Token. Du generierst das Token in GitHub, dann übergibst es als Bearer-Token im Request-Header deiner MCP-Konfiguration. Das Token muss durch eine Umgebungsvariable geliefert und in der Konfigurationsdatei referenziert werden. Es darf nicht inline zu . mcp. json committed werden, weil ein Token, das direkt in eine committed Datei geschrieben wird, in Repository-Historie eintritt und nicht durch Überschreiben der Datei in einem späteren Commit entfernt werden kann.

OAuth ist ein anderer Authentifizierungs-Mechanismus, der von Servern verwendet wird, wo der Service einzelne Benutzer durch einen Browser-basierten Sign-In-Flow authentifiziert. Linear ist ein Beispiel eines Servers, der dieses Muster verwendet. Wenn du dich zum ersten Mal mit einem Linear MCP-Server verbindest, leitet der Client zu Linears Sign-In-Seite um. Nach der Genehmigung des Zugriffs wird ein Token ausgegeben und automatisch gespeichert. Keine Anmeldedaten werden von Hand kopiert oder verwaltet. OAuth ist das richtige Muster für jede Integration, wo das Autorisierungs-Modell des Service an Benutzer-Identität gebunden ist.

GitHub MCP verwendet eine Service-Anmeldedaten, die du generierst und speicherst; Linear MCP initiiert einen Sign-In-Flow, der die Anmeldedaten für dich verwaltet. Beide sind Remote-HTTP-Server, und beide folgen der gleichen Transport- und Umfang-Logik. Der Authentifizierungs-Schritt ist, was sich unterscheidet.

Die MCP-Einrichtungs-Referenz Die Tabelle unten erfasst Transport- und Umfang-Entscheidungen für jeden Bereitstellungs-Kontext.

KontextTransportUmfangKonfigurationsortGeheimnis-Handhabung

Persönliches lokales Tool (läuft nur auf deiner Maschine)stdioLokal~/. claude. json (Pro-Projekt-Eintrag)Nur Umgebungsvariablen. Niemals in Konfigurationsdatei. Gemeinsamer Team-Server (alle Teamkollegen verbinden sich mit dem gleichen Service)HTTPProjekt (. mcp. json). mcp. json committed zu Repo-RootOAuth oder Umgebungsvariablen. API-Schlüssel dürfen niemals zu . mcp. json committed werden. Persönliches Experiment (nicht bereit zu teilen)stdio oder HTTPLokalPersönliche Claude-EinstellungenNur Umgebungsvariablen. Organisations-weite Bereitstellung (Admin-verwaltet)HTTPUnternehmenVerwaltete Einstellungen (Admin-kontrolliert)Geheimnisse von Administrator verwaltet. Konfiguration gesperrt, um Override zu verhindern.

Kosten · Komplexität · Risiko Kosten: Jeder verbundene MCP-Server fügt seine Tool-Definitionen zum Context-Fenster hinzu. Je mehr Server verbunden, desto größer jede Anfrage. Lade nur die Server, die eine gegebene Aufgabe braucht. Komplexität: Transport und Umfang sind unabhängige Entscheidungen, aber sie interagieren: Ein stdio-Server kann nicht Projekt-Umfang sein zum Teilen, weil er nur auf einer Maschine läuft. Gleiche Transport zu, wo der Server läuft, bevor du Umfang wählst. Risiko: Das Committen eines API-Schlüssels in . mcp. json zur Versionskontrolle ist der häufigste Fehler in diesem Abschnitt. Der Schlüssel reist in Repository-Historie, wo Rotation später nicht ausreichend ist, um die Exposition zu entfernen. Geheimnisse gehen in Umgebungsvariablen. Die Konfigurationsdatei hält nur die Server-Adresse.

Funktioniert gutEine wiederverwendbare Integration, die du über mehrere Claude Code-Sitzungen verwenden möchtest und mit dem Team teilen möchtest, wo die Fähigkeit stabil genug ist, um als separater Prozess verwaltet zu werden. Der GitHub-Server ist ein großartiges Beispiel. Fügt Kosten oder Komplexität hinzuTeams, die Umgebungs-Geheimnisse nicht sorgfältig verwalten, sollten genau beobachtet werden. Das Hinzufügen von MCP-Servern erhöht die Anzahl der Orte, wo ein Geheimnis misshandelt werden könnte. Das Risiko konzentriert sich auf die . mcp. json-Datei, die zum Repository committed wird. Verwende einen anderen AnsatzEine einmalige Aufgabe, wo die Tool-Logik direkt in der Codebasis leben kann und nicht über Sitzungen oder Anwendungen wiederverwendet werden muss. Für eine Single-Projekt-Integration, die von einer Person verwendet wird, kann das direkte Verdrahten des Tools im API-Aufruf einfacher sein als die Verwaltung eines Servers.

Screen 13: Der API-Schlüssel, der mit der Konfigurationsdatei ins Repository reiste

Watch OutMCP-Server·4 min Der API-Schlüssel, der mit der Konfigurationsdatei ins Repository reiste

Setup Der Server funktionierte, das Team brauchte eine gemeinsame Einrichtung, und die Authentifizierungs-Methode zu bereinigen fühlte sich wie etwas an, das du nach der Übergabe tun könntest. Diese Abkürzung verwandelte einen temporären hart codierten API-Schlüssel in eine gemeinsame Anmeldedaten-Exposition in dem Moment, in dem die Konfigurationsdatei committed wurde.

Was passierte Ein Developer verbindete sich mit einem Data-Warehouse MCP-Server mit einem Service-Account API-Schlüssel. Um den Server schnell während der Einrichtung zum Laufen zu bringen, wurde der Schlüssel direkt in die . mcp. json-Konfigurationsdatei platziert. Der Plan war, ihn vor dem Teilen der Einrichtung mit dem Team zu einer Umgebungsvariable zu verschieben.

Der Developer committed die . mcp. json zum Projekt-Repository, damit Teamkollegen sich mit dem gleichen Server verbinden könnten, indem sie das Repo klonten, und der Schlüssel committed mit. Innerhalb von 48 Stunden hatten drei Teamkollegen das Repository geklont, und eine CI-Pipeline hatte einen frischen Klon ausgelöst. Der Schlüssel war jetzt an vier Orten: der lokalen Maschine, der Repository-Historie, den drei Teamkollege-Maschinen und dem CI-Runner-Dateisystem.

Nach der Realisierung verschiebte der Developer den Schlüssel zu einer Umgebungsvariable, aktualisierte die . mcp. json und committed die korrigierte Datei. Aber der Schlüssel war immer noch in der Commit-Historie, und der Service-Account musste rotiert werden. Die Rotation brach zwei externe Dienste, die mit dem gleichen Schlüssel konfiguriert worden waren, und dies brauchte drei Stunden Arbeit, um zu beheben.

Die korrigierte . mcp. json verwendet eine Umgebungsvariablen-Referenz statt eines Inline-Wertes: Vorher (nicht verwenden) { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer sk-abc123... " ............. inline Anmeldedaten } } Nachher (korrekt) { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}" ............ Umgebungsvariablen-Referenz } }

Was du beachten solltest API-Schlüssel, die zu einer Konfigurationsdatei committed werden, werden zur Repository-Historie committed. Das Überschreiben der Datei in einem späteren Commit entfernt den Schlüssel nicht aus der Historie; es entfernt ihn nur aus der aktuellen Version. Jede Anmeldedaten, die inline zu einer committed Datei geschrieben wird, muss als kompromittiert behandelt und rotiert werden. Das richtige Muster ist, den Wert in eine Umgebungsvariable zu setzen und die Variable in der Konfigurationsdatei zu referenzieren.

Um zu verhindern, dass der Agent Anmeldedaten-Werte direkt zu committed Dateien schreibt, verwende zwei Ebenen. Erstens, füge eine Konventions-Anweisung zu CLAUDE. md hinzu, die besagt, dass Anmeldedaten-Werte niemals inline zu . mcp. json geschrieben werden dürfen. Dies signalisiert die Regel dem Modell während jeder Sitzung. Zweitens, unterstütze diese Anweisung mit einem PreToolUse-Hook, der Schreib- und Bearbeitungs-Operationen gegen . mcp. json auf Muster inspiziert, die wie Inline-Anmeldedaten-Werte aussehen, und mit Code beendet, um die Operation zu blockieren, wenn einer erkannt wird. Die CLAUDE. md-Anweisung kommuniziert die Absicht; der Hook erzwingt sie deterministisch, unabhängig davon, was das Modell entscheidet zu tun. Dies ist die gleiche Hook-versus-Anweisung-Unterscheidung, die im Abschnitt Dauerhafter Projektkontext behandelt wird: Eine Anweisung in CLAUDE. md kann inkonsistent befolgt werden, wenn die Datei wächst oder der Kontext sich verschiebt, und ein Hook feuert bei jedem relevanten Tool-Aufruf ohne Ausnahme.

Screen 14: Checkpoint 5: Gleiche Transport und Umfang zu jedem Bereitstellungs-Szenario

CheckpointMCP-Server·4 min Checkpoint 5: Gleiche Transport und Umfang zu jedem Bereitstellungs-Szenario Versuche es jetzt. Für jedes Bereitstellungs-Szenario unten, wähle den richtigen Transport und Umfang. Beschriftete Konfigurationsschnipsel werden bereitgestellt. Ein lokales SQLite-Abfrage-Tool, das du nur auf deiner Entwicklungs-Maschine verwendest. HTTP + Projekt (. mcp. json)HTTP + Unternehmens (verwaltete Einstellungen)stdio + Lokalstdio oder HTTP + LocalEin Code-Such-Service, der auf deiner Unternehmens-Infrastruktur gehostet wird, auf den das ganze Engineering-Team zugreifen sollte. HTTP + Projekt (. mcp. json)HTTP + Unternehmens (verwaltete Einstellungen)stdio + Lokalstdio oder HTTP + LocalEin experimenteller Web-Scraping-Server, den du diese Woche gegen ein spezifisches Repository testest, nicht bereit zu teilen. HTTP + Projekt (. mcp. json)HTTP + Unternehmens (verwaltete Einstellungen)stdio + Lokalstdio oder HTTP + LocalEin Sicherheits-Scanning-Server, den deine Organisations-IT-Team auf der Installation von jedem Developers Claude Code bereitstellen muss. HTTP + Projekt (. mcp. json)HTTP + Unternehmens (verwaltete Einstellungen)stdio + Lokalstdio oder HTTP + Local

Absenden Jetzt überspringen

Screen 15: Claude mit Unternehmenssystemen verbinden und es sicher authentifizieren

TeachingUnternehmens-Integration·18 min Claude mit Unternehmenssystemen verbinden und es sicher authentifizieren Früher hat das Modul behandelt, wie man einen MCP-Server baut und seinen Transport und Umfang konfiguriert. Für einen Server, der nur von deinem Team auf einem internen Projekt verwendet wird, deckt das GitHub-Personal-Access-Token-Beispiel das Authentifizierungs-Muster ab.

Dieser Abschnitt behandelt, was sich ändert, wenn die Integration in einer regulierten Umgebung funktionieren muss: Die Identitäts-, Geheimnis-Handhabungs- und Daten-Residenz-Fragen, die ein Prototyp normalerweise ignoriert, werden zu Anforderungen, die in der Produktions-Bereitstellung beantwortet werden müssen.

Warum Unternehmens-Integration anders ist als ein funktionierender Prototyp Ein Prototyp, der Claude mit einem internen Service verbindet, beantwortet eine Frage: Funktioniert die Verbindung? Eine Produktions-Unternehmens-Integration muss mehrere zusätzliche Fragen beantworten: Wer handelt das Modell als, und ist diese Identität überprüfbar? Welche Daten kann es zugreifen, und wo verlässt dieses Daten die Organisation? Kann ein Administrator die Konfiguration sperren, damit kein einzelner Developer die Authentifizierungs-Einrichtung ändern kann? Kann der Zugriff auf eine Weise protokolliert werden, die eine Compliance-Überprüfung erfüllt?

Diese Fragen sind nicht neu für Unternehmens-Software; sie haben die gleichen Identitäts-, Zugriffs- und Compliance-Anforderungen, die auf jeden externen System gelten, das regulierte Daten berührt. Sie als Teil des Integrations-Designs zu behandeln ist, was einen Demo von etwas Bereitstellungs-Bereitem unterscheidet.

Authentifizierungs-Muster nach Service-Typ Der richtige Authentifizierungs-Mechanismus hängt davon ab, wo der Service läuft und welches Identitäts-Modell er unterstützt. Wähle jeden Tab aus, um das Muster und wann man es verwendet zu sehen.

Remote-Services mit Benutzer-Identität Remote-Services mit Service-Identität Lokale Services mit Dateisystem-Zugriff

Verwende OAuth. Der MCP-Server gibt einen 401 Unauthorized zurück, um zu signalisieren, dass Authentifizierung erforderlich ist. Der Client initiiert einen Browser-basierten Sign-In-Flow. Nach der Genehmigung des Zugriffs durch den Benutzer wird ein Token ausgegeben und gespeichert. Niemand kopiert ein Geheimnis von Hand; der OAuth-Flow ist das erwartete Muster für Cloud-Services, SaaS-Tools und jede Integration, wo die Benutzer-Identität Teil des Autorisierungs-Modells ist. Der Linear MCP-Server von früher in diesem Modul verwendet dieses Muster; der GitHub-Server authentifiziert sich stattdessen mit einem Personal Access Token, der als Header übergeben wird.

Verwende einen API-Schlüssel, der durch eine Umgebungsvariable übergeben wird. Der Schlüssel identifiziert den Service-Account. Der Schlüssel darf niemals zu einer Konfigurationsdatei committed werden; er lebt in der Umgebung am Punkt der Ausführung. Für eine CI-Pipeline, die das Agent SDK verwendet, wird der Schlüssel als Geheimnis vom Pipeline-Runner injiziert, nicht in den Code gebacken.

stdio-Transport mit keiner Netzwerk-Authentifizierung. Die Sicherheits-Grenze ist das Dateisystem-Berechtigungs-Modell. Eine Deny-Regel in den Einstellungsdateien ist die Governance-Ebene.

Die Verwaltung des Geheimnisses selbst ist die andere Hälfte der sicheren Authentifizierung. Eine Anmeldedaten reist niemals mit der Konfiguration, die sie referenziert: Die Config-Datei hält nur eine Variablen-Referenz, und der Wert lebt in einer Umgebungsvariable oder einem verwalteten Geheimnis-Store, der am Punkt der Ausführung injiziert wird. Speichere Service-Account-Schlüssel in einem Geheimnis-Manager, statt in Dateien, und rotiere sie nach einem Zeitplan und sofort nach jeder vermuteten Exposition. Wenn ein Schlüssel leckt, musst du ihn rotieren, aber denke daran, du kannst einen Wert, der in committed Code gebacken ist, nicht rotieren. Umfang jede Anmeldedaten auf den engsten Zugriff, den ihre Aufgabe braucht, daher erreicht ein kompromittierter Schlüssel nur das, was diese eine Integration brauchte.

Die Verwaltung des Geheimnisses nach Authentifizierung: Speicherung, Rotation und Trennung von Config Die Wahl des richtigen Authentifizierungs-Musters etabliert die Verbindung, aber sie zu halten ist ein separates Problem. Das MCP-Schlüssel-Leck, das früher erwähnt wurde, war nicht eine schlechte Wahl der Auth-Methode, es war eine Anmeldedaten, die am falschen Ort lebte und nicht bereinigt werden konnte, sobald sie sich ausbreitete. Drei Praktiken halten das davon ab zu passieren, und jede adressiert eine spezifische Weise, wie eine Anmeldedaten exponiert wird.

Die erste Praktik ist Trennung: Eine Anmeldedaten reist niemals mit der Konfiguration, die sie referenziert. Die Konfigurationsdatei hält eine Variablen-Referenz, und der Wert lebt irgendwo, wo die Datei nicht ist. Dies ist die Regel, die das Leck-Fehler brach. Der Grund, warum es wichtig ist, ist mechanisch: Konfigurationsdateien werden committed, geteilt und geklont. Ein Wert, der inline geschrieben wird, reist mit jedem dieser Kopien, und ein committed Wert tritt in Repository-Historie auf eine Weise ein, die Überschreiben nicht entfernt. Wenn du den Wert aus der Datei hältst, bleibt die Datei sicher zu teilen.

Die zweite Praktik ist, wo der Wert geht, sobald er aus der Datei ist. Für einen Wert, der nur auf einer Maschine oder in einem Pipeline-Lauf lebt, ist eine Umgebungsvariable, die am Punkt der Ausführung injiziert wird, genug: Der CI-Runner setzt ihn als Geheimnis, die Konfiguration liest ihn nach Name, und nichts wird auf die Festplatte geschrieben. Für einen Wert, den mehrere Services oder Personen brauchen, ist ein Geheimnis-Store besser. Ein Geheimnis-Store ist ein verwalteter Service, der Anmeldedaten hält, sie zu autorisierten Anrufern zur Laufzeit zurückgibt und aufzeichnet, wer was gelesen hat. Es zentralisiert den Wert, daher aktualisiert eine einzelne Rotation jeden Consumer auf einmal, und es entfernt die Kopien, die sich ansammeln, wenn jeder Service seine eigene Anmeldedaten in seiner eigenen Datei hält. Erreiche eine Umgebungsvariable, wenn das Geheimnis lokal und kurzlebig ist, und ein Geheimnis-Store, wenn das Geheimnis geteilt oder überprüft werden muss.

Die dritte Praktik ist Rotation: Eine Anmeldedaten mit einer neuen auf einem Zeitplan und sofort nach jeder vermuteten Exposition ersetzen. Rotation ist die einzige angemessene Antwort auf einen geleakten Schlüssel, weil ein Schlüssel, der exponiert wurde, nicht wieder geheim gemacht werden kann. Du musst einen neuen ausgeben. Dies ist, warum das Inline-Anmeldedaten-Muster so kostspielig ist: Ein Wert, der in committed Code gebacken ist, kann nicht sauber rotiert werden, da der alte Wert in der Historie bleibt und jeder Consumer, der hart darauf codiert ist, bei Änderung bricht. Eine Anmeldedaten, die aus einem Geheimnis-Store oder einer Umgebungsvariable gelesen wird, rotiert, ohne den Code zu berühren, der sie verwendet, weil der Code die Anmeldedaten nach Name referenziert und der Name nicht ändert, wenn der Wert dahinter es tut.

Zwei Gewohnheiten können Rotation billiger machen: Umfang jede Anmeldedaten auf den engsten Zugriff, den ihre Aufgabe braucht, daher erreicht ein Schlüssel, der leckt, nur das, was diese Integration brauchte. Halte einen Datensatz, welche Services jede Anmeldedaten verwenden, daher ist eine Rotation nicht oberflächlich ihre Consumer.

Das Leck-Fehler, das früher in dem Modul identifiziert wurde, identifizierte den Fehler: Eine Anmeldedaten, die inline zu einer committed Datei geschrieben wurde. Um dies davon abzuhalten zu passieren, wende diese drei Praktiken an: Trennung hält den Wert aus der Datei, ein Geheimnis-Store oder eine Umgebungsvariable gibt dem Wert ein Zuhause, das die Datei nicht teilt, und Rotation kann mit Wiederherstellung nur helfen, wenn die ersten zwei gehalten werden.

Was regulierte Industrien auf funktionierende Authentifizierung aufbauen Ein Finanzdienstleistungs- oder Gesundheitswesen-Kunde fragt mehr Fragen als „funktioniert Authentifizierung? " Sie fragen, wo Daten verarbeitet werden, wie Zugriff protokolliert wird, und ob ein Administrator die Konfiguration sperren kann, damit ein Developer die Auth-Einrichtung während eines Audit-Fensters nicht ändern kann.

Die verwaltete Unternehmens-Konfiguration aus früheren Abschnitten beantwortet die letzte Frage: Eine von einem Administrator bereitgestellte Server-Konfiguration, die nicht von einzelnen Benutzern überschrieben werden kann, bedeutet, dass die Auth-Einrichtung über die Organisation konsistent ist und nicht davon abhängt, dass jedes Developers Einstellungsdatei korrekt ist.

Audit-Hooks beantworten die Protokollierungs-Frage: Ein PostToolUse-Hook, der jeden Tool-Aufruf und seine Parameter zu einem Audit-Store protokolliert, bietet den Datensatz, den eine Compliance-Überprüfung braucht. Der Hook feuert deterministisch für jeden Aufruf, unabhängig davon, was das Modell entscheidet, und das Protokoll ist nicht etwas, das das Modell überspringen kann.

Daten-Residenz beantwortet die Verarbeitungs-Frage: Ein Server, der mit einem HTTP-Endpunkt in einer spezifischen Region konfiguriert ist, kombiniert mit einer Plattform-Bereitstellung, die Verarbeitung an diese Region pinnt, gibt einem Compliance-Reviewer eine überprüfbare Antwort zu, wo Daten gehen. Dies ist, warum die Infrastruktur-Anforderung und die Plattform-Wahl von früher in dem Modul bei Audit-Zeit wichtig sind, nicht nur bei Build-Zeit.

Code-Modernisierung: Anwendung des ganzen Moduls auf Legacy-Änderung Code-Modernisierung ist ein nützlicher Test-Fall für alles, das dieses Modul behandelt, weil es sich auf die Risiken konzentriert, die jedes Tool entworfen wurde, zu verwalten. Großflächige Änderungen an einer unbekannten Legacy-Codebasis tragen hohes Blast-Radius, unvorhersehbare Abhängigkeiten und begrenzte Reversibilität. Die Tools aus diesem Modul adressieren jedes dieser Risiken direkt, wenn du sie vor der Arbeit anwendest. Die Explore-, Plan- und Code-Schleife ist der Kern-Workflow für diese Art von Arbeit. Der Plan-Modus hält den Agent in der schreibgeschützten Explorationsphase, während du Vertrauen in seine Änderungen aufbaust. Du kannst die vorgeschlagenen Änderungen überprüfen, alles identifizieren, das Pfade berührt, die du nicht erwartet hast, und zurückdrängen, bevor eine einzelne Datei geändert wird. Hooks erzwingen Guardrails, die Änderungen an spezifischen Pfaden während der empfindlichsten Phasen verhindern. CLAUDE. md trägt die Konventionen für die neuen Ziel-Muster, daher wendet der Agent sie konsistent über den ganzen Umfang von Änderungen an, statt zu den Legacy-Mustern zurückzudriften, die er im umgebenden Code liest.

Ein verantwortungsvoller Scoping-Ansatz für hochriskante Arbeit adressiert drei Fragen, bevor die Sitzung startet.

Was ist das Blast-Radius, wenn etwas schief geht: Welche Systeme hängen vom Code ab, der geändert wird, und was bricht nachgelagert, wenn eine Änderung falsch ist? Wie werden Änderungen überprüft: Gibt es einen PostToolUse-Hook, der jeden Tool-Aufruf protokolliert, und erfüllt dieses Protokoll, wer die Arbeit überprüfen muss? Wer genehmigt jede Phase, bevor die nächste beginnt? Der Plan-Modus erzwingt die Grenze zwischen Exploration und Ausführung, aber die Genehmigungsentscheidung selbst ist deine, um zu definieren und zu dokumentieren, bevor die Arbeit beginnt.

Diese Fragen sind nicht spezifisch für Modernisierungs-Arbeit. Sie gelten für jede hochriskante agentic Aufgabe. Code-Modernisierung zeigt sie klar, weil der Umfang groß ist, die Codebasis unbekannt ist, und die Kosten, es falsch zu machen, hoch sind.

Die Authentifizierungs- und Integrations-Checkliste Die Tabelle unten benennt die Schlüssel-Entscheidungen für jeden Service-Typ.

Service-TypAuth-MethodeWo Geheimnisse lebenWas wird protokolliert Wer kann die Config sperren

Remote mit Benutzer-Identität (SaaS, Cloud)OAuthToken, das von OAuth-Provider ausgegeben und vom Client gespeichert wird. PostToolUse-Hook zu Audit-Log. Administrator über verwaltete Unternehmens-Einstellungen. Remote mit Service-Identität (interne API)API-Schlüssel in Umgebungsvariable Nur Umgebung. Niemals in committed Config. PostToolUse-Hook zu Audit-Log. Administrator über verwaltete Unternehmens-Einstellungen. Lokal (Dateisystem, lokale DB)Dateisystem-BerechtigungenKein Geheimnis benötigt. Deny-Regeln erzwingen Pfad-Zugriff. PostToolUse-Hook zu Audit-Log. Deny-Regeln in verwalteten Unternehmens-Einstellungen.

Kosten · Komplexität · Risiko Kosten: OAuth-Flows fügen einen einmaligen Einrichtungs-Schritt pro Benutzer pro Service hinzu. API-Schlüssel-Verwaltung erfordert einen Geheimnis-Rotations-Prozess, und Audit-Protokollierung durch PostToolUse-Hooks fügt einen kleinen Overhead zu jedem Tool-Aufruf hinzu. Komplexität: Regulierte Umgebungen fügen Anforderungen hinzu, die nicht in einem Prototyp auftauchen. Sie während des Scoping zu identifizieren ist die Disziplin, die Integrationen im Zeitplan hält. Risiko: Das Risiko konzentriert sich, wenn ein Prototyp zur Produktion geht. Ein System, das hart codierte Anmeldedaten verwendet, kein Audit-Log hat und nicht zentral gesperrt werden kann, wird eine regulierte Kundenüberprüfung nicht bestehen. Die Behebungen sind nicht hart, aber sie erfordern Aufmerksamkeit, bevor die Überprüfung.

Funktioniert gutJede Integration, die Daten berührt, die ein regulierter Kunde sich kümmert, wo die gleiche Tooling bereits Unternehmens-verwaltete Einstellungen und Audit-Hooks unterstützt. Das Scoping der Sicherheits-Anforderungen upfront fügt wenig Overhead hinzu und verhindert, dass die Integration bei der finalen Überprüfung steckenbleibt. Fügt Kosten oder Komplexität hinzuTeams, die nicht mit OAuth-Flows oder Unternehmens-Geheimnis-Verwaltung vertraut sind. Diese Muster erfordern Koordination mit Sicherheits- oder IT-Teams in den meisten regulierten Organisationen, und der Zeitplan muss das berücksichtigen. Verwende einen anderen AnsatzEin Prototyp oder Proof of Concept, der niemals Produktions-Daten sieht. Die volle Unternehmens-Integrations-Checkliste ist nicht für eine Demo-only-Integration gerechtfertigt, aber die Umgebungsvariablen-Gewohnheit für Geheimnisse kostet nichts und ist gute Praktik.

Screen 16: Die OAuth-Verbindung, die im Staging funktionierte und in der Produktion fehlschlug

Watch OutUnternehmens-Integration·3 min Die OAuth-Verbindung, die im Staging funktionierte und in der Produktion fehlschlug

Setup Die OAuth-Verbindung funktionierte End-to-End im Staging, daher fühlte sich der Umzug zur Produktion wie ein routinemäßiger Cutover an. Was das Team verpasste, war, dass OAuth-Redirect-URIs pro Host registriert werden und oft pro Umgebung kontrolliert werden, daher bedeutete Erfolg im Staging nicht, dass der Produktions-Host autorisiert war, den Sign-In-Flow zu vervollständigen.

Das Gespräch, das den fehlenden Schritt oberflächlich machte Der folgende Austausch fand in einer Post-Deployment-Überprüfung statt, nachdem die MCP-Integration in der Produktion fehlschlug. Die Integration hatte alle Staging-Tests bestanden. Sicherheits-Reviewer: „Jeder Produktions-Sign-In-Versuch durch die MCP-Verbindung schlägt fehl. Der Fehler ist ein Redirect-URI-Mismatch. Wo wurde die OAuth-App registriert? "

Developer: „Ich registrierte sie für staging. mycompany. com während der Entwicklung. Wir zogen letzte Woche zur Produktion. Die Verbindung funktionierte überall im Staging. "

Sicherheits-Reviewer: „Das ist das Problem. Der OAuth-Provider akzeptiert nur Redirect-URIs, die du explizit registriert hast, und production. mycompany. com ist nicht auf der Allow-Liste. Jeder Sign-In-Versuch trifft die Überprüfung, schlägt den URI-Abgleich fehl und loopt zurück zum Sign-In-Bildschirm. "

Developer: „Also muss ich nur den Produktions-URI zur App-Registrierung hinzufügen? "

Sicherheits-Reviewer: „Ja, und bevor du es tust, überprüfe, ob deine Staging-App-Registrierung eine separate App von der Produktion sein sollte. Die meisten Unternehmens-Kunden erfordern separate OAuth-App-Registrierungen für jede Umgebung als Teil ihrer Sicherheits-Richtlinie, daher ist die Verwendung der gleichen App-Registrierung über Umgebungen hinweg das zweite Problem, das ich kennzeichnen würde. " Der Developer hatte den OAuth-Flow End-to-End im Staging getestet und bestätigt, dass er funktionierte, was bedeutet, dass der Produktions-Fehler kein Code-Defekt war. Stattdessen war es ein Konfigurationsschritt, der pro Host und pro Umgebung anwendbar ist, und der Developer wusste nicht, ihn für die Produktion zu tun.

Was du beachten solltest OAuth-Redirect-URIs werden pro Host registriert, daher bedeutet eine funktionierende Staging-OAuth-Verbindung nicht, dass die Produktions-Verbindung konfiguriert ist. Bevor du eine OAuth-authentifizierte MCP-Integration in eine neue Umgebung verschiebst, füge den neuen Host-Redirect-URI zur OAuth-App-Registrierung hinzu. Für regulierte Unternehmens-Kunden, überprüfe, ob separate OAuth-App-Registrierungen für Staging und Produktion erforderlich sind. Enthalte den Registrierungs-Schritt in der Bereitstellungs-Checkliste, daher wird er nicht beim ersten Produktions-Sign-In-Versuch entdeckt.

Screen 17: Checkpoint 6: Diagnostiziere den Authentifizierungs-Fehler aus einer Spur

CheckpointUnternehmens-Integration·3 min Checkpoint 6: Diagnostiziere den Authentifizierungs-Fehler aus einer Spur Versuche es jetzt: Lese die Verbindungs-Spur unten.

Benenne den Authentifizierungs-Fehler-Mechanismus, dann wähle die richtige gezielte Behebung aus drei Optionen. Verbindungs-Spur [MCP Client] Connecting to https://data-api. internal/mcp ... [MCP Client] GET /auth/token, 401 Unauthorized [MCP Client] Reading credential from: /home/jenkins/. config/mcp-credentials. json [MCP Client] Credential value: WAREHOUSE_TOKEN= sk-**[redacted] [MCP Client] Retrying with credential, 401 Unauthorized [MCP Client] Connection failed after 3 attempts ABehebung A: Rotiere den API-Schlüssel und aktualisiere /home/jenkins/. config/mcp-credentials. json mit dem neuen Wert. BBehebung B: Rotiere den abgelehnten Schlüssel, dann verschiebe die Anmeldedaten aus der Datei und injiziere sie als Umgebungsvariable in der CI-Pipeline-Runner-Konfiguration. Aktualisiere die MCP-Konfiguration, um die Variable zu referenzieren. CBehebung C: Wechsle von API-Schlüssel-Authentifizierung zu OAuth für diesen Service.

Absenden Jetzt überspringen

Screen 18: Kumulative Integrations-Aufgabe: Checkpoint

CumulativeCumulative Integration Task·6 min Kumulative Integrations-Aufgabe: Checkpoint Die Integration unten hat drei Bugs, die über die Ebenen dieses Moduls verteilt sind: einen in der Claude Code-Konfigurationsebene, einen in der Plugin- oder Verpackungsebene und einen in der MCP- oder Authentifizierungs-Ebene.

Für jede Datei: Identifiziere den Bug und schreibe einen Satz, der beschreibt, was er tut oder nicht tut zur Laufzeit.

Datei 1: . claude/settings. json { "permissions": { "defaultMode": "bypassPermissions", "deny": ["Read(. env. production)"] } }

Datei 2: . claude/skills/migration-validate/SKILL. md --- name: migration-validate description: Validates migration scripts before they run against production. ---

Steps

Run: /Users/priya/scripts/validate-migration. sh
Report validation results.

Datei 3: . mcp. json { "mcpServers": { "data-warehouse": { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer sk-prod-warehouse-abc123" } } } }

Modell-Antwort anzeigen Jetzt überspringen

Modell-Antwort Datei 1 (settings. json): defaultMode ist bypassPermissions; entfernt jeden Bestätigungsprompt auf einer Produktions-Workstation, einschließlich für destruktive Operationen. Die Deny-Regel für . env. production ist korrekt; nur der Modus ist falsch. Datei 2 (SKILL. md): Schritt 1 verwendet einen absoluten Pfad /Users/priya/scripts/validate-migration. sh; dieser Pfad existiert nur auf der Maschine des Autors und wird auf keiner Teamkollege-Maschine auflösen, nachdem sie das Projekt klonen. Datei 3 (. mcp. json): Der API-Schlüssel sk-prod-warehouse-abc123 ist inline in dem Authorization-Header committed; er tritt in Repository-Historie ein, wo er nicht durch Überschreiben der Datei in einem späteren Commit entfernt werden kann, und muss als kompromittiert behandelt werden.

Wie viele hast du erfasst?

Alle drei korrekt Verpasst den API-Schlüssel (Bug 3) Zwei von drei korrekt Eins von drei korrekt

Screen 19: Kumulative Integrations-Aufgabe: Zusammenbau

CumulativeCumulative Integration Task·6 min Kumulative Integrations-Aufgabe: Zusammenbau Jetzt schreibe die korrigierte Version aller drei Dateien.

Produziere den kompletten korrigierten Inhalt für settings. json, SKILL. md und . mcp. json.

Modell-Antwort anzeigen Jetzt überspringen

Modell-Antwort Datei 1: settings. json (korrigiert) { "permissions": { "defaultMode": "acceptEdits", "deny": ["Read(. env. production)"] } } Datei 2: SKILL. md (korrigiert) --- name: migration-validate description: Validates migration scripts before they run against production. ---

Steps

Run: $CLAUDE_PROJECT_DIR/scripts/validate-migration. sh
Report validation results.

Datei 3: . mcp. json (korrigiert) { "mcpServers": { "data-warehouse": { "type": "http", "url": "https://warehouse. internal/mcp", "headers": { "Authorization": "Bearer ${WAREHOUSE_MCP_TOKEN}" } } } } settings. json setzt defaultMode auf acceptEdits in Berechtigungen; genehmigt automatisch Dateiänderungen und häufige Dateisystembefehle, aber gated destruktive Shell-Befehle, der richtige Kompromiss für eine Produktions-Migrations-Workstation. Der Skill verwendet $CLAUDE_PROJECT_DIR, daher löst der Pfad vom Projekt-Root auf jeder Maschine nach dem Klonen auf. Die MCP-Konfiguration referenziert die Anmeldedaten als Umgebungsvariable, daher wird sie niemals zur Repository-Historie committed.

Wie verglich sich dein Zusammenbau?

Korrekter Zusammenbau Fehlende Berechtigungs-Behebung Fehlende Pfad-Behebung Fehlende Geheimnis-Behebung

Screen 20: Sieben Schlüssel-Takeaways

RecapSchlüssel-Takeaways·6 min Sieben Schlüssel-Takeaways Ein Takeaway pro Abschnitt, das das Modul zusammenbindet.

1 Berechtigungsmodus ist eine Risiko-Entscheidung, nicht eine Geschwindigkeits-Entscheidung. Claude Code gibt dir Modi, die von Prompt-vor-allem bis Prompt-für-nichts reichen. Der Berechtigungsmodus sollte das Risiko-Profil der Arbeit und Umgebung abgleichen, nicht die Vorliebe für weniger Prompts. Ein Bypass-Modus auf einer Entwickler-Workstation gegen eine Live-Codebasis entfernt jeden Checkpoint zwischen dem Agent und deinen Dateien. Eine Deny-Regel auf dem Pfad, der nicht berührt werden darf, gesetzt auf Projekt- oder Unternehmensebene, deckt die Lücke, die ein Modus allein nicht tut.

2 Eine KI-Code-Überprüfung gibt dir einen Satz von Erkenntnissen zu triage, nicht ein Urteil zum Anwenden. Vertraue den Erkenntnissen, die der Reviewer aus dem Diff vor sich beweisen kann, wie ein fehlender Null-Check oder eine nicht geschlossene Ressource, und bestätige sie auf den Zeilen, die es zitiert. Behandle jeden Anspruch über Laufzeit-Verhalten oder ein anderes System als eine Hypothese zu testen, weil der Reviewer diesen Anspruch ohne den Beweis machte, der ihn beweisen würde. Platziere das menschliche Gate am Punkt, wo ein Erkenntnisse zu einer Aktion wird, die schwer rückgängig zu machen ist, und erhöhe die Reviewer-Genauigkeit, indem du ihm die Konventionen gibst, die es sonst raten müsste.

3 Ein Skill ist tragbar, aber „läuft überall" ist etwas, das du entwirfst. Die gleiche SKILL. md kann in Claude Code, auf der Messages API und durch das Agent SDK laufen, aber jede lädt und sandboxed es anders: Dateisystem-Entdeckung in Claude Code, Beta-Header und ein Code-Ausführungs-Container auf der API, und settingSources auf dem SDK. Ein Skill, der auf eine klare Beschreibung beschränkt ist und frei von lokalen Umgebungsannahmen ist, portiert sauber; einer, der das Terminal, in dem er geschrieben wurde, annimmt, nicht. In jeder Runtime starten Subagenten sauber: Sie laden Skills nicht automatisch vor.

4 Dauerhafter Kontext erfordert den richtigen Mechanismus für jede Besorgnis. CLAUDE. md ist das Sitzungs-persistente Projektgedächtnis, aber es verdünnt sich mit Größe. Rules-Dateien scopen Anleitung zu, wo sie anwendbar ist. Hooks erzwingen Guardrails deterministisch, nicht probabilistisch. Subagenten halten Explorationsarbeit aus dem Hauptkontext. Diese vier Mechanismen lösen jedes ein anderes Problem, daher erzwingt das Zwingen aller in CLAUDE. md eine einzelne Datei, die schwerer zu verwalten und leichter zu ignorieren ist.

5 Eine teilbare Einrichtung erfordert tragbare Komponenten. Ein Plugin, das einen absoluten Pfad zum Home-Verzeichnis des Autors referenziert, installiert sich auf einer Maschine und schlägt auf allen anderen fehl. Skills, Hooks und Plugin-Komponenten, die geteilt werden, müssen Pfade relativ zum Projekt-Root referenzieren, und jede Umgebungsvariablen-Anforderung muss dokumentiert oder zur Installationszeit validiert werden. Teste die Installation auf einer sauberen Maschine vor der Verteilung.

6 Transport und Umfang sind unabhängige Entscheidungen mit abhängigen Konsequenzen. stdio ist für Server, die auf deiner Maschine laufen. HTTP ist für alles, das remote gehostet oder von mehreren Developern zugegriffen wird. Lokaler Umfang hält einen Server persönlich; Projekt-Umfang teilt ihn mit dem Repo über . mcp. json. Die Kombination muss die Bereitstellungs-Absicht abgleichen: Ein gemeinsamer Team-Server erfordert HTTP-Transport und Projekt- oder Unternehmens-Umfang. Ein stdio-Server in . mcp. json ist eine Konfiguration, die teilbar aussieht, aber nicht ist.

7 Unternehmens-Integration erfordert die Identifizierung der Sicherheits-Anforderungen vor der Bereitstellung. Ein regulierter Kunde fragt über Identität, Daten-Residenz, Zugriffs-Protokollierung und Konfigurationssteuerung. Die Antworten kommen von OAuth für Benutzer-Identitäts-Services, Umgebungsvariablen für Service-Anmeldedaten, PostToolUse-Hooks für Audit-Protokollierung und verwaltete Unternehmens-Einstellungen für Konfigurationslock. Keine davon ist hart zu implementieren, aber alle sind hart, nach einer Produktions-Bereitstellung, die eine Sicherheits-Überprüfung fehlgeschlagen hat, zu retrofit.

Was kommt als nächstes Modul 4 behandelt Produktions-Engineering, Evaluationen und Sicherheit: Wie man misst, ob deine Claude Code-Integrationen bei Skala korrekt funktionieren, wie man Eval-Harnesses baut und wie man Produktions-Grad-Sicherheits-Guardrails entwirfst. Die Berechtigungsmodi, Hooks und Authentifizierungs-Muster aus diesem Modul sind die Grundlage, die diese Evaluationen testen.

Quellen

Claude 101 (Skilljar) Claude Code 101 In Action (Skilljar) Building with the Claude API (Skilljar) code. claude. com platform. claude. com docs. claude. com

Du kannst jetzt Claude Code sicher ausführen, es als Team-Asset teilen und es mit echten Systemen verbinden. Von Berechtigungsmodi bis Unternehmens-Authentifizierung hältst du jetzt die Konfigurationsent scheidungen, die eine Integration lange nach dem Verlassen deiner Maschine funktionieren lassen.

Screen 21: Schlüsselbegriffe aus diesem Modul

GlossarSchlüsselbegriffe·3 min Schlüsselbegriffe aus diesem Modul Alphabetisch. Klicke auf einen Begriff, um seine Definition zu erweitern.

Claude Agent SDKEine programmierbare Schnittstelle, die die gleiche Agent-Schleife exponiert, die Claude Code im Terminal läuft. Sie ermöglicht Developern, die Schleife aus Code aufzurufen, den Berechtigungsmodus und verfügbare Tools zu setzen und Aufgaben ohne eine interaktive Sitzung auszuführen. Das gleiche Berechtigungs-Modell und Deny-Regeln, die im Terminal anwendbar sind, gelten im SDK. CLAUDE. mdEine Markdown-Datei, die an der Root eines Claude Code-Projekts platziert ist. Ihr Inhalt wird dem Context-Fenster am Anfang jeder Sitzung vorangestellt. Sie hält die universellen Projekt-Einschränkungen, Konventionen und Befehle, die bedingungslos über alle Sitzungen anwendbar sein sollten. Dateien, die über ungefähr 200-300 Zeilen wachsen, riskieren, kritische Regeln durch Inhalts-Gewicht zu verdünnen. HookEin Befehl, der an ein Lebenszyklusereignis in Claudes Code-Ausführung gebunden ist (PreToolUse, PostToolUse, UserPromptSubmit, Stop). Anders als Anweisungen in CLAUDE. md läuft Hooks deterministisch beim konfigurierten Ereignis, unabhängig davon, was das Modell entscheidet. Ein PreToolUse-Hook kann mit Code 2 beenden, um einen Tool-Aufruf zu blockieren, bevor er läuft. MCP (Model Context Protocol)Eine offene Kommunikationsebene, die einem MCP-Client wie Claude Code erlaubt, sich mit einem MCP-Server zu verbinden, der Tools, Ressourcen und Prompts exponiert. Das Protokoll definiert, wie der Client die Tools des Servers entdeckt und aufgerufen. Die Verwendung von MCP verschiebt Tool-Definition und Wartung aus einzelnem Anwendungs-Code und in einen wiederverwendbaren Server, den jeder MCP-Client anhängen kann. MCP-TransportDer Kommunikationskanal zwischen einem MCP-Client und einem MCP-Server. stdio läuft den Server als lokalen Subprocess auf der gleichen Maschine wie der Client. HTTP verbindet sich mit einem remote gehosteten Server über ein Netzwerk. Die Wahl des Transports bestimmt, wo der Server laufen kann und wer sich verbinden kann. BerechtigungsmodusEine Einstellung in Claude Code, die steuert, wie oft der Agent stoppt, um Bestätigung zu fordern, bevor Tool-Aufrufe ausgeführt werden. Modi reichen von default (fordert vor fast jeder Aktion auf) bis zu Bypass-Modi (keine Aufforderungen überhaupt). Deny-Regeln überschreiben jeden Modus; eine Deny-Regel auf Unternehmensebene kann von keiner einzelnen Konfiguration umgangen werden. PluginEin versioniertes Bundle von Claude Code-Komponenten (Skills, Hooks, Subagenten und MCP-Server-Konfigurationen), das über einen Marketplace verteilt wird. Das Installieren eines Plugins gibt dem Empfänger die gleiche Einrichtung wie der Autor in einem Schritt. Unternehmens-Administratoren können Plugins organisations-weit durch verwaltete Einstellungen bereitstellen. Rules-AnweisungsdateiEine Datei, die Anleitung auf eine spezifische Pfad oder Bedingung in Claude Code scoped. Anders als CLAUDE. md, das für jede Sitzung bedingungslos lädt, aktiviert sich eine Rules-Datei nur, wenn Claude Code im Verzeichnis arbeitet, das sie beaufsichtigt. Verwendet, um pfadspezifische Anleitung aus der Hauptprojekt-Gedächtnis-Datei zu halten. SubagentEin separater Ausführungs-Kontext, den Claude Code für eine delegierte Aufgabe startet. Ein Subagent erbt nicht die Hauptgesprächs-Historie oder angesammelten Dateien des Hauptkontexts; er startet sauber, führt die Aufgabe aus und gibt nur eine Zusammenfassung zurück. Die Verwendung von Subagenten für Explorations- oder Untersuchungs-Arbeit hält den Hauptsitzungs-Kontext davon ab, sich mit Inhalt zu füllen, der nicht wiederverwendet wird.

Screen 22: Glückwunsch! Du hast dieses Modul erfolgreich abgeschlossen.

Modul-AbschlussEntwickler-Pfad·2 min Glückwunsch! Du hast dieses Modul erfolgreich abgeschlossen. Du kannst jetzt Claude Code unter dem richtigen Berechtigungsmodus ausführen, ihm dauerhaften Projektkontext geben, einen Workflow als teilbares Plugin verpacken und Claude über MCP mit echten Systemen verbinden, ohne eine Anmeldedaten zu lecken oder eine Sicherheits-Überprüfung zu bestehen. Die Konfigurationsent scheidungen in diesem Modul sind, was eine Integration lange nach dem Verlassen deiner Maschine funktionieren lässt.

4 von 8 Checkpoints bestanden

MSO-Grundlagen Tokens, Context-Fenster, Sampling, Modell-Tiers, Aufforderungs-Modi und API-Transport-Mechaniken.

Produktions-Grad-Aufforderung, Agenten & Tool-Nutzung Produktions-bereite Aufforderungen, Tool-Nutzungs-Schleifen, Streaming, Kontext- und Gedächtnis-Verwaltung und Checkpoint-Agent-Schleifen.

Claude Code, MCP & Integration Berechtigungsmodi, dauerhafter Kontext, Plugin-Verpackung, MCP-Server und Unternehmens-Authentifizierung.

Du bist hier

Produktions-Engineering, Evals und Sicherheit Evals, Tracing, Fehler-Handhabung, Kosten- und Orchestrierungs-Budgets und Sicherheits-Grenzen, die in der Produktion halten.

Accelerators und IP-Beitrag Verpacke Accelerators, bereite überprüfbare Beiträge vor, wähle Bereitstellungs-Plattformen und markiere Vertrauens-Grenzen.

Modul überprüfen Von vorne beginnen Starte Modul 4 → Zurück zur Kurs-Startseite

Modul 3 abgeschlossen.