designloop

Que fait designloop ?

Une boucle qui élève la qualité d'une interface existante, ou des textes qui l'entourent, en les mesurant plutôt qu'en devinant. À chaque tour : capture de l'UI (ou instantané du texte) de la même manière, faites évaluer par de nouveaux juges selon une rubrique fixe, corrigez ce qu'ils ont trouvé, répétez. Il est modélisé sur la méthode de jugement de dream-loop (un nouveau juge à chaque tour, pointilleux, les régressions obtiennent un score plus bas), appliquée au polissage d'UI au lieu de la correspondance à une image cible, et sur l'approche d'optimisation de Theo (t3.gg) pour le design d'interface dans Agents Sucked At UI (Until Today).

La boucle fonctionne grâce à trois séparations. Gardez-les :

• Les juges n'implémentent jamais et les implémenteurs ne jugent jamais. Un agent qui a écrit la correction la note généreusement.
• Les juges sont renouvelés à chaque tour. Un juge qui a vu le tour précédent s'ancre sur son propre verdict antérieur. Donnez à un nouveau juge la rubrique, les nouvelles captures et le verdict précédent (pour que les scores restent cohérents et que les régressions soient nommées), pas la conversation.
• L'ensemble de captures est fixe. Les scores ne sont comparables que si le tour N montre les mêmes surfaces, états et thèmes que le tour 0.

Trois modes

La boucle est la même dans les trois ; ce que les juges mesurent diffère. Fixez d'abord le mode, car il détermine la rubrique, les questions pertinentes et l'ampleur du changement attendu.

• Polissage professionnel — un passage objectif, ce qu'un designer produit senior vérifie : un ensemble unique de tokens et de surfaces utilisé partout, moins de tailles et de graisses de police, une échelle d'espacement cohérente, la lisibilité et le contraste, les cibles de clics et les zones de curseur, la couverture des états, la parité clair/sombre, la qualité des animations. La cible est la meilleure version de l'application elle-même ; les changements de goût sont exclus. Lisez references/mode-polish.md.
• Direction artistique — un passage subjectif vers un aspect et une sensation spécifiques : un style nommé ("réalisme graphique", "pop néon avec art ASCII et mises en page brutales et dynamiques"), un ensemble de références, une image cible générée, ou un design Figma à reproduire. Les juges notent à quel point l'UI exprime cette direction. Un changement visuel plus important est attendu, donc les polices, les couleurs et le caractère de la mise en page sont en jeu. Lisez references/mode-art-direction.md.
• Écriture — la boucle appliquée aux mots : textes d'interface (libellés, erreurs, états vides, onboarding), documentation et pages produit, ou articles autonomes. Les juges notent la clarté, la concision, la voix, la cohérence et l'exactitude pour un lecteur nommé, soutenus par des tests de lecture (un nouvel agent lit le texte à froid et dit ce qu'il ferait). Le sens reste fixe ; les mots s'améliorent. Lisez references/mode-writing.md, qui explique comment chaque étape ci-dessous change (textes au lieu de surfaces, instantanés au lieu de captures, un glossaire au lieu de tokens).

Déduisez le mode de la demande quand elle est claire ("resserre", "cohérent", "bâclé" → polissage ; "fais-le ressembler à", "plus artistique", un nom de style, un lien Figma → direction artistique ; "texte", "formulation", "doc", "messages d'erreur", "cet article" → écriture), sinon demandez. Un utilisateur peut en vouloir plusieurs : exécutez d'abord la direction artistique pour définir l'apparence, puis un passage de polissage pour la rendre cohérente, et un passage d'écriture sur le texte, chacun comme sa propre boucle avec sa propre rubrique. Ne les mélangez pas dans une seule rubrique, ou les juges échangent la cohérence contre le style et les scores cessent de vouloir dire quoi que ce soit.

Étape 1 : Interroger l'utilisateur

Fixez le mode, puis demandez le reste avec AskUserQuestion (deux appels ; il faut jusqu'à quatre questions chacun). Ignorez toute question à laquelle le message de l'utilisateur a déjà répondu, et proposez d'abord une option recommandée. Les réponses vont dans le fichier brief (étape 3), que chaque sous-agent lit.

1. Objectif — qu'est-ce qui devrait être meilleur quand ce sera fait, dans leurs mots ? ("Chrome semble incohérent", "les menus sont bâclés", "ça semble saccadé"). Demandez aussi ce qui est interdit : les surfaces qu'ils veulent gérer eux-mêmes, et combien de changement ils acceptent (resserrer vs. restyler vs. reconcevoir). La plupart des utilisateurs veulent resserrer, pas une refonte ; dites-le dans chaque brief ou les implémenteurs dépasseront les bornes.
2. Focus (sélection multiple) — quelles dimensions importent le plus ; cela définit les poids de la rubrique. Les options dépendent du mode et sont listées dans son fichier de référence (polissage : cohérence et tokens, typographie, espacement et mise en page, lisibilité, interaction et cibles de clics, animations, performances ; direction artistique : les traits du look choisi, et quelles parties de l'UI devraient le porter ; écriture : clarté, concision, structure, voix et ton, cohérence, utilité, exactitude). En mode écriture, demandez aussi les questions supplémentaires dans references/mode-writing.md (lecteur et objectif, échantillons de voix, ce qui est fixe, limites de longueur et de localisation).
3. Référence — où est l'UI aujourd'hui ? Soit l'utilisateur donne un score sur 10, soit les juges le notent d'abord. Recommandez de faire les deux quand l'utilisateur a une opinion : leur nombre calibre les juges (s'ils disent 6 et que les juges disent 8, la rubrique est trop douce — resserrez-la avant le tour 1).
4. Condition d'arrêt — un score cible (par ex. ≥9/10 dans chaque groupe et thème), un nombre de tours, ou la première éventualité. Recommandez "score cible, plafonné à N tours". Avertissez qu'une boucle sans plafond peut utiliser beaucoup de tokens.
5. Intelligence des sous-agents — quel modèle et quel effort les juges et implémenteurs utilisent. Proposez : meilleur disponible (le plus lent, le plus minutieux), équilibré (le modèle et l'effort de la session elle-même), rapide (modèle moins cher pour la capture et les corrections mécaniques, modèle fort pour le jugement). Le jugement est là où l'intelligence paie le plus ; si l'utilisateur veut économiser, économisez d'abord sur la capture et l'implémentation mécanique.
6. Références — ont-ils des designs qu'ils aiment ou doivent reproduire ? Sites web, applications, captures d'écran, un lien Figma, un système de design, ou une ligne directrice ou une compétence nommée (un HIG de plateforme, une compétence de design-engineering). Demandez ce qu'ils aiment dans chacun (la densité, les menus, les animations), car "j'aime ce site" sans raison est copié en bloc. En mode polissage, les références sont facultatives et généralement des lignes directrices. En mode direction artistique, la boucle a besoin d'une cible : une description de style, des références, un design Figma ou une image générée ; si l'utilisateur n'en a pas, proposez d'en rassembler ou d'en générer (voir "Références et cibles").
7. Livraison — une branche seulement, une PR (non fusionnée), et/ou un build qu'ils peuvent exécuter. Par défaut : branche + PR non fusionnée. Ne fusionnez ou ne publiez jamais sauf s'ils le demandent.

Mettez tout ce que l'utilisateur vous a donné dans .designloop/references/ (étape 3) et listez-le dans la rubrique, pour que chaque juge et implémenteur travaille à partir des mêmes sources.

Étape 2 : Étudier la configuration du projet

Avant d'écrire des règles, découvrez comment ce projet est réellement exécuté, testé et livré, pour que la boucle suive les habitudes de l'utilisateur au lieu d'imposer les siennes. Regardez d'abord, demandez ensuite : lisez ce que le dépôt et la machine peuvent vous dire, et ne demandez que ce qui est encore flou ou relève d'une préférence.

Cherchez :

• Instructions déjà écrites : CLAUDE.md / AGENTS.md, README et CONTRIBUTING, notes mémoire, et tous les fichiers de règles d'agent antérieurs. Ceux-ci priment sur tout ce qui est déduit.
• Comment l'application s'exécute et comment elle peut être pilotée : scripts package, Makefile, builds de développement vs. production, et ce qui peut la capturer (navigateur/CDP, Playwright, simulateur ou outillage d'appareil, une configuration existante de capture d'écran ou e2e). Si rien ne peut piloter l'application automatiquement, dites-le et demandez comment l'utilisateur souhaite que les captures soient faites.
• Les vérifications auxquelles le projet fait confiance : vérification de type, lint, tests, build, et si elles passent aujourd'hui.
• Habitudes Git : branche par défaut, nommage des branches, si les worktrees sont déjà utilisés, conventions de message de commit, si le travail passe par des PRs.
• Tout ce qu'une exécution pourrait toucher en dehors du dépôt : comptes réels, API payantes ou backends IA, messagerie, données de production, le propre profil ou les appareils de l'utilisateur. Vérifiez s'il existe un mode mock, démo ou bac à sable.
• Si un outil de design est connecté : si l'utilisateur a donné un lien Figma (ou un autre lien d'outil de design), cherchez un connecteur ou un serveur MCP qui peut le lire, et s'il est connecté.
• Si des images peuvent être générées ici : vérifiez ce que cette session peut réellement appeler, plutôt que de présumer. Certains harnais ont la génération d'images intégrée (Codex oui) ; dans d'autres, elle provient d'une compétence, d'un plugin ou d'un serveur MCP installé (Higgsfield ou tout autre modèle d'image). Parcourez les outils et compétences disponibles. S'il n'y en a pas, la boucle fonctionne toujours ; les images cibles sont facultatives.
• Les limites de la machine qui comptent pour le travail parallèle : espace disque libre, ports déjà utilisés, autres agents ou serveurs de développement en cours d'exécution.

Confirmez ensuite avec l'utilisateur, en un seul appel AskUserQuestion, uniquement les choix que vous n'avez pas pu déterminer à partir de ce que vous avez trouvé. Les choix typiques sont :

• Où travailler : la branche actuelle, une nouvelle branche, ou des worktrees séparés par implémenteur (nécessaires si les implémenteurs s'exécutent en parallèle).
• Comment tester : serveur de développement uniquement, ou aussi le build de production/empaqueté avant de terminer ; quels thèmes, tailles de fenêtre ou appareils comptent.
• Ce qui ne doit pas être touché ou dépensé : comptes réels et services payants, et si un mode mock est acceptable pour les captures.
• Combien exécuter à la fois : implémenteurs en parallèle, ou un à la fois.

Indiquez ce que vous avez déduit dans la question ("J'ai trouvé X, donc je prévois de Y") pour que l'utilisateur puisse corriger rapidement. Écrivez le résultat dans RULES.md (étape suivante), et notez quelles règles proviennent de l'utilisateur et lesquelles vous avez déduites.

Étape 3 : Configuration

Créez un dossier de travail en dehors de l'arborescence source, ou un .designloop/ ignoré par git dans le dépôt :

.designloop/
  BRIEF.md        # les réponses de l'entretien : objectif, périmètre inclus/exclu, tolérance au changement, focus, condition d'arrêt
  RUBRIC.md        # à partir de references/rubric.md, pondéré pour le focus choisi
  RULES.md         # les règles de travail de ce projet, de l'étape 2 (voir references/briefs.md)
  references/      # ce que l'utilisateur aime, et toutes les images cibles (voir ci-dessous)
  capture/         # le(s) script(s) de capture et la liste des surfaces
  round-0/ …       # par tour : images fixes par thème, videos/, index.json, judge-*.md

Écrivez-les avant de générer quoi que ce soit. Les sous-agents commencent sans contexte, donc les fichiers sont le contexte : pointez les briefs vers eux au lieu de retaper.

• RUBRIC.md — commencez par la rubrique dans le fichier de référence du mode (references/mode-polish.md ou references/mode-art-direction.md), avec l'en-tête partagé et le format de sortie du juge de references/rubric.md. Ajustez les poids en fonction du focus de l'utilisateur, écrivez explicitement les listes de périmètre IN et OUT, et définissez ce que signifie le score maximum.
• RULES.md — ce que l'étape 2 a établi : comment exécuter et piloter l'application, où travailler dans git, les vérifications à effectuer, ce qui ne doit pas être touché ou dépensé, et comment nettoyer. references/briefs.md contient la liste des choses qu'il doit couvrir.
• Liste des surfaces — chaque surface dans le périmètre, chacune avec les états qui valent la peine d'être jugés (repos, survol, ouvert, sélectionné, vide, erreur, occupé) et chaque thème. Divisez-la en deux ou trois groupes de surfaces connexes pour que chaque juge puisse examiner attentivement ; un juge parcourant cinquante captures d'écran survole.

Vérifiez que les vérifications du projet passent avant de commencer, pour qu'un échec ultérieur soit le vôtre.

Références et cibles

Une rubrique dit ce qui est bon en général ; les références disent à quoi ressemble le bon pour cet utilisateur. Le mode direction artistique a toujours une cible d'une certaine sorte. Le mode polissage peut fonctionner avec la seule rubrique, les meilleures surfaces de l'application elles-mêmes servant de norme.

Il existe trois types de cibles, et elles ont une autorité différente. Dites lequel est chaque fichier dans references/README.md, car les juges et les implémenteurs doivent les traiter différemment :

• Une spécification (un design Figma que l'utilisateur dit de reproduire) : faisant autorité. Reproduisez-le.
• Une référence (sites, applications, captures d'écran que l'utilisateur aime) : reproduisez les traits nommés, pas l'ensemble.
• Une image générée : une direction pour la sensation uniquement.

Références données par l'utilisateur. Sauvegardez-les dans .designloop/references/ avec un court README.md : pour chacune, ce que c'est et ce que l'utilisateur aime. Pour un site web ou une application, capturez des captures d'écran des parties pertinentes (et un clip si l'attrait est l'animation) afin que les juges regardent la même chose à chaque tour au lieu de re-récupérer une page qui peut changer. Transformez les goûts en traits concrets et vérifiables dans la rubrique ("hauteur de ligne environ 28px", "une couleur d'accent", "les menus apparaissent en fondu en moins de 200ms"), car un juge peut noter un trait mais pas une ambiance.

Références que vous rassemblez. Si l'utilisateur veut une direction mais n'a pas d'exemples, proposez trois ou quatre produits bien connus dont l'interface correspond à leur objectif, montrez-les, et laissez l'utilisateur choisir. Ne choisissez pas à leur place.

Un design Figma. Si l'utilisateur donne un lien Figma, vérifiez si un connecteur Figma ou un serveur MCP est disponible dans cette session (étape 2). Si c'est le cas, chargez d'abord sa propre compétence ou ses instructions, puis récupérez pour chaque frame lié : une ré…