Usa il prefisso ! per eseguire comandi shell dentro gli slash command, iniettando automaticamente diff, contenuto dei file e risultati dei test
La maggior parte degli slash command ha questo aspetto:
Esamina la qualità del codice nelle modifiche attuali e fornisci suggerimenti concreti.
Funziona, ma c'è un limite di fondo: Claude deve dedurre da solo cosa siano «le modifiche attuali». Se il tuo command inietta attivamente il contesto, i risultati cambiano completamente.
Questo articolo spiega come trasformare i command in istruzioni dotate di «vista» — che al momento dell'attivazione leggono automaticamente il contenuto dei file, lo stato di git e le informazioni del progetto, infilando tutto nel prompt in modo che Claude non debba indovinare.
!`comando` inietta l'output della ShellGli slash command personalizzati permettono di incorporare comandi shell direttamente nel prompt. La sintassi: racchiudere il comando tra backtick e farlo precedere da un punto esclamativo, !`comando`. All'attivazione, il comando viene eseguito per primo, l'output sostituisce il segnaposto, e Claude riceve il prompt già assemblato.
Ecco il git diff attuale:
!`git diff HEAD`
Esamina queste modifiche, concentrandoti su errori logici e problemi di sicurezza.
Per i comandi multi-riga usa un blocco di codice fenced che inizia con
```!:```! node --version git status --short ```
Quando si attiva /review, ciò che Claude riceve davvero è:
Ecco il git diff attuale:
diff --git a/app/models/user.rb b/app/models/user.rb
index 3a2f1c8..9b4e2d1 100644
--- a/app/models/user.rb
+++ b/app/models/user.rb
@@ -12,6 +12,9 @@ class User < ApplicationRecord
...
Esamina queste modifiche, concentrandoti su errori logici e problemi di sicurezza.
Niente copia-incolla manuale: nell'istante in cui il command si attiva, il diff è già lì dentro.
---
allowed-tools: Bash(cat:*)
---
Ecco il contenuto completo del file corrente:
!`cat $ARGUMENTS`
Trova tutti i potenziali problemi di performance in questo file. Indica numeri di riga e correzioni concrete.
Utilizzo: /perf app/models/order.rb
$ARGUMENTS riceve il percorso del file, e cat ne legge il contenuto per iniettarlo. Claude vede codice reale, non una descrizione vaga del tipo «guarda il file corrente».
allowed-toolsnel frontmatter pre-autorizza il comandocat, quindi all'attivazione non compare alcuna conferma di permesso. Senza questa riga dovresti cliccare «Consenti» a ogni esecuzione. Tutti gli esempi che seguono richiedono la stessa dichiarazione.
Branch corrente e stato delle modifiche:
!`git status --short`
!`git log --oneline -10`
Sulla base di queste informazioni, genera una descrizione PR concisa che copra cosa è cambiato e perché.
Questo command /pr non ti chiede di descrivere «cosa ho cambiato» — se lo va a leggere da solo.
Stack tecnologico del progetto:
!`cat .claude/context/stack.md`
Schema attuale del database (tabelle principali):
!`head -100 db/schema.rb`
Con questo contesto, scrivi uno script di migration per $ARGUMENTS seguendo le convenzioni del progetto.
Metti in anticipo le informazioni di contesto del progetto in .claude/context/, e il command le leggerà al volo all'attivazione, senza dover ridescrivere il progetto ogni volta.
Ultima esecuzione dei test:
!`bundle exec rspec --format progress 2>&1 | tail -30`
Questi sono i test falliti. Analizza la causa radice e proponi correzioni. Non toccare i test stessi.
Quando /fix-tests parte, lancia direttamente i test e ne raccoglie l'output — Claude vede i veri messaggi di errore.
Combinando tutto quanto, /review può diventare davvero preciso:
---
description: Esamina le modifiche attuali, inietta diff e contesto automaticamente
allowed-tools: Bash(git diff:*), Bash(cat:*)
---
## Modifiche attuali
!`git diff HEAD`
## File coinvolti
!`git diff HEAD --name-only`
## Standard di codifica del progetto
!`cat .claude/context/coding-standards.md 2>/dev/null || echo "(nessun file di standard)"`
---
Esamina le modifiche sopra:
1. Correttezza logica: casi limite non gestiti, errori di logica
2. Sicurezza: SQL injection, controlli di autorizzazione, esposizione di dati sensibili
3. Conformità agli standard: rispetta gli standard di codifica del progetto?
4. Leggibilità: denominazione, commenti, struttura
Per ogni problema indica nome del file, numero di riga e un suggerimento concreto. Se non ci sono problemi, dillo — non riempire tanto per riempire.
Questo command non richiede nessuna preparazione da parte tua: all'attivazione, diff, lista dei file e standard di codifica vengono iniettati automaticamente.
I comandi shell possono fallire (file inesistente, comando non nel PATH, ecc.). Usa || per fornire un valore di default ed evitare che il command si interrompa:
!`git diff HEAD 2>/dev/null || echo "(nessuna modifica git o non è un repository git)"`
!`cat .env.example 2>/dev/null || echo "(file .env.example assente)"`
!`which rspec > /dev/null 2>&1 && bundle exec rspec --dry-run 2>&1 | head -20 || echo "(RSpec non rilevato)"`
Quando un comando fallisce, Claude riceve un testo esplicativo invece di uno spazio vuoto, e può adattare la propria risposta di conseguenza.
Tutto l'output dei comandi ! finisce nella context window. Qualche trappola classica:
Non fare cat di file grandi interi
# Pericoloso: può iniettare decine di migliaia di righe
!`cat db/schema.rb`
# Meglio: estrai solo ciò che serve
!`grep -A 5 "create_table \"orders\"" db/schema.rb`
Limita i file di log con un numero di righe
!`tail -50 log/development.log`
Tronca l'output dei test
!`bundle exec rspec 2>&1 | tail -40`
Più il contesto è preciso, migliori sono le risposte di Claude. Buttargli dentro tutto il codice non lo rende più intelligente, lo fa solo perdere nel rumore.
Domanda frequente: le info di contesto del progetto vanno in CLAUDE.md o iniettate dinamicamente con !?
Criterio:
| Tipo di informazione | Dove va |
|---|---|
| Contesto di progetto sempre necessario (stack, struttura, convenzioni) | CLAUDE.md |
| Stato che cambia nel tempo (diff corrente, risultati dei test, contenuto dei file) | Iniezione dinamica con ! |
| Contesto specifico di un task (documento di design di un certo modulo) | !cat su richiesta |
CLAUDE.md è conoscenza di sfondo persistente, ! è uno snapshot al momento del task. I due si completano — non duplicare.
.claude/commands/ completa.claude/
├── commands/
│ ├── review.md # Review: inietta diff + standard
│ ├── test.md # Scrivere test: inietta il file target
│ ├── fix-tests.md # Riparare test: inietta i fallimenti
│ ├── pr.md # Descrizione PR: inietta git log + status
│ ├── explain.md # Spiegare codice: inietta il contenuto del file
│ └── migrate.md # Scrivere migration: inietta frammenti di schema
├── context/
│ ├── stack.md # Descrizione dello stack tecnologico
│ └── coding-standards.md # Standard di codifica
└── settings.json
La directory context/ ospita i file di contesto statici che i vari command leggono on demand. Questa struttura si committa direttamente in git e si condivide nel team.
Command statico:
Esamina le modifiche al codice attuali.
Claude deve prima chiedere «dove sono le modifiche?» o cercarle da sé — risultati instabili.
Command consapevole del contesto:
Ecco il diff (con il contenuto reale), ecco gli standard pertinenti (con il contenuto reale), esamina.
Claude passa direttamente all'analisi. Risposte precise, niente fronzoli, niente continui chiarimenti.
La differenza non sta nelle capacità di Claude, ma in quante informazioni reali gli hai dato.