anti-ai-design

Compétence de conception d'UI auto-orchestrée avec des règles anti-IA obligatoires. Produit des écrans incroyablement beaux et visuellement distincts — jamais le résultat générique produit par l'IA.

Quand l'utiliser

Activez cette compétence chaque fois que l'utilisateur demande :

Une page d'accueil, une section héros ou un écran marketing
Un tableau de bord, un panneau d'administration ou une interface riche en données
Un écran d'application mobile (iOS, Android) ou une UI web responsive
Un flux d'intégration, un formulaire d'inscription ou une présentation de produit
Une bibliothèque de composants ou un écran de système de design
« Améliorez l'apparence », « refaites le design de ceci », « créez une UI pour… »

Contrat d'interaction non négociable

Avant de générer tout résultat de conception, vous DEVEZ résoudre ces trois décisions dans l'ordre :

Périmètre de la plateforme — demandez à l'utilisateur pour quelles plateformes générer : mobile, tablette, desktop.
- La sélection multiple est autorisée.
- Si l'utilisateur choisit uniquement mobile et desktop, ne générez PAS de tablette.
- Si la plateforme est déjà explicitement indiquée et sans ambiguïté, confirmez en la réitérant et continuez.
Direction des couleurs — résolvez la direction des couleurs de la marque en utilisant cet ordre :
- Si l'utilisateur a fourni des couleurs exactes, utilisez-les.
- Sinon, si l'utilisateur a fourni une ambiance de marque/thème, proposez 2 à 3 directions de palette adaptées et demandez-lui de choisir.
- Sinon, sélectionnez automatiquement une palette adaptée à la catégorie du produit et indiquez clairement qu'elle a été sélectionnée automatiquement.
Direction stylistique — présentez 2 à 3 options de style et demandez à l'utilisateur d'en choisir une.

Ne sautez pas ces décisions, sauf si la conversation contient déjà une réponse sans ambiguïté.

Mode d'exécution

Interactif (par défaut)

Demandez à l'utilisateur chaque choix manquant dans l'ordre : plateforme → couleur → style.
Attendez sa réponse avant de passer à la phase suivante.
Présentez des fiches d'option pour la direction stylistique avec un label RECOMMANDÉ.

Non interactif

Activez-le lorsque l'utilisateur :

invoque la compétence avec mode: non_interactive ou un indicateur équivalent,
exécute une commande CLI unique, une tâche Codex en arrière-plan ou un pipeline scripté, ou
fournit une invite sans contexte conversationnel préalable (pas de tours de chat avant la demande).

Règles de sélection automatique (appliquées dans l'ordre) :

Plateforme — si non précisée, utilisez par défaut desktop. S'il existe des signaux mobile-first (description d'application mobile, mention de React Native, contexte « téléphone »), utilisez par défaut mobile.
Direction des couleurs — sélectionnez la palette la mieux adaptée au type de projet détecté sans proposer d'alternative.
Direction stylistique — parmi les 2 à 3 styles candidats pour ce contexte de projet, sélectionnez celui qui serait marqué RECOMMANDÉ. Ne présentez pas de fiches d'option.

En-tête de sortie requis avant la génération (non interactif uniquement) :

Sélection automatique :
- Plateforme : [plateforme(s) sélectionnée(s)]
- Palette : [nom de la palette] — primaire [valeur hexadécimale]
- Style : [nom du style] — [ambiance en une phrase]
Passage à la génération du bundle.

Ne posez pas de questions de clarification. Ne présentez pas de fiches d'option. Passez directement à la Phase 3 après l'en-tête.

Contrat de sortie — Bundle CJX, pas un seul fichier HTML

La sortie par défaut est un répertoire bundle pour le projet, pas un seul fichier HTML lâche.

<slug-app>-design/
  html/
    landing-page.html
    mobile-<écran>.html
    tablette-<écran>.html
    desktop-<écran>.html
  css/
    foundation.css
    shared.css
    landing-page.css
    mobile-<écran>.css
    tablette-<écran>.css
    desktop-<écran>.css
  js/
    app.js
    landing-page.js
    mobile-<écran>.js
    tablette-<écran>.js
    desktop-<écran>.js

Règles du bundle

html/ contient un fichier HTML par combinaison écran/plateforme générée.
css/foundation.css contient uniquement les jetons de design figés.
css/shared.css contient les primitives partagées, utilitaires, animations, recettes de verre, états de focus et schémas de mise en page communs.
Le CSS spécifique à un écran va dans un fichier spécifique à cet écran.
js/app.js contient les assistants UI partagés, les toggles d'état, la gestion des données fictives et les interactions respectueuses de l'accessibilité.
Le JS spécifique à un écran va dans un fichier spécifique à cet écran uniquement si nécessaire.
Si l'utilisateur demande ultérieurement un export en un seul fichier, vous pouvez en outre fournir un export HTML autonome, mais le contrat par défaut est le bundle CJX.

Règles de nommage des fichiers par plateforme

Les pages d'accueil restent sémantiques : landing-page.html, landing-page.css, landing-page.js
Les écrans d'application utilisent des préfixes de plateforme :
- mobile-<écran>.html
- tablette-<écran>.html
- desktop-<écran>.html
Générez des fichiers uniquement pour les plateformes sélectionnées.
Si l'utilisateur a sélectionné mobile et desktop, le bundle de sortie ne doit contenir aucun fichier tablette-*.

Pourquoi des fichiers séparés au lieu d'un seul HTML responsive

Utilisez des fichiers de plateforme séparés par défaut car :

chaque plateforme peut avoir une architecture de l'information, une navigation, une densité et un placement des CTA sensiblement différents,
la révision et la remise sont plus faciles lorsque chaque cible est isolée,
la vérification CJX est plus claire lorsque l'intention de l'écran est explicite,
desktop/tablette/mobile nécessitent souvent une hiérarchie différente, pas seulement des points de rupture différents.

Un seul HTML responsive n'est acceptable que lorsque l'utilisateur demande explicitement une livraison en un seul fichier.

Routage des sous-compétences

Chargez UNIQUEMENT le fichier de référence nécessaire pour l'étape en cours. Ne chargez PAS tous les fichiers à la fois.

Tâche	Charger	Détails
Choisir un style de design / une direction artistique	`references/design-styles-catalog.md`	36 styles répartis dans 11 catégories
Sélectionner une tendance / un pack artistique	`references/design-trends.md`	6 tendances, 3 packs de direction artistique
Appliquer une recette de design	`references/design-recipes-catalog.md`	15 recettes de design complètes
Appliquer les règles de mise en page par plateforme	`references/platform-rules.md`	Règles Mobile/iOS 26/Desktop/Tablette
Figer et injecter les jetons de base	`references/foundation-tokens.md`	Instructions et format pour le gel des jetons
Appliquer la grammaire des rayons + hiérarchie d'imbrication	`references/radius-choreography.md`	Rôles de rayons sémantiques, règles de surface imbriquée, grammaire des rayons par famille de style
Appliquer les règles UX / de parcours client	`references/ux-guidelines.md`	Application des règles UX, schémas CJX
Appliquer la chorégraphie du mouvement + l'intention d'interaction	`references/motion-choreography.md`	Objectif du mouvement, politique de survol, transitions d'état, règles de mouvement par plateforme
Appliquer la propriété des actifs du bundle + audit du manifeste	`references/output-bundle-rules.md`	Règles des actifs partagés vs écran, manifeste, auto-audit
Générer le bundle de sortie	`references/output-template.md`	Structure du bundle, modèle HTML, contrat de fichier

Flux d'auto-orchestration

Exécutez ces phases dans l'ordre. Chaque phase a une logique conditionnelle — suivez-la précisément.

Phase 1 — DÉTECTION DU CONTEXTE

Analysez la conversation et les éventuels fichiers joints pour : le nom du projet, les couleurs de marque existantes, les polices, la pile technique, la plateforme cible et l'objectif de l'écran.
Classez le type de projet comme l'un des suivants : SaaS produit · e-commerce · application mobile · portfolio · tableau de bord · site marketing · autre.
Extrayez les écrans demandés et comptez-les.
Résolvez le périmètre de la plateforme comme un ou plusieurs de : mobile, tablette, desktop.
Si le périmètre de la plateforme est manquant ou ambigu : posez exactement une question de sélection de plateforme avec des choix à sélection multiple :
- Mobile
- Tablette
- Desktop
Si l'utilisateur a déjà spécifié des plateformes, ne reposez pas la question — conservez-les exactement.
Notez les éventuels jetons de marque existants (couleurs, polices, échelle d'espacement) trouvés dans le projet — vous les utiliserez lors du gel des jetons ultérieur.
Résolvez la priorité du jeu de couleurs en fonction du type de projet :

Dark-mode-first (le mode sombre est le canevas principal ; le mode clair est la surcharge facultative) :
- Tableau de bord · panneau d'administration · SaaS riche en données · fintech · outils développeur · analytics · surveillance · crypto/web3 · média/streaming · jeux vidéo
Light-mode-first (le mode clair est le canevas principal ; le mode sombre est la surcharge facultative) :
- E-commerce · site marketing · portfolio · santé · éducation · alimentation & boissons · style de vie
Si le type de projet est ambigu ou ne correspond à aucune des listes, utilisez par défaut light-mode-first et proposez le mode sombre en supplément.

Transférez cette décision comme color_scheme_priority: dark_first | light_first. Les options de palette de la Phase 2 et le gel des jetons de la Phase 4 doivent refléter cette priorité.

Phase 2 — DIRECTION COULEUR + DESIGN

Résolvez la direction des couleurs avant la sélection du style.
Si l'utilisateur n'a pas fourni de palette explicite, proposez 2 à 3 directions de palette qui correspondent à la catégorie du produit et reflètent la color_scheme_priority de la Phase 1 :
- Pour les projets dark_first : présentez d'abord des options de palette sombre (par exemple, OLED luxe sombre, ardoise électrique, bleu marine profond), incluez une option claire uniquement comme dernier choix.
- Pour les projets light_first : présentez d'abord des options de palette claire (par exemple, commerce énergie-chaleureuse, confiance froide-neutre), incluez une option sombre uniquement si elle correspond à la marque.
- Demandez à l'utilisateur d'en choisir une.
Si l'utilisateur refuse de choisir, sélectionnez automatiquement la palette la mieux adaptée et expliquez pourquoi en une phrase.
Chargez references/design-styles-catalog.md.
Dans le catalogue, sélectionnez 2 à 3 styles qui correspondent le mieux au type de projet, à la palette choisie et au contexte.

Pour chaque style sélectionné, générez une fiche d'option dans ce format :

[N]. **Nom du style** — RECOMMANDÉ (si applicable)
Ambiance : [ambiance/humeur en une phrase]
Esthétique clé : [3 caractéristiques visuelles déterminantes]

Marquez EXACTEMENT une option comme RECOMMANDÉE en fonction de la meilleure adéquation.
Présentez la liste numérotée à l'utilisateur et demandez-lui de choisir. Attendez sa réponse avant de continuer.
Si l'utilisateur demande un style différent de ceux de la liste, acceptez-le et continuez.

Phase 3 — GÉNÉRATION DU BUNDLE

Chargez references/platform-rules.md pour les plateformes sélectionnées.
Chargez references/output-template.md pour le format du bundle CJX.
Chargez references/output-bundle-rules.md pour la propriété des actifs, le placement des classes partagées, le manifeste et l'auto-audit du bundle.
Chargez references/radius-choreography.md pour résoudre la grammaire des rayons, la hiérarchie des surfaces imbriquées et la courbure basée sur les rôles avant d'écrire tout CSS.
Chargez references/ux-guidelines.md lors de la génération de la sortie finale car l'exhaustivité des états est obligatoire.
Appliquez TOUTES les règles Anti-AI Design ci-dessous.
Appliquez les règles de plateforme pour chaque plateforme sélectionnée séparément.
Résolvez une grammaire des rayons pour la direction stylistique choisie avant d'écrire le CSS des composants :
- choisissez 2 à 4 niveaux de rayons principaux plus la pilule si nécessaire,
- mappez-les à des rôles sémantiques : coque, surface, incrustation, contrôle, serré, pilule,
- maintenez la grammaire cohérente dans tout le bundle,
- assurez-vous que les surfaces imbriquées de même matériau diminuent en courbure.
Générez un répertoire bundle contenant :
- html/
- css/
- js/
- manifest.json
Générez un trio HTML/CSS/JS par combinaison écran/plateforme requise.
Générez uniquement les écrans demandés et uniquement les plateformes sélectionnées.
Les pages d'accueil peuvent rester sémantiques multiplateformes si le même fichier fonctionne bien, mais si la mise en page change significativement selon la plateforme, générez également des variantes de page d'accueil spécifiques à la plateforme.
Chaque fichier HTML doit :

référencer ../css/foundation.css
référencer ../css/shared.css
référencer son fichier CSS d'écran
référencer le ../js/app.js partagé
référencer son fichier JS d'écran si nécessaire
utiliser data-ai-id sur tous les éléments structurels majeurs
utiliser un texte contextuel et réaliste — jamais de lorem ipsum

Chaque écran d'application généré doit inclure ou gérer explicitement les quatre états UX du ux-guidelines.md :

chargement
vide
erreur
succès

Ces états peuvent être visibles dans le canevas principal ou implémentés comme des états fictifs activables via des contrôles JS, mais ils doivent exister dans le bundle livré.
Résolvez l'état visible par défaut intentionnellement :

les écrans de générateur doivent par défaut être vides sauf si l'utilisateur a explicitement demandé un canevas de succès préchargé/prêt pour la démo,
les écrans de résultat/révision doivent par défaut être succès sauf si le récit exige explicitement un autre état d'abord,
ne laissez jamais un écran de générateur sous-entendre un résultat finalisé avant que l'utilisateur n'ait fourni ou chargé une entrée.

Appliquez les règles de réalisme des écrans utilitaires aux écrans de générateur, de résultat, de tableau de bord et riches en formulaires :

optimisez pour la confiance, la scannabilité et l'alignement avant le spectaculaire,
maintenez le formulaire principal, le canevas d'état, le tableau de résultats et les groupes CTA dans des schémas de flux normaux stables,
n'utilisez pas de cartes de contenu chevauchantes ou positionnées en absolu comme structure principale d'un écran utilitaire,
gardez l'asymétrie décorative secondaire afin qu'elle n'affaiblisse jamais la clarté de la tâche ou la visibilité des CTA,
assurez-vous que la typographie du héros sur les écrans utilitaires se lit de manière crédible à la fenêtre d'affichage cible au lieu de reposer sur un enroulement théâtral.

Avant de déclarer la sortie complète, exécutez l'auto-audit du bundle à partir de references/output-bundle-rules.md :

déplacez tous les sélecteurs réutilisés dans 2 fichiers HTML ou plus dans shared.css
assurez-vous qu'aucune page ne dépend d'un fichier CSS d'une page sœur pour s'afficher correctement
assurez-vous que chaque actif référencé existe
assurez-vous que manifest.json correspond exactement aux fichiers générés
assurez-vous qu'aucun fichier n'existe pour les plateformes non sélectionnées
assurez-vous que la hiérarchie des rayons suit la grammaire sémantique choisie et que les surfaces imbriquées ne s'aplatissent pas en couches de rayon égal
assurez-vous que les écrans utilitaires réussissent l'audit de réalisme de mise en page à leur fenêtre d'affichage cible

Phase 4 — GEL DES JETONS DE BASE

Après avoir généré le premier écran approuvé, extrayez les valeurs exactes des jetons dans css/foundation.css.
Gelez non seulement la couleur/type/mouvement, mais aussi la grammaire sémantique des rayons pour le bundle.
Utilisez ce format exact :

/* JETONS DE BASE GELÉS — NE PAS MODIFIER */
:root {
  --color-primary: <valeur exacte>;
  --color-secondary: <valeur exacte>;
  --color-accent: <valeur exacte>;
  --color-bg: <valeur exacte>;
  --color-surface: <valeur exacte>;
  --color-text: <valeur exacte>;
  --color-text-muted: <valeur exacte>;
  --font-heading: <pile de polices exacte>;
  --font-body: <pile de polices exacte>;
  --space-base: <valeur exacte>;
  --radius-1: <valeur exacte>;
  --radius-2: <valeur exacte>;
  --radius-3: <valeur exacte>;
  --radius-4: <valeur exacte>;
  --radius-pill: <valeur exacte>;
  --duration-fast: <valeur exacte>;
  --duration-normal: <valeur exacte>;
  --duration-slow: <valeur exacte>;
}

Règles Anti-AI Design (APPLIQUER STRICTEMENT)

1. Bannir le dégradé bleu-violet par défaut

Défaut autorisé : pas de dégradé. Si un dégradé est utilisé, il doit être intentionnel, extrêmement contrasté avec la concurrence et validé par l'utilisateur.

2. Interdire les icônes génériques et les maquettes de tableau de bord paresseuses

Utilisez des icônes personnalisées cohérentes ou une bibliothèque spécifique (par exemple, Phosphor, Feather, Lucide). Pas de symboles sans âme de type Font Awesome v4.
Inspirez-vous des designs de niche ou adaptés à un contexte (par exemple, une application de finance personnelle peut utiliser des icônes de type finances réelles, pas des icônes technologiques génériques).

3. Geler les couleurs dès la Phase 2

Une fois qu'une direction de palette est choisie, ne proposez pas de permutations de couleurs aléatoires plus tard.

4. Ne pas utiliser de photos lisses et propres comme remplissage — utilisez des visuels authentiques

Pas de photos de banque d'images cliniques. Utilisez des visuels très texturés, atmosphériques ou bruts.
Les espaces réservés doivent être intentionnels (par exemple, illustrations dessinées à la main, motifs personnalisés, abstractions photographiques).

5. Ne pas centrer les layouts sans raison

Les layouts centrés symétriques ennuyeux sont interdits. Utilisez des grilles asymétriques, des compositions décentrées, de l'espace négatif comme élément actif.

6. Pas de carte de héros arrondie générique avec un dégradé de fond et du texte blanc par-dessus

C'est le geste de design le plus paresseux de l'ère de l'IA. Il est interdit sauf si l'utilisateur le demande explicitement.

7. Capturer les valeurs aberrantes — éviter les extrêmes

Ne rendez pas les couleurs ternes, les polices banales, les espacements larges ou la typographie écrasée. Trouvez la tension entre l'audacieux et le fonctionnel.

8. Concevoir pour une intention émotionnelle, pas seulement pour une fonction

Chaque écran doit transmettre un sentiment délibéré : confiance, urgence, jeu, luxe, minimalisme stoïque.
Documentation : references/design-styles-catalog.md

9. Les transitions et micro-interactions doivent être chorégraphiées, pas jetées

Pour les transitions d'état, utilisez un échelonnement, des courbes d'assouplissement intentionnelles et un timing qui renforcent la clarté hiérarchique du composant.
Documentation : references/motion-choreography.md

10. Privilégier la qualité à la quantité

Générez moins d'écrans mais chacun doit avoir un état UI complet. Un écran bien conçu avec chargement, vide, erreur et succès l'emporte sur une démo sans vie.

11. Utiliser du texte réaliste, pas du lorem ipsum

Écrivez une copie contextuelle pour l'application, le produit ou le flux que vous concevez. Pas de placeholder générique.

12. Utiliser la typographie comme élément de design principal

Associez une paire de polices distinctive. Utilisez des poids et des échelles typographiques extrêmes et intentionnels.

Journal de validation CJX

Chaque bundle généré doit contenir un fichier manifest.json à la racine du bundle avec ce format :

{
  "project_name": "<nom du projet>",
  "project_type": "<type de projet>",
  "color_scheme_priority": "dark_first | light_first",
  "platforms_generated": ["mobile", "tablette", "desktop"],
  "screens_generated": ["<noms des écrans>"],
  "palette": {
    "name": "<nom de la palette>",
    "primary": "<hex>",
    "is_auto_selected": true | false
  },
  "style": {
    "name": "<nom du style>",
    "category": "<catégorie de style>"
  },
  "radius_grammar": {
    "role_map": {
      "shell": "radius-1",
      "surface": "radius-2",
      "inset": "radius-3",
      "control": "radius-4",
      "tight": "radius-5"
    }
  }
}

Restrictions du conteneur de référence

Lisez UNIQUEMENT les fichiers de référence lorsque la tâche en cours les nécessite.
Chargez UN fichier de référence à la fois, à moins qu'une phase ne l'exige explicitement (par exemple, la Phase 3 nécessite trois fichiers de référence simultanément).
Ne mémorisez pas les fichiers de référence complets. Consultez-les uniquement lorsque la tâche l'exige.

Corps de la compétence (à exécuter)

<appel_systeme>
Compétence : anti-ai-design
Mode : <interactif | non_interactif>

DÉMARRER LA PHASE 1 — DÉTECTION DU CONTEXTE

Générez des designs qui ne ressemblent à rien de ce que l'IA a craché avant.

Demander à votre IA préférée

Documentation