Modul 2

Der Claude-Code-Baukasten

Tag 1 · ca. 150 Minuten (zwei Blöcke)

Lernziel Modul 2

Der Teilnehmer kann jedes Claude-Code-Primitiv benennen, sein Einsatzgebiet erklären und weiß, welches Werkzeug für welchen Zweck gedacht ist.

Benennen · einordnen · abgrenzen. Bauen kommt an Tag 2 und 3.

Die neun Bausteine

CLAUDE.md

Dauerwissen, immer im Kontext

Rules

Wissen, das nur bei Bedarf lädt

Skills

Abrufbares Verfahren mit Anleitung

Commands vs. Skills

Der Unterschied, der am meisten verwirrt

Subagents

Arbeit in fremdem Kontext

Hooks

Deterministische Automatik

Output Styles

Wie geantwortet wird

MCP

Anschluss an fremde Systeme

Plugins

Das teilbare Bündel

Vier Fragen, neun Antworten

Alle Primitive beantworten genau eine von vier Fragen. Wer die Frage kennt, findet das Werkzeug — nicht umgekehrt.

Was soll er wissen?

CLAUDE.md, Rules — Wissen, das die Session überlebt.

Was soll er können?

Skills, Commands — wiederholbare Verfahren auf Abruf.

Wie soll er arbeiten?

Subagents, Hooks, Output Styles — Ausführung, Automatik, Form.

Woran soll er andocken?

MCP, Plugins — fremde Systeme und teilbare Bündel.

Jedes Primitiv ist eine Antwort auf stateless aus Modul 1: Was der Agent nicht behält, muss im Repo liegen — und dort so liegen, dass es zur richtigen Zeit im Kontext landet.

Wo das alles physisch liegt

projekt/ CLAUDE.md Projektwissen — immer geladen .mcp.json MCP-Server des Projekts .claude/ settings.json Permissions + Hook-Registrierung (im Repo) settings.local.json persönliche Ergänzung (nicht geteilt) rules/ *.md — laden je nach bearbeiteter Datei skills/<name>/SKILL.md commands/<name>.md agents/<name>.md Subagents
Verifiziert am Referenzprojekt cgsit-finance: CLAUDE.md im Repo-Wurzelverzeichnis, .mcp.json daneben, sowie .claude/settings.json, .claude/settings.local.json, .claude/rules/ (9 Dateien), .claude/skills/ (11 Skills, je SKILL.md), .claude/commands/ (4 Dateien), .claude/agents/ (3 Dateien). — geprüft am 2026-07-21

Was soll er wissen?

CLAUDE.md

Eine Markdown-Datei im Repo, die bei jedem Start automatisch in den Kontext geladen wird. Das Onboarding-Dokument für den neuen Kollegen aus Modul 1 — nur dass er es jeden Morgen neu liest.

Dafür gedacht

Build- und Testbefehle, Architekturüberblick, verbindliche Konventionen, Workflow-Regeln, Verweise auf tiefere Doku.

Dafür nicht

Alles, was nur selten gebraucht wird. Jede Zeile kostet in jeder Session Tokens — auch in denen, in denen sie niemanden interessiert.

Vertiefung in Modul 7: Aufbau, Umfang, Pitfalls — und wie man misst, ob sie überhaupt wirkt.

Rules — Wissen auf Zuruf

Regeldateien, die nicht immer geladen sind, sondern nur dann, wenn die Arbeit sie betrifft — typischerweise gesteuert über Datei-Muster im Kopf der Regeldatei.

Regeldatei (Beispiel)lädt beiInhalt
java-conventions.md**/*.javaSprach- und Stilkonventionen
migration-safety.md**/db/migration/**/V*.sqlRegeln für riskante DB-Migrationen
money-fx.md**/*Fx*.java, **/Currency*.java, …Geld-, Rundungs- und Währungsinvarianten
Aus cgsit-finance: 9 Dateien unter .claude/rules/, jede mit einem globs:-Eintrag im YAML-Frontmatter (Liste von Glob-Mustern). Die Zuordnung Datei → Globs ist zusätzlich in der CLAUDE.md tabelliert. — geprüft am 2026-07-21

Was soll er können?

Skills — ein Verfahren zum Nachschlagen

Ein Skill ist ein dokumentiertes Verfahren in einem eigenen Ordner: eine Beschreibung, wofür er da ist, plus die Anleitung, wie das Verfahren abläuft. Er liegt bereit — und wird geladen, wenn er gebraucht wird.

Beschreibung

Wofür ist der Skill da? Daran erkennt der Agent, ob er passt.

Anleitung

Die eigentlichen Schritte — so ausführlich wie nötig, ohne Kontextkosten im Normalfall.

Erlaubte Werkzeuge

Ein Skill kann einschränken, womit er arbeiten darf.

Aus cgsit-finance: Skills liegen als .claude/skills/<name>/SKILL.md mit YAML-Frontmatter; verwendete Schlüssel dort u. a. name, description, allowed-tools, argument-hint, user-invocable. Beispiel-Skills: rfcs, test, commit, architecture-reviewer. — geprüft am 2026-07-21

Commands vs. Skills

Command

Ich rufe etwas auf. Eine Textdatei, die ich per Schrägstrich-Aufruf als Prompt einsetze.

Immer von mir gestartet, nie vom Agenten. Kurz, ein Zweck, keine Auswahllogik.

Denkmodell: Tastenkürzel für einen Prompt.

Skill

Der Agent greift zu. Ein Verfahren mit Beschreibung, das der Agent selbst wählen kann — oder das ich anstoße.

Umfangreicher, mehrstufig, mit Regeln und Grenzen.

Denkmodell: Handbuch im Regal, mit Aufschrift auf dem Rücken.

Der Unterschied ist nicht die Mächtigkeit, sondern wer auslöst: Command = ich, immer. Skill = auch der Agent, wenn die Beschreibung passt.

Wie soll er arbeiten?

Subagents — Arbeit außer Haus

Ein Subagent bearbeitet eine abgegrenzte Aufgabe in einem eigenen Kontext und liefert nur das Ergebnis zurück. Der ganze Suchlärm bleibt draußen.

Auftrag
Subagent
eigener Kontext
nur das
Ergebnis

Dafür gedacht

Recherche, Testläufe mit viel Ausgabe, unabhängige Reviews, mehrere Perspektiven auf dieselbe Änderung.

Dafür nicht

Aufgaben, bei denen man den Weg mitlesen will — und alles, was den gesamten Gesprächsverlauf braucht. Der Subagent kennt ihn nicht.

Aus cgsit-finance: drei Subagent-Definitionen unter .claude/agents/researcher, code-reviewer, test-engineer. Der test-Skill lässt die Testausgabe bewusst im Subagenten laufen, damit sie nicht in den Hauptkontext gerät. — geprüft am 2026-07-21

Hooks — das Einzige, was sicher passiert

Ein Hook ist ein Programm, das an definierten Punkten des Ablaufs ausgeführt wird — vor oder nach einer Werkzeugnutzung. Es läuft immer, unabhängig davon, was das Modell gerade für richtig hält.

Regeln und Anweisungen sind Bitten an ein nicht-deterministisches Modell. Ein Hook ist Code. Was wirklich garantiert sein muss, gehört in einen Hook — nicht in einen weiteren Merksatz in der CLAUDE.md.

Dafür gedacht

Formatieren, Linten, verbotene Muster abfangen, Nachweise erzwingen, gefährliche Befehle stoppen.

Dafür nicht

Alles, was ein Urteil erfordert. Ein Hook prüft, dass etwas da ist — nicht, ob es gut ist. Und: jeder Fehlalarm erzieht zum Ignorieren.

Ein echtes Beispiel

Ausgangslage In cgsit-finance hängen die Freigabe-Gates eines Planungsdokuments an Disziplin: Status auf „Accepted" setzen darf nur, wer den Review auch dokumentiert hat. Disziplin ist beim nicht-deterministischen Agenten keine Zusicherung. Lehre: Aus der Bitte wurde ein Prüfprogramm, das nach jeder Dateiänderung läuft und ein fehlendes Nachweis-Artefakt zurückmeldet.
Verifiziert in cgsit-finance/.claude/settings.json: unter hooks registrierte Ereignisse PreToolUse (matcher Bash) und PostToolUse (matcher Edit|Write|MultiEdit), jeweils als Kommando python3 "$CLAUDE_PROJECT_DIR/scripts/claude-hooks/<datei>.py". Vorhandene Hook-Skripte: rfc-gate-guardrails.py, postedit-guardrails.py, block-prod-compose-down.py, block-parallel-docker-build.py.
Ebenfalls in derselben Datei: permissions.deny mit u. a. Bash(git push --force *), Bash(git reset --hard*), Bash(*DROP DATABASE*), Bash(aws rds delete-db-instance*). — geprüft am 2026-07-21

Output Styles — die Form der Antwort

Steuert, wie geantwortet wird, nicht was getan wird: Ausführlichkeit, Tonfall, Aufbau der Ausgabe.

Dafür gedacht

Konsistente Darstellung über ein Team hinweg. Knappe Antworten für Geübte, erklärende Antworten für Einarbeitung und Lehre.

Dafür nicht

Fachliche Regeln, Verfahren oder Sicherheitsvorgaben. Wer Inhalt über den Stil steuern will, hat das falsche Werkzeug in der Hand.

Das am seltensten gebrauchte Primitiv im Baukasten — aber es gehört auf die Landkarte, damit es niemand mit Rules verwechselt.

Woran soll er andocken?

MCP — Anschluss an fremde Systeme

Ein offenes Protokoll, über das ein Agent Werkzeuge und Daten außerhalb der Codebasis erreicht: Ticketsystem, Datenbank, Dokumentation, interne Dienste. Ein Server stellt bereit, der Client nutzt.

Dafür gedacht

Systeme, für die es keine brauchbare Kommandozeile gibt — oder wo eine strukturierte Schnittstelle deutlich verlässlicher ist als Textausgabe.

Dafür nicht

Alles, was ein vorhandenes CLI schon kann. Jeder angebundene Server legt seine Werkzeugbeschreibungen in jeden Kontext — Modul 1 lässt grüßen.

Aus cgsit-finance: eine .mcp.json im Repo-Wurzelverzeichnis mit dem Schlüssel mcpServers und genau einem Eintrag (Angular-Werkzeugserver, gestartet über npx). Ein Server, weil er etwas kann, was die Kommandozeile dort nicht bietet. — geprüft am 2026-07-21

Plugins — das teilbare Bündel

Ein Plugin verpackt mehrere Primitive — Skills, Commands, Agents, Hooks, MCP-Anbindung — zu einer installierbaren Einheit und macht sie über Repo-Grenzen hinweg verteilbar.

Bündeln

Was zusammengehört, wird gemeinsam installiert und gemeinsam versioniert.

Teilen

Andere Teams bekommen den Arbeitsstand, ohne Dateien abzuschreiben.

Weiterentwickeln

Das Bündel wird gepflegt wie eine interne Bibliothek — mit Reviews und Releases.

Plugins sind die Team-Antwort auf den Baukasten. Für einen Einzelnen sind sie Overhead, für fünf Teams sind sie der einzige Weg — Vertiefung in Modul 10.

Ich will X → ich benutze Y

Ich will…Werkzeugweil…
…dass er unsere Build- und Testbefehle immer kenntCLAUDE.mdgilt in jeder Session, ohne Auslöser
…Konventionen nur beim Anfassen bestimmter DateienRulelädt gezielt, spart Kontext
…ein mehrstufiges Verfahren, das er selbst erkenntSkillBeschreibung macht ihn auffindbar
…einen Prompt, den ich täglich selbst auslöseCommandich bin der Auslöser, immer
…Recherche oder Testlauf ohne KontextmüllSubagenteigener Kontext, nur Ergebnis kommt zurück
…eine Garantie, dass etwas passiertHookCode statt Bitte — deterministisch
…dass ein Befehl nie ausgeführt wirdPermissions (deny)harte Grenze vor der Ausführung
…knappere oder erklärendere AntwortenOutput Stylebetrifft die Form, nicht die Sache
…Zugriff auf ein System außerhalb des ReposMCPstrukturierte Schnittstelle statt Textparsen
…all das an andere Teams weitergebenPluginein Bündel, versioniert und installierbar

Die vier klassischen Verwechslungen

1CLAUDE.md oder Rule? Gilt es immer — oder nur beim Anfassen bestimmter Dateien? Alles, was „immer" ist, ohne es zu sein, ist Dauerbelastung des Kontextfensters.
2Command oder Skill? Wer löst aus — ich jedes Mal, oder soll der Agent selbst merken, dass es dran ist?
3Skill oder Subagent? Der Skill sagt wie etwas geht, der Subagent wo es passiert. Beides zusammen ist der Normalfall, nicht die Ausnahme.
4Rule oder Hook? Soll es befolgt werden — oder erzwungen? Wer eine Zusicherung braucht, bekommt sie nur vom Hook.
Jede dieser Fragen hat eine Unterscheidungsachse: Ladezeitpunkt · Auslöser · Ort · Verbindlichkeit.

Wo es weitergeht

PrimitivVertiefungDort geht es um…
CLAUDE.mdModul 7Aufbau, Umfang, Pitfalls, agent-ready Codebase
SubagentsModul 5Parallel Agent Development, Review-Loops
Skills, Rules, Commands, HooksModul 8selbst bauen, pro Workflow-Phase
MCPModul 8Server, Tools, Resources — und MCP vs. CLI
Permissions & GrenzenModul 9Blast Radius, Security-Gates in der CI
PluginsModul 10Team-Asset, Versionierung, Konsolidierung
Modul 2 ist die Landkarte. Ab hier wird jedes Primitiv genau dort ausgepackt, wo der Arbeitsablauf es braucht — nicht früher.

Übung 2 — Werkzeug zu Szenario

Aufgabe

Ordnet jedem der folgenden Szenarien genau ein Primitiv zu und schreibt einen Satz Begründung dazu:

(a) Jeder Agent soll wissen, wie unser Projekt gebaut und getestet wird · (b) Vor jedem Commit soll garantiert formatiert werden · (c) Beim Bearbeiten von SQL-Migrationen gelten Sonderregeln · (d) Unser Release-Ablauf hat zwölf Schritte, die niemand auswendig kann · (e) Ich starte jeden Morgen dieselbe Statusabfrage · (f) Eine Bibliotheksrecherche soll den Hauptkontext nicht zumüllen · (g) Der Agent soll unser Ticketsystem lesen können · (h) Ein zweites Team will unseren kompletten Arbeitsstand übernehmen

Verifizierbares Ergebnis: eine ausgefüllte Zuordnungsmatrix (8 Zeilen: Szenario → Primitiv → Begründung), in der jede Begründung eine der vier Unterscheidungsachsen nennt — Ladezeitpunkt, Auslöser, Ort oder Verbindlichkeit.

Dauer ca. 20 Minuten · Partnerarbeit, danach 10 Minuten Auflösung im Plenum

© 2026 CGS IT Solutions GmbH

Alle Rechte vorbehalten

Diese Schulungsunterlagen sind urheberrechtlich geschützt. Vervielfältigung, Weitergabe oder kommerzielle Nutzung — auch in Auszügen — nur mit ausdrücklicher schriftlicher Genehmigung der CGS IT Solutions GmbH.

cgsit-claude-training · Modul 2 · v0.1.0