comparison-lab

---

name: comparison-lab description: Úsalo cuando alguien pida una prueba A/B, comparar enfoques/diseños/opciones/variantes, construir un tablero de comparación o laboratorio de comparación, elegir la mejor de varias soluciones, o evaluar varias soluciones lado a lado. Genera variantes genuinamente distintas y respaldadas por investigación de cualquier cosa — enfoques de solución, diseños de UI/componentes, estrategias de prueba/evaluación, medios generados (código, imágenes, audio, texto) — y renderiza cada una como una tarjeta tipo post-it en un tablero compartible con insignias objetivas, un bucle de selección + retroalimentación, y un conmutador crudo-vs-procesado para aislar confusiones en el pipeline. Disparadores: "prueba A/B", "comparar", "laboratorio de comparación", "lado a lado", "variantes", "qué enfoque/diseño/opción", "elegir el mejor", "evaluar opciones". argument-hint: [qué comparar]

Qué hace esta habilidad

Convierte "compara algunas opciones para X" en un instrumento real. Generas varias variantes genuinamente distintas y respaldadas por investigación de X, renderizas cada una en su propio panel en un tablero de comparación compartible, y se lo entregas a un humano para que compare, elija ganadores y deje comentarios. Sus elecciones vuelven a ti y profundizas los ganadores.

Funciona para cualquier cosa: enfoques de solución alternativos, diseños de UI/componentes, estrategias de prueba/evaluación y medios generados (código, imágenes, audio, texto). El tablero es un archivo HTML independiente sin dependencias, por lo que se integra en cualquier proyecto.

$ARGUMENTS es qué comparar. Si es vago (comparar qué, variando qué dimensión, para qué sujetos), haz 1-2 preguntas de precisión antes de generar.

Principios fundamentales (la columna vertebral — no los omitas)

1. Variantes genuinas y distintas — no ajustes de perilla. Cada variante es una técnica real y nombrada. Si dos variantes difieren solo por un valor de parámetro, son un enfoque muestreado dos veces — fúndelos. Prueba: si puedes describir dos variantes con la misma oración y solo intercambiar un número, no son distintas.
2. La investigación ES el paso de calibración. Cuando el dominio tiene una literatura o prácticas establecidas, investiga las técnicas reales NOMBRADAS ANTES de diseñar variantes — usa WebSearch / docs / references/. Adivinar el menú desde la imaginación sobrepasa o subestima. (Ver reference.md §1 para indicaciones de investigación por dominio).
3. Comparación controlada. Congela cada entrada; varía SOLO la dimensión bajo prueba. Misma semilla/escenario/indicación/copia en cada tarjeta de una fila. Indica las entradas congeladas en el objetivo de la fila. Una fila = una dimensión variada.
4. Insignias objetivas. Donde algo sea medible, adjunta una insignia de métrica codificada por color por panel (distancia-del-objetivo, tasa-de-aprobación, latencia, tamaño-del-bundle, relación-de-contraste, …) para que la elección se base en evidencia, no en sensaciones.
5. Aísla confusiones — múltiples vistas de un artefacto. Cuando vale la pena ver más de una vista de la misma salida, dale a la tarjeta un conmutador content.views (por ejemplo, Notación / Piano-roll / Audio / Crudo / Diff). El caso clásico es CRUDO vs PROCESADO — renderiza el artefacto crudo junto al procesado para que el humano pueda saber qué etapa de un pipeline de traducir/recolorizar/normalizar/serializar/comprimir causó un mal resultado; content.raw es el atajo de 2 vistas para ello. Nunca falsifiques un conmutador. Solo agrega una vista cuando genuinamente difiera — si procesado y crudo resultan idénticos (una transformación fiel), elimina el conmutador. Un conmutador sin efecto es peor que ninguno; el tablero colapsa automáticamente las vistas byte-idénticas y oculta automáticamente el conmutador cuando hay ≤1 vista.
6. Honestidad métrica-vs-artefacto. Renderiza el artefacto real junto a sus insignias de métrica y deja que los desacuerdos se muestren. Si la notación claramente tiene una 3ª disminuida pero la insignia de "distancia" marca 0, esa contradicción es el hallazgo — significa que la métrica está ignorando algo. Sacarlo a la luz es el punto; no escondas el artefacto detrás del número ni ajustes el número para que coincida.
7. Puerta de contenido real. Cada panel muestra salida REAL — nunca un marcador de posición, placeholder o verificación de tamaño de byte. Verifica que el contenido real se renderice. Para audio, el contenido debe SONAR realmente — verificado con la fuente de muestra bloqueada (reference.md §9 puerta fuera de línea) — no solo renderizarse.
8. Una superficie compartible. Produce un solo tablero que el humano abre (un archivo o enlace), no artefactos dispersos.
9. Disciplina de checkpoint. Construye primero la porción más riesgosa / representativa (un sujeto, una fila, con contenido real + audio/reproducción si corresponde). Muestra al humano y obtén retroalimentación ANTES de escalar a cada dimensión.
10. Cierra el bucle. El humano elige ganadores y deja comentarios EN el tablero; esa exportación vuelve a ti para refinar. Luego profundiza los ganadores.
11. Ganadores por sujeto + fusión. Cuando la mejor variante difiere por sujeto de prueba, muestra los ganadores por sujeto y agrega una ronda de fusión/síntesis que combine los rasgos ganadores, en lugar de forzar un ganador global. El punto de múltiples sujetos es exponer que un solo enfoque rara vez gana en todas partes — respeta eso en lugar de promediarlo.

Flujo de trabajo

1. Clarifica la comparación. A partir de $ARGUMENTS, precisar: qué se compara, la única dimensión que varía por fila, y los sujetos/semillas controlados (2 es un buen valor predeterminado). Pregunta solo si es genuinamente ambiguo.

2. Investiga las variantes reales. Si el dominio tiene técnicas establecidas, búscalas primero (reference.md §1 tiene indicaciones de investigación). Produce una lista corta de 2-6 enfoques nombrados y genuinamente distintos por fila. Rechaza dos que difieran solo por un parámetro.

3. Genera contenido real para cada variante. Para cada (sujeto, fila, variante), produce el artefacto real y elige su tipo de contenido: html (UI/texto), code, image, iframe, audio (incl. síntesis WebAudio), o passfail (pruebas/evaluaciones). Ver reference.md §2 para la tabla de modalidades. Para ofrecer varias vistas de una misma salida, establece content.views a una lista de vistas nombradas (la primera es la predeterminada; las vistas idénticas colapsan, el conmutador se oculta automáticamente con ≤1) — o usa el atajo de 2 vistas content.raw donde un pipeline podría ocultar la verdad (principio 5). Adjunta badges objetivos donde algo sea medible, y muéstralos junto al artefacto real para que las contradicciones surjan (principios 4, 6).

Renderizar artefactos reales de dominio (notación, gráficos, diagramas): el camino confiable es renderizar a un <svg> en una página headless, tomar svg.outerHTML, e incrustarlo a través del tipo de contenido html (SVG en línea — NO un <img> data-URI, que pierde el espacio de nombres SVG y renderiza roto). Los renderizadores de glifos (por ejemplo, VexFlow/Bravura) necesitan la fuente incrustada como @font-face en base64 TANTO en la página de renderizado como en el tablero, con document.fonts.ready esperado antes de renderizar y antes de capturar la pantalla. template/render-artifacts.example.mjs es un harness para copiar y adaptar exactamente para esto; reference.md §6 tiene la receta completa y los problemas comunes.

4. Construye el tablero a partir de la plantilla. Copia template/comparison-lab.html al proyecto (en algún lugar servible, o en cualquier lugar para uso file://). Escribe tu conjunto de datos en un data.json junto a él usando el esquema en template/README.md. NO construyas una nueva UI desde cero — la plantilla ya incluye el tablero de post-it, insignias, conmutador, botones y exportación.

• Servido sobre http(s): data.json se obtiene automáticamente.
• Abierto con doble clic (file://): pega el conjunto de datos en el bloque <script id="inline-data"> en el HTML (la obtención de un archivo hermano está bloqueada en file://).

5. Verifica que renderiza contenido real. Abre el tablero y confirma que cada panel muestra salida real (no el marcador de posición), las insignias están coloreadas, cualquier conmutador views/raw funciona donde está presente (y está ausente donde no hay una segunda vista genuina), y Pick/Feedback/Export funcionan. Si tienes acceso a un navegador headless, haz una captura de pantalla — también en un ancho de teléfono (el tablero es móvil primero). Arregla cualquier cosa que parezca un borrador.

6. Checkpoint — comparte la porción más riesgosa. Entrega al humano el tablero (enlace o archivo) con la primera fila/sujeto completamente construida. Obtén retroalimentación antes de escalar al resto. Este es el principio 9 — no construyas todo en silencio.

7. Recoge selecciones + profundiza ganadores. El humano elige ganadores y deja notas, luego hace clic en Exportar selecciones + comentarios (Markdown o JSON). Toma eso y profundiza las variantes elegidas — refina, solidifica o productiza lo que eligieron.

La UI del tablero (lo que incluye la plantilla)

Un tablero blanco limpio de tarjetas tipo post-it — texto negro de alto contraste, sombra sutil, franja de encabezado pastel por tarjeta, rectas y alineadas. Calibrado contra tableros kanban / post-it reales.

• Encabezado: título, introducción congelada, un selector de sujeto/semilla (botones que cambian la entrada controlada), una leyenda de insignias, Restablecer, y Exportar selecciones + comentarios.
• Cada tarjeta (post-it): etiqueta de variante, una línea de descripción de técnica, un espacio de contenido genérico (renderiza HTML/SVG en línea, <img>, <iframe> con sandbox, <audio>/síntesis, <pre><code>, o una lista de verificación pasa/falla — impulsado por los datos), insignias de métrica codificadas por color, y un conmutador de vista nombrado opcional (una fila de píldoras) cuando los datos proporcionan content.views o content.raw.
• Botones por tarjeta: ★ Elegir (alterna un resaltado de ganador), ✎ Comentario (nota en línea), más acciones de contenido que siguen la vista activa (▶ Reproducir, ⤢ Abrir, ⧉ Copiar).
• Exportar vuelca las selecciones del humano + notas como Markdown o JSON copiable. Las selecciones + notas persisten en localStorage.
• Cero dependencias, cero red — funciona abriendo el archivo. Móvil primero: las tarjetas colapsan a una columna en un teléfono, los objetivos táctiles son ≥40px, el selector de sujeto permanece accesible en el encabezado fijo, el texto del cuerpo sigue siendo legible. Amigable con mouse y táctil, respeta prefers-reduced-motion.

Archivos

Archivo	Propósito
template/comparison-lab.html	El tablero. Autocontenido (CSS en línea + JS vanilla), móvil primero. Cópialo tal cual; no lo reconstruyas.
template/data.sample.json	Conjunto de datos funcional que demuestra generalidad (html, code, passfail, image+raw, un conmutador content.views de N vistas, audio en 2 sujetos). Copia → data.json, edita.
template/render-artifacts.example.mjs	Harness para copiar y adaptar para renderizar artefactos reales de dominio (notación/gráficos/diagramas) en el tablero — agrupa tu renderizador, incrusta una fuente de glifos, extrae SVG en línea headless, inyecta + captura pantalla. Edita los bloques ADAPT THIS.
template/README.md	Cómo poblar data.json; el esquema completo, campo por campo (incl. content.views); el formato de exportación.
reference.md	Inmersión profunda en diseño de variantes + indicaciones de investigación por dominio (§1), la tabla de renderizado de modalidades (§2), insignias (§3), puntero de esquema (§4), el ejemplo trabajado de música incl. la historia crudo-vs-procesado (§5), renderizado de artefactos reales + el harness headless (§6), el esquema content.views + lección métrica-vs-artefacto (§7), y una lista de verificación móvil primero (§8).

Notas

• Esta es una habilidad de enfoque (como la lluvia de ideas) — invocable con barra diagonal E invocable por el modelo. No establezcas disable-model-invocation.
• Copia la plantilla HTML textualmente — todo el trabajo de UI está hecho. Tu trabajo son los datos: variantes genuinas + contenido real + insignias.
• NO entregues un tablero de variantes casi duplicadas. Si no puedes nombrar cada variante como una técnica distinta, no has hecho el paso 2.
• NO falsifiques contenido. Un panel con marcador de posición anula el propósito (principio 7).
• NO entregues un conmutador sin efecto. Solo agrega una vista views/raw cuando realmente difiera — las vistas idénticas se colapsan automáticamente, pero diseña para una diferencia real (principio 5).
• Para vistas previas interactivas más grandes, prefiere iframe con srcdoc sobre una cadena html enorme. Para SVG renderizado, incrústalo a través del tipo html, no un <img> data-URI (reference.md §6).
• Mantén los medios generados en línea (data: URIs, síntesis WebAudio) para que el tablero siga siendo un solo archivo compartible sin conexión.