PodcastsHear the voice. See the shape of the thought.

Dieses Tutorial aus der Claude Code-Serie von Anthropic stellt vier konkrete Muster vor, die zuverlässige Subagenten von solchen unterscheiden, die abdriften, hängenbleiben oder Dateien verändern, die sie nicht anfassen sollten. Der Erzähler geht jeden Ansatz anhand eines Code-Review- und eines Websuche-Subagenten durch und zeigt genau, welche Konfigurationsparameter angepasst werden und warum. ## [00:03] Subagenten-Verhalten über Name und Beschreibung steuern Jede Nachricht an den Haupt-Kontextfenster-Agenten enthält im System-Prompt den Namen und die Beschreibung aller registrierten Subagenten. Die Beschreibung erfüllt damit eine Doppelfunktion: Sie teilt dem Orchestrator mit, *wann* er den Subagenten starten soll, und liefert die Vorlage, anhand derer er den Eingabe-Prompt formuliert. Das Tutorial demonstriert dies mit einem Code-Review-Subagenten. In der ursprünglichen Konfiguration schreibt der Orchestrator einen generischen Prompt, der den Subagenten anweist, selbst `git diff` aufzurufen. Wird die Beschreibung so geändert, dass sie lautet „Du musst dem Agenten genau mitteilen, welche Dateien er prüfen soll", geht die Verantwortung für die Dateiauswahl an den Orchestrator über — der nächste Lauf produziert einen deutlich spezifischeren Eingabe-Prompt. Denselben Hebel gibt es für Websuche-Subagenten: Das Hinzufügen von „Liefere Quellen, die zitierbar sind" zur Beschreibung sorgt dafür, dass der Hauptthread diese Anweisung bei jeder Delegation automatisch einschließt. > *"If you want to better control when the main agent launches a sub agent automatically, you should modify the name and description."* ## [01:41] Ausgabeformate definieren Der Erzähler bezeichnet das Ausgabeformat als die wirksamste Einzelverbesserung. Ohne ein definiertes Format fehlt dem Subagenten ein klares Signal dafür, wann er genug getan hat — er läuft weiter, sammelt Kontext an und verbraucht Token. Ein strukturiertes Ausgabeformat schafft einen natürlichen Haltepunkt: Sobald die Pflichtfelder gefüllt sind, weiß der Subagent, dass er fertig ist. Praktisch bedeutet das, dem System-Prompt des Subagenten ein explizites Schema hinzuzufügen — einen Zusammenfassungsblock, eine Befundliste, ein Statusfeld. > *"Without a defined output format, sub agents struggle to decide when enough research has been done and they tend to run much much longer than sub agents that are given an output format."* ## [02:04] Hindernisse im Ergebnisbericht melden Wenn ein Subagent ein Problem löst — einen Abhängigkeitskonflikt, einen Befehl, der unerwartete Flags benötigt, eine Eigenheit der Umgebung — muss der Hauptthread diese Information erhalten, sonst läuft er im nächsten Schritt in dieselbe Wand. Die Lösung besteht darin, das Melden von Hindernissen direkt in das Ausgabeformat zu integrieren. Der Erzähler nennt die Kategorien, die immer auftauchen sollten: aufgetretene Hindernisse, Einrichtungsprobleme, gefundene Workarounds, Befehle, die spezielle Flags oder Konfigurationen erforderten, sowie Abhängigkeiten oder Imports, die Schwierigkeiten verursachten. Werden diese ins Pflichtschema aufgenommen, erbt der Hauptthread die hart erkämpften Erkenntnisse des Subagenten, statt sie neu erarbeiten zu müssen. > *"Otherwise, the main thread has to rediscover the same solutions, obstacles encountered, any setup issues, workarounds discovered or environment quirks, commands that needed special flags or configuration, dependencies or imports that cause problems."* ## [02:42] Werkzeugzugriff nach Rolle einschränken Der Werkzeugzugriff ist nicht nur eine Sicherheitskontrolle — er ist auch ein Mittel zur Rollenklarheit. Ein schreibgeschützter Subagent mit nur `glob`, `grep` und `read` kann keine Dateien versehentlich ändern, was seine Rolle für alle, die die Konfiguration lesen, unmissverständlich macht. Der Erzähler ordnet drei Zugriffsebenen drei Subagenten-Rollen zu: Ein Recherche-Subagent erhält nur Lesezugriff, weil das Erkunden der Codebasis keine Schreibvorgänge erfordert. Ein Review-Subagent bekommt `bash` für `git diff`, aber keine Dateibearbeitungswerkzeuge. Nur Subagenten, die explizit damit beauftragt sind, Code zu verändern — etwa einer, der CSS-Updates einspielt — erhalten `edit` und `write`. Bei mehreren Subagenten im Einsatz wird die Werkzeugliste zu einer maschinenlesbaren Zusammenfassung der Aufgabe jedes Einzelnen. > *"Only give edit and write to sub agents that should actually change your code, like a styling agent applying CSS updates."* ## [03:27] Die vier Muster effektiver Subagenten Das Tutorial schließt mit einer einzigen Zusammenfassung aller vier Muster: strukturierte Ausgabe, Hindernismeldung, präzise Beschreibungen und eingeschränkter Werkzeugzugriff. Jedes Muster verstärkt die anderen — präzise Beschreibungen reduzieren Unklarheiten in Eingabe-Prompts, Ausgabeformate schaffen Haltepunkte, Hindernismeldungen sichern den Kontext über Agentengrenzen hinweg, und minimaler Werkzeugzugriff verhindert Nebeneffekte, die verbleibende Unklarheiten verstärken würden. > *"So effective sub agents use structured output report obstacles have specific descriptions and limit tool access."* ## Entitäten - **Anthropic Tutorial Narrator** (Person): Moderator der Claude Code Subagenten-Tutorial-Serie im Auftrag von Anthropic - **Claude Code** (Software): Anthropics agentisches Coding-Tool, das Subagenten orchestriert, um mehrstufige Engineering-Aufgaben abzuschließen - **Subagent** (Konzept): eine spezialisierte Claude-Instanz, die von einem Orchestrator-Agenten gestartet wird und über einen eigenen System-Prompt, Werkzeugzugriff und Eingabe-Prompt verfügt - **Ausgabeformat** (Konzept): ein im System-Prompt eines Subagenten definiertes Pflichtschema, das eine Abbruchbedingung schafft und die an den Hauptthread zurückgegebenen Informationen strukturiert - **Hindernismeldung** (Konzept): ein Muster, das Subagenten verpflichtet, Workarounds, Abhängigkeitsprobleme und Umgebungsbesonderheiten in ihrer Ausgabe zu melden, damit der Orchestrator sie nicht neu entdecken muss - **Werkzeugzugriff einschränken** (Konzept): jeden Subagenten auf die Werkzeuge zu beschränken, die seine Rolle erfordert — Lesezugriff für Recherche, bash für Reviews, edit/write nur für Agenten, die Dateien ändern müssen - **Anthropic** (Organisation): Schöpfer von Claude und der agentischen Coding-Plattform Claude Code

Subagenten sind spezialisierte Assistenten, an die Claude Code Aufgaben delegieren kann — jeder läuft in einem eigenen, isolierten Kontextfenster, erledigt seine Arbeit selbstständig und liefert danach eine kompakte Zusammenfassung zurück, während der vollständige Zwischenverlauf verworfen wird. Dieses zweiminütige Tutorial von Anthropic erklärt, warum diese Isolation das Hauptkontextfenster nutzbar hält, zeigt ein konkretes Code-Explorations-Szenario, das den Kompromiss verdeutlicht, und listet die eingebauten Subagenten auf, mit denen Claude Code heute ausgeliefert wird. ## [00:03] Was Subagenten sind Ein Subagent läuft in einem eigenen, separaten Kontextfenster, das mit einem selbst definierten System-Prompt initialisiert wird. Der übergeordnete Agent (Claude Code im Hauptthread) gibt dem Subagenten eine Aufgabenbeschreibung basierend auf der eigenen Anfrage. Der Subagent arbeitet diese selbstständig ab und liefert dann eine Zusammenfassung an den Hauptthread zurück — während die gesamte Zwischenarbeit isoliert bleibt. > *"Sub-agents are specialized assistants that Claude can delegate tasks to."* Der entscheidende Designpunkt: Sobald der Subagent fertig ist, wird sein gesamter Gesprächsverlauf vollständig verworfen. Nur die zurückgegebene Zusammenfassung fließt in das Hauptgespräch ein. ## [00:24] Das Kontextfenster im Griff behalten Jeder Tool-Aufruf, den Claude im Hauptthread macht — Datei-Lesevorgänge, Suchen, Funktions-Traces — sammelt sich im Hauptkontextfenster an. Bei langen Sitzungen füllt sich das schnell. Subagenten sind genau dafür da, einzelne Recherche- oder Aktionsaufgaben auszulagern, damit die Kosten nicht im Hauptfenster landen. > *"Each sub-agent runs in its own conversation contacts window with a custom system prompt that you define."* Der Kompromiss ist klar: Das Hauptfenster gewinnt einen sauberen Kontext, verliert aber den Einblick darin, wie der Subagent zu seinen Schlüssen gelangt ist und was er unterwegs entdeckt hat. Man bekommt die Antwort, nicht den Reasoning-Trace. ## [01:13] Ein konkretes Beispiel: das Zahlungssystem Angenommen, du nutzt Claude Code, um in einer unbekannten Codebasis herauszufinden, welcher Service Rückerstattungen verarbeitet. Ohne Subagenten würde Claude möglicherweise 15 Dateien lesen, mehrere Suchen durchführen und mehrere Funktionsaufrufe nachverfolgen — und all das füllt das Hauptkontextfenster, obwohl du nur eine einzige Information gebraucht hättest. > *"With a sub-agent, you get the answer without the journey."* Der Subagent durchforstet die Codebasis, findet die Antwort und liefert eine kompakte Zusammenfassung zurück — das Hauptkontextfenster bleibt sauber. Der Preis dafür ist der fehlende Einblick: Man sieht nicht, welche Dateien gelesen oder welche Traces verfolgt wurden. ## [02:00] Die eingebauten Subagenten von Claude Code Claude Code wird mit drei eingebauten Subagenten ausgeliefert, die sofort einsatzbereit sind: - **General-purpose sub-agent** — für mehrstufige Aufgaben, die sowohl Erkundung als auch Aktion erfordern. - **Explore sub-agent** — schnelles Durchsuchen von Codebasen ohne den Overhead eines vollständigen Task-Loops. - **Plan sub-agent** — läuft im Plan-Modus und analysiert die Codebasis, bevor ein Plan präsentiert wird. > *"And you can also create your own sub-agents with custom system prompts and tool access."* Über diese drei hinaus lassen sich eigene Subagenten mit individuellen System-Prompts und Tool-Zugriffslisten definieren, zugeschnitten auf spezifische Workflows. ## [02:30] Wann Subagenten sinnvoll sind Subagenten lohnen sich, wenn eine abgeschlossene, in sich selbst enthaltene Frage oder Aufgabe vorliegt, die andernfalls viel Zwischenkontext ins Hauptfenster spülen würde. > *"Sub-agents like Claude Code break work into focused pieces, keep your main context window clean, and bring back just what you need, whether you're using the built-in ones or creating your own."* Besonders wertvoll sind sie bei längeren Claude Code-Sitzungen, in denen sich der Kontextfensterdruck aufbaut — eine Teilaufgabe an einen Subagenten auszulagern, statt sie direkt im Hauptthread zu bearbeiten, verlängert spürbar, wie lange eine Sitzung effektiv bleibt. ## Entitäten - **Anthropic Tutorial Narrator** (Person): Sprecher der Tutorial-Reihe "Claude Code subagents", produziert von Anthropic - **Claude Code** (Software): Anthropics agentischer Coding-Assistent; die Umgebung, in der Subagenten betrieben werden - **Claude** (Software): das zugrundeliegende KI-Modell, das Claude Code und seine Subagenten antreibt - **Sub-agent** (Konzept): ein spezialisierter Assistent, an den Claude Code Aufgaben delegiert; läuft in einem isolierten Kontextfenster mit eigenem System-Prompt - **Context window** (Konzept): der begrenzte Token-Puffer, der den gesamten Gesprächsverlauf, Tool-Aufrufe und Ergebnisse enthält; Subagenten verhindern, dass er sich mit Zwischenarbeit füllt - **General-purpose sub-agent** (Software): eingebauter Claude Code-Subagent für mehrstufige Erkundungs- und Aktionsaufgaben - **Explore sub-agent** (Software): eingebauter Claude Code-Subagent, optimiert für schnelles Durchsuchen von Codebasen - **Plan sub-agent** (Software): eingebauter Claude Code-Subagent, der im Plan-Modus die Codebasis analysiert, bevor ein Plan präsentiert wird - **Anthropic** (Organisation): Schöpfer von Claude und Claude Code; Produzent dieser Tutorial-Reihe

Tao und Dwarkesh nehmen Keplers Entdeckung der Planetenbewegung als Linse für das, was KI in der Wissenschaft wirklich verändert. Tao argumentiert, dass die Hypothesengenerierung heute nahezu kostenlos ist und der Engpass damit auf Bewertung, Peer-Review und die Bewährung über die Zeit übergeht. Aktuelle KI-Systeme gewinnen durch Breite (alle Standardmethoden auf jedes Problem anwenden), Menschen durch Tiefe (kumulativ auf Teilfortschritten aufbauen) — deshalb werden Hybridkonfigurationen die Mathematik noch mindestens ein Jahrzehnt dominieren. ## [00:00] Kepler war ein LLM mit hoher Temperatur Tao schildert, wie Kepler zu seinen drei Gesetzen der Planetenbewegung gelangte. Kepler startete mit einer falschen, aber ästhetisch überzeugenden Theorie — Platonische Körper zwischen den Planetenbahnen — und verwarf sie erst, nachdem er jahrelang Tycho Brahes gestohlene Beobachtungen mit bloßem Auge ausgewertet hatte. Ellipsen, Flächensatz und das Verhältnis aus Umlaufzeit und Abstand entstanden durch jahrzehntelange Datenanalyse; Newtons Erklärung folgte ein Jahrhundert später. Dwarkeshs Deutung: Kepler ähnelt einem LLM mit hoher Temperatur, der zufällige Zusammenhänge gegen einen prüfbaren Datensatz durchspielt. Tao stimmt der Mechanik zu, widerspricht aber bei der Engpassfrage. Ideen zu erzeugen war schon damals billig — Kepler hatte keinen Mangel an Theorien. Was er brauchte, waren Brahes um eine Größenordnung bessere Daten und die Geduld, Ideen zu verwerfen, die die Daten widerlegten. > *Aber wie Sie sagen, muss das durch ebenso viel Verifikation gedeckt sein, sonst ist es nur Schrott.* ## [11:44] Wie erkennt man ein neues vereinheitlichendes Konzept in Massen von KI-Schrott? Tao: Hat KI die Ideengenerierung auf nahezu null gedrückt, werden Peer-Review und die Bewährung über die Zeit zur eigentlichen Engstelle. Fachzeitschriften versinken bereits in KI-generierten Einreichungen. Was eine Idee wert ist, zeigt sich daran, was spätere Wissenschaft damit anfängt — Kopernikus war ungenauer als Ptolemäus, bis Kepler das Bild vervollständigte — und diese Bewertung lässt sich im Moment kaum automatisieren. Dwarkesh fragt, wie die Wissenschaft ein Bell-Labs-artiges vereinheitlichendes Konzept (Shannons Bit, der Transformer) in Millionen mittelmäßiger Arbeiten erkennen würde. Taos Antwort verweist auf den Teil, der menschlich bleiben könnte: Wissenschaftler produzieren nicht nur Theorien, sie erzählen Geschichten, die andere überzeugen, Jahre in die Nachverfolgung zu investieren. Darwins Prosa leistete, was Newtons lateinische Gleichungen nicht schafften. > *KI hat die Kosten der Ideengenerierung auf nahezu null gesenkt, ähnlich wie das Internet die Kosten der Kommunikation auf nahezu null gesenkt hat.* ## [26:10] Der deduktive Überhang Tao über das ungenutzte Signal in vorhandenen Daten. Die Astronomie hat seit Jahrhunderten die Disziplin verfeinert, maximale Information aus minimalen Daten zu ziehen — weshalb Quant-Hedgefonds bevorzugt Astronomie-Doktoranden einstellen. Ein Lieblingsbeispiel: Forscher maßen, wie oft Wissenschaftler die Arbeiten, die sie zitieren, tatsächlich gelesen hatten, indem sie verfolgten, welche Tippfehler sich durch Zitationsketten fortpflanzten. Er schlägt vor, dieselbe wissenschaftssoziologische Methode auf den KI-Fortschritt selbst anzuwenden — Zitationsmuster, Konferenzerwähnungen und andere Spuren auswerten, um zu erkennen, ob ein Ergebnis tatsächlich einen Fortschritt darstellte, statt auf die langsame Bewährung über die Zeit zu warten. > *Eine Erkenntnis war, dass der deduktive Überhang in vielen Feldern viel größer sein könnte, als die meisten Menschen ahnen.* ## [30:31] Auswahlverzerrung bei gemeldeten KI-Entdeckungen KI hat rund 50 von etwa 1.100 Erdős-Problemen gelöst und stagniert seither. Tao erklärt den Selektionseffekt: Bei diesen 50 gab es kaum Literatur — eine obskure Technik plus ein bekanntes Ergebnis reichten, und KI-Werkzeuge sind hervorragend darin, "alle Standardkombinationen durchzuprobieren." Wenn 80 % der Arbeit durch bestehende Methoden erledigt ist, räumt KI das Problem aus dem Weg. Braucht es eine wirklich neue Technik, kommen die Werkzeuge nicht weiter, und die Erfolgsquote systematischer Durchläufe liegt bei 1-2 %. Taos Metapher: KI-Werkzeuge sind springende Roboter in einem dunklen Gebirge. Sie kommen über kurze Mauern hinweg, die Menschen nicht erreichen können, aber sie können keinen Griff fassen, dort verharren und sich aus Teilfortschritten hochziehen. Die optimistische Lesart — sobald KI ein bestimmtes Niveau erreicht, kann man eine Million Kopien parallel auf eine Million Probleme ansetzen, was keine menschliche Gemeinschaft kann — ist auch der strukturelle Grund, warum die Wissenschaft neue Paradigmen braucht, die Breite wirklich nutzen. > *Sie sind überlegen in der Breite, und Menschen sind überlegen in der Tiefe, zumindest menschliche Experten.* ## [46:43] KI macht Arbeiten breiter und reichhaltiger, aber nicht tiefer Tao über seine eigene Arbeitsweise: Arbeiten enthalten jetzt mehr Code, mehr Abbildungen und tiefere Literaturrecherchen, weil Hilfsaufgaben etwa fünfmal günstiger geworden sind. Der eigentliche Kern — den schwierigsten Teil eines Problems lösen — geschieht nach wie vor mit Stift und Papier. Er würde sich scheuen, sich als "doppelt so produktiv" zu bezeichnen, denn der Maßstab ist nicht eindimensional; was sich verändert hat, ist die Art der Arbeiten, die er schreibt, nicht die Rate, mit der er seine eigentliche Ausgangsfrage beantwortet. Die Unterscheidung zwischen Cleverness und Intelligenz führt an denselben Ort. Wenn zwei Menschen gemeinsam an einem Mathematikproblem arbeiten, wird jeder gescheiterte Ansatz zur Basis für den nächsten. Bei aktuellen KI-Systemen vergisst eine neue Sitzung, was die letzte herausgefunden hat. Der kumulative Hochzieh-Schritt fehlt — es bleibt bei reinem Versuch-und-Irrtum und der schließlichen Absorption ins nächste Training. > *Die Arbeiten sind dadurch reicher und breiter geworden, aber nicht notwendigerweise tiefer.* ## [53:00] Wenn KI ein Problem löst, können Menschen dann etwas daraus lernen? Könnte eine KI die Riemann-Hypothese in Lean beweisen und uns ohne jeden Erkenntnisgewinn zurücklassen? Tao macht sich keine Sorgen. Lean hat die Eigenschaft, dass jeder Beweis atomar zerlegbar ist — jedes Lemma lässt sich einzeln inspizieren, ablativieren und testen. Selbst ein 3.000-Zeilen-Beweis wird so zum Rohmaterial: Andere KI-Systeme können ihn auf Eleganz umformen, andere Menschen den konzeptuellen Gehalt herausarbeiten, und das Artefakt bleibt nützlich, auch wenn die ursprüngliche Herleitung undurchsichtig war. Er sagt eine ganze Berufsgruppe von Mathematikern voraus, deren Aufgabe es sein wird, riesige Lean-generierte Beweise auseinanderzunehmen und die darin verborgenen Ideen freizulegen — eine Art Beweisarchäologie, mit menschlichem Urteilsvermögen und KI-Ablativierungswerkzeugen. > *Man gewinnt viel mehr aus dem Zusammenspiel von Menschen, die mit diesen Werkzeugen zusammenarbeiten.* ## [59:20] Wir brauchen eine halbformale Sprache für den Austausch zwischen Wissenschaftlern Dwarkesh fragt, wie eine halbformale Sprache für mathematische Strategien (im Unterschied zu mathematischen Beweisen) aussehen könnte. Tao verfolgt die Frage durch den Primzahlsatz von Gauß — die erste große statistische Vermutung in der Mathematik, aus Rohdaten abgeleitet, bevor ein Beweis existierte — und durch die Zwilllingsprimzahlvermutung, an die Mathematiker glauben, weil das Zufallsmodell der Primzahlen sie vorhersagt. Mathematik hat sowohl rigorose Beweise als auch rigorose Heuristiken; nur die Beweisseite wurde formalisiert, so dass Lean sie prüfen kann. Warum die Heuristikseite noch nicht formalisiert wurde: Jeder RL-prüfbare Bewerter wird zum Angriffsziel für Exploits, und der subjektive Teil von "dieses Argument ist überzeugend" lässt sich noch nicht in einem exploitierbaren Rahmen fassen. Tao würde gern einen Weg finden, Vermutungsgenerierung und Strategiewahl im großen Maßstab zu benchmarken, möglicherweise indem man kleine KI-Systeme in vereinfachten mathematischen Universen laufen lässt und beobachtet, welche Strategien entstehen. > *Es gibt einen subjektiven Aspekt der Wissenschaft, den wir nicht wissen, wie wir ihn so erfassen können, dass wir KI auf nützliche Weise einbinden könnten.* ## [69:48] Wie Terry seine Zeit einteilt Tao darüber, wie er neue Teilgebiete erschließt. Er ordnet sich selbst als Fuchs im Sinne Berlins ein — ein bisschen über alles, gelegentlich Igel, wenn nötig. Der Antrieb ist eine Vollständigkeitsobsession: Wenn ein anderer Mathematiker ein Ergebnis mit einer Technik beweisen kann, die er nicht kennt, muss er herausfinden, was der Trick war. (Videospiele hat er aus demselben Grund aufgegeben.) Zusammenarbeit mit anderen Mathematikern ist das wichtigste Vehikel, und Dinge in seinem Blog aufzuschreiben ist die Gedächtnishilfe, die er entwickelt hat, nachdem er Argumente sechs Monate nach ihrer Herleitung wiederholt vergessen hatte. In seinem Kalender lässt Tao bewusst Raum für Zufälle. Er würde es hassen, seine Zeit so straff zu optimieren, dass er nie in einem Meeting sitzt, das außerhalb seiner Komfortzone liegt. Das Jahr am Institute for Advanced Study bestätigte die Falle — zwei Wochen reine Forschung waren großartig, dann ging ihm die Inspiration aus. Die zufällige Entdeckung im nächsten Bücherregal, das beiläufige Flurgespräch und das Meeting, das er widerstrebend besuchte, leisteten mehr, als es den Anschein hatte. > *Diese zufälligen Begegnungen mögen nicht optimal erscheinen, aber sie sind tatsächlich sehr wichtig.* ## [77:05] Mensch-KI-Hybride werden die Mathematik noch sehr viel länger dominieren Wann wird KI die Mathematik eigenständig betreiben? Tao rahmt die Frage neu — KI betreibt bereits Mathematik, die Menschen nicht können, seit dem Taschenrechner, nur an einer anderen Grenze. In etwa einem Jahrzehnt erwartet er, dass ein Großteil dessen, was Doktoranden heute tun — Standardmethoden anwenden, Literatur aufarbeiten — an KI übergeht; das Feld wird dann eine Ebene nach oben rücken, wie es beim Computeralgebrasystem und der symbolischen Integration geschah. Die Genetik endete nicht, als Sequenzierung billig wurde; sie skalierte hinauf zu Ökosystemen. Die Mathematik wird dasselbe tun. Sein Rat an Studierende, die jetzt in die Mathematik einsteigen: Veränderung einkalkulieren, aber den Abschluss auf dem herkömmlichen Weg erwerben — vorläufig gibt es noch keinen Ersatz dafür, Mathematik auf dem traditionellen Pfad zu erarbeiten. Gleichzeitig anpassungsfähig genug bleiben, um völlig neue Forschungsweisen zu nutzen, wenn sie entstehen, einschließlich solcher, die es noch nicht gibt. Bemerkenswert ist, dass ein Gymnasiast heute mit KI-Werkzeugen und Lean echte mathematische Forschung betreiben kann — das war vor fünf Jahren noch nicht möglich. > *Ich glaube tatsächlich, dass Mensch-KI-Hybride die Mathematik noch sehr viel länger dominieren werden.* ## Entitäten - **Terence Tao** (Person): Fields-Medaillist (2006), Mathematiker an der UCLA, schreibt regelmäßig über die Rolle von KI in der mathematischen Forschung. - **Dwarkesh Patel** (Person): Moderator des Dwarkesh Podcast; Langformatinterviews zu KI, Wissenschaft und Technologie. - **Johannes Kepler** (Person): Astronom (1571-1630), der die drei Gesetze der Planetenbewegung aus den Beobachtungen Tycho Brahes ableitete. - **Tycho Brahe** (Person): Dänischer Beobachtungsastronom, dessen jahrzehntelange Planetenbeobachtungen mit bloßem Auge den Datensatz lieferten, den Kepler benötigte. - **Lean** (Software): Beweisassistent, in dem mathematische Beweise formalisiert, geprüft, zerlegt und atomar ablativiert werden können. - **Erdős-Probleme** (Konzept): Die rund 1.100 offenen Probleme, die Paul Erdős aufgestellt hat; KI hat etwa 50 davon gelöst, fast alle mit kaum vorhandener Vorliteratur. - **Der deduktive Überhang** (Konzept): Die Idee, dass vorhandene Daten weit mehr ableitbares Wissen enthalten, als bisher extrahiert wurde, mit der Astronomie als Modell. - **Riemann-Hypothese** (Konzept): Ungelöste Vermutung zur Verteilung der Primzahlen; der Testfall dafür, ob ein KI-Beweis das mathematische Verständnis des Menschen voranbringen würde.

Claude Code Skills sind wiederverwendbare Markdown-Dateien, die Spezialwissen einmalig festhalten. Claude aktiviert sie automatisch, sobald eine Anfrage passt — ohne dass der Nutzer Anweisungen wiederholen oder einen Slash-Befehl eingeben muss. Dieses dreiminütige Tutorial erklärt, was Skills sind, wo sie liegen, wie sie sich von CLAUDE.md-Dateien unterscheiden und welches Signal anzeigt, dass es Zeit ist, einen zu schreiben. ## [00:03] Das Wiederholungsproblem, das Skills lösen Jedes Mal, wenn du Claude die Coding-Standards deines Teams erklärst, neu beschreibst, wie du PR-Feedback strukturiert haben möchtest, oder ihn an dein bevorzugtes Commit-Format erinnerst, wiederholst du dich. Der Sprecher nennt drei Beispiele nacheinander, um den genauen Reibungspunkt zu benennen, den Skills beseitigen. > *"Every time you explain your team's coding standards to Claude, you're repeating yourself."* ## [00:20] Was ein Skill ist und wie Claude einen auswählt Ein Skill ist eine Markdown-Datei, die Claude einmal beibringt, wie etwas funktioniert. Claude speichert die Anweisung und wendet sie automatisch an, sobald die Situation es erfordert. In Claude Code heißt diese Datei SKILL.md. Das description-Feld darin ist der entscheidende Mechanismus: Wenn du Claude bittest, eine PR zu reviewen, vergleicht er deine Anfrage mit allen verfügbaren Skill-Beschreibungen und aktiviert die passende. > *"Claude reads your request, compares it to all available skill descriptions, and activates the ones that match."* ## [01:05] Wo Skills gespeichert werden: persönlich oder Projekt Skills haben zwei Speicherorte, je nachdem wer sie braucht. Persönliche Skills kommen in `~/.claude/skills` und begleiten dich projektübergreifend: Commit-Stil, Dokumentationsformat, wie du Code erklärt haben möchtest. Projekt-Skills kommen in `.claude/skills` im Repository-Stammverzeichnis; wer das Repo klont, erhält sie automatisch. Dort leben Team-Standards: Markenrichtlinien, bevorzugte Schriften und Farben fürs Webdesign. > *"Anyone who clones the repository gets these skills automatically."* ## [01:42] Skills vs CLAUDE.md: automatisch und kontexteffizient Claude Code bietet mehrere Anpassungsebenen, und Skills besetzen eine eigene Nische. CLAUDE.md-Dateien werden in jedes Gespräch bedingungslos geladen — richtig für Regeln wie „immer TypeScript Strict Mode verwenden". Skills laden bei Bedarf, nur wenn sie zur aktuellen Anfrage passen, und zunächst gelangen nur Name und Beschreibung in den Kontext. Der vollständige Skill-Inhalt wird erst beim Auslösen geladen. So belastet die PR-Review-Checkliste den Kontext nicht beim Debuggen, sondern wird erst dann eingelesen, wenn du tatsächlich ein Review anforderst. Slash-Befehle muss man eintippen; Skills nicht. > *"Skills are unique because they're automatic and task-specific."* ## [02:27] Wann man einen Skill schreibt Skills eignen sich am besten für Spezialwissen, das an bestimmte Aufgaben gebunden ist: Code-Review-Standards des Teams, Commit-Formate, Markenrichtlinien. Die abschließende Faustregel ist knapp und praktisch: Wer sich dabei ertappt, Claude immer wieder dasselbe zu erklären, hat einen Skill vor sich, der darauf wartet, geschrieben zu werden. > *"If you find yourself explaining the same thing to Claude repeatedly, well, that's a skill waiting to be written."* ## Entitäten - **Anthropic Tutorial Narrator** (Person): Sprecher und Moderator der Claude Code Skills-Tutorialserie - **Claude Code** (Software): KI-Programmierassistent von Anthropic; die Laufzeitumgebung, in der Skills erkannt und angewendet werden - **SKILL.md** (Konzept): die Markdown-Datei, die einen Skill definiert — enthält Namen, Beschreibung und Anweisungen für Claude - **CLAUDE.md** (Konzept): projektweite oder globale Anweisungsdatei, die bedingungslos in jedes Claude Code-Gespräch geladen wird, im Gegensatz zu Skills - **Anthropic** (Organisation): Schöpfer von Claude und Claude Code

Ein PR-Review-Skill, den ein einzelner Entwickler nutzt, ist praktisch; derselbe Skill im ganzen Team standardisiert Code-Reviews und sorgt für ein einheitliches Erlebnis in der gesamten Organisation. Dieses Tutorial zeigt vier konkrete Verteilungsmethoden — Repository-Commits, Plugins, Enterprise Managed Settings und benutzerdefinierte Sub-Agenten — und erklärt genau, wann welche zum Einsatz kommt. Der Abschnitt zu Sub-Agenten enthält einen nicht offensichtlichen Vorbehalt: Sub-Agenten erben Skills nicht automatisch, und eingebaute Agenten können überhaupt nicht auf Skills zugreifen. ## [00:01] Warum Teilen den Wert eines Skills vervielfacht Ein Skill, der nur bei einem Entwickler liegt, leistet seinen Dienst. Derselbe Skill im Team verankert Standards, beseitigt individuelle Abweichungen und macht jeden Review-Prozess konsistent in Stil und Ergebnis. Das Tutorial beginnt mit einem direkten Vergleich zwischen Einzel- und Teamnutzung, bevor die vier Sharing-Mechanismen vorgestellt werden. > *"A PR review skill that only you use is helpful. The same skill shared across your team standardizes code review and provides a consistent experience amongst your organization which is much better."* ## [00:18] Skills ins Repository einchecken Der Weg mit dem geringsten Aufwand: Skills in `.claude/skills` im Projektrepository ablegen. Wer das Repository klont, erhält diese Skills sofort — kein Installationsschritt, kein zusätzliches Tooling. Updates kommen über den normalen `git pull`-Zyklus. Diese Methode passt zu Team-Codierstandards, projektspezifischen Workflows und Skills, die auf die eigene Codestruktur verweisen. > *"Anyone who clones the repository gets these skills automatically. No extra installation, it's just what you're doing already."* ## [00:45] Skills über Plugins verteilen Plugins erweitern Claude Code um benutzerdefinierte Funktionalität, die über ein einzelnes Projekt hinaus reist. Im Plugin-Projekt spiegelt ein `skills/`-Verzeichnis die Struktur von `.claude/` wider — Skillname, `SKILL.md`. Nach der Veröffentlichung in einem Marketplace kann jeder Claude Code-Nutzer das Plugin herunterladen und aktivieren. Dieser Kanal eignet sich am besten für Skills, die allgemein genug sind, um der breiteren Community zu dienen, nicht nur den Konventionen eines einzelnen Teams. > *"Think of plugins as ways to extend Claude Code with custom functionality, but designed to be shared across teams and projects."* ## [01:26] Unternehmensweites Deployment via Managed Settings Administratoren können Skills über Managed Settings an jeden Entwickler der Organisation verteilen. Enterprise-Skills haben die höchste Priorität: Sie überschreiben persönliche, Projekt- und Plugin-Skills mit gleichem Namen. Gedacht ist das für verbindliche Standards — Sicherheitsanforderungen, Compliance-Workflows, Codierungsrichtlinien, die einheitlich sein müssen. Der Narrator betont das Wort „must" ausdrücklich: Das sind keine Empfehlungen. > *"This is for mandatory standards, security requirements, compliance workflows, or coding practices that must be consistent across the organization."* ## [01:52] Benutzerdefinierte Sub-Agenten und explizites Skill-Loading Sub-Agenten erben die Skills der Hauptkonversation nicht. Eingebaute Agenten (explorer, planner, verify) können überhaupt nicht auf Skills zugreifen. Nur benutzerdefinierte Sub-Agenten — definiert durch eine `agent.md`-Datei in `.claude/agents` — können Skills nutzen, und zwar ausschließlich die, die im `skills:`-Feld dieser Datei explizit aufgeführt sind. Skills werden beim Start des Sub-Agenten geladen, nicht bei Bedarf. Die Liste sollte daher knapp gehalten werden: nur Skills, die für den Zweck des Agenten stets relevant sind. Das Tutorial zeigt, wie man mit dem Claude Code Sub-Agenten-Creator einen neuen Sub-Agenten erstellt und Skills an eine bestehende `agent.md` anhängt. > *"Built-in agents like the explorer, planner, and verify can't access skills at all. Only custom sub-agents you define can use them, and only when you explicitly list them."* ## [03:18] Zusammenfassung: die richtige Verteilungsmethode wählen Der Abschluss ordnet jede Methode ihrem Szenario zu: Projektverzeichnisse für den Teamzugang, Plugins für die repositoryübergreifende Weitergabe, Enterprise-Deployment für organisationsweite Pflichtstandards und explizite Sub-Agenten-Skill-Listen für isolierte Aufgabendelegation. Der Hinweis zu Sub-Agenten kommt noch einmal — nur die Skills auflisten, die für einen bestimmten Agenten stets relevant sind, denn sie werden beim Start geladen, nicht lazy. > *"Share skills through project directories for team access, plugins for cross-repository distribution, or enterprise deployment for organization-wide standards."* ## Entitäten - **Anthropic Tutorial-Narrator** (Person): alleiniger Präsentator der Claude Code Skills Tutorial-Serie - **Claude Code** (Software): KI-gestützter Coding-Assistent von Anthropic; die Laufzeitumgebung, in der Skills erstellt und eingesetzt werden - **Skills** (Konzept): wiederverwendbare Anweisungssets in `.claude/skills`, die das Verhalten von Claude Code erweitern - **Plugins** (Konzept): verteilbare Pakete, die Skills bündeln und teamübergreifend sowie über den Marketplace teilen - **Managed Settings** (Konzept): Enterprise-Administratormechanismus zur organisationsweiten Bereitstellung von Skills mit höchster Priorität - **Sub-Agenten** (Konzept): benutzerdefinierte Claude Code-Agenten, die via `agent.md` in `.claude/agents` definiert werden; der einzige Agententyp, der Skills laden kann, und nur wenn sie explizit aufgeführt sind - **Anthropic** (Organisation): Unternehmen, das Claude Code entwickelt hat und die Claude Code Skills Tutorial-Serie produziert

Ein vierminütiges Tutorial aus der Claude Code Skills-Reihe über die erweiterten Konfigurationsfelder, die aus einem einfachen Skill ein zuverlässiges, kontexteffizientes Werkzeug machen. Der Erzähler geht das vollständige agentskills.io-Feldset durch — `name`, `description`, `allowed_tools`, `model` — und erklärt anschließend, wie man größere Skills per Progressive Disclosure strukturiert, sodass Referenzmaterial und Skripte nur geladen werden, wenn die Anfrage des Nutzers das tatsächlich erfordert. ## [00:02] Überblick über erweiterte Skill-Felder Der offene Standard agentskills.io definiert mehrere Felder jenseits der Pflichtfelder `name` und `description`. `name` muss aus Kleinbuchstaben mit Bindestrichen bestehen, darf maximal 64 Zeichen lang sein und muss mit dem Verzeichnisnamen übereinstimmen. `description` fasst bis zu 1.024 Zeichen und ist das primäre Signal, anhand dessen Claude einen Skill einer Anfrage zuordnet. Zwei optionale Felder runden die Konfiguration ab: `allowed_tools` schränkt ein, welche Werkzeuge der Skill aufrufen darf, und `model` fixiert den Skill auf eine bestimmte Claude-Version. > *"Ein einfacher Skill funktioniert mit nur einem name und einer description – aber hier sind einige fortgeschrittene Tipps, mit denen deine Skills in Claude Code wirklich effektiv werden."* ## [00:39] Effektive Descriptions schreiben Eine vage Description – „help with dogs" – lässt Claude im Dunkeln darüber, wofür der Skill zuständig ist und wann er ausgelöst wird. Eine gute Description beantwortet genau zwei Fragen: Was tut dieser Skill, und wann soll Claude ihn einsetzen? Schlüsselbegriffe an die natürliche Ausdrucksweise der Nutzeranfragen anzupassen ist der wirksamste Hebel, um Skills zu reparieren, die nicht auslösen. > *"Eine gute Description beantwortet zwei Fragen: Was macht dieser Skill? Und wann soll Claude ihn nutzen?"* ## [01:20] Werkzeuge mit allowed_tools einschränken `allowed_tools` ist der Mechanismus, um einen Skill auf eine definierte Operationsfläche zu begrenzen — zum Beispiel reiner Lesezugriff für sicherheitssensible Arbeitsabläufe. Ist das Feld gesetzt, darf Claude nur diese Werkzeuge ohne Rückfrage aufrufen; Bearbeiten, Schreiben und Bash-Befehle sind ausgeschlossen. Wird das Feld weggelassen, bleibt Claudes normales Berechtigungsmodell unverändert. > *"Wenn dieser Skill aktiv ist, kann Claude nur diese Werkzeuge ohne Genehmigung verwenden. Kein Bearbeiten, kein Schreiben, keine Bash-Befehle."* ## [01:49] Progressive Disclosure für Multi-Datei-Skills Skills teilen Claudes Kontextfenster mit dem laufenden Gespräch. Alles in eine 20.000 Zeilen lange `SKILL.md` zu packen bläht den Kontext bei jedem Aufruf auf und macht die Datei zum Wartungsalbtraum. Die Lösung: wesentliche Anweisungen in `SKILL.md` belassen und Referenzmaterial in separate Dateien auslagern, die Claude nur liest, wenn die aktuelle Anfrage das wirklich verlangt. Der Standard empfiehlt drei Hilfsverzeichnisse — `scripts/` für ausführbaren Code, `references/` für Dokumentation und `assets/` für Bilder und Vorlagen. Ein Link in `SKILL.md` funktioniert wie ein Inhaltsverzeichniseintrag; kommt das Thema nie auf, wird die Datei nie geladen. Skripte im Skill-Verzeichnis werden ausgeführt, ohne dass ihr Quellcode in den Kontext geladen wird — nur ihre Ausgabe verbraucht Tokens. Der Erzähler empfiehlt, `SKILL.md` unter 500 Zeilen zu halten; wird diese Marke überschritten, ist das ein Signal, den Skill aufzuteilen. > *"Es ist, als hätte man ein Inhaltsverzeichnis im Kontextfenster, statt das gesamte Dokument dort hineinzuquetschen."* ## [03:18] Zusammenfassung: Skill-Metadaten und Best Practices Das Tutorial schließt mit einer Wiederholung der vollständigen Konfigurationsfläche: `name` und `description` sind Pflicht; `allowed_tools` schränkt die Werkzeugfläche ein; `model` fixiert die Claude-Version. Descriptions benötigen konkrete Aktionsverben und Auslösephrasen, um zuverlässig zu matchen. Bei größeren Skills hält Progressive Disclosure `SKILL.md` unter 500 Zeilen und lädt Hilfsdateien erst, wenn sie tatsächlich gebraucht werden. Skripte werden ohne Laden ihres Quellcodes ausgeführt, was den Kontext schlank hält. > *"Skripte können ausgeführt werden, ohne ihren Inhalt zu laden, was den Kontext effizient hält."* ## Entitäten - **Anthropic-Tutorial-Erzähler** (Person): alleiniger Moderator dieser Tutorial-Reihe, der die Konfiguration von Claude Code Skills erklärt. - **Claude Code** (Software): CLI-Tool von Anthropic, das Skills gemäß dem agentskills.io-Standard lädt und ausführt. - **agentskills.io** (Organisation): offener Standard, der das Skill-Manifest-Schema definiert, einschließlich `name`, `description`, `allowed_tools`, `model` und Verzeichniskonventionen. - **SKILL.md** (Konzept): primäre Manifest-Datei eines Claude Code Skills; sollte unter 500 Zeilen bleiben und Links zu unterstützenden Dateien enthalten. - **allowed_tools** (Konzept): optionales Skill-Feld, das bestimmte Claude-Werkzeuge auf die Whitelist setzt und so reine Lese- oder Sandbox-Skill-Modi ermöglicht. - **Progressive Disclosure** (Konzept): Strukturierung eines Multi-Datei-Skills, sodass Referenzdateien und Skripte nur dann in den Kontext geladen werden, wenn die aktuelle Anfrage das wirklich benötigt. - **Kontextfenster** (Konzept): geteiltes Token-Budget zwischen dem Gespräch und den von Claude geladenen Skill-Dateien; die Schlüsselressource, die Progressive Disclosure schonen soll.

Dieses 3-minütige Tutorial zeigt Schritt für Schritt, wie man eine persönliche Claude Code-Fähigkeit von Grund auf baut: ein Verzeichnis mit einer SKILL.md-Datei anlegen, sicherstellen, dass die Fähigkeit beim Start geladen wird, und beobachten, wie Claude sie auf eine echte Anfrage anwendet. Die zweite Hälfte erklärt genau, wie Claudes Lade-Pipeline für Fähigkeiten funktioniert — von den vier Scan-Speicherorten und dem startorientierten Nur-Name-Durchlauf bis zum Bestätigungsgate und der vierstufigen Prioritätsreihenfolge, die Namenskonflikte auflöst. ## [00:03] Was dieses Tutorial aufbaut Der Erzähler nennt gleich zu Beginn das konkrete Ziel: eine Fähigkeit, die Claude beibringt, Code mithilfe visueller Diagramme und Analogien zu erklären. Nach dem Aufbau wird auch nachverfolgt, was intern abläuft, wenn Claude eine Fähigkeit erkennt und ausführt. > *"This skill will teach Claude how we would like it to explain code using visual diagrams and analogies."* ## [00:18] Die Fähigkeitsdatei erstellen Persönliche Fähigkeiten liegen im Home-Verzeichnis (nicht in einem Projekt), daher besteht der erste Schritt darin, ein neues Verzeichnis mit dem Fähigkeitsnamen in `~/.claude/skills/` zu erstellen. Darin befindet sich eine einzige SKILL.md-Datei. Drei Abschnitte sind entscheidend: `name` (der Bezeichner, den Claude beim Start speichert), `description` (das Kriterium, anhand dessen Claude entscheidet, ob die Fähigkeit aktiviert wird) und alles nach dem zweiten `---`-Trennzeichen (die eigentlichen Anweisungen, denen Claude folgt, wenn die Fähigkeit ausgelöst wird). > *"Take into consideration that we're creating a directory with the skill name inside of the skills directory."* ## [00:52] Deine Fähigkeit laden und testen Claude Code scannt Fähigkeiten beim Start, nicht auf Abruf, daher ist nach dem Erstellen der Datei ein Neustart der Session erforderlich. `/skills` sollte dann die neu erstellte Fähigkeit auflisten. Zum Testen wechselt man zu einem Branch mit Änderungen und sendet die Anfrage in natürlicher Sprache: "Write a PR description for my changes." Claude zeigt an, dass es die PR-description-Fähigkeit aufruft, liest dann den Diff und schreibt eine Beschreibung, die jedes Mal dieselbe Vorlage einhält. > *"Claude will then show you that it's using the PR description skill."* ## [01:25] Wie Claude Fähigkeiten im Hintergrund lädt Beim Start scannt Claude Code vier Speicherorte: verwaltete Enterprise-Einstellungen, das persönliche `~/.claude/skills/`, das `.claude/`-Verzeichnis des Projekts und installierte Plugins. Dabei werden nur `name` und `description` geladen, nicht der vollständige Inhalt. Kommt eine Anfrage an, vergleicht Claude sie mit den gespeicherten Beschreibungen; "explain what this function does" überschneidet sich mit "explain code with visual diagrams", also stimmt die Fähigkeit überein. Bevor Claude die vollständige SKILL.md liest, bittet es um Bestätigung, damit der Nutzer immer weiß, welcher Kontext eingebettet wird. > *"It loads only the name and description of each skill, not the full content. This is important later."* ## [02:02] Prioritätsregeln und Namenskonflikte Das Klonen eines Repositorys, das eigene Fähigkeiten mitbringt, kann Namenskollisionen verursachen. Claude löst sie mit einer festen Prioritätsleiter: Enterprise (höchste) → persönlich → Projekt → Plugins (niedrigste). Eine Enterprise-Fähigkeit `code-review` setzt sich immer gegen eine gleichnamige persönliche Fähigkeit durch. Die praktische Lösung ist beschreibendes Benennen: `security-review` oder `frontend-pr-review` statt des generischen `review`, damit Konflikte erst gar nicht entstehen. > *"If your company has an enterprise code review skill and you create a personal code review skill, the enterprise version of that takes precedence."* ## [02:52] Fähigkeiten aktualisieren und entfernen Eine Fähigkeit zu aktualisieren bedeutet, die SKILL.md direkt zu bearbeiten und zu speichern. Eine Fähigkeit zu entfernen bedeutet, das Verzeichnis zu löschen. Beide Vorgänge erfordern einen Neustart von Claude Code, damit die Änderung wirksam wird — die Fähigkeitenliste wird einmalig beim Sitzungsstart aufgebaut und nicht auf Live-Änderungen überwacht. > *"Edit the skill.md file to update a skill and restart Claude Code for changes to take effect."* ## Entitäten - **Anthropic-Tutorial-Erzähler** (Person): einziger Moderator des Skill-Erstellungs-Tutorials in der Claude Code skills-Serie - **Claude Code** (Software): Anthropics CLI für Claude; scannt Fähigkeiten beim Start und wendet sie an, wenn Benutzeranfragen zu den Fähigkeitsbeschreibungen passen - **SKILL.md** (Konzept): die einzige Datei, die eine Fähigkeit definiert — enthält ein YAML-Frontmatter (name, description) und freien Anweisungstext nach dem zweiten `---`-Trennzeichen - **Fähigkeiten** (Konzept): wiederverwendbare, benannte Anweisungssets, die Claude ein konsistentes Verhaltensmuster beibringen; als Verzeichnisse mit einer SKILL.md-Datei gespeichert - **Enterprise-Fähigkeiten** (Konzept): von der Organisation verwaltete Fähigkeiten, die an der Spitze der vierstufigen Prioritätsreihenfolge stehen und persönliche, Projekt- und Plugin-Fähigkeiten überschreiben - **Anthropic** (Organisation): Schöpfer von Claude und Claude Code; veröffentlicht diese Tutorial-Serie unter claude.com/resources/courses

Claude Code bietet Entwicklern fünf verschiedene Anpassungsmöglichkeiten — Skills, CLAUDE.md, Subagenten, Hooks und MCP-Server — jede für einen anderen Zweck gebaut. Dieses dreiminütige Tutorial ordnet jede Option dem richtigen Anwendungsfall zu, damit man nicht zu Skills greift, wo CLAUDE.md ausreicht, oder einen Hook verdrahtet, wo eigentlich ein Subagent gefragt ist. ## [00:02] Fünf Anpassungsoptionen, eine Entscheidungsfrage Claude Code stellt fünf Wege bereit, das Verhalten zu gestalten: Skills, CLAUDE.md, Subagenten, Hooks und MCP-Server. Der Sprecher listet alle fünf in rascher Folge auf und verlagert die Frage sofort von „Was sind das?" zu „Welches gehört hierher?" > *"Sie lösen unterschiedliche Probleme. Zu wissen, wann man welches einsetzt, verhindert, dass man das Falsche baut."* Alles Weitere im Tutorial ist im Grunde die Antwort auf diesen einen Satz. ## [00:18] CLAUDE.md vs Skills: dauerhaft vs bei Bedarf CLAUDE.md ist eine Datei, die Claude zu Beginn jedes Gesprächs liest — ohne Aktivierung. Hier gehören projektweite Vorgaben hin, die nie vergessen werden dürfen: Framework-Entscheidungen, Codierungsstil, Datenbankregeln. Skills hingegen laden bei Bedarf: Die PR-Review-Checkliste gelangt erst dann in den Kontext, wenn wirklich um ein Review gebeten wird — nicht schon beim Schreiben von neuem Code. > *"Use Claude MD for project-wise standards that always apply constraints like never modify the database schema, framework preferences, and coding style."* Die Trennlinie liegt zwischen Dauerhaftigkeit und Relevanz. Wenn eine Anweisung für jeden Prompt im Projekt gelten muss, gehört sie in CLAUDE.md. Ist sie nur manchmal nützlich, gehört sie in eine Skill. ## [01:03] Skills vs Subagenten: geteilter Kontext vs isolierte Ausführung Skills injizieren Wissen in das laufende Gespräch — ihre Anweisungen fügen sich dem vorhandenen Kontext hinzu. Subagenten arbeiten anders: Sie erhalten eine Aufgabe, starten einen separaten Ausführungskontext, arbeiten unabhängig und liefern Ergebnisse zurück, ohne das Hauptgespräch zu berühren. > *"Use sub agents when you want to delegate a task to a separate execution context. You need different tool access that the main conversation does. You want isolation between delegated work and your main context."* Skills kommen zum Einsatz, wenn Fachwissen das Denken von Claude durch ein laufendes Gespräch hindurch prägen soll. Subagenten wählt man, wenn eine klare Grenze zwischen der Hauptsitzung und einer delegierten Arbeitseinheit gewünscht ist — andere Werkzeuge, kein Kontextverlauf. ## [01:42] Hooks vs Skills: ereignisgesteuert vs anforderungsgesteuert Hooks lösen bei Ereignissen automatisch aus — ein Linter läuft jedes Mal, wenn Claude eine Datei speichert; eine Eingabe wird vor einem bestimmten Werkzeugaufruf geprüft. Nicht die Frage löst sie aus, sondern das Handeln von Claude. Skills sind das Gegenteil: anforderungsgesteuert, sie werden aktiv, wenn eine Anfrage zu ihnen passt. > *"A hook might run a llinter every time Claude saves a file or validate input before certain tool calls. They're all event driven, while skills, they're request driven. They activate based on what you're asking."* Muss ein Verhalten bedingungslos bei einem Systemereignis eintreten, ist es ein Hook. Soll es die Art beeinflussen, wie Claude auf eine Frage antwortet, ist es eine Skill. ## [02:15] Alle fünf kombiniert für umfassende Anpassung Ein gut konfiguriertes Claude Code-Setup weist jedem Werkzeug seine natürliche Rolle zu: CLAUDE.md für dauerhaft gültige Projektstandards, Skills für aufgabenspezifisches Fachwissen, das nicht jeden Prompt belasten soll, Hooks für automatisierte Nebeneffekte, Subagenten für isolierte delegierte Arbeit und MCP-Server für den Zugriff auf externe Werkzeuge. Sie sind keine Alternativen — sie ergänzen sich. > *"Don't force everything into skills when another option fits best. You can use multiple at a time."* Skills aktivieren sich automatisch, wenn ein Thema relevant ist; CLAUDE.md ist stets präsent; Subagenten laufen isoliert; Hooks feuern bei Ereignissen; MCP stellt externe Werkzeuge bereit. Das richtige Layer für jedes Anliegen wählen und alles frei kombinieren. ## Entitäten - **Anthropic Tutorial-Sprecher** (Person): Moderator dieser Claude Code Skills-Tutorial-Reihe, der im Namen von Anthropic präsentiert. - **Claude Code** (Software): Anthropics KI-gestützter Coding-Assistent; Thema der Tutorial-Reihe. - **Skills** (Konzept): Bedarfsgesteuerte Wissenspakete, die aktiviert werden, wenn Claude eine Benutzeranfrage abgleicht; sie injizieren Anweisungen in den aktuellen Gesprächskontext. - **CLAUDE.md** (Konzept): Konfigurationsdatei, die automatisch in jedes Claude Code-Gespräch geladen wird; dient dauerhaft gültigen projektweiten Standards und Vorgaben. - **Subagenten** (Konzept): Separate Ausführungskontexte, die gestartet werden, um delegierte Aufgaben isoliert vom Hauptgespräch zu bearbeiten. - **Hooks** (Konzept): Ereignisgesteuerte Automatisierung, die bei bestimmten Claude-Aktionen wie Datei speichern oder Werkzeugaufrufen anspringt — unabhängig von Benutzeranfragen. - **MCP-Server** (Software): Model Context Protocol-Server, die Claude Code-Sitzungen mit externen Werkzeugen versorgen. - **Anthropic** (Organisation): Entwickler von Claude Code und Herausgeber der Claude Code Skills-Tutorial-Reihe.