Claude Code skills: comandi pronti per il lavoro in team

Un comando utile al team specifica gli input, i riscontri da esaminare e la forma della risposta. È una scheda di lavoro conservata accanto al codice: digitandone il nome, la applichi all'attività del momento.

Parti da /plan, /diff, /context e /compact. Poi aggiungi /team-pr-check, uno dei modelli qui sotto. La revisione del codice è un ottimo punto di partenza: a ogni modifica tornano le stesse domande su permessi, dati e test.

I comandi integrati di Claude Code da conoscere

Inseriscili all'inizio di un messaggio in Claude Code. Le parentesi quadre indicano argomenti facoltativi; quelle angolari, argomenti obbligatori. La selezione mantiene la sintassi della documentazione dei comandi di Anthropic, verificata il 13 ottobre 2026. La disponibilità dipende da piattaforma, piano e ambiente.

Usa /compact quando prosegui lo stesso lavoro e /clear quando passi a un'altra attività. Per una funzionalità ancora in sviluppo, un'istruzione utile è /compact keep the acceptance criteria, unresolved risks, and exact test commands.

/release-notes apre il changelog di Claude Code. Non prepara le note di rilascio della tua applicazione. Il comando personalizzato proposto più avanti ha un nome diverso proprio per questo.

Per integrare questi comandi nel lavoro quotidiano, consulta le buone pratiche per Claude Code.

Nel menu dei comandi compaiono anche le skill incluse

Alcune voci del menu slash affidano a Claude una procedura da seguire. Sono skill incluse nel prodotto, distinte dai comandi fissi della CLI:

• /code-review esamina un diff o un altro oggetto supportato. /review è il suo alias. Aggiungendo --fix richiedi modifiche; con --comment chiedi di pubblicare commenti di revisione.
• /simplify esamina il codice modificato per individuare interventi di pulizia e li applica.
• /verify compila ed esegue l'applicazione per verificarne il comportamento.
• /doctor diagnostica i problemi di configurazione e propone soluzioni.

Scegli una semplice revisione se vuoi conoscere i problemi prima di modificare il codice. Sintassi completa, prerequisiti e disponibilità di questi comandi sono descritti nelle voci dedicate alle skill incluse nella documentazione dei comandi.

Claude Code skills: il formato dei comandi personalizzati

Per le nuove procedure, salva un file di istruzioni Markdown in .claude/skills/<name>/SKILL.md nel repository. Includilo in un commit perché i colleghi ricevano la stessa procedura. Le procedure personali vanno invece in ~/.claude/skills/<name>/SKILL.md.

Il vecchio formato .claude/commands/<name>.md funziona ancora. Entrambe le forme creano comandi /<name>. Una cartella di skill può contenere anche modelli, documenti di riferimento e script: preferisci questo formato quando la procedura cresce. Guida di Anthropic alle skill

Da dove arrivano i comandi dei plugin e di MCP?

I plugin raccolgono funzionalità in pacchetti riutilizzabili. Le loro cartelle skills/<name>/SKILL.md creano comandi con namespace, come /plugin-name:skill-name. I comandi dei plugin nel vecchio formato si trovano in commands/. Queste cartelle vanno nella radice del plugin, accanto alla cartella .claude-plugin/ che contiene il manifest, non al suo interno. Usa /plugin per gestire i plugin e /reload-plugins dopo le modifiche. Componenti dei plugin

Parti dalle skill di progetto finché il processo riguarda una sola base di codice. Valuta un plugin quando devi mantenere e distribuire lo stesso processo su più repository. La guida ai migliori plugin per Claude Code presenta pacchetti già disponibili che vale la pena esaminare prima di crearne un altro.

I prompt MCP arrivano dai server collegati. MCP, il Model Context Protocol, collega Claude Code a strumenti e dati esterni. Un server può anche pubblicare prompt riutilizzabili. Il menu li mostra come /servername:promptname (MCP); puoi richiamarli anche con /mcp__servername__promptname. Compaiono soltanto se il server collegato espone quei prompt. Un'integrazione che offre strumenti non fornisce automaticamente tutti i prompt di cui potresti avere bisogno. Documentazione dei prompt MCP

Gli argomenti dei prompt MCP vengono separati in corrispondenza degli spazi e seguono i parametri dichiarati dal server. Il risultato del prompt entra nella conversazione. Non dare per scontato che un prompt del server gestisca gli argomenti come una skill locale.

Scrivi il file, poi passa gli input del lavoro

Il frontmatter è il breve blocco di impostazioni YAML che precede le istruzioni Markdown. Il delimitatore iniziale --- deve trovarsi sulla prima riga del file. Ecco i campi utili per questi modelli:

allowed-tools concede autorizzazioni: non limita l'uso ai soli strumenti elencati. Tutti i campi del frontmatter sono facoltativi; description è consigliato. I file dei comandi nel vecchio formato accettano gli stessi campi, tranne name e paths. Riferimento del frontmatter

Argomenti: $ARGUMENTS inserisce l'intera stringa di input. $0 o $ARGUMENTS[0] indica il primo argomento; $1 il secondo. Gli argomenti con nome corrispondono alle posizioni nell'ordine dichiarato. Racchiudi tra virgolette un valore posizionale composto da più parole. argument-hint documenta gli input, ma la procedura deve comunque verificarli. Sostituzione degli argomenti

I modelli omettono name, quindi il nome viene dalla cartella. Il loro frontmatter funziona anche nei file dei comandi del vecchio formato. Conserva le informazioni stabili sul repository nella memoria del team in CLAUDE.md e i passaggi di una specifica attività nella relativa skill.

Cinque comandi personalizzati pronti per il team

Crea le cartelle indicate qui sotto e incolla ciascun blocco nel relativo SKILL.md. Esegui /reload-skills per rileggere i nuovi file. Sono modelli originali da adattare: non sono comandi inclusi da Anthropic e non vengono presentati come risultati di test.

L'ordine dà la precedenza ai controlli tecnici ripetibili, poi alla comunicazione. I modelli usano, quando possibile, riscontri disponibili nel repository locale. Per produrre un risultato utile non richiedono un collegamento a un sistema di gestione delle segnalazioni o delle PR.

Una checklist per le PR che toccano i dati dei clienti

Un piccolo team SaaS potrebbe usarla prima di richiedere una revisione umana. Ripropone le stesse domande su isolamento dei tenant, autorizzazioni e copertura dei test anche quando chi ha scritto il codice va di fretta. Il vantaggio è un passaggio alla revisione più uniforme, in cui ogni problema è collegato a un punto del codice e a uno scenario di errore.

Salva il file come .claude/skills/team-pr-check/SKILL.md. Richiamalo con /team-pr-check main per confrontare il branch corrente con il suo antenato comune con main.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

Una checklist è utile quando riflette i problemi che si verificano davvero nel tuo prodotto. Sostituisci i controlli generici con quelli sui confini rilevanti, come la titolarità degli account, lo stato di fatturazione o i permessi ereditati tramite i team.

Prima il test, poi la correzione di un bug riproducibile

Un founder che mantiene un prodotto in produzione potrebbe usarla quando una segnalazione include un modo concreto per riprodurre il bug. La procedura comprende sia la riproduzione del comportamento errato sia il controllo di regressione: una patch plausibile non basta a considerare concluso il lavoro.

Salva il file come .claude/skills/team-test-first-fix/SKILL.md. Richiamalo con /team-test-first-fix duplicate webhook events create duplicate invoices.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

Questa procedura è adatta ai difetti riproducibili. Se l'incidente in produzione è intermittente e mancano riscontri, comincia dall'indagine invece di forzare il comando a inventare un test che fallisce.

Un piano di migrazione prima di intervenire su un sistema condiviso

Un team che modifica lo schema di un database o sostituisce un'API potrebbe usarla per far emergere i dubbi su sequenza e compatibilità prima di passare all'implementazione. Il risultato utile è un piano da discutere, soprattutto quando vecchie e nuove versioni dovranno funzionare insieme.

Salva il file come .claude/skills/team-migration-plan/SKILL.md. Richiamalo con /team-migration-plan "billing storage" "new invoice schema".

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

L'istruzione di pianificare non cambia la modalità dei permessi di Claude Code. Se vuoi che anche la sessione sia in Plan Mode, inserisci /plan prima di richiamare questa skill. Considera la procedura scritta e i permessi degli strumenti della sessione come controlli distinti. Plan Mode

Note di rilascio per il tuo prodotto

Uno sviluppatore che si occupa dei rilasci potrebbe usarla per trasformare un intervallo definito di modifiche in una bozza destinata ai clienti. Riduce il lavoro necessario per spiegare l'impatto dei commit sugli utenti e richiede riscontri per ogni affermazione.

Salva il file come .claude/skills/team-release-notes/SKILL.md. Richiamalo con /team-release-notes previous-release HEAD, sostituendo previous-release con un tag o un commit esistente.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

Un intervallo di codice dimostra che cosa è cambiato nel repository. Non dimostra quali clienti abbiano ricevuto la modifica. Verifica lo stato del rilascio prima di pubblicare la bozza.

Un changelog settimanale per il team

Un responsabile tecnico potrebbe usarla per preparare l'aggiornamento settimanale destinato a prodotto e assistenza. Separa il lavoro integrato nel branch dai rilasci verificati, evitando di annunciare per errore qualcosa ancora dietro un flag.

Salva il file come .claude/skills/team-weekly-changelog/SKILL.md. Richiamalo con /team-weekly-changelog START_DATE END_DATE main, sostituendo le date con timestamp ISO che includano il fuso orario. L'intervallo include l'inizio ed esclude la fine.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

Tieni separate le note di rilascio dagli aggiornamenti settimanali. Un rilascio riguarda un insieme definito di modifiche al codice e si rivolge ai clienti. Un aggiornamento settimanale copre un periodo di rendicontazione e può includere lavoro utile che non è ancora stato rilasciato.

Come capire se vale la pena mantenere un comando?

Misura il lavoro ripetitivo che accompagna l'uso del modello, non quanto colpisce la sua prima risposta.

Il valore settimanale si calcola così: esecuzioni × (tempo di preparazione e correzione precedente − tempo di preparazione e correzione attuale) × costo orario del team − spesa aggiuntiva per il modello − tempo di manutenzione valorizzato allo stesso costo orario. Inserisci le tue misurazioni. Un prompt più lungo che richiede più lavoro di revisione può farti perdere denaro, anche se dà l'impressione di automatizzare di più.

La voce di costo su cui è più probabile incidere è il tempo che gli sviluppatori senior dedicano a rispiegare lo stesso processo e a rimediare a passaggi di consegne incompleti. La procedura richiede comunque manutenzione quando cambiano l'architettura o il processo di rilascio.

Un comando salvato continua a consumare risorse del modello quando Claude lo esegue. /usage riporta stime del costo dei token e informazioni sull'utilizzo del piano; una stima del costo API visualizzata non è la fattura dell'abbonamento. Documentazione di Anthropic sui costi

Due idee da sviluppare a partire da questi comandi

I modelli sono utili come strumenti interni. Per trasformarli in un prodotto serve un vantaggio più solido del semplice salvataggio di un prompt.

L'opportunità più promettente: controlli di revisione su misura per il repository

Un piccolo team software potrebbe pagare per un pacchetto di revisione aggiornato che conosca i punti a maggior rischio del suo codice: quali tabelle appartengono a un account, quali azioni incidono sulla fatturazione e quali test devono accompagnare una modifica.

Il 13 ottobre 2026, la panoramica delle keyword di DataForSEO per Google negli Stati Uniti, in inglese, ha restituito 1,300 ricerche mensili stimate per “ai code review”. Il dato segnala interesse per l'attività, non domanda per uno specifico plugin di Claude Code. Panoramica delle keyword di DataForSEO

La versione minima vendibile potrebbe combinare una checklist di progetto, note sull'architettura e un insieme di bug passati con cui valutarla. Prima di distribuirla come plugin, verifica che produca su quegli esempi rilievi sostenuti da riscontri.

L'ostacolo è una concorrenza forte: Claude Code include già funzionalità di revisione e CodeRabbit vende strumenti per la revisione del codice. Un prompt generico per la revisione offre poco con cui distinguersi. Sceglierei questa opportunità solo avendo accesso alla storia dei problemi di un team specifico e una persona responsabile di mantenere accurati i controlli.

Un'opportunità più contenuta: comunicare i rilasci con riscontri verificabili

Un team di prodotto potrebbe usare un flusso di lavoro mantenuto nel tempo che trasformi le modifiche del repository in note di rilascio per i clienti e in un riepilogo interno per l'assistenza, con riferimenti alle fonti e una verifica esplicita dello stato di distribuzione.

La stessa panoramica delle keyword ha restituito 70 ricerche mensili stimate per “release notes generator”. È un segnale di ricerca modesto: partirei quindi da un servizio o da un flusso di lavoro interno, prima di sviluppare un software autonomo. Panoramica delle keyword di DataForSEO

La versione minima potrebbe produrre bozze da un intervallo Git scelto, nel formato già usato dal team. La parte difficile è collegare le modifiche ai flag, ai deployment e all'effettiva disponibilità per i clienti. Il comando può organizzare i riscontri; non può creare quelli che il team non registra.

I limiti da considerare nel codice aziendale

Un comando rende uniformi le istruzioni. A stabilire se il risultato è accettabile restano i test, la revisione e i controlli di rilascio. Considera i cinque modelli come procedure di partenza e revisiona le loro modifiche insieme a quelle del codice applicativo.

Il contenuto completo di una skill viene caricato quando la si usa: mantieni quindi concisa la procedura e sposta i riferimenti dettagliati nei file di supporto. Le skill personali possono avere la precedenza su quelle di progetto con lo stesso nome; nelle sessioni locali da terminale, le skill possono anche nascondere i comandi integrati omonimi. Scegli nomi distintivi e controlla la provenienza delle skill quando i colleghi ottengono comportamenti diversi. Caricamento e precedenza delle skill

Per i permessi, configura separatamente le effettive regole degli strumenti. Una frase come “solo revisione” comunica a Claude la tua intenzione, ma non impone un vincolo a livello di sistema operativo. Permessi di Claude Code

Da dove partire lunedì

Includi per primo /team-pr-check nel repository. Sostituisci i punti generici con i controlli che la tua ultima modifica problematica avrebbe dovuto superare. Eseguilo su una modifica completata di cui conosci l'esito, confronta i rilievi con il problema effettivo e correggi la procedura prima di farla entrare nelle abitudini del team. Aggiungi i comandi per i rilasci e gli aggiornamenti settimanali quando ne avrete concordato i formati di output.

Se vuoi collegare questi flussi di lavoro ai tuoi sistemi aziendali, sviluppo automazioni AI basate sui controlli di cui il tuo team ha davvero bisogno.