Delegar

Del backlog: la lógica duplicada entre los adaptadores cloud (ítem 3) y la operación del worker que quedó coja. Dos frentes, a la vez.

Paso a paso

1. Partir antes de paralelizar. Se congelan los contratos compartidos: RetryPolicy, AuditEvent, WorkerHealth. Recién entonces se abren los frentes.

2. Dos terminales en el clon, un worktree por frente. Cada comando crea una copia de trabajo aislada del mismo repo, con su propia rama. Git haciendo de muro físico entre dos agentes.

claude -w refactor-adaptadores    # frente A
claude -w operacion-worker        # frente B

Prompt del frente A:

Unifica la lógica de retry duplicada entre los adaptadores en un módulo
común, con errores tipados y sus tests. El contrato RetryPolicy está
congelado: no lo cambies.

Prompt del frente B:

Dale observabilidad a la operación del worker: métrica de cola pendiente,
logs de procesamiento con timestamp, runbook actualizado y el terraform
que haga falta. No toques app/adapters/.

El frente B mezcla app e infra sin pedir permiso: así es el trabajo real.

3. De dónde nacen las sesiones que trabajan solas: /background suelta la sesión actual de tu terminal y la deja trabajando; /fork copia la conversación completa a una sesión nueva que sigue sola mientras tú continúas en la tuya. Con cuatro o cinco sesiones vivas, agent view las muestra y despacha desde un solo lugar.

4. Subagentes. Cuando una sesión tiene que revisar cuarenta archivos, no los carga en su mesa: manda la búsqueda a un subagente, que lee todo en su propio contexto y devuelve un resumen. La pregunta que decide entre subagente y worktree: ¿necesita tocar archivos, o solo necesita responderme algo?

5. Agentes con nombre propio. Cuando pides el mismo trabajador una y otra vez, merece archivo. El wizard /agents ya no existe; ahora se lo pides a Claude en lenguaje natural y lo que produce es un archivo versionado.

Crea un subagente 'revisor' en .claude/agents/ que revise diffs de este
repo: correctitud, riesgos de concurrencia (regla del issue #12) y
cumplimiento del CLAUDE.md. Solo lectura, modelo más liviano, y que
explique cada objeción con el código en la mano.

Resultado esperado, el frontmatter que genera solo:

.claude/agents/revisor.md
---
name: revisor
description: Revisor de solo lectura para diffs de incident-system. Úsalo después
  de escribir o modificar código, antes de commitear o abrir un PR: correctitud,
  riesgos de concurrencia (patrón check-then-insert del issue #12) y cumplimiento
  de CLAUDE.md. Invócalo proactivamente cuando el usuario pida "revisar".
tools: Read, Grep, Glob, Bash
model: haiku
---

Tres cosas: la descripción es cómo Claude decide delegarle trabajo solo (mismo patrón que la skill). Modelo liviano y solo lectura: un revisor no necesita el modelo caro ni permisos de escritura. Y vive en .claude/agents/, dentro del repo, en git: tu equipo hereda al revisor al clonar.

Pruébalo: revisor: mira el diff del frente A y dame tus objeciones.

6. Las sesiones se hablan. En la terminal del frente A:

Avísale a la sesión del frente B que el contrato de retry quedó congelado
y puede rebasear.

Resultado esperado: el mensaje aparece en la otra terminal con el nombre de la sesión que lo mandó. Detalle de diseño: un mensaje jamás aprueba permisos del otro lado, jamás cambia configuración, y un comando que venga adentro llega como texto, no se ejecuta. Información, no autoridad.

7. El mapa completo de coordinación, ordenado por quién sostiene el plan y dónde viven los resultados intermedios:

SUBAGENTE ............ investigación lateral; el resultado vuelve a TU mesa
/background y /fork .. sesiones tuyas que siguen solas
MENSAJES ............. sesiones independientes que se avisan cosas
AGENT TEAMS .......... un líder, tareas compartidas, coordinación explícita (experimental)
WORKFLOWS ............ decenas de agentes; el plan vive en un SCRIPT

8. Workflows. Cuando la tarea necesita más agentes de los que una conversación puede coordinar, escribes la palabra ultracode en el prompt y Claude no ejecuta la tarea: escribe el orquestador. Un script con fases, agentes en paralelo y verificación cruzada antes de reportarte. La flota se mira con /workflows.

ultracode: audita app/ buscando llamadas a la base sin manejo de errores
y supuestos rotos del contrato de estados; verifica cada hallazgo antes
de reportarlo.

Resultado esperado: propone un workflow (lo apruebas), manda agentes a leer app/, trae hallazgos reales y los verifica con agentes escépticos antes de reportar. Navega la corrida con /workflows. Si tienes un modelo más grande, este es de los pocos lugares donde ponerlo: cuando el que escribe es el orquestador, la calidad del plan se multiplica por cada agente que lo ejecuta.

9. El payoff: /batch. Todo lo que hiciste a mano (partir, congelar contratos, aislar en worktrees, un agente por frente) viene empaquetado:

/batch agrega type hints completos a los módulos de app/

Resultado esperado: investiga el repo y te propone la partición en unidades independientes, cada una en su worktree con su PR. La lección es leer el plan con criterio. Ejemplo real: dos unidades tocaban app/worker/main.py, que tenía trabajo vivo en la rama del frente B sin mergear. El batch no puede verlo (mira main, no ramas ajenas). Tú sí. Elige “Tell Claude what to change” y corrige:

Corrige el plan: app/worker/main.py tiene trabajo sin mergear en la rama
worktree-operacion-worker (observabilidad del worker). Saca ese archivo
del alcance de todas las unidades; se tipa después del merge de los frentes.

10. Cierre: merge de los dos frentes, y el gate integrado como juez: tests, build, validación de infra. Verde.

Comandos desbloqueados

• claude --worktree (-w) · una copia aislada del repo por sesión.
• /background · la sesión sigue sola.
• /fork · copia de la conversación en una sesión nueva.
• Subagentes · investigación sin ensuciar la mesa.
• .claude/agents/ · agentes con nombre, versionados.
• Mensajes entre sesiones · información, no autoridad.
• ultracode y /workflows · el plan en un script.
• /batch · partición y PRs en paralelo, empaquetado.
• agent view (mención) · muchas sesiones desde un solo lugar.

Backlog: ítem 3 tachado. Marcador: autonomía sube (varios a la vez) · control sube (fronteras tuyas).