Skill-Tiering: Das Vier-Buckets-Modell, das unsere 80+ Skills aus dem Kontext heraushält

Warum mehr Skills nicht weniger Kontext bedeuten müssen

Das Claude-Code-Setup von Statnive lädt mehr als 80 Skills, die Produktmanagement, Backend-Scaffolding, QA, Security-Audits, WordPress-spezifische Patterns, Release-Packaging und mehr abdecken. Das Framework, auf dem wir aufbauen (jaan.to), liefert 141 mit. Naive Lesart: mehr Skills, mehr Kontext-Overhead, weniger Platz für die eigentliche Arbeit.

Die tatsächliche Rechnung ist interessanter. 80 Skills können 3.200 Tokens permanenter Metadaten kosten — oder null, je nachdem, wie jeder einzelne konfiguriert ist. Den Unterschied macht das Vier-Buckets-Tiering-Modell, das das Skill-System von Claude Code definiert, plus eine einzige Frage, mit der man den richtigen Bucket auswählt.

Dieser Beitrag geht alle vier Buckets mit der tatsächlichen Skill-Verteilung von Statnive durch, zeigt die Frage, mit der wir entscheiden, und die drei Dinge, die wir falsch gemacht haben, bevor es passte.

Progressive Disclosure: Der Mechanismus darunter

Bevor das Tiering-Modell Sinn ergibt, muss der Lade-Mechanismus klar sein. Claude Code verwendet drei Schichten progressiver Offenlegung für Skills:

Schicht	Was geladen wird	Wann	Kosten
1 — Metadaten	YAML-Frontmatter `name` + `description`	Immer beim Start	~30–50 Tokens pro Skill
2 — Body	Vollständiger `SKILL.md`-Inhalt	Wenn der Skill aufgerufen wird	Anthropic empfiehlt ≤ 500 Zeilen / ~5K Tokens
3 — Gebündelte Ressourcen	Referenzierte Skripte, Templates, Referenzen	Nur beim Zugriff	Null Grundkosten

Genau das ist der Hebel des Tiering-Modells. Die Metadaten-Schicht ist das Einzige, was immer im Kontext liegt. Alles andere kommt on demand.

Bei einem 141-Skill-Framework ergibt das 4.200–14.100 Tokens permanenten Overhead allein für Metadaten, linear mit der Anzahl der Skills. Mehr, wenn die Beschreibungen zu wortreich sind. Weniger — oder null —, wenn man bestimmten Skills sagt, dass sie das Metadaten-Register vollständig überspringen sollen.

Ein dokumentierter Bug (Claude Code GitHub Issue #14882) berichtet, dass einige Plugin-Skills beim Start ihren vollständigen Body laden statt nur die Frontmatter. Wir achten darauf in unserem eigenen /context-Output. Wenn die Metadaten-Zeile Ihrer Skills Zahlen weit über ~50 Tokens × Anzahl auto-invocable Skills zeigt, sind Sie davon betroffen.

Die vier Buckets

Jeder Skill im Statnive-Repo passt in einen der vier Buckets. Das definierende Frontmatter-Feld pro Bucket:

Bucket 1 — Always-On (Standard-Frontmatter)

---
name: simplify
description: Review changed code for reuse, quality, efficiency. Auto-fixes issues.
---

Das sind die Kern-Workflow-Skills, zu denen das Modell automatisch routen sollte. Standard-Frontmatter — keine speziellen Flags. Metadaten beim Start geladen; Body beim Aufruf.

Statnive-Beispiele: simplify, statnive-release, statnive-release-zip. Die feuern bei den meisten Release-bezogenen Arbeiten.

Kosten pro Skill: ~40 Tokens Metadaten dauerhaft im Kontext.

Bucket 2 — Auto-Invocable (Standard-Frontmatter, knappe Beschreibung)

Aus Sicht von Claude Code dieselbe Konfiguration wie Always-On. Die Unterscheidung ist redaktionell: Domänen-Skills, die nur feuern, wenn ihre Trigger-Keywords matchen. Die Disziplin liegt darin, die Beschreibung trigger-orientiert und kurz zu halten.

---
name: wp-rest-api
description: Use when building REST endpoints in WordPress plugins.
---

Schlechte Beschreibung (funktioniert noch, kostet aber mehr):

description: A comprehensive skill for working with the WordPress REST API,
  including endpoint registration, controller patterns, schema validation,
  authentication, response shaping, and CPT/taxonomy exposure...

Gute Beschreibung (oben): 13 Tokens. Schlechte Beschreibung: 38 Tokens. Über 60+ auto-invocable Skills hinweg sind das grob 1.500 Tokens permanente Metadaten-Einsparung.

Statnive-Beispiele: wp-rest-api, wp-plugin-development, wp-performance, react-best-practices, wp-block-development, alle jaan-to:*-Planungs-Skills.

Kosten pro Skill: ~30–50 Tokens Metadaten dauerhaft im Kontext.

Bucket 3 — Manual-Only (`disable-model-invocation: true`)

---
name: statnive-emergency-rollback
description: Emergency-only rollback procedure for a botched deploy.
disable-model-invocation: true
---

Der Skill existiert, das Slash-Kommando funktioniert (/statnive-emergency-rollback), aber die Metadaten landen nie im <available_skills>-Register. Claude weiß nicht, dass es ihn gibt, solange der Nutzer ihn nicht ausdrücklich aufruft.

Kosten pro Skill: 0 Tokens. Das ist der magische Bucket.

Wann einsetzen: seltene Workflows, destruktive Operationen, alles, wo das Modell nicht automatisch hin routen soll. Wenn das Markieren als manual-only einen Workflow blockieren würde, gehört der Skill stattdessen in Bucket 1 oder 2.

Statnive-Beispiele: Notfall-Rollback, manuelle Datenbank-Eingriffe, einmalige Migrations-Skripte, alles, was „nur für den Fall” existiert, aber nicht opportunistisch feuern soll.

Wir markieren grob die Hälfte unserer Skills als disable-model-invocation: true. Über 80+ Skills hinweg sind das ~1.800 Tokens an wiedergewonnenen Baseline-Metadaten — und die Routing-Qualität bei den verbleibenden auto-invocable Skills hat sich sogar verbessert, weil Claude nicht mehr zwischen Quasi-Duplikaten wählen musste.

Bucket 4 — Fork / Subagent (`context: fork`)

---
name: simplify
description: Review changed code for reuse, quality, efficiency. Auto-fixes issues.
context: fork
---

Fork-Modus führt den Skill in einem isolierten Subagent-Kontext mit eigener Konversationshistorie und eigenem 200K-Token-Fenster aus. Der Arbeits-Output bleibt aus dem Hauptkontext heraus. Nur eine Zusammenfassung kehrt zurück.

Für in sich geschlossene Workflows wie Code-Reviews, Security-Audits und mehrstufige Recherchen ist das ein Game-Changer. Anthropic dokumentiert, dass Subagenten ~500–1.000 Tokens aus über 10.000 interner Arbeit zurückgeben — grob eine 37%ige Reduktion des Hauptkontexts bei komplexen Aufgaben, in denen der Subagent viel Lesen und Verarbeiten geleistet hat.

Statnive-Beispiele: simplify (drei parallele Review-Agenten, gibt eine Zusammenfassung zurück), jaan-to:backend-pr-review, jaan-to:sec-audit-remediate, jaan-to:detect-dev. Alles, was viele Dateien liest und ein Urteil zurückgibt.

Kosten pro Skill: ~40 Tokens Metadaten, aber die Arbeit selbst läuft isoliert.

Die Eine-Frage-Prüfung

Die vier Buckets klingen nach vier Entscheidungen. In Wahrheit sind sie eine: Muss der Hauptdialog die Zwischenarbeit des Skills sehen?

Antwort	Bucket
Ja — der Skill schreibt Code, an dem die Hauptsitzung weiter editieren wird	Always-on oder Auto-invocable
Nein — der Skill liefert ein Urteil, eine Zusammenfassung oder einen Bericht	Fork / Subagent
Vielleicht — sollte aber nie automatisch feuern (selten, destruktiv, eigenwillig)	Manual-only

Lautet die Antwort „nein”, setzen Sie context: fork. Ihr Hauptkontext bleibt sauber, und Sie können Haiku 4.5 ($1/$5 pro MTok) für die leseintensive Arbeit des Subagenten nutzen, während die Hauptsitzung Sonnet oder Opus verwendet. Das ist ein 3×-Kostengewinn obendrauf zum Kontextgewinn.

Lautet die Antwort „ja”, landet er in Bucket 1 oder 2. Die Wahl zwischen Always-On und Auto-Invocable ist redaktionell: wie sicher kann Claude diesen Skill aus Natural-Language-Hinweisen heraus triggern? Starke, eindeutige Trigger gehören in Auto-Invocable. Workflows, die das Modell in den meisten Sitzungen erwägen sollte, gehören in Always-On.

Existiert der Skill, soll aber nie automatisch feuern, markieren Sie ihn als Manual-Only und holen Sie sich seine Metadaten-Kosten zurück.

Die tatsächliche Skill-Verteilung von Statnive

Hier unser aktueller Stand über ~85 Skills:

Bucket	Anzahl	Gesamte Metadaten-Kosten	Anmerkungen
Always-On	8	~320 Tokens	Release, simplify, Sprint-Planung, PR-Review
Auto-invocable	38	~1.520 Tokens	Domänen-Skills mit starken Trigger-Keywords
Manual-only	32	0 Tokens	Slash-Kommando-Only
Fork / Subagent	7	~280 Tokens	Reviews, Audits, Detects
Gesamtkosten Metadaten	85	~2.120 Tokens	Etwa 1 % des Kontexts

Ohne Tiering — wären alle 85 Standard — würden wir grob 3.400 Tokens permanenter Metadaten zahlen. Allein die 32 Manual-Only-Skills sparen ~1.280 Tokens. Wirkt isoliert klein; zählt aber, kombiniert mit CLAUDE.md-Kürzungen und MCP Tool Search.

Body-Limits: Warum 500 Zeilen die richtige Zahl ist

Die Metadaten-Seite ist permanenter Overhead. Die Body-Seite ist Per-Aufruf-Overhead — und ebenso wichtig zu kontrollieren.

Anthropic empfiehlt, jede SKILL.md unter 500 Zeilen (~5K Tokens) zu halten. Forschung zur aggressiven Optimierung schiebt das auf eine harte Obergrenze von 600 Zeilen pro Skill-Body, wobei alles darüber Reference Extraction verlangt: Templates, lange Checklisten, Multi-Stack-Vergleiche, Anti-Pattern-Kataloge raus aus der SKILL.md und in separate Dateien, die über klare Pointer referenziert werden.

Das Pattern sieht so aus:

.claude/skills/wp-plugin-development/
├── SKILL.md                          # 380 Zeilen — nur Execution-Core
└── references/
    ├── activation-deactivation-patterns.md   # Wird nur bei Bedarf geladen
    ├── settings-api-patterns.md
    ├── nonce-and-capability-checklist.md
    └── release-packaging-checklist.md

Der Execution-Core bleibt kompakt und deterministisch. Referenzen laden on demand und kosten null Tokens, bis sie benutzt werden. Wir haben drei unserer schwersten Skills nach diesem Muster umgebaut und ~12.000 Tokens aus typischen Aufruf-Budgets gestrichen.

Das andere Body-Control-Feld, das sich lohnt:

allowed-tools: ["Read", "Grep", "Glob"]

Das schränkt ein, auf welche Tools der Skill zugreifen darf, und reduziert sowohl Token-Overhead als auch Execution-Surface. Ein Skill, der nur Code liest, braucht keinen Write-, Bash- oder MCP-Tool-Zugriff — die Tool-Liste einzuschränken schränkt das beim Skill-Aufruf injizierte Schema ein und beseitigt ganze Klassen versehentlichen Verhaltens.

Was wir bei den ersten drei Anläufen falsch gemacht haben

Ehrliche Caveats, gleiches Muster wie im Rest der Serie:

Wir haben mit wortreichen Beschreibungen gestartet. Unsere erste Skill-Welle hatte Beschreibungen mit 60+ Tokens, optimiert für menschliche Leser. Sie funktionierten — kosteten aber das Doppelte des Nötigen. Trim-Runde eins schnitt ~1.400 Tokens Metadaten aus dem Auto-Invocable-Bucket.
Wir hatten drei Skills, die Ähnliches taten. Im Auto-Invocable-Bucket lagen pm-roadmap-add, pm-roadmap-update und pm-sprint-plan mit überlappenden Triggern. Routing wurde zum Münzwurf. Wir haben konsolidiert und die Trigger geschärft. Routing-Genauigkeit hoch, Metadaten-Kosten runter.
Wir hatten schwergewichtige Skills, die nicht im Fork-Modus liefen. simplify lief ursprünglich inline. Er las 30+ Dateien, fuhr drei Review-Durchgänge und gab einen 2.000-Token-Bericht zurück — und all diese interne Arbeit verschmutzte den Hauptkontext. Der Wechsel auf context: fork reduzierte den typischen Hauptkontext-Verbrauch pro Release-Sitzung um ~9.000 Tokens.

Der Mess-Schritt

Wie im Rest der Serie: /context ist die Diagnose. Die Zeile, auf die Sie beim Skill-Tiering achten, ist die mit dem Skill-Metadaten-Token-Count. Unsere Zielwerte:

Quelle	Ziel	Harte Obergrenze
Skill-Metadaten	≤ 2.500 Tokens	5.000
Anzahl auto-invocable Skills	≤ 60	—
Beliebige einzelne SKILL.md-Body-Größe	≤ 500 Zeilen / ~5K Tokens	600 Zeilen / ~8K Tokens

Liegt Ihre Skill-Metadaten-Zeile deutlich über 5K Tokens und Sie haben weniger als 100 Skills, haben Sie wahrscheinlich entweder wortreiche Beschreibungen (Bucket-2-Problem) oder den oben erwähnten Lade-Bug (Bucket-1-Problem).

Wie das mit dem Rest von Statnive zusammenhängt

Wir führen 248 PHP-Unit-Tests bei jedem Commit aus. Releases bestehen 22 Release-Gates, bevor irgendeine Version ausgeliefert wird. Die Skills, die das alles orchestrieren — statnive-release, simplify, wp-plugin-development, die QA-Generatoren — passen in grob 2.100 Tokens permanenter Metadaten. Die Arbeit passiert, der Kontext bleibt sauber, das Team bleibt klein.

Das Vier-Buckets-Modell ist keine akademische Übung. Es ist der Grund, warum wir ein WordPress-Analytics-Plugin unter einem 5KB-Tracker-Budget ausliefern können, ohne ein fünfköpfiges Team dahinter zu haben.

Statnive ausprobieren

Datenschutz-First-WordPress-Analytics, gebaut von einem Team, das /context häufiger ausführt als /help. Statnive kostenlos auf WordPress.org installieren — Ihre Daten bleiben auf Ihrem Server, unsere Skill-Bibliothek bleibt deutlich unter ihrem Token-Budget.