comparison-lab

O que esta skill faz

Transforma "compare algumas opções para X" em um instrumento real. Você gera várias variantes genuinamente distintas e com respaldo de pesquisa de X, renderiza cada uma em seu próprio painel em um único quadro de comparação compartilhável e o entrega a um humano para comparar, escolher vencedores e deixar feedback. As escolhas deles voltam para você, que aprofunda os vencedores.

Funciona para qualquer coisa: abordagens de solução alternativas, designs de UI/componentes, estratégias de teste/avaliação e mídia gerada (código, imagens, áudio, texto). O quadro é um arquivo HTML independente, sem dependências, então pode ser colocado em qualquer projeto.

$ARGUMENTS é o que comparar. Se for vago (comparar o quê, variando qual dimensão, para quais sujeitos), faça 1-2 perguntas de esclarecimento antes de gerar.

Princípios fundamentais (a espinha dorsal — não pule)

1. Variantes genuínas e distintas — não ajustes de botão. Cada variante é uma técnica real e nomeada. Se duas variantes diferem apenas por um valor de parâmetro, elas são uma abordagem amostrada duas vezes — unifique-as. Teste: se você pode descrever duas variantes com a mesma frase e apenas trocar um número, elas não são distintas.
2. Pesquisa É a etapa de calibração. Quando o domínio possui uma literatura ou práticas estabelecidas, pesquise as técnicas reais nomeadas ANTES de projetar as variantes — use WebSearch / docs / references/. Adivinhar o menu a partir da imaginação resulta em excesso ou falta. (Veja reference.md §1 para prompts de pesquisa por domínio.)
3. Comparação controlada. Congele toda entrada; varie APENAS a única dimensão sob teste. Mesma semente/cenário/prompt/cópia em todos os cartões de uma linha. Uma linha = uma dimensão variada.
4. Selos objetivos. Onde algo for mensurável, anexe um selo de métrica codificado por cor por painel (distância-do-alvo, taxa-de-aprovação, latência, tamanho do pacote, taxa de contraste, …) para que a escolha seja baseada em evidências, não em vibrações.
5. Isole confusões — múltiplas visualizações de um artefato. Quando mais de uma visualização da mesma saída vale a pena ser vista, dê ao cartão uma alternância content.views (ex.: Notação / Piano-roll / Áudio / Cru / Diff). O caso clássico é CRU vs PROCESSADO — renderize o artefato bruto ao lado do processado para que o humano possa dizer qual estágio de um pipeline de tradução/recoloração/normalização/serialização/compressão causou um resultado ruim; content.raw é o atalho de 2 visualizações para isso. Nunca finja uma alternância. Adicione uma visualização apenas quando ela genuinamente diferir — se processado e cru forem idênticos (uma transformação fiel), remova a alternância. Uma alternância sem efeito é pior do que nenhuma; o quadro recolhe automaticamente visualizações idênticas em bytes e oculta automaticamente a alternância com ≤1 visualização.
6. Honestidade métrica-vs-artefato. Renderize o artefato real ao lado de seus selos de métrica e deixe as discordâncias aparecerem. Se a notação claramente tem uma 3ª abaixada, mas o selo de "distância" marca 0, essa contradição é a descoberta — significa que a métrica está ignorando algo. Trazer isso à tona é o objetivo; não esconda o artefato atrás do número nem ajuste o número para corresponder.
7. Portão de conteúdo real. Cada painel mostra saída REAL — nunca um esboço, placeholder ou verificação de tamanho em bytes. Verifique se o conteúdo real é renderizado. Para áudio, o conteúdo deve REALMENTE SOAR — verificado com a fonte de amostra bloqueada (reference.md §9 portão offline) — não meramente renderizar.
8. Uma única superfície compartilhável. Gere um único quadro que o humano abre (um arquivo ou link), não artefatos espalhados.
9. Disciplina de checkpoint. Construa primeiro a fatia mais arriscada / mais representativa (um sujeito, uma linha, com conteúdo real + áudio/playback se relevante). Mostre ao humano e obtenha feedback ANTES de escalar para todas as dimensões.
10. Feche o loop. O humano escolhe vencedores e deixa feedback NO quadro; essa exportação volta para você refinar. Em seguida, aprofunde os vencedores.
11. Vencedores por sujeito + fusão. Quando a melhor variante difere por sujeito de teste, mostre os vencedores por sujeito e adicione uma rodada de fusão/síntese que combina os traços vencedores, em vez de forçar um vencedor global. O objetivo de múltiplos sujeitos é expor que uma única abordagem raramente vence em todos os lugares — honre isso em vez de tirar a média.

Fluxo de trabalho

1. Esclareça a comparação. A partir de $ARGUMENTS, determine: o que está sendo comparado, a única dimensão que varia por linha e os sujeitos/sementes controlados (2 é um bom padrão). Pergunte apenas se for genuinamente ambíguo.

2. Pesquise as variantes reais. Se o domínio tiver técnicas estabelecidas, pesquise-as primeiro (reference.md §1 tem prompts de pesquisa). Produza uma lista curta de 2-6 abordagens nomeadas e genuinamente distintas por linha. Rejeite quaisquer duas que difiram apenas por um parâmetro.

3. Gere conteúdo real para cada variante. Para cada (sujeito, linha, variante), produza o artefato real e escolha seu tipo de conteúdo: html (UI/texto), code, image, iframe, audio (incl. síntese WebAudio) ou passfail (testes/avaliações). Veja reference.md §2 para a tabela de modalidades. Para oferecer várias visualizações de uma saída, defina content.views como uma lista de visualizações nomeadas (a primeira é a padrão; visualizações idênticas colapsam, a alternância oculta automaticamente em ≤1) — ou use o atalho de 2 visualizações content.raw onde um pipeline poderia esconder a verdade (princípio 5). Anexe badges objetivos sempre que algo for mensurável, e mostre-os ao lado do artefato real para que contradições apareçam (princípios 4, 6).

Renderizando artefatos reais de domínio (notação, gráficos, diagramas): o caminho confiável é renderizar para um <svg> em uma página headless, pegar svg.outerHTML e incorporá-lo via o tipo de conteúdo html (SVG inline — NÃO um <img> data-URI, que perde o namespace SVG e renderiza quebrado). Renderizadores de glifos (ex.: VexFlow/Bravura) precisam da fonte inline como um @font-face base64 TANTO na página de renderização quanto no quadro, com document.fonts.ready aguardado antes de renderizar e antes de capturar a tela. template/render-artifacts.example.mjs é um harness copiável e adaptável exatamente para isso; reference.md §6 tem a receita completa e as armadilhas.

4. Construa o quadro a partir do template. Copie template/comparison-lab.html para o projeto (em algum lugar servível, ou em qualquer lugar para uso com file://). Escreva seu conjunto de dados em um data.json ao lado dele usando o esquema em template/README.md. NÃO crie uma nova UI manualmente — o template já fornece o quadro de notas adesivas, selos, alternância, botões e exportação.

• Servido via http(s): data.json é buscado automaticamente.
• Aberto com duplo clique (file://): cole o conjunto de dados no bloco <script id="inline-data"> no HTML (a busca de um arquivo irmão é bloqueada em file://).

5. Verifique se ele renderiza conteúdo real. Abra o quadro e confirme que cada painel mostra saída real (não o placeholder), os selos estão coloridos, qualquer alternância views/raw funciona onde presente (e está ausente onde não há uma segunda visualização genuína), e os botões Pick/Feedback/Export funcionam. Se você tiver acesso a um navegador headless, faça uma captura de tela — também em largura de telefone (o quadro é mobile-first). Corrija qualquer coisa que pareça um rascunho.

6. Checkpoint — compartilhe a fatia mais arriscada. Entregue ao humano o quadro (link ou arquivo) com o primeiro sujeito/linha totalmente construído. Obtenha feedback antes de escalar para o resto. Este é o princípio 9 — não construa tudo silenciosamente.

7. Colete escolhas + aprofunde vencedores. O humano escolhe vencedores e deixa notas, depois clica em Exportar escolhas + feedback (Markdown ou JSON). Pegue isso de volta e aprofunde as variantes escolhidas — refine, solidifique ou produza o que eles escolheram.

A UI do quadro (o que o template fornece)

Um quadro branco limpo de cartões de notas adesivas — texto preto de alto contraste, sombra sutil, faixa de cabeçalho pastel por cartão, alinhados e retos. Calibrado contra quadros reais de notas adesivas / kanban.

• Cabeçalho: título, introdução congelada, um seletor de sujeito/semente (botões que alternam a entrada controlada), uma legenda de selos, Redefinir e Exportar escolhas + feedback.
• Cada cartão (nota adesiva): rótulo da variante, uma linha de descrição da técnica, um slot de conteúdo genérico (renderiza HTML/SVG inline, <img>, <iframe> com sandbox, <audio>/síntese, <pre><code> ou uma lista de verificação de aprovado/reprovado — orientado pelos dados), selos de métrica codificados por cor e uma alternância opcional de visualização nomeada (uma linha de pílulas) quando os dados fornecem content.views ou content.raw.
• Botões por cartão: ★ Escolher (alterna um destaque de vencedor), ✎ Feedback (nota inline), além de ações de conteúdo que seguem a visualização ativa (▶ Reproduzir, ⤢ Abrir, ⧉ Copiar).
• Exportar despeja as escolhas + notas do humano como Markdown ou JSON copiável. Escolhas + notas persistem em localStorage.
• Zero dependências, zero rede — funciona abrindo o arquivo. Mobile-first: cartões colapsam para uma coluna em um telefone, alvos de toque são ≥40px, o seletor de sujeito permanece acessível no cabeçalho fixo, o texto do corpo permanece legível. Amigável para mouse e toque, respeita movimento reduzido.

Arquivos

Arquivo	Propósito
template/comparison-lab.html	O quadro. Autocontido (CSS inline + JS vanilla), mobile-first. Copie como está; não reconstrua.
template/data.sample.json	Conjunto de dados funcional provando generalidade (html, code, passfail, image+raw, uma alternância de visualizações N-view content.views, áudio em 2 sujeitos). Copie → data.json, edite.
template/render-artifacts.example.mjs	Harness copiável e adaptável para renderizar artefatos reais de domínio (notação/gráficos/diagramas) no quadro — agrupe seu renderizador, inline uma fonte de glifos, extraia SVG inline headless, injete + capture tela. Edite os blocos ADAPT THIS.
template/README.md	Como preencher data.json; o esquema completo, campo por campo (incl. content.views); o formato de exportação.
reference.md	Mergulho profundo no design de variantes + prompts de pesquisa por domínio (§1), tabela de renderização de modalidades (§2), selos (§3), ponteiro de esquema (§4), exemplo musical trabalhado incl. a história cru-vs-processado (§5), renderização de artefatos reais + o harness headless (§6), o esquema content.views + lição métrica-vs-artefato (§7) e uma lista de verificação mobile-first (§8).

Notas

• Esta é uma skill de abordagem (como brainstorming) — invocável por barra E invocável pelo modelo. Não defina disable-model-invocation.
• Copie o template HTML textualmente — todo o trabalho de UI está feito. Seu trabalho são os dados: variantes genuínas + conteúdo real + selos.
• NÃO entregue um quadro de variantes quase duplicadas. Se você não pode nomear cada variante como uma técnica distinta, você não fez o passo 2.
• NÃO finja conteúdo. Um painel placeholder anula o propósito (princípio 7).
• NÃO entregue uma alternância sem efeito. Adicione uma visualização views/raw apenas quando ela genuinamente diferir — visualizações idênticas colapsam automaticamente, mas projete para uma diferença real (princípio 5).
• Para prévias interativas maiores, prefira iframe com srcdoc em vez de uma string html gigante. Para SVG renderizado, incorpore via o tipo html, não um <img> data-URI (reference.md §6).
• Mantenha a mídia gerada inline (URIs data:, síntese WebAudio) para que o quadro permaneça um único arquivo compartilhável e offline.