
Sådan tilføjer du flag til Claude Code slash-kommandoer: 4 mønstre, der faktisk virker
Claude Code parser ikke --flags på den måde, man ville forvente for brugerdefinerede slash-kommandoer, men fire mønstre giver dig den samme UX, og tre af dem er renere, end CLI-parsing nogensinde har været. Sådan tilføjer du korrekt flag til Claude Code slash-kommandoer, med fungerende .md-filer, du kan kopiere allerede i dag.
Hurtigt svar:
- Claude Code parser ikke CLI-flag (
--json,--verbose) for brugerdefinerede kommandoer, brugen har ingen flag-parser. - For CLI-agtig UX, skriv flag ind i
$ARGUMENTSog lad LLM'en fortolke dem som naturligt sprog. - For typede argumenter, brug positionelle
$1/$2eller navngivne argumenter erklæret iarguments:frontmatter-feltet. - Dokumentér forventede flag i
argument-hint:, så/-autofuldførelsen viser dem til brugeren.
Hvordan fungerer argumenter til Claude Code-skråstregskommandoer egentlig?
Claude Code erstatter tre slags tokens, før din kommando sendes til LLM'en: $ARGUMENTS (hele strengen efter kommandonavnet), positionelle $0/$1/$2 (shell-lignende citerede segmenter) og navngivne $variableName erklæret i frontmatter. Der er ingen indbygget CLI-flag-parser, --dry-run ender i $ARGUMENTS som bogstavelig tekst.
Her er den del, der forvirrer alle. Når du skriver /deploy --staging --dry-run, kører Claude Code ikke argparse mod --staging --dry-run. I stedet indsætter den hele strengen, der hvor din .md-fil refererer til $ARGUMENTS, og sender derefter den renderede prompt til modellen. LLM'en ser --staging --dry-run som almindelig tekst og beslutter selv, hvad der skal gøres.
Det er ikke en fejl, det er designet. Den er et substitutionslag, ikke en parser. Indbyggede kommandoer som /clear og /help (se den officielle CLI-reference) har ganske vist flag, men de brugerdefinerede kommandoer, du selv skriver, følger andre regler.
Claude Code erstatter tokens og overlader derefter den renderede prompt til LLM'en. Der er ingen flag-parser.
I vores eget arbejde med Claude Code er den absolut hyppigste forvirring netop dette: udviklere bruger en time på at finde ud af, hvorfor --verbose "ikke bliver genkendt", før de indser, at LLM'en er parseren. Fra og med Claude Code v2.1.126 (maj 2026) er denne adfærd dokumenteret i den officielle skråstregskommando-dokumentation og ændrer sig ikke foreløbig. Skråstregskommandoer er en søsterprimitiv til Claude Code hooks — begge udvider Claude Code, men kommandoer udløses af brugerinput, mens hooks udløses af værktøjshændelser.
Her er den mindst mulige brugerdefinerede kommando, der beviser substitutionsmodellen:
---
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.Gem den som .claude/commands/echo-args.md, skriv /echo-args hello world --foo, og LLM'en vil se den bogstavelige streng hello world --foo indsat i prompten. Det er hele den mentale model. For en dybere gennemgang af, hvordan kommandofiler relaterer sig til det bredere skills-system, se vores Skills-introduktion.
Byg din første parametriske slash-kommando på 5 minutter
Opret .claude/commands/greet.md med tre linjer frontmatter og én prompt-linje, der refererer til $ARGUMENTS. Genstart Claude Code, skriv /greet World, og se World blive indsat i prompten, før LLM'en ser det. Det er hele ceremonien, fem trin, ingen build-værktøjer.
Her er opskriften fra start til slut:
- Opret mappen. Fra din projektrod skal du køre
mkdir -p .claude/commands..claude/-mappen ligger ved siden af din kode; kommandoer i den opdages automatisk, når Claude Code starter en session. - Skriv kommandofilen. Gem nedenstående snippet som
.claude/commands/greet.md. - Genindlæs din session. Afslut og genstart Claude Code (eller kør
/reload, hvis din version understøtter det). Kommandoer læses én gang ved sessionens start. - Kald den. Skriv
/greet Worldi chatten. - Bekræft substitutionen. Åbn transskriptionen, og bekræft, at LLM'en så
Worldinterpoleret i promptens indhold, ikke det bogstavelige token$ARGUMENTS.
Her er den fulde fil:
---
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.Og terminalinteraktionen:
> /greet World
Hey World, great to see you! What are you working on today?Det var det. Du har nu en parametrisk slash-kommando. Det er argument-hint-feltet, der får /-autofuldførelsesmenuen til at vise <name> ud for din kommando, et lille UX-touch med stor gevinst.
Hvis
$ARGUMENTSikke substitueres, skyldes det 9 ud af 10 gange, at du har skrevet$argseller$ARGS, tokenet er bogstaveligt skrevet med store bogstaver.
Tokenet skelner mellem store og små bogstaver og er eksakt. $ARGUMENTS virker. $arguments, $args, $ARGS, ${ARGUMENTS} fejler alle lydløst, de sendes til LLM'en som bogstavelig tekst, og modellen ser bare vrøvl. Tjek stavningen grundigt, før du antager en dybere fejl.
Hvilke frontmatter-felter styrer argumenthåndtering?
Fem frontmatter-felter former, hvordan en slash-kommando håndterer argumenter: argument-hint (hvad autofuldførelse viser), allowed-tools (hvad kommandoen må kalde), arguments (erklæring af navngivne argumenter), model (hvilken Claude-variant der kører den) og disable-model-invocation (låser kommandoen til kun at kunne kaldes af brugere). Tilsammen dækker de stort set alle parametriske mønstre, du får brug for.
Her er den komplette frontmatter-reference for brugerdefinerede kommandoer i Claude Code v2.1.x:
| Felt | Formål | Eksempel | Påkrævet? |
|---|---|---|---|
description: | Enlinjes opsummering i /-menuen | Run staging deploy | Anbefalet |
argument-hint: | Autofuldførelsestip vist efter kommandonavnet | [--dry-run] [--region us] | Anbefalet |
allowed-tools: | Hvidliste over værktøjer, kommandoen må kalde | Bash(git:*) Read Edit | Valgfrit |
arguments: | Erklæring af navngivne argumenter | [issue, branch] | Valgfrit |
model: | Tilsidesæt model for denne kommando | claude-opus-4-7 | Valgfrit |
disable-model-invocation: | Forhindr agenten i at kalde denne kommando | true | Valgfrit |
context: fork | Kør i isoleret kontekst | fork | Valgfrit |
To faldgruber, der er værd at klistre op på skærmen. For det første er allowed-tools mellemrumssepareret, ikke kommasepareret. Skriver du Bash(git:*), Read, Edit, vil intet blive hvidlistet — fortolkeren behandler hele strengen som én fejlformet post. Brug Bash(git:*) Read Edit. Vi lærte det på den hårde måde; for flere mønstre som dette, se vores CLAUDE.md-best practices om konfigurationsfilkonventioner.
For det andet tilsidesætter model:-feltet den model, brugeren aktuelt har valgt til sessionen. Nyttigt, når en kommando er beregningsmæssigt billig, og du vil tvinge den over på en mindre variant — se vores guide om modelvalg for at vælge mellem Opus 4.7 og Sonnet til forskellige kommandotyper.
Feltet disable-model-invocation: true er dit sikkerhedsnet for destruktive kommandoer. Sæt det på /deploy-prod eller /drop-database, så kan andre agenter ikke kalde disse kommandoer programmatisk — kun et menneske, der skriver i chatten, kan udløse dem.
Hvad er de 4 argumentmønstre, du faktisk kommer til at bruge?
Fire mønstre dækker cirka 95 % af de reelle Claude Code-skråstregskommandoer: (1) boolesk flag som /deploy --dry-run, der parses af LLM'en fra $ARGUMENTS, (2) værdiflag som /test --filter auth, der udtrækkes fra $ARGUMENTS, (3) påkrævet positionsargument + valgfrit flag som /fix-issue 123 --priority high, der blander $1 og $ARGUMENTS, og (4) strengt typet positionsargument som /migrate-component SearchBar React Vue, der bruger $0/$1/$2.
Vælg det mønster, der passer til din kommandos form. Her er en fungerende .md-fil til hvert mønster.

Mønster 1: Boolesk flag (--dry-run)
Når du vil have CLI-flag-UX, og flaget blot er til/fra, så lad LLM'en om at registrere det inde i $ARGUMENTS. Ingen parsingslogik, ingen positionel jonglering — beskriv bare reglen i prompten.
---
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`.Skriv /deploy --dry-run, og LLM'en ser flaget, udskriver planen og stopper. Skriv /deploy, og den deployer. Brugeren foretog nul parsing, LLM'en udførte alt arbejdet, hvilket er præcis det, den er god til.
Mønster 2: Værdivlag (--filter <pattern>)
Samme idé, men nu har flaget en værdi. LLM'en læser --filter auth ud af $ARGUMENTS og bruger understrengen efter det.
---
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 kører kun auth-testene. /test kører alt. LLM'en udtrækker mønsteret efter --filter pålideligt, fordi Claude er virkelig god til denne slags udtrækning af struktureret tekst — langt mere pålideligt, end folk forventer.
Mønster 3: Obligatorisk positionelt argument + valgfrit flag
Det er den hybrid, vi selv bruger mest i vores eget kommandobibliotek. $1 bærer det obligatoriske argument, $ARGUMENTS bærer alt (så LLM'en stadig kan få øje på valgfrie flag). Det er den reneste kombination, når ét argument er ufravigeligt, og resten er frit formuleret kontekst.
---
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.Kaldes som /fix-issue 1234 --priority high the login form blanks the email field after a failed attempt. $1 opløses til 1234. $ARGUMENTS opløses til hele den efterfølgende streng, som LLM'en gladeligt parser for både prioritetsflaget og den frit formulerede beskrivelse.
Vi bruger præcis denne $1 + $ARGUMENTS-kombination i vores /fix-issue-kommando, $1 til issue-nummeret, resten til frit formuleret kontekst, som LLM'en parser. Det har været det mønster med højeste ROI gennem et år med daglig brug af Claude Code.
Mønster 4: Streng positionel (typet)
Når alle argumenter er påkrævede, og rækkefølgen betyder noget, kan du helt droppe $ARGUMENTS. Brug $0/$1/$2 (eller navngivne argumenter via arguments:-frontmatterfeltet) til entydige, typede pladser.
---
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).Kald den som /migrate-component SearchBar React Vue. Erklæringen med navngivne argumenter gør både autofuldførelsen og promptteksten selvdokumenterende – enhver, der læser migrate-component.md, kan med et øjekast se, hvilken plads der er hvilken. Dette mønster er ideelt til kommandoer med tre eller flere påkrævede argumenter. Du kan også se denne stil i fællesskabsbiblioteker som wshobson/commands på GitHub.
Booleske flag og værdiflag virker, fordi LLM'en er en fleksibel parser. Streng positionel virker, fordi der ikke kræves nogen LLM-intelligens. At blande de to er hemmeligheden.
Hvornår bør du bruge $ARGUMENTS vs. positionelle vs. navngivne?
Brug $ARGUMENTS, når argumenterne er i CLI-flag-stil, og du ønsker LLM-fleksibel parsing. Brug positionelle $1/$2, når argumenterne er typede, ordnede, og du ønsker nul LLM-tvetydighed. Brug navngivne arguments:, når der er 3+ argumenter, og klarhed i autofuldførelsen betyder mere end kompakthed. Her er beslutningsmatricen:
| Brugsscenarie | Bedste valg | Syntaks | Fordele | Ulemper | Eksempel |
|---|---|---|---|---|---|
| CLI-flag-UX med valgfrie argumenter | $ARGUMENTS | $ARGUMENTS i brødteksten | Fleksibel, spejler Unix-UX | Parsing på LLM-siden, ingen validering | /deploy --staging --dry-run |
| Typede, ordnede påkrævede argumenter | Positionelle $0/$1 | $0 $1 $2 i brødteksten | Nul tvetydighed, hurtig | Sårbar over for argumentrækkefølge | /migrate Button React Vue |
| 3+ argumenter, hvor klarhed er vigtig | Navngivne via arguments: | arguments: [a, b, c] derefter $a $b $c | Selvdokumenterende | Omstændelig frontmatter | /issue 123 main high |
| Blandet påkrævede + valgfrie | Hybrid ($1 + $ARGUMENTS) | $1 then $ARGUMENTS | Det bedste fra begge | To mentale modeller i én fil | /fix-issue 123 --priority high |

Instinktet hos de fleste udviklere er at række ud efter $ARGUMENTS først, fordi det føles tættest på den bash-verden, de kender. Det er fint til prototyper, men typede positionelle er reelt bedre, når kontrakten er stabil. LLM'en behøver ikke at parse $1, det er allerede en ren streng.
En grov tommelfingerregel: hvis du kan beskrive kommandoens signatur i én engelsk sætning uden at bruge ordene "or" og "optionally," så brug positionelle. Hvis du har brug for de ord, så brug $ARGUMENTS.
Er slash-kommandoer nu det samme som skills?
I foråret 2026 fusionerede Anthropic brugerdefinerede kommandoer ind i det bredere skills-system, men .claude/commands/*.md-filer virker stadig og bruger den samme frontmatter. En skill er en mappe (.claude/skills/foo/SKILL.md plus understøttende filer) med ekstra kontrol over aktivering, såsom disable-model-invocation. En kommando er en enkelt .md-fil. Samme substitutionsregler, forskellig indpakning.
Her er den praktiske forskel:
| Aspekt | .claude/commands/foo.md | .claude/skills/foo/ |
|---|---|---|
| Filform | Enkelt .md-fil | Mappe med SKILL.md + understøttende filer |
| Bedst til | Hurtige engangskommandoer, projektlokale automatiseringer | Genanvendelige bundter med skabeloner, referancer, underfiler |
| Kontrol over aktivering | Kun frontmatter | Frontmatter + disable-model-invocation pr. fil |
| Argumenthåndtering | Identisk ($ARGUMENTS, $1, navngivne) | Identisk ($ARGUMENTS, $1, navngivne) |

Så nej, .claude/commands/ er ikke udfaset. Anthropic holdt udtrykkeligt filformen kørende, da de fusionerede systemerne, for mange projekter har kommandobiblioteker fastlåst i versionskontrol. Hvis du vil have understøttende filer (som en CONTRIBUTING.md-reference, din skill indlæser, eller en template.json, den kopierer), så brug skills. Ellers kan du blive ved kommandoer.
Fusionen er en del af en bredere satsning mod den åbne agentskills.io-standard, og det er en af flere v2.1.x-ændringer, der er værd at kende, se vores oversigt over Claude Code v2.1-funktioner for det samlede funktionslandskab og vores skills-vejledning for en dybere gennemgang af skills.
Hvorfor substitueres min $ARGUMENTS ikke? Almindelige fejl løst
Fem almindelige årsager til, at $ARGUMENTS ikke substitueres: (1) token med små bogstaver eller forkortet form ($args, $ARGS, $arguments — det skal være ordret $ARGUMENTS), (2) argumenter med flere ord uden anførselstegn (/cmd hello world opdeles; /cmd "hello world" holder det samlet), (3) allowed-tools er kommasepareret i stedet for mellemrumssepareret, (4) kommandofilen ligger ikke i .claude/commands/ eller .claude/skills/, (5) Claude Code-sessionen skal genindlæses, efter at filen er redigeret.
$ARGUMENTS vises bogstaveligt i LLM-prompten
Symptom: Din prompt viser $ARGUMENTS som almindelig tekst i modellens svar, som om brugeren ignorerede den. Årsag: Forkert versalbrug eller forkert stavemåde. Tokenet er bogstaveligt talt $ARGUMENTS, otte tegn, kun store bogstaver. Løsning: Åbn .md-filen, grep efter $args, $ARGS, $arguments, ${ARGUMENTS}, og erstat med $ARGUMENTS. $args-stavefejlsbuggen har ramt alle udviklere på vores team mindst én gang; det er den klart hyppigste bug i familien af "ukendt skråstregskommando".
Argument med flere ord opdeles uventet
Symptom: Du kørte /migrate-component Search Bar React Vue, og $1 er Search, $2 er Bar. Årsag: Blanke tegn opdelte positionsargumenter. Løsning: Sæt argumentet med flere ord i anførselstegn: /migrate-component "Search Bar" React Vue. Nu er $1 Search Bar. Dette matcher shell-adfærd, som er den mentale model, som brugen bevidst afspejler.
allowed-tools bliver ikke overholdt
Symptom: Kommandoen kører, men Claude nægter at kalde de værktøjer, du troede, du havde hvidlistet, eller også kalder den værktøjer, du ikke har angivet. Årsag: Kommasepareret i stedet for mellemrumssepareret. Løsning: Ændr allowed-tools: Bash, Read, Edit til allowed-tools: Bash Read Edit. For værktøjs-undermønstre skal du formatere det som Bash(git:*) Bash(npm:*) Read.
Kommandoen vises ikke i /-autofuldførelse
Symptom: Du skriver /, og din kommando er ikke på listen. Årsag: Filplacering, manglende frontmatter eller disable-model-invocation er sat forkert. Løsning: Bekræft, at filen ligger på .claude/commands/yourcmd.md (eller .claude/skills/yourcmd/SKILL.md) i forhold til din projektrod. Bekræft, at frontmatteren mindst har et description:-felt. Hvis du sætter disable-model-invocation: true, vises kommandoen ikke for andre agenter, men den vises stadig i den menneskeskrevne /-menu.
Du redigerede .md-filen, men intet ændrede sig
Symptom: Du rettede fejlen, gemte filen og kørte kommandoen igen, men den samme fejlbehæftede adfærd fortsatte. Årsag: Claude Code cacher kommandofiler ved sessionsstart. Løsning: Afslut og genstart Claude Code, eller kør /reload, hvis din version understøtter det.
Claude Code læser
.md-filer ved sessionsstart. Hvis du redigerer en kommando, og den 'ikke ændrer sig', så genstart din session, før du antager en dybere fejl.
For edge cases ud over disse fem er Claude Code-repoets issues det bedste sted at søge. De fleste mærkelige substitutionsfejl, vi har set, er en variant af en af ovenstående.
FAQ: Argumenter til slash-kommandoer i Claude Code
Hvordan sender jeg argumenter til en Claude Code-skråstregskommando?
Skriv argumentstrengen efter kommandonavnet: /greet World. I din kommandos .md-fil refererer du til værdien som $ARGUMENTS (hele strengen), $1 (første positionsargument) eller $variableName (hvis du har erklæret arguments: [variableName] i frontmatter). Systemet erstatter tokenet, inden prompten sendes til LLM'en.
Hvad er $ARGUMENTS i Claude Code?
$ARGUMENTS er en substitutionstoken i brugerdefinerede slashkommandofiler, som Claude Code erstatter med hele den argumentstreng, brugeren har indtastet efter kommandonavnet. Hvis en bruger kører /deploy --staging --dry-run, bliver $ARGUMENTS til den bogstavelige streng --staging --dry-run i den gengivne prompt, før LLM'en overhovedet ser den.
Kan Claude Codes slash-kommandoer tage CLI-lignende flag som --json?
Ikke fra naturens hånd — brugeren har ingen flag-parser til brugerdefinerede kommandoer. Du skriver --json ind i $ARGUMENTS, og din prompt instruerer LLM'en om at genkende det og handle derefter. Dette virker, fordi Claude er en fleksibel fortolker af struktureret tekst. Indbyggede kommandoer som /clear og /help har rigtige flag, men brugerdefinerede kommandoer, du selv skriver, følger reglerne for ren substitution.
Hvad er forskellen på $1, $ARGUMENTS og $name i Claude Code?
$1 er det første positionelle argument adskilt af blanktegn ($2 er det andet, og så videre). $ARGUMENTS er hele argumentstrengen ordret, inklusive alle positionelle dele og eventuelle flag. $name er et navngivet argument erklæret i frontmatter-feltet arguments: [name], hvilket er nyttigt, når du vil have selvbeskrivende positionelle pladser uden numerisk indeksering.
Hvordan fungerer argument-hint i Claude Code?
argument-hint er et frontmatter-felt, der styrer, hvad /-autofuldførelsesmenuen viser ud for dit kommandonavn. Hvis du sætter argument-hint: <issue-number> [--priority high], vises præcis den skabelon, efter brugeren har tastet /. Det er udelukkende til UX – det validerer eller parser ikke argumenter. Det er stadig værd at sætte, fordi det er den billigste dokumentation, du nogensinde kommer til at skrive.
Hvordan opretter jeg en brugerdefineret slash-kommando med flere argumenter?
To gode muligheder. For positionelle: referér til $1, $2, $3 i selve prompten. For navngivne: erklær arguments: [first, second, third] i frontmatter og referér til $first, $second, $third. Navngivne er mere læsevenlige ved tre eller flere argumenter. Brug kun $ARGUMENTS, når du vil have LLM'en til at fortolke en frit formuleret afsluttende streng efter de påkrævede positionelle pladser.
Er .claude/commands/ udfaset til fordel for .claude/skills/?
Nej. Anthropic sammenlagde de to systemer i foråret 2026, men holdt udtrykkeligt .claude/commands/*.md fungerende med identiske substitutionsregler. Brug commands til enkelt-fils automatiseringer og skills til multi-fils bundter (SKILL.md plus skabeloner eller referencer). Samme frontmatter, samme $ARGUMENTS-adfærd, forskellig emballering. Begge er førsteklasse fra og med v2.1.126.
Hvorfor substitueres $ARGUMENTS ikke i min kommando?
De tre hyppigste årsager, i rækkefølge efter hyppighed: fejl i store/små bogstaver (skal være med store bogstaver $ARGUMENTS, ikke $args eller $arguments), forkert filplacering (skal ligge i .claude/commands/ eller .claude/skills/) eller en forældet session (Claude Code læser kommandofiler ved sessionstart, så genstart efter redigering). Hvis alle tre er i orden, så kør /echo-args foo med det minimale eksempel fra H2 #1 for at isolere problemet.
Kan jeg kræve bestemte argumenter?
Ikke på brugsniveau — der findes ingen indbygget validering af påkrævede argumenter. Mønsteret er at instruere LLM'en i din prompt: "Hvis $1 er tom, så stop og bed brugeren om at angive et issue-nummer." Modellen håndhæver kontrakten. Det er ikke idiotsikkert, men i praksis er det pålideligt nok til daglig brug, især når det kombineres med et tydeligt argument-hint.
Tilsidesætter model: i frontmatter CLI-flag?
Ja, frontmatter vinder. Hvis din kommandofil erklærer model: claude-haiku-4, kører kommandoen på Haiku, uanset hvilken model brugeren har valgt til sessionen. Det er nyttigt til billige, ofte anvendte kommandoer, du vil holde væk fra Opus. Se vores guide til skift af Claude-modeller for at vælge den rigtige variant til hver kommandotype.
Afrunding
Fire mønstre. Vælg det, der passer til din kommandos form:
- Boolsk flag (
--dry-run), skriv det ind i$ARGUMENTS, og lad LLM'en registrere det. - Værdiflag (
--filter <pattern>), samme tilgang, LLM'en udtrækker værdien. - Påkrævet positionel + valgfrit flag,
$1til det obligatoriske,$ARGUMENTStil resten. - Streng positionel,
$0/$1/$2(eller navngivet viaarguments:) når hver plads er påkrævet og ordnet.
Nu hvor dine kommandoer er parametriske, er næste skridt at integrere dem i agent-workflows. Start med vores Claude Skills-vejledning for opgraderingen til multi-fil-pakning, eller gennemse alternative AI-kodeværktøjer, hvis du sammenligner harnesses. Uanset hvad, er din .claude/commands/-mappe netop blevet en hel del mere nyttig.