cc-viewer 1.7.22 → 1.7.23

package/concepts/de/Tool-getDiagnostics.md

@@ -1,44 +0,0 @@
-# getDiagnostics
-
-Ruft Language-Server-Diagnosen (Fehler, Warnungen, Hinweise) aus der verbundenen IDE für eine bestimmte Datei oder für jede Datei ab, die die IDE derzeit geöffnet hat. Wird verwendet, um zu verifizieren, dass Code-Änderungen sauber kompilieren, bevor eine Aufgabe für erledigt erklärt wird.
-
-## Wann verwenden
-
-- Nach einem `Edit` oder `Write`, um zu bestätigen, dass die Änderung keinen Typfehler, Syntaxfehler oder keine Lint-Warnung eingeführt hat.
-- Vor dem Beenden einer Aufgabe, um jede offene Datei nach ungelösten Problemen zu durchsuchen.
-- Beim Diagnostizieren eines vom Benutzer gemeldeten Fehlers – das Ziehen der exakten Compiler- oder Type-Checker-Meldung aus der IDE vermeidet Rätselraten.
-- Als leichtgewichtige Alternative zur Ausführung eines vollständigen Builds oder Testbefehls, wenn Sie nur die statische Korrektheit prüfen müssen.
-
-Verlassen Sie sich NICHT auf `getDiagnostics` als Ersatz für die Test-Suite. Es meldet, was der Language-Server sieht, nicht was zur Test- oder Produktionszeit läuft.
-
-## Parameter
-
-- `uri` (string, optional): Die Datei-URI (typischerweise `file:///absolute/path`), für die Diagnosen abgerufen werden sollen. Wenn weggelassen, gibt das Tool Diagnosen für jede derzeit in der IDE geöffnete Datei zurück.
-
-## Beispiele
-
-### Beispiel 1: Eine einzelne Datei nach dem Bearbeiten prüfen
-
-```
-getDiagnostics(
-  uri="file:///Users/sky/project/src/auth.ts"
-)
-```
-
-Gibt alle TypeScript-Fehler, ESLint-Warnungen oder andere Language-Server-Meldungen für `src/auth.ts` zurück.
-
-### Beispiel 2: Alle geöffneten Dateien durchkämmen
-
-```
-getDiagnostics()
-```
-
-Gibt Diagnosen über jeden derzeit geöffneten Editor zurück. Nützlich am Ende eines dateiübergreifenden Refactorings, um sicherzustellen, dass anderswo nichts regrediert ist.
-
-## Hinweise
-
-- `getDiagnostics` ist ein IDE-Brücken-Tool. Es ist nur verfügbar, wenn Claude Code mit einer unterstützenden IDE-Integration verbunden ist (zum Beispiel der VS-Code-Erweiterung). In einer reinen Terminal-Sitzung erscheint das Tool nicht.
-- Die Ergebnisse spiegeln wider, welche Language-Server die IDE geladen hat – TypeScript, Pyright, ESLint, rust-analyzer usw. Qualität und Abdeckung hängen vom IDE-Setup des Benutzers ab, nicht von Claude Code.
-- Diagnosen sind live. Geben Sie dem Language-Server nach einem Edit einen Moment zur Neu-Analyse, bevor Sie ein leeres Ergebnis als Erfolg interpretieren – wiederholen Sie, falls die Datei gerade gespeichert wurde.
-- Schweregrade umfassen typischerweise `error`, `warning`, `information` und `hint`. Fokussieren Sie sich zuerst auf `error`; Warnungen können absichtlicher Projektstil sein.
-- Für Dateien, die derzeit nicht in der IDE geöffnet sind, hat der Language-Server möglicherweise keine Diagnosen zu melden, selbst wenn die Datei echte Probleme enthält. Öffnen Sie die Datei oder führen Sie den Build aus, um autoritative Abdeckung zu erhalten.

package/concepts/en/Tool-TeamCreate.md

@@ -1,53 +0,0 @@
-# TeamCreate
-
-Establishes a new collaboration team with a shared task list and inter-agent messaging channel. A team is the coordination primitive for multi-agent work — the main session acts as leader and spawns named teammates via the `Agent` tool.
-
-## When to Use
-
-- The user explicitly requests a team, swarm, crew, or multi-agent collaboration.
-- A project has several clearly independent workstreams that benefit from dedicated specialists (e.g. frontend, backend, tests, docs).
-- You need a persistent shared task list that multiple agents update as they make progress.
-- You want named, addressable teammates that can exchange messages via `SendMessage` rather than one-shot subagent calls.
-
-Do NOT use for a single delegated search or a one-off parallel fan-out — plain `Agent` calls are lighter and sufficient.
-
-## Parameters
-
-- `team_name` (string, required): Unique identifier for the team. Used as the directory name under `~/.claude/teams/` and as the `team_name` argument when spawning teammates.
-- `description` (string, required): Short statement of the team's objective. Shown to every teammate on spawn and written into the team config.
-- `agent_type` (string, optional): Default subagent persona applied to teammates that do not override it. Typical values are `general-purpose`, `Explore`, or `Plan`.
-
-## Examples
-
-### Example 1: Create a refactor team
-
-```
-TeamCreate(
-  team_name="refactor-crew",
-  description="Refactor the data access layer from raw SQL to Prisma, including migrations and tests.",
-  agent_type="general-purpose"
-)
-```
-
-After creation, spawn teammates with `Agent` using `team_name: "refactor-crew"` and distinct `name` values such as `db-lead`, `migrations`, and `tests`.
-
-### Example 2: Create an investigation team
-
-```
-TeamCreate(
-  team_name="perf-investigation",
-  description="Identify and rank the top three performance regressions introduced in the last release.",
-  agent_type="Explore"
-)
-```
-
-Each spawned teammate inherits `Explore` as its default persona, matching the read-only investigative nature of the work.
-
-## Notes
-
-- Only one team can be led at a time from a given session. Finish or delete the current team before creating another.
-- A team is 1:1 with a shared task list. The leader owns task creation, assignment, and closure; teammates update the status of tasks they are working on.
-- Team configuration is persisted at `~/.claude/teams/{team_name}/config.json`, and the task directory lives alongside it. These files survive across sessions until explicitly removed with `TeamDelete`.
-- Teammates are spawned using the `Agent` tool with matching `team_name` plus a distinct `name`. The `name` becomes the address used by `SendMessage`.
-- Pick a `team_name` that is filesystem-safe (letters, digits, dashes, underscores). Avoid spaces or slashes.
-- Write the `description` so that a brand-new teammate, reading it cold, would understand the team's goal without further context. It becomes part of every teammate's startup prompt.

package/concepts/en/Tool-TeamDelete.md

@@ -1,44 +0,0 @@
-# TeamDelete
-
-Tears down the currently active team, removing its configuration directory and shared task directory. This is the cleanup counterpart to `TeamCreate` and is typically called after the team's objective has been achieved and all teammates have shut down.
-
-## When to Use
-
-- The team has completed its work and the final report has been delivered to the user.
-- The team was created in error or its scope has changed so drastically that starting fresh is cleaner than continuing.
-- You need to create a new team but one is already active — delete the old one first, since only one team can be led at a time.
-- A team has become stale across sessions and its persisted state under `~/.claude/teams/` is no longer needed.
-
-Do NOT call while teammates are still running — shut them down first via `SendMessage` with a `shutdown_request`, wait for every `shutdown_response`, then delete.
-
-## Parameters
-
-`TeamDelete` takes no parameters in its typical invocation. It operates on the currently active team owned by the calling session.
-
-## Examples
-
-### Example 1: Routine shutdown after success
-
-1. Broadcast a shutdown request to the team:
-   ```
-   SendMessage(to="*", message={ "type": "shutdown_request" })
-   ```
-2. Wait for each teammate to reply with a `shutdown_response`.
-3. Call `TeamDelete()` to remove the team directory and task directory.
-
-### Example 2: Replacing a misconfigured team
-
-If `TeamCreate` was called with the wrong `agent_type` or `description`, first ensure no teammates have been spawned yet (or shut them down), then:
-
-```
-TeamDelete()
-TeamCreate(team_name="...", description="...", agent_type="...")
-```
-
-## Notes
-
-- `TeamDelete` fails if any teammate is still active. The error response lists the live teammates — send each one a `shutdown_request` via `SendMessage`, await their `shutdown_response`, and retry.
-- Deletion is irreversible from the tool's perspective. The team's config at `~/.claude/teams/{team_name}/config.json` and its task directory are removed from disk. If you need the task list preserved, export or copy the directory before deleting.
-- Only the leader session that created the team can delete it. A spawned teammate cannot call `TeamDelete` on its own team.
-- Deleting the team does not roll back any filesystem changes that teammates made in the repository. Those are ordinary git-tracked edits and must be reverted separately if unwanted.
-- After `TeamDelete` returns successfully, the session is free to call `TeamCreate` again for a new team.

package/concepts/en/Tool-executeCode.md

@@ -1,47 +0,0 @@
-# executeCode
-
-Executes a snippet of code inside a live kernel or sandbox supplied by an IDE integration (for example the Jupyter kernel bound to the currently open notebook). The tool is only present when Claude Code is running alongside a compatible IDE bridge such as the VS Code extension with a Jupyter kernel selected.
-
-## When to Use
-
-- Running a quick computation, data inspection, or plot against the state already loaded in an active Jupyter kernel.
-- Validating a snippet of code before pasting it into a notebook cell.
-- Exploring an in-memory dataframe, variable, or model that exists in the kernel but is not serialized to disk.
-- Producing a chart or numeric result that the user wants rendered inline in the IDE.
-
-Do NOT use for standalone scripts that would be better served by `Bash` running `python script.py`, or for code that needs to persist across a fresh kernel.
-
-## Parameters
-
-- `code` (string, required): The code to execute in the current kernel. Runs as if pasted into a notebook cell — variables defined persist in the kernel until it is restarted.
-- `language` (string, optional): The language of the snippet when the IDE bridge supports multiple kernels. Most commonly omitted; defaults to the language of the active kernel (typically Python).
-
-## Examples
-
-### Example 1: Inspect an in-memory dataframe
-
-```
-executeCode(
-  code="df.head()\nprint(df.shape)\nprint(df.dtypes)"
-)
-```
-
-Returns the first rows, shape, and column dtypes of a dataframe already loaded in the kernel.
-
-### Example 2: Quick numeric check
-
-```
-executeCode(
-  code="import numpy as np\nnp.mean([1, 2, 3, 4, 5])"
-)
-```
-
-Runs a one-off calculation without creating a notebook cell.
-
-## Notes
-
-- `executeCode` is an IDE-bridge tool. It is unavailable in plain terminal sessions of Claude Code; it only appears when the session is connected to an IDE that exposes a kernel (for example the VS Code Jupyter extension).
-- State persists in the kernel. Variables defined by one `executeCode` call remain visible to later calls, to notebook cells, and to the user — be mindful of side effects.
-- Long-running or blocking code will block the kernel. Keep snippets short; for multi-minute work, write an actual script and run it via `Bash`.
-- Output (stdout, return values, images) is returned to the session. Very large outputs may be truncated by the IDE bridge.
-- For file edits, prefer `Edit`, `Write`, or `NotebookEdit` — `executeCode` is not a substitute for authoring source files.

package/concepts/en/Tool-getDiagnostics.md

@@ -1,44 +0,0 @@
-# getDiagnostics
-
-Retrieves language-server diagnostics (errors, warnings, hints) from the connected IDE for a specific file or for every file the IDE currently has open. Used to verify that code changes compile cleanly before declaring a task done.
-
-## When to Use
-
-- After an `Edit` or `Write` to confirm the change did not introduce a type error, syntax error, or lint warning.
-- Before ending a task to sweep every open file for unresolved problems.
-- When diagnosing an error the user reports — pulling the exact compiler or type-checker message from the IDE avoids guessing.
-- As a lightweight alternative to running a full build or test command when you only need to check static correctness.
-
-Do NOT rely on `getDiagnostics` as a replacement for the test suite. It reports what the language server sees, not what runs at test or production time.
-
-## Parameters
-
-- `uri` (string, optional): The file URI (typically `file:///absolute/path`) to fetch diagnostics for. When omitted, the tool returns diagnostics for every file the IDE currently has open.
-
-## Examples
-
-### Example 1: Check a single file after editing
-
-```
-getDiagnostics(
-  uri="file:///Users/sky/project/src/auth.ts"
-)
-```
-
-Returns any TypeScript errors, ESLint warnings, or other language-server messages for `src/auth.ts`.
-
-### Example 2: Sweep all open files
-
-```
-getDiagnostics()
-```
-
-Returns diagnostics across every currently open editor. Useful at the end of a multi-file refactor to ensure nothing regressed elsewhere.
-
-## Notes
-
-- `getDiagnostics` is an IDE-bridge tool. It is only available when Claude Code is connected to a supporting IDE integration (for example the VS Code extension). In a plain terminal session the tool will not appear.
-- The results reflect whatever language servers the IDE has loaded — TypeScript, Pyright, ESLint, rust-analyzer, etc. Quality and coverage depend on the user's IDE setup, not on Claude Code.
-- Diagnostics are live. After an edit, give the language server a moment to re-analyze before interpreting an empty result as success — re-run if the file was just saved.
-- Severity levels typically include `error`, `warning`, `information`, and `hint`. Focus on `error` first; warnings may be intentional project style.
-- For files not currently open in the IDE, the language server may have no diagnostics to report even if the file contains real issues. Open the file or run the build for authoritative coverage.

package/concepts/es/Tool-TeamCreate.md

@@ -1,53 +0,0 @@
-# TeamCreate
-
-Establece un nuevo equipo de colaboración con una lista de tareas compartida y un canal de mensajería entre agentes. Un equipo es la primitiva de coordinación para trabajo multiagente — la sesión principal actúa como líder y genera compañeros con nombre mediante la herramienta `Agent`.
-
-## Cuándo usar
-
-- El usuario solicita explícitamente un equipo, enjambre, tripulación o colaboración multiagente.
-- Un proyecto tiene varios flujos de trabajo claramente independientes que se benefician de especialistas dedicados (p. ej. frontend, backend, pruebas, documentación).
-- Necesitas una lista de tareas compartida persistente que varios agentes actualicen a medida que avanzan.
-- Quieres compañeros con nombre y direccionables que puedan intercambiar mensajes vía `SendMessage` en lugar de llamadas de subagente de una sola vez.
-
-NO uses esto para una sola búsqueda delegada o una dispersión paralela puntual — las llamadas simples `Agent` son más ligeras y suficientes.
-
-## Parámetros
-
-- `team_name` (string, obligatorio): Identificador único para el equipo. Se usa como nombre de directorio bajo `~/.claude/teams/` y como el argumento `team_name` al generar compañeros.
-- `description` (string, obligatorio): Declaración corta del objetivo del equipo. Se muestra a cada compañero al generarse y se escribe en la configuración del equipo.
-- `agent_type` (string, opcional): Persona de subagente por defecto aplicada a compañeros que no la sobrescriban. Valores típicos son `general-purpose`, `Explore` o `Plan`.
-
-## Ejemplos
-
-### Ejemplo 1: Crear un equipo de refactor
-
-```
-TeamCreate(
-  team_name="refactor-crew",
-  description="Refactor the data access layer from raw SQL to Prisma, including migrations and tests.",
-  agent_type="general-purpose"
-)
-```
-
-Tras la creación, genera compañeros con `Agent` usando `team_name: "refactor-crew"` y valores `name` distintos como `db-lead`, `migrations` y `tests`.
-
-### Ejemplo 2: Crear un equipo de investigación
-
-```
-TeamCreate(
-  team_name="perf-investigation",
-  description="Identify and rank the top three performance regressions introduced in the last release.",
-  agent_type="Explore"
-)
-```
-
-Cada compañero generado hereda `Explore` como su persona por defecto, lo que coincide con la naturaleza investigativa de solo lectura del trabajo.
-
-## Notas
-
-- Solo se puede liderar un equipo a la vez desde una sesión dada. Termina o elimina el equipo actual antes de crear otro.
-- Un equipo es 1:1 con una lista de tareas compartida. El líder posee la creación, asignación y cierre de tareas; los compañeros actualizan el estado de las tareas en las que están trabajando.
-- La configuración del equipo se persiste en `~/.claude/teams/{team_name}/config.json`, y el directorio de tareas vive junto a ella. Estos archivos sobreviven entre sesiones hasta que se eliminen explícitamente con `TeamDelete`.
-- Los compañeros se generan usando la herramienta `Agent` con un `team_name` coincidente más un `name` distinto. El `name` se convierte en la dirección usada por `SendMessage`.
-- Elige un `team_name` que sea seguro para el sistema de archivos (letras, dígitos, guiones, guiones bajos). Evita espacios o barras.
-- Escribe la `description` de modo que un compañero nuevo, leyéndola en frío, pueda entender el objetivo del equipo sin más contexto. Se convierte en parte del prompt de arranque de cada compañero.

package/concepts/es/Tool-TeamDelete.md

@@ -1,44 +0,0 @@
-# TeamDelete
-
-Desmantela el equipo activo actual, eliminando su directorio de configuración y el directorio de tareas compartidas. Es la contraparte de limpieza de `TeamCreate` y típicamente se llama después de que el objetivo del equipo se haya logrado y todos los compañeros se hayan apagado.
-
-## Cuándo usar
-
-- El equipo ha completado su trabajo y el informe final ha sido entregado al usuario.
-- El equipo se creó por error o su ámbito ha cambiado tan drásticamente que empezar de cero es más limpio que continuar.
-- Necesitas crear un nuevo equipo pero ya hay uno activo — elimina el viejo primero, ya que solo se puede liderar un equipo a la vez.
-- Un equipo se ha vuelto obsoleto a lo largo de sesiones y su estado persistido bajo `~/.claude/teams/` ya no es necesario.
-
-NO llames mientras los compañeros sigan en ejecución — apágalos primero vía `SendMessage` con un `shutdown_request`, espera cada `shutdown_response` y luego elimina.
-
-## Parámetros
-
-`TeamDelete` no recibe parámetros en su invocación típica. Opera sobre el equipo activo actual propiedad de la sesión que llama.
-
-## Ejemplos
-
-### Ejemplo 1: Apagado rutinario tras el éxito
-
-1. Haz broadcast de una solicitud de apagado al equipo:
-   ```
-   SendMessage(to="*", message={ "type": "shutdown_request" })
-   ```
-2. Espera a que cada compañero responda con un `shutdown_response`.
-3. Llama a `TeamDelete()` para eliminar el directorio del equipo y el directorio de tareas.
-
-### Ejemplo 2: Reemplazar un equipo mal configurado
-
-Si `TeamCreate` fue llamado con el `agent_type` o `description` equivocado, primero asegúrate de que no se hayan generado compañeros aún (o apágalos), luego:
-
-```
-TeamDelete()
-TeamCreate(team_name="...", description="...", agent_type="...")
-```
-
-## Notas
-
-- `TeamDelete` falla si algún compañero sigue activo. La respuesta de error lista los compañeros vivos — envía a cada uno un `shutdown_request` vía `SendMessage`, espera su `shutdown_response` y reintenta.
-- La eliminación es irreversible desde la perspectiva de la herramienta. La configuración del equipo en `~/.claude/teams/{team_name}/config.json` y su directorio de tareas se eliminan del disco. Si necesitas preservar la lista de tareas, exporta o copia el directorio antes de eliminar.
-- Solo la sesión líder que creó el equipo puede eliminarlo. Un compañero generado no puede llamar a `TeamDelete` sobre su propio equipo.
-- Eliminar el equipo no revierte los cambios del sistema de archivos que los compañeros hicieron en el repositorio. Esos son ediciones ordinarias rastreadas por git y deben revertirse por separado si no se desean.
-- Tras el retorno exitoso de `TeamDelete`, la sesión es libre de llamar a `TeamCreate` nuevamente para un nuevo equipo.

package/concepts/es/Tool-executeCode.md

@@ -1,47 +0,0 @@
-# executeCode
-
-Ejecuta un fragmento de código dentro de un kernel o sandbox en vivo proporcionado por una integración de IDE (por ejemplo el kernel de Jupyter vinculado al notebook abierto actualmente). La herramienta solo está presente cuando Claude Code se ejecuta junto con un puente de IDE compatible como la extensión de VS Code con un kernel de Jupyter seleccionado.
-
-## Cuándo usar
-
-- Ejecutar un cálculo rápido, inspección de datos o gráfico contra el estado ya cargado en un kernel activo de Jupyter.
-- Validar un fragmento de código antes de pegarlo en una celda de notebook.
-- Explorar un dataframe, variable o modelo en memoria que existe en el kernel pero no está serializado a disco.
-- Producir un gráfico o resultado numérico que el usuario quiere renderizado en línea en el IDE.
-
-NO uses esto para scripts independientes que se atenderían mejor con `Bash` ejecutando `python script.py`, o para código que necesita persistir entre un kernel fresco.
-
-## Parámetros
-
-- `code` (string, obligatorio): El código a ejecutar en el kernel actual. Se ejecuta como si se pegara en una celda de notebook — las variables definidas persisten en el kernel hasta que se reinicie.
-- `language` (string, opcional): El lenguaje del fragmento cuando el puente del IDE soporta múltiples kernels. Lo más común es omitirlo; por defecto es el lenguaje del kernel activo (típicamente Python).
-
-## Ejemplos
-
-### Ejemplo 1: Inspeccionar un dataframe en memoria
-
-```
-executeCode(
-  code="df.head()\nprint(df.shape)\nprint(df.dtypes)"
-)
-```
-
-Devuelve las primeras filas, la forma y los dtypes de columna de un dataframe ya cargado en el kernel.
-
-### Ejemplo 2: Comprobación numérica rápida
-
-```
-executeCode(
-  code="import numpy as np\nnp.mean([1, 2, 3, 4, 5])"
-)
-```
-
-Ejecuta un cálculo puntual sin crear una celda de notebook.
-
-## Notas
-
-- `executeCode` es una herramienta de puente de IDE. No está disponible en sesiones de terminal plano de Claude Code; solo aparece cuando la sesión está conectada a un IDE que expone un kernel (por ejemplo la extensión Jupyter de VS Code).
-- El estado persiste en el kernel. Las variables definidas por una llamada `executeCode` permanecen visibles para llamadas posteriores, para celdas de notebook y para el usuario — ten en cuenta los efectos secundarios.
-- El código de larga duración o bloqueante bloqueará el kernel. Mantén los fragmentos cortos; para trabajo de varios minutos, escribe un script real y ejecútalo vía `Bash`.
-- La salida (stdout, valores de retorno, imágenes) se devuelve a la sesión. Las salidas muy grandes pueden ser truncadas por el puente del IDE.
-- Para ediciones de archivos, prefiere `Edit`, `Write` o `NotebookEdit` — `executeCode` no sustituye a la autoría de archivos fuente.

package/concepts/es/Tool-getDiagnostics.md

@@ -1,44 +0,0 @@
-# getDiagnostics
-
-Recupera diagnósticos del servidor de lenguaje (errores, advertencias, pistas) desde el IDE conectado para un archivo específico o para todos los archivos que el IDE tiene abiertos actualmente. Se usa para verificar que los cambios de código compilan limpiamente antes de declarar una tarea terminada.
-
-## Cuándo usar
-
-- Tras un `Edit` o `Write` para confirmar que el cambio no introdujo un error de tipo, error de sintaxis o advertencia de lint.
-- Antes de finalizar una tarea para barrer cada archivo abierto en busca de problemas sin resolver.
-- Al diagnosticar un error que reporta el usuario — extraer el mensaje exacto del compilador o verificador de tipos desde el IDE evita adivinar.
-- Como alternativa ligera a ejecutar un build o suite de pruebas completos cuando solo necesitas comprobar la corrección estática.
-
-NO dependas de `getDiagnostics` como reemplazo de la suite de pruebas. Reporta lo que el servidor de lenguaje ve, no lo que se ejecuta en tiempo de prueba o producción.
-
-## Parámetros
-
-- `uri` (string, opcional): La URI del archivo (típicamente `file:///absolute/path`) para la que obtener diagnósticos. Cuando se omite, la herramienta devuelve diagnósticos para cada archivo que el IDE tiene abierto actualmente.
-
-## Ejemplos
-
-### Ejemplo 1: Comprobar un solo archivo tras editar
-
-```
-getDiagnostics(
-  uri="file:///Users/sky/project/src/auth.ts"
-)
-```
-
-Devuelve cualquier error de TypeScript, advertencia de ESLint u otros mensajes del servidor de lenguaje para `src/auth.ts`.
-
-### Ejemplo 2: Barrer todos los archivos abiertos
-
-```
-getDiagnostics()
-```
-
-Devuelve diagnósticos de cada editor abierto actualmente. Útil al final de un refactor de varios archivos para asegurar que nada ha regresionado en otro lugar.
-
-## Notas
-
-- `getDiagnostics` es una herramienta de puente de IDE. Solo está disponible cuando Claude Code está conectado a una integración de IDE compatible (por ejemplo la extensión de VS Code). En una sesión de terminal plano la herramienta no aparecerá.
-- Los resultados reflejan los servidores de lenguaje que el IDE haya cargado — TypeScript, Pyright, ESLint, rust-analyzer, etc. La calidad y cobertura dependen de la configuración del IDE del usuario, no de Claude Code.
-- Los diagnósticos son en vivo. Tras una edición, da al servidor de lenguaje un momento para re-analizar antes de interpretar un resultado vacío como éxito — vuelve a ejecutar si el archivo se acaba de guardar.
-- Los niveles de severidad típicamente incluyen `error`, `warning`, `information` y `hint`. Enfócate primero en `error`; las advertencias pueden ser estilo intencional del proyecto.
-- Para archivos que no están abiertos actualmente en el IDE, el servidor de lenguaje puede no tener diagnósticos que reportar incluso si el archivo contiene problemas reales. Abre el archivo o ejecuta el build para una cobertura autoritativa.

package/concepts/fr/Tool-TeamCreate.md

@@ -1,53 +0,0 @@
-# TeamCreate
-
-Établit une nouvelle équipe de collaboration avec une liste de tâches partagée et un canal de messagerie inter-agents. Une équipe est la primitive de coordination pour le travail multi-agents — la session principale fait office de chef et fait apparaître des coéquipiers nommés via l'outil `Agent`.
-
-## Quand l'utiliser
-
-- L'utilisateur demande explicitement une équipe, un essaim, un équipage ou une collaboration multi-agents.
-- Un projet comporte plusieurs flux de travail clairement indépendants qui bénéficient de spécialistes dédiés (par exemple frontend, backend, tests, docs).
-- Vous avez besoin d'une liste de tâches partagée persistante que plusieurs agents mettent à jour à mesure qu'ils progressent.
-- Vous voulez des coéquipiers nommés et adressables capables d'échanger des messages via `SendMessage` plutôt que des appels de sous-agent à usage unique.
-
-N'utilisez PAS pour une unique recherche déléguée ou un fan-out parallèle ponctuel — de simples appels `Agent` sont plus légers et suffisants.
-
-## Paramètres
-
-- `team_name` (string, requis) : identifiant unique pour l'équipe. Utilisé comme nom de répertoire sous `~/.claude/teams/` et comme argument `team_name` lors du lancement de coéquipiers.
-- `description` (string, requis) : courte déclaration de l'objectif de l'équipe. Affichée à chaque coéquipier au lancement et écrite dans la configuration de l'équipe.
-- `agent_type` (string, optionnel) : persona de sous-agent par défaut appliquée aux coéquipiers qui ne la remplacent pas. Les valeurs typiques sont `general-purpose`, `Explore` ou `Plan`.
-
-## Exemples
-
-### Exemple 1 : créer une équipe de refactoring
-
-```
-TeamCreate(
-  team_name="refactor-crew",
-  description="Refactor the data access layer from raw SQL to Prisma, including migrations and tests.",
-  agent_type="general-purpose"
-)
-```
-
-Après la création, faites apparaître des coéquipiers avec `Agent` en utilisant `team_name: "refactor-crew"` et des valeurs `name` distinctes telles que `db-lead`, `migrations` et `tests`.
-
-### Exemple 2 : créer une équipe d'investigation
-
-```
-TeamCreate(
-  team_name="perf-investigation",
-  description="Identify and rank the top three performance regressions introduced in the last release.",
-  agent_type="Explore"
-)
-```
-
-Chaque coéquipier généré hérite de `Explore` comme persona par défaut, ce qui correspond à la nature en lecture seule et investigative du travail.
-
-## Notes
-
-- Une seule équipe peut être dirigée à la fois depuis une session donnée. Terminez ou supprimez l'équipe courante avant d'en créer une autre.
-- Une équipe est en relation 1:1 avec une liste de tâches partagée. Le chef possède la création, l'affectation et la clôture des tâches ; les coéquipiers mettent à jour le statut des tâches sur lesquelles ils travaillent.
-- La configuration de l'équipe est persistée à `~/.claude/teams/{team_name}/config.json`, et le répertoire de tâches se trouve à côté. Ces fichiers survivent aux sessions jusqu'à leur suppression explicite avec `TeamDelete`.
-- Les coéquipiers sont générés via l'outil `Agent` avec le `team_name` correspondant et un `name` distinct. Le `name` devient l'adresse utilisée par `SendMessage`.
-- Choisissez un `team_name` compatible avec le système de fichiers (lettres, chiffres, tirets, underscores). Évitez les espaces ou les slashes.
-- Rédigez la `description` de manière qu'un tout nouveau coéquipier, la lisant à froid, comprenne l'objectif de l'équipe sans contexte supplémentaire. Elle fait partie de l'invite de démarrage de chaque coéquipier.

package/concepts/fr/Tool-TeamDelete.md

@@ -1,44 +0,0 @@
-# TeamDelete
-
-Démantèle l'équipe actuellement active, en supprimant son répertoire de configuration et son répertoire de tâches partagé. C'est le pendant de nettoyage de `TeamCreate` et il est typiquement appelé après que l'objectif de l'équipe a été atteint et que tous les coéquipiers ont été arrêtés.
-
-## Quand l'utiliser
-
-- L'équipe a terminé son travail et le rapport final a été remis à l'utilisateur.
-- L'équipe a été créée par erreur ou son périmètre a tellement changé qu'il est plus propre de repartir de zéro que de continuer.
-- Vous devez créer une nouvelle équipe mais une est déjà active — supprimez d'abord l'ancienne, puisqu'une seule équipe peut être dirigée à la fois.
-- Une équipe est devenue obsolète au fil des sessions et son état persisté sous `~/.claude/teams/` n'est plus nécessaire.
-
-N'appelez PAS pendant que des coéquipiers sont encore en cours d'exécution — arrêtez-les d'abord via `SendMessage` avec un `shutdown_request`, attendez chaque `shutdown_response`, puis supprimez.
-
-## Paramètres
-
-`TeamDelete` ne prend aucun paramètre dans son invocation typique. Il opère sur l'équipe actuellement active détenue par la session appelante.
-
-## Exemples
-
-### Exemple 1 : arrêt de routine après succès
-
-1. Diffuser une demande d'arrêt à l'équipe :
-   ```
-   SendMessage(to="*", message={ "type": "shutdown_request" })
-   ```
-2. Attendre que chaque coéquipier réponde avec un `shutdown_response`.
-3. Appeler `TeamDelete()` pour supprimer le répertoire d'équipe et le répertoire de tâches.
-
-### Exemple 2 : remplacer une équipe mal configurée
-
-Si `TeamCreate` a été appelé avec le mauvais `agent_type` ou `description`, assurez-vous d'abord qu'aucun coéquipier n'a été lancé (ou arrêtez-les), puis :
-
-```
-TeamDelete()
-TeamCreate(team_name="...", description="...", agent_type="...")
-```
-
-## Notes
-
-- `TeamDelete` échoue si un coéquipier est encore actif. La réponse d'erreur liste les coéquipiers en vie — envoyez à chacun un `shutdown_request` via `SendMessage`, attendez leur `shutdown_response` et réessayez.
-- La suppression est irréversible du point de vue de l'outil. La configuration de l'équipe à `~/.claude/teams/{team_name}/config.json` et son répertoire de tâches sont supprimés du disque. Si vous avez besoin de préserver la liste de tâches, exportez ou copiez le répertoire avant de supprimer.
-- Seule la session chef qui a créé l'équipe peut la supprimer. Un coéquipier généré ne peut pas appeler `TeamDelete` sur sa propre équipe.
-- Supprimer l'équipe ne rétablit pas les modifications du système de fichiers que les coéquipiers ont apportées dans le dépôt. Ce sont des modifications suivies par git ordinaires et doivent être annulées séparément si indésirables.
-- Après le retour réussi de `TeamDelete`, la session est libre d'appeler `TeamCreate` à nouveau pour une nouvelle équipe.

package/concepts/fr/Tool-executeCode.md

@@ -1,47 +0,0 @@
-# executeCode
-
-Exécute un extrait de code dans un noyau ou un sandbox en direct fourni par une intégration IDE (par exemple le noyau Jupyter lié au notebook actuellement ouvert). L'outil n'est présent que lorsque Claude Code fonctionne aux côtés d'un pont IDE compatible tel que l'extension VS Code avec un noyau Jupyter sélectionné.
-
-## Quand l'utiliser
-
-- Exécuter un calcul rapide, une inspection de données ou un tracé sur l'état déjà chargé dans un noyau Jupyter actif.
-- Valider un extrait de code avant de le coller dans une cellule de notebook.
-- Explorer un dataframe, une variable ou un modèle en mémoire qui existe dans le noyau mais n'est pas sérialisé sur disque.
-- Produire un graphique ou un résultat numérique que l'utilisateur veut voir rendu inline dans l'IDE.
-
-N'utilisez PAS pour des scripts autonomes qui seraient mieux servis par `Bash` exécutant `python script.py`, ou pour du code qui doit persister à travers un noyau neuf.
-
-## Paramètres
-
-- `code` (string, requis) : le code à exécuter dans le noyau courant. S'exécute comme s'il était collé dans une cellule de notebook — les variables définies persistent dans le noyau jusqu'à son redémarrage.
-- `language` (string, optionnel) : le langage de l'extrait lorsque le pont IDE prend en charge plusieurs noyaux. Le plus souvent omis ; par défaut le langage du noyau actif (généralement Python).
-
-## Exemples
-
-### Exemple 1 : inspecter un dataframe en mémoire
-
-```
-executeCode(
-  code="df.head()\nprint(df.shape)\nprint(df.dtypes)"
-)
-```
-
-Renvoie les premières lignes, la forme et les dtypes de colonnes d'un dataframe déjà chargé dans le noyau.
-
-### Exemple 2 : vérification numérique rapide
-
-```
-executeCode(
-  code="import numpy as np\nnp.mean([1, 2, 3, 4, 5])"
-)
-```
-
-Effectue un calcul ponctuel sans créer de cellule de notebook.
-
-## Notes
-
-- `executeCode` est un outil de pont IDE. Il est indisponible dans les sessions de terminal classiques de Claude Code ; il n'apparaît que lorsque la session est connectée à un IDE qui expose un noyau (par exemple l'extension Jupyter de VS Code).
-- L'état persiste dans le noyau. Les variables définies par un appel `executeCode` restent visibles pour les appels ultérieurs, les cellules de notebook et l'utilisateur — attention aux effets de bord.
-- Le code de longue durée ou bloquant bloquera le noyau. Gardez les extraits courts ; pour un travail de plusieurs minutes, écrivez un véritable script et exécutez-le via `Bash`.
-- La sortie (sortie standard, valeurs de retour, images) est renvoyée à la session. Les très grandes sorties peuvent être tronquées par le pont IDE.
-- Pour les modifications de fichiers, préférez `Edit`, `Write` ou `NotebookEdit` — `executeCode` n'est pas un substitut à la création de fichiers source.

package/concepts/fr/Tool-getDiagnostics.md

@@ -1,44 +0,0 @@
-# getDiagnostics
-
-Récupère les diagnostics (erreurs, avertissements, indices) du serveur de langage depuis l'IDE connecté pour un fichier spécifique ou pour tous les fichiers que l'IDE a actuellement ouverts. Utilisé pour vérifier que les modifications de code compilent proprement avant de déclarer une tâche terminée.
-
-## Quand l'utiliser
-
-- Après un `Edit` ou un `Write` pour confirmer que le changement n'a pas introduit d'erreur de type, d'erreur de syntaxe ou d'avertissement de lint.
-- Avant de terminer une tâche pour balayer chaque fichier ouvert à la recherche de problèmes non résolus.
-- Lors du diagnostic d'une erreur signalée par l'utilisateur — récupérer le message exact du compilateur ou du vérificateur de types de l'IDE évite de deviner.
-- Comme alternative légère à l'exécution d'un build complet ou d'une commande de test lorsque vous n'avez besoin que de vérifier la correction statique.
-
-Ne comptez PAS sur `getDiagnostics` comme remplacement de la suite de tests. Il rapporte ce que le serveur de langage voit, pas ce qui s'exécute en test ou en production.
-
-## Paramètres
-
-- `uri` (string, optionnel) : l'URI du fichier (typiquement `file:///absolute/path`) dont récupérer les diagnostics. Lorsqu'omis, l'outil renvoie les diagnostics pour chaque fichier que l'IDE a actuellement ouvert.
-
-## Exemples
-
-### Exemple 1 : vérifier un seul fichier après édition
-
-```
-getDiagnostics(
-  uri="file:///Users/sky/project/src/auth.ts"
-)
-```
-
-Renvoie toute erreur TypeScript, avertissement ESLint ou autre message de serveur de langage pour `src/auth.ts`.
-
-### Exemple 2 : balayer tous les fichiers ouverts
-
-```
-getDiagnostics()
-```
-
-Renvoie les diagnostics sur chaque éditeur actuellement ouvert. Utile à la fin d'un refactoring multi-fichiers pour s'assurer que rien n'a régressé ailleurs.
-
-## Notes
-
-- `getDiagnostics` est un outil de pont IDE. Il n'est disponible que lorsque Claude Code est connecté à une intégration IDE compatible (par exemple l'extension VS Code). Dans une session de terminal classique, l'outil n'apparaîtra pas.
-- Les résultats reflètent les serveurs de langage que l'IDE a chargés — TypeScript, Pyright, ESLint, rust-analyzer, etc. La qualité et la couverture dépendent de la configuration de l'IDE de l'utilisateur, pas de Claude Code.
-- Les diagnostics sont en direct. Après une modification, laissez au serveur de langage un moment pour réanalyser avant d'interpréter un résultat vide comme un succès — relancez si le fichier vient d'être enregistré.
-- Les niveaux de sévérité incluent typiquement `error`, `warning`, `information` et `hint`. Concentrez-vous d'abord sur `error` ; les avertissements peuvent être du style de projet intentionnel.
-- Pour les fichiers non ouverts dans l'IDE, le serveur de langage peut n'avoir aucun diagnostic à rapporter même si le fichier contient de vrais problèmes. Ouvrez le fichier ou exécutez le build pour une couverture faisant autorité.