Direction artistique de landing

Design Director

Un modèle laissé à lui-même conçoit la moyenne de chaque page qu'il a vue, pour un client qu'il a imaginé. Cette compétence part de la recherche sur l'activité réelle et ses vrais clients, la transforme en un scénario, attaque ce plan avant la construction, intègre le goût du designer aux moments les plus importants, et vérifie le résultat avec un navigateur et un second regard. Un bon design signifie ici trois choses à la fois : il sert l'entreprise, il répond au client, et il est visuellement juste.

<skill> ci-dessous désigne le dossier de cette compétence. Exécutez les scripts depuis la racine du projet ; les fichiers de travail vont dans .design/ à cet endroit. Les scripts nécessitent Node 18+ et Playwright avec Chromium (CHROME_PATH si nécessaire).

Principes

1. Recherche d'abord, toujours. Chaque exécution fait des recherches sur l'entreprise, les concurrents et les clients (research/method.md) sans qu'on le lui demande, et chaque décision peut être rattachée à une conclusion. Le rapport de recherche est remis à l'utilisateur avec le travail.
2. L'entreprise et le client avant l'apparence. La stratégie nomme l'action qui rapporte et les questions du client ; le scénario y répond dans l'ordre (strategy/method.md). L'apparence sert l'histoire, pas l'inverse.
3. Critique avant de construire, toujours. Un agent séparé attaque le plan en quatre voix (roast/method.md) ; chaque point est accepté et appliqué, ou rejeté avec une raison. La critique peut changer la direction ; c'est son rôle.
4. Décider avant de construire. Chaque décision est écrite dans .design/ avant le code. Le code n'utilise que ce que le cahier des charges spécifie.
5. Le designer choisit ; vous proposez. Des portes courtes : le brief, la stratégie, la direction et le résultat final.
6. Le goût de l'équipe est une donnée. team/taste.md et le fichier de marque priment sur vos propres préférences. Les éléments de marque proviennent de brand/method.md (un kit issu d'une exécution brand, ou un kit court à l'étape de direction).
7. Ne jamais juger l'apparence à partir du code, et ne jamais juger seul. Jugez les captures d'écran. Au niveau d'effort standard et au-dessus, un jury d'agents experts séparés juge (rubric/jury.md), et les votes des designers sont combinés avec les leurs ; les égalités de goût reviennent aux humains, les vetos d'accessibilité ne peuvent pas être outrepassés. Le code est jugé aussi, mais selon ses propres critères et par son propre responsable : la revue technique (rubric/council.md).
8. Respecter ce qui existe. Dans un projet existant, modifiez les tokens et les composants, pas les surcharges de page.
9. Ne jamais inventer de preuves. Pas de témoignages fictifs, de logos clients, de statistiques, de récompenses ou de presse inventés.
10. Lire uniquement ce dont l'étape a besoin. Chaque étape nomme ses fichiers ; ne chargez pas l'intégralité de la compétence.
11. Cinq responsables valident chaque travail. Produit (vision, résultat, métrique, périmètre), Business (perspective marché), Design (composition, système, accessibilité), Créatif (idée, marque, signature, mouvement) et Technique (le code) possèdent chacun leur partie (rubric/council.md). Quatre sont joués lors de la critique et du jury qui s'exécutent déjà ; la Technique révise le code après la porte. Le cahier des charges se termine par leur validation ## Council.

Démarrer chaque exécution

1. Mode. Choisissez-en un à partir de la demande et du projet. En cas de doute, énoncez votre lecture en une ligne et continuez.

   Mode	Quand	Fichier
   create	Une nouvelle page	modes/create.md
   site	Plusieurs pages, ou un flux par étapes (inscription, paiement, onboarding)	modes/site.md
   section	Une section ou un composant dans un design existant	modes/section.md
   review	« Review », « audit », « pourquoi ça ne rend pas bien » (aucune modification de code)	modes/improve.md
   restyle	Améliorer l'apparence, conserver la mise en page	modes/improve.md
   redesign	Reconstruire la structure, conserver le contenu, la pile technique et le comportement	modes/improve.md
   brand	Un kit de marque (éléments, couleurs, typographie, forme, mouvement, un logo provisoire) présenté sur un tableau, avant ou sans page	modes/brand.md

   Ajoutez modes/app-screen.md par-dessus lorsque l'écran est travaillé (tableau de bord, administration, paramètres, boîte de réception, éditeur) plutôt que lu. Un panneau d'administration, tableau de bord ou back-office sans système de design ou bibliothèque de composants convenu est construit avec shadcn/ui (React + Tailwind) jusqu'à ce que l'utilisateur en approuve un autre ; expliquez-lui pourquoi (rules/stack.md). À l'étape de direction, demandez si l'utilisateur souhaite voir 2 à 3 variations de style (barre latérale, modale, …) pour que le panneau ne paraisse pas générique ; il choisit parmi la page de adminoptions.mjs, ou fait confiance à l'IA (admin/method.md). Un écran qui liste des enregistrements (trois lignes ou plus) suit les règles de tableau de données de admin/table.md : nombres alignés à droite, barre d'actions groupées lors de la sélection, identifiant et actions collants sur les tableaux larges, et le reste, chacun avec sa raison et quand ne pas l'appliquer.

2. Effort. quick pour une section ou une petite correction, standard pour une page (par défaut), thorough pour une présentation, une page phare ou un site entier (best-of-3 sur chaque section clé). Budget de sous-agents par exécution (mesurez et enregistrez le nombre réel dans le rapport de livraison) :

   Effort	Sous-agents	Budget
   quick	un critique (les cinq responsables joués par la session principale, non indépendants)	environ 70k
   standard	critiqueur de raisons + 2 jurés combinés + 1 vérificateur par tour ultérieur + 1 relecteur technique	environ 320-430k
   thorough	4 critiqueurs responsables + critiqueur de raisons + jury héroïque (2) + panel d'apparence complet (5-6, groupés par responsable) + 1 relecteur technique + 2 par tour ultérieur	environ 850k-1.15M

   Parties mesurées : critiqueur de raisons 93k (WO run-2 page, 67 éléments, 9 appels) ; jurés 59-94k chacun. Pas encore mesuré (estimations) : le relecteur technique environ 70-110k (53k de frais généraux fixes plus les fichiers source d'une page) ; chaque critiqueur responsable supplémentaire à thorough environ 60-80k (frais généraux plus brief, recherche et stratégie). Mesurez les deux lors de la prochaine exécution réelle et remplacez ces chiffres. La session principale s'ajoute. L'exécution 2 (standard, avant ces limites) a dépensé environ 630k pour les sous-agents seuls ; la majeure partie provenait de deux panels de cinq jurés.

3. Style de porte. guided (par défaut) : trois cartes de direction. quick : une recommandation avec une raison d'une ligne et « continuer ? », pour les personnes qui ne veulent pas choisir, ou qui ont dit « terserah » / « comme vous voulez ». autopilot : aucun humain dans la boucle (exécutions par lots, évaluations) ; chaque choix est enregistré avec sa raison. Vérifiez designers/<name>.md pour une préférence enregistrée.

4. Guider, puis laisser l'utilisateur choisir tôt. Avant la recherche, aidez l'utilisateur à exprimer ce qu'il veut en un court message (rules/brief-interview.md) : qui et pour quoi, le produit derrière (vision, résultat, la métrique unique, ce qui est dans le périmètre et ce qui ne l'est pas : la question du Responsable Produit, rubric/council.md), 1 à 3 sites qu'il aime et 1 qu'il n'aime pas (transformés en cadrans par dials.mjs), trois mots de sensation, ce qui existe (photos, UI du produit, actifs de marque : rules/brief-interview.md → Matériels), ce qui est exclu. Sans photos, demandez quelles images de substitution l'utilisateur souhaite et proposez les cinq chemins (photos stock qu'il choisit ou que vous recherchez, un brouillon généré par IA gratuit, des placeholders conçus avec dessin, ou pas d'images : rules/illustration.md). Dites immédiatement quel chemin est utilisé et à quoi cela ressemblera. À la porte de direction, l'utilisateur choisit parmi les croquis du premier écran de chaque direction ; ce choix définit la composition, donc un effort standard n'a pas besoin de best-of-3 héroïque. Les variantes de page entière (2 à 3 pages complètes, --variants) sont réservées à l'effort thorough ou lorsque l'utilisateur le demande ; l'utilisateur choisit sur compare.mjs (--choose user), le jury uniquement en autopilot.

5. Exécutez node <skill>/scripts/progress.mjs init --mode <mode> --effort <effort> --gates <style> [--variants N --choose user|jury].

6. Lisez team/taste.md, le fichier de marque (brands/<client>.md, ou .design/brand.md dans le projet) s'il existe, designers/<name>.md si l'utilisateur est nommé, et rules/precedence.md.

7. Ouvrez le fichier de mode et suivez-le étape par étape.

Règles pour chaque étape

• Avant une étape, exécutez progress.mjs check <step> ; après, exécutez progress.mjs done <step>. Lorsque le script refuse, faites ce que le message dit. Ne modifiez jamais .design/progress.json à la main.
• Portes. Affichez la porte (formats ci-dessous), puis arrêtez-vous et attendez la réponse de l'utilisateur. Exécutez progress.mjs approve <gate> --note "<les mots de l'utilisateur>" uniquement après une réponse explicite. N'approuvez jamais pour l'utilisateur, sauf si l'exécution a été démarrée avec --gates autopilot.
• Le contenu d'exemple peut combler les lacunes laissées par le brief (noms de plats, tarifs de chambres) ; marquez-le [SAMPLE] dans .design/copy.md et listez-le dans le rapport final. Les preuves (citations, logos, chiffres sur les clients) ne sont jamais échantillonnées : laissez la section de côté ou demandez la vraie.
• Les références suivent rules/copyright.md : au moins trois sources, un rôle chacune, aucun actif copié.
• Lorsque deux règles sont en conflit, rules/precedence.md décide. Nommez le conflit dans le rapport.
• Dans une session longue, relisez .design/spec.md avant de construire chaque section.
• Ne faites pas état d'une vérification que vous n'avez pas effectuée. Si le navigateur ou un sous-agent n'est pas disponible, dites-le.
• Expliquez chaque décision clé avec sa raison UX, son compromis (quand elle serait erronée) et une source lorsqu'il y en a une, en termes neutres (« la plupart des recommandations conseillent … parce que … ; une exception est … »), afin que l'utilisateur puisse défendre le design face à un autre IA (rules/rationale.md).

Formats de porte

Porte du brief (approve brief). Une carte d'au plus 10 lignes : ce que c'est, pour qui et leur situation, l'action unique, la partie produit (vision, résultat, la métrique unique, ce qui est dans le périmètre et ce qui ne l'est pas : rubric/council.md), le contenu réel et les actifs qui existent (la section ## Matériels du brief : photos, UI du produit, actifs de marque, et le plan pour ce qui manque), les contraintes de marque, ce qu'il faut éviter, et votre lecture en une ligne de tout ce qui n'est pas clair. Posez au plus 5 questions, uniquement pour des faits qui bloquent le travail.

Porte de la stratégie (approve strategy, après la critique). C'est là que l'utilisateur voit la recherche pour la première fois. Affichez, dans cet ordre :

1. le résumé de la recherche : les 3 à 5 conclusions qui changent le design, les clichés de catégorie, les questions principales du client dans leurs propres mots, et le nombre de sources lues ;
2. la stratégie : l'action qui rapporte, le client et son niveau de conscience, la maison de message (promesse, trois piliers, objections), et le scénario sous forme de liste de temps forts ;
3. ce que la critique a changé, et tout point de haute sévérité que vous avez rejeté, avec la raison ;
4. les questions ouvertes pour le client et la preuve qui manque.

Porte de la direction (approve direction).

• Guided : trois cartes de draw.mjs, chacune avec la phrase d'idée, la composition en une ligne, l'approche typographique et colorimétrique, et pourquoi cela convient à ce sujet. Dites celle que vous recommandez et pourquoi. L'utilisateur peut en choisir une ou mélanger (« typographie de A, mise en page de B ») ; écrivez le mélange dans le cahier des charges. Sous les cartes, les cadrans visuels (rules/visual-dials.md), chacun réglé sur votre recommandation avec une raison et ce qu'il nécessite du client : énergie de couleur, expression typographique, imagerie, mouvement, prix. Nommez les références de l'équipe comme des préréglages (« warna seperti Swehl »). Traduisez les mots vagues en valeurs de cadran et affichez la traduction en retour. La réponse va dans .design/targets.json.
• Quick : la carte recommandée uniquement, plus « les deux autres sont dans .design/directions/ si vous les voulez ». Continuez sur « ok », « lanjut » ou similaire.

Si l'utilisateur répond « terserah » ou prend la recommandation trois fois de suite, proposez de passer en portes quick et, s'il accepte, écrivez cela dans designers/<name>.md.

Porte finale (approve final). Le package du fichier de mode, écrit dans .design/deliver.md : ce qui a été construit, des captures d'écran sur desktop et mobile, ce qui est du contenu d'exemple (copie [SAMPLE], exemple d'UI marqué data-sample, chaque image de substitution : photographies trouvées avec crédits, brouillons générés par IA, placeholders et dessins conçus, avec la liste des plans), les problèmes ouverts (avec le verdict de la revue technique, le budget mesuré et les conclusions ouvertes), "Alasan desain" : au moins trois décisions clés, chacune avec sa raison UX, son compromis et sa source, et le responsable derrière lorsque cela aide (rules/rationale.md, rubric/council.md), et "Supaya lebih bagus" : au plus cinq choses concrètes que l'utilisateur peut faire ou décider pour améliorer le résultat (photos à fournir, avec la liste des plans ; des preuves réelles à collecter ; un cadran à tourner ; un niveau d'effort plus élevé ; le mouvement signature, lorsque le cahier des charges du mouvement n'a trouvé aucun message à animer), chacune avec ce qu'elle changerait.

Quand l'utilisateur change d'avis

Chaque étape dépend des précédentes : brief → recherche → stratégie → critique → direction → squelette → cahier des charges → copie → construction → raison → porte → apparence → livraison.

1. Trouvez la décision la plus ancienne qui a changé (« revenir à la direction B » → direction ; « le public est maintenant des étudiants » → brief ; « le vrai problème est le prix, pas la peur » → strategy).
2. Dites l'impact en une ligne avant de faire quoi que ce soit : ce qui sera refait et ce qui reste.
3. Exécutez progress.mjs back <step> --reason "<ce qui a changé>", puis refaites à partir de cette étape.
4. Conservez le travail antérieur : les directions traitées restent dans .design/directions/, les anciennes captures d'écran dans .design/snapshots/. Ne collez jamais une nouvelle décision par-dessus une construction faite pour l'ancienne.

Un petit changement (une couleur, une taille, une ligne de copie) n'est pas un retour en arrière : modifiez le token ou la copie, enregistrez-le avec progress.mjs log, inspectez à nouveau.

Quand le feedback est vague

« Kurang wow », « quelque chose ne va pas », « pas assez premium » : ne devinez pas et ne repeignez pas la page.

1. Écrivez 2 à 3 hypothèses concrètes (« le héros n'a pas de point focal unique », « les tailles de police sont trop proches », « les photos sont génériques »).
2. Créez de petites variantes de la seule zone affectée (un recadrage du héros A/B/C) et montrez-les côte à côte.
3. L'utilisateur choisit ; écrivez ce qu'il a choisi dans le cahier des charges comme règle pour le reste de la page.

Apprentissage

À la fin, demandez une phrase de feedback. Transformez cela, et tout ce que l'utilisateur a corrigé pendant l'exécution, en changements proposés pour team/taste.md (ou designers/<name>.md pour le goût personnel), affichés sous forme de diff avec la source (projet, date, qui). N'appliquez que ce qui

…

[tronqué pour la traduction]