Commands, Skills, Subagents, Rules: Was ich beim Organisieren von 139 Erweiterungen gelernt habe

Nach dem Erstellen von 95 Hooks, 44 Skills, 85 Commands und 11 Rule-Dateien für Claude Code habe ich gelernt, dass die Wahl der falschen Abstraktion mehr Zeit verschwendet als das Erstellen der falschen Funktion. Ein Skill, der eine Rule hätte sein sollen, blähte meinen Kontext um 40 % auf. Ein Command, der ein Skill hätte sein sollen, erforderte, dass ich jedes Mal /fastapi eintippen musste, wenn ich einen API-Endpunkt bearbeitete.¹

TL;DR

Claude Code bietet vier Möglichkeiten, das Verhalten zu erweitern: Commands (vom Benutzer ausgelöste Prompts), Skills (automatisch eingebundener Kontext), Subagents (delegierte Aufgabenausführer) und Rules (immer aktive Einschränkungen). Nach dem Organisieren von 139 Erweiterungen habe ich festgestellt, dass das Entscheidungsframework einfach ist: Rules für Invarianten, Skills für Domänenwissen, Commands für Workflows, Subagents für Isolation. Der schwierige Teil ist zu erkennen, wann man falsch gewählt hat, und dann zu migrieren.

Die vier Abstraktionen (mit echten Beispielen)

Commands: „/commit” und 84 weitere

Commands werden aktiviert, wenn ich /command-name eintippe. Jeder wird zu einem Prompt-Template expandiert.²

Meine 85 Commands umfassen /commit (intelligenter Git-Commit), /review (Code-Review-Agents starten), /deploy (Deployment-Checkliste), /publish-check (Blog-Vorveröffentlichungs-Validierung) und /deliberate (Multi-Agent-Recherche).

Der Fehler, den ich gemacht habe: Ich hatte /fastapi als Command gebaut, der bei Bedarf FastAPI-Patterns injizierte. Das Problem: Ich vergaß es in der Hälfte der Fälle einzutippen. Jeder vergessene Aufruf bedeutete, dass der Agent Patterns verpasste, die ich durchgesetzt haben wollte. Die Lösung war die Migration von /fastapi zu einem Skill mit automatischer Aktivierung.

Skills: 44 automatisch aktivierte Wissensmodule

Skills werden automatisch aktiviert, wenn die Konversation zur Beschreibung des Skills passt. Ich tippe keinen Command ein; das System injiziert relevantes Fachwissen basierend auf dem Kontext.³ Eine Schritt-für-Schritt-Anleitung zum Erstellen eigener Skills finden Sie unter eigene Skills erstellen.

---
description: FastAPI backend development patterns and conventions
---
# FastAPI Skill
When working on FastAPI endpoints, follow these patterns...

Meine 44 Skills decken ab: - Domänenwissen (8): FastAPI, SwiftUI, HTMX/Alpine, Datenbank, Testing, Debugging, Architektur, Sicherheit - Blog-Infrastruktur (7): blog-writer-core, blog-evaluator, citation-verifier, SEO-Playbook - Philosophie/Qualität (5): Shokunin (Jiro), No Shortcuts, Rubin-Essenz, Design-Prinzipien - Multi-Agent (3): Deliberation, Review, Content-Erstellung - Projektspezifisch (4): persönliche Webseite, ResumeGeni-Blog, Obsidian-Erfassung

Der Vorfall mit 40 % Kontext-Aufblähung: Anfangs hatte ich meinen vollständigen FastAPI-Patterns-Leitfaden (800 Zeilen) in eine Rule-Datei geschrieben. Rules werden in jede Sitzung geladen. Wenn ich an iOS-Apps, CSS oder Blog-Inhalten arbeitete, verbrauchten 800 Zeilen irrelevanter FastAPI-Patterns Kontext-Tokens. Das Verschieben des Inhalts in einen Skill mit der Beschreibung „FastAPI backend development” löste das Problem: Der Skill wurde nur bei API-Arbeit geladen.⁴

Subagents: Isolierte Reviewer

Subagents laufen in ihrem eigenen Kontextfenster mit eingeschränktem Werkzeugzugriff und unabhängigen Berechtigungen.⁵

Meine Subagents umfassen security-reviewer (Nur-Lese-Zugriff, OWASP-Schwachstellenanalyse), test-runner (führt Tests aus, analysiert Fehler) und conventions-reviewer (Prüfung von Projektstandards).

Warum Isolation wichtig ist: Während eines Code-Reviews sollte der Reviewer keine Dateien bearbeiten können. Ein Skill kann Review-Wissen injizieren, aber das Review findet weiterhin im Hauptkontext mit vollen Schreibberechtigungen statt. Ein Subagent erzwingt den Nur-Lese-Zugriff architektonisch.

Rules: 11 immer aktive Einschränkungsdateien

Rules werden automatisch in jede Konversation geladen. Meine 11 Rule-Dateien decken ab:⁶

~/.claude/rules/
├── security.md        # Never commit secrets, parameterized queries
├── git-workflow.md    # Conventional commits, branch naming
├── corrections.md     # Always use Claude (not OpenAI), current date
├── quality-loop.md    # Quality review loop, pride check
├── api-design.md      # REST conventions, response format
├── testing.md         # pytest conventions, coverage targets
└── aio.md             # AI Overview optimization for web content

Die Lektion zur Dimensionierung: Meine Rules umfassen insgesamt etwa 180 Zeilen über 11 Dateien. Jede Zeile wird in jede Sitzung geladen. Ursprünglich hatte ich über 400 Zeilen, bevor ich themenspezifische Inhalte in Skills migrierte. Das 180-Zeilen-Rule-Set deckt echte Invarianten ab (Sicherheitseinschränkungen, Git-Workflow, Korrekturen). Alles andere gehört in Skills.

Das Entscheidungsframework

Das Migrationsmuster

Meine .claude/-Struktur hat sich in drei Phasen entwickelt:

Phase 1 (Monat 1–2): Alles in Rules. Über 400 Zeilen immer geladener Kontext. iOS-Patterns, FastAPI-Patterns, Design-Richtlinien, Testing-Standards. Der Kontext war in jeder Sitzung aufgebläht.

Phase 2 (Monat 3–4): Themenspezifische Inhalte in Skills migriert. Rules sanken auf 200 Zeilen. Skills wuchsen auf über 20 Verzeichnisse. Die Kontext-Aufblähung sank um 40 %.

Phase 3 (Monat 5+): Subagents für Aufgaben hinzugefügt, die Isolation erfordern (Code-Review, Sicherheitsaudit). Commands stabilisierten sich bei 85 für explizite Workflows. Skills wuchsen auf 44, als ich domänenspezifisches Fachwissen hinzufügte.⁷

Die Lektion: Beginnen Sie mit Rules (günstig, immer verfügbar), entdecken Sie, was themenspezifisch ist (migrieren Sie zu Skills), und fügen Sie Subagents nur hinzu, wenn Sie Isolation benötigen. Kontext ist Architektur zeigt, welches tiefere Prinzip hinter diesem Migrationsmuster steckt: Die Kontextstruktur ist die architektonische Entscheidung, die jedes Agentenverhalten prägt. Das Hooks-Tutorial behandelt die Lifecycle-Event-Handler, die diese vier Abstraktionen ergänzen. Zusammengenommen bilden diese Erweiterungstypen die Grundlage von Claude Code als Infrastruktur — das vollständige Muster ist im Claude-Code-Leitfaden dokumentiert.

Skills, die Subagents antreiben

Ein leistungsstarkes Muster: Injizieren Sie Skills in den Subagent-Kontext über das skills-Frontmatter-Feld:

---
description: Code reviewer with security expertise
allowed-tools: [Read, Grep, Glob]
skills: [security, testing-philosophy]
---
Review code for quality, security, and test coverage...

Die Skills security und testing-philosophy injizieren ihren Inhalt in den System-Prompt des Subagents. Der Reviewer erhält spezialisiertes Wissen innerhalb seines isolierten, schreibgeschützten Kontexts.⁸

Meine Review-Pipeline nutzt dieses Muster: Drei Subagents (correctness-reviewer, security-reviewer, conventions-reviewer) erhalten jeweils unterschiedliche Skill-Injektionen. Der Correctness-Reviewer erhält debugging-philosophy. Der Security-Reviewer erhält das Sicherheits-Rule-Set. Der Conventions-Reviewer erhält die Codierungsstandards des Projekts.

Meine Produktionsarchitektur

~/.claude/
├── commands/     # 85 — User-triggered workflows
│   ├── commit.md, review.md, deploy.md
│   ├── publish-check.md, deliberate.md
│   └── morning.md, analytics.md, plan.md
│
├── skills/       # 44 — Auto-invoked expertise
│   ├── fastapi/, swiftui/, htmx-alpine/
│   ├── blog-writer-core/, citation-verifier/
│   └── jiro/, no-shortcuts/, rubin-essence/
│
├── agents/       # Isolated task executors
│   ├── security-reviewer.md
│   ├── correctness-reviewer.md
│   └── conventions-reviewer.md
│
├── rules/        # 11 files, ~180 lines — Always-on constraints
│   ├── security.md, git-workflow.md
│   ├── corrections.md, quality-loop.md
│   └── api-design.md, testing.md, aio.md
│
└── hooks/        # 95 — Lifecycle event handlers
    ├── git-safety-guardian.sh
    ├── recursion-guard.sh
    └── blog-quality-gate.sh

Wichtigste Erkenntnisse

Für Solo-Entwickler: - Beginnen Sie mit Rules für projektspezifische Standards (insgesamt unter 200 Zeilen halten) - Fügen Sie Skills für Ihre meistgenutzten Technologie-Stacks hinzu; die automatische Aktivierung eliminiert das Problem des „vergessenen Aufrufs” - Erstellen Sie zunächst Commands für Ihre drei häufigsten Workflows - Fügen Sie Subagents nur hinzu, wenn Sie Werkzeugeinschränkung oder Kontextisolation benötigen

Für Teams: - Standardisieren Sie Rules auf Projektebene für teamweite Konsistenz - Teilen Sie Skills über ein gemeinsames Repository; die Portabilität von Skills über Projekte hinweg ist ihr Hauptvorteil gegenüber projektspezifischer Konfiguration

Häufige Fragen

Worin unterscheiden sich Commands, Skills, Rules und Subagents in Claude Code?

Commands sind vom Benutzer ausgelöste Prompts, die Sie mit /command-name aufrufen. Skills sind automatisch eingebundene Kontextmodule, die aktiviert werden, sobald die Konversation zu ihrer Beschreibung passt. Rules sind immer aktive Einschränkungen, die in jede Sitzung geladen werden. Subagents sind isolierte Aufgabenausführer mit eingeschränktem Werkzeugzugriff und eigenem Kontextfenster. Das Entscheidungsframework lautet: Rules für Invarianten, Skills für Domänenwissen, Commands für Workflows, Subagents für Isolation.

Wie viele Claude-Code-Erweiterungen sind zu viele?

Die Anzahl zählt weniger als die Einordnung. Mein System läuft mit 95 Hooks, 44 Skills, 85 Commands und 11 Rule-Dateien ohne Performance-Probleme, weil jeder Typ anders geladen wird. Rules (immer aktiv) sollten insgesamt unter 200 Zeilen bleiben. Skills werden nur bei Bedarf geladen und dürfen deshalb frei wachsen. Commands werden auf Abruf aktiviert. Das Problem ist nicht die Menge, sondern die falsche Einordnung: Themenspezifische Inhalte in Rules statt in Skills verursachten eine Kontext-Aufblähung von 40 %, die sich durch die Migration zur richtigen Abstraktion sofort erledigte.

Sollte ich bei der Einrichtung von Claude Code mit Rules oder Skills beginnen?

Beginnen Sie mit Rules für echte Invarianten (Sicherheitseinschränkungen, Git-Workflow, Korrekturen), die unabhängig vom Thema für jede Sitzung gelten. Halten Sie sie insgesamt unter 200 Zeilen. Fügen Sie danach Skills für Ihre meistgenutzten Technologie-Stacks hinzu; die automatische Aktivierung eliminiert das Problem des „vergessenen Aufrufs”. Erstellen Sie anschließend Commands für Ihre drei häufigsten Workflows. Subagents kommen zuletzt — nur dann, wenn Sie für Aufgaben wie Code-Reviews Werkzeugeinschränkung oder Kontextisolation benötigen.

Wie lässt sich Kontext-Aufblähung in Claude-Code-Sitzungen verhindern?

Migrieren Sie themenspezifische Inhalte von Rules zu Skills. Rules werden in jede Sitzung geladen, Skills dagegen nur, wenn das Gesprächsthema passt. Meine Rules schrumpften von über 400 auf 180 Zeilen, nachdem ich FastAPI-Patterns, iOS-Patterns und Design-Richtlinien in Skills mit beschreibendem Frontmatter verschoben hatte. Die Kontextreduktion von 40 % war sofort spürbar. Das Prinzip: Was nicht für jede Sitzung relevant ist, gehört nicht in Rules.

Lassen sich Claude-Code-Skills projektübergreifend teilen?

Ja. Skills in ~/.claude/skills/ stehen in allen Projekten zur Verfügung. Projektspezifische Skills gehören in das Verzeichnis .claude/skills/ innerhalb des Projekts. Die Portabilität von Skills über Projekte hinweg ist ihr Hauptvorteil gegenüber projektspezifischer Konfiguration. Teams können Skills über ein gemeinsames Repository teilen, sodass alle Mitglieder auf dasselbe Domänenwissen und dieselben Qualitätsstandards zugreifen.

Quellenangaben