# Instrucciones para el agente: Cambios paralelos: worktrees separados y revisión de comportamiento

Pega este texto a tu agente (Claude Code, Codex, OpenCode, Hermes o el que uses) y dile «ayúdame a montarlo». Son los pasos para ponerlo en marcha; el porqué de cada pieza está en la guía completa.

- Dificultad: intermedio
- Guía completa: https://lab.wisd.ai/hub/multi-agent-ide

---

## Para el agente: cómo acompañar al usuario

1. Pregunta primero para qué lo quiere. Si su objetivo no necesita algún paso, sáltalo.
2. Antes de instalar, comprueba lo que ya tiene (versiones, claves, sistema operativo).
3. Avanza un paso cada vez: explica en una frase qué vas a hacer y deja que el usuario lo ejecute o lo apruebe.
4. Tras cada paso, comprueba que funcionó antes de seguir. Si falla, para y explica el error.
5. No inventes comandos ni opciones: si la documentación del proyecto contradice estos pasos, manda la documentación.
6. Al terminar, haz una prueba real con el objetivo del usuario y dile dónde profundizar.

---

## Pasos de configuración

### Delimita la prueba

Elige dos tareas independientes, sus archivos permitidos y su criterio de aceptación. Conserva una base limpia identificada y separa los datos de prueba compartidos.

### Configura Emdash

Sigue [Emdash](/hub/emdash-parallel-coding-worktrees), incluidos sus requisitos, configuración y comprobación actuales. Comprueba una tarea con su rama y carpeta de trabajo distintas antes de editar y conserva la revisión base.

### Configura Superpowers TDD

Sigue [Superpowers TDD](/hub/superpowers-tdd), incluidos sus requisitos, configuración y comprobación actuales. Carga la skill en la sesión que hará el cambio y conserva evidencia del fallo de comportamiento esperado y de la prueba correcta posterior.

## Datos que pasan entre piezas

Los archivos siguientes son entregables de este caso preparados por el agente; no implican exportadores ni sincronización automática.

Entrega de Emdash a cada sesión TDD el nombre de rama, ruta de worktree, revisión base, archivos permitidos y criterio; recoge en evidencias.md por tarea el cambio de código y las salidas de prueba fallida y correcta. Si falta aislamiento o una prueba falla por el entorno, detén la integración hasta resolverlo; vuelve a comprobar tras cada rama integrada.

## Monta el flujo

### Paso 1

Abre el repositorio de prueba en Emdash y crea una tarea por cambio. Comprueba que cada sesión tiene su rama y carpeta distintas antes de editar.

### Paso 2

En cada encargo usa Superpowers TDD: describe el comportamiento, observa la prueba fallar por la causa esperada y realiza el cambio mínimo. Conserva salidas y diff.

### Paso 3

Revisa cada rama y ejecuta sus comprobaciones. Integra una a una en una rama de revisión, resuelve conflictos conociendo ambos cambios y vuelve a comprobar el comportamiento combinado.

## Comprobación

Comprueba aislamiento de rutas y ramas, evidencia de fallo inicial y éxito posterior. Tras integrar, ejecuta las comprobaciones que cubren la interacción de los cambios.

## Si algo falla

Si las tareas empiezan a editar los mismos archivos, detén una y reorganiza el reparto. Si el fallo depende de servicios compartidos, aísla el recurso antes de atribuirlo al código.

Esta composición de WISD no se ha ejecutado como prueba integral. La configuración se consulta en las guías enlazadas; las etapas describen cómo coordinar las piezas.

## Prompt para tu agente

Sustituye los campos entre <> antes de pegarlo.

```text
Lee y sigue las instrucciones publicadas de las piezas: Emdash: /hub/emdash-parallel-coding-worktrees/instrucciones.md; Superpowers TDD: /hub/superpowers-tdd/instrucciones.md. Completa los requisitos, configuración y comprobación de cada pieza antes de usarla; comprueba su uso desde el cliente o arnés elegido, no solo su presencia en disco. Si falta un campo entre <>, una fuente obligatoria, acceso o una operación documentada, detén la etapa dependiente, informa qué falta y pídemelo; usa una alternativa manual solo cuando esté descrita y comprobada. No inventes datos ni des por superada una comprobación pendiente.

Coordina <tarea A> y <tarea B> en <repositorio>, con <archivos permitidos por tarea> y <criterios de aceptación>. Usa Emdash para ramas y worktrees separados y Superpowers TDD para observar el fallo y comprobar cada corrección. Verifica aislamiento antes de editar. Revisa diffs y evidencias, integra una rama cada vez en <rama de revisión> y ejecuta <comprobaciones combinadas>. Entrega cambios, resultados y dudas; si las tareas dejan de ser independientes, pásalas a secuencia.

Entrega de Emdash a cada sesión TDD el nombre de rama, ruta de worktree, revisión base, archivos permitidos y criterio; recoge en evidencias.md por tarea el cambio de código y las salidas de prueba fallida y correcta. Si falta aislamiento o una prueba falla por el entorno, detén la integración hasta resolverlo; vuelve a comprobar tras cada rama integrada.
```