cc-viewer 1.6.182 → 1.6.183

package/concepts/it/Tool-Grep.md

@@ -1,57 +1,46 @@
 # Grep
 
-## Definizione
+Cerca i contenuti dei file usando il motore ripgrep. Offre supporto completo per espressioni regolari, filtraggio per tipo di file e tre modalità di output così da poter scambiare precisione per compattezza.
 
-Potente strumento di ricerca nel contenuto basato su ripgrep. Supporta espressioni regolari, filtro per tipo di file e diverse modalità di output.
+## Quando usare
+
+- Localizzare ogni call site di una funzione o ogni riferimento a un identificatore
+- Verificare se una stringa o un messaggio di errore appare ovunque nel codebase
+- Contare le occorrenze di un pattern per misurare l'impatto prima di un refactor
+- Restringere una ricerca a un tipo di file (`type: "ts"`) o glob (`glob: "**/*.tsx"`)
+- Estrarre corrispondenze multi-riga come definizioni di struct multi-riga o blocchi JSX con `multiline: true`
 
 ## Parametri
 
-| Parametro | Tipo | Obbligatorio | Descrizione |
-|------|------|------|------|
-| `pattern` | string | Sì | Pattern di ricerca con espressione regolare |
-| `path` | string | No | Percorso di ricerca (file o directory), predefinita la directory di lavoro corrente |
-| `glob` | string | No | Filtro per nome file (es. `*.js`, `*.{ts,tsx}`) |
-| `type` | string | No | Filtro per tipo di file (es. `js`, `py`, `rust`), più efficiente di glob |
-| `output_mode` | enum | No | Modalità di output: `files_with_matches` (predefinita), `content`, `count` |
-| `-i` | boolean | No | Ricerca senza distinzione maiuscole/minuscole |
-| `-n` | boolean | No | Mostra numeri di riga (solo modalità content), predefinito true |
-| `-A` | number | No | Numero di righe da mostrare dopo la corrispondenza |
-| `-B` | number | No | Numero di righe da mostrare prima della corrispondenza |
-| `-C` / `context` | number | No | Numero di righe da mostrare prima e dopo la corrispondenza |
-| `head_limit` | number | No | Limita il numero di voci nell'output, predefinito 0 (illimitato) |
-| `offset` | number | No | Salta i primi N risultati |
-| `multiline` | boolean | No | Abilita la modalità di corrispondenza multiriga, predefinito false |
-
-## Scenari d'uso
-
-**Adatto per:**
-- Cercare stringhe o pattern specifici nel codebase
-- Trovare dove vengono usate funzioni/variabili
-- Filtrare i risultati di ricerca per tipo di file
-- Contare il numero di corrispondenze
-
-**Non adatto per:**
-- Cercare file per nome — usare Glob
-- Esplorazione aperta che richiede più cicli di ricerca — usare Task (tipo Explore)
+- `pattern` (string, obbligatorio): L'espressione regolare da cercare. Usa la sintassi ripgrep, quindi le parentesi graffe letterali devono essere escapate (ad esempio `interface\{\}` per trovare `interface{}`).
+- `path` (string, opzionale): File o directory da cercare. Default: working directory corrente.
+- `glob` (string, opzionale): Filtro di nome file come `*.js` o `*.{ts,tsx}`.
+- `type` (string, opzionale): Scorciatoia per tipo di file come `js`, `py`, `rust`, `go`. Più efficiente di `glob` per linguaggi standard.
+- `output_mode` (enum, opzionale): `files_with_matches` (default, restituisce solo i percorsi), `content` (restituisce le righe corrispondenti) o `count` (restituisce i conteggi delle corrispondenze).
+- `-i` (boolean, opzionale): Abbinamento case-insensitive.
+- `-n` (boolean, opzionale): Include i numeri di riga in modalità `content`. Default `true`.
+- `-A` (number, opzionale): Righe di contesto da mostrare dopo ogni corrispondenza (richiede modalità `content`).
+- `-B` (number, opzionale): Righe di contesto prima di ogni corrispondenza (richiede modalità `content`).
+- `-C` / `context` (number, opzionale): Righe di contesto su entrambi i lati di ogni corrispondenza.
+- `multiline` (boolean, opzionale): Permette ai pattern di estendersi su più righe (`.` corrisponde a `\n`). Default `false`.
+- `head_limit` (number, opzionale): Limita le righe restituite, i percorsi dei file o le voci di conteggio. Default 250; passa `0` per illimitato (usa con parsimonia).
+- `offset` (number, opzionale): Salta i primi N risultati prima di applicare `head_limit`. Default `0`.
+
+## Esempi
+
+### Esempio 1: Trovare tutti i call site di una funzione
+Imposta `pattern: "registerHandler\\("`, `output_mode: "content"` e `-C: 2` per vedere le righe circostanti di ogni chiamata.
+
+### Esempio 2: Contare le corrispondenze su un tipo
+Imposta `pattern: "TODO"`, `type: "py"` e `output_mode: "count"` per vedere i totali per file di TODO nei sorgenti Python.
+
+### Esempio 3: Corrispondenza di struct multi-riga
+Usa `pattern: "struct Config \\{[\\s\\S]*?version"` con `multiline: true` per catturare un campo dichiarato diverse righe dentro una struct Go.
 
 ## Note
 
-- Usa la sintassi ripgrep (non grep), i caratteri speciali come le parentesi graffe devono essere escapati
-- La modalità `files_with_matches` restituisce solo i percorsi dei file, la più efficiente
-- La modalità `content` restituisce il contenuto delle righe corrispondenti, supporta righe di contesto
-- La corrispondenza multiriga richiede l'impostazione `multiline: true`
-- Usare sempre lo strumento Grep anziché i comandi `grep` o `rg` in Bash
-
-## Testo originale
-
-<textarea readonly>A powerful search tool built on ripgrep
-
-  Usage:
-  - ALWAYS use Grep for search tasks. NEVER invoke `grep` or `rg` as a Bash command. The Grep tool has been optimized for correct permissions and access.
-  - Supports full regex syntax (e.g., "log.*Error", "function\s+\w+")
-  - Filter files with glob parameter (e.g., "*.js", "**/*.tsx") or type parameter (e.g., "js", "py", "rust")
-  - Output modes: "content" shows matching lines, "files_with_matches" shows only file paths (default), "count" shows match counts
-  - Use Agent tool for open-ended searches requiring multiple rounds
-  - Pattern syntax: Uses ripgrep (not grep) - literal braces need escaping (use `interface\{\}` to find `interface{}` in Go code)
-  - Multiline matching: By default patterns match within single lines only. For cross-line patterns like `struct \{[\s\S]*?field`, use `multiline: true`
-</textarea>
+- Preferisci sempre `Grep` all'esecuzione di `grep` o `rg` tramite `Bash`; il tool è ottimizzato per permessi corretti e output strutturato.
+- La modalità di output predefinita è `files_with_matches`, che è la più economica. Passa a `content` solo quando devi vedere le righe stesse.
+- I flag di contesto (`-A`, `-B`, `-C`) sono ignorati a meno che `output_mode` non sia `content`.
+- Insiemi di risultati grandi bruciano token di contesto. Usa `head_limit`, `offset` o filtri `glob`/`type` più stretti per restare focalizzati.
+- Per la scoperta di nomi di file, usa invece `Glob`; per indagini aperte su molti cicli, invia un `Agent` con l'agente Explore.

package/concepts/it/Tool-Monitor.md

@@ -0,0 +1,50 @@
+# Monitor
+
+Avvia un monitor in background che trasmette eventi da uno script a lunga esecuzione. Ogni riga dell'output standard diventa una notifica — continua a lavorare mentre gli eventi arrivano nella chat.
+
+## Quando usare
+
+- Seguire errori, avvisi o firme di crash in un file di log mentre è in corso un deployment
+- Interrogare un'API remota, una PR o una pipeline CI ogni 30 secondi per rilevare nuovi eventi di stato
+- Sorvegliare le modifiche in una directory del filesystem o nell'output di compilazione in tempo reale
+- Attendere una condizione specifica su molte iterazioni (ad esempio un traguardo di un passo di addestramento o lo svuotamento di una coda)
+- **Non** per un semplice "aspetta fino al completamento" — usare `Bash` con `run_in_background` per quello; emette una notifica di completamento quando il processo termina
+
+## Parametri
+
+- `command` (stringa, obbligatorio): Il comando shell o lo script da eseguire. Ogni riga scritta nello stdout diventa un evento di notifica separato. Il monitor termina quando il processo termina.
+- `description` (stringa, obbligatorio): Una breve etichetta leggibile mostrata in ogni notifica. Essere specifici — "errori in deploy.log" è meglio di "osservando i log". Questa etichetta identifica quale monitor si è attivato.
+- `timeout_ms` (numero, predefinito `300000`, max `3600000`): Scadenza di terminazione forzata in millisecondi. Dopo questa durata il processo viene terminato. Ignorato quando `persistent: true`.
+- `persistent` (booleano, predefinito `false`): Quando `true`, il monitor viene eseguito per tutta la durata della sessione senza timeout. Fermarlo esplicitamente con `TaskStop`.
+
+## Esempi
+
+### Esempio 1: Seguire un file di log per errori e crash
+
+Questo esempio copre tutti gli stati terminali: marcatore di successo, traceback, parole chiave di errore comuni, terminazione OOM e uscita inaspettata del processo.
+
+```bash
+tail -F /var/log/deploy.log | grep -E --line-buffered \
+  "deployed|Traceback|Error|FAILED|assert|Killed|OOM"
+```
+
+Usare `grep --line-buffered` in ogni pipe. Senza di esso il sistema operativo memorizza l'output in blocchi da 4 KB e gli eventi possono subire ritardi di minuti. Il motivo di alternanza copre sia il percorso di successo (`deployed`) sia i percorsi di fallimento (`Traceback`, `Error`, `FAILED`, `Killed`, `OOM`). Un monitor che osserva solo il marcatore di successo rimane silenzioso durante un crash — il silenzio è identico a "ancora in esecuzione".
+
+### Esempio 2: Interrogare un'API remota ogni 30 secondi
+
+```bash
+while true; do
+  curl -sf "https://api.example.com/status" || true
+  sleep 30
+done | grep --line-buffered -E "completed|failed|error"
+```
+
+`|| true` impedisce che un errore di rete transitorio termini il ciclo. Intervalli di polling di 30 secondi o più sono appropriati per le API remote per evitare i limiti di frequenza. Regolare il motivo grep per catturare sia le risposte di successo che quelle di errore in modo che gli errori lato API non siano mascherati dal silenzio.
+
+## Note
+
+- **Usare sempre `grep --line-buffered` nelle pipe.** Senza di esso, il buffering della pipe ritarda gli eventi di minuti perché il sistema operativo accumula l'output fino a riempire un blocco da 4 KB. `--line-buffered` forza un flush dopo ogni riga.
+- **Il filtro deve coprire sia le firme di successo che quelle di fallimento.** Un monitor che osserva solo il marcatore di successo rimane silenzioso in caso di crash, blocco o uscita inaspettata. Ampliare l'alternanza: includere `Error`, `Traceback`, `FAILED`, `Killed`, `OOM` e simili marcatori di stato terminale accanto alla parola chiave di successo.
+- **Intervalli di polling: 30 secondi o più per le API remote.** Il polling frequente di servizi esterni rischia errori di limite di frequenza o blocchi. Per le verifiche locali del filesystem o dei processi, 0,5–1 secondo è appropriato.
+- **Usare `persistent: true` per i monitor di durata della sessione.** Il `timeout_ms` predefinito di 300.000 ms (5 minuti) termina il processo. Per i monitor che devono essere eseguiti fino all'arresto esplicito, impostare `persistent: true` e chiamare `TaskStop` al termine.
+- **Arresto automatico in caso di flood di eventi.** Ogni riga dello stdout è un messaggio di conversazione. Se il filtro è troppo ampio e produce troppi eventi, il monitor viene fermato automaticamente. Riavviarlo con un motivo `grep` più stretto. Le righe che arrivano entro 200 ms vengono raggruppate in una singola notifica.

package/concepts/it/Tool-NotebookEdit.md

@@ -1,33 +1,39 @@
 # NotebookEdit
 
-## Definizione
+Modifica una singola cella in un notebook Jupyter (`.ipynb`). Supporta la sostituzione del sorgente di una cella, l'inserimento di una nuova cella o l'eliminazione di una cella esistente preservando il resto della struttura del notebook.
 
-Sostituisce, inserisce o elimina celle specifiche in un Jupyter notebook (file .ipynb).
+## Quando usare
+
+- Correggere o aggiornare una cella di codice in un notebook di analisi senza riscrivere l'intero file
+- Sostituire una cella markdown per migliorare la narrativa o aggiungere documentazione
+- Inserire una nuova cella di codice o markdown in una posizione nota in un notebook esistente
+- Rimuovere una cella obsoleta o rotta così che le celle a valle non dipendano più da essa
+- Preparare un notebook riproducibile iterando sulle celle una alla volta
 
 ## Parametri
 
-| Parametro | Tipo | Obbligatorio | Descrizione |
-|------|------|------|------|
-| `notebook_path` | string | Sì | Percorso assoluto del file notebook |
-| `new_source` | string | Sì | Nuovo contenuto della cella |
-| `cell_id` | string | No | ID della cella da modificare. In modalità inserimento, la nuova cella viene inserita dopo questo ID |
-| `cell_type` | enum | No | Tipo di cella: `code` o `markdown`. Obbligatorio in modalità inserimento |
-| `edit_mode` | enum | No | Modalità di modifica: `replace` (predefinita), `insert`, `delete` |
+- `notebook_path` (string, obbligatorio): Percorso assoluto al file `.ipynb`. I percorsi relativi sono rifiutati.
+- `new_source` (string, obbligatorio): Il nuovo sorgente della cella. Per `replace` e `insert` diventa il corpo della cella; per `delete` viene ignorato ma comunque richiesto dallo schema.
+- `cell_id` (string, opzionale): ID della cella target. Nelle modalità `replace` e `delete`, il tool agisce su questa cella. Nella modalità `insert`, la nuova cella viene inserita immediatamente dopo la cella con questo ID; ometti per inserire in cima al notebook.
+- `cell_type` (enum, opzionale): O `code` o `markdown`. Obbligatorio quando `edit_mode` è `insert`. Quando omesso durante `replace`, il tipo della cella esistente viene preservato.
+- `edit_mode` (enum, opzionale): `replace` (default), `insert` o `delete`.
 
-## Scenari d'uso
+## Esempi
 
-**Adatto per:**
-- Modificare celle di codice o markdown in un Jupyter notebook
-- Aggiungere nuove celle a un notebook
-- Eliminare celle da un notebook
+### Esempio 1: Sostituire una cella di codice buggata
+Chiama `NotebookEdit` con `notebook_path` impostato al percorso assoluto, `cell_id` impostato all'ID della cella target e `new_source` contenente il codice Python corretto. Lascia `edit_mode` al suo default `replace`.
 
-## Note
+### Esempio 2: Inserire una spiegazione markdown
+Per aggiungere una cella markdown subito dopo una cella `setup` esistente, imposta `edit_mode: "insert"`, `cell_type: "markdown"`, `cell_id` all'ID della cella setup e metti la narrativa in `new_source`.
 
-- `cell_number` è indicizzato a partire da 0
-- La modalità `insert` inserisce una nuova cella nella posizione specificata
-- La modalità `delete` elimina la cella nella posizione specificata
-- Il percorso deve essere assoluto
+### Esempio 3: Eliminare una cella obsoleta
+Imposta `edit_mode: "delete"` e fornisci il `cell_id` della cella da rimuovere. Fornisci qualsiasi stringa per `new_source`; non viene applicata.
 
-## Testo originale
+## Note
 
-<textarea readonly>Completely replaces the contents of a specific cell in a Jupyter notebook (.ipynb file) with new source. Jupyter notebooks are interactive documents that combine code, text, and visualizations, commonly used for data analysis and scientific computing. The notebook_path parameter must be an absolute path, not a relative path. The cell_number is 0-indexed. Use edit_mode=insert to add a new cell at the index specified by cell_number. Use edit_mode=delete to delete the cell at the index specified by cell_number.</textarea>
+- Passa sempre un percorso assoluto. `NotebookEdit` non risolve i percorsi relativi rispetto alla working directory.
+- Il tool riscrive solo la cella target; i conteggi di esecuzione, gli output e i metadati delle celle non correlate restano intatti.
+- Inserire senza un `cell_id` posiziona la nuova cella proprio all'inizio del notebook.
+- `cell_type` è obbligatorio per gli inserimenti. Per le sostituzioni, omettilo a meno che tu non voglia esplicitamente convertire una cella di codice in markdown o viceversa.
+- Per ispezionare le celle e ottenere i loro ID, usa prima il tool `Read` sul notebook; restituisce le celle con i loro contenuti e output.
+- Usa il normale `Edit` per file sorgente semplici; `NotebookEdit` è specifico per il JSON `.ipynb` e comprende la sua struttura di celle.

package/concepts/it/Tool-PushNotification.md

@@ -0,0 +1,48 @@
+# PushNotification
+
+Invia una notifica desktop dalla sessione corrente di Claude Code. Se Remote Control è connesso, invia la notifica anche al telefono dell'utente, richiamando la sua attenzione da qualunque attività stia svolgendo verso la sessione.
+
+## Quando usare
+
+- Un'attività di lunga durata è terminata mentre l'utente era probabilmente lontano dal terminale
+- Una compilazione, un'esecuzione di test o un deployment è completato e il risultato è pronto per la revisione
+- È stato raggiunto un punto decisionale che richiede l'intervento dell'utente prima di poter continuare
+- È emerso un errore o un blocco che non è possibile risolvere in modo autonomo
+- L'utente ha esplicitamente chiesto di essere notificato al completamento di un'attività o al verificarsi di una condizione specifica
+
+## Quando non usare
+
+Non inviare notifiche per aggiornamenti di avanzamento di routine durante un'attività, né per confermare di aver risposto a qualcosa che l'utente ha appena chiesto e sta chiaramente attendendo. Non notificare al termine di un'attività breve — se l'utente l'ha appena inviata e sta aspettando, la notifica non aggiunge valore e riduce la fiducia nelle notifiche future. Propendi fortemente per non inviare.
+
+## Parametri
+
+- `message` (stringa, obbligatorio): il corpo della notifica. Mantenerlo sotto i 200 caratteri; i sistemi operativi mobili troncano le stringhe più lunghe. Inizia con ciò su cui l'utente agirebbe: "build failed: 2 auth tests" è più utile di "task complete".
+- `status` (stringa, obbligatorio): impostare sempre su `"proactive"`. È un indicatore fisso e non cambia.
+
+## Esempi
+
+### Esempio 1: notifica al completamento di un'analisi lunga
+
+È stato richiesto un audit delle dipendenze su tutto il repository, che ha richiesto diversi minuti. L'utente si è allontanato. Quando il report è pronto:
+
+```
+message: "Audit dipendenze completato: 3 CVE critici in lodash, axios, jsonwebtoken. Report: audit-report.txt"
+status: "proactive"
+```
+
+### Esempio 2: segnalare un punto decisionale durante un lavoro autonomo
+
+Durante un refactoring in più fasi, si scopre che due moduli hanno interfacce in conflitto e non possono essere uniti senza una decisione progettuale:
+
+```
+message: "Refactoring sospeso: AuthService e UserService hanno interfacce token in conflitto. Serve una decisione per continuare."
+status: "proactive"
+```
+
+## Note
+
+- Propendi per **non** inviare. La notifica interrompe l'utente indipendentemente da ciò che sta facendo. Trattala come un costo che deve essere giustificato dal valore dell'informazione.
+- Inizia con contenuto su cui si possa agire. Le prime parole devono comunicare cosa è successo e cosa, se necessario, l'utente deve fare — non un'etichetta di stato generica.
+- Mantieni `message` sotto i 200 caratteri. I sistemi operativi mobili troncheranno le stringhe più lunghe, eliminando la parte più importante se appare alla fine.
+- Se il risultato indica che il push non è stato inviato perché Remote Control non è connesso, è il comportamento atteso. Non sono necessari nuovi tentativi o azioni aggiuntive; la notifica desktop locale viene comunque attivata.
+- Evita lo spam di notifiche. Se invii notifiche frequentemente per eventi minori, l'utente inizierà a ignorarle. Riserva questo strumento ai momenti in cui c'è una reale possibilità che l'utente si sia allontanato e voglia conoscere il risultato ora.

package/concepts/it/Tool-Read.md

@@ -1,56 +1,41 @@
 # Read
 
-## Definizione
+Carica il contenuto di un singolo file dal filesystem locale. Supporta testo semplice, codice sorgente, immagini, PDF e notebook Jupyter, restituendo i risultati con numeri di riga a base 1 in stile `cat -n`.
 
-Legge il contenuto di un file dal file system locale. Supporta file di testo, immagini, PDF e Jupyter notebook.
+## Quando usare
+
+- Leggere un file sorgente a un percorso noto prima di modificarlo o analizzarlo
+- Ispezionare file di configurazione, lockfile, log o artefatti generati
+- Visualizzare screenshot o diagrammi che l'utente ha incollato nella conversazione
+- Estrarre un intervallo di pagine specifico da un lungo manuale PDF
+- Aprire un notebook `.ipynb` per rivedere celle di codice, markdown e output delle celle insieme
 
 ## Parametri
 
-| Parametro | Tipo | Obbligatorio | Descrizione |
-|------|------|------|------|
-| `file_path` | string | Sì | Percorso assoluto del file |
-| `offset` | number | No | Numero di riga iniziale (per la lettura segmentata di file grandi) |
-| `limit` | number | No | Numero di righe da leggere (per la lettura segmentata di file grandi) |
-| `pages` | string | No | Intervallo di pagine PDF (es. "1-5", "3", "10-20"), applicabile solo ai PDF |
+- `file_path` (string, obbligatorio): Percorso assoluto al file target. I percorsi relativi sono rifiutati.
+- `offset` (integer, opzionale): Numero di riga a base 1 da cui iniziare la lettura. Utile per file grandi quando abbinato a `limit`.
+- `limit` (integer, opzionale): Numero massimo di righe da restituire a partire da `offset`. Default: 2000 righe dall'inizio del file quando omesso.
+- `pages` (string, opzionale): Intervallo di pagine per file PDF, ad esempio `"1-5"`, `"3"` o `"10-20"`. Obbligatorio per PDF più lunghi di 10 pagine; massimo 20 pagine per richiesta.
+
+## Esempi
+
+### Esempio 1: Leggere un piccolo file per intero
+Chiama `Read` con solo `file_path` impostato a `/Users/me/project/src/index.ts`. Vengono restituite fino a 2000 righe con numeri di riga, il che è di solito sufficiente per il contesto di editing.
 
-## Scenari d'uso
+### Esempio 2: Paginare attraverso un lungo log
+Usa `offset: 5001` e `limit: 500` su un file di log di molte migliaia di righe per recuperare una finestra stretta senza sprecare token di contesto.
 
-**Adatto per:**
-- Leggere file di codice, file di configurazione e altri file di testo
-- Visualizzare file immagine (Claude è un modello multimodale)
-- Leggere documenti PDF
-- Leggere Jupyter notebook (restituisce tutte le celle con i relativi output)
-- Leggere più file in parallelo per ottenere contesto
+### Esempio 3: Estrarre pagine PDF specifiche
+Per un PDF di 120 pagine in `/tmp/spec.pdf`, imposta `pages: "8-15"` per tirare fuori solo il capitolo di cui hai bisogno. Omettere `pages` su un PDF grande produce un errore.
 
-**Non adatto per:**
-- Leggere directory — usare il comando `ls` di Bash
-- Esplorazione aperta del codebase — usare Task (tipo Explore)
+### Esempio 4: Visualizzare un'immagine
+Passa il percorso assoluto di uno screenshot PNG o JPG. L'immagine viene resa visivamente così che Claude Code possa ragionarci sopra direttamente.
 
 ## Note
 
-- Il percorso deve essere assoluto, non relativo
-- Per impostazione predefinita legge le prime 2000 righe del file
-- Le righe che superano i 2000 caratteri vengono troncate
-- L'output usa il formato `cat -n`, con numeri di riga a partire da 1
-- Per PDF grandi (oltre 10 pagine) è necessario specificare il parametro `pages`, massimo 20 pagine per volta
-- La lettura di un file inesistente restituisce un errore (non causa un crash)
-- È possibile chiamare più Read in parallelo in un singolo messaggio
-
-## Testo originale
-
-<textarea readonly>Reads a file from the local filesystem. You can access any file directly by using this tool.
-Assume this tool is able to read all files on the machine. If the User provides a path to a file assume that path is valid. It is okay to read a file that does not exist; an error will be returned.
-
-Usage:
-- The file_path parameter must be an absolute path, not a relative path
-- By default, it reads up to 2000 lines starting from the beginning of the file
-- You can optionally specify a line offset and limit (especially handy for long files), but it's recommended to read the whole file by not providing these parameters
-- Any lines longer than 2000 characters will be truncated
-- Results are returned using cat -n format, with line numbers starting at 1
-- This tool allows Claude Code to read images (eg PNG, JPG, etc). When reading an image file the contents are presented visually as Claude Code is a multimodal LLM.
-- This tool can read PDF files (.pdf). For large PDFs (more than 10 pages), you MUST provide the pages parameter to read specific page ranges (e.g., pages: "1-5"). Reading a large PDF without the pages parameter will fail. Maximum 20 pages per request.
-- This tool can read Jupyter notebooks (.ipynb files) and returns all cells with their outputs, combining code, text, and visualizations.
-- This tool can only read files, not directories. To read a directory, use an ls command via the Bash tool.
-- You can call multiple tools in a single response. It is always better to speculatively read multiple potentially useful files in parallel.
-- You will regularly be asked to read screenshots. If the user provides a path to a screenshot, ALWAYS use this tool to view the file at the path. This tool will work with all temporary file paths.
-- If you read a file that exists but has empty contents you will receive a system reminder warning in place of file contents.</textarea>
+- Preferisci sempre percorsi assoluti. Se l'utente ne fornisce uno, fidatene così com'è.
+- Righe più lunghe di 2000 caratteri vengono troncate; tratta il contenuto restituito come possibilmente tagliato per dati estremamente larghi.
+- Leggi più file indipendenti? Emetti più chiamate `Read` nella stessa risposta così che vengano eseguite in parallelo.
+- `Read` non può elencare directory. Usa una chiamata `Bash` con `ls` o il tool `Glob` invece.
+- Leggere un file esistente ma vuoto restituisce un avviso di sistema piuttosto che i byte del file, quindi gestisci quel segnale esplicitamente.
+- Un `Read` riuscito è richiesto prima di poter usare `Edit` sullo stesso file nella sessione corrente.

package/concepts/it/Tool-RemoteTrigger.md

@@ -0,0 +1,73 @@
+# RemoteTrigger
+
+Chiama l'API dei trigger remoti di claude.ai per gestire l'esecuzione di attività pianificate e su richiesta. Il token OAuth viene gestito internamente dallo strumento e non viene mai esposto al modello o alla shell.
+
+## Quando usare
+
+- Gestire agenti remoti (trigger) su claude.ai, inclusa la visualizzazione, l'ispezione e l'aggiornamento dei trigger esistenti
+- Creare una nuova attività automatizzata basata su cron che esegua un agente Claude secondo una pianificazione ricorrente
+- Eseguire un trigger esistente su richiesta senza attendere la successiva esecuzione pianificata
+- Elencare o verificare tutti i trigger correnti per esaminarne la configurazione e lo stato
+- Aggiornare le impostazioni di un trigger, come la pianificazione, il payload o la descrizione, senza doverlo ricreare
+
+## Parametri
+
+- `action` (string, obbligatorio): l'operazione da eseguire — uno tra `list`, `get`, `create`, `update` o `run`
+- `trigger_id` (string, obbligatorio per `get`, `update` e `run`): l'identificatore del trigger su cui operare; deve corrispondere al pattern `^[\w-]+$` (solo caratteri di parola e trattini)
+- `body` (object, obbligatorio per `create` e `update`; facoltativo per `run`): il payload della richiesta inviata all'API
+
+## Esempi
+
+### Esempio 1: elencare tutti i trigger
+
+```json
+{
+  "action": "list"
+}
+```
+
+Chiama `GET /v1/code/triggers` e restituisce un array JSON di tutti i trigger associati all'account autenticato.
+
+### Esempio 2: creare un nuovo trigger che viene eseguito ogni mattina nei giorni feriali
+
+```json
+{
+  "action": "create",
+  "body": {
+    "name": "weekday-morning-report",
+    "schedule": "0 8 * * 1-5",
+    "description": "Generare un riepilogo giornaliero ogni giorno feriale alle 08:00 UTC"
+  }
+}
+```
+
+Chiama `POST /v1/code/triggers` con il corpo fornito e restituisce l'oggetto trigger appena creato, incluso il `trigger_id` assegnato.
+
+### Esempio 3: eseguire un trigger su richiesta
+
+```json
+{
+  "action": "run",
+  "trigger_id": "my-report-trigger"
+}
+```
+
+Chiama immediatamente `POST /v1/code/triggers/my-report-trigger/run`, ignorando l'orario pianificato.
+
+### Esempio 4: recuperare un singolo trigger
+
+```json
+{
+  "action": "get",
+  "trigger_id": "my-report-trigger"
+}
+```
+
+Chiama `GET /v1/code/triggers/my-report-trigger` e restituisce la configurazione completa del trigger.
+
+## Note
+
+- Il token OAuth viene iniettato nel processo dallo strumento — non copiare, incollare o registrare mai i token manualmente; farlo crea un rischio per la sicurezza ed è superfluo quando si utilizza questo strumento.
+- Preferire questo strumento a `curl` grezzo o ad altri client HTTP per tutte le chiamate all'API dei trigger; l'utilizzo diretto di HTTP aggira l'iniezione sicura del token e può esporre le credenziali.
+- Lo strumento restituisce la risposta JSON grezza dell'API; il chiamante è responsabile dell'analisi della risposta e della gestione dei codici di stato di errore.
+- Il valore di `trigger_id` deve corrispondere al pattern `^[\w-]+$` — sono ammessi solo caratteri alfanumerici, trattini bassi e trattini; spazi o caratteri speciali causeranno il fallimento della richiesta.

package/concepts/it/Tool-ScheduleWakeup.md

@@ -0,0 +1,56 @@
+# ScheduleWakeup
+
+Pianifica quando riprendere il lavoro in modalità dinamica `/loop`. Lo strumento consente a Claude di autogestire il ritmo delle iterazioni di un'attività, dormendo per l'intervallo scelto e poi attivandosi nuovamente con lo stesso prompt del loop.
+
+## Quando usare
+
+- Per autogestire il ritmo di un'attività dinamica `/loop` dove l'intervallo di iterazione dipende dallo stato del lavoro anziché da un orologio fisso
+- Per attendere il completamento di una lunga compilazione, distribuzione o esecuzione di test prima di controllare i risultati
+- Per inserire tick di inattività tra le iterazioni quando non c'è un segnale specifico da monitorare in questo momento
+- Per eseguire un loop autonomo senza prompt dell'utente — passare il sentinel letterale `<<autonomous-loop-dynamic>>` come `prompt`
+- Per interrogare un processo il cui stato sta per cambiare (usare un breve ritardo per mantenere la cache calda)
+
+## Parametri
+
+- `delaySeconds` (numero, obbligatorio): Secondi fino alla ripresa. Il runtime limita automaticamente il valore a `[60, 3600]`, quindi non è necessario limitarlo manualmente.
+- `reason` (stringa, obbligatoria): Una breve frase che spiega il ritardo scelto. Mostrata all'utente e registrata nella telemetria. Essere specifici — "controllo della lunga compilazione bun" è più utile di "in attesa."
+- `prompt` (stringa, obbligatoria): L'input `/loop` da attivare al risveglio. Passare la stessa stringa ad ogni turno in modo che il prossimo trigger ripeta l'attività. Per un loop autonomo senza prompt dell'utente, passare il sentinel letterale `<<autonomous-loop-dynamic>>`.
+
+## Esempi
+
+### Esempio 1: breve ritardo per ricontrollare un segnale che cambia rapidamente (mantenere la cache calda)
+
+Una compilazione è appena stata avviata e di solito termina in due o tre minuti.
+
+```json
+{
+  "delaySeconds": 120,
+  "reason": "controllo compilazione bun prevista in ~2 min",
+  "prompt": "controllare lo stato della compilazione e segnalare eventuali errori"
+}
+```
+
+120 secondi mantiene il contesto della conversazione nella cache dei prompt Anthropic (TTL 5 min), quindi il prossimo risveglio è più veloce ed economico.
+
+### Esempio 2: lungo tick di inattività (accettare il cache miss, ammortizzare su un'attesa più lunga)
+
+Una migrazione del database è in esecuzione e di solito richiede 20–40 minuti.
+
+```json
+{
+  "delaySeconds": 1200,
+  "reason": "la migrazione richiede solitamente 20–40 min; ricontrollo in 20 min",
+  "prompt": "controllare lo stato della migrazione e continuare se completata"
+}
+```
+
+La cache sarà fredda al risveglio, ma l'attesa di 20 minuti ammortizza ampiamente il costo del singolo cache miss. Interrogare ogni 5 minuti pagherebbe lo stesso costo di miss 4 volte senza alcun beneficio.
+
+## Note
+
+- **TTL della cache di 5 minuti**: La cache dei prompt Anthropic scade dopo 300 secondi. I ritardi inferiori a 300 s mantengono il contesto caldo; i ritardi superiori a 300 s comportano un cache miss al prossimo risveglio.
+- **Evitare esattamente 300 s**: È il peggio di entrambi i mondi — si paga il cache miss senza ottenere un'attesa significativamente più lunga. Ridurre a 270 s (mantenere la cache calda) o impegnarsi con 1200 s o più (un miss acquista un'attesa molto più lunga).
+- **Valore predefinito per i tick di inattività**: Quando non c'è un segnale specifico da monitorare, usare **1200–1800 s** (20–30 min). Questo consente al loop di controllare periodicamente senza bruciare la cache 12 volte all'ora inutilmente.
+- **Limitazione automatica**: Il runtime limita `delaySeconds` a `[60, 3600]`. I valori inferiori a 60 diventano 60; i valori superiori a 3600 diventano 3600. Non è necessario gestire questi limiti manualmente.
+- **Omettere la chiamata per terminare il loop**: Se si intende interrompere le iterazioni, non chiamare ScheduleWakeup. Semplicemente omettere la chiamata termina il loop.
+- **Passare lo stesso `prompt` ad ogni turno**: Il campo `prompt` deve contenere l'istruzione `/loop` originale ad ogni invocazione affinché il prossimo risveglio sappia quale attività riprendere.

package/concepts/it/Tool-SendMessage.md

@@ -1,41 +1,68 @@
 # SendMessage
 
-## Definizione
+Consegna un messaggio da un membro del team a un altro all'interno di un team attivo, o trasmette a ogni teammate contemporaneamente. È l'unico canale che i teammate possono ascoltare — qualsiasi cosa scritta nell'output di testo normale è invisibile a loro.
 
-Invia messaggi tra agent all'interno di un team. Utilizzato per la comunicazione diretta, il broadcast e i messaggi di protocollo (richieste/risposte di arresto, approvazione piani).
+## Quando usare
+
+- Assegnare un compito o passare un sottoproblema a un teammate nominato durante la collaborazione di team.
+- Richiedere stato, risultati intermedi o una code review da un altro agente.
+- Trasmettere una decisione, un vincolo condiviso o un annuncio di spegnimento all'intero team via `*`.
+- Rispondere a un prompt di protocollo come una richiesta di shutdown o una richiesta di approvazione del piano dal team leader.
+- Chiudere il cerchio alla fine di un compito delegato così che il leader possa marcare l'elemento come completato.
 
 ## Parametri
 
-| Parametro | Tipo | Obbligatorio | Descrizione |
-|-----------|------|--------------|-------------|
-| `to` | string | Sì | Destinatario: nome del membro, o `"*"` per broadcast a tutti |
-| `message` | string / object | Sì | Messaggio di testo o oggetto di protocollo strutturato |
-| `summary` | string | No | Anteprima di 5-10 parole mostrata nell'interfaccia |
+- `to` (string, obbligatorio): Il `name` del teammate target come registrato nel team, oppure `*` per trasmettere a tutti i teammate contemporaneamente.
+- `message` (string o object, obbligatorio): Testo semplice per comunicazioni normali, o un oggetto strutturato per risposte di protocollo come `shutdown_response` e `plan_approval_response`.
+- `summary` (string, opzionale): Un'anteprima di 5–10 parole mostrata nel log di attività del team per i messaggi in testo semplice. Obbligatorio per messaggi di stringa lunghi; ignorato quando `message` è un oggetto di protocollo.
+
+## Esempi
+
+### Esempio 1: Passaggio diretto di un compito
+
+```
+SendMessage(
+  to="db-lead",
+  message="Please audit prisma/schema.prisma and list any model missing createdAt/updatedAt timestamps. Reply when done.",
+  summary="Audit schema for missing timestamps"
+)
+```
 
-## Tipi di messaggio
+### Esempio 2: Trasmettere un vincolo condiviso
 
-### Testo semplice
-Messaggi diretti tra membri del team per coordinamento, aggiornamenti di stato e discussioni sui task.
+```
+SendMessage(
+  to="*",
+  message="Reminder: do not touch files under legacy/ — that subtree is frozen until the migration PR lands.",
+  summary="Freeze legacy/ during migration"
+)
+```
 
-### Richiesta di arresto
-Chiede a un membro di arrestarsi in modo ordinato: `{ type: "shutdown_request", reason: "..." }`
+### Esempio 3: Risposta di protocollo
 
-### Risposta di arresto
-Il membro approva o rifiuta l'arresto: `{ type: "shutdown_response", approve: true/false }`
+Rispondi a una richiesta di shutdown dal leader usando un messaggio strutturato:
 
-### Risposta di approvazione piano
-Approva o rifiuta il piano di un membro: `{ type: "plan_approval_response", approve: true/false }`
+```
+SendMessage(
+  to="leader",
+  message={ "type": "shutdown_response", "ready": true, "final_report": "All assigned diff chunks committed on branch refactor-crew/db-lead." }
+)
+```
 
-## Broadcast vs. Diretto
+### Esempio 4: Risposta di approvazione del piano
 
-- **Diretto** (`to: "nome-membro"`): Invia a un membro specifico — preferito per la maggior parte delle comunicazioni
-- **Broadcast** (`to: "*"`): Invia a tutti i membri — da usare con parsimonia, solo per annunci critici a livello di team
+```
+SendMessage(
+  to="leader",
+  message={ "type": "plan_approval_response", "approved": true, "notes": "LGTM, but please split step 4 into migration + backfill." }
+)
+```
 
-## Strumenti correlati
+## Note
 
-| Strumento | Scopo |
-|-----------|-------|
-| `TeamCreate` | Creare un nuovo team |
-| `TeamDelete` | Rimuovere il team al completamento |
-| `Agent` | Avviare membri che si uniscono al team |
-| `TaskCreate` / `TaskUpdate` / `TaskList` | Gestire la lista dei task condivisa |
+- Il tuo normale output di testo dell'assistente NON viene trasmesso ai teammate. Se vuoi che un altro agente veda qualcosa, deve passare attraverso `SendMessage`. È l'errore più comune nei workflow di team.
+- La trasmissione (`to: "*"`) è costosa — sveglia ogni teammate e consuma il loro contesto. Riservala ad annunci che genuinamente riguardano tutti. Preferisci invii mirati.
+- Mantieni i messaggi concisi e orientati all'azione. Includi i percorsi dei file, i vincoli e il formato di risposta atteso di cui il destinatario ha bisogno; ricorda che non hanno memoria condivisa con te.
+- Gli oggetti messaggio di protocollo (`shutdown_response`, `plan_approval_response`) hanno forme fisse. Non mescolare campi di protocollo in messaggi di testo semplice o viceversa.
+- I messaggi sono asincroni. Il destinatario riceverà il tuo al suo prossimo turno; non assumere che l'abbiano letto o abbiano agito su di esso finché non rispondono.
+- Un `summary` ben scritto rende il log di attività del team scorrevole per il leader — trattalo come una riga oggetto di commit.