Slik legger du til flagg i Claude Code slash-kommandoer: 4 mønstre som faktisk virker

Slik legger du til flagg i Claude Code slash-kommandoer: 4 mønstre som faktisk virker

Claude Code parser ikke --flagg slik du kanskje forventer for egendefinerte slash-kommandoer — men fire mønstre gir deg samme UX, og tre av dem er ryddigere enn CLI-parsing noen gang var. Her er hvordan du legger til flagg i Claude Code slash-kommandoer på riktig måte, med fungerende .md-filer du kan kopiere i dag.

Kort svar:

• Claude Code parser ikke CLI-flagg (--json, --verbose) for egendefinerte kommandoer — harness har ingen flagg-parser.
• For CLI-lignende UX: skriv flaggene inn i $ARGUMENTS og la LLM-en tolke dem som naturlig språk.
• For typede argumenter: bruk posisjonsbaserte $1/$2 eller navngitte argumenter deklarert i frontmatter-feltet arguments:.
• Dokumenter forventede flagg i argument-hint: slik at /-autofullfør viser dem til brukeren.

Hvordan fungerer egentlig argumenter i Claude Code slash-kommandoer?

Claude Code-harness erstatter tre typer tokens før kommandoen sendes til LLM-en: $ARGUMENTS (hele strengen etter kommandonavnet), posisjonsbaserte $0/$1/$2 (shell-lignende kvoterte segmenter), og navngitte $variabelNavn deklarert i frontmatter. Det finnes ingen innebygd CLI-flagg-parser — --dry-run lander i $ARGUMENTS som ren tekst.

Her er den delen som forvirrer alle. Når du skriver /deploy --staging --dry-run, kjører Claude Code ikke argparse mot --staging --dry-run. Harness limer hele strengen inn der .md-filen refererer til $ARGUMENTS, og sender deretter den renderte prompten til modellen. LLM-en ser --staging --dry-run som vanlig tekst og bestemmer hva som skal gjøres.

Det er ikke en feil — det er designet. Harness er et substitusjonslagr, ikke en parser. Innebygde kommandoer som /clear og /help (se den offisielle CLI-referansen) har flagg, men egendefinerte kommandoer du skriver følger andre regler.

Claude Code-harness erstatter tokens, og sender deretter den renderte prompten til LLM-en. Det finnes ingen flagg-parser.

I vårt eget Claude Code-arbeid er denne enkeltforvirringen den vanligste — utviklere bruker en time på å forstå hvorfor --verbose "ikke oppdages", før de innser at LLM-en er parseren. Fra og med Claude Code v2.1.126 (mai 2026) er denne oppførselen dokumentert i den offisielle slash-kommando-dokumentasjonen og vil ikke endres med det første. Slash-kommandoer er et søsken-primitivt til Claude Code hooks — begge utvider harness, men kommandoer utløses av brukerinndata mens hooks utløses av verktøyhendelser.

Her er den minst mulige egendefinerte kommandoen som beviser substitusjonsmodellen:

---
description: Ekko hva brukeren enn skriver etter kommandoen
argument-hint: [hva som helst]
---

Brukeren sendte disse argumentene: $ARGUMENTS

Repeter dem ordrett, og beskriv deretter hva brukeren sannsynligvis mente.

Lagre det som .claude/commands/echo-args.md, skriv /echo-args hello world --foo, og LLM-en vil se den bokstavelige strengen hello world --foo substituert inn i prompten. Det er hele den mentale modellen. For en dypere gjennomgang av hvordan kommandofiler forholder seg til det bredere skills-systemet, se vår Skills-innføring.

Bygg din første parametriske slash-kommando på 5 minutter

Opprett .claude/commands/greet.md med tre linjer frontmatter og én prompt-linje som refererer til $ARGUMENTS. Start Claude Code på nytt, skriv /greet World, og se World substitueres inn i prompten før LLM-en ser den. Det er hele seansen — fem steg, ingen byggeverktøy.

Her er oppskriften fra ende til annen:

1. Opprett mappen. Fra prosjektets rotmappe, kjør mkdir -p .claude/commands. .claude/-mappen ligger ved siden av koden din; kommandoer der oppdages automatisk når Claude Code starter en økt.
2. Skriv kommandofilen. Lagre kodebiten nedenfor som .claude/commands/greet.md.
3. Last inn økten på nytt. Avslutt og start Claude Code på nytt (eller kjør /reload hvis versjonen din støtter det). Kommandoer leses én gang ved øktstart.
4. Kall den. Skriv /greet World i chatten.
5. Bekreft substitusjonen. Åpne transkriptet og bekreft at LLM-en så World interpolert inn i prompten, ikke det bokstavelige tokenet $ARGUMENTS.

Her er hele filen:

---
description: Hils noen entusiastisk
argument-hint: <navn>
---

Du er en vennlig assistent. Hils personen som heter "$ARGUMENTS" med én kort, varm setning. Spør dem deretter hva de jobber med i dag.

Og terminalinteraksjonen:

> /greet World
Hei World, så hyggelig å se deg! Hva jobber du med i dag?

Det er alt. Du har nå en parametrisk slash-kommando. Feltet argument-hint er det som får /-autofullfør-menyen til å vise <navn> ved siden av kommandoen — liten UX-touch, stor effekt.

Hvis $ARGUMENTS ikke substitueres, er det 9 av 10 ganger fordi du skrev $args eller $ARGS — tokenet er bokstavelig store bokstaver.

Tokenet er litt-for-litt-sensitivt og eksakt. $ARGUMENTS virker. $arguments, $args, $ARGS, ${ARGUMENTS} feiler stille — de sendes til LLM-en som bokstavelig tekst og modellen ser bare rot. Sjekk stavemåten tre ganger før du antar en dypere feil.

Hvilke frontmatter-felt styrer argumenthåndtering?

Fem frontmatter-felt former hvordan en slash-kommando håndterer argumenter: argument-hint (hva autofullfør viser), allowed-tools (hva kommandoen kan kalle), arguments (navngitt-argument-deklarasjon), model (hvilken Claude-variant som kjører den), og disable-model-invocation (låser kommandoen til kun brukeranrop). Til sammen dekker de nesten alle parametriske mønstre du trenger.

Her er den komplette frontmatter-referansen for Claude Code v2.1.x egendefinerte kommandoer:

To fallgruver verdt å feste til skjermen. For det første er allowed-tools mellomrom-separert, ikke komma-separert. Å skrive Bash(git:*), Read, Edit vil stille feile å hviteliste noe — parseren behandler hele strengen som én misdannet oppføring. Bruk Bash(git:*) Read Edit. Vi lærte dette den harde veien; for flere mønstre som dette, se vår guide om CLAUDE.md beste praksiser om konfigurasjonsfil-konvensjoner.

For det andre overstyrer model:-feltet hvilken modell brukeren har valgt for økten. Nyttig når en kommando er beregningsbillig og du vil tvinge den over på en mindre variant — se vår guide om modellvalg for å velge mellom Opus 4.7 og Sonnet for ulike kommandotyper.

disable-model-invocation: true-feltet er sikkerhetsnettet ditt for destruktive kommandoer. Sett det på /deploy-prod eller /drop-database så vil ikke andre agenter kunne kalle disse kommandoene programmatisk — bare et menneske som skriver i chatten kan utløse dem.

Hva er de 4 argumentmønstrene du faktisk vil bruke?

Fire mønstre dekker omtrent 95 % av alle Claude Code slash-kommandoer: (1) boolsk flagg som /deploy --dry-run parset av LLM-en fra $ARGUMENTS, (2) verdiflagg som /test --filter auth ekstrahert fra $ARGUMENTS, (3) påkrevd posisjonell + valgfritt flagg som /fix-issue 123 --priority high som blander $1 og $ARGUMENTS, og (4) strengt posisjonsbasert som /migrate-component SearchBar React Vue som bruker $0/$1/$2.

Velg det som passer formen på kommandoen din. Her er en fungerende .md-fil for hvert av dem.

Mønster 1: Boolsk flagg (--dry-run)

Når du vil ha CLI-flagg-UX og flagget bare er av/på, lean på LLM-en for å oppdage det inne i $ARGUMENTS. Ingen parsinglogikk, ingen posisjonsjonglering — beskriv bare regelen i prompten.

---
description: Deploy til staging eller produksjon
argument-hint: [--dry-run]
allowed-tools: Bash(git:*) Bash(npm:*) Read
---

Deploy nåværende branch til staging.

Sendte argumenter: $ARGUMENTS

Hvis "$ARGUMENTS" inneholder "--dry-run", skal du IKKE faktisk deploye. Print i stedet deployment-planen: hvilke filer som ville endres, hvilke env-variabler som ville settes, og hvilke kommandoer som ville kjøres. Stopp etter å ha printet planen.

Ellers, fortsett med den virkelige deployen med `git push staging main` og `npm run deploy:staging`.

Skriv /deploy --dry-run og LLM-en ser flagget, printer planen og stopper. Skriv /deploy og den deployer. Harness gjorde null parsing — LLM-en gjorde alt arbeidet, som er nøyaktig det den er god på.

Mønster 2: Verdiflagg (--filter <mønster>)

Samme idé, men nå bærer flagget en verdi. LLM-en leser --filter auth ut av $ARGUMENTS og bruker delstrengen etter det.

---
description: Kjør testsuiten, eventuelt filtrert
argument-hint: [--filter <mønster>]
allowed-tools: Bash(npm:*) Read
---

Kjør prosjektets testsuite.

Argumenter: $ARGUMENTS

Hvis "$ARGUMENTS" inneholder "--filter <mønster>", kjør bare tester som matcher <mønster>. Bruk `npm test -- --grep <mønster>` for den faktiske kommandoen.

Hvis ingen `--filter` er til stede, kjør hele suiten med `npm test`.

Rapporter bestått/feilet antall til slutt.

/test --filter auth kjører bare auth-testene. /test kjører alt. LLM-en ekstraherer mønsteret etter --filter pålitelig fordi Claude er genuint god på denne typen strukturert tekstekstraksjon — langt mer pålitelig enn folk forventer.

Mønster 3: Påkrevd posisjonsbasert + valgfritt flagg

Dette er hybriden vi bruker mest i vår egen kommandobibliotek. $1 bærer det påkrevde argumentet, $ARGUMENTS bærer alt (slik at LLM-en fortsatt kan oppdage valgfrie flagg). Det er den reneste miksen når ett argument er ufravikelig og resten er friform-kontekst.

---
description: Fikse et GitHub-issue
argument-hint: <issue-nummer> [--priority high|medium|low] [kontekst...]
allowed-tools: Bash(gh:*) Bash(git:*) Read Edit
---

Fiks GitHub-issue #$1.

Alle argumenter: $ARGUMENTS

Steg:
1. Kjør `gh issue view $1` for å laste inn issue-teksten.
2. Les kodebasen for å finne den/de relevante filen(e).
3. Hvis "$ARGUMENTS" inneholder "--priority high", opprett en hotfix-branch fra main. Ellers branch fra develop.
4. Anvend fiksen, kjør tester og åpne en PR koblet til issuen.

Alt annet i $ARGUMENTS etter issuenummeret er friform-kontekst — ta det med i forståelsen av buggen.

Kall med /fix-issue 1234 --priority high innloggingsskjemaet tømmer e-postfeltet etter et mislykket forsøk. $1 løses til 1234. $ARGUMENTS løses til hele den etterfølgende strengen, som LLM-en gladelig parser for både prioritetsflagget og friform-beskrivelsen.

Vi bruker nøyaktig denne $1 + $ARGUMENTS-miksen i vår /fix-issue-kommando — $1 for issuenummeret, resten for friform-kontekst LLM-en parser. Det har vært det høyeste-ROI-mønsteret gjennom et år med daglig Claude Code-bruk.

Mønster 4: Strengt posisjonsbasert (typet)

Når hvert argument er påkrevd og rekkefølgen betyr noe, dropp $ARGUMENTS helt. Bruk $0/$1/$2 (eller navngitte argumenter via frontmatter-feltet arguments:) for utvetydige typede plasser.

---
description: Migrer en komponent mellom rammeverk
argument-hint: <komponent> <fra-rammeverk> <til-rammeverk>
arguments: [component, fromFramework, toFramework]
allowed-tools: Read Edit Write
---

Migrer komponenten kalt "$component" fra $fromFramework til $toFramework.

1. Les den eksisterende komponentfilen (søk etter `$component.{jsx,tsx,vue,svelte}`).
2. Oversett komponent-idiomene fra $fromFramework til $toFramework: livssyklusmetoder, tilstandshåndtering, prop-syntaks, hendelsebinding.
3. Skriv den nye filen med matchende utvidelse for $toFramework.
4. Print et diff-sammendrag til slutt.

Hvis $fromFramework eller $toFramework ikke støttes, avbryt og fortell brukeren hvilke rammeverk SOM støttes (React, Vue, Svelte, Solid).

Kall med /migrate-component SearchBar React Vue. Den navngitte-argument-deklarasjonen gjør autofullfør og prompten selvdokumenterende — alle som leser migrate-component.md kan umiddelbart se hvilken plass som er hva. Dette mønsteret skinner for kommandoer med tre eller flere påkrevde argumenter. Du kan også se denne stilen i community-biblioteker som wshobson/commands på GitHub.

Boolske og verdiflagg virker fordi LLM-en er en fleksibel parser. Strengt posisjonsbasert virker fordi ingen LLM-intelligens er nødvendig. Å blande de to er hemmeligheten.

Når bør du bruke $ARGUMENTS vs posisjonsbasert vs navngitt?

Bruk $ARGUMENTS når argumenter er CLI-flagg-lignende og du vil ha LLM-fleksibel parsing. Bruk posisjonsbasert $1/$2 når argumenter er typede, ordnede og du vil ha null LLM-tvetydighet. Bruk navngitte arguments: når det er 3+ argumenter og klarhet i autofullfør betyr mer enn korthet. Her er beslutningsmatrisen:

Instinktet de fleste utviklere har er å gripe $ARGUMENTS først fordi det føles nærmest bash-verdenen de kjenner. Det er greit for prototyper, men typet posisjonsbasert er genuint bedre når kontrakten er stabil. LLM-en trenger ikke å parse $1 — det er allerede en ren streng.

En grov tommelfingerregel: hvis du kan beskrive kommandoens signatur i én engelsk setning uten å bruke ordene "eller" og "valgfritt", gå posisjonsbasert. Hvis du trenger de ordene, gå $ARGUMENTS.

Er slash-kommandoer det samme som skills nå?

Anthropic slo egendefinerte kommandoer sammen med det bredere skills-systemet våren 2026, men .claude/commands/*.md-filer fungerer fortsatt og bruker samme frontmatter. En skill er en mappe (.claude/skills/foo/SKILL.md pluss støttefiler) med ekstra anropskontroll som disable-model-invocation. En kommando er en enkelt .md-fil. Samme substitusjonsregler, annen pakking.

Her er den praktiske forskjellen:

Nei, .claude/commands/ er ikke avviklet. Anthropic holdt eksplisitt filformen fungerende da de slo sammen systemene — altfor mange prosjekter har kommandobiblioteker festet i versjonskontroll. Hvis du vil ha støttefiler (som en CONTRIBUTING.md-referanse skillen din laster, eller en template.json den kopierer), gå for skills. Ellers hold deg til kommandoer.

Sammenslåingen er en del av et bredere press mot den åpne agentskills.io-standarden, og det er én av flere v2.1.x-endringer verdt å kjenne til — se vår oppsummering av Claude Code v2.1-funksjoner for det fulle funksjonslandskapet og vår skills-opplæring for en dypere skills-gjennomgang.

Hvorfor substitueres ikke $ARGUMENTS? Vanlige feil rettet

Fem vanlige årsaker til at $ARGUMENTS ikke substitueres: (1) liten bokstav eller forkortelse ($args, $ARGS, $arguments — må være bokstavelig $ARGUMENTS), (2) flerordsargumenter ikke kvotert (/cmd hello world splitter; /cmd "hello world" holder det sammen), (3) allowed-tools komma-separert i stedet for mellomrom-separert, (4) kommandofil ikke i .claude/commands/ eller .claude/skills/, (5) Claude Code-økt må lastes inn på nytt etter redigering av filen.

$ARGUMENTS vises bokstavelig i LLM-prompten

Symptom: Prompten viser $ARGUMENTS som ren tekst i modellens svar, som om harness ignorerte det. Årsak: Feil bokstavstørrelse eller stavemåte. Tokenet er bokstavelig $ARGUMENTS — åtte tegn, alle store bokstaver. Løsning: Åpne .md, grep etter $args, $ARGS, $arguments, ${ARGUMENTS}, erstatt med $ARGUMENTS. $args-skrivefeil-buggen har truffet alle på teamet vårt minst én gang; det er den enkeltfeiltypen med høyest volum i "ukjent slash-kommando"-familien.

Flerordsargument deles uventet

Symptom: Du kjørte /migrate-component Search Bar React Vue og $1 er Search, $2 er Bar. Årsak: Mellomrom deler posisjonsbaserte argumenter. Løsning: Kvotér flerordsargumentet: /migrate-component "Search Bar" React Vue. Nå er $1 Search Bar. Dette speiler shell-atferd, som er den mentale modellen harness bevisst speiler.

allowed-tools respekteres ikke

Symptom: Kommandoen kjører, men Claude nekter å kalle verktøy du trodde du hvitelistet, eller den kaller verktøy du ikke listet. Årsak: Komma-separert i stedet for mellomrom-separert. Løsning: Endre allowed-tools: Bash, Read, Edit til allowed-tools: Bash Read Edit. For verktøy-undermønstre, formater som Bash(git:*) Bash(npm:*) Read.

Kommandoen vises ikke i /-autofullfør

Symptom: Du skriver / og kommandoen din er ikke i listen. Årsak: Filplassering, manglende frontmatter, eller disable-model-invocation satt feil. Løsning: Bekreft at filen er på .claude/commands/dinkmd.md (eller .claude/skills/dinkmd/SKILL.md) relativt til prosjektets rot. Bekreft at frontmatter har minst et description:-felt. Hvis du satte disable-model-invocation: true, vises ikke kommandoen til andre agenter, men vises fortsatt i den mennesklige /-menyen.

Du redigerte .md-filen, men ingenting endret seg

Symptom: Du fikset buggen, lagret filen, kjørte kommandoen igjen, samme ødelagte atferd. Årsak: Claude Code cacher kommandofiler ved øktstart. Løsning: Avslutt og start Claude Code på nytt, eller kjør /reload hvis versjonen din støtter det.

Claude Code leser .md-filer ved øktstart. Hvis du redigerer en kommando og den "ikke endres", start økten på nytt før du antar en dypere feil.

For kanttilfeller utover disse fem, er Claude Code-repo-issuene det beste stedet å søke. De fleste rare substitusjonsbuggene vi har sett er en variant av én av de ovennevnte.

FAQ: Claude Code slash-kommando argumenter

Hvordan sender jeg argumenter til en Claude Code slash-kommando?

Skriv argumentstrengen etter kommandonavnet: /greet World. Inne i kommandoens .md-fil, referer til verdien som $ARGUMENTS (hele strengen), $1 (første posisjonell), eller $variabelNavn (hvis du deklarerte arguments: [variabelNavn] i frontmatter). Harness erstatter tokenet før den sender prompten til LLM-en.

Hva er $ARGUMENTS i Claude Code?

$ARGUMENTS er et substitusjonstoken i egendefinerte slash-kommandofiler som Claude Code-harness erstatter med hele argumentstrengen brukeren skrev etter kommandonavnet. Hvis en bruker kjører /deploy --staging --dry-run, blir $ARGUMENTS til den bokstavelige strengen --staging --dry-run inne i den renderte prompten før LLM-en noen gang ser den.

Kan Claude Code slash-kommandoer ta CLI-lignende flagg som --json?

Ikke nativt — harness har ingen flagg-parser for egendefinerte kommandoer. Du skriver --json inn i $ARGUMENTS, og prompten instruerer LLM-en om å oppdage det og oppføre seg deretter. Dette virker fordi Claude er en fleksibel parser av strukturert tekst. Innebygde kommandoer som /clear og /help har ekte flagg, men egendefinerte kommandoer du skriver lever etter kun-substitusjonsregler.

Hva er forskjellen mellom $1, $ARGUMENTS og $navn i Claude Code?

$1 er det første mellomrom-separerte posisjonsargumentet ($2 er det andre, og så videre). $ARGUMENTS er hele argumentstrengen verbatim, inkludert alle posisjonsbaserte deler og eventuelle flagg. $navn er et navngitt argument deklarert i frontmatter-feltet arguments: [navn] — nyttig når du vil ha selvdokumenterende posisjonsplasser uten numerisk indeksering.

Hvordan fungerer argument-hint i Claude Code?

argument-hint er et frontmatter-felt som styrer hva /-autofullfør-menyen viser ved siden av kommandonavnet ditt. Å sette argument-hint: <issue-nummer> [--priority high] viser nøyaktig den malen etter at brukeren skriver /. Det er bare UX — det validerer eller parser ikke argumenter. Det er fortsatt verdt å sette fordi det er den billigste dokumentasjonen du noen gang vil skrive.

Hvordan oppretter jeg en egendefinert slash-kommando med flere argumenter?

To ryddige alternativer. For posisjonsbasert: referer til $1, $2, $3 i promptkroppen. For navngitt: deklarer arguments: [første, andre, tredje] i frontmatter og referer til $første, $andre, $tredje. Navngitt er mer lesbart for tre-pluss argumenter. Bruk $ARGUMENTS bare når du vil at LLM-en skal parse en friform-etterfølgende streng etter de påkrevde posisjonsplassene.

Er .claude/commands/ avviklet til fordel for .claude/skills/?

Nei. Anthropic slo de to systemene sammen våren 2026, men holdt eksplisitt .claude/commands/*.md fungerende med identiske substitusjonsregler. Bruk kommandoer for enkeltfil-automatiseringer og skills for flerfil-pakker (SKILL.md pluss maler eller referanser). Samme frontmatter, samme $ARGUMENTS-atferd, annen pakking. Begge er førsteklasses fra og med v2.1.126.

Hvorfor substitueres ikke $ARGUMENTS i kommandoen min?

Tre toppårsaker, i frekvensrekkefølge: bokstavstørrelsesfeil (må være store bokstaver $ARGUMENTS, ikke $args eller $arguments), feil filplassering (må ligge i .claude/commands/ eller .claude/skills/), eller utdatert økt (Claude Code leser kommandofiler ved øktstart, så start på nytt etter redigering). Hvis alle tre sjekker ut, kjør /echo-args foo med minimumseksempelet fra H2 #1 for å isolere problemet.

Kan jeg kreve bestemte argumenter?

Ikke på harness-nivå — det er ingen innebygd påkrevd-argument-validering. Mønsteret er å instruere LLM-en i prompten: "Hvis $1 er tom, stopp og fortell brukeren å oppgi et issuenummer." Modellen håndhever kontrakten. Det er ikke skuddsikkert, men i praksis er det pålitelig nok for daglig bruk, spesielt når det er kombinert med en tydelig argument-hint.

Overstyrer model: i frontmatter CLI-flagg?

Ja — frontmatter vinner. Hvis kommandofilen din deklarerer model: claude-haiku-4, kjører den kommandoen på Haiku uavhengig av hvilken modell brukeren valgte for økten. Dette er nyttig for billige, hyppig invokerte kommandoer du vil holde borte fra Opus. Se guiden vår om å bytte Claude-modeller for å velge riktig variant per kommandotype.

Oppsummering

Fire mønstre. Velg det som passer kommandoens form:

• Boolsk flagg (--dry-run) — skriv det inn i $ARGUMENTS, la LLM-en oppdage det.
• Verdiflagg (--filter <mønster>) — samme tilnærming, LLM-en ekstraherer verdien.
• Påkrevd posisjonsbasert + valgfritt flagg — $1 for det ufravikelige, $ARGUMENTS for resten.
• Strengt posisjonsbasert — $0/$1/$2 (eller navngitt via arguments:) når hver plass er påkrevd og ordnet.

Nå som kommandoene dine er parametriske, er neste steg å koble dem inn i agentarbeidsflyter — start med Claude Skills-opplæringen for flerfil-pakkeopgraderingen, eller bla gjennom alternative AI-kodingsverktøy hvis du sammenligner harnesses. Uansett har .claude/commands/-mappen din nettopp blitt mye mer nyttig.