Free

Slash Command: costruire un sistema di comandi riutilizzabili per Claude Code

Definisci slash command riutilizzabili come file Markdown, condividili con il team tramite git e copri le attività frequenti come revisione del codice, generazione di test e descrizioni PR.


Claude Code include alcuni slash command predefiniti — /help, /clear, /compact. Ma quelli che accelerano davvero il flusso di lavoro sono quelli che scrivi tu stesso.

Questo articolo spiega come progettare un sistema di slash command riutilizzabili in modo che tutto il team condivida la stessa libreria di prompt, invece di riscrivere le descrizioni dei task ogni volta da zero.

Cos'è un Slash Command personalizzato

In Claude Code, uno slash command personalizzato è semplicemente un file Markdown. Mettilo nella directory giusta, Claude Code lo rileva all'avvio, e digitare /nome-file lo attiva.

Il contenuto del file è il prompt inviato a Claude. Tutto qui.

Nessuna sintassi speciale, nessun formato di configurazione — un file .md è un comando.

Dove mettere i file

Due posizioni, due scopi:

Posizione Percorso Ambito
Progetto .claude/commands/ Solo il progetto corrente, può essere committato in git
Utente ~/.claude/commands/ Tutti i progetti, personale

Il livello di progetto è il nucleo della condivisione in team. Committa .claude/commands/ in git e chiunque cloni il repository avrà automaticamente il set completo di comandi.

Il livello utente è per le abitudini personali — i tuoi controlli di stile del codice preferiti o integrazioni di strumenti che usi solo tu.

Creare il primo Command

Dalla root del progetto:

mkdir -p .claude/commands

Crea .claude/commands/review.md:

Rivedi la qualità del codice delle modifiche attuali. Concentrati su:

1. Errori logici e casi limite
2. Se la denominazione è chiara
3. Codice duplicato che vale la pena estrarre
4. Problemi di sicurezza (SQL injection, XSS, segreti esposti)

Dai suggerimenti concreti e attuabili — non consigli generici.

Riavvia Claude Code e digita /review per attivarlo.

Usare $ARGUMENTS per ricevere input

I comandi a contenuto fisso hanno un utilizzo limitato. $ARGUMENTS li rende flessibili — ciò che l'utente digita dopo /comando viene sostituito nel prompt.

Esempio .claude/commands/test.md:

Scrivi test per il seguente: $ARGUMENTS

Requisiti:
- Copri il percorso normale e i casi limite
- I nomi dei test devono essere auto-esplicativi
- Usa dati reali invece di mock dove possibile

Utilizzo:

/test il metodo login della classe UserAuthentication

Claude riceve:

Scrivi test per il seguente: il metodo login della classe UserAuthentication

Requisiti:
...

$ARGUMENTS può apparire ovunque nel prompt ed essere usato più volte.

Principi di design

Un comando, una responsabilità

Non scrivere un comando "tuttofare". /review è per la revisione del codice, /test per scrivere test, /pr per le descrizioni di PR. I comandi mirati sono più facili da ricordare e riutilizzare.

Scrivi prompt concreti, non astratti

Male:

Aiutami a ottimizzare questo codice

Bene:
```
Ottimizza questo codice per le performance. Priorità:
1. Ridurre le query inutili al database (problemi N+1)
2. Evitare calcoli ripetuti nei cicli
3. Sostituire le ricerche lineari con strutture dati più efficienti

Mantieni l'interfaccia invariata — modifica solo l'implementazione.
```

I vincoli concreti portano a risultati mirati.

Aggiungi frontmatter ai tuoi comandi

Il campo description appare nella lista dei comandi di Claude Code, così i membri del team capiscono rapidamente a cosa serve ogni comando:

---
description: Rivede le modifiche attuali per feedback sulla qualità del codice
---

Rivedi la qualità del codice delle modifiche attuali...

Un set pratico di Commands a livello di progetto

Per un progetto Rails, questi comandi coprono le attività di sviluppo quotidiano più comuni:

.claude/commands/review.md — Revisione del codice

```markdown

description: Rivede le modifiche attuali per logica, sicurezza e leggibilità

Rivedi le modifiche in git diff. Verifica:
- Errori logici e gestione dei casi limite
- Problemi di sicurezza: SQL injection, controlli di autorizzazione
- Chiarezza della denominazione
- Logica duplicata che vale la pena estrarre

Per ogni problema, indica la posizione specifica e un suggerimento concreto.
```

.claude/commands/test.md — Generare test

```markdown

description: Genera casi di test per il codice specificato

Scrivi test per questo codice: $ARGUMENTS

Usa RSpec. Copri: percorso normale, casi limite, condizioni di errore.
Formato di denominazione: describe ... context ... it ...
Usa oggetti reali di default; mocka solo le dipendenze esterne quando necessario.
```

.claude/commands/pr.md — Descrizione PR

```markdown

description: Genera titolo e descrizione PR dalle modifiche attuali

Basandoti su git diff e log dei commit, genera una descrizione PR.

Formato:

Cosa è cambiato

(2-3 frasi che riassumono cosa è stato fatto)

Perché

(Contesto e motivazione)

Come testare

(Come verificare questa modifica)

Sii conciso, scritto per un code reviewer.
```

.claude/commands/explain.md — Spiegare il codice

```markdown

description: Spiega cosa fa il file o la funzione specificata

Spiega cosa fa $ARGUMENTS:
- Qual è la sua responsabilità complessiva?
- Come funziona la logica chiave?
- Quali casi limite vale la pena notare?

Scrivi per uno sviluppatore nuovo in questa parte del codice. Concentrati sul perché, non solo sul cosa.
```

Commands a livello utente: flusso di lavoro personale

Alcune abitudini sono personali e non devono essere imposte a tutto il team. Mettile in ~/.claude/commands/:

~/.claude/commands/standup.md — Preparazione standup giornaliero
```markdown
Basandoti sul git log di oggi e sui TODO aperti, prepara un riepilogo per lo standup:
- Cosa ho completato ieri
- Cosa prevedo di fare oggi
- Eventuali blocchi

Massimo 5 frasi.
```

~/.claude/commands/refactor.md — Suggerimenti di refactoring
```markdown
Analizza $ARGUMENTS e suggerisci miglioramenti di refactoring.

Proponi solo modifiche genuinamente utili — non fare refactoring fine a sé stesso.
Per ogni suggerimento, spiega: quale problema risolve, quanto lavoro comporta e qual è il rischio.
```

La chiave per l'adozione in team: committare in git

Il vero valore dei comandi personalizzati non è la produttività individuale — è dare al team un vocabolario condiviso.

Committa .claude/commands/ nel repository e documenta i comandi disponibili nel README o in CLAUDE.md. I nuovi membri hanno la libreria di prompt accumulata dal team nel momento in cui clonano il repo, senza doverla scoprire da soli.

Man mano che il progetto evolve, evolvono anche i comandi. Se un prompt non funziona bene, correggi una riga e fai push — tutto il team riceve l'aggiornamento. Questo è il modo a minor costo per radicare il prompt engineering a livello di team.

Struttura di directory di riferimento

.claude/
├── commands/
│   ├── review.md      # Revisione del codice
│   ├── test.md        # Generare test
│   ├── pr.md          # Descrizione PR
│   └── explain.md     # Spiegare il codice
└── settings.json