
Så lägger du till flaggor i Claude Code slash-kommandon: 4 mönster som faktiskt fungerar
Claude Code parsar inte --flaggor på det sätt du kanske förväntar dig för egna slash-kommandon — men fyra mönster ger dig exakt samma UX, och tre av dem är snyggare än CLI-parsning någonsin var. Här är hur du lägger till flaggor i Claude Code slash-kommandon på rätt sätt, med fungerande .md-filer du kan kopiera direkt.
Snabbt svar:
- Claude Code parsar inte CLI-flaggor (
--json,--verbose) för egna kommandon — harness saknar flagg-parser. - För CLI-liknande UX skriver du flaggor i
$ARGUMENTSoch låter LLM:en tolka dem som naturligt språk. - För typade argument använder du positionella
$1/$2eller namngivna argument deklarerade i frontmatter-fältetarguments:. - Dokumentera förväntade flaggor i
argument-hint:så att/-autokompletteringen visar dem för användaren.
Hur fungerar egentligen Claude Code slash-kommando-argument?
Claude Codes harness ersätter tre typer av token innan ditt kommando skickas till LLM:en: $ARGUMENTS (hela strängen efter kommandonamnet), positionella $0/$1/$2 (shell-style segment med citationstecken), och namngivna $variabelnamn deklarerade i frontmatter. Det finns ingen inbyggd CLI-flagg-parser — --dry-run hamnar i $ARGUMENTS som literal text.
Det här är vad som förvirrar alla till en början. När du skriver /deploy --staging --dry-run kör Claude Code inte argparse mot --staging --dry-run. Harness klistrar in hela strängen där din .md-fil refererar till $ARGUMENTS, och skickar sedan den renderade prompten till modellen. LLM:en ser --staging --dry-run som vanlig text och bestämmer vad som ska göras.
Det är ingen bugg — det är designen. Harness är ett substitutionslager, inte en parser. Inbyggda kommandon som /clear och /help (se officiell CLI-referens) har flaggor, men egna kommandon du skriver styrs av andra regler.
Claude Codes harness substituerar tokens och skickar sedan den renderade prompten till LLM:en. Det finns ingen flagg-parser.
I vårt eget Claude Code-arbete är den vanligaste förvirringen exakt detta — utvecklare spenderar en timme på att försöka lista ut varför --verbose "inte detekteras" innan de inser att LLM:en är parsern. Från och med Claude Code v2.1.126 (maj 2026) är detta beteende dokumenterat i officiella slash-commands-docs och kommer inte att ändras inom kort. Slash-kommandon är ett syskonprimitiv till Claude Code hooks — båda utökar harness, men kommandon triggas av användarinmatning medan hooks triggas av verktyghändelser.
Här är det minsta möjliga egna kommandot som bevisar 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.Spara det som .claude/commands/echo-args.md, skriv /echo-args hello world --foo, och LLM:en kommer se den literala strängen hello world --foo substituerad i prompten. Det är hela tankemodellen. För en djupare genomgång av hur kommandofiler relaterar till det bredare skills-systemet, se vår Skills-introduktion.
Bygg ditt första parametriska slash-kommando på 5 minuter
Skapa .claude/commands/greet.md med tre rader frontmatter och en promptrad som refererar till $ARGUMENTS. Starta om Claude Code, skriv /greet World, och se hur World substitueras i prompten innan LLM:en ser den. Det är hela ceremonin — fem steg, inga byggverktyg.
Här är receptet från start till slut:
- Skapa katalogen. Kör
mkdir -p .claude/commandsfrån din projektkatalog. Mappen.claude/ligger bredvid din kod och kommandon inuti den hittas automatiskt när Claude Code startar en session. - Skriv kommandofilen. Spara utdraget nedan som
.claude/commands/greet.md. - Ladda om sessionen. Avsluta och starta om Claude Code (eller kör
/reloadom din version stöder det). Kommandon läses in en gång vid sessionsstart. - Anropa det. Skriv
/greet Worldi chatten. - Verifiera substitutionen. Öppna transkriptet och bekräfta att LLM:en såg
Worldinterpolerat i promptkroppen, inte den literala token$ARGUMENTS.
Här är hela filen:
---
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.Och terminalinteraktionen:
> /greet World
Hey World, great to see you! What are you working on today?Det var allt. Du har nu ett parametriskt slash-kommando. Fältet argument-hint är det som gör att /-autokompletteringsmenyn visar <name> bredvid ditt kommando — liten UX-detalj, stort utfall.
Om
$ARGUMENTSinte substitueras beror det 9 gånger av 10 på att du skrivit$argseller$ARGS— token är bokstavligen versaler.
Token är skiftlägeskänslig och exakt. $ARGUMENTS fungerar. $arguments, $args, $ARGS, ${ARGUMENTS} misslyckas alla tyst — de skickas till LLM:en som literal text och modellen ser bara nonsens. Trippelkolla stavningen innan du antar att det är ett djupare fel.
Vilka frontmatter-fält styr argumenthantering?
Fem frontmatter-fält formar hur ett slash-kommando hanterar argument: argument-hint (vad autokompletteringen visar), allowed-tools (vad kommandot får anropa), arguments (deklaration av namngivna argument), model (vilken Claude-variant som kör det) och disable-model-invocation (låser kommandot till användaranrop). Tillsammans täcker de i princip alla parametriska mönster du behöver.
Här är den fullständiga frontmatter-referensen för anpassade Claude Code v2.1.x-kommandon:
| Fält | Syfte | Exempel | Obligatoriskt? |
|---|---|---|---|
description: | Enradssammanfattning i /-menyn | Run staging deploy | Rekommenderat |
argument-hint: | Autokompletteringstips som visas efter kommandonamnet | [--dry-run] [--region us] | Rekommenderat |
allowed-tools: | Vitlista över verktyg kommandot får anropa | Bash(git:*) Read Edit | Valfritt |
arguments: | Deklaration av namngivna argument | [issue, branch] | Valfritt |
model: | Åsidosätt modell för detta kommando | claude-opus-4-7 | Valfritt |
disable-model-invocation: | Blockera agenter från att anropa detta kommando | true | Valfritt |
context: fork | Kör i isolerad kontext | fork | Valfritt |
Två fallgropar värda att fästa på skärmen. Först: allowed-tools är mellanslag-separerat, inte komma-separerat. Att skriva Bash(git:*), Read, Edit misslyckas tyst med att vitlista något — parsern behandlar hela strängen som en felaktig post. Använd Bash(git:*) Read Edit. Vi lärde oss detta den hårda vägen; för fler mönster av det slaget, se vår guide om CLAUDE.md bästa metoder om konfigurationsfilskonventioner.
För det andra: fältet model: åsidosätter vilken modell användaren har valt för sessionen. Användbart när ett kommando är beräkningsmässigt billigt och du vill tvinga det till en mindre variant — se vår guide om modellval för att välja mellan Opus 4.7 och Sonnet för olika kommandotyper.
Fältet disable-model-invocation: true är ditt skyddsnät för destruktiva kommandon. Sätt det på /deploy-prod eller /drop-database och andra agenter kan inte anropa dessa kommandon programmatiskt — bara en människa som skriver i chatten kan trigga dem.
Vilka är de 4 argumentmönster du faktiskt kommer att använda?
Fyra mönster täcker ungefär 95 % av verkliga Claude Code slash-kommandon: (1) boolesk flagga som /deploy --dry-run tolkad av LLM:en från $ARGUMENTS, (2) värdiflagga som /test --filter auth extraherad från $ARGUMENTS, (3) obligatorisk positionell + valfri flagga som /fix-issue 123 --priority high som blandar $1 och $ARGUMENTS, och (4) strikt positionell som /migrate-component SearchBar React Vue med $0/$1/$2.
Välj det som passar ditt kommandos form. Här är en fungerande .md-fil för vart och ett.

Mönster 1: Boolesk flagga (--dry-run)
När du vill ha CLI-flagg-UX och flaggan är på/av, låt LLM:en detektera den inuti $ARGUMENTS. Ingen parsningslogik, ingen positionell jonglering — beskriv bara regeln 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 och LLM:en ser flaggan, skriver ut planen och stoppar. Skriv /deploy och den kör på riktigt. Harness gjorde noll parsning — LLM:en gjorde allt arbete, vilket är precis vad den är bra på.
Mönster 2: Värdiflagga (--filter <mönster>)
Samma idé, men nu bär flaggan ett värde. LLM:en läser --filter auth ur $ARGUMENTS och använder delsträngen efter den.
---
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ör bara auth-testerna. /test kör allt. LLM:en extraherar mönstret efter --filter tillförlitligt — Claude är genuint bra på den typen av strukturerad textextraktion, bättre än de flesta förväntar sig.
Mönster 3: Obligatorisk positionell + valfri flagga
Det här är hybriden vi använder mest i vår egna kommandobibliotek. $1 bär det obligatoriska argumentet, $ARGUMENTS bär allt (så LLM:en fortfarande kan fånga valfria flaggor). Det är den renaste kombinationen när ett argument är icke-förhandlingsbart och resten är fri kontext.
---
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.Anropa som /fix-issue 1234 --priority high inloggningsformuläret raderar e-postfältet efter ett misslyckat försök. $1 löser upp till 1234. $ARGUMENTS löser upp till hela efterföljande strängen, som LLM:en gärna parsar för både prioritetsflaggan och den fria beskrivningen.
Vi använder exakt den här $1 + $ARGUMENTS-kombinationen i vårt /fix-issue-kommando — $1 för ärendenumret, resten för fri kontext LLM:en parsar. Det har varit det högst avkastande mönstret under ett år av daglig Claude Code-användning.
Mönster 4: Strikt positionell (typad)
När varje argument är obligatoriskt och ordningen spelar roll, droppa $ARGUMENTS helt. Använd $0/$1/$2 (eller namngivna argument via frontmatter-fältet arguments:) för entydiga typade platser.
---
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).Anropa som /migrate-component SearchBar React Vue. Deklarationen av namngivna argument gör att autokompletteringen och promptkroppen är självdokumenterande — vem som helst som läser migrate-component.md ser direkt vilken plats som är vilken. Det här mönstret är extra bra för kommandon med tre eller fler obligatoriska argument. Du kan också se det här stilen i community-bibliotek som wshobson/commands på GitHub.
Booleska och värdiflaggor fungerar eftersom LLM:en är en flexibel parser. Strikt positionell fungerar eftersom ingen LLM-intelligens krävs. Att blanda de två är hemligheten.
När ska du använda $ARGUMENTS vs positionell vs namngiven?
Använd $ARGUMENTS när argument är CLI-flagg-liknande och du vill ha LLM-flexibel parsning. Använd positionella $1/$2 när argument är typade, ordnade och du vill ha noll LLM-tvetydighet. Använd namngivna arguments: när det finns 3+ argument och tydlighet i autokompletteringen är viktigare än korthet. Här är beslutsmatrisen:
| Användningsfall | Bästa val | Syntax | Fördelar | Nackdelar | Exempel |
|---|---|---|---|---|---|
| CLI-flagg-UX med valfria argument | $ARGUMENTS | $ARGUMENTS i kroppen | Flexibelt, speglar Unix-UX | LLM-sideparsning, ingen validering | /deploy --staging --dry-run |
| Typade, ordnade obligatoriska argument | Positionella $0/$1 | $0 $1 $2 i kroppen | Noll tvetydighet, snabbt | Känsligt för argumentordning | /migrate Button React Vue |
| 3+ argument där tydlighet spelar roll | Namngivna via arguments: | arguments: [a, b, c] sedan $a $b $c | Självdokumenterande | Utförlig frontmatter | /issue 123 main high |
| Blandat obligatorisk + valfri | Hybrid ($1 + $ARGUMENTS) | $1 sedan $ARGUMENTS | Det bästa av båda | Två tankemodeller i en fil | /fix-issue 123 --priority high |

Instinkten hos de flesta utvecklare är att nå för $ARGUMENTS först eftersom det känns närmast bash-världen de känner. Det fungerar för prototyper, men typad positionell är genuint bättre när kontraktet är stabilt. LLM:en behöver inte parsa $1 — det är redan en ren sträng.
En tumregel: om du kan beskriva kommandots signatur i en enda engelsk mening utan att använda orden "eller" och "valfritt", välj positionell. Om du behöver de orden, välj $ARGUMENTS.
Är slash-kommandon detsamma som skills nu?
Anthropic slog ihop egna kommandon med det bredare skills-systemet våren 2026, men .claude/commands/*.md-filer fungerar fortfarande och använder samma frontmatter. En skill är en katalog (.claude/skills/foo/SKILL.md plus stödfiler) med extra anropskontroll som disable-model-invocation. Ett kommando är en enda .md-fil. Samma substitutionsregler, olika förpackning.
Här är den praktiska skillnaden:
| Aspekt | .claude/commands/foo.md | .claude/skills/foo/ |
|---|---|---|
| Filform | Enda .md-fil | Katalog med SKILL.md + stödfiler |
| Bäst för | Snabba engångskommandon, projektlokala automatiseringar | Återanvändbara buntar med mallar, referenser, underfilar |
| Anropskontroll | Endast frontmatter | Frontmatter + per-fil disable-model-invocation |
| Argumenthantering | Identisk ($ARGUMENTS, $1, namngiven) | Identisk ($ARGUMENTS, $1, namngiven) |

Nej, .claude/commands/ är inte utfasad. Anthropic behöll uttryckligen filformen när de slog ihop systemen — för många projekt har kommandobibliotek fastade i versionskontroll. Om du vill ha stödfiler (som en CONTRIBUTING.md-referens din skill laddar, eller en template.json den kopierar), välj skills. Annars håll dig till kommandon.
Sammanslagningen är en del av en bredare push mot den öppna agentskills.io-standarden, och det är en av flera v2.1.x-ändringar värda att känna till — se vår sammanfattning av Claude Code v2.1-funktioner för hela funktionsbilden och vår skills-handledning för en djupare genomgång av skills.
Varför substitueras inte min $ARGUMENTS? Vanliga buggar fixade
Fem vanliga anledningar till att $ARGUMENTS inte substitueras: (1) gemen eller förkortad token ($args, $ARGS, $arguments — måste vara literal $ARGUMENTS), (2) argument med flera ord inte citerade (/cmd hello world delar upp; /cmd "hello world" håller ihop), (3) allowed-tools komma-separerat istället för mellanslag-separerat, (4) kommandofilen inte i .claude/commands/ eller .claude/skills/, (5) Claude Code-sessionen behöver laddas om efter att filen redigerades.
$ARGUMENTS visas bokstavligen i LLM-prompten
Symptom: Din prompt visar $ARGUMENTS som vanlig text i modellens svar, som om harness ignorerade det. Orsak: Fel skiftläge eller stavning. Token är bokstavligen $ARGUMENTS — åtta tecken, alla versaler. Fix: Öppna .md, sök efter $args, $ARGS, $arguments, ${ARGUMENTS}, ersätt med $ARGUMENTS. $args-skrivfelsbugg har drabbat varje utvecklare i vårt team minst en gång; det är den enskilt vanligaste buggen i "okänt slash-kommando"-familjen.
Argument med flera ord delas oväntad
Symptom: Du körde /migrate-component Search Bar React Vue och $1 är Search, $2 är Bar. Orsak: Blanksteg delar upp positionella argument. Fix: Citera argumentet med flera ord: /migrate-component "Search Bar" React Vue. Nu är $1 Search Bar. Det speglar shell-beteende, vilket är den tankemodell harness medvetet efterliknar.
allowed-tools respekteras inte
Symptom: Kommandot kör men Claude vägrar anropa verktyg du trodde du vitlistade, eller anropar verktyg du inte listade. Orsak: Komma-separerat istället för mellanslag-separerat. Fix: Ändra allowed-tools: Bash, Read, Edit till allowed-tools: Bash Read Edit. För verktygsmönster, formatera som Bash(git:*) Bash(npm:*) Read.
Kommandot syns inte i /-autokompletteringen
Symptom: Du skriver / och ditt kommando finns inte i listan. Orsak: Filplacering, saknad frontmatter eller disable-model-invocation satt felaktigt. Fix: Bekräfta att filen ligger på .claude/commands/dittkommando.md (eller .claude/skills/dittkommando/SKILL.md) relativt till din projektkatalog. Bekräfta att frontmatter har minst ett description:-fält. Om du satte disable-model-invocation: true dyker kommandot inte upp för andra agenter men syns fortfarande i den mänskliga /-menyn.
Du redigerade .md-filen men ingenting ändrades
Symptom: Du fixade buggen, sparade filen, körde kommandot igen, samma trasiga beteende. Orsak: Claude Code cachar kommandofiler vid sessionsstart. Fix: Avsluta och starta om Claude Code, eller kör /reload om din version stöder det.
Claude Code läser
.md-filer vid sessionsstart. Om du redigerar ett kommando och det "inte ändras", starta om sessionen innan du antar ett djupare fel.
För edge-fall bortom dessa fem är Claude Code-repots issues bästa platsen att söka. De flesta konstiga substitutionsbuggar vi sett är någon variant av en av ovanstående.
FAQ: Claude Code slash-kommando-argument
Hur skickar jag argument till ett Claude Code slash-kommando?
Skriv argumentsträngen efter kommandonamnet: /greet World. Inuti ditt kommandos .md-fil refererar du till värdet som $ARGUMENTS (hela strängen), $1 (första positionella) eller $variabelnamn (om du deklarerade arguments: [variabelnamn] i frontmatter). Harness substituerar token innan prompten skickas till LLM:en.
Vad är $ARGUMENTS i Claude Code?
$ARGUMENTS är en substitutionstoken i egna slash-kommandofiler som Claude Codes harness ersätter med hela argumentsträngen användaren skrivit efter kommandonamnet. Om en användare kör /deploy --staging --dry-run blir $ARGUMENTS den literala strängen --staging --dry-run inuti den renderade prompten innan LLM:en ser den.
Kan Claude Code slash-kommandon ta CLI-liknande flaggor som --json?
Inte nativt — harness har ingen flagg-parser för egna kommandon. Du skriver --json i $ARGUMENTS, och din prompt instruerar LLM:en att detektera det och bete sig enligt det. Det fungerar eftersom Claude är en flexibel parser av strukturerad text. Inbyggda kommandon som /clear och /help har riktiga flaggor, men egna kommandon du skriver styrs av substitutionsregler.
Vad är skillnaden mellan $1, $ARGUMENTS och $namn i Claude Code?
$1 är det första blanksteg-separerade positionella argumentet ($2 är det andra, och så vidare). $ARGUMENTS är hela argumentsträngen ordagrant, inklusive alla positionella delar och eventuella flaggor. $namn är ett namngivet argument deklarerat i frontmatter-fältet arguments: [namn] — användbart när du vill ha självdokumenterande positionella platser utan numerisk indexering.
Hur fungerar argument-hint i Claude Code?
argument-hint är ett frontmatter-fält som styr vad /-autokompletteringsmenyn visar bredvid ditt kommandonamn. Att sätta argument-hint: <issue-number> [--priority high] visar exakt den mallen efter att användaren skrivit /. Det är bara UX — det validerar eller parsar inte argument. Det är fortfarande värt att sätta eftersom det är den billigaste dokumentation du någonsin kommer skriva.
Hur skapar jag ett eget slash-kommando med flera argument?
Två rena alternativ. För positionella: referera till $1, $2, $3 i din promptkropp. För namngivna: deklarera arguments: [first, second, third] i frontmatter och referera till $first, $second, $third. Namngivna är mer läsbart för tre eller fler argument. Använd $ARGUMENTS bara när du vill att LLM:en ska parsa en fri efterföljande sträng efter de obligatoriska positionella platserna.
Är .claude/commands/ utfasad till förmån för .claude/skills/?
Nej. Anthropic slog ihop de två systemen våren 2026 men behöll uttryckligen .claude/commands/*.md med identiska substitutionsregler. Använd kommandon för enda-fils-automatiseringar och skills för flerfils-buntar (SKILL.md plus mallar eller referenser). Samma frontmatter, samma $ARGUMENTS-beteende, olika förpackning. Båda är förstaklassiga från och med v2.1.126.
Varför substitueras inte $ARGUMENTS i mitt kommando?
Tre vanliga orsaker, i frekvensordning: skiftlägesfel (måste vara versaler $ARGUMENTS, inte $args eller $arguments), fel filplacering (måste ligga i .claude/commands/ eller .claude/skills/), eller inaktuell session (Claude Code läser kommandofiler vid sessionsstart, starta om efter redigering). Om alla tre stämmer, kör /echo-args foo med det minimala exemplet från H2 #1 för att isolera problemet.
Kan jag kräva vissa argument?
Inte på harness-nivå — det finns ingen nativ obligatorisk-argument-validering. Mönstret är att instruera LLM:en i din prompt: "Om $1 är tomt, stoppa och berätta för användaren att ange ett ärendenummer." Modellen upprätthåller kontraktet. Det är inte skottsäkert, men i praktiken tillförlitligt nog för daglig användning, särskilt i kombination med ett tydligt argument-hint.
Åsidosätter model: i frontmatter CLI-flaggor?
Ja — frontmatter vinner. Om din kommandofil deklarerar model: claude-haiku-4 kör kommandot på Haiku oavsett vilken modell användaren valt för sessionen. Det är användbart för billiga, ofta anropade kommandon du vill hålla borta från Opus. Se vår guide om att byta Claude-modeller för att välja rätt variant per kommandotyp.
Avslutning
Fyra mönster. Välj det som passar ditt kommandos form:
- Boolesk flagga (
--dry-run) — skriv in den i$ARGUMENTS, låt LLM:en detektera den. - Värdiflagga (
--filter <mönster>) — samma tillvägagångssätt, LLM:en extraherar värdet. - Obligatorisk positionell + valfri flagga —
$1för det obligatoriska,$ARGUMENTSför resten. - Strikt positionell —
$0/$1/$2(eller namngivna viaarguments:) när varje plats är obligatorisk och ordnad.
Nu när dina kommandon är parametriska är nästa steg att koppla dem till agentarbetsflöden — börja med vår Claude Skills-handledning för flerfils-förpackningsuppgraderingen, eller bläddra bland alternativa AI-kodningsverktyg om du jämför harnesses. Hur som helst, din .claude/commands/-mapp är nu mycket mer användbar.