Von Slash Commands zu Skills: wann und wie migrieren

Die ersten drei Artikel haben den vollständigen Einsatz von Slash Commands gezeigt: vom Markdown-File über die !command-Injektion bis zur Orchestrierung via Subagents und MCP. Nichts davon ist veraltet — aber das offizielle Team hat im Hintergrund eine Zusammenführung vollzogen: Custom Commands sind in Skills aufgegangen.

Dein .claude/commands/review.md läuft weiter, /review funktioniert nach wie vor, du musst gar nichts ändern. Wer aber will, dass das Command mehr Fähigkeiten bekommt (mehrere Dateien, Fork-Ausführung, automatische Aktivierung nach Path), findet den neuen Weg unter .claude/skills/review/SKILL.md. Dieser Artikel klärt zwei Dinge: wie man migriert — und ob es den Aufwand lohnt.

Minimale Migration: einen Path ändern, den Rest stehen lassen

Das Kompatibilitätsversprechen ist eindeutig: .claude/commands/deploy.md und .claude/skills/deploy/SKILL.md werden beide als /deploy registriert und verhalten sich gleich. Bei Namenskollisionen gewinnt das Skill.

Die kleinstmöglichen Schritte:

cd .claude/commands
mkdir -p ../skills/review
mv review.md ../skills/review/SKILL.md

Am Dateiinhalt muss keine einzige Zeile geändert werden. YAML-Frontmatter, !`command`, @file, $ARGUMENTS — alles weiterhin kompatibel.

Allein mit diesem Schritt fragt sich der Leser allerdings: wozu dann überhaupt migrieren? Die Antwort liegt darin, dass ein Skill-Verzeichnis beliebig viele Dateien enthalten kann, ein Command hingegen immer nur eine.

Gründe zu migrieren: die vier Extras von SKILL.md

1. Begleitdateien: lange Dokumente auslagern

SKILL.md ist der Einstieg, und im selben Verzeichnis dürfen beliebige weitere Dateien liegen. Stell dir so eine Struktur vor:

.claude/skills/review/
├── SKILL.md            # Einstieg, knappe Anweisungen + Referenzen
├── checklist.md        # lange Code-Review-Checklist
├── examples/
│   └── good-diff.md    # Positivbeispiel
└── scripts/
    └── lint.sh         # Script, das SKILL.md aufrufen kann

Innerhalb von SKILL.md wird über relative Paths referenziert:

Prüfe das aktuelle diff nach den Kriterien in [checklist.md](checklist.md).
Siehe [examples/good-diff.md](examples/good-diff.md) für das erwartete Ausgabeformat.

Diese Begleitdateien landen nicht automatisch im Context — Claude liest sie bei Bedarf. Die offizielle Empfehlung: SKILL.md unter 500 Zeilen halten, alles andere in Begleitdateien auslagern.

2. `disable-model-invocation`: welche Skills nur du manuell auslösen darfst

Standardmäßig kann Claude ein Skill selbstständig aufrufen, wenn es den Moment passend findet. Für Commands mit Seiteneffekten wie /deploy, /commit, /send-email ist das riskant — du willst nicht, dass Claude „deployt, weil der Code gut aussieht".

---
name: deploy
description: Deployment in die Produktion
disable-model-invocation: true
allowed-tools: Bash(kamal deploy:*), Bash(git push:*)
---

Mit dieser Zeile lässt sich /deploy nur noch per manueller Eingabe starten — Claude ruft es im Gesprächsverlauf nicht mehr eigenmächtig auf.

Umgekehrt bedeutet user-invocable: false „darf nur Claude selbst aufrufen, taucht aber nicht im /-Menü auf" — passend für Hintergrundwissen-Skills (etwa legacy-system-context, das Claude in passenden Situationen automatisch lädt und das manuell auszulösen sinnlos wäre).

3. `context: fork`: das Skill im Subagent laufen lassen

Das ist der größte Zugewinn. Im vorherigen Artikel haben wir gesehen, dass ein Command mit allowed-tools: Task das Modell dazu bringen kann, einen Subagent zu starten — aber du musstest im Prompt selbst formulieren: „Starte einen Explore-Subagent, der …".

Im SKILL reicht eine einzige Frontmatter-Zeile:

---
name: deep-research
description: Ein Symbol tiefgehend untersuchen
context: fork
agent: Explore
---

Untersuche alle Verwendungen von $ARGUMENTS:
- sämtliche Aufrufstellen
- fachliche Szenarien
- alternative Implementierungen

Gib eine Zusammenfassung ≤300 Wörter zurück.

Wenn du /deep-research SomeClass auslöst, wird die komplette SKILL.md zum Prompt eines eigenständigen Subagents, ausgeführt als Agent Type Explore, und am Ende kommt nur das Fazit zurück. Der Context der Hauptunterhaltung bleibt sauber.

Das verwandelt das „Subagent starten" von einer Prompt-Beschreibung in ein deklaratives Skill-Attribut.

4. `paths`: automatische Aktivierung nach Dateityp

---
name: rails-conventions
description: Code-Konventionen dieses Rails-Projekts
paths: ["app/**/*.rb", "config/**/*.rb"]
---

Halte dich an die Rails-Konventionen dieses Projekts:
- Service Objects statt Fat Controllers
- Alle ActiveRecord-Scopes müssen benannt sein
...

Während du gerade app/models/user.rb editierst, wird dieses Skill automatisch in den Context geladen; beim Bearbeiten von package.json nicht. Das ist präziser als ein globales CLAUDE.md — im Grunde ein „CLAUDE.md, nach Path geschichtet".

Praxis: `/plan` zum Skill aufrüsten

Das Schluss-/plan-Beispiel aus dem letzten Artikel war ursprünglich ein Single-File-Command:

.claude/commands/plan.md

Als Skill:

.claude/skills/plan/
├── SKILL.md
├── research-prompt.md     # Anweisungen für Subagent 1
└── risk-prompt.md         # Anweisungen für Subagent 2

SKILL.md:

---
name: plan
description: Umsetzungsplan auf Basis eines Linear-Tickets erstellen
disable-model-invocation: true
allowed-tools: mcp__linear__*, Task, Read, Grep, Bash(git log:*)
---

## Context

@.claude/context/architecture.md

## Zustand

!`git log --oneline -10`

## Aufgabe

Beschreibung und Kommentare des Linear-Tickets $ARGUMENTS abrufen.

Mit Task zwei Subagents parallel starten:
1. Code-Recherche: Prompt in [research-prompt.md](research-prompt.md)
2. Risiko-Einschätzung: Prompt in [risk-prompt.md](risk-prompt.md)

Beide Ergebnisse zusammenführen zu: Umsetzungsschritten + Risikoliste + Empfehlung zur Commit-Granularität.

Die beiden Subagent-Prompts liegen in eigenen Dateien — man kann sie pflegen, ohne SKILL.md anzufassen. Das Skill selbst bleibt unter 30 Zeilen schlank, während die Begleitdateien bei Bedarf jeweils mehrere hundert Zeilen lang sein dürfen.

Wer nicht einmal selbst Subagents orchestrieren möchte, kann noch weiter gehen und das komplette Skill in einen Fork werfen, sodass der Explore-Agent alles am Stück erledigt:

---
name: plan
context: fork
agent: Explore
allowed-tools: mcp__linear__*
---

/plan ENG-4213 → der Explore-Agent in isoliertem Context übernimmt den gesamten SKILL.md-Inhalt als Auftrag → liefert nur den finalen Plan zurück. Die Hauptunterhaltung bleibt vollkommen sauber.

Wann man lieber nicht migrieren sollte

Nicht jedes Command verdient ein Upgrade. In .claude/commands/ bleiben ist richtig, wenn:

Ein einzelnes Markdown reicht: keine Checklist, keine Beispiele, keine Scripts zum Auslagern.
Kein Fork nötig: die Aufgabe ist eng mit der Hauptunterhaltung verzahnt und braucht die vollständige Historie.
Keine automatische Path-Aktivierung nötig: Trigger erfolgt ohnehin manuell.
Keine Zugriffssteuerung nötig: nichts Schlimmes passiert, wenn Claude es selbst aufruft.

Einfache Dinge wie /commit oder /pr-desc — ein Frontmatter plus ein paar Zeilen Prompt — sind in .claude/commands/ sogar übersichtlicher. Offiziell heißt es: beide Formen koexistieren und keine wird abgekündigt.

Die Koexistenz in der Praxis

Die sauberste Organisation eines .claude/-Verzeichnisses sieht derzeit etwa so aus:

.claude/
├── commands/           # leicht: Single-File + simpler Prompt
│   ├── commit.md
│   └── pr-desc.md
├── skills/             # schwer: Multi-File / Fork / Access Control
│   ├── plan/
│   │   ├── SKILL.md
│   │   ├── research-prompt.md
│   │   └── risk-prompt.md
│   ├── deploy/
│   │   └── SKILL.md    # disable-model-invocation
│   └── rails-conventions/
│       └── SKILL.md    # automatische Aktivierung per paths glob
└── context/
    └── coding-standards.md

Nicht alles blind migrieren. Der Trigger lautet: „dieses Command beginnt zu wuchern" — über 200 Zeilen, Aufteilung der Doku nötig, Lust auf Subagent-Ausführung. Erst dann wird der Path geändert — eine Sache von wenigen Minuten.

Kurz und knapp

Gewünschte Fähigkeit	`commands/`	`skills/`
Single-File-Prompt-Shortcut	✅	✅
!`command` / `@file` / `$ARGUMENTS`	✅	✅
Zugriffssteuerung via `allowed-tools`	✅	✅
Begleitdateien (Referenzen, Scripts)	❌	✅
`disable-model-invocation` gegen Fehlauslösung	❌	✅
Isolierte Ausführung via `context: fork` + `agent:`	❌	✅
Automatische Aktivierung per `paths:` glob	❌	✅

Die ersten drei Zeilen sind in Commands und Skills identisch; die letzten vier gibt es nur bei Skills. Was du brauchst, nimmst du — der Rest bleibt, wo er ist.

Der offizielle Kurs neigt sich Richtung Skills, aber das Kompatibilitätsversprechen für commands/ ist eindeutig — das ist keine „sofort migrieren oder verschwinden"-Änderung, sondern ein Zusatz im Stil „hier ist mehr, ohne Zwang". Versteh die Unterschiede, migriere bedarfsgerecht, und zwinge dir keine kosmetische Einheitlichkeit auf.