Cuándo usar subagentes y cuándo mantener el trabajo en el hilo principal

TL;DR

Mantén el trabajo en el hilo principal del chat cuando el agente necesite todo el contexto compartido contigo, orientación frecuente, criterio de producto o un plan coherente que abarque varias fases.

Usa un subagente cuando la tarea sea aislada, genere mucho ruido, se pueda paralelizar, sea especializada o resulte útil principalmente como un resumen para la conversación principal.

Suena sencillo, pero el impacto real tiene matices:

• Los subagentes protegen el contexto principal de resultados de búsqueda, logs, capturas del navegador, salidas extensas de pruebas y caminos de exploración que no llevan a ninguna parte.
• Los subagentes pueden ejecutarse en paralelo, pero el paralelismo multiplica el consumo de tokens y la carga de revisión.
• Los subagentes son excelentes para «investiga y reporta lo que encuentres». Son menos eficaces cuando la tarea requiere una negociación constante con la persona o continuidad cuidadosa entre muchas decisiones.
• Los worktrees resuelven un problema distinto: el aislamiento de archivos. Los subagentes resuelven el aislamiento del contexto y la delegación. A menudo conviene usar ambos.
• Cursor y Claude Code ahora ofrecen mecanismos similares, pero con distintos nombres y modelos de coordinación. No trates «subagente», «agente en la nube», «equipo de agentes» y «worktree» como términos intercambiables.

Mi regla por defecto:

Main thread:
  decisions, synthesis, product tradeoffs, shared context, final edits

Subagent:
  research, verification, log reading, codebase exploration,
  independent review, isolated implementation attempt

Lo que aprenderás aquí

• Cuándo debe permanecer el trabajo en el hilo del historial del chat.
• Cuándo se puede ejecutar una tarea en un subagente sin problemas.
• Cómo se complementan los subagentes de Cursor, los Cloud Agents y los worktrees.
• En qué se diferencian los subagentes, forks, worktrees, sesiones en segundo plano y equipos de agentes de Claude Code.
• El impacto real en costo, velocidad, calidad del contexto, corrección y esfuerzo de revisión.
• Prompts prácticos y definiciones de subagentes que puedes adaptar.
• Un framework sencillo de decisión para ingenieros y PMs.

La pregunta central

Los agentes de programación modernos pueden hacer mucho más que responder a un prompt. Pueden inspeccionar un repo, ejecutar comandos, consultar documentación, editar archivos, abrir pull requests y ahora delegar trabajo a otras instancias de agentes.

Esto plantea una nueva pregunta sobre el flujo de trabajo:

¿Debería hacerse este trabajo dentro de la conversación principal o delegarse a un subagente?

La conversación principal no es solo una transcripción. Es la memoria de trabajo del agente para la tarea. Contiene objetivos, restricciones, resultados de herramientas, correcciones del usuario, decisiones parciales y la historia de cómo evolucionó la solución.

Un subagente es un agente de trabajo con su propia ventana de contexto. El agente principal le envía una tarea, el subagente trabaja por separado y el principal recibe el resultado. En la mayoría de los sistemas, el agente principal no hereda cada lectura intermedia de archivos, resultado de búsqueda, log de shell o captura del navegador.

Ese aislamiento es precisamente el objetivo.

El modelo mental

Piensa en el hilo principal como la sala donde se toman las decisiones.

Piensa en los subagentes como salas aparte donde se realiza trabajo enfocado.

                 human + main agent
              product intent, tradeoffs,
             final synthesis, commit scope
                         |
        +----------------+----------------+
        |                |                |
        v                v                v
   research agent   test agent      review agent
   reads 40 files   runs noisy      checks risks
   returns summary  test output     returns findings
        |                |                |
        +----------------+----------------+
                         |
                         v
              main thread decides

Si en una de esas salas se descubre algo importante, el subagente debe devolver un resultado conciso: hallazgos, evidencia, rutas de archivos, comandos ejecutados y próximos pasos recomendados.

Si el subagente necesita negociar cada paso, probablemente no debería trabajar por separado.

Qué debe permanecer en el hilo principal del chat

Mantén el trabajo en el hilo principal cuando la tarea dependa del criterio compartido y de la continuidad.

Buenos candidatos para el hilo principal:

• Convertir una solicitud vaga en un plan de implementación claro.
• Decidir el alcance con el usuario.
• Evaluar las ventajas y desventajas técnicas junto con el impacto en el producto.
• Elegir la arquitectura final después de varias investigaciones.
• Editar código que afecta la parte central de la tarea.
• Coordinar cambios en los que cada paso depende del resultado anterior.
• Escribir el resumen final, la descripción del PR y las notas de lanzamiento.

La señal clave no es «¿esto es importante?». El trabajo importante puede delegarse. La señal clave es:

¿Este trabajo necesita toda la conversación en evolución para mantener la coherencia?

Por ejemplo, si tú y el agente están analizando si lanzar hoy una funcionalidad más acotada o hacer después una refactorización más amplia, mantengan esa conversación en el hilo principal. Un subagente puede recopilar información, pero no debería encargarse de la decisión de producto.

Main-thread flow:

User goal
  -> clarify constraints
  -> inspect relevant files
  -> choose approach
  -> implement
  -> verify
  -> explain tradeoffs

Este flujo se beneficia de la continuidad. El agente debe recordar por qué rechazaste un enfoque y por qué otro coincide con la intención del producto.

Qué puede ejecutarse en un subagente

Usa un subagente cuando la tarea tenga límites claros y el agente principal necesite sobre todo el resultado.

Buenos candidatos para un subagente:

• «Busca en el código todos los puntos de entrada de autenticación y resume el flujo».
• «Ejecuta la suite de pruebas y reporta solo las pruebas que fallen con sus errores relevantes».
• «Revisa este diff en busca de problemas de seguridad, en modo de solo lectura».
• «Compara tres posibles bibliotecas y devuelve una recomendación».
• «Investiga la consola del navegador y devuelve el caso reproducible más pequeño».
• «Prueba una implementación en un worktree aislado para que podamos compararla».
• «Comprueba si el artículo cita documentación oficial actualizada».

Estas tareas comparten un patrón:

input is clear
work is noisy
output can be summarized
parent can judge result

Los subagentes son especialmente útiles para operaciones que consumen mucho contexto. La exploración del código, los logs y la automatización del navegador pueden generar enormes cantidades de resultados intermedios. Si todo eso termina en la conversación principal, el agente puede quedarse sin espacio para la decisión en sí.

Cursor: subagentes, Cloud Agents y worktrees

Cursor describe los subagentes como asistentes de IA especializados a los que el agente principal puede delegar tareas. Cada subagente tiene su propia ventana de contexto y devuelve su resultado al agente principal.

Esta distinción de Cursor es útil:

Cursor Agent:
  main coding conversation in editor, CLI, or cloud

Cursor Subagent:
  context-isolated helper for focused work

Cursor Cloud Agent:
  a full agent run in an isolated cloud VM, often creating a branch or PR

Cursor Worktree:
  a separate Git checkout so parallel agents do not edit the same files

La documentación de subagentes de Cursor destaca cuatro beneficios: aislamiento del contexto, ejecución paralela, conocimiento especializado y reutilización. También señala una realidad sobre el costo: cada subagente consume tokens de manera independiente, y ejecutar varios en paralelo puede multiplicar aproximadamente el consumo de tokens.

Cursor también tiene subagentes integrados para tareas que consumen mucho contexto:

• Explore para buscar y analizar código.
• Bash para secuencias de comandos que pueden generar una salida extensa.
• Browser para automatización del navegador, donde las capturas del DOM y de pantalla pueden generar mucho ruido.

Esto nos dice algo importante sobre el diseño de productos: los beneficios más evidentes de los subagentes no son glamorosos. Están en las partes rutinarias y ruidosas del trabajo de software.

Los Cloud Agents de Cursor son una unidad de delegación más amplia

Los Cloud Agents de Cursor, antes llamados Background Agents, se ejecutan en máquinas virtuales aisladas en la nube. Clonan repos, instalan dependencias, acceden a secretos y servidores MCP configurados, compilan, ejecutan pruebas y pueden subir cambios para entregarlos.

Usa un Cloud Agent cuando la unidad de delegación se parezca más a:

"Here is a task. Go work in your own environment and return a branch or PR."

Usa un subagente cuando la unidad de delegación se parezca más a:

"Go investigate this inside my current task and return a useful result."

Esa diferencia importa para los PMs. Un Cloud Agent puede convertir elementos del backlog en trabajo listo para revisión mientras tú haces otra cosa. Un subagente hace más eficaz la conversación actual sin llenarla con cada paso intermedio.

Los worktrees de Cursor resuelven las colisiones de archivos

El soporte de worktrees de Cursor le da a cada agente una copia de trabajo de Git independiente. Esto significa que los agentes pueden editar, instalar, compilar y ejecutar pruebas sin interferir con tu copia de trabajo principal ni entre sí.

No confundas esto con el aislamiento del contexto:

Subagent = separate thinking/context
Worktree = separate files/branch
Cloud VM = separate machine/environment

Para cambios de código, el mejor patrón suele ser:

subagent + worktree

separate context
  +
separate files
  =
parallel experiment you can review

Claude Code: subagentes, forks, worktrees y equipos de agentes

La documentación de Claude Code presenta los subagentes como asistentes especializados con su propia ventana de contexto, prompt de sistema personalizado, acceso a herramientas y permisos independientes. El agente principal delega una tarea, el subagente trabaja de manera independiente y devuelve el resultado.

La recomendación de Claude es directa:

Usa la conversación principal cuando:

• La tarea necesita intercambios frecuentes.
• Varias fases comparten una cantidad considerable de contexto.
• Estás haciendo un cambio rápido y puntual.
• La latencia importa.

Usa subagentes cuando:

• La tarea produce una salida extensa que no necesitas en el contexto principal.
• Quieres restricciones o permisos específicos para las herramientas.
• El trabajo es autónomo y puede devolver un resumen.

Esa es la mejor regla general que encontré en la documentación.

Los subagentes integrados de Claude apuntan al mismo patrón

Claude Code incluye subagentes integrados como Explore, Plan y general-purpose. Explore es de solo lectura y está optimizado para descubrir archivos y explorar el código. Plan recopila contexto durante la planificación. General-purpose se encarga de trabajos más complejos con varios pasos.

De nuevo, la idea no es «crear agentes porque los agentes son geniales».

La idea es:

Keep exploration out of the main thread
unless the exploration itself is the conversation.

Los subagentes con fork son un caso especial

Claude también documenta los subagentes con fork. Un subagente normal con nombre comienza con un contexto nuevo más el prompt de delegación. Un fork hereda todo el historial de la conversación en el momento en que se inicia.

Esto es útil cuando la tarea secundaria requeriría demasiadas explicaciones adicionales.

Named subagent:
  fresh context
  custom prompt/tools/model
  good for focused roles

Fork:
  inherits current conversation
  same broad situation
  good for trying side approaches

La contrapartida es que los forks reducen el beneficio de empezar con un contexto limpio. Saben más, pero también cargan con más contexto.

Los equipos de agentes no son simplemente subagentes

Los equipos de agentes de Claude Code son sesiones independientes de Claude Code coordinadas por un agente líder, con una lista de tareas compartida y mensajería entre agentes. La documentación los propone para trabajos en los que varios agentes necesitan comunicarse, cuestionar hallazgos o coordinarse de forma independiente.

Usa subagentes para trabajos específicos que deban reportar sus resultados.

Usa equipos de agentes cuando los agentes de trabajo necesiten comunicarse entre sí.

Subagents:
  parent coordinates
  workers report back to parent

Agent team:
  lead coordinates
  teammates can communicate
  shared task list

Los equipos de agentes agregan más sobrecarga y consumo de tokens. Son especialmente útiles para la investigación paralela, la revisión de código desde distintos ángulos, las partes independientes de una funcionalidad o la depuración con hipótesis contrapuestas.

El impacto real de usar subagentes

Los subagentes no son un botón gratuito de productividad. Redistribuyen costos y riesgos.

1. Mejora la calidad del contexto

Esta es la mayor ventaja.

El hilo principal se mantiene enfocado en la intención del usuario, las decisiones, el estado de la implementación y la síntesis final. Todo el proceso intermedio, con su desorden, queda en otro lugar.

Sin subagentes:

main context =
  user goal
  20 file reads
  8 grep outputs
  3 failed test logs
  browser DOM dump
  one useful conclusion

Con subagentes:

main context =
  user goal
  useful conclusion
  evidence summary
  next decision

Ese contexto más limpio a menudo importa más que el tamaño bruto de la ventana de contexto.

2. La velocidad puede mejorar, pero solo para trabajo independiente

Los subagentes en paralelo pueden terminar investigaciones independientes en el tiempo que tarde el más lento, en lugar de sumar los tiempos de todos.

Buen prompt para trabajo paralelo:

Investigate these independently:
1. auth middleware
2. session storage
3. frontend login state

Return file paths, risks, and recommended fixes.
Do not edit files.

Mal prompt para trabajo paralelo:

Three agents should all modify the same checkout and improve auth.

El primer prompt divide el trabajo. El segundo crea conflictos y complica la revisión.

3. El costo aumenta más rápido de lo esperado

Cada subagente tiene su propio contexto y consumo de tokens. Si cinco subagentes leen las mismas instrucciones del repo, inspeccionan archivos y producen resúmenes, estás pagando por cinco ciclos de trabajo.

Aun así puede valer la pena. Un ingeniero sénior preferiría pagar por tres investigaciones enfocadas que pasar una hora leyendo logs manualmente. Pero la economía no hace magia.

Usa subagentes cuando se cumpla alguna de estas condiciones:

• Evitan contaminar el contexto principal.
• Reducen el tiempo total de espera.
• Producen perspectivas independientes.
• Establecen un límite de permisos útil.
• Permiten comparar implementaciones alternativas.

Si no se cumple ninguna, mantén el trabajo en el hilo principal.

4. La corrección puede mejorar mediante una revisión independiente

Uno de los mejores usos es un subagente de verificación.

El agente principal implementa. El subagente revisa con un objetivo diferente.

main agent:
  implement the feature

verifier subagent:
  run tests
  inspect the diff
  find incomplete claims
  report pass/fail

Esto ayuda porque implementar y verificar requieren modos de pensamiento distintos. El agente que implementa es vulnerable al sesgo de confirmación. Un verificador con un prompt escéptico puede detectar casos que se pasaron por alto.

5. Aumenta la carga de revisión

El trabajo paralelo produce resultados en paralelo. Alguien todavía tiene que integrar los hallazgos.

Para los ingenieros, esto significa revisar resúmenes, diffs, pruebas y artefactos.

Para los PMs, significa decidir si el mayor volumen de trabajo producido es valioso cuando también genera más trabajo pendiente de revisión.

La pregunta no es:

¿Podemos ejecutar diez agentes?

La pregunta es:

¿Podemos revisar diez resultados lo suficientemente bien como para confiar en ellos?

Framework de decisión

Usa esto antes de delegar:

Does the task need the full evolving user conversation?
  yes -> main thread
  no  -> continue

Will the task generate noisy intermediate output?
  yes -> subagent
  no  -> continue

Can the task return a compact result?
  no  -> main thread
  yes -> continue

Can it run independently from other work?
  yes -> subagent, possibly parallel
  no  -> main thread or sequential subagent chain

Will it edit files?
  no  -> subagent is low risk
  yes -> use a worktree or isolated branch

Do multiple workers need to coordinate with each other?
  yes -> consider agent teams or a human-owned plan
  no  -> subagent is enough

Aquí está el mismo framework en una tabla:

Patrones prácticos de prompts

Subagente de investigación

Use a read-only subagent to inspect the payment flow.

Return:
- the key files and entry points
- the current flow in 8 bullets or fewer
- any unclear or risky areas
- what you did not inspect

Do not edit files.
Do not paste long code snippets.

Por qué funciona:

• Limita el alcance.
• Pide evidencia.
• Evita volcar grandes cantidades de código.
• Mantiene visibles las incertidumbres.

Subagente de verificación

Use a verifier subagent to check the current diff.

Verify:
- the feature is implemented, not only stubbed
- tests were added or existing tests still cover the behavior
- npm test or the closest relevant command passes
- there are no unrelated edits

Return pass/fail, commands run, and specific file references.

Por qué funciona:

• Separa el modo de implementación del modo de revisión.
• Pide comandos reales, no impresiones.
• Mantiene la responsabilidad del juicio final en el agente principal.

Investigación paralela

Run three read-only investigations in parallel:

1. API behavior
2. database schema and migrations
3. frontend state and UI edge cases

Each subagent should return:
- relevant files
- current behavior
- likely change points
- risks

After all return, synthesize one implementation plan.

Por qué funciona:

• Cada agente tiene un ámbito distinto.
• El agente principal conserva la responsabilidad de la síntesis.
• El plan final se mantiene coherente.

Ejemplo: definición de un subagente de Cursor

Los subagentes personalizados de Cursor son archivos Markdown con frontmatter en YAML. Un verificador útil mantenido por el equipo podría verse así:

---
name: verifier
description: Validates completed work. Use after implementation to confirm the change is functional and scoped.
model: inherit
readonly: true
---

You are a skeptical verification agent.

When invoked:
1. Inspect the current diff.
2. Identify what the parent agent claims is complete.
3. Run the most relevant tests or checks when allowed.
4. Verify that the implementation exists and is not only a stub.
5. Look for unrelated file changes.

Return:
- pass/fail
- commands run
- evidence by file path
- incomplete or risky items
- recommended next action

Ubicación a nivel de proyecto:

.cursor/agents/verifier.md

Usa este tipo de subagente cuando el problema recurrente sea «el agente dice que terminó, pero necesito una segunda revisión antes de creerle».

Ejemplo: definición de un subagente de Claude Code

Claude Code también admite subagentes definidos en archivos. Un agente de investigación de solo lectura podría verse así:

---
name: codebase-researcher
description: Read-only codebase researcher. Use when a task needs broad exploration across files before implementation.
tools: Read, Grep, Glob
model: inherit
---

You are a codebase research specialist.

Your job is to investigate, not edit.

When invoked:
1. Restate the question you are answering.
2. Search for the smallest set of relevant files.
3. Summarize the architecture and behavior.
4. Include exact file paths.
5. Flag uncertainty and areas not inspected.

Do not propose a full implementation unless asked.
Do not paste large code blocks.

Ubicación a nivel de proyecto:

.claude/agents/codebase-researcher.md

Es una buena opción cuando el hilo principal trata sobre un cambio más amplio, pero primero necesita un conjunto de hallazgos de investigación bien delimitado.

Ejemplo: una heurística sencilla de delegación

Si estás construyendo tu propio enrutador de agentes, puedes codificar una heurística básica antes de recurrir a una orquestación compleja.

type Task = {
  needsUserJudgment: boolean;
  expectedOutput: "summary" | "code-change" | "decision";
  noisy: boolean;
  independent: boolean;
  editsFiles: boolean;
};

function chooseExecutionMode(task: Task) {
  if (task.needsUserJudgment || task.expectedOutput === "decision") {
    return "main-thread";
  }

  if (task.editsFiles && task.independent) {
    return "subagent-in-worktree";
  }

  if (task.noisy && task.expectedOutput === "summary") {
    return "subagent";
  }

  if (task.independent && task.expectedOutput === "summary") {
    return "parallel-subagent-candidate";
  }

  return "main-thread";
}

Lo importante no es el código. Lo importante es la disciplina:

delegate only when the output contract is clear

Antipatrones

1. Delegar la decisión

Mal:

Use subagents to decide what product we should build.

Mejor:

Use subagents to research three customer workflows.
Return evidence and tradeoffs.
We will decide in the main thread.

2. Paralelizar ediciones del mismo archivo

Mal:

Have five agents refactor the auth service at once.

Mejor:

Have one agent inspect auth service risks.
Have another inspect tests.
Have another inspect API callers.
Synthesize first, then edit.

3. Usar subagentes para tareas diminutas

Mal:

Use a subagent to rename this variable.

Mejor:

Rename the variable in the main thread.

Iniciar un subagente y recopilar contexto puede ser más lento que simplemente hacer la tarea.

4. Aceptar resúmenes sin evidencia

Mal:

Looks good.

Mejor:

Looks good because:
- tests run: npm test
- files inspected: src/auth/session.ts, src/middleware.ts
- risks remaining: refresh token expiry not covered

El resumen de un subagente debe ser conciso, no vago.

Cómo deberían pensar los PMs sobre esto

Para los PMs, los subagentes tienen menos que ver con la arquitectura de modelos y más con cómo se organiza el trabajo.

Una buena tarea delegada tiene:

• Un objetivo claro.
• Límites claros.
• Un resultado esperado claro.
• Una definición clara de cuándo está terminada.
• Una persona que pueda revisar y evaluar el resultado.

Esto se aplica muy bien al trabajo de producto:

bad delegation:
  "Improve onboarding"

good delegation:
  "Inspect onboarding analytics events.
   Return missing events, duplicate events,
   and one recommended event schema update."

Los subagentes dan mejores resultados cuando el trabajo se descompone con precisión. La delegación vaga, en cambio, produce resúmenes que suenan seguros sobre trabajos con un alcance mal definido.

Cómo deberían pensar los ingenieros sobre esto

Para los ingenieros, los subagentes son una herramienta de gestión de contexto y verificación.

Los mejores usos en ingeniería que he visto son:

• Exploración de la arquitectura en modo de solo lectura antes de tocar el código.
• Análisis de pruebas y logs.
• Revisión independiente de diffs.
• Revisión de seguridad o rendimiento con herramientas limitadas.
• Intentos de implementación de tipo best-of-N en worktrees separados.
• Conjuntos de hallazgos de investigación sobre sistemas poco conocidos.

La disciplina importante es mantener la responsabilidad de la integración en el hilo principal.

Subagent finds.
Main thread decides.
Main thread integrates.
Verifier checks.
Human reviews.

Reglas prácticas de operación

Usa estas reglas de equipo hasta que tengas mejores datos de tu propio entorno:

1. Comienza con un subagente, no con cinco.
2. Prefiere primero los subagentes de solo lectura.
3. Usa worktrees para los subagentes que editan archivos.
4. Pide evidencia, no solo conclusiones.
5. Divide el trabajo por módulo, riesgo o hipótesis.
6. Mantén la síntesis final en el hilo principal.
7. Registra si los subagentes redujeron el tiempo de revisión o solo lo trasladaron.
8. Convierte los prompts exitosos que se repiten en definiciones de subagentes del proyecto.

Un flujo de trabajo útil por defecto

Para un cambio de código de tamaño mediano:

1. Main thread:
   clarify goal and constraints

2. Research subagent:
   inspect relevant code paths, read-only

3. Main thread:
   choose implementation plan

4. Main thread or worktree subagent:
   implement

5. Verifier subagent:
   run tests, inspect diff, report gaps

6. Main thread:
   fix gaps, write summary, prepare PR

Esto te da aislamiento de contexto sin perder coherencia.

En resumen

Los subagentes son más valiosos cuando protegen la conversación principal del ruido y producen resultados independientes que se pueden revisar.

Son menos valiosos cuando se usan por reflejo para cada tarea.

Un flujo de trabajo maduro no consiste en «un agente frente a muchos agentes». Consiste en:

one main thread for coherence
focused subagents for bounded work
worktrees for file isolation
cloud agents for independent backlog execution
agent teams when workers must coordinate

Ese es el enfoque que recomendaría hoy a los equipos de ingeniería y PMs que adoptan Cursor, Claude Code o cualquier entorno similar de programación con agentes.

Preguntas abiertas en este artículo

Este artículo se basa en la documentación actual de los productos y en un análisis práctico de flujos de trabajo, no en un benchmark controlado.

Las siguientes investigaciones útiles serían:

• Un benchmark pequeño que compare un agente en el hilo principal frente a un agente en el hilo principal más un subagente verificador.
• Un estudio de costos de subagentes de investigación en paralelo en repos reales.
• Un estudio del tiempo de revisión: ¿los subagentes reducen el tiempo de revisión humana o solo crean más artefactos?
• Una taxonomía de fallos en el trabajo de programación delegado: contexto desactualizado, mala división del trabajo, problemas de permisos, conflictos de integración y resúmenes vagos.
• Una comparación de Cursor Cloud Agents, sesiones en segundo plano de Claude y worktrees en la nube al estilo de Codex con las mismas tareas del backlog.

Lista de fuentes

• Documentación de Cursor: subagentes
• Documentación de Cursor: Cloud Agents
• Documentación de Cursor: worktrees
• Documentación de Cursor: mejores prácticas para Cloud Agents
• Blog de Cursor: mejores prácticas para programar con agentes
• Documentación de Claude Code: crear subagentes personalizados
• Documentación de Claude Code: subagentes en el SDK
• Documentación de Claude Code: ejecutar agentes en paralelo
• Documentación de Claude Code: ejecutar sesiones paralelas con worktrees
• Documentación de Claude Code: orquestar equipos de sesiones de Claude Code
• Documentación de Claude Code: extender Claude Code