Dieses Dokument begleitet die Präsentation "Claude Code Features — Agentic Coding SKILLS". Es enthält pro Slide ausführliche Speaker Notes, Hintergrundwissen und Talking Points, damit du auch bei Nachfragen sicher bist.
Was du sagst (ca. 1 Min.):
Willkommen. Wir reden heute über Claude Code — aber nicht als Tutorial. Wir wollen verstehen, wie man mit einem AI-Agent arbeitet. Claude Code ist mittlerweile ein mächtiges Tool geworden: Skills, Subagents, MCP Server, Hooks, Slash Commands, Output Styles, Memory Files. Das kann überwältigend wirken. Unser Ziel heute: Klarheit schaffen. Wann nutze ich was, und warum?
Hintergrund für dich:
Claude Code ist Anthropics CLI-Tool für agentic coding. Es wurde im Februar 2025 veröffentlicht und läuft direkt im Terminal. Im Gegensatz zu Chat-basierten AI-Tools (wie ChatGPT oder Claude.ai) arbeitet Claude Code direkt in deinem Dateisystem: Es kann Dateien lesen, schreiben, Bash-Befehle ausführen, und mit externen Tools interagieren. Es ist kein Copilot-Autocomplete — es ist ein Agent, der selbstständig Aufgaben ausführt.
Was du sagst (ca. 30 Sek.):
Kurzer Überblick, was wir durchgehen. Wir starten mit dem Mindset-Unterschied zwischen Vibe Coding und Agentic Coding. Dann die vier Grundbausteine — Prompt, Context, Model, Tools. Was ein Agent Harness ist. Dann der praktische Teil: Welches Feature wann. Und zum Schluss: Warum es Skills gibt und warum nicht einfach alles MCP ist.
Was du sagst (ca. 3–4 Min.):
Bevor wir Features besprechen, müssen wir über den Unterschied zwischen zwei Arbeitsweisen reden, die von außen gleich aussehen — aber fundamental anders sind.
Vibe Coding — der Begriff stammt von Andrej Karpathy (Anfang 2025). Er hat das so beschrieben: Du gibst einem AI-Tool einen Prompt, akzeptierst was rauskommt, und "vibest" dich durch den Code. Copy-Paste aus dem Chat, hoffen dass es funktioniert, bei Fehlern den Error zurück in den Chat werfen. Für Prototypen und Demos ist das völlig okay. Aber: Du hast keine Kontrolle darüber, was der Agent tut, welchen Kontext er nutzt, und ob das Ergebnis reproduzierbar ist.
Agentic Coding ist das Gegenteil. Du verstehst die Mechanik. Du weißt, welcher Prompt welches Verhalten auslöst. Du managst aktiv, was im Context Window landet. Du wählst bewusst das richtige Modell und die richtigen Tools. Du bist der Pilot, nicht der Passagier.
Der entscheidende Punkt: Vibe Coding skaliert nicht. Wenn du in einem Team arbeitest, wenn du reproduzierbare Ergebnisse brauchst, wenn du Production-Code schreibst — dann musst du verstehen, was unter der Haube passiert. Und dafür sind die Features da, die wir heute besprechen.
Hintergrund für dich:
- Andrej Karpathy ist Ex-Tesla-AI-Chef und OpenAI-Gründungsteam. Sein "Vibe Coding"-Tweet ging viral. Er meinte es ursprünglich positiv (Spaß am Experimentieren), aber der Begriff wird heute oft genutzt um unkontrolliertes AI-gestütztes Programmieren zu beschreiben.
- Der Kern-Unterschied: Bei Vibe Coding behandelst du den Agent als Black Box. Bei Agentic Coding verstehst du die Inputs (Prompt, Context) und steuerst die Outputs bewusst.
- Konkretes Beispiel für die Diskussion: Wenn jemand fragt "Was ist so schlimm an Vibe Coding?" — der Punkt ist nicht, dass es schlecht ist. Es hat seinen Platz. Aber sobald du im Team arbeitest, Code Reviews machst, oder Code deployst, brauchst du Reproduzierbarkeit. Und die bekommst du nur, wenn du die Mechanik verstehst.
Mögliche Frage aus dem Publikum: "Ist das nicht dasselbe wie der Unterschied zwischen einem Junior und einem Senior?" → Guter Vergleich! Ja, im Prinzip. Ein Senior versteht warum etwas funktioniert. Ein Junior kopiert Pattern die funktionieren. Der Unterschied ist, dass selbst Seniors zu Juniors werden können, wenn sie die Agent-Mechanik nicht verstehen.
Was du sagst (ca. 4–5 Min.):
Jeder Agent — egal ob Claude Code, Cursor, Windsurf, GitHub Copilot — basiert auf genau vier Bausteinen. Wenn du diese vier verstehst, verstehst du jedes Feature, das diese Tools jemals bauen werden.
1. Prompt — Deine Anweisung. Das ist das wichtigste Element. Alles andere drumherum — Skills, Commands, Agents — am Ende wird daraus ein Prompt generiert, der an das Modell geschickt wird. Es sind Tokens rein, Tokens raus. Wenn du lernst, gute Prompts zu schreiben, kannst du jedes Feature nutzen. Wenn nicht, hilft dir kein Feature.
2. Context — Was der Agent "weiß". Das Context Window ist das Arbeitsgedächtnis des Modells. Alles was der Agent sehen kann — dein Code, deine CLAUDE.md, die Chat-History, geladene Dateien — das ist der Kontext. Er ist begrenzt (bei Claude typischerweise 200k Tokens). Wenn dein Kontext voll ist oder verrauscht, wird die Antwort schlechter. Context Management ist eine der wichtigsten Skills im Agentic Coding.
3. Model — Welches Modell läuft. Claude Sonnet ist schnell und günstig, gut für Routine-Tasks. Claude Opus ist langsamer aber tiefgründiger, gut für komplexe Architekturentscheidungen. Die Wahl des Modells beeinflusst direkt die Qualität.
4. Tools — Die Hände des Agents. Was kann er tun? Bash-Befehle ausführen, Dateien lesen und schreiben, Web-Suchen machen, MCP Server aufrufen. Ohne Tools ist der Agent nur ein Textgenerator. Mit Tools wird er zum Akteur.
Hintergrund für dich:
- Context Window erklärt: Stell dir das Context Window wie einen Schreibtisch vor. Je mehr Papiere (Tokens) drauf liegen, desto schwerer findet der Agent das Relevante. Ein 200k-Token-Window klingt riesig, aber eine mittelgroße Codebase füllt das schnell. Deshalb ist Context-Effizienz so wichtig — und genau da setzen Skills an (dazu kommen wir).
- Token-Zahlen als Referenz: Ein durchschnittliches Wort ≈ 1.3 Tokens. 200k Tokens ≈ 150k Wörter ≈ ca. 300 Seiten Text. Klingt viel, aber wenn du 10 Source Files à 500 Zeilen lädst, bist du schon bei 50k+ Tokens nur für den Code.
- CLAUDE.md ist eine spezielle Datei im Repository-Root, die Claude Code automatisch liest. Dort kannst du projektspezifische Anweisungen hinterlegen (Coding Conventions, Architektur-Regeln, etc.). Das ist ein Schlüssel-Feature für Teams.
- Warum "Core 4": Dieses Framing kommt aus der Agentic Coding Community. Die Idee: Wenn du diese vier Dimensionen bewusst steuerst, hast du volle Kontrolle über den Output. Jedes Feature das ein Tool-Hersteller baut, ist nur eine Abstraktion über eine oder mehrere dieser vier Dimensionen.
Mögliche Frage: "Welches Modell soll ich für was nehmen?" → Sonnet für: Routine-Coding, Tests schreiben, Refactoring, schnelle Iterationen. Opus für: Architekturentscheidungen, komplexe Debugging-Sessions, wenn du einen "Senior-Engineer-Blick" brauchst. Haiku für: einfache Tasks, Formatierung, schnelle Checks. Im Zweifel: Start mit Sonnet, eskaliere zu Opus wenn die Ergebnisse nicht passen.
Was du sagst (ca. 3 Min.):
Das ist die wichtigste Folie der Präsentation. Merkt euch das: Der Prompt ist die fundamentale Einheit. Alles andere baut darauf auf.
Schaut euch die Hierarchie an. Ganz unten: der Prompt. Das ist ein reiner Text, den ihr an das Modell schickt. Ein Slash Command ist ein gespeicherter, wiederverwendbarer Prompt — mit einem Namen, den ihr per /mein-command aufrufen könnt. Ein Subagent ist ein Prompt, der in einem eigenen, isolierten Context Window läuft. Und ein Skill ist eine Sammlung von Prompts, Ressourcen und Konfiguration, die der Agent automatisch erkennt und aktiviert.
Die Empfehlung: Startet immer mit einem Prompt. Baut erst dann einen Slash Command, wenn ihr den Prompt mehr als dreimal benutzt habt. Baut erst dann einen Skill, wenn ihr mehrere verwandte Commands habt, die zusammen ein Problem-Set lösen. Verkompliziert nicht zu früh.
Hintergrund für dich:
- Slash Command konkret: In Claude Code sind Custom Slash Commands Markdown-Dateien im
.claude/commands/-Verzeichnis deines Projekts. Wenn du/mein-commandtippst, wird der Inhalt dieser Datei als Prompt an den Agent geschickt. Einfacher geht's nicht. Beispiel: Eine Datei.claude/commands/commit.mdmit dem Inhalt "Analysiere die staged changes und schreibe eine konventionelle Commit-Message" — fertig ist dein/commit-Command. - Warum "Primitive" wichtig: In der Softwareentwicklung ist ein Primitiv die kleinste, nicht weiter zerlegbare Einheit. Integer, String, Boolean — das sind Primitive. Der Prompt ist das Primitiv des Agentic Coding. Wenn du die Primitive nicht beherrschst, helfen dir die Abstraktionen nicht.
- Composability-Kette im Detail:
- Ein Skill kann Slash Commands aufrufen (per
slash_command_tool) - Ein Skill kann MCP Server nutzen
- Ein Skill kann Subagents delegieren
- Ein Slash Command kann ebenfalls Skills triggern, MCP nutzen, Subagents starten
- Ein Subagent kann Slash Commands aufrufen
- Aber: Ein Subagent kann KEINEN weiteren Subagent starten (keine Verschachtelung)
- Ein Skill kann Slash Commands aufrufen (per
- Praktischer Tipp für die Diskussion: "Wenn ihr morgen anfangt, baut euch drei Slash Commands für eure häufigsten Tasks. Das allein wird euren Workflow sofort verbessern. Skills könnt ihr später einführen."
Was du sagst (ca. 3 Min.):
Claude Code ist mehr als ein Chat-Interface. Es ist ein Agent Harness — eine Runtime-Umgebung, die einen AI-Agent mit Fähigkeiten ausstattet und orchestriert.
Was heißt das konkret? Der Agent allein — das Claude-Modell — kann nur Text generieren. Aber Claude Code gibt ihm Hände: Er kann Bash-Befehle ausführen, Dateien lesen und schreiben, MCP Server aufrufen. Und mit den neueren Features kommen noch mehr Fähigkeiten dazu: Skills als wiederverwendbare Expertise, Subagents für parallele Arbeit, Hooks für deterministische Automatisierung.
Das Harness ist das Bindeglied. Es entscheidet: Welches Tool wird aufgerufen? Welcher Kontext wird geladen? Welcher Prompt wird generiert? Der Agent operiert innerhalb der Regeln, die das Harness vorgibt.
Denkt daran wie ein Cockpit. Das Modell ist der Pilot. Das Harness ist das Flugzeug mit all seinen Instrumenten und Systemen. Und ihr seid der Fluglotse, der die Richtung vorgibt.
Hintergrund für dich:
- Agent Harness als Konzept: Der Begriff kommt aus der AI-Engineering-Community. Ein Harness (wörtlich: Geschirr, Gurt) ist die Infrastruktur, die einen "nackten" Language Model in einen handlungsfähigen Agent verwandelt. Andere Harnesses sind z.B. LangChain, CrewAI, AutoGPT — aber Claude Code ist speziell für Software Engineering optimiert.
- Welche Tools hat Claude Code konkret?
- Bash Tool: Führt Shell-Befehle aus (git, npm, docker, etc.)
- File Read/Write: Kann Dateien im Dateisystem lesen und editieren
- MCP Server: Verbindung zu externen Diensten (Datenbanken, APIs, Jira, Slack, etc.)
- Subagent Tool: Delegiert Tasks an isolierte Agent-Instanzen
- Slash Command Tool: Ruft gespeicherte Prompts auf
- Web Search: Sucht im Internet nach Informationen
- Hooks erklärt: Hooks sind deterministische Automatisierungen, die an bestimmten Lifecycle-Events von Claude Code hängen. Beispiel: "Nach jedem Tool-Call, prüfe ob der Agent eine Datei außerhalb des Projektverzeichnisses editieren will und verhindere das." Hooks sind KEIN AI — sie sind klassischer Code, der an definierten Punkten ausgeführt wird. Das ist wichtig, weil es Determinismus in einen stochastischen Prozess bringt.
- Memory Files (CLAUDE.md): Claude Code liest automatisch
CLAUDE.mdim Projekt-Root und in Unterverzeichnissen. Dort definierst du: Coding Conventions, Tech Stack, Architektur-Entscheidungen, Team-Regeln. Das ist der "persistente Kontext" — bei jedem Start wird er geladen.
Mögliche Frage: "Was ist der Unterschied zwischen Claude Code und Cursor/Copilot?" → Cursor und Copilot sind IDE-integriert (VSCode etc.) und fokussieren auf Code-Completion und Chat. Claude Code ist Terminal-first und Agent-first: Es führt selbstständig Multi-Step-Tasks aus, erstellt Dateien, committet, testet. Es ist weniger "Autocomplete" und mehr "autonomer Engineering-Partner". Cursor hat mittlerweile auch Agent-Features, aber Claude Code war dafür von Anfang an designt.
Was du sagst (ca. 3 Min.):
Diese Tabelle orientiert sich an IndyDevDan's Vergleich — sie zeigt alle 12 relevanten Dimensionen. Ich habe sie auf zwei Slides aufgeteilt: erst die Eigenschaften, dann die Composability.
Triggered By: Skills werden rein vom Agent getriggert — das ist ihr Alleinstellungsmerkmal. MCP und Subagents können beides: vom Agent automatisch oder manuell. Slash Commands triggert ausschließlich der Engineer per /mein-command.
Context Efficiency — der rote Punkt bei MCP. Das ist DER Schwachpunkt von MCP. MCP Server laden beim Start ALLE Tool-Definitionen ins Context Window. Bei 5 Servern mit je 20 Tools sind das 100 Tool-Definitionen im Kontext bevor du anfängst. Skills lösen das mit Progressive Disclosure.
Context Persistence: Subagents sind der Ausreißer — ihr Kontext geht nach dem Task verloren. Das ist gewollt (Isolation), aber man muss es wissen.
Parallelizable: Nur Subagents. Wenn ihr "parallel" denkt, denkt Subagent. Kein anderes Feature kann das.
Modularity: Skills und MCP sind beide "High" — aber auf verschiedene Art. Skills durch ihre Dateistruktur, MCP durch die Server-Architektur.
Was du sagst (ca. 3 Min.):
Hier wird's spannend. Diese Slide zeigt, was was benutzen kann.
Tool Permissions: MCP hat als einziges KEINE Tool Permissions. Das heißt: MCP-Tools laufen ohne explizite Erlaubnis-Abfrage. Skills, Subagents und Slash Commands können dagegen kontrollieren, welche Tools der Agent nutzen darf.
Can Use Skills: Das "Kind of" bei MCP ist wichtig. MCP Server können nicht direkt Skills aufrufen — aber wenn ein MCP-Tool-Call im Kontext eines Agents stattfindet, der Skills hat, kann der Agent danach einen Skill triggern. Es ist also indirekt möglich, aber kein First-Class-Support.
Can Use Subagents: Subagents können KEINE weiteren Subagents starten. Das ist eine bewusste Beschränkung. Wenn ein Subagent einen weiteren Subagent starten könnte, hättest du unkontrollierte Rekursion. Alle anderen Features können Subagents delegieren.
Die Key Insight unten fasst es zusammen: Skills stehen an der Spitze der Kompositions-Hierarchie. Sie können alles nutzen — Prompts, MCP, Subagents, andere Skills. Das macht sie zum mächtigsten Feature, aber auch zum aufwändigsten.
Hintergrund für dich:
-
Progressive Disclosure im Detail — die drei Ebenen:
- Metadata-Ebene: Der Agent sieht nur Name + Beschreibung des Skills (ca. 1–2 Sätze). Das reicht um zu entscheiden "ist das relevant?"
- SKILL.md-Ebene: Der Agent liest die Haupt-Anleitung. Hier stehen Instruktionen, Workflows, Regeln. Vielleicht 500–2000 Tokens.
- Ressourcen-Ebene: Der Agent lädt zusätzliche Dateien — Beispiel-Code, Templates, Konfigurationen. Nur wenn wirklich gebraucht. Das ist wie ein Buch: Du liest erst den Klappentext, dann das Inhaltsverzeichnis, dann das relevante Kapitel. Nicht sofort das ganze Buch.
-
MCP Context-Problem quantifiziert: Ein typischer MCP Server (z.B. Postgres MCP) hat ~15 Tools. Jedes Tool hat eine JSON-Schema-Definition mit Name, Beschreibung, Parametern. Das sind leicht 200–500 Tokens pro Tool. Bei 15 Tools: 3.000–7.500 Tokens. Bei 5 Servern: 15.000–37.500 Tokens — nur für Tool-Definitionen! Das ist 5–10% deines gesamten Context Windows, verbraucht bevor du anfängst zu arbeiten.
-
Subagent-Context-Isolation erklärt: Ein Subagent bekommt ein eigenes, frisches Context Window. Er sieht NICHT die History deines Haupt-Agents. Du gibst ihm einen konkreten Auftrag, er erledigt ihn, und gibt dir das Ergebnis zurück. Der Nachteil: Alles was er zwischendurch "gelernt" hat (Kontext, Entscheidungen), geht verloren. Du bekommst nur das finale Ergebnis.
-
Tool Permissions erklärt: Claude Code fragt standardmäßig nach Erlaubnis bevor es bestimmte Tools ausführt (z.B. Bash-Commands, Datei-Writes). Skills, Subagents und Slash Commands können in ihrer Konfiguration definieren, welche Tools "auto-approved" sind. MCP-Tools haben diesen Mechanismus nicht — sie laufen wenn aufgerufen. Das ist ein Sicherheitsaspekt, den man bei der Wahl bedenken sollte.
-
Warum Subagents keine Subagents starten: Das ist eine Schutzmaßnahme gegen unkontrollierte Rekursion und Kosten-Explosion. Stell dir vor: Agent startet Subagent, der startet Subagent, der startet Subagent... Jeder mit eigenem Context Window, eigenen API-Calls. Die Kosten und Komplexität würden exponentiell wachsen.
Mögliche Frage: "Wenn Skills so toll sind, warum nicht alles als Skill bauen?" → Overhead. Ein Skill braucht eine Verzeichnisstruktur, eine SKILL.md, durchdachte Beschreibungen. Für einen einfachen "schreib mir eine Commit Message"-Task ist das Overkill. Slash Commands sind schneller erstellt und direkt nutzbar. Die Regel: Wenn es ein einzelner, wiederkehrender Task ist → Slash Command. Wenn es ein ganzes Problem-Set mit mehreren verwandten Tasks ist → Skill.
Was du sagst (ca. 3–4 Min.):
Lasst uns das an konkreten Beispielen durchgehen.
PDF-Daten automatisch extrahieren → Skill. Warum? Das Keyword ist "automatisch". Ihr wollt, dass der Agent von selbst erkennt: "Ah, da ist ein PDF, ich weiß wie ich damit umgehe." Ein Skill mit Instruktionen zur PDF-Verarbeitung wird automatisch aktiviert.
Jira anbinden → MCP. Klarer Fall. Jira ist ein externer Dienst mit einer API. MCP Server sind genau dafür da: Externe Datenquellen und APIs anbinden.
Security Audit → Subagent. Ein Audit ist aufwändig, erzeugt viel Output, und ihr wollt euren Haupt-Kontext nicht damit zuballern. Außerdem könnt ihr mehrere Audit-Subagents parallel laufen lassen (einer für Dependencies, einer für Code-Patterns, einer für Config-Files).
Commit Message → Slash Command. Einfacher Task, manuell getriggert, one-shot. Perfekt für /commit.
Style-Guide Violations → Skill. Wiederkehrendes Verhalten. Der Agent soll bei jedem Code-Review automatisch euren Style-Guide anwenden. Dafür braucht er ein Skill mit euren Regeln, Beispielen, und Korrekturen.
React-Komponente erstellen → Slash Command. Einmaliger Generierungs-Task. /create-component mit eurem Template und euren Conventions.
Hintergrund für dich:
-
Entscheidungsbaum — einfach zu merken:
- Ist es eine externe API/Datenquelle? → MCP
- Brauche ich parallele Ausführung oder isolierten Kontext? → Subagent
- Soll der Agent das automatisch tun, und es gibt mehrere verwandte Tasks? → Skill
- Ist es ein einzelner, manueller Task? → Slash Command
- Unsicher? → Start mit einem Slash Command. Upgrade später.
-
Git Work Trees als durchgängiges Beispiel: Das Beispiel aus dem Video ist gut um den Unterschied zu zeigen:
- Work Tree erstellen = einzelner Task → Slash Command (
/create-worktree) - Work Trees erstellen, verwalten, mergen, entfernen, auflisten = Problem-Set → Skill
- 3 Work Trees gleichzeitig aufsetzen = parallel → Subagent (der intern den Slash Command nutzt)
- Work Tree erstellen = einzelner Task → Slash Command (
-
Hooks nicht vergessen: Hooks passen in keines der vier Felder, weil sie deterministisch sind (kein AI). Beispiele für Hooks:
- "Nach jedem Claude Code-Run: Führe den Linter aus"
- "Vor jedem Commit: Prüfe ob CLAUDE.md aktuell ist"
- "Wenn der Agent eine Migration-Datei erstellt: Führe
php bin/console doctrine:schema:validateaus" Hooks sind quasi eure CI/CD-Pipeline innerhalb von Claude Code.
Was du sagst (ca. 4 Min.):
Das ist die Kernfrage, die viele stellen: "Warum brauchen wir Skills? Wir haben doch MCP."
Problem 1: Context Window Explosion. Das habe ich vorhin schon angesprochen. MCP Server laden beim Start alles rein. Bei vielen Teams, die mehrere Server nutzen — Postgres, Jira, Slack, GitHub — ist ein signifikanter Teil des Context Windows schon verbraucht bevor die eigentliche Arbeit beginnt.
Skills lösen das mit Progressive Disclosure. Drei Ebenen: Der Agent sieht erst die Metadata — einen Satz Beschreibung. Dann, nur wenn relevant, die SKILL.md mit den eigentlichen Instruktionen. Und erst wenn nötig, die zusätzlichen Ressourcen. Das ist wie ein Arzt, der erst die Symptome hört, dann das Lehrbuch-Kapitel nachschlägt, und erst dann den Spezialisten hinzuzieht.
Problem 2: MCP hat keine Struktur für Domain-Wissen. MCP ist fantastisch für API-Calls — "hole mir die offenen Tickets aus Jira", "führe diese SQL-Query aus". Aber wenn du dem Agent beibringen willst wie er arbeiten soll — Best Practices, Workflows, Entscheidungslogik — dann fehlt dir bei MCP die Struktur dafür. Skills haben ein eigenes Verzeichnis mit Platz für Anleitungen, Beispiele, Templates, Skripte.
Problem 3: MCP ist nicht Agent-First. MCP wartet passiv darauf aufgerufen zu werden. Skills werden aktiv vom Agent erkannt und genutzt. Der Agent liest die Skill-Beschreibung und entscheidet: "Das passt zu dem was ich gerade tun soll." Das ist ein fundamentaler Unterschied in der Architektur.
Aber — und das ist wichtig: Skills ersetzen MCP nicht. Skills nutzen MCP. Ein Skill für "Datenbank-Management" könnte intern den Postgres-MCP-Server aufrufen. Die Skill-Ebene fügt dem die Orchestrierung hinzu: Wann welche Query, welche Checks vorher, welche Validierung nachher.
Hintergrund für dich:
- MCP (Model Context Protocol) erklärt: MCP ist ein offener Standard, den Anthropic Ende 2024 veröffentlicht hat. Es definiert, wie AI-Agents mit externen Tools kommunizieren. Ein MCP Server ist ein kleiner Prozess, der eine API bereitstellt (Tools + Ressourcen), und der Agent kann diese Tools aufrufen. Beispiel: Der Postgres-MCP-Server bietet Tools wie
query,list_tables,describe_table. - Warum MCP trotzdem wichtig bleibt: MCP ist das Standard-Protokoll. Es funktioniert Tool-übergreifend (Claude Code, Cursor, Zed, etc.). Skills sind Claude-Code-spezifisch. Wenn du ein Tool baust, das in vielen Agents funktionieren soll, baust du einen MCP Server. Wenn du Expertise für deinen spezifischen Workflow in Claude Code kapseln willst, baust du einen Skill.
- Progressive Disclosure — technisch: Im Dateisystem sieht ein Skill so aus:
Der Agent lädt bei Boot nur.claude/skills/mein-skill/ ├── SKILL.md ← Haupt-Instruktionen (Ebene 2) ├── metadata.json ← Name + Beschreibung (Ebene 1) ├── templates/ ← Zusätzliche Ressourcen (Ebene 3) ├── examples/ ← Beispiel-Code (Ebene 3) └── scripts/ ← Hilfs-Skripte (Ebene 3)metadata.json. Erst bei Aktivierung liest erSKILL.md. Und erst bei Bedarf greift er auftemplates/,examples/,scripts/zu.
Mögliche Frage: "Soll ich jetzt alle meine MCP Server durch Skills ersetzen?" → Nein! MCP Server und Skills haben verschiedene Aufgaben. MCP = Zugang zu externen APIs und Datenquellen. Skills = wiederverwendbare Workflows und Expertise. Am besten: Skills, die MCP Server nutzen. Beispiel: Ein "Database Migration Skill" der den Postgres-MCP-Server aufruft, aber zusätzlich Validierungen, Rollback-Strategien und Naming-Conventions mitbringt.
Was du sagst (ca. 3–4 Min.):
Jetzt wird's praktisch. Wann baue ich einen Skill und wann nicht?
Falsch: Einen Skill bauen, um Git Work Trees zu erstellen. Das ist ein einzelner Task. Ein Slash Command reicht. /create-worktree main feature-x — fertig. Wenn du dafür einen Skill baust, hast du Overhead ohne Mehrwert.
Richtig: Einen Skill bauen, um Git Work Trees zu managen. Erstellen, auflisten, Ports zuweisen, Environment-Variablen setzen, mergen, aufräumen. Das ist ein Problem-Set mit mehreren verwandten Operationen. Hier lohnt sich die Investition in einen Skill.
Die Faustregel: Ein Skill lohnt sich, wenn ein einzelner Prompt nicht reicht. Wenn du merkst, dass du immer wieder verwandte Commands brauchst, die zusammen ein Domänen-Problem lösen — dann ist es Zeit für einen Skill.
Und der Entscheidungsweg ist immer derselbe: Start mit einem Prompt. Brauche ich Parallelisierung? → Subagent. Viele verwandte Tasks? → Skill. Externe API? → MCP.
Hintergrund für dich:
-
Skill-Anatomie — was gehört rein:
- SKILL.md: Die "Bedienungsanleitung". Hier steht: Was kann dieser Skill? Welche Operationen unterstützt er? Welche Regeln gelten? Welche Schritte werden in welcher Reihenfolge ausgeführt?
- Ressourcen: Templates, Beispiel-Code, Konfigurationsdateien, Skripte. Alles was der Agent braucht, um den Job zu erledigen.
- Metadata: Name und Beschreibung. Die Beschreibung ist kritisch — sie entscheidet, ob der Agent den Skill findet und aktiviert.
-
Composability in der Praxis: Ein gut gebauter Skill nutzt die anderen Features:
Work Tree Manager Skill ├── Nutzt Slash Commands: /create-worktree, /list-worktrees ├── Nutzt MCP: Git-MCP für Branch-Operationen ├── Nutzt Subagents: Für paralleles Setup mehrerer Trees └── SKILL.md: Orchestriert alles, definiert WorkflowsDer Skill ist der Manager. Die anderen Features sind die Arbeiter.
-
Kritik an Skills (Fair & Balanced): Skills sind kein perfektes Feature. Berechtigte Kritikpunkte:
- Keine native Verschachtelung von Prompts/Subagents: Du kannst keinen
/commands/-Ordner innerhalb eines Skills haben. Du musst denslash_command_toolprogrammatisch aufrufen. - Reliabilität bei Verkettung: Wenn Skill A Skill B aufruft, der Skill C aufruft — wie zuverlässig ist das? Bei komplexen Ketten steigt die Fehlerwahrscheinlichkeit.
- Kein fundamentaler Neuheits-Wert: Technisch gesehen sind Skills "opinionierte Prompt-Engineering + Dateistruktur". Du konntest das vorher auch selbst bauen. Skills geben dir "nur" eine konventionalisierte Struktur dafür. Trotzdem: Die Konvention hat Wert. Genauso wie MVC kein neues Programmierparadigma war, aber trotzdem die Webentwicklung revolutioniert hat.
- Keine native Verschachtelung von Prompts/Subagents: Du kannst keinen
Mögliche Frage: "Wir haben schon Custom Slash Commands. Müssen wir jetzt alles zu Skills umbauen?"
→ Nein! Behalt deine Slash Commands. Skills sind für die nächste Stufe: Wenn du merkst, dass du 5+ verwandte Commands hast, die zusammen ein Problem-Set lösen, dann lohnt sich ein Skill. Aber einzelne Commands wie /commit, /test, /review — die sind perfekt als Slash Commands.
Was du sagst (ca. 2 Min.):
Fünf Dinge zum Mitnehmen.
Erstens: Agentic Coding heißt bewusste Steuerung. Prompt, Context, Model, Tools — wenn ihr diese vier Dimensionen versteht und managt, habt ihr die Kontrolle.
Zweitens: Startet immer mit einem Prompt. Ein Slash Command ist in 2 Minuten erstellt. Investiert nicht in Komplexität, bevor ihr wisst, dass ihr sie braucht.
Drittens: Skills sind für Problem-Sets, nicht für einzelne Tasks. Denkt an den Work-Tree-Manager: nicht "erstellen", sondern "erstellen, verwalten, aufräumen, mergen".
Viertens: MCP für externe APIs, Subagents für Isolation und Parallelisierung. Die Grenzen sind hier klar.
Fünftens: Skills sind kontext-effizient dank Progressive Disclosure. Das ist ihr größter technischer Vorteil gegenüber MCP.
Hintergrund für dich:
- Quick-Win für morgen: "Jeder erstellt bis morgen einen Custom Slash Command für seinen häufigsten Task." Das ist der niedrigschwelligste Einstieg. Eine Markdown-Datei in
.claude/commands/— fertig. - Team-Empfehlung: Startet ein Verzeichnis
.claude/commands/im Repo. Teilt Commands übers Team. Das ist der erste Schritt zu geteilter Agentic-Coding-Expertise. - Nächster Schritt nach diesem Talk: Wenn Interesse besteht, können wir einen Workshop machen wo wir gemeinsam einen Team-Skill bauen — z.B. für euren Review-Workflow oder euer Deployment.
Was du sagst (ca. 30 Sek.):
Das war der Überblick. Lasst uns darüber reden — was sind eure häufigsten Tasks? Wo seht ihr Potenzial für Commands oder Skills? Wer hat schon Erfahrung mit Claude Code und will teilen?
Hintergrund für dich:
Bereite für die Diskussion 2–3 konkrete Demos vor, falls das Gespräch ins Stocken gerät:
- Demo: Slash Command erstellen — Live einen
/commit-Command bauen und nutzen - Demo: CLAUDE.md — Zeigen wie Project-Context funktioniert
- Demo: Subagent — Einen parallelen Task delegieren und das Ergebnis zeigen
| Begriff | Erklärung |
|---|---|
| Agent | Ein AI-Modell + Tools + Kontext, das selbstständig Aufgaben ausführen kann |
| Context Window | Das "Arbeitsgedächtnis" des Modells — alles was es gleichzeitig sehen kann |
| Token | Die kleinste Texteinheit für das Modell (≈ 0.75 Wörter im Deutschen) |
| MCP | Model Context Protocol — offener Standard für Tool-Integrationen |
| Progressive Disclosure | Informationen werden schrittweise geladen, nicht alles auf einmal |
| Slash Command | Gespeicherter Prompt, aufrufbar per /name |
| Subagent | Agent-Instanz mit eigenem, isoliertem Context Window |
| Skill | Paket aus Instruktionen + Ressourcen für ein wiederkehrendes Problem-Set |
| Hook | Deterministischer Code, der an Lifecycle-Events von Claude Code hängt |
| CLAUDE.md | Projektspezifische Anweisungsdatei, automatisch gelesen von Claude Code |
| Harness | Die Runtime-Umgebung, die ein Modell zum handlungsfähigen Agent macht |
| Vibe Coding | Unkontrolliertes Arbeiten mit AI — Prompt rein, hoffen |
| Agentic Coding | Bewusstes Steuern von Prompt, Context, Model und Tools |