designloop

¿Qué hace designloop?

Un bucle que eleva la calidad de una interfaz existente, o la escritura en ella y a su alrededor, midiéndola, no adivinando. Cada ronda: captura la UI (o toma una instantánea del texto) de la misma manera, que jueces nuevos la puntúen según una rúbrica fija, corrige lo que encontraron y repite. Está modelado en el método de evaluación de dream-loop (un juez fresco por ronda, puntilloso, las regresiones puntúan más bajo), aplicado al pulido de UI en lugar de emparejar una imagen de destino, y en el enfoque de escalada de colinas de Theo (t3.gg) para el diseño de UI en Agents Sucked At UI (Until Today).

El bucle funciona gracias a tres separaciones. Mantenlas:

• Los jueces nunca implementan y los implementadores nunca juzgan. Un agente que escribió la corrección la puntúa generosamente.
• Los jueces son nuevos cada ronda. Un juez que vio la ronda anterior se ancla en su propio veredicto anterior. Dale a un juez nuevo la rúbrica, las nuevas capturas y el veredicto anterior (para que la puntuación sea consistente y se nombren las regresiones), no la conversación.
• El conjunto de capturas es fijo. Las puntuaciones solo son comparables si la ronda N muestra las mismas superficies, estados y temas que la ronda 0.

Tres modos

El bucle es el mismo en los tres; lo que los jueces miden es diferente. Decide el modo primero, porque determina la rúbrica, las preguntas que vale la pena hacer y cuánto cambio se espera.

• Pulido profesional — un pase objetivo, las cosas que un diseñador de producto senior verifica: un conjunto de tokens y superficies usado en todas partes, menos tamaños y pesos de fuente, una escala de espaciado consistente, legibilidad y contraste, objetivos táctiles y zonas del cursor, cobertura de estados, paridad claro/oscuro, calidad de movimiento. El objetivo es la mejor versión de la propia aplicación; los cambios de gusto no aplican. Lee references/mode-polish.md.
• Dirección de arte — un pase subjetivo hacia un aspecto y sensación específicos: un estilo nombrado ("realismo gráfico", "pop neón con arte ASCII y diseños brutales y dinámicos"), un conjunto de referencias, una imagen objetivo generada o un diseño de Figma a igualar. Los jueces puntúan qué tan bien la UI expresa esa dirección. Se espera un cambio visual mayor, por lo que las fuentes, el color y el carácter del diseño entran en juego. Lee references/mode-art-direction.md.
• Escritura — el bucle aplicado a las palabras: textos de UI (etiquetas, errores, estados vacíos, incorporación), documentación y páginas de producto, o piezas independientes. Los jueces puntúan claridad, concisión, voz, coherencia y precisión para un lector nombrado, respaldados por pruebas de lector (un agente nuevo lee el texto en frío y dice qué haría). El significado se mantiene fijo; las palabras mejoran. Lee references/mode-writing.md, que dice cómo cambia cada paso siguiente (textos en lugar de superficies, instantáneas en lugar de capturas, un glosario en lugar de tokens).

Deduce el modo de la solicitud cuando esté claro ("apretar", "consistente", "descuidado" → pulido; "haz que se vea como", "más artístico", un nombre de estilo, un enlace de Figma → dirección de arte; "texto", "redacción", "documentación", "mensajes de error", "esta publicación" → escritura), de lo contrario pregunta. Un usuario puede querer más de uno: ejecuta primero la dirección de arte para establecer el aspecto, luego un pase de pulido para hacerlo consistente y un pase de escritura sobre el texto, cada uno como su propio bucle con su propia rúbrica. No los mezcles en una sola rúbrica, o los jueces intercambiarán consistencia por estilo y las puntuaciones dejarán de significar algo.

Paso 1: Entrevistar al usuario

Decide el modo, luego pregunta el resto con AskUserQuestion (dos llamadas; acepta hasta cuatro preguntas cada una). Salta cualquier pregunta que el mensaje del usuario ya haya respondido y ofrece una opción recomendada primero. Las respuestas van al archivo de brief (paso 3), que es lo que lee cada subagente.

1. Objetivo — ¿qué debería mejorar cuando esto termine, en sus palabras? ("Chrome se siente inconsistente", "los menús están descuidados", "se siente entrecortado"). También pregunta qué está fuera de los límites: superficies que quieren manejar ellos mismos y cuánto cambio aceptarán (apretar vs. rediseñar vs. rediseñar por completo). La mayoría de los usuarios quieren apretar, no un rediseño; dilo en cada brief o los implementadores se excederán.
2. Enfoque (selección múltiple) — qué dimensiones importan más; esto establece los pesos de la rúbrica. Las opciones dependen del modo y se enumeran en su archivo de referencia (pulido: consistencia y tokens, tipografía, espaciado y diseño, legibilidad, interacción y objetivos táctiles, movimiento, rendimiento; dirección de arte: los rasgos del estilo elegido y qué partes de la UI deben portarlo; escritura: claridad, concisión, estructura, voz y tono, coherencia, utilidad, precisión). En el modo escritura, también haz las preguntas adicionales en references/mode-writing.md (lector y propósito, muestras de voz, qué está fijo, límites de longitud y localización).
3. Línea base — ¿dónde está la UI hoy? El usuario da una puntuación del 1 al 10, o los jueces la puntúan primero. Recomienda hacer ambas cuando el usuario tenga una opinión: su número calibra a los jueces (si dice 6 y los jueces dicen 8, la rúbrica es demasiado permisiva — ajústala antes de la ronda 1).
4. Condición de parada — una puntuación objetivo (ej. ≥9/10 en cada grupo y tema), un número de rondas, o lo que ocurra primero. Recomienda "puntuación objetivo, con un máximo de N rondas". Advierte que un bucle sin límite puede usar muchos tokens.
5. Inteligencia del subagente — qué modelo y esfuerzo usan los jueces e implementadores. Ofrece: el mejor disponible (más lento, más minucioso), equilibrado (el modelo y esfuerzo de la sesión actual), rápido (modelo más barato para capturas y correcciones mecánicas, modelo fuerte para juzgar). Juzgar es donde la inteligencia más rinde; si el usuario quiere ahorrar, ahorra primero en captura e implementación mecánica.
6. Referencias — ¿tienen diseños que les gustan o deben coincidir? Sitios web, aplicaciones, capturas de pantalla, un enlace de Figma, un sistema de diseño o una pauta o habilidad nombrada (una HIG de plataforma, una habilidad de diseño-ingeniería). Pregunta qué les gusta de cada una (la densidad, los menús, el movimiento), porque "me gusta este sitio" sin una razón se copia por completo. En modo pulido, las referencias son opcionales y generalmente pautas. En modo dirección de arte, el bucle necesita un objetivo: una descripción de estilo, referencias, un diseño de Figma o una imagen generada; si el usuario no tiene ninguna, ofrece recopilar o generar algunas (ver "Referencias y objetivos").
7. Entrega — solo una rama, un PR (sin fusionar), y/o una compilación que puedan ejecutar. Por defecto: rama + PR sin fusionar. Nunca fusiones ni publiques a menos que lo pidan.

Pon todo lo que el usuario te dio en .designloop/references/ (paso 3) y enuméralo en la rúbrica, para que cada juez e implementador trabaje desde las mismas fuentes.

Paso 2: Estudiar la configuración del proyecto

Antes de escribir cualquier regla, averigua cómo se ejecuta, prueba y publica este proyecto realmente, para que el bucle siga los hábitos del usuario en lugar de imponer los suyos propios. Mira primero, pregunta después: lee lo que el repositorio y la máquina pueden decirte, y solo pregunta sobre lo que aún no esté claro o sea una cuestión de preferencia.

Busca:

• Instrucciones ya escritas: CLAUDE.md / AGENTS.md, README y CONTRIBUTING, notas de memoria y cualquier archivo de reglas de agente anterior. Estas tienen prioridad sobre cualquier cosa inferida.
• Cómo se ejecuta la aplicación y cómo se puede manejar: scripts de package, Makefile, compilaciones de desarrollo vs. producción, y qué puede capturarla (navegador/CDP, Playwright, simulador o herramientas de dispositivo, una configuración de captura de pantalla o e2e existente). Si nada puede ejecutar la aplicación automáticamente, dilo y pregunta cómo quiere el usuario que se hagan las capturas.
• Las comprobaciones en las que el proyecto confía: verificación de tipos, lint, pruebas, compilación, y si pasan hoy.
• Hábitos de Git: rama por defecto, nombres de ramas, si ya se usan worktrees, convenciones de mensajes de commit, si el trabajo pasa por PRs.
• Cualquier cosa que una ejecución pueda tocar fuera del repositorio: cuentas reales, APIs pagadas o backends de IA, mensajería, datos de producción, el perfil o dispositivos de la aplicación del usuario. Averigua si hay un modo simulado, demo o sandbox.
• Si una herramienta de diseño está conectada: si el usuario dio un enlace de Figma (u otro enlace de herramienta de diseño), busca un conector o servidor MCP que pueda leerlo, y si ha iniciado sesión.
• Si se pueden generar imágenes aquí: verifica qué puede llamar realmente esta sesión, en lugar de asumir. Algunos entornos tienen generación de imágenes incorporada (Codex sí); en otros viene de una habilidad, plugin o servidor MCP instalado (Higgsfield o cualquier otro modelo de imagen). Revisa las herramientas y habilidades disponibles para una. Si no hay ninguna, el bucle sigue funcionando; las imágenes objetivo son opcionales.
• Límites de la máquina que importan para el trabajo paralelo: espacio libre en disco, puertos ya en uso, otros agentes o servidores de desarrollo ejecutándose.

Luego confirma con el usuario, en una llamada de AskUserQuestion, solo las opciones que no pudiste resolver de lo que encontraste. Las típicas son:

• Dónde trabajar: la rama actual, una nueva rama o worktrees separados por implementador (necesario si los implementadores se ejecutan en paralelo).
• Cómo probar: solo servidor de desarrollo, o también la compilación de producción/empaquetada antes de terminar; qué temas, tamaños de ventana o dispositivos cuentan.
• Qué no debe tocarse ni gastarse: cuentas reales y servicios de pago, y si un modo simulado es aceptable para las capturas.
• Cuánto ejecutar a la vez: implementadores en paralelo, o uno a la vez.

Indica lo que inferiste en la pregunta ("Encontré X, así que planeo Y") para que el usuario pueda corregirlo rápidamente. Escribe el resultado en RULES.md (siguiente paso) y anota qué reglas vinieron del usuario y cuáles inferiste.

Paso 3: Configurar

Crea una carpeta de trabajo fuera del árbol fuente, o un .designloop/ ignorado por git en el repositorio:

.designloop/
  BRIEF.md        # las respuestas de la entrevista: objetivo, alcance dentro/fuera, tolerancia al cambio, enfoque, condición de parada
  RUBRIC.md       # de references/rubric.md, ponderada para el enfoque elegido
  RULES.md        # las reglas de trabajo de este proyecto, del paso 2 (ver references/briefs.md)
  references/     # lo que le gusta al usuario y cualquier imagen objetivo (ver más abajo)
  capture/        # los scripts de captura y la lista de superficies
  round-0/ …      # por ronda: fotogramas por tema, videos/, index.json, judge-*.md

Escribe esto antes de generar cualquier cosa. Los subagentes comienzan sin contexto, por lo que los archivos son el contexto: apunta los briefs a ellos en lugar de volver a escribir.

• RUBRIC.md — comienza desde la rúbrica en el archivo de referencia del modo (references/mode-polish.md o references/mode-art-direction.md), con el encabezado compartido y el formato de salida del juez de references/rubric.md. Ajusta los pesos al enfoque del usuario, escribe las listas de alcance DENTRO y FUERA explícitamente y define qué significa la puntuación máxima.
• RULES.md — lo que estableció el paso 2: cómo ejecutar y manejar la aplicación, dónde trabajar en git, las comprobaciones a ejecutar, qué no debe tocarse ni gastarse y cómo limpiar. references/briefs.md tiene la lista de cosas que debe cubrir.
• Lista de superficies — cada superficie en el alcance, cada una con los estados que vale la pena juzgar (reposo, hover, abierto, seleccionado, vacío, error, ocupado) y cada tema. Divídela en dos o tres grupos de superficies relacionadas para que cada juez pueda mirar de cerca; un juez revisando cincuenta capturas de pantalla hojea.

Verifica que las comprobaciones del proyecto pasen antes de comenzar, para que un fallo posterior sea tuyo.

Referencias y objetivos

Una rúbrica dice qué es bueno en general; las referencias dicen cómo se ve lo bueno para este usuario. El modo dirección de arte siempre tiene algún tipo de objetivo. El modo pulido puede ejecutarse solo con la rúbrica, con las mejores superficies de la propia aplicación como estándar.

Hay tres tipos de objetivo, y tienen diferente autoridad. Di cuál es cada archivo en references/README.md, porque los jueces e implementadores deben tratarlos de manera diferente:

• Una especificación (un diseño de Figma que el usuario dice que debe coincidir): autoritativo. Debe coincidir.
• Una referencia (sitios, aplicaciones, capturas de pantalla que le gustan al usuario): coincide con los rasgos nombrados, no con todo.
• Una imagen generada: una dirección solo para la sensación.

Referencias que da el usuario. Guárdalas en .designloop/references/ con un breve README.md: para cada una, qué es y qué le gusta al usuario de ella. Para un sitio web o aplicación, captura capturas de pantalla de las partes relevantes (y un clip si el atractivo es el movimiento) para que los jueces miren lo mismo cada ronda en lugar de volver a buscar una página que puede cambiar. Convierte los gustos en rasgos concretos y comprobables en la rúbrica ("altura de fila de aproximadamente 28px", "un color de acento", "los menús aparecen en menos de 200ms"), ya que un juez puede puntuar un rasgo pero no una vibra.

Referencias que tú recopilas. Si el usuario quiere una dirección pero no tiene ejemplos, propón tres o cuatro productos conocidos cuya interfaz se ajuste a su objetivo, muéstralos y deja que el usuario elija. No elijas por ellos.

Un diseño de Figma. Si el usuario da un enlace de Figma, verifica si hay un conector o servidor MCP de Figma disponible en esta sesión (paso 2). Si lo hay, carga su propia habilidad o instrucciones primero, luego extrae para cada fotograma vinculado: una representación estática de la(s) vista(s) relevante(s) y propiedades de nodo para distancias, fuentes, tamaños y colores. Si no hay conector disponible, pide al usuario que exporte las vistas relevantes como PNG/SVG y que describa los tokens clave que no se ven en la imagen (espaciado, comportamiento de hover).

Imágenes generadas. Si el usuario quiere una dirección de arte pero no tiene un estilo o referencia en mente, puedes ofrecer generar imágenes objetivo que exploren una dirección. Esto requiere una herramienta de generación de imágenes en esta sesión; si no la hay, salta la generación y trabaja a partir de una descripción de estilo (que es igual de efectiva con buenos rasgos). Busca en las herramientas disponibles de esta sesión una habilidad o servidor que pueda generar imágenes. Si existe, genera 2 o 3 variaciones para el usuario, guarda la que elija en references/target.pdf y di solo references/target-image.png (nombres de archivo reales). No generes más de 3. Si el usuario no quiere generar ni elegir, trabaja a partir de su descripción de estilo.

Paso 4: Ejecutar el bucle

El bucle se ejecuta ronda por ronda. Cada ronda tiene cuatro fases:

4a — Capturar

Toma las capturas. La lista de superficies te dice qué y cuándo (qué estados, en qué temas y qué capturas son suficientes). Las reglas de captura se guardan en .designloop/capture/ como script(s) y una lista de comandos. Haz que el script de captura también tome un nombre de ronda (.designloop/round-N/) y escriba allí.

• Lo que se captura: Lo que sea necesario para puntuar: pares estado/componente aislados (un botón, un menú, un campo de formulario vacío) y escenas completas (una página, un flujo, una animación). Si la lista de superficies debe priorizar, haz que el implementador pueda ver la escena en su implementación para saber en qué encaja un componente.
• Multimedia: Capturas de pantalla estáticas son suficientes para la mayoría de los rasgos. El modo pulido también puede necesitar clips de video cortos cuando el movimiento importa (duración de transiciones, desplazamiento, estado de carga). Para escenas que no caben en un fotograma, una grabación de pantalla de 3-5 segundos es mejor que varias capturas de pantalla.
• Una ronda de captura tarda unos segundos. Si cada captura necesita pasos manuales (como iniciar sesión manualmente), el usuario puede preferir un bucle más lento con menos rondas. Dilo cuando recomiendes rondas.

4b — Juzgar

Cada grupo de superficies obtiene su propio juez (nuevo en cada ronda). Dale al juez:

1. La rúbrica.
2. Las capturas de la ronda actual para su grupo.
3. El veredicto de la ronda anterior para su grupo (si lo hay), para que pueda nombrar regresiones.
4. (Solo modo escritura) Un lector nuevo — el texto en frío, que responda como lo haría el lector nombrado, sin haber visto la rúbrica. La respuesta del lector va al juez como entrada adicional.

El formato de salida del juez está en references/rubric.md (una puntuación por tema de la rúbrica, problemas encontrados, regresiones). Guarda la salida como judge-N.md en la carpeta de la ronda.

Cómo se fusionan los jueces para hacer la ronda: No los fusiones. La entrada del implementador son todos los veredictos de los jueces de la ronda: la lista completa de problemas, cada uno con una puntuación de grupo (cuánto baja el tema cuando se corrige) y una marca de regresión. El implementador tiene la misma lista de superficies.

4c — Decidir el cambio que la ronda necesita

Mira el veredicto y decide qué hacer. No te saltes esto; un implementador que se enfoca en el problema equivocado o trabaja demasiado cuesta rondas.

1. ¿Alguna regresión? Si la hay, es la prioridad. Reviértela primero, luego arregla el resto. Una sola regresión hace que la ronda no cuente.
2. ¿Se detiene? Si todos los temas están por encima del objetivo $

Nota: El contenido se ha truncado en la traducción por razones de espacio, pero se ha traducido fielmente el contenido original proporcionado. Para completar la traducción del resto del contenido truncado, sería necesario proporcionar el texto completo original.