> ## Documentation Index
> Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Personalizza Code Review

> Regola ciò che Code Review segnala nelle tue pull request con REVIEW.md e CLAUDE.md: ricalibra la gravità, salta percorsi, aggiungi controlli e scopri quale copia viene applicata.

Puoi cambiare ciò che [Code Review](/docs/it/code-review) segnala nel tuo repository eseguendo il commit di istruzioni al suo interno. È così che riduci il volume dei nit, interrompi i commenti sui file generati o aggiungi una regola a cui il tuo team tiene. Inseriscile in uno di questi due file:

* **`CLAUDE.md`**: [istruzioni di progetto](/docs/it/memory) che Claude Code legge per ogni attività, revisioni incluse. Code Review le legge come contesto di progetto e segnala le modifiche che le violano.
* **`REVIEW.md`**: istruzioni solo per le revisioni. Usalo per indicare cosa il tuo team vuole che venga segnalato, con quale gravità e cosa saltare.

Aggiungi `REVIEW.md` alla root del tuo repository ed esegui il merge. Poi [proteggi il tuo branch predefinito](#which-branch-review-md-is-read-from).

<Note>
  Per cambiare quanto sono approfondite le revisioni o quando vengono eseguite, chiedi a un Owner di modificare il [livello di revisione](/docs/it/code-review-setup#set-the-default-review-level) o l'[impostazione **Review runs**](/docs/it/code-review-setup#set-when-reviews-run).
</Note>

<h2 id="use-claude-md-for-project-wide-rules">
  Usa CLAUDE.md per le regole valide per l'intero progetto
</h2>

Code Review legge i file `CLAUDE.md` del tuo repository come contesto di progetto. Una modifica che viola una delle loro regole diventa un rilevamento al [livello di gravità](/docs/it/code-review-pull-requests#severity-levels) adatto al problema.

Una revisione legge il `CLAUDE.md` nella root del tuo repository e i file `CLAUDE.md` nelle directory padre di ciascun file modificato. Il `CLAUDE.md` di una sottodirectory viene letto quando la pull request modifica un file in quel percorso.

<h2 id="use-review-md-for-review-only-rules">
  Usa REVIEW\.md per le regole specifiche della revisione
</h2>

`REVIEW.md` è un file nella root del tuo repository che adatta Code Review al tuo repository. Puoi anche aggiungere un `REVIEW.md` in una sottodirectory per aggiungere controlli sulle modifiche in quel percorso, in aggiunta al file root.

Gli agenti che individuano i problemi e gli agenti che li verificano ricevono il suo contenuto come istruzioni di revisione del tuo repository, insieme alle indicazioni di revisione predefinite di Code Review. Il passaggio che scrive la revisione finale lo consulta prima di stabilire la gravità e scrivere il riepilogo.

Questo layout di esempio ha un file root e un file in una sottodirectory:

```text theme={null}
your-repo/
├── REVIEW.md            # Root file
├── services/
│   └── billing/
│       └── REVIEW.md    # Adds checks for changes under services/billing/
└── src/
```

Prima di fare affidamento su un file in una sottodirectory, proteggi il tuo branch predefinito e verifica [cosa legge una revisione per la tua configurazione dei branch](#what-a-review-reads-for-each-branch-setup).

<Note>
  Il servizio Code Review e il [comando `/code-review`](/docs/it/code-review-local) locale sono due strumenti separati e leggono file diversi. Il servizio legge sia `CLAUDE.md` sia `REVIEW.md`. Il comando `/code-review`, che esegui all'interno di una sessione di Claude Code sulla tua macchina, legge i tuoi file `CLAUDE.md` e non `REVIEW.md`. Inserisci in `CLAUDE.md` le indicazioni che vuoi applicare in entrambi i contesti e riserva `REVIEW.md` alle regole specifiche della revisione delle pull request.
</Note>

<h3 id="example-review-md">
  Esempio di REVIEW\.md
</h3>

Questo `REVIEW.md` ricalibra la gravità per un servizio backend, limita i nit, salta i file generati e aggiunge controlli specifici del repository.

```markdown theme={null}
# Review instructions

## What Important means here

Reserve Important for findings that would break behavior, leak data,
or block a rollback: incorrect logic, unscoped database queries, PII
in logs or error messages, and migrations that aren't backward
compatible. Style, naming, and refactoring suggestions are Nit at
most.

## Cap the nits

Report at most five Nits per review.

## Do not report

- Anything CI already enforces: lint, formatting, type errors
- Generated files under `src/gen/` and any `*.lock` file
- Test-only code that intentionally violates production rules

## Always check

- New API routes have an integration test
- Log lines don't include email addresses, user IDs, or request bodies
- Database queries are scoped to the caller's tenant
```

<h3 id="choose-what-to-write-in-review-md">
  Scegli cosa scrivere in REVIEW\.md
</h3>

`REVIEW.md` è Markdown in formato libero che cambia ciò che una revisione individua e riporta. Non cambia il formato della revisione. Trova il problema che stai riscontrando, quindi aggiungi un'istruzione come quella mostrata. L'[esempio](#example-review-md) usa le prime quattro.

* **Vengono contrassegnate come Important le cose sbagliate**: ridefinisci cosa significa 🔴 Important per il tuo repository. La calibrazione predefinita è pensata per il codice di produzione, e un repository di documentazione, un repository di configurazione o un prototipo potrebbero richiedere una definizione molto più ristretta. Indica quali classi di rilevamenti sono Important e quali sono al massimo Nit. Puoi anche alzare la gravità, ad esempio trattando qualsiasi violazione di `CLAUDE.md` come Important.
* **Troppi nit**: limita quanti commenti 🟡 Nit pubblica una singola revisione. Un limite come "riporta al massimo cinque nit" mantiene le revisioni utilizzabili.
* **Commenti sui file generati o su ciò che la CI controlla già**: elenca i percorsi e le categorie di rilevamenti per cui Claude deve saltare le segnalazioni. I candidati comuni sono il codice generato, i lockfile e le dipendenze vendorizzate, oltre a tutto ciò che la tua CI già applica, come il linting o il controllo ortografico. Per i percorsi che meritano una certa revisione ma non un esame completo, imposta invece una soglia più alta: "in `scripts/`, segnala solo se quasi certo e grave."
* **Una regola del team non viene controllata**: aggiungi le regole che vuoi vengano segnalate in ogni pull request, come "le nuove route API devono avere un test di integrazione."
* **Rilevamenti che si rivelano errati**: richiedi prove prima che una classe di rilevamenti venga pubblicata. Ad esempio, "le affermazioni sul comportamento richiedono una citazione `file:line` nel sorgente, non un'inferenza basata sui nomi" riduce i falsi positivi che altrimenti costerebbero all'autore un ulteriore scambio.

Alcune di queste istruzioni [richiedono il file root su un branch predefinito protetto](#which-branch-review-md-is-read-from).

Limita `REVIEW.md` alle istruzioni che cambiano il comportamento della revisione e lascia il contesto generale del progetto in `CLAUDE.md`.

<h3 id="which-branch-review-md-is-read-from">
  Da quale branch viene letto REVIEW\.md
</h3>

Code Review legge `REVIEW.md` dal branch di base della pull request o dal branch predefinito, mai dalle modifiche della pull request stessa. Per cambiare il comportamento della revisione, esegui prima il merge della modifica a `REVIEW.md`.

Mantieni `REVIEW.md` sul tuo branch predefinito e proteggi quel branch. Quando una revisione legge la copia su un branch predefinito protetto, la prima riga della tabella seguente, rispetta queste istruzioni del file root:

* Abbassare la gravità di un rilevamento
* Escludere percorsi, file o classi di problemi
* Limitare i commenti nit

<h4 id="what-counts-as-branch-protection">
  Cosa conta come protezione del branch
</h4>

Code Review considera come protezione queste impostazioni:

* **Branch predefinito**: una regola classica di protezione del branch o un ruleset
* **Qualsiasi altro branch**: solo un ruleset

Un ruleset conta quando limita gli aggiornamenti o richiede pull request con almeno un'approvazione. Se richiede pull request, deve anche annullare quell'approvazione a ogni nuovo push oppure richiedere che l'approvazione arrivi dopo l'ultimo push.

<h4 id="what-a-review-reads-for-each-branch-setup">
  Cosa legge una revisione per ciascuna configurazione dei branch
</h4>

Trova la situazione del tuo repository nella prima colonna della tabella seguente.

| Protezione del branch | Copia letta | File letti |
| :- | :- | :- |
| Il branch predefinito è protetto e la pull request punta a esso o a un branch non protetto da alcun ruleset | Branch predefinito | File root e delle sottodirectory |
| La pull request punta a un altro branch protetto da un ruleset | Quel branch di base | File root e delle sottodirectory |
| Il branch predefinito non è protetto e il branch di base non ha regole di protezione di nessuno dei due tipi | Branch predefinito | File root |
| Code Review non riesce a confermare le impostazioni di protezione. Questo include un branch predefinito non protetto con un branch di base che ha solo una regola classica | Nessuna | Nessuno |

Se il check run menziona `REVIEW.md`, consulta [Il check run menziona REVIEW.md](/docs/it/code-review-troubleshooting#the-check-run-mentions-review-md).

<h2 id="related-resources">
  Risorse correlate
</h2>

* [Code Review](/docs/it/code-review): cos'è il servizio e come viene eseguita una revisione
* [Leggere e richiedere revisioni su una pull request](/docs/it/code-review-pull-requests#severity-levels): cosa significa ciascun livello di gravità e come appaiono i rilevamenti
* [Configurare Code Review](/docs/it/code-review-setup): il livello di revisione e quando vengono eseguite le revisioni, impostati da un Owner
* [Revisione locale con `/code-review`](/docs/it/code-review-local): il comando `/code-review`, i suoi argomenti e i livelli di sforzo
* [Memoria](/docs/it/memory): come funzionano i file `CLAUDE.md` in Claude Code