Flags zu Claude Code Slash-Commands hinzufügen: 4 Muster, die wirklich funktionieren

Flags zu Claude Code Slash-Commands hinzufügen: 4 Muster, die wirklich funktionieren

Claude Code parst --flags für eigene Slash-Commands nicht so, wie man es erwarten würde — aber vier Muster liefern dieselbe UX, und drei davon sind sauberer als CLI-Parsing jemals war. So fügt man Claude Code Slash-Command Flags korrekt hinzu, mit funktionierenden .md-Dateien, die man sofort übernehmen kann.

Kurzantwort:

• Claude Code parst keine CLI-Flags (--json, --verbose) für eigene Commands — der Harness hat keinen Flag-Parser.
• Für CLI-ähnliche UX schreibt man Flags in $ARGUMENTS und lässt das LLM sie als natürliche Sprache interpretieren.
• Für typisierte Argumente verwendet man positionale $1/$2 oder benannte Argumente, die im arguments:-Frontmatter-Feld deklariert werden.
• Erwartete Flags sollte man in argument-hint: dokumentieren, damit sie im /-Autocomplete angezeigt werden.

Wie funktionieren Argumente bei Claude Code Slash-Commands eigentlich?

Der Harness von Claude Code ersetzt vor dem Senden des Commands an das LLM drei Arten von Tokens: $ARGUMENTS (den gesamten String nach dem Command-Namen), positionale $0/$1/$2 (Shell-artige Segmente in Anführungszeichen) und benannte $variablenName, die im Frontmatter deklariert sind. Einen eingebauten CLI-Flag-Parser gibt es nicht — --dry-run landet als Literaltext in $ARGUMENTS.

Hier ist der Teil, der alle stolpern lässt. Wenn man /deploy --staging --dry-run tippt, läuft Claude Code kein argparse gegen --staging --dry-run. Der Harness fügt den gesamten String überall dort ein, wo die .md-Datei $ARGUMENTS referenziert, und schickt den gerenderten Prompt dann ans Modell. Das LLM sieht --staging --dry-run als normalen Text und entscheidet, was zu tun ist.

Das ist kein Bug — es ist das Design. Der Harness ist eine Substitutionsschicht, kein Parser. Eingebaute Commands wie /clear und /help (siehe die offizielle CLI-Referenz) haben zwar Flags, aber eigene Commands, die man selbst schreibt, folgen anderen Regeln.

Der Harness von Claude Code substituiert Tokens und übergibt den gerenderten Prompt ans LLM. Einen Flag-Parser gibt es nicht.

In unserer eigenen Claude-Code-Arbeit ist genau diese Verwechslung am häufigsten — Entwickler verbringen eine Stunde damit herauszufinden, warum --verbose "nicht erkannt wird", bis sie merken, dass das LLM der Parser ist. Ab Claude Code v2.1.126 (Mai 2026) ist dieses Verhalten in der offiziellen Slash-Commands-Dokumentation dokumentiert und wird sich so bald nicht ändern. Slash-Commands sind ein Geschwister-Primitiv zu Claude Code Hooks — beide erweitern den Harness, aber Commands werden durch Benutzereingaben ausgelöst, Hooks durch Tool-Ereignisse.

Hier ist der kleinstmögliche eigene Command, der das Substitutionsmodell beweist:

---
description: Echo whatever the user types after the command
argument-hint: [anything]
---

The user passed these arguments: $ARGUMENTS

Repeat them back verbatim, then describe what the user probably meant.

Diese Datei als .claude/commands/echo-args.md speichern, /echo-args hello world --foo tippen, und das LLM sieht den Literalstring hello world --foo in den Prompt eingesetzt. Das ist das gesamte mentale Modell. Für eine ausführlichere Erläuterung, wie Command-Dateien mit dem breiteren Skills-System zusammenhängen, siehe unseren Skills-Leitfaden.

Den ersten parametrischen Slash-Command in 5 Minuten bauen

.claude/commands/greet.md mit drei Zeilen Frontmatter und einer Prompt-Zeile, die $ARGUMENTS referenziert, erstellen. Claude Code neu starten, /greet Welt tippen, und Welt wird in den Prompt eingesetzt, bevor das LLM ihn sieht. Das ist die gesamte Zeremonie — fünf Schritte, keine Build-Tools.

Das Rezept von Anfang bis Ende:

1. Das Verzeichnis erstellen. Vom Projektstamm aus mkdir -p .claude/commands ausführen. Der .claude/-Ordner liegt neben dem Code; Commands darin werden beim Start einer Claude-Code-Sitzung automatisch gefunden.
2. Die Command-Datei schreiben. Das unten stehende Snippet als .claude/commands/greet.md speichern.
3. Die Sitzung neu laden. Claude Code beenden und neu starten (oder /reload ausführen, wenn die Version das unterstützt). Commands werden beim Sitzungsstart einmalig gelesen.
4. Aufrufen. /greet Welt im Chat tippen.
5. Substitution prüfen. Das Transkript öffnen und bestätigen, dass das LLM Welt in den Prompt-Körper eingesetzt gesehen hat, nicht den Literaltoken $ARGUMENTS.

Die vollständige Datei:

---
description: Greet someone enthusiastically
argument-hint: <name>
---

You are a friendly assistant. Greet the person named "$ARGUMENTS" with one short, warm sentence. Then ask them what they're working on today.

Und die Terminal-Interaktion:

> /greet World
Hey World, great to see you! What are you working on today?

Fertig. Jetzt gibt es einen parametrischen Slash-Command. Das argument-hint-Feld ist das, was das /-Autocomplete-Menü dazu bringt, <name> neben dem Command anzuzeigen — kleiner UX-Effekt, große Wirkung.

Wenn $ARGUMENTS nicht substituiert wird, liegt es in 9 von 10 Fällen daran, dass man $args oder $ARGS geschrieben hat — der Token ist wörtlich in Großbuchstaben.

Der Token ist groß- und kleinschreibungssensitiv und exakt. $ARGUMENTS funktioniert. $arguments, $args, $ARGS, ${ARGUMENTS} schlagen alle lautlos fehl — sie werden als Literaltext ans LLM gesendet, und das Modell sieht nur Unsinn. Die Schreibweise dreifach prüfen, bevor man einen tieferliegenden Bug vermutet.

Welche Frontmatter-Felder steuern die Argumentverarbeitung?

Fünf Frontmatter-Felder bestimmen, wie ein Slash-Command Argumente behandelt: argument-hint (was Autocomplete anzeigt), allowed-tools (was der Command aufrufen darf), arguments (Deklaration benannter Argumente), model (welche Claude-Variante ihn ausführt) und disable-model-invocation (sperrt den Command auf Benutzer-seitigen Aufruf). Zusammen decken sie praktisch alle parametrischen Muster ab.

Hier ist die vollständige Frontmatter-Referenz für eigene Commands in Claude Code v2.1.x:

Zwei Fehlerquellen, die man sich merken sollte. Erstens ist allowed-tools leerzeichengetrennt, nicht kommagetrennt. Bash(git:*), Read, Edit schreiben wird lautlos nichts auf die Whitelist setzen — der Parser behandelt den gesamten String als einen missgeformten Eintrag. Bash(git:*) Read Edit verwenden. Das haben wir auf die harte Tour gelernt; für ähnliche Muster siehe unsere CLAUDE.md Best Practices zu Config-Datei-Konventionen.

Zweitens überschreibt das model:-Feld das Modell, das der Benutzer für die aktuelle Sitzung ausgewählt hat. Nützlich, wenn ein Command recheneffizient ist und man ihn auf einer kleineren Variante laufen lassen möchte — unser Leitfaden zur Modellauswahl hilft bei der Wahl zwischen Opus 4.7 und Sonnet für verschiedene Command-Typen.

Das disable-model-invocation: true-Feld ist das Sicherheitsnetz für destruktive Commands. Bei /deploy-prod oder /drop-database gesetzt, können andere Agenten diese Commands nicht programmatisch aufrufen — nur ein Mensch, der in den Chat tippt, kann sie auslösen.

Was sind die 4 Argument-Muster, die man wirklich braucht?

Vier Muster decken etwa 95% aller echten Claude-Code-Slash-Commands ab: (1) Boolean-Flag wie /deploy --dry-run, vom LLM aus $ARGUMENTS geparst, (2) Wert-Flag wie /test --filter auth, aus $ARGUMENTS extrahiert, (3) Pflichtpositional + optionales Flag wie /fix-issue 123 --priority high, das $1 und $ARGUMENTS kombiniert, und (4) strikt typisiertes Positional wie /migrate-component SearchBar React Vue mit $0/$1/$2.

Das Muster wählen, das zur Form des Commands passt. Hier ist eine funktionierende .md-Datei für jedes.

Muster 1: Boolean-Flag (--dry-run)

Wenn man CLI-Flag-UX möchte und das Flag einfach an/aus ist, lässt man das LLM es in $ARGUMENTS erkennen. Keine Parser-Logik, kein Positional-Jonglieren — die Regel einfach im Prompt beschreiben.

---
description: Deploy to staging or production
argument-hint: [--dry-run]
allowed-tools: Bash(git:*) Bash(npm:*) Read
---

Deploy the current branch to staging.

Arguments passed: $ARGUMENTS

If "$ARGUMENTS" contains "--dry-run", DO NOT actually deploy. Instead, print the deployment plan: which files would change, which env vars would be set, and which commands would run. Stop after printing the plan.

Otherwise, proceed with the real deployment using `git push staging main` and `npm run deploy:staging`.

/deploy --dry-run tippen und das LLM erkennt das Flag, gibt den Plan aus und stoppt. /deploy tippen und es wird deployed. Der Harness hat null Parsing gemacht — das LLM hat die gesamte Arbeit erledigt, was genau das ist, worin es gut ist.

Muster 2: Wert-Flag (--filter <Muster>)

Gleiche Idee, aber das Flag trägt jetzt einen Wert. Das LLM liest --filter auth aus $ARGUMENTS und verwendet den Teilstring danach.

---
description: Run the test suite, optionally filtered
argument-hint: [--filter <pattern>]
allowed-tools: Bash(npm:*) Read
---

Run the project's test suite.

Arguments: $ARGUMENTS

If "$ARGUMENTS" contains "--filter <pattern>", run only tests matching <pattern>. Use `npm test -- --grep <pattern>` for the actual command.

If no `--filter` is present, run the full suite with `npm test`.

Report pass/fail counts at the end.

/test --filter auth führt nur die Auth-Tests aus. /test führt alles aus. Das LLM extrahiert das Muster nach --filter zuverlässig, weil Claude bei dieser Art strukturierter Textextraktion wirklich gut ist — weit zuverlässiger, als die meisten erwarten.

Muster 3: Pflichtpositional + optionales Flag

Das ist das Hybrid-Muster, das wir in unserer eigenen Command-Bibliothek am häufigsten verwenden. $1 trägt das Pflichtargument, $ARGUMENTS trägt alles (damit das LLM noch optionale Flags erkennen kann). Es ist die sauberste Kombination, wenn ein Argument unverzichtbar ist und der Rest freier Kontext ist.

---
description: Fix a GitHub issue
argument-hint: <issue-number> [--priority high|medium|low] [context...]
allowed-tools: Bash(gh:*) Bash(git:*) Read Edit
---

Fix GitHub issue #$1.

Full arguments: $ARGUMENTS

Steps:
1. Run `gh issue view $1` to load the issue body.
2. Read the codebase to locate the relevant file(s).
3. If "$ARGUMENTS" contains "--priority high", create a hotfix branch off main. Otherwise branch off develop.
4. Apply the fix, run tests, and open a PR linked to the issue.

Anything else in $ARGUMENTS after the issue number is freeform context — fold it into your understanding of the bug.

Aufruf: /fix-issue 1234 --priority high das Login-Formular löscht die E-Mail-Adresse nach einem fehlgeschlagenen Versuch. $1 wird zu 1234. $ARGUMENTS wird zum gesamten nachfolgenden String, den das LLM sowohl auf das Prioritäts-Flag als auch auf die freie Beschreibung hin parst.

Wir nutzen genau diese $1 + $ARGUMENTS-Kombination in unserem /fix-issue-Command — $1 für die Issue-Nummer, der Rest für freien Kontext, den das LLM parst. Es war das Muster mit dem höchsten ROI in einem Jahr täglicher Claude-Code-Nutzung.

Muster 4: Striktes Positional (typisiert)

Wenn alle Argumente Pflichtfelder sind und die Reihenfolge zählt, lässt man $ARGUMENTS ganz weg. $0/$1/$2 (oder benannte Argumente über das arguments:-Frontmatter-Feld) für eindeutige typisierte Slots verwenden.

---
description: Migrate a component between frameworks
argument-hint: <component> <from-framework> <to-framework>
arguments: [component, fromFramework, toFramework]
allowed-tools: Read Edit Write
---

Migrate the component named "$component" from $fromFramework to $toFramework.

1. Read the existing component file (search for `$component.{jsx,tsx,vue,svelte}`).
2. Translate the component idioms from $fromFramework to $toFramework: lifecycle methods, state handling, prop syntax, event binding.
3. Write the new file in the matching extension for $toFramework.
4. Print a diff summary at the end.

If $fromFramework or $toFramework is unsupported, abort and tell the user which frameworks ARE supported (React, Vue, Svelte, Solid).

Aufruf: /migrate-component SearchBar React Vue. Die Deklaration benannter Argumente macht Autocomplete und Prompt-Körper selbst-dokumentierend — wer migrate-component.md liest, sieht auf den ersten Blick, welcher Slot welchem entspricht. Dieses Muster glänzt bei Commands mit drei oder mehr Pflichtargumenten. Dieser Stil findet sich auch in Community-Bibliotheken wie wshobson/commands auf GitHub.

Boolean- und Wert-Flags funktionieren, weil das LLM ein flexibler Parser ist. Striktes Positional funktioniert, weil keine LLM-Intelligenz nötig ist. Die Kombination aus beidem ist das eigentliche Geheimnis.

Wann sollte man $ARGUMENTS vs. Positional vs. Benannt verwenden?

$ARGUMENTS verwenden, wenn Argumente CLI-Flag-artig sind und man LLM-flexibles Parsing möchte. Positionales $1/$2 verwenden, wenn Argumente typisiert, geordnet sind und null LLM-Mehrdeutigkeit gewünscht wird. Benanntes arguments: verwenden, wenn es 3+ Argumente gibt und Klarheit im Autocomplete wichtiger ist als Kürze. Hier die Entscheidungsmatrix:

Der Instinkt der meisten Entwickler ist, zuerst zu $ARGUMENTS zu greifen, weil es der Bash-Welt am nächsten kommt, die sie kennen. Für Prototypen ist das in Ordnung, aber typisiertes Positional ist wirklich besser, wenn der Vertrag stabil ist. Das LLM muss $1 nicht parsen — es ist bereits ein sauberer String.

Eine grobe Faustregel: Wenn man die Signatur des Commands in einem englischen Satz beschreiben kann, ohne die Wörter "oder" und "optional" zu verwenden, positional wählen. Wenn diese Wörter benötigt werden, $ARGUMENTS wählen.

Sind Slash-Commands jetzt dasselbe wie Skills?

Anthropic hat eigene Commands im Frühjahr 2026 in das breitere Skills-System integriert, aber .claude/commands/*.md-Dateien funktionieren weiterhin und verwenden dieselben Frontmatter-Felder. Ein Skill ist ein Verzeichnis (.claude/skills/foo/SKILL.md plus unterstützende Dateien) mit zusätzlicher Aufrufsteuerung wie disable-model-invocation. Ein Command ist eine einzelne .md-Datei. Gleiche Substitutionsregeln, unterschiedliche Verpackung.

Hier ist der praktische Unterschied:

.claude/commands/ ist also nicht veraltet. Anthropic hat beim Zusammenführen der Systeme explizit die Datei-Form funktionsfähig gelassen — zu viele Projekte haben Command-Bibliotheken in der Versionskontrolle. Wenn unterstützende Dateien benötigt werden (wie eine CONTRIBUTING.md-Referenz, die der Skill lädt, oder eine template.json, die er kopiert), Skills verwenden. Sonst bei Commands bleiben.

Die Zusammenführung ist Teil einer breiteren Bewegung hin zum offenen agentskills.io-Standard und eine von mehreren v2.1.x-Änderungen, die es wert sind zu kennen — unser Überblick über Claude Code v2.1-Features zeigt das vollständige Feature-Bild, und unser Skills-Leitfaden bietet eine ausführlichere Skills-Einführung.

Warum substituiert mein $ARGUMENTS nicht? Häufige Bugs behoben

Fünf häufige Gründe, warum $ARGUMENTS nicht substituiert: (1) Kleinbuchstaben oder Kurzform des Tokens ($args, $ARGS, $arguments — es muss literal $ARGUMENTS sein), (2) Mehrteilige Argumente nicht in Anführungszeichen gesetzt (/cmd hello world teilt auf; /cmd "hello world" hält zusammen), (3) allowed-tools kommagetrennt statt leerzeichengetrennt, (4) Command-Datei nicht in .claude/commands/ oder .claude/skills/, (5) Claude-Code-Sitzung muss nach dem Bearbeiten der Datei neu gestartet werden.

$ARGUMENTS erscheint als Literaltext im LLM-Prompt

Symptom: Der Prompt zeigt $ARGUMENTS als Klartext in der Modellantwort, als hätte der Harness es ignoriert. Ursache: Falsche Schreibweise. Der Token ist literal $ARGUMENTS — acht Zeichen, alle in Großbuchstaben. Lösung: Die .md öffnen, nach $args, $ARGS, $arguments, ${ARGUMENTS} suchen und durch $ARGUMENTS ersetzen. Der $args-Tippfehler-Bug hat jeden Entwickler in unserem Team mindestens einmal erwischt; es ist der mit Abstand häufigste Bug in der "unbekannter Slash-Command"-Familie.

Mehrteiliges Argument wird unerwartet aufgespalten

Symptom: Man hat /migrate-component Search Bar React Vue ausgeführt und $1 ist Search, $2 ist Bar. Ursache: Leerzeichen teilen positionale Argumente auf. Lösung: Das mehrteilige Argument in Anführungszeichen setzen: /migrate-component "Search Bar" React Vue. Jetzt ist $1 gleich Search Bar. Das entspricht dem Shell-Verhalten, das der Harness bewusst spiegelt.

allowed-tools wird nicht respektiert

Symptom: Der Command läuft, aber Claude verweigert die Nutzung von Tools, die man vermeintlich auf die Whitelist gesetzt hat, oder ruft Tools auf, die nicht gelistet sind. Ursache: Kommagetrennt statt leerzeichengetrennt. Lösung: allowed-tools: Bash, Read, Edit in allowed-tools: Bash Read Edit ändern. Für Tool-Submuster das Format Bash(git:*) Bash(npm:*) Read verwenden.

Command erscheint nicht im /-Autocomplete

Symptom: Man tippt / und der Command ist nicht in der Liste. Ursache: Falscher Dateiort, fehlendes Frontmatter oder falsch gesetztes disable-model-invocation. Lösung: Bestätigen, dass die Datei unter .claude/commands/yourcmd.md (oder .claude/skills/yourcmd/SKILL.md) relativ zum Projektstamm liegt. Bestätigen, dass das Frontmatter mindestens ein description:-Feld hat. Wenn disable-model-invocation: true gesetzt wurde, erscheint der Command nicht für andere Agenten, aber weiterhin im manuell getippten /-Menü.

Die .md-Datei wurde bearbeitet, aber nichts hat sich geändert

Symptom: Man hat den Bug behoben, die Datei gespeichert, den Command erneut ausgeführt — dasselbe fehlerhafte Verhalten. Ursache: Claude Code cached Command-Dateien beim Sitzungsstart. Lösung: Claude Code beenden und neu starten, oder /reload ausführen, wenn die Version das unterstützt.

Claude Code liest .md-Dateien beim Sitzungsstart. Wenn man einen Command bearbeitet und er "sich nicht ändert", die Sitzung neu starten, bevor man einen tieferliegenden Bug vermutet.

Für Randfälle jenseits dieser fünf sind die Claude-Code-Repo-Issues der beste Anlaufpunkt. Die meisten seltsamen Substitutions-Bugs, die wir gesehen haben, sind eine Variante eines der obigen Fälle.

FAQ: Argumente für Claude Code Slash-Commands

Wie gibt man Argumente an einen Claude Code Slash-Command weiter?

Den Argument-String nach dem Command-Namen tippen: /greet Welt. In der .md-Datei des Commands den Wert als $ARGUMENTS (den gesamten String), $1 (erstes Positional) oder $variablenName referenzieren (wenn man arguments: [variablenName] im Frontmatter deklariert hat). Der Harness substituiert den Token, bevor der Prompt ans LLM gesendet wird.

Was ist $ARGUMENTS in Claude Code?

$ARGUMENTS ist ein Substitutions-Token in eigenen Slash-Command-Dateien, das der Claude-Code-Harness durch den gesamten Argument-String ersetzt, den der Benutzer nach dem Command-Namen eingegeben hat. Wenn ein Benutzer /deploy --staging --dry-run ausführt, wird $ARGUMENTS zum Literalstring --staging --dry-run im gerenderten Prompt, bevor das LLM ihn je sieht.

Können Claude Code Slash-Commands CLI-artige Flags wie --json aufnehmen?

Nicht nativ — der Harness hat keinen Flag-Parser für eigene Commands. Man schreibt --json in $ARGUMENTS, und der Prompt weist das LLM an, es zu erkennen und entsprechend zu handeln. Das funktioniert, weil Claude ein flexibler Parser strukturierter Texte ist. Eingebaute Commands wie /clear und /help haben echte Flags, aber eigene Commands folgen ausschließlich Substitutions-Regeln.

Was ist der Unterschied zwischen $1, $ARGUMENTS und $name in Claude Code?

$1 ist das erste leerzeichengetrennte positionale Argument ($2 ist das zweite usw.). $ARGUMENTS ist der gesamte Argument-String wörtlich, einschließlich aller positionalen Teile und Flags. $name ist ein benanntes Argument, das im Frontmatter arguments: [name]-Feld deklariert ist — nützlich, wenn man selbst-dokumentierende positionale Slots ohne numerische Indizierung möchte.

Wie funktioniert argument-hint in Claude Code?

argument-hint ist ein Frontmatter-Feld, das steuert, was das /-Autocomplete-Menü neben dem Command-Namen anzeigt. argument-hint: <issue-number> [--priority high] zu setzen zeigt genau dieses Template an, nachdem der Benutzer / tippt. Es ist nur UX — es validiert oder parst keine Argumente. Es lohnt sich trotzdem es zu setzen, weil es die billigste Dokumentation ist, die man je schreiben wird.

Wie erstellt man einen eigenen Slash-Command mit mehreren Argumenten?

Zwei saubere Optionen. Für Positional: $1, $2, $3 im Prompt-Körper referenzieren. Für Benannt: arguments: [first, second, third] im Frontmatter deklarieren und $first, $second, $third referenzieren. Benannt ist besser lesbar bei drei oder mehr Argumenten. $ARGUMENTS nur verwenden, wenn das LLM einen freien nachfolgenden String nach den Pflicht-Positionals parsen soll.

Ist .claude/commands/ zugunsten von .claude/skills/ veraltet?

Nein. Anthropic hat die beiden Systeme im Frühjahr 2026 zusammengeführt, aber .claude/commands/*.md mit identischen Substitutions-Regeln explizit funktionsfähig gelassen. Commands für Einzel-Datei-Automatisierungen verwenden, Skills für Mehrfach-Datei-Bündel (SKILL.md plus Templates oder Referenzen). Gleiche Frontmatter-Felder, gleiche $ARGUMENTS-Logik, unterschiedliche Verpackung. Beide sind als von v2.1.126 an erster Klasse.

Warum substituiert $ARGUMENTS in meinem Command nicht?

Die drei häufigsten Ursachen in der Reihenfolge ihrer Häufigkeit: Groß-/Kleinschreibungsfehler (muss $ARGUMENTS in Großbuchstaben sein, nicht $args oder $arguments), falscher Dateiort (muss in .claude/commands/ oder .claude/skills/ liegen) oder veraltete Sitzung (Claude Code liest Command-Dateien beim Sitzungsstart, also nach dem Bearbeiten neu starten). Wenn alle drei geprüft sind, /echo-args foo mit dem minimalen Beispiel aus dem ersten H2-Abschnitt ausführen, um das Problem zu isolieren.

Kann man bestimmte Argumente als Pflichtfelder kennzeichnen?

Nicht auf Harness-Ebene — es gibt keine native Pflichtargument-Validierung. Das Muster ist, das LLM im Prompt anzuweisen: "Wenn $1 leer ist, stoppe und sag dem Benutzer, eine Issue-Nummer anzugeben." Das Modell erzwingt den Vertrag. Es ist nicht narrensicher, aber in der Praxis zuverlässig genug für den täglichen Einsatz, besonders in Kombination mit einem klaren argument-hint.

Überschreibt model: im Frontmatter CLI-Flags?

Ja — das Frontmatter gewinnt. Wenn die Command-Datei model: claude-haiku-4 deklariert, läuft dieser Command auf Haiku, unabhängig davon, welches Modell der Benutzer für die Sitzung ausgewählt hat. Das ist nützlich für günstige, häufig aufgerufene Commands, die man von Opus fernhalten möchte. Unser Leitfaden zum Wechseln zwischen Claude-Modellen hilft bei der Wahl der richtigen Variante für verschiedene Command-Typen.

Fazit

Vier Muster. Das passende zur Form des Commands wählen:

• Boolean-Flag (--dry-run) — in $ARGUMENTS schreiben, vom LLM erkennen lassen.
• Wert-Flag (--filter <Muster>) — gleicher Ansatz, das LLM extrahiert den Wert.
• Pflichtpositional + optionales Flag — $1 für das Muss-Argument, $ARGUMENTS für den Rest.
• Striktes Positional — $0/$1/$2 (oder benannt via arguments:), wenn jeder Slot Pflicht und geordnet ist.

Jetzt, wo die Commands parametrisch sind, ist der nächste Schritt, sie in Agenten-Workflows einzubinden — mit unserem Claude-Skills-Leitfaden für das Mehrfach-Datei-Paket-Upgrade beginnen, oder alternative KI-Coding-Tools durchstöbern, wenn man Harnesses vergleicht. Der .claude/commands/-Ordner ist in jedem Fall jetzt deutlich nützlicher.