cc-viewer 1.6.182 → 1.6.183

package/concepts/es/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+Lista todos los trabajos cron programados mediante `CronCreate` en la sesión actual. Devuelve un resumen de cada cron activo que incluye `id`, expresión cron, `prompt` abreviado, indicador `recurring`, indicador `durable` y la próxima hora de ejecución.
+
+## Cuándo usar
+
+- Para auditar todos los trabajos actualmente programados antes de realizar cambios o finalizar una sesión.
+- Para encontrar el `id` correcto de un trabajo antes de llamar a `CronDelete` y eliminarlo.
+- Para depurar por qué un trabajo esperado nunca se ejecutó, confirmando su existencia y revisando su próxima hora de ejecución.
+- Para confirmar que un trabajo de una sola ejecución (no recurrente) aún no se ha disparado y sigue pendiente.
+
+## Parámetros
+
+Ninguno.
+
+## Ejemplos
+
+### Ejemplo 1: auditar todos los trabajos programados
+
+Invocar `CronList` sin argumentos para obtener la lista completa de todos los trabajos cron activos. La respuesta incluye el `id` de cada trabajo, la expresión cron que define su horario, una versión truncada del `prompt` que ejecutará, si es `recurring` (recurrente), si es `durable` (persistente entre reinicios) y la próxima hora en que está programado para ejecutarse.
+
+### Ejemplo 2: localizar el id de una tarea recurrente específica
+
+Si se crearon varios trabajos cron y es necesario eliminar uno en particular, invocar primero `CronList`. Examinar la lista devuelta en busca del trabajo cuyo resumen de `prompt` y expresión cron coincidan con la tarea que se desea eliminar. Copiar su `id` y pasarlo a `CronDelete`.
+
+## Notas
+
+- Solo se listan los trabajos creados en la sesión actual, a menos que hayan sido creados con `durable: true`, lo que les permite persistir tras reinicios de sesión.
+- El campo `prompt` en el resumen está truncado; muestra solo el comienzo del texto completo del prompt, no el contenido íntegro.
+- Los trabajos de una sola ejecución (`recurring` es `false`) que ya se han disparado son eliminados automáticamente y ya no aparecen en la lista.

package/concepts/es/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## Definición
+Realiza una sustitución exacta de cadenas dentro de un archivo existente. Es la forma preferida de modificar archivos porque solo se transmite el diff, manteniendo las ediciones precisas y auditables.
 
-Edita archivos mediante reemplazo exacto de cadenas. Reemplaza `old_string` por `new_string` en el archivo.
+## Cuándo usar
 
-## Parámetros
+- Corregir un bug en una sola función sin reescribir el archivo circundante
+- Actualizar un valor de configuración, una cadena de versión o una ruta de importación
+- Renombrar un símbolo en todo un archivo con `replace_all`
+- Insertar un bloque cerca de un ancla (amplía `old_string` para incluir contexto cercano, luego proporciona el reemplazo)
+- Aplicar ediciones pequeñas y bien acotadas como parte de un refactor en varios pasos
 
-| Parámetro | Tipo | Requerido | Descripción |
-|-----------|------|-----------|-------------|
-| `file_path` | string | Sí | Ruta absoluta del archivo a modificar |
-| `old_string` | string | Sí | Texto original a reemplazar |
-| `new_string` | string | Sí | Nuevo texto de reemplazo (debe ser diferente de old_string) |
-| `replace_all` | boolean | No | Si se reemplazan todas las coincidencias, por defecto `false` |
+## Parámetros
 
-## Casos de uso
+- `file_path` (string, obligatorio): Ruta absoluta del archivo a modificar.
+- `old_string` (string, obligatorio): El texto exacto a buscar. Debe coincidir carácter por carácter, incluyendo espacios en blanco e indentación.
+- `new_string` (string, obligatorio): El texto de reemplazo. Debe diferir de `old_string`.
+- `replace_all` (boolean, opcional): Cuando es `true`, reemplaza cada aparición de `old_string`. Por defecto es `false`, lo que requiere que la coincidencia sea única.
 
-**Adecuado para:**
-- Modificar segmentos específicos de código en archivos existentes
-- Corregir bugs, actualizar lógica
-- Renombrar variables (con `replace_all: true`)
-- Cualquier escenario que requiera modificación precisa del contenido de un archivo
+## Ejemplos
 
-**No adecuado para:**
-- Crear archivos nuevos — usar Write
-- Reescrituras a gran escala — puede requerir Write para sobrescribir el archivo completo
+### Ejemplo 1: Corregir un solo sitio de llamada
+Establece `old_string` a la línea exacta `const port = 3000;` y `new_string` a `const port = process.env.PORT ?? 3000;`. La coincidencia es única, por lo que `replace_all` puede quedarse con su valor por defecto.
 
-## Notas
+### Ejemplo 2: Renombrar un símbolo en todo un archivo
+Para renombrar `getUser` a `fetchUser` en todas partes de `api.ts`, establece `old_string: "getUser"`, `new_string: "fetchUser"` y `replace_all: true`.
 
-- Se debe haber leído el archivo previamente con Read antes de usar, de lo contrario dará error
-- `old_string` debe ser único en el archivo, de lo contrario la edición falla. Si no es único, proporcionar más contexto para hacerlo único, o usar `replace_all`
-- Al editar texto se debe mantener la indentación original (tab/espacios), no incluir el prefijo de número de línea de la salida de Read
-- Preferir editar archivos existentes en lugar de crear nuevos
-- `new_string` debe ser diferente de `old_string`
+### Ejemplo 3: Desambiguar un fragmento repetido
+Si `return null;` aparece en varias ramas, amplía `old_string` para incluir contexto circundante (por ejemplo la línea `if` precedente) de modo que la coincidencia sea única. De lo contrario, la herramienta da error en vez de adivinar.
 
-## Texto original
-
-<textarea readonly>Performs exact string replacements in files.
+## Notas
 
-Usage:
-- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. 
-- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
-- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
-- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
-- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`.
-- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.</textarea>
+- Debes llamar a `Read` sobre el archivo al menos una vez en la sesión actual antes de que `Edit` acepte cambios. Los prefijos de número de línea de la salida de `Read` no forman parte del contenido del archivo; no los incluyas en `old_string` ni en `new_string`.
+- Los espacios en blanco deben coincidir exactamente. Presta atención a tabs versus espacios y a los espacios al final de línea, especialmente en YAML, Makefiles y Python.
+- Si `old_string` no es único y `replace_all` es `false`, la edición falla. Amplía el contexto o habilita `replace_all`.
+- Prefiere `Edit` sobre `Write` siempre que el archivo ya exista; `Write` sobrescribe todo el archivo y pierde contenido no relacionado si no tienes cuidado.
+- Para varias ediciones no relacionadas en el mismo archivo, realiza varias llamadas `Edit` en secuencia en lugar de un reemplazo único grande y frágil.
+- Evita introducir emojis, texto de marketing o bloques de documentación no solicitados al editar archivos de código fuente.

package/concepts/es/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## Definición
+Cambia la sesión al modo plan, una fase de exploración de solo lectura en la que el asistente investiga el código y redacta un plan de implementación concreto para que el usuario lo apruebe antes de modificar archivo alguno.
 
-Cambia Claude Code al modo de planificación, utilizado para explorar la base de código y diseñar un plan antes de la implementación.
+## Cuándo usar
+
+- El usuario solicita un cambio no trivial que abarca varios archivos o subsistemas.
+- Los requisitos son ambiguos y el asistente necesita leer código antes de comprometerse con un enfoque.
+- Se propone un refactor, migración o actualización de dependencia y el radio de impacto no está claro.
+- El usuario dice explícitamente "planea esto", "primero hagamos un plan", o solicita una revisión de diseño.
+- El riesgo es lo suficientemente alto como para que pasar directamente a editar pueda desperdiciar trabajo o dañar el estado.
 
 ## Parámetros
 
-Sin parámetros.
+Ninguno. `EnterPlanMode` no recibe argumentos — invócalo con un objeto de parámetros vacío.
 
-## Casos de uso
+## Ejemplos
 
-**Adecuado para:**
-- Implementación de nuevas funcionalidades — requiere decisiones de arquitectura
-- Existen múltiples enfoques viables — requiere que el usuario elija
-- Las modificaciones de código afectan el comportamiento o la estructura existente
-- Cambios en múltiples archivos — posiblemente involucra 2-3 o más archivos
-- Requisitos poco claros — necesita explorar primero para entender el alcance
-- Las preferencias del usuario son importantes — la implementación puede tener múltiples direcciones razonables
+### Ejemplo 1: Solicitud de funcionalidad grande
 
-**No adecuado para:**
-- Correcciones de una línea o pocas líneas (errores tipográficos, bugs obvios)
-- El usuario ya dio instrucciones muy específicas
-- Tareas puramente de investigación/exploración — usar Task (tipo Explore)
+El usuario pregunta: "Añade SSO mediante Okta al panel de administración." El asistente llama a `EnterPlanMode`, luego pasa varios turnos leyendo el middleware de autenticación, el almacenamiento de sesiones, los guardas de rutas y la interfaz de inicio de sesión existente. Escribe un plan que describe los cambios necesarios, los pasos de migración y la cobertura de pruebas, y lo envía mediante `ExitPlanMode` para su aprobación.
 
-## Comportamiento en modo de planificación
+### Ejemplo 2: Refactor arriesgado
 
-Después de entrar en modo de planificación, Claude Code:
-1. Usa las herramientas Glob, Grep, Read para explorar la base de código en profundidad
-2. Comprende los patrones y la arquitectura existentes
-3. Diseña un plan de implementación
-4. Envía el plan al usuario para aprobación
-5. Puede usar AskUserQuestion si necesita aclaraciones
-6. Sale mediante ExitPlanMode cuando el plan está listo
+El usuario dice: "Convierte los controladores REST a tRPC." El asistente entra en modo plan, examina cada controlador, cataloga el contrato público, enumera las fases de despliegue (shim, lectura dual, cutover) y propone un plan de secuenciación antes de tocar ningún archivo.
 
 ## Notas
 
-- Esta herramienta requiere el consentimiento del usuario para entrar en modo de planificación
-- Si no está seguro de si se necesita planificación, es preferible planificar — alinear de antemano es mejor que rehacer
-
-## Texto original
-
-<textarea readonly>Use this tool proactively when you're about to start a non-trivial implementation task. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval.
-
-## When to Use This Tool
-
-**Prefer using EnterPlanMode** for implementation tasks unless they're simple. Use it when ANY of these conditions apply:
-
-1. **New Feature Implementation**: Adding meaningful new functionality
-   - Example: "Add a logout button" - where should it go? What should happen on click?
-   - Example: "Add form validation" - what rules? What error messages?
-
-2. **Multiple Valid Approaches**: The task can be solved in several different ways
-   - Example: "Add caching to the API" - could use Redis, in-memory, file-based, etc.
-   - Example: "Improve performance" - many optimization strategies possible
-
-3. **Code Modifications**: Changes that affect existing behavior or structure
-   - Example: "Update the login flow" - what exactly should change?
-   - Example: "Refactor this component" - what's the target architecture?
-
-4. **Architectural Decisions**: The task requires choosing between patterns or technologies
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-   - Example: "Implement state management" - Redux vs Context vs custom solution
-
-5. **Multi-File Changes**: The task will likely touch more than 2-3 files
-   - Example: "Refactor the authentication system"
-   - Example: "Add a new API endpoint with tests"
-
-6. **Unclear Requirements**: You need to explore before understanding the full scope
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Fix the bug in checkout" - need to investigate root cause
-
-7. **User Preferences Matter**: The implementation could reasonably go multiple ways
-   - If you would use AskUserQuestion to clarify the approach, use EnterPlanMode instead
-   - Plan mode lets you explore first, then present options with context
-
-## When NOT to Use This Tool
-
-Only skip EnterPlanMode for simple tasks:
-- Single-line or few-line fixes (typos, obvious bugs, small tweaks)
-- Adding a single function with clear requirements
-- Tasks where the user has given very specific, detailed instructions
-- Pure research/exploration tasks (use the Agent tool with explore agent instead)
-
-## What Happens in Plan Mode
-
-In plan mode, you'll:
-1. Thoroughly explore the codebase using Glob, Grep, and Read tools
-2. Understand existing patterns and architecture
-3. Design an implementation approach
-4. Present your plan to the user for approval
-5. Use AskUserQuestion if you need to clarify approaches
-6. Exit plan mode with ExitPlanMode when ready to implement
-
-## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Requires architectural decisions (session vs JWT, where to store tokens, middleware structure)
-
-User: "Optimize the database queries"
-- Multiple approaches possible, need to profile first, significant impact
-
-User: "Implement dark mode"
-- Architectural decision on theme system, affects many components
-
-User: "Add a delete button to the user profile"
-- Seems simple but involves: where to place it, confirmation dialog, API call, error handling, state updates
-
-User: "Update the error handling in the API"
-- Affects multiple files, user should approve the approach
-
-### BAD - Don't use EnterPlanMode:
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-User: "Add a console.log to debug this function"
-- Simple, obvious implementation
-
-User: "What files handle routing?"
-- Research task, not implementation planning
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
-- If unsure whether to use it, err on the side of planning - it's better to get alignment upfront than to redo work
-- Users appreciate being consulted before significant changes are made to their codebase
-</textarea>
+- El modo plan es de solo lectura por contrato. Estando dentro, el asistente no debe ejecutar `Edit`, `Write`, `NotebookEdit`, ni ningún comando de shell que mute estado. Usa únicamente `Read`, `Grep`, `Glob` y comandos `Bash` no destructivos.
+- No entres en modo plan para ediciones triviales de una línea, preguntas de investigación pura o tareas donde el usuario ya haya especificado el cambio con todo detalle. La sobrecarga perjudica más que ayuda.
+- Bajo el modo Auto, se desaconseja el modo plan salvo que el usuario lo solicite explícitamente — el modo Auto prefiere la acción sobre la planificación previa.
+- Usa el modo plan para reducir correcciones de rumbo en trabajo costoso. Un plan de cinco minutos suele ahorrar una hora de ediciones mal orientadas.
+- Una vez en modo plan, enfoca la investigación en las partes del sistema que realmente van a cambiar. Evita recorridos exhaustivos del repositorio sin relación con la tarea en curso.
+- El plan en sí debe escribirse en disco en la ruta que el harness espera para que `ExitPlanMode` pueda enviarlo. El plan debe contener rutas de archivos concretas, nombres de funciones y pasos de verificación, no intenciones vagas.
+- El usuario puede rechazar el plan y pedir revisiones. Itera dentro del modo plan hasta que el plan sea aceptado; solo entonces sal.

package/concepts/es/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## Definición
+Crea un worktree de Git aislado sobre una nueva rama, o cambia la sesión a un worktree existente del repositorio actual, de modo que el trabajo paralelo o experimental pueda avanzar sin tocar el checkout principal.
 
-Creates an isolated git worktree and switches the current session into it. Only used when the user explicitly asks to work in a worktree.
+## Cuándo usar
 
-## Parámetros
-
-| Name | Type | Required | Description |
-|---|---|---|---|
-| name | string | No | A name for the worktree. If not provided, a random name is generated. |
-
-## Casos de uso
+- El usuario dice explícitamente "worktree" — por ejemplo "inicia un worktree", "crea un worktree" o "trabaja en un worktree".
+- Las instrucciones del proyecto en `CLAUDE.md` o la memoria persistente te indican usar un worktree para la tarea actual.
+- Quieres continuar una tarea que previamente fue preparada como worktree (pasa `path` para volver a entrar).
+- Varias ramas experimentales deben coexistir en disco sin cambios constantes de checkout.
+- Una tarea de larga duración debe aislarse de ediciones no relacionadas en el árbol de trabajo principal.
 
-**Adecuado para:**
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree")
-
-**No adecuado para:**
-- The user asks to create/switch branches — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-
-## Notas
-
-- Must be in a git repository, or have WorktreeCreate/WorktreeRemove hooks configured
-- Must not already be in a worktree
-
-## Texto original
-
-<textarea readonly>Use this tool ONLY when the user explicitly asks to work in a worktree. This tool creates an isolated git worktree and switches the current session into it.
+## Parámetros
 
-## When to Use
+- `name` (string, opcional): Un nombre para el directorio del nuevo worktree. Cada segmento separado por `/` solo puede contener letras, dígitos, puntos, guiones bajos y guiones; la cadena completa está limitada a 64 caracteres. Si se omite y `path` también se omite, se genera un nombre aleatorio. Mutuamente excluyente con `path`.
+- `path` (string, opcional): La ruta del sistema de archivos de un worktree existente del repositorio actual al que cambiar. Debe aparecer en `git worktree list` para este repo; las rutas que no sean worktrees registrados del repositorio actual son rechazadas. Mutuamente excluyente con `name`.
 
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree", "use a worktree")
+## Ejemplos
 
-## When NOT to Use
+### Ejemplo 1: Crear un nuevo worktree con un nombre descriptivo
 
-- The user asks to create a branch, switch branches, or work on a different branch — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-- Never use this tool unless the user explicitly mentions "worktree"
+```
+EnterWorktree(name="feat/okta-sso")
+```
 
-## Requirements
+Crea `.claude/worktrees/feat/okta-sso` en una nueva rama basada en `HEAD`, y luego cambia el directorio de trabajo de la sesión a ese worktree. Todas las ediciones de archivos y comandos de shell posteriores operan dentro de ese worktree hasta que salgas.
 
-- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json
-- Must not already be in a worktree
+### Ejemplo 2: Volver a entrar en un worktree existente
 
-## Behavior
+```
+EnterWorktree(path="/Users/me/repo/.claude/worktrees/feat/okta-sso")
+```
 
-- In a git repository: creates a new git worktree inside `.claude/worktrees/` with a new branch based on HEAD
-- Outside a git repository: delegates to WorktreeCreate/WorktreeRemove hooks for VCS-agnostic isolation
-- Switches the session's working directory to the new worktree
-- On session exit, the user will be prompted to keep or remove the worktree
+Reanuda el trabajo en un worktree creado previamente. Como entraste mediante `path`, `ExitWorktree` no lo eliminará automáticamente — salir con `action: "keep"` simplemente retorna al directorio original.
 
-## Parameters
+## Notas
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- No llames a `EnterWorktree` salvo que el usuario lo haya pedido explícitamente o las instrucciones del proyecto lo requieran. Las solicitudes ordinarias de cambio de rama o corrección de bugs deben usar comandos normales de Git, no worktrees.
+- Cuando se invoca dentro de un repositorio Git, la herramienta crea un worktree bajo `.claude/worktrees/` y registra una nueva rama basada en `HEAD`. Fuera de un repositorio Git, delega en los hooks `WorktreeCreate` / `WorktreeRemove` configurados en `settings.json` para aislamiento agnóstico del VCS.
+- Solo una sesión de worktree está activa a la vez. La herramienta se niega a ejecutarse si ya estás dentro de una sesión de worktree; primero sal con `ExitWorktree`.
+- Usa `ExitWorktree` para salir a mitad de sesión. Si la sesión termina estando aún dentro de un worktree recién creado, se le pregunta al usuario si desea conservarlo o eliminarlo.
+- Los worktrees ingresados mediante `path` se consideran externos — `ExitWorktree` con `action: "remove"` no los eliminará. Esta es una barrera de seguridad para proteger worktrees que el usuario gestiona manualmente.
+- Un worktree nuevo hereda el contenido de la rama actual pero tiene un directorio de trabajo e índice independientes. Los cambios con y sin staging del checkout principal no son visibles dentro del worktree.
+- Consejo de nombrado: antepón el tipo de trabajo (`feat/`, `fix/`, `spike/`) para que varios worktrees concurrentes sean fáciles de distinguir en `git worktree list`.

package/concepts/es/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## Definición
+Envía el plan de implementación que se redactó durante el modo plan para su aprobación por el usuario y — si es aprobado — transiciona la sesión fuera del modo plan para que puedan comenzar las ediciones.
 
-Sale del modo de planificación y envía el plan al usuario para su aprobación. El contenido del plan se lee del archivo de plan escrito previamente.
+## Cuándo usar
 
-## Parámetros
-
-| Parámetro | Tipo | Requerido | Descripción |
-|-----------|------|-----------|-------------|
-| `allowedPrompts` | array | No | Lista de descripciones de permisos necesarios para implementar el plan |
-
-Cada elemento del array `allowedPrompts`:
-
-| Campo | Tipo | Requerido | Descripción |
-|-------|------|-----------|-------------|
-| `tool` | enum | Sí | Herramienta aplicable, actualmente solo soporta `Bash` |
-| `prompt` | string | Sí | Descripción semántica de la operación (como "run tests", "install dependencies") |
-
-## Casos de uso
+- Un plan escrito durante `EnterPlanMode` está completo y listo para revisión.
+- La tarea está orientada a implementación (cambios de código o configuración), no investigación pura, por lo que un plan explícito es apropiado.
+- Toda la lectura y el análisis previos han sido realizados; no se necesita más investigación antes de que el usuario decida.
+- El asistente ha enumerado rutas de archivos, funciones y pasos concretos — no solo objetivos.
+- El usuario ha pedido ver el plan, o el flujo de modo plan está a punto de pasar el testigo a las herramientas de edición.
 
-**Adecuado para:**
-- El plan está completo en modo de planificación, listo para enviar a aprobación del usuario
-- Solo para tareas de implementación que requieren escribir código
-
-**No adecuado para:**
-- Tareas puramente de investigación/exploración — no se necesita salir del modo de planificación
-- Querer preguntar al usuario "¿está bien el plan?" — esa es exactamente la función de esta herramienta, no usar AskUserQuestion para eso
-
-## Notas
+## Parámetros
 
-- Esta herramienta no acepta el contenido del plan como parámetro — lo lee del archivo de plan escrito previamente
-- El usuario verá el contenido del archivo de plan para aprobarlo
-- No usar AskUserQuestion para preguntar "¿está bien el plan?" antes de llamar a esta herramienta, es redundante
-- No mencionar "plan" en las preguntas, ya que el usuario no puede ver el contenido del plan antes de ExitPlanMode
+- `allowedPrompts` (array, opcional): Prompts que el usuario puede escribir en la pantalla de aprobación para autoaprobar o alterar el plan. Cada elemento especifica un permiso con ámbito (por ejemplo, un nombre de operación y la herramienta a la que aplica). Déjalo sin establecer para usar el flujo de aprobación por defecto.
 
-## Texto original
+## Ejemplos
 
-<textarea readonly>Use this tool when you are in plan mode and have finished writing your plan to the plan file and are ready for user approval.
+### Ejemplo 1: Envío estándar
 
-## How This Tool Works
-- You should have already written your plan to the plan file specified in the plan mode system message
-- This tool does NOT take the plan content as a parameter - it will read the plan from the file you wrote
-- This tool simply signals that you're done planning and ready for the user to review and approve
-- The user will see the contents of your plan file when they review it
+Tras investigar un refactor de autenticación dentro del modo plan y escribir el archivo de plan en disco, el asistente llama a `ExitPlanMode` sin argumentos. El harness lee el plan desde su ubicación canónica, lo muestra al usuario y espera aprobación o rechazo.
 
-## When to Use This Tool
-IMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.
+### Ejemplo 2: Acciones rápidas preaprobadas
 
-## Before Using This Tool
-Ensure your plan is complete and unambiguous:
-- If you have unresolved questions about requirements or approach, use AskUserQuestion first (in earlier phases)
-- Once your plan is finalized, use THIS tool to request approval
+```
+ExitPlanMode(allowedPrompts=[
+  {"tool": "Bash", "prompt": "run tests"},
+  {"tool": "Bash", "prompt": "install dependencies"}
+])
+```
 
-**Important:** Do NOT use AskUserQuestion to ask "Is this plan okay?" or "Should I proceed?" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.
+Permite al usuario conceder permiso por adelantado para comandos de seguimiento rutinarios, para que el asistente no tenga que detenerse en cada solicitud de permiso durante la implementación.
 
-## Examples
+## Notas
 
-1. Initial task: "Search for and understand the implementation of vim mode in the codebase" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.
-2. Initial task: "Help me implement yank mode for vim" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.
-3. Initial task: "Add a new feature to handle user authentication" - If unsure about auth method (OAuth, JWT, etc.), use AskUserQuestion first, then use exit plan mode tool after clarifying the approach.
-</textarea>
+- `ExitPlanMode` solo tiene sentido para trabajo de tipo implementación. Si la solicitud del usuario es una tarea de investigación o explicación sin cambios de archivos, responde directamente en su lugar — no enrutes a través del modo plan solo para salir de él.
+- El plan ya debe estar escrito en disco antes de llamar a esta herramienta. `ExitPlanMode` no acepta el cuerpo del plan como parámetro; lee desde la ruta que el harness espera.
+- Si el usuario rechaza el plan, vuelves al modo plan. Revisa basándote en la retroalimentación y vuelve a enviar; no empieces a editar archivos mientras el plan no esté aprobado.
+- La aprobación concede permiso para salir del modo plan y usar herramientas mutadoras (`Edit`, `Write`, `Bash`, etc.) para el ámbito descrito en el plan. Expandir el ámbito después requiere un nuevo plan o consentimiento explícito del usuario.
+- No uses `AskUserQuestion` para preguntar "¿te parece bien este plan?" antes de llamar a esta herramienta — solicitar la aprobación del plan es exactamente lo que hace `ExitPlanMode`, y el usuario no puede ver el plan hasta que se envíe.
+- Mantén el plan mínimo y accionable. Un revisor debería poder leerlo por encima en menos de un minuto y entender exactamente qué va a cambiar.
+- Si te das cuenta a mitad de implementación de que el plan estaba equivocado, detente y reporta al usuario en lugar de desviarte silenciosamente. Volver a entrar al modo plan es un paso válido a continuación.

package/concepts/es/Tool-ExitWorktree.md

@@ -0,0 +1,41 @@
+# ExitWorktree
+
+Sale de una sesión de worktree creada previamente por `EnterWorktree` y devuelve la sesión al directorio de trabajo original. Esta herramienta solo actúa sobre los worktrees creados por `EnterWorktree` en la sesión actual; si no hay ninguna sesión activa de este tipo, la llamada no tiene efecto.
+
+## Cuándo usar
+
+- Has terminado el trabajo en un worktree aislado y deseas volver al directorio de trabajo principal.
+- Completaste una tarea en un worktree de rama de función y, tras hacer el merge, quieres limpiar la rama y el directorio.
+- Quieres conservar el worktree para usarlo más adelante y simplemente regresar al directorio original sin eliminar nada.
+- Quieres abandonar una rama experimental o temporal sin dejar ningún artefacto en disco.
+- Necesitas iniciar una nueva sesión de `EnterWorktree`, lo cual requiere salir primero de la actual.
+
+## Parámetros
+
+- `action` (cadena, obligatorio): `"keep"` conserva el directorio del worktree y la rama en disco para poder volver más adelante; `"remove"` elimina tanto el directorio como la rama, realizando una salida limpia.
+- `discard_changes` (booleano, opcional, valor predeterminado `false`): Solo es relevante cuando `action` es `"remove"`. Si el worktree contiene archivos sin confirmar o commits que no están en la rama original, la herramienta rechaza la eliminación a menos que `discard_changes` sea `true`. La respuesta de error lista los cambios concretos para que puedas confirmar con el usuario antes de volver a invocar.
+
+## Ejemplos
+
+### Ejemplo 1: salida limpia tras hacer merge de los cambios
+
+Después de finalizar el trabajo en un worktree y hacer merge de la rama en main, llama a `ExitWorktree` con `action: "remove"` para eliminar el directorio del worktree y la rama, y volver al directorio de trabajo original.
+
+```
+ExitWorktree(action: "remove")
+```
+
+### Ejemplo 2: descartar un worktree temporal con código experimental sin confirmar
+
+Si un worktree contiene cambios experimentales sin confirmar que deben descartarse por completo, primero intenta `action: "remove"`. La herramienta rechazará la operación y listará los cambios sin confirmar. Tras confirmar con el usuario que los cambios pueden descartarse, vuelve a invocar con `discard_changes: true`.
+
+```
+ExitWorktree(action: "remove", discard_changes: true)
+```
+
+## Notas
+
+- Esta herramienta solo actúa sobre worktrees creados por `EnterWorktree` en la sesión actual. No afectará a worktrees creados con `git worktree add`, worktrees de sesiones anteriores ni al directorio de trabajo normal si nunca se llamó a `EnterWorktree`; en esos casos la llamada no tiene efecto.
+- `action: "remove"` se rechaza si el worktree tiene cambios sin confirmar o commits no presentes en la rama original, a menos que se proporcione explícitamente `discard_changes: true`. Confirma siempre con el usuario antes de establecer `discard_changes: true`, ya que los datos no pueden recuperarse.
+- Si hay una sesión de tmux adjunta al worktree: con `remove` se termina; con `keep` continúa en ejecución y se devuelve su nombre para que el usuario pueda reconectarse más tarde.
+- Tras completar `ExitWorktree`, se puede volver a llamar a `EnterWorktree` para iniciar una nueva sesión de worktree.

package/concepts/es/Tool-Glob.md

@@ -1,39 +1,35 @@
 # Glob
 
-## Definición
+Compara nombres de archivo contra un patrón glob y devuelve las rutas ordenadas por tiempo de modificación más reciente primero. Optimizado para localizar archivos rápidamente en bases de código de cualquier tamaño sin recurrir a `find` en el shell.
 
-Herramienta rápida de coincidencia de patrones de nombres de archivo, compatible con bases de código de cualquier tamaño. Devuelve rutas de archivos coincidentes ordenadas por tiempo de modificación.
+## Cuándo usar
 
-## Parámetros
+- Enumerar cada archivo de una extensión específica (por ejemplo, todos los archivos `*.ts` bajo `src`)
+- Descubrir archivos de configuración o fixtures por convención de nombre (`**/jest.config.*`, `**/*.test.tsx`)
+- Estrechar la superficie de búsqueda antes de ejecutar un `Grep` dirigido
+- Verificar si un archivo ya existe en un patrón conocido antes de llamar a `Write`
+- Encontrar archivos modificados recientemente apoyándose en el orden por tiempo de modificación
 
-| Parámetro | Tipo | Requerido | Descripción |
-|-----------|------|-----------|-------------|
-| `pattern` | string | Sí | Patrón glob (como `**/*.js`, `src/**/*.ts`) |
-| `path` | string | No | Directorio de búsqueda, por defecto el directorio de trabajo actual. No pasar "undefined" ni "null" |
+## Parámetros
 
-## Casos de uso
+- `pattern` (string, obligatorio): La expresión glob a buscar. Admite `*` para comodines de un solo segmento, `**` para coincidencias recursivas y `{a,b}` para alternativas, por ejemplo `src/**/*.{ts,tsx}`.
+- `path` (string, opcional): Directorio en el que ejecutar la búsqueda. Debe ser una ruta de directorio válida cuando se proporcione. Omite el campo por completo para buscar en el directorio de trabajo actual. No pases las cadenas `"undefined"` ni `"null"`.
 
-**Adecuado para:**
-- Buscar archivos por patrón de nombre
-- Encontrar todos los archivos de un tipo específico (como todos los archivos `.tsx`)
-- Localizar archivos primero al buscar definiciones de clases específicas (como `class Foo`)
-- Se pueden lanzar múltiples llamadas Glob en paralelo en un solo mensaje
+## Ejemplos
 
-**No adecuado para:**
-- Buscar contenido de archivos — usar Grep
-- Exploración abierta que requiere múltiples rondas de búsqueda — usar Task (tipo Explore)
+### Ejemplo 1: Todos los archivos fuente TypeScript
+Llama a `Glob` con `pattern: "src/**/*.ts"`. El resultado es una lista ordenada por mtime, por lo que los archivos editados más recientemente aparecen primero, lo que es útil para enfocarse en puntos calientes.
 
-## Notas
+### Ejemplo 2: Localizar un candidato de definición de clase
+Cuando sospechas que una clase vive en un archivo cuyo nombre no conoces, busca con `pattern: "**/*UserService*"` para estrechar los candidatos, luego sigue con `Read` o `Grep`.
 
-- Soporta sintaxis glob estándar: `*` coincide con un nivel, `**` coincide con múltiples niveles, `{}` coincide con múltiples opciones
-- Los resultados se ordenan por tiempo de modificación
-- Se recomienda más que el comando `find` de Bash
+### Ejemplo 3: Descubrimiento en paralelo antes de una tarea mayor
+En un solo mensaje, emite múltiples llamadas `Glob` (por ejemplo una para `**/*.test.ts` y otra para `**/fixtures/**`) para que ambas se ejecuten en paralelo y sus resultados puedan correlacionarse.
 
-## Texto original
+## Notas
 
-<textarea readonly>- Fast file pattern matching tool that works with any codebase size
-- Supports glob patterns like "**/*.js" or "src/**/*.ts"
-- Returns matching file paths sorted by modification time
-- Use this tool when you need to find files by name patterns
-- When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead
-- You can call multiple tools in a single response. It is always better to speculatively perform multiple searches in parallel if they are potentially useful.</textarea>
+- Los resultados se ordenan por tiempo de modificación del archivo (más reciente primero), no alfabéticamente. Ordena en el lado cliente si necesitas un orden estable.
+- Los patrones son evaluados por la herramienta, no por el shell; no necesitas entrecomillarlos ni escaparlos como lo harías en la línea de comandos.
+- Para exploración abierta que requiere varias rondas de búsqueda y razonamiento, delega a una `Agent` con el tipo de agente Explore en lugar de encadenar muchas llamadas `Glob`.
+- Prefiere `Glob` sobre invocaciones de `find` o `ls` en `Bash` para descubrir nombres de archivo; maneja los permisos de forma consistente y devuelve salida estructurada.
+- Cuando buscas contenido dentro de archivos en lugar de nombres de archivo, usa `Grep` en su lugar.