Communitygithub.com

Unslop Design

Analyse et refonte du design d'une application ou d'un site web pour éliminer le « slop » (couleur d'accent décorative, dégradés, ombres inutiles, badges bruyants, émojis en guise d'icônes, espacements au jugé, salutations comme titres de page, casse des titres, hiérarchie plate, nombres redondants) en utilisant un système (espacement, typographie, rôles de couleur, élévation) et un processus orchestré — inventaire à partir d'enregistrements d'écran ou de captures d'écran, passage en niveaux de gris, réviseurs designers produit en parallèle, proposition gagnante publiée, développeurs par zone, audits et une PR. Fonctionne.

Qu'est-ce que Unslop Design ?

Ce skill définit une méthodologie complète pour réviser et refondre l'interface utilisateur d'une application ou d'un site web en éliminant le « slop » — éléments de design superflus comme les couleurs décoratives, les dégradés, les ombres vides de sens, les badges sonores, les émojis utilisés comme icônes, les espacements approximatifs, les titres de page sous forme de salutations, la casse systématique, la hiérarchie plate et les nombres redondants. Le processus repose sur un système strict d'espacement, de typographie, de rôles de couleur et d'élévation, et suit une orchestration multi-étapes : inventaire à partir d'enregistrements d'écran ou de captures, passage en niveaux de gris pour valider la hiérarchie, revues parallèles par des designers produit seniors, publication d'une proposition avant/après, implémentation par les développeurs dans des branches isolées, audits et finalisation par une pull request. Le skill est compatible avec divers agents IA comme Claude Code, Codex, Cursor, Copilot et Gemini, et s'adapte à leurs capacités (sous-agents, worktrees git, etc.). Il est également conçu pour fonctionner sur plusieurs plateformes (SwiftUI, Compose, web, widgets, watch, voiture) et intègre des principes non négociables comme le contraste mesuré (WCAG AA), la hiérarchie avant la couleur, et la vérification systématique de ce que voit l'utilisateur (modes clair/sombre, grande taille de texte, données réelles). Si le projet possède déjà son propre skill de design, celui-ci prévaut en cas de conflit. En résumé, ce skill transforme un processus subjectif de refonte en une procédure reproductible, mesurable et automatisable, garantissant un design plus épuré, accessible et cohérent.

Compatible avec✓Claude Code✓Codex CLI✓Cursor✓Gemini CLI
Part ofDesign & UI
npx skills add https://github.com/marcosnovo/unslop-design/tree/HEAD
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Que fait Unslop Design ?

Trois parties : ce qu'il faut corriger (checklist.md, chaque correction avec sa raison), comment orchestrer (process.md, tours avec réviseurs et développeurs en parallèle) et cas et sources (references.md : les cinq avant/après qui ont lancé ce skill et une carte de Refactoring UI). La fiche de spécification que chaque réviseur remplit se trouve dans spec-card.md. Les notes par plateforme (SwiftUI, Compose, web, widgets, watch, voiture) sont dans platforms.md. Lisez celle dont vous avez besoin, pas toutes.

Principes (non négociables)

  1. Une correction est une règle, pas un réglage. Chaque changement est livré sous forme de token ou de composant (espacement, taille de police, graisse, rôle de couleur, rayon, ombre, bouton), jamais en tant que valeur littérale dans la vue. Si le token manque, créez-le dans le même changement. Choisissez les valeurs par élimination au sein de l'échelle (essayez la valeur et ses deux voisines ; la valeur du milieu gagne ou vous répétez), jamais pixel par pixel.
  2. La hiérarchie avant la couleur. L'écran doit fonctionner en niveaux de gris : l'espacement, la taille, le poids et le contraste font le travail ; la couleur vient après et seulement pour signifier quelque chose. Si ce qui importe n'est pas clair en gris, la couleur ne le corrigera pas.
  3. La première chose que vous lisez est la réponse. Un seul nombre héro par écran (le solde, le prix, la progression du jour) ; tout le reste passe au second plan. Mettez en valeur en dévalorisant la concurrence, pas en gonflant le héros. Au maximum une surface sombre/héro par écran, et aucune dans les feuilles ou les fenêtres modales.
  4. La couleur dit une seule chose. Un accent de marque pour l'action ou le nombre héro ; tout le reste est un rôle avec une signification (argent/succès, ascendant/danger, statut, récompense) et du gris pour ce qui ne fait que naviguer. Couleur décorative = slop. La couleur ne travaille jamais seule : une forme ou un mot l'accompagne.
  5. Contraste mesuré, pas supposé. WCAG AA (4,5:1 pour le texte, 3:1 pour les grands textes et les icônes) calculé à partir des vraies valeurs hexadécimales sur les vrais fonds, clair et sombre. Le blanc sur une couleur de marque verte/jaune ne passe presque jamais ; le texte gris sur un fond coloré non plus (choisissez une nuance de la même teinte).
  6. Rien que l'écran ne peut pas délivrer. Pas de nombres inventés, pas de projections présentées comme des données, pas de fonctionnalité implicite qui n'existe pas, pas d'état vide qui ment. Concevez la version la plus petite que vous pouvez réellement livrer.
  7. Un geste signature, tiré du domaine. Un détail de marque né de ce que l'application montre (un prix sur un tableau de prix avec un dernier chiffre plus petit, des chiffres en matrice de points sur une application de course), pas une nouvelle police ou un nouvel effet ; et il se dégrade élégamment là où il ne s'applique pas. Tout le reste est natif : ne combattez pas la barre d'onglets, les commutateurs ou les feuilles système.
  8. Les plateformes sont livrées ensemble. Si le projet a iOS et Android (ou application et web), la modification va aux deux dans la même PR, dans chaque langue.
  9. Vérifiez ce que l'utilisateur voit. Captures d'écran en modes clair et sombre, taille de texte la plus grande, devise/langue non par défaut, données réelles (noms longs, vide, 2000 éléments). Ce qui ne peut pas être compilé dans votre environnement est audité en lisant le code, et la PR le mentionne.

Tout agent (Claude Code, Codex, Cursor, Copilot, Gemini…)

Les règles sont les mêmes partout. Là où il est écrit « agents », utilisez ce que votre outil propose : des sous-agents s'il en a (Claude Code, Codex…), avec un git worktree chacun pour les développeurs. Sans sous-agents, exécutez les réviseurs l'un après l'autre, chacun avec son propre brief, et conservez leurs sorties séparément avant l'étape de jury. Là où il est écrit « publier », Claude Code publie un artefact ; les autres agents écrivent un fichier HTML que l'utilisateur ouvre. Dans une application de chat sans base de code, arrêtez après la proposition avant/après.

Accord de travail (valeurs par défaut)

  • Réviseurs = designers produit seniors et développeurs = développeurs seniors, en tant qu'agents (utilisez le modèle demandé par l'utilisateur). L'orchestrateur ne construit pas les zones : il fait le travail partagé, intègre et audite.
  • Chaque décision est accompagnée d'une recommandation explicite et actionnable.
  • Avant d'implémenter, publiez l'avant/après et attendez le « oui » de l'utilisateur.
  • Chaque tour révise également ce que les tours précédents ont livré et toutes les vidéos/captures d'écran reçues, pas seulement les plus récentes.
  • Quand la fusion est autorisée une fois que CI est vert : terminez par une liste de ce qu'il faut vérifier lors de la compilation (risques concrets) et, s'il n'y a pas de Mac/simulateur, une invite autonome pour une session locale.
  • Sur « est-ce que tout est fait ? » : fait (avec PRs) · en attente de votre part · volontairement laissé de côté.
  • Après le dernier tour, mettez à jour le système de design du projet.

Flux court

  1. Inventaire : images tirées des vidéos (process.md § 1), écrans et états, et chaque écran localisé dans le code.
  2. Système : vérifiez (ou créez) les échelles d'espacement, de typographie, de couleur et d'élévation (checklist.md § Système). Sans échelles, les réviseurs jugent à l'œil.
  3. Passage en niveaux de gris + réviseurs en parallèle (3-4, un par zone) par rapport à checklist.md, en appliquant les corrections une par une.
  4. Proposition gagnante : une page HTML avec l'avant/après, la fiche de spécification et la liste des décisions ; l'utilisateur choisit.
  5. Développeurs par zone dans des worktrees isolés avec un brief fermé ; intégrez, compilez, auditez, PR, répondez aux bots de revue, fusionnez quand vert.
  6. Enfin : mettez à jour le système de design du projet (doc + tokens + son propre skill) avec ce qui est nouveau.

Si le projet a déjà son propre skill de design

Utilisez-le pour les tokens et composants concrets ; celui-ci apporte la méthode et la checklist générale. Si une règle ici entre en conflit avec une décision écrite du projet, le projet gagne et la proposition le signale.

Skills associés

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community