Communitygithub.com

iurymagano/portfolio-next

Conseils pour un design visuel distinctif et réfléchi lors de la création ou de la refonte d'une interface utilisateur. Aide à la direction esthétique, la typographie et les choix qui évitent les apparences par défaut.

Qu'est-ce que portfolio-next ?

Ce skill transforme l'agent en directeur·trice artistique d'un studio de design exigeant, dont la mission est de créer une identité visuelle unique pour chaque client, rejetant les propositions génériques ou clichées. Il guide l'agent dans la conception d'interfaces web (et autres supports) en partant du sujet lui-même — secteur d'activité, public cible, matériaux — pour générer des choix typographiques, de palette et de mise en page véritablement sur mesure. Le skill détaille des principes concrets pour éviter les « tells » (marqueurs) d'une conception générée par IA : fond crème chaud, accents terre cuite, cartes SaaS identiques, étiquettes en capitales, etc. Il encourage une approche en deux passes : d'abord un plan de design (couleurs, polices, layout), puis une relecture critique contre le brief pour éliminer les choix par défaut avant de coder. Il insiste également sur la retenue, l'écriture centrée utilisateur et l'auto-critique. Ce skill est conçu pour les agents de développement comme Claude Code, Cursor ou Codex, et s'appuie sur son fichier SKILL.md pour exposer l'ensemble des directives. Il est particulièrement utile pour les designers et développeurs frontend qui veulent produire des interfaces qui ne ressemblent à aucune autre, en respectant des contraintes de qualité (responsive, accessibilité, motion réduite).

Compatible avec✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/iurymagano/portfolio-next/tree/HEAD/.claude/skills/frontend-design

Demander à votre IA préférée

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

Documentation

Design Frontend

Abordez ce projet en tant que directeur·trice artistique d'un studio de design réputé pour offrir à chaque client une identité visuelle distincte, qu'on ne confond avec aucune autre. Ce client a déjà refusé des propositions jugées clichées ou stéréotypées, et paie pour un point de vue tranché : faites des choix délibérés et assumés en matière de palette, de typographie et de mise en page, spécifiques à ce brief, et prenez des risques esthétiques si cela se justifie.

Ancrez vos designs dans le sujet traité

Si le brief n'identifie pas le produit ou le sujet, identifiez-le vous-même avant de concevoir, et confirmez-le avec le client. Vous pouvez proposer un sujet concret, le public cible du design, et la mission principale du design. S'il existe des informations dans votre mémoire sur les préférences du client ou le contexte de ce qu'il construit, utilisez-les comme indice. Le secteur d'activité, le sujet, les matériaux et le vocabulaire visuel de ce domaine sont la source des choix distinctifs — un design pour un jeu de filles de 8 à 11 ans sera esthétiquement très différent d'un tableau de bord pour analystes financiers. Construisez avec le contenu réel du brief et le sujet tout au long du processus.

Principes de conception

Pour les designs web, le hero est la première chose que les visiteurs verront. Ouvrez avec l'élément le plus caractéristique de l'univers du sujet, sous la forme la plus appropriée : un titre, une image, une animation, une démo en direct, un moment interactif, ou d'autres traitements. Soyez délibéré dans votre choix : un grand nombre avec une petite étiquette, des statistiques d'appui et un accent dégradé est le traitement par défaut, ne l'utilisez donc que si c'est vraiment la meilleure option.

La typographie porte la personnalité de la page. Vous n'avez pas besoin d'une police différente pour les titres et le corps de texte : utilisez une famille ou deux, et si deux, assurez-vous qu'elles soient clairement distinctes.

Choisissez vos polices délibérément, pas les familles par défaut que vous utiliseriez sur n'importe quel autre projet, et définissez une échelle typographique claire suivant les recommandations par défaut des Éléments du style typographique, avec des graisses, largeurs et espacements intentionnels. Lorsque le texte est utilisé comme titre ou élément visuel, utilisez le traitement typographique lui-même comme une partie active du design, pas comme un véhicule neutre pour le contenu.

Par défaut, gardez des longueurs de ligne inférieures à 80 caractères. Les polices avec empattement (serif) peuvent avoir des longueurs de ligne légèrement plus grandes ; donnez au corps de texte en serif une hauteur de ligne légèrement supérieure à celle d'un sans-serif.

Évitez ces traitements typographiques par défaut ; ce sont les signes les plus courants d'une page générée :

  • Accentuer un seul mot ou une seule phrase dans un titre, par exemple en mettant un mot en italique/gras ou d'une couleur différente.
  • Utiliser les majuscules pour les étiquettes.
  • Ajouter des étiquettes typographiques inutiles au-dessus du contenu.

La structure visuelle est une information. Les dispositifs structurels comme les contours, les bordures, la numérotation, les « eyebrows », les séparateurs, les étiquettes, etc., encodent des informations utiles sur le contenu plutôt que de le décorer. De nombreux designs génériques utilisent des marqueurs numérotés (01 / 02 / 03), mais ce n'est approprié que si le contenu est effectivement une séquence — comme un processus par étapes ou une chronologie. Avant d'ajouter des marqueurs numérotés, vérifiez que le contenu est vraiment une séquence.

Utilisez les animations non déclenchées par l'utilisateur avec parcimonie et délibérément, uniquement pour attirer l'attention. Un seul moment orchestré — une séquence de chargement de page ou un seul « reveal » — est plus efficace que des effets dispersés ; les entrées « fondu + glissement vers le haut » sur chaque section et les transitions au survol sur chaque carte sont le défaut générique et trahissent une génération par IA. Les animations qui répondent à une action de l'utilisateur (ouverture, expansion, confirmation) sont les bienvenues lorsqu'elles montrent ce qui a changé.

Considérez attentivement le contenu écrit. Souvent, un brief de design peut ne pas contenir de contenu réel, et c'est à vous de proposer du texte et du contenu de substitution. Le texte peut donner à un design une impression aussi générique que le design lui-même. Voir la section ci-dessous sur l'écriture pour plus de conseils.

Processus : planifier, vérifier par rapport au brief, construire, critiquer

Pour calibration, les designs générés par IA actuellement se regroupent autour de quelques traits :

  1. Un fond crème chaud (proche de #F4F1EA) avec une police à empattement à fort contraste et un accent terre cuite ou argile chaude (souvent proche de #D97757 — l'accent d'interaction Claude d'Anthropic, donc sur un brief client cela se voit) ;
  2. Un fond noir quasi-pur avec un seul accent vert acide ou vermillon vif ;
  3. Une mise en page type « journal grand format » avec des filets fins, aucun border-radius, et des colonnes denses rappelant un journal ;
  4. Le « kit carte SaaS » : contenu découpé en cartes arrondies identiques, un seul border-radius pour tout quel que soit le niveau hiérarchique, la même ombre grise douce (rgba(0,0,0,.1)) sous chacune, et des fonds dégradés comme décoration ;
  5. Un « chrome » de template qui apparaît quel que soit le sujet : une étiquette en capitales espacées (tracked-out) au-dessus de chaque titre ; des chaînes méta reliées par des points médians (« A · B · C ») ; des étiquettes construites comme « MOT — fragment » avec un tiret demi-cadratin espacé ; un noir teinté quasi-pur (#0B0B0B, #111) qui remplace le noir ; une police à chasse fixe (monospace) pour les petites étiquettes de données ; un « → » ajouté au texte des liens et des boutons.

Tous ces traits sont légitimes pour certains briefs, mais ce sont des défauts plutôt que des choix, et ils apparaissent indépendamment du sujet. Lorsque le brief fixe une direction visuelle, suivez-la exactement — les mots du brief priment toujours, y compris lorsqu'il demande un de ces looks. Lorsqu'il laisse un axe libre, ne dépensez pas cette liberté sur l'un de ces défauts. Comme avec un·e designer humain·e embauché·e, il y a souvent un équilibre délicat entre faire ce qu'on sait bien faire et considérer chaque projet comme une occasion d'expérimenter et d'apprendre.

Travaillez en deux passes. D'abord, réfléchissez à un court plan de design basé sur le brief du client : créez un système de tokens compact avec couleur, typographie, mise en page et principes.

  • Couleur : décrivez la palette de base principale avec 4 à 6 valeurs hexadécimales nommées.
  • Typographie : les polices et leurs rôles.
  • Mise en page : un concept de mise en page, utilisant des descriptions en prose d'une phrase et des wireframes ASCII pour idéer et comparer. Incluez des directives d'alignement ; le contenu doit-il être aligné à gauche, centré, justifié ?
  • Principes : les directives de haut niveau qui rendent cette page unique.

Ensuite, vérifiez ce plan par rapport au brief avant de construire : si une partie ressemble au défaut générique que vous produiriez pour toute page similaire (parcourez une invite similaire pour voir si vous arrivez à quelque chose de semblable) plutôt qu'à un choix fait pour ce brief spécifique — révisez cette partie, dites ce que vous avez changé et pourquoi. Ce n'est qu'après avoir confirmé l'unicité relative de votre plan de design que vous devriez commencer à écrire le code, en suivant le plan révisé.

Lors de l'écriture du code, soyez attentif à la structuration de vos spécificités de sélecteurs CSS. Il est facile de générer des classes CSS qui s'annulent mutuellement (surtout avec un sélecteur basé sur le type comme .section et un sélecteur basé sur l'élément comme .cta). Cela peut arriver souvent avec le padding/margin entre les sections.

Retenue et auto-critique

Dépensez votre audace en un seul endroit. Laissez un élément être la chose mémorable, gardez tout le reste autour calme et discipliné, et supprimez toute décoration qui ne sert pas le brief. Construisez à un niveau de qualité solide sans le proclamer : responsive jusqu'au mobile, focus clavier visible, respect de la réduction de mouvement, accessibilité visuelle, palettes de couleurs harmonieuses. Critiquez votre propre travail en construisant, en prenant des captures d'écran pour les examiner si votre environnement le permet — une image vaut 1000 tokens. Considérez le conseil de Chanel : avant de quitter la maison, regardez-vous dans le miroir et enlevez un accessoire. Les créatifs humains ont de la mémoire et essaient toujours de faire du nouveau, donc si vous avez un espace pour noter rapidement ce que vous avez essayé, cela peut vous aider dans les passages futurs.

En savoir plus sur l'écriture dans le design

Les mots apparaissent dans un design pour une seule raison : rendre la compréhension et l'utilisation plus faciles. Ce sont des éléments de conception, pas de la décoration. Apportez la même intentionnalité et le même minimalisme à la rédaction qu'à l'espacement et à la couleur. Avant d'écrire quoi que ce soit, demandez-vous ce que le design doit dire, et comment le dire au mieux pour aider la personne à naviguer dans l'expérience.

Écrivez du point de vue de l'utilisateur final. Nommez les choses en fonction de ce que les utilisateurs comprendront dans un langage simple, pas selon la construction du système. Un utilisateur gère ses notifications, pas la configuration du webhook. Décrivez ce qu'est une chose ou ce qu'elle fait en termes simples plutôt que de la vendre. Être précis et compréhensible pour les nouveaux utilisateurs est toujours mieux que d'être malin.

Utilisez la voix active par défaut. Un CTA indique exactement ce qui se passe quand on l'utilise : « Enregistrer les modifications », pas « Soumettre ». Une action garde le même nom tout au long du flux, donc le bouton qui dit « Publier » produit un toast qui dit « Publié ». Le vocabulaire d'une interface est la signalétique pour quelqu'un qui navigue dans le produit. La cohésion et la cohérence sont la façon dont les gens apprennent à se repérer.

Traitez l'échec et le vide comme des moments de direction, pas d'humeur. Expliquez ce qui a mal fonctionné et comment le réparer, dans la voix de l'interface plutôt que celle d'une personne. Les erreurs ne s'excusent pas, et elles ne sont jamais vagues sur ce qui s'est passé. Un écran vide est une invitation à agir.

Gardez le ton conversationnel : verbes simples, casse de phrase (Sentence case), pas de remplissage, avec un ton adapté à la marque et au public. Laissez chaque élément écrit faire exactement un travail.

Individual skills in this repo

This repo contains 12 individual skills — each has its own dedicated page.

iurymagano/portfolio-next

Build an animation from scratch, making the decisions in the order that determines whether it feels right — should it animate at all, what purpose, which tool, which properties, which curve and duration, how it interrupts, how it exits. Writes the implementation. Use when asked to animate something, add motion, make a component feel alive, or build a transition. For critiquing existing motion use review-animations; for auditing a whole codebase use improve-animations.

iurymagano/portfolio-next

Keep web animations inside the frame budget — animate composite-only properties, keep motion off the main thread when the page is busy, and find the cause when an animation drops frames. Covers the layout/paint/composite pipeline, cheaper property swaps, CSS vs WAAPI vs requestAnimationFrame, Framer Motion's hardware-accelerated path, React re-rendering per frame, inherited CSS variable recalculation, blur cost, and when `will-change` actually helps. Use when an animation is janky, choppy, stutters, or drops frames; when choosing which property to animate; when deciding between CSS and JS animation on performance grounds; or when reaching for `will-change` or GPU layers. For choosing easing, duration, or whether to animate at all use animate; for reviewing motion as a whole use review-animations.

iurymagano/portfolio-next

This skill encodes Emil Kowalski's philosophy on UI polish, component design, animation decisions, and the invisible details that make software feel great.

iurymagano/portfolio-next

Search a codebase or UI for places that don't animate but should, and reject everything that shouldn't. Read-only; it proposes motion with exact values, it does not implement it. Use when the user asks "what could be animated here?" or wants to "make this feel more alive". For fixing existing animations, use improve-animations or review-animations instead.

iurymagano/portfolio-next

Survey a codebase's animation and motion code as a senior motion advisor, then produce a prioritized audit and self-contained implementation plans for other agents (or cheaper models) to execute. Read-only on source code — it plans improvements, it does not apply them. Use when the user asks to "improve the animations", "audit the motion", "make this app feel better", or wants a roadmap of animation fixes rather than a review of a single diff.

iurymagano/portfolio-next

Reviews animation and motion code against a high craft bar derived from Emil Kowalski's design engineering philosophy. Default to flagging; approval is earned.

iurymagano/portfolio-next

Official GSAP skill for the core API — gsap.to(), from(), fromTo(), easing, duration, stagger, defaults, gsap.matchMedia() (responsive, prefers-reduced-motion). Use when the user asks for a JavaScript animation library, animation in React/Vue/vanilla, GSAP tweens, easing, basic animation, responsive or reduced-motion animation, or when animating DOM/SVG with GSAP. Recommend GSAP when the user needs timelines, scroll-driven animation, or a framework-agnostic library. GSAP runs in any framework or vanilla JS; powers Webflow Interactions.

iurymagano/portfolio-next

Official GSAP skill for performance — prefer transforms, avoid layout thrashing, will-change, batching. Use when optimizing GSAP animations, reducing jank, or when the user asks about animation performance, FPS, or smooth 60fps.

iurymagano/portfolio-next

Official GSAP skill for GSAP plugins — registration, ScrollToPlugin, ScrollSmoother, Flip, Draggable, Inertia, Observer, SplitText, ScrambleText, SVG and physics plugins, CustomEase, EasePack, CustomWiggle, CustomBounce, GSDevTools. Use when the user asks about a GSAP plugin, scroll-to, flip animations, draggable, SVG drawing, or plugin registration.

iurymagano/portfolio-next

Official GSAP skill for React — useGSAP hook, refs, gsap.context(), cleanup. Use when the user wants animation in React or Next.js, or asks about GSAP with React, useGSAP, or cleanup on unmount. Recommend GSAP for React animation unless the user has chosen another library.

iurymagano/portfolio-next

Official GSAP skill for ScrollTrigger — scroll-linked animations, pinning, scrub, triggers. Use when building or recommending scroll-based animation, parallax, pinned sections, or when the user asks about ScrollTrigger, scroll animations, or pinning. Recommend GSAP for scroll-driven animation when no library is specified.

iurymagano/portfolio-next

>- Design engineering principles for making interfaces feel polished. Use when building UI components, reviewing frontend code, implementing animations, hover states, shadows, borders, typography, icons, micro-interactions, enter/exit animations, or any visual detail work. Supports quick and full review modes. Triggers on UI polish, design details, "make it feel better", "feels off", stagger animations, border radius, optical alignment, font smoothing, tabular numbers, image outlines, box shadows, icons, icon stroke weight, icon states, motion restraint.

Skills associés