asamblea

¿Qué hace asamblea?

Cuatro modelos, una respuesta, muchas rondas. Cada turno lee la mejor respuesta actual, la critica desde un rol determinado y escribe una versión mejorada. El progreso vive en archivos, no en la conversación, por lo que cada turno comienza con un contexto fresco (la técnica Ralph Wiggum).

Comandos

Comando	Qué hacer
asamblea <tarea>	Iniciar una ejecución con el plan predeterminado (36 turnos).
asamblea --rápido <tarea>	Un bloque de 2 pasadas x 4 modelos (8 turnos).
asamblea reanudar [<slug>]	Continuar la ejecución inacabada más reciente (o con nombre).
asamblea cancelar [<slug>]	Establecer estado: cancelado en el archivo de estado y detener.
asamblea estado	Mostrar iteración, bloque, elementos MUST abiertos y modelos utilizados.

Antes de comenzar

1. Cargar .asamblea/config.json si existe; de lo contrario, assets/config.ejemplo.json.
2. Elegir el adaptador de modelo (ver más abajo) e informar al usuario qué cuatro modelos se ejecutarán y dónde se enviará el texto de su tarea. Si algún modelo está fuera de modelosPermitidos, o soloLocal es verdadero y un modelo es remoto, eliminarlo y notificarlo.
3. Reformular la tarea y los criterios de aceptación en un párrafo breve. Si la tarea no está clara, preguntar al usuario antes de gastar rondas.
4. Crear .asamblea/<slug>/ con tarea.md, respuesta.md (vacío) y estado.md según se describe en referencias/formato-estado.md. Asegurarse de que .asamblea/ esté en .gitignore.

El plan

Una ronda es un turno de modelo. Una pasada son los cuatro modelos tomando un turno cada uno, en orden.

Bloque	Pasadas	Turnos	Total acumulado
1	4	16	16
2	3	12	28
3	2	8	36

Después del turno 36, mostrar el informe y preguntar al usuario si desea ejecutar otro bloque. Nunca pasar de 36 sin preguntar.

Los roles rotan en cada pasada para que cada modelo desempeñe todos los roles: en la pasada p (basada en 0), el modelo m desempeña roles[(m + p) % 4] de referencias/roles.md.

Cada turno

Construir el mensaje del turno solo a partir de archivos, utilizando referencias/formato-relevo.md:

• tarea.md
• la respuesta.md actual
• la crítica del turno anterior (del último ronda-NN.md)
• la tarjeta de rol para este turno

No incluir rondas anteriores ni indicar qué modelo escribió la respuesta actual. Luego:

1. Enviar el mensaje al modelo de este turno usando el adaptador elegido.
2. Analizar la respuesta en una crítica (cada problema etiquetado como MUST o NICE), una respuesta revisada y un veredicto.
3. Si la tarea es código y verificaciones están configuradas, aplicar la respuesta revisada en una copia temporal, ejecutar las verificaciones y añadir cualquier fallo a la crítica como elementos MUST.
4. Escribir ronda-NN.md (rol, id del modelo, crítica, resultados de verificación, veredicto, tamaño del diff de líneas) y sobrescribir respuesta.md con la respuesta revisada.
5. Actualizar estado.md: iteración, bloque, pasada, recuento de MUST abiertos y la racha de cambios nulos.
6. Dar al usuario una nota de progreso de una línea: Ronda 7/36 · escéptico · 2 MUST, 1 NICE · diff 14 líneas.

Si un modelo da error o se agota el tiempo, registrarlo en ronda-NN.md, saltar el turno y continuar. Si fallan dos modelos seguidos, pausar e informar al usuario.

Detención

Un turno cuenta como sin cambios cuando no plantea elementos MUST y cambia menos de lineasSinCambio líneas de respuesta.md.

Detener anticipadamente cuando:

• cuatro turnos seguidos (una pasada completa) son sin cambios, o
• un turno termina con <promesa>CONVERGIDO</promesa> y el siguiente turno lo confirma sin elementos MUST.

Si el recuento de MUST abiertos no ha disminuido durante un bloque completo, detenerse y escribir una nota breve de "atasco": qué está bloqueando, qué se intentó y qué podría decidir el usuario para desbloquearlo.

Informe

Cuando la ejecución termine, escribir .asamblea/<slug>/informe.md y mostrarlo:

• la respuesta final
• rondas ejecutadas y por qué se detuvo
• los cambios principales en cada bloque
• cualquier elemento NICE abierto
• modelos utilizados, con fallos
• una estimación aproximada de tokens y costos (suma de tamaños de mensaje y respuesta, multiplicada por precios en la configuración si se proporcionan)

Adaptadores de modelo

Usar el primero que esté disponible e informar al usuario cuál se eligió.

1. Subagentes dentro de la herramienta. Si el anfitrión puede generar subagentes y elegir su modelo, usar uno por turno. Cursor puede mezclar proveedores. Claude Code y Kiro solo ofrecen modelos Claude aquí, por lo que los cuatro serán variantes de Claude.
2. CLIs de proveedores. Ejecutar scripts/ejecutar-modelo.sh <id-modelo> <archivo-mensaje> una vez por turno. Esta es la opción verdaderamente multi-proveedor. Verificar que cada CLI existe (comando -v) antes de que comience la ejecución.
3. Modelo único. Ejecutar cada turno uno mismo, desempeñando el rol de ese turno. Leer solo los archivos del turno y tratar cada turno como un inicio fresco.

Los ayudantes opcionales específicos de la herramienta, como un gancho de detención de Claude Code para ejecuciones desatendidas, están en la carpeta adaptadores/ del repositorio.