designloop

O que designloop faz?

Um loop que eleva a qualidade de uma interface existente, ou da escrita nela e ao seu redor, medindo-a, não adivinhando. A cada rodada: capture a UI (ou tire um instantâneo do texto) da mesma forma, tenha juízes frescos avaliando-a contra uma rubrica fixa, corrija o que encontraram e repita. É modelado no método de julgamento do dream-loop (um juiz novo a cada rodada, exigente, regressões pontuam mais baixo), aplicado ao polimento de UI em vez de corresponder a uma imagem alvo, e na abordagem de escalada de colina de Theo (t3.gg) para design de UI em Agents Sucked At UI (Until Today).

O loop funciona por causa de três separações. Mantenha-as:

• Juízes nunca implementam e implementadores nunca julgam. Um agente que escreveu a correção a avalia generosamente.
• Juízes são renovados a cada rodada. Um juiz que viu a rodada anterior ancora-se em seu próprio veredito anterior. Dê a um novo juiz a rubrica, as novas capturas e o veredito anterior (para que a pontuação permaneça consistente e as regressões sejam nomeadas), não a conversa.
• O conjunto de capturas é fixo. As pontuações só são comparáveis se a rodada N mostrar as mesmas superfícies, estados e temas que a rodada 0.

Três modos

O loop é o mesmo nos três; o que os juízes medem é diferente. Estabeleça o modo primeiro, porque ele decide a rubrica, as perguntas que vale a pena fazer e quanta mudança é esperada.

• Polimento profissional — uma passada objetiva, as coisas que um designer de produto sênior verifica: um conjunto de tokens e superfícies usado em todos os lugares, menos tamanhos e pesos de fonte, uma escala de espaçamento consistente, legibilidade e contraste, alvos de interação e zonas do cursor, cobertura de estados, paridade claro/escuro, qualidade de movimento. O alvo é o melhor eu do aplicativo; mudanças de gosto estão fora. Leia references/mode-polish.md.
• Direção de arte — uma passada subjetiva em direção a uma aparência e sensação específicas: um estilo nomeado ("realismo gráfico", "pop neon com arte ASCII e layouts brutais e dinâmicos"), um conjunto de referências, uma imagem alvo gerada ou um design do Figma para corresponder. Os juízes pontuam o quão bem a UI expressa essa direção. Espera-se uma mudança visual maior, então fontes, cor e caráter do layout estão em jogo. Leia references/mode-art-direction.md.
• Escrita — o loop aplicado a palavras: cópia de UI (rótulos, erros, estados vazios, onboarding), documentação e páginas de produto, ou peças independentes. Os juízes pontuam clareza, concisão, voz, consistência e precisão para um leitor nomeado, apoiados por testes de leitor (um agente novo lê o texto frio e diz o que faria). O significado permanece fixo; as palavras melhoram. Leia references/mode-writing.md, que diz como cada etapa abaixo muda (textos em vez de superfícies, instantâneos em vez de capturas, um glossário em vez de tokens).

Inferir o modo a partir da solicitação quando estiver claro ("apertar", "consistente", "descuidado" → polimento; "deixar parecido com", "mais artístico", um nome de estilo, um link do Figma → direção de arte; "cópia", "texto", "documentação", "mensagens de erro", "este post" → escrita), caso contrário, pergunte. Um usuário pode querer mais de um: execute a direção de arte primeiro para definir a aparência, depois uma passada de polimento para torná-la consistente e uma passada de escrita na cópia, cada uma como seu próprio loop com sua própria rubrica. Não os misture em uma rubrica, ou os juízes trocam consistência por estilo e as pontuações param de significar algo.

Etapa 1: Entrevistar o usuário

Estabeleça o modo e depois pergunte o restante com AskUserQuestion (duas chamadas; leva até quatro perguntas cada). Pule qualquer pergunta que a mensagem do usuário já respondeu e ofereça uma opção recomendada primeiro. As respostas vão para o arquivo de brief (etapa 3), que é o que cada subagente lê.

1. Objetivo — o que deve estar melhor quando isso estiver pronto, nas palavras deles? ("O Chrome parece inconsistente", "os menus estão descuidados", "parece travado".) Pergunte também o que está fora dos limites: superfícies que eles querem lidar sozinhos e quanta mudança eles aceitarão (apertar vs. reformular vs. redesenhar). A maioria dos usuários quer apertar, não um redesign; diga isso em cada brief ou os implementadores exagerarão.
2. Foco (seleção múltipla) — quais dimensões importam mais; isso define os pesos da rubrica. As opções dependem do modo e estão listadas em seu arquivo de referência (polimento: consistência e tokens, tipografia, espaçamento e layout, legibilidade, interação e alvos de interação, movimento, desempenho; direção de arte: as características da aparência escolhida e quais partes da UI devem carregá-la; escrita: clareza, concisão, estrutura, voz e tom, consistência, utilidade, precisão). No modo de escrita, pergunte também as perguntas extras em references/mode-writing.md (leitor e propósito, amostras de voz, o que é fixo, limites de comprimento e localização).
3. Baseline — onde está a UI hoje? Ou o usuário dá uma nota de 0 a 10, ou os juízes a pontuam primeiro. Recomende fazer ambos quando o usuário tem uma opinião: o número deles calibra os juízes (se eles dizem 6 e os juízes dizem 8, a rubrica está muito suave — aperte-a antes da rodada 1).
4. Condição de parada — uma nota alvo (ex.: ≥9/10 em cada grupo e tema), um número de rodadas ou o que ocorrer primeiro. Recomende "nota alvo, limitada a N rodadas". Avise que um loop sem limite pode usar muitos tokens.
5. Inteligência do subagente — qual modelo e esforço os juízes e implementadores executam. Ofereça: melhor disponível (mais lento, mais completo), equilibrado (modelo e esforço da própria sessão), rápido (modelo mais barato para captura e correções mecânicas, modelo forte para julgamento). Julgamento é onde a inteligência mais compensa; se o usuário quiser economizar, economize na captura e implementação mecânica primeiro.
6. Referências — eles têm designs que gostam ou devem corresponder? Sites, aplicativos, capturas de tela, um link do Figma, um sistema de design ou uma diretriz ou habilidade nomeada (um HIG da plataforma, uma habilidade de design-engenharia). Pergunte o que eles gostam em cada um (a densidade, os menus, o movimento), porque "gosto deste site" sem um motivo é copiado por completo. No modo de polimento, as referências são opcionais e geralmente diretrizes. No modo de direção de arte, o loop precisa de um alvo: uma descrição de estilo, referências, um design do Figma ou uma imagem gerada; se o usuário não tiver nenhum, ofereça-se para reunir ou gerar alguns (veja "Referências e alvos").
7. Entrega — apenas um branch, um PR (não mesclado) e/ou uma compilação que eles possam executar. Padrão: branch + PR não mesclado. Nunca mescle ou lance a menos que eles peçam.

Coloque tudo que o usuário lhe deu em .designloop/references/ (etapa 3) e liste-o na rubrica, para que cada juiz e implementador trabalhe a partir das mesmas fontes.

Etapa 2: Estudar a configuração do projeto

Antes de escrever quaisquer regras, descubra como este projeto é realmente executado, testado e enviado, para que o loop siga os hábitos do usuário em vez de impor os seus próprios. Olhe primeiro, pergunte depois: leia o que o repositório e a máquina podem lhe dizer, e só pergunte sobre o que ainda não está claro ou é uma questão de preferência.

Procure por:

• Instruções já escritas: CLAUDE.md / AGENTS.md, README e CONTRIBUTING, notas de memória e quaisquer arquivos de regras de agente anteriores. Estes prevalecem sobre qualquer coisa inferida.
• Como o aplicativo é executado e como pode ser dirigido: scripts de package, Makefile, compilações de desenvolvimento vs. produção e o que pode capturá-lo (navegador/CDP, Playwright, simulador ou ferramentas de dispositivo, uma configuração de captura de tela ou e2e existente). Se nada puder dirigir o aplicativo automaticamente, diga e pergunte como o usuário deseja que as capturas sejam feitas.
• As verificações em que o projeto confia: verificação de tipo, lint, testes, compilação e se passam hoje.
• Hábitos do Git: branch padrão, nomeação de branches, se worktrees já estão em uso, convenções de mensagens de commit, se o trabalho passa por PRs.
• Qualquer coisa que uma execução possa tocar fora do repositório: contas reais, APIs pagas ou backends de IA, mensagens, dados de produção, perfil do próprio aplicativo do usuário ou dispositivos. Descubra se há um modo de simulação, demonstração ou sandbox.
• Se uma ferramenta de design está conectada: se o usuário deu um link do Figma (ou outro link de ferramenta de design), procure por um conector ou servidor MCP que possa lê-lo e se ele está conectado.
• Se imagens podem ser geradas aqui: verifique o que esta sessão pode realmente chamar, em vez de assumir. Alguns harnesses têm geração de imagem embutida (Codex tem); em outros, ela vem de uma habilidade, plugin ou servidor MCP instalado (Higgsfield ou qualquer outro modelo de imagem). Procure nas ferramentas e habilidades disponíveis por um. Se não houver nenhum, o loop ainda funciona; imagens alvo são opcionais.
• Limites da máquina que importam para trabalho paralelo: espaço livre em disco, portas já em uso, outros agentes ou servidores de desenvolvimento em execução.

Em seguida, confirme com o usuário, em uma chamada AskUserQuestion, apenas as escolhas que você não conseguiu resolver a partir do que encontrou. As típicas são:

• Onde trabalhar: o branch atual, um novo branch ou worktrees separados por implementador (necessário se os implementadores executarem em paralelo).
• Como testar: apenas servidor de desenvolvimento, ou também a compilação de produção/empacotada antes de finalizar; quais temas, tamanhos de janela ou dispositivos contam.
• O que não deve ser tocado ou gasto: contas reais e serviços pagos, e se um modo de simulação é aceitável para capturas.
• Quanto executar de uma vez: implementadores em paralelo, ou um de cada vez.

Declare o que você inferiu na pergunta ("Encontrei X, então planejo Y") para que o usuário possa corrigir rapidamente. Escreva o resultado em RULES.md (próxima etapa) e anote quais regras vieram do usuário e quais você inferiu.

Etapa 3: Configurar

Crie uma pasta de trabalho fora da árvore de origem, ou um .designloop/ ignorado pelo git no repositório:

.designloop/
  BRIEF.md        # as respostas da entrevista: objetivo, escopo dentro/fora, tolerância a mudanças, foco, condição de parada
  RUBRIC.md       # de references/rubric.md, ponderado para o foco escolhido
  RULES.md        # as regras de trabalho deste projeto, da etapa 2 (veja references/briefs.md)
  references/     # o que o usuário gosta e quaisquer imagens alvo (veja abaixo)
  capture/        # o(s) script(s) de captura e a lista de superfícies
  round-0/ …      # por rodada: imagens estáticas por tema, vídeos/, index.json, judge-*.md

Escreva-os antes de gerar qualquer coisa. Subagentes começam sem contexto, então os arquivos são o contexto: aponte briefs para eles em vez de redigitar.

• RUBRIC.md — comece da rubrica no arquivo de referência do modo (references/mode-polish.md ou references/mode-art-direction.md), com o cabeçalho compartilhado e formato de saída do juiz de references/rubric.md. Ajuste os pesos para o foco do usuário, escreva as listas de escopo DENTRO e FORA explicitamente e defina o que a pontuação máxima significa.
• RULES.md — o que a etapa 2 estabeleceu: como executar e dirigir o aplicativo, onde trabalhar no git, as verificações a executar, o que não deve ser tocado ou gasto e como limpar. references/briefs.md tem a lista de coisas que deve cobrir.
• Lista de superfícies — cada superfície no escopo, cada uma com os estados que valem a pena julgar (repouso, hover, aberto, selecionado, vazio, erro, ocupado) e cada tema. Divida-a em dois ou três grupos de superfícies relacionadas para que cada juiz possa olhar de perto; um juiz em cinquenta capturas de tela superficializa.

Verifique se as verificações do projeto passam antes de começar, para que uma falha posterior seja sua.

Referências e alvos

Uma rubrica diz o que é bom em geral; as referências dizem como é o bom para este usuário. O modo de direção de arte sempre tem um alvo de algum tipo. O modo de polimento pode ser executado apenas com a rubrica, usando as melhores superfícies do próprio aplicativo como padrão.

Existem três tipos de alvo, e eles carregam autoridade diferente. Diga qual é cada arquivo em references/README.md, porque juízes e implementadores devem tratá-los de forma diferente:

• Uma especificação (um design do Figma que o usuário diz para corresponder): autoritativo. Corresponda a ele.
• Uma referência (sites, aplicativos, capturas de tela que o usuário gosta): corresponda às características nomeadas, não à coisa toda.
• Uma imagem gerada: uma direção apenas para a sensação.

Referências que o usuário dá. Salve-as em .designloop/references/ com um README.md curto: para cada uma, o que é e o que o usuário gosta nela. Para um site ou aplicativo, capture capturas de tela das partes relevantes (e um clipe se o apelo for movimento) para que os juízes olhem para a mesma coisa a cada rodada em vez de buscar novamente uma página que pode mudar. Transforme os gostos em características concretas e verificáveis na rubrica ("altura da linha cerca de 28px", "uma cor de destaque", "menus aparecem em menos de 200ms"), já que um juiz pode pontuar uma característica, mas não uma vibração.

Referências que você reúne. Se o usuário quiser uma direção, mas não tiver exemplos, proponha três ou quatro produtos conhecidos cuja interface se ajuste ao objetivo deles, mostre-os e deixe o usuário escolher. Não escolha por eles.

Um design do Figma. Se o usuário der um link do Figma, verifique se um conector ou servidor MCP do Figma está disponível nesta sessão (etapa 2). Se estiver, carregue sua própria habilidade ou instruções primeiro e, em seguida, puxe para cada quadro vinculado: uma reprodução...