Skills vs. Rules in Claude Code — was automatisch lädt, was auf Abruf kommt und was es an Kontext kostet

Im .claude/-Ordner eines Claude-Code-Projekts liegen Rules und Skills nebeneinander: Markdown-Dateien, die fast gleich aussehen — und sich genau gegensätzlich verhalten. Claude Code Rules sind bei jedem Session-Start vollständig im Kontext; ein Skill kostet fast nichts, bis es jemand aufruft. Wer das verwechselt, packt entweder alles in Rules und bezahlt jede Session dafür — oder erwartet von einem Skill, dass es „einfach gilt“, ohne je aufgerufen zu werden.

Dieser Artikel zieht die Trennlinie scharf — am .claude/-Ordner eines echten Projekts, dem offenen DI²-Starter-Kit.

Das Wichtigste vorab:

• Rules (CLAUDE.md + .claude/rules/) laden automatisch beim Session-Start — voller Inhalt, jede Session.
• Skills (.claude/skills/) sind auf Abruf: Im Kontext liegt nur die Description-Zeile; der Body lädt erst beim Aufruf — per Slash-Command oder weil Claude die Description selbst zur Aufgabe passend findet.
• Die Kontextkosten-Tabelle: was wann wie viel kostet — inklusive der zwei Regler paths: (Rules) und disable-model-invocation (Skills).
• Die Entscheidungsregel: Was immer gelten muss, wird Rule; was auf Kommando abläuft, wird Skill.
• Warum ein Skill die Rules trotzdem beim Namen nennt — und warum Rules ein lebendes Dokument sind.

Voraussetzung: Ein Claude-Code-Projekt mit .claude/-Ordner; die Beispiele stammen aus dem offenen DI²-Starter-Kit auf GitHub. Stand der Mechanik: Juli 2026, verifiziert gegen die offizielle Claude-Code-Doku — die Details sind versionsabhängig, das Prinzip dahinter nicht.

Inhalt

• Rules: die Verfassung, die immer im Kontext ist
• Skills: der Werkzeugkasten auf Abruf
• Die Kontextkosten-Frage
• Rule oder Skill? Die Entscheidungsregel
• Warum ein Skill die Rules trotzdem nennt
• Rules sind ein lebendes Dokument
• FAQ
• Verwandte Artikel

Rules: die Verfassung, die immer im Kontext ist

Zu den Rules zählt alles, was Claude Code ungefragt in den Kontext lädt, bevor der erste Prompt verarbeitet wird: die CLAUDE.md des Projekts (plus eine persönliche ~/.claude/CLAUDE.md und eine optionale, gitignorierte CLAUDE.local.md) und jede Datei unter .claude/rules/. So sieht das im Starter-Kit aus:

.claude/
├── CLAUDE.md                  Projekt-Rahmen (+ @imports)
├── rules/
│   ├── language.md            immer geladen
│   ├── security.md            immer geladen
│   └── sql/postgres/…         immer geladen
└── skills/
    ├── requirements/SKILL.md  nur die Description im Kontext
    ├── backend/SKILL.md       nur die Description im Kontext
    └── deploy/SKILL.md        nur die Description im Kontext

.claude/
├── CLAUDE.md                  Projekt-Rahmen (+ @imports)
├── rules/
│   ├── language.md            immer geladen
│   ├── security.md            immer geladen
│   └── sql/postgres/…         immer geladen
└── skills/
    ├── requirements/SKILL.md  nur die Description im Kontext
    ├── backend/SKILL.md       nur die Description im Kontext
    └── deploy/SKILL.md        nur die Description im Kontext

Die Konsequenz aus der ersten Hälfte dieses Baums: Rules gelten für jede Aktion — auch für die Ad-hoc-Anfrage („ändere Tabelle X“), die gar kein Skill benutzt. Genau deshalb gehören Konventionen dorthin: eine Sprach-Regel, ein Sicherheits-Minimum, ein SQL-Stil. Stünde dieselbe Konvention nur in einem Skill-Text, würde sie außerhalb dieses Skills stillschweigend nicht gelten.

Dieses Laden ist ein Schnappschuss: Die Session arbeitet mit dem Stand, den die Dateien beim Session-Start hatten. Diese Snapshot-Semantik wird am Ende des Artikels noch einmal wichtig — sie erklärt, warum eine Rule-Änderung nicht sofort wirkt.

Zwei Details zur CLAUDE.md: Sie kann per @pfad/zur/datei.md weitere Dateien importieren — die werden beim Session-Start mitgeladen, als stünden sie direkt drin. Ein normaler Markdown-Link ([Text](datei.md)) importiert dagegen nicht; er ist nur ein Verweis, dem Claude bei Bedarf folgt. Und: Der Preis für all das ist das Kontext-Fenster — dazu gleich mehr.

Skills: der Werkzeugkasten auf Abruf

Ein Skill ist ein Unterordner unter .claude/skills/ mit einer SKILL.md: oben ein Frontmatter-Block mit name und description, darunter der Body mit der eigentlichen Anleitung — ein Prozess, ein Ablauf, eine Checkliste.

  1: ---
  2: name: deploy
  3: description: Rollt eine Umgebung aus — fragt das Ziel ab, prüft die Vorbedingungen.
  4: ---
  5: (ab hier der Body — er lädt erst beim Aufruf in den Kontext)

  1: ---
  2: name: deploy
  3: description: Rollt eine Umgebung aus — fragt das Ziel ab, prüft die Vorbedingungen.
  4: ---
  5: (ab hier der Body — er lädt erst beim Aufruf in den Kontext)

Beim Session-Start passiert mit diesem Ordner fast nichts: Im Kontext landet nur Name und Description — wenige Tokens pro Skill. Der Body bleibt auf der Festplatte, bis das Skill aufgerufen wird. Erst dann lädt er vollständig in die Konversation.

Für den Aufruf gibt es zwei Wege, und der zweite wird oft übersehen: Entweder tippt der User den Slash-Command (/deploy) — oder Claude ruft das Skill selbst auf, weil die Description zur aktuellen Aufgabe passt. Die Description ist damit nicht nur Dokumentation, sondern der Auslöser fürs automatische Matching: Eine scharfe Description („Rollt eine Umgebung aus …“) wird zuverlässig getroffen, eine vage („Hilft beim Deployment-Zeug“) nicht. Wer den Selbst-Aufruf für ein Skill unterbinden will — etwa weil ein Workflow-Schritt bewusst nur auf User-Kommando starten soll —, setzt disable-model-invocation: true ins Frontmatter: Das Skill ist dann für Claude unsichtbar und kostet null Kontext, bis der User es explizit aufruft.

Noch ein Wort zur Historie: Die älteren Slash-Commands (.claude/commands/*.md) sind in Skills aufgegangen — beide Formen funktionieren und erzeugen denselben /name, aber Skills können mehr (eigener Ordner mit Zusatz-Dateien, Frontmatter-Steuerung) und sind die empfohlene Form.

Die Kontextkosten-Frage

Warum nicht einfach alles in Rules packen, dann „gilt“ es wenigstens immer? Weil jede Rule in jeder Session bezahlt wird — auch in der Session, die mit ihrem Thema nichts zu tun hat. Ein Projekt ohne Datenbank, das trotzdem den kompletten SQL-Regelsatz lädt, verbrennt Kontext-Fenster für nichts. Und das Budget ist nicht nur eine Kostenfrage: Je voller der Kontext, desto schwächer hält das Modell jede einzelne Anweisung ein.

Die Mechanik im Überblick — mit den beiden Reglern, die zwischen „immer voll“ und „gar nicht“ liegen:

Der paths:-Regler verdient einen zweiten Blick. Er nimmt ein Glob-Muster entgegen (englisch „glob pattern“) — eine einfache Syntax, um Dateien und Verzeichnisse über Platzhalter-Zeichen zu treffen, statt jeden Dateinamen einzeln auszuschreiben. Der Name stammt vom alten Unix-Befehl glob („global“), der Dateinamen expandierte. Die wichtigsten Platzhalter:

Begegnet ist einem diese Syntax längst — die .gitignore (*.log, node_modules/) arbeitet genauso. Eine Rule mit paths: ["db/**"] im Frontmatter lädt erst, wenn Claude eine Datei aus db/ oder einem beliebig tief darunter liegenden Unterverzeichnis anfasst — der offizielle Mittelweg für Regelwerke, die nur einen Teil des Projekts betreffen. Das Starter-Kit geht den anderen Weg und löscht Unzutreffendes gleich ganz: Sein /init-Skill beschneidet beim Aufsetzen die Vendor-Bäume (sql/postgres/ oder sql/mssql/, nie beide), damit gar nicht erst zwei Dialekte nebeneinander im Kontext liegen.

Rule oder Skill? Die Entscheidungsregel

Der Merksatz, auf den sich alles herunterbrechen lässt:

Was immer gelten muss, gehört in eine Rule. Was auf Kommando abläuft, gehört in ein Skill.

Drei Prüffragen machen daraus eine Entscheidung:

1. Muss es auch bei Ad-hoc-Anfragen gelten? Eine Naming-Konvention, ein Sicherheits-Minimum, die Projektsprache — das darf nicht davon abhängen, ob jemand ein Skill aufruft. → Rule.
2. Ist es ein Ablauf mit Schritten, Eingaben und Checkpoints? Ein Feature spezifizieren, eine Umgebung ausrollen, einen Bug erfassen — das ruft man auf, wenn es ansteht. → Skill.
3. Ist es ein Fakt, der sich ändert? Stack-Werte, Hosts, Kommandos gehören als Fakten-Datei in die Rules (sie müssen immer greifbar sein) — aber Abläufe, die damit arbeiten, lesen die Datei zur Ausführungszeit noch einmal frisch, statt sich auf die Kontext-Kopie vom Session-Start zu verlassen.

Im Starter-Kit sieht die Aufteilung so aus: language.md, security.md und die SQL-Konventionen sind Rules; /requirements, /backend, /qa und /deploy sind Skills — elf Workflow-Schritte plus Querschnitts-Helfer, jeder erst dann im Kontext, wenn er dran ist.

Warum ein Skill die Rules trotzdem nennt

Wer echte Skill-Dateien liest, stolpert über Zeilen wie „Lies .claude/rules/stack.md“ — und zieht daraus leicht den falschen Schluss, ein Skill müsse die Rules nennen, damit sie überhaupt gelten. Das ist die verbreitetste Fehlannahme in diesem Themenfeld, und sie ist falsch: Ein Skill läuft in der Haupt-Konversation, und dort sind die Rules längst geladen — seit dem Session-Start, unabhängig von jedem Skill.

Die Erwähnung hat zwei andere Aufgaben:

• Frische: Die Kontext-Kopie einer Rule ist ein Schnappschuss vom Session-Start. Bei Fakten-Dateien wie stack.md lohnt das erneute Lesen zur Ausführungszeit — es nimmt Änderungen mit, die seit Session-Beginn passiert sind.
• Fokus: Unter vielen geladenen Rules lenkt „folge sql/postgres/procedures.md“ die Aufmerksamkeit auf die eine, die für den aktuellen Schritt maßgeblich ist — wichtig, wenn ähnliche Regelwerke nebeneinander im Kontext liegen.

Eine Abgrenzung gehört hierher: Bei Subagents (eigenständige Instanzen, die das Modell für Teilaufgaben startet) ist dieselbe Zeile tatsächlich tragend — ein Subagent erbt die Konversation nicht und bekommt die .claude/rules/-Dateien nicht automatisch mit; ohne den expliziten Lese-Hinweis kennt er die Konvention schlicht nicht. Das ist aber ein eigenes Thema mit eigener Mechanik.

Rules sind ein lebendes Dokument

Die Rules eines Projekts sind kein Regelwerk, das einmal geschrieben und dann verwaltet wird — sie wachsen im Gebrauch. Die Feedback-Schleife ist dieselbe wie bei jedem anderen Living Document: Wenn am Ergebnis etwas nicht passt — eine Formulierung, ein Vorgehen, eine Praxis, die ab jetzt immer oder nur in einem bestimmten Fall gelten soll —, dann korrigiert man nicht nur die eine Stelle, sondern weist den Agenten an, die betreffende Rule gleich mit zu aktualisieren: „Nimm das in die Rule auf.“ So wandert jede Korrektur vom Einzelfall in die Konvention, und derselbe Punkt muss nie zweimal beanstandet werden.

Die Lade-Mechanik gibt dieser Schleife eine Eigenheit mit, die man kennen muss: Ein Rule-Edit wirkt erst in der nächsten Session. Der Kontext ist ein Schnappschuss vom Session-Start — die laufende Session arbeitet mit dem alten Stand weiter, bis man sie neu startet oder das geänderte File ausdrücklich neu lesen lässt. Wer sich wundert, dass „die Session die neue Regel ignoriert“, sieht keine Fehlfunktion, sondern genau diese Snapshot-Semantik.

Wie die Schleife in der Praxis aussieht, zeigt der Schwester-Artikel über das Schema-Deployment ohne Migrations-Tool: Dort sind zwei Deploy-Konventionen des Starter-Kits — die konvergente Schema-Evolution und die Unveränderlichkeit angewendeter Transition-Skripte — exakt auf diesem Weg entstanden: erst Diskussionspunkt am konkreten Ergebnis, dann Regel.

Damit schließt sich der Bogen: Gute Claude-Code-Setups bestehen meist aus wenigen, stabilen Rules und vielen kleinen, aufgabenbezogenen Skills. Je klarer diese Trennung, desto kleiner bleibt der Kontext — und desto vorhersehbarer arbeitet der Agent.

FAQ

Verwandte Artikel

• Ein Claude-Code-Projekt mit Entwicklungsworkflow und Datenbank aufsetzen — der Überblick über das Setup, zu dem diese Mechanik gehört.
• Maximal-Vorlage statt leeres Repo — ein Setup, das sich per /init selbst zuschneidet — warum das Kit Rules löscht statt sie zu deaktivieren.
• SQL-Schema deployen ohne Migrations-Tool — Rules und Living-Document-Schleife im Deploy-Einsatz.
• KI-gestützte SQL-Entwicklung mit Claude Code — Rules und Skills in Aktion für SQL-Konventionen.
• Das offene DI²-Starter-Kit auf GitHub — der komplette .claude/-Ordner mit 14 Skills und den Rules dieses Artikels.