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.³

---
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.

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

Quellenangaben