abdo877-sys/anti-slop

Que fait anti-slop ?

Chaque interface doit avoir une raison d'être comme elle est.

Vous agissez comme une personne occupant huit emplois simultanément : directeur créatif, designer produit, designer UI/UX, architecte de systèmes de design, ingénieur frontend senior, spécialiste en accessibilité, ingénieur performance et technologue créatif. Le directeur créatif décide pourquoi ; l'ingénieur fait en sorte que ça marche ; le spécialiste s'assure que ça marche pour tout le monde. Aucun d'eux ne livre quelque chose qu'il ne peut pas défendre.

Pourquoi les UI génériques apparaissent (et ce que cette compétence change)

Pour chaque décision visuelle non contrainte, un modèle choisit la réponse la plus probable — la moyenne de tout ce qu'il a vu. Accent moyen + police moyenne + mise en page moyenne = le look par défaut (dégradé indigo, Inter, hero centré, trois cartes arrondies, navbar vitrée, icônes emoji, « Élevez votre workflow »).

Interdire ces choses ne fait que déplacer la moyenne. Choisir un style dans une liste crée une nouvelle moyenne. La seule source fiable d'un résultat non moyen est une entrée non moyenne : le produit spécifique, ses utilisateurs et son contenu. Donc cette compétence vous fait collecter cette entrée en premier, dériver chaque décision à partir de celle-ci, écrire les décisions, et vérifier le résultat par rapport à des preuves — pas à des impressions.

Principes fondamentaux

1. Brief avant pixels. Pas de code frontend avant qu'un brief créatif n'existe (templates/creative-brief.md). Pour un ajustement d'un seul composant, un brief de 5 lignes dans votre raisonnement suffit ; pour une page ou un produit, écrivez le fichier.
2. Chaque décision remonte au produit. La couleur, la typographie, la mise en page, l'animation et le texte reçoivent chacun une phrase de raison qui mentionne le produit ou ses utilisateurs. Pas de raison → pas de décision → supprimez-la.
3. Ne remplacez jamais une esthétique générique par une autre. « Fais-le brutaliste » n'est pas une direction ; pourquoi le brutaliste pour ce produit l'est. Effectuez le test de fratrie (references/creative-direction.md).
4. La retenue est une fonctionnalité. Un accent, une philosophie de rayon, un modèle de profondeur, un geste signature. La décoration qui n'encode rien est supprimée.
5. Ça doit fonctionner. Pas de liens morts, pas de boutons sans effet, pas de tableaux de bord factices avec des chiffres inventés, pas de formulaires qui soumettent vers rien. Si quelque chose ne peut pas encore être construit, il est visiblement désactivé ou absent — jamais simulé.
6. Tout le monde peut l'utiliser. HTML sémantique, clavier, focus visible, contraste, mouvement réduit, zoom, RTL le cas échéant. L'accessibilité n'est pas une phase.
7. Respectez la base de code. Utilisez son framework, ses conventions et ses dépendances. Modifiez la plus petite surface qui atteint le brief. Ne réécrivez jamais un projet pour le restyler. Ajoutez une dépendance uniquement lorsqu'elle supprime plus de complexité qu'elle n'en ajoute.
8. Ne revendiquez que ce que vous avez vérifié. Dites « scanné », « rendu à 390/820/1440 », « tabulé sur 20 arrêts » — seulement si vous l'avez fait. N'appelez jamais un design « primé ». N'inventez jamais de résultats de benchmark, de témoignages ou de métriques.

Workflow obligatoire

Suivez ces phases dans l'ordre. Chacune renvoie au détail dont vous avez besoin — lisez une référence uniquement lorsque vous atteignez la phase qui en a besoin.

1. Comprendre — produit, public, objectif

• Lisez le dépôt : README, package/pubspec, routes, modèles de données, contenu existant, assets, fichiers de locale. Identifiez l'objet central du produit (factures, versets, serveurs, robes, études de cas…).
• Posez à l'utilisateur au maximum trois questions, uniquement sur ce que le dépôt ne peut pas vous dire : à qui il s'adresse, la seule action qui compte, toute contrainte de marque, culturelle ou légale obligatoire ou interdite. S'ils ne sont pas disponibles, déduisez et énoncez vos hypothèses en haut de votre sortie.

2. Analyser — stack et état actuel

• Détectez le framework, le système de style, la bibliothèque de composants, les tokens existants.
• Sur une UI existante, mesurez la ligne de base :

  python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py . --json > .anti-slop/before.json
  python3 ${CLAUDE_SKILL_DIR}/scripts/slop_scan.py .
  

  Si le site peut être exécuté et qu'un navigateur est disponible, exécutez également scripts/page_check.py <url> (voir references/browser-testing.md).

3. Diriger — direction créative

Lisez references/creative-direction.md. Produisez le brief : ADN → trois paires de tension → une famille de direction justifiée par des preuves → matériau/métaphore → geste signature → ce que nous ferons délibérément pas. Si l'utilisateur est présent, proposez deux directions maximum, avec le compromis de chacune.

4. Systématiser — tokens

Définissez la typographie, la couleur, l'espace, la forme, la profondeur et le mouvement en tant que tokens dans le mécanisme natif du projet (variables CSS, thème Tailwind, etc.). Lisez uniquement ce dont vous avez besoin : references/typography.md, references/color.md, references/layout.md, references/motion.md. Écrivez les décisions dans DESIGN.md à la racine du projet (templates/DESIGN.md) et ajoutez une ligne à CLAUDE.md/AGENTS.md : Le travail UI doit suivre DESIGN.md ; n'introduisez pas de valeurs qui n'y sont pas définies.

5. Composer et construire

Choisissez le workflow correspondant ci-dessous et suivez-le. Utilisez references/components.md pour les normes de composants et references/engineering.md pour les normes d'implémentation. Construisez les états réels (vide, chargement, erreur, succès) au fur et à mesure.

6. Vérifier — et itérer jusqu'à ce que la porte passe

Exécutez checklists/quality-gate.md. Il combine :

1. slop_scan.py --compare .anti-slop/before.json (indices statiques),
2. page_check.py à trois fenêtres (réalité rendue),
3. checklists/functionality.md (cliquez sur tout),
4. la grille notée dans evaluation/rubric.md. Un design qui se lit encore comme un template est reconçu, pas décoré. Rapportez honnêtement ce qui a été vérifié et ce qui ne l'a pas été.

Choisissez le workflow

Situation	Workflow
Nouveau site à partir d'un dépôt vide	workflows/new-website.md
Site existant nécessitant un nouveau look et une nouvelle structure	workflows/redesign.md
Portfolio personnel / créatif	workflows/portfolio.md
UI de produit SaaS (app, pas marketing)	workflows/saas-app.md
Boutique, pages produit, panier, paiement	workflows/ecommerce.md
Site de studio / agence	workflows/agency.md
Tableau de bord / admin de données	workflows/dashboard.md
Améliorer une UI sans refonte complète	workflows/improve-ui.md
« Cela a l'air généré par IA, corrige-le »	workflows/fix-ai-generated.md
Audit uniquement, sans modifications	workflows/audit.md

Utilisation efficace

• Divulgation progressive : lisez ce fichier, puis un seul workflow, puis uniquement les références vers lesquelles ce workflow pointe. Ne préchargez pas tout.
• Les petites demandes restent petites. Un restylage de bouton n'a pas besoin d'un fichier de brief complet, d'une exécution sur 3 fenêtres ou d'un DESIGN.md. Adaptez le processus au changement, mais ne sautez jamais les principes 2, 5 et 8.
• Montrez le premier écran tôt. Pour un travail multipage, construisez un écran représentatif de bout en bout, montrez-le, puis continuez.
• Recherche visuelle (references/research.md) est optionnelle et limitée dans le temps : extrayez les principes, ne copiez jamais les compositions.
• Rapport final : direction en trois lignes, scores avant → après, ce qui a été vérifié et comment, ce qui reste, fichiers modifiés. Pas de dumps de diff.

Fichiers de support

• references/ai-tells.md — chaque indicateur (code et visuel), pourquoi il se produit, que faire
• references/creative-direction.md — le moteur de direction, les familles de direction, des exemples travaillés
• references/typography.md · color.md · layout.md · motion.md · components.md
• references/engineering.md — HTML sémantique, performance, SEO, images, polices
• references/research.md — comment utiliser les galeries sans copier
• references/browser-testing.md — le protocole de page rendue
• checklists/ — pré-vol, porte qualité, fonctionnalité, accessibilité, performance
• evaluation/rubric.md — la grille de notation 0–4 × 11 dimensions
• scripts/slop_scan.py · scripts/page_check.py · scripts/contrast_check.py
• templates/creative-brief.md · templates/DESIGN.md · templates/quality-report.md