Molveau
Tous les guides

Flux de travail IA8 min de lecture

Les compétences Claude Code que j'utilise vraiment

Le catalogue complet de ma pile de compétences, avec le comment et le pourquoi de chacune — discipline de processus, partenaires de réflexion, la suite de verbes design, le mouvement GSAP, les recherches, et comment écrire les vôtres.

Dans le guide sur le cerveau IA, j'expliquais les trois couches : instructions, mémoire, compétences. Celui-ci ouvre complètement le tiroir des compétences. Une compétence est un guide markdown que l'IA charge quand une tâche correspond; après un an à construire des sites clients de cette façon, voici chaque compétence qui a gagné sa place permanente — ce qu'elle fait, comment je l'utilise, et pourquoi elle reste.

Une règle alimente tout : si une compétence peut s'appliquer à la tâche, la charger avant de faire quoi que ce soit. La compétence fixe l'approche. L'improvisation est exactement ce que les compétences existent pour empêcher.

1. Discipline de processus

D'une suite publique appelée Superpowers — le squelette de chaque fonctionnalité :

  • Brainstorming — la conception avant le code : questions une à la fois, approches avec compromis, approbation d'un devis écrit avant de rien construire. Pourquoi : élimine le « j'ai construit la mauvaise chose avec assurance », le mode d'échec le plus coûteux de l'IA.
  • Rédaction de plans — transforme le devis approuvé en tâches de petite taille avec étapes de vérification. Pourquoi : les plans survivent aux frontières de session; l'intuition, non.
  • Développement piloté par les tests — rouge-vert-refactorisation, imposé; aucune implémentation avant un test qui échoue. Pourquoi : quand une IA écrit le code, le test est le devis contre lequel elle ne peut pas argumenter.
  • Débogage systématique — reproduire, réduire, formuler une hypothèse, instrumenter — avant tout correctif. Pourquoi : bloque les correctifs plaqués qui traitent le symptôme.
  • Développement par sous-agents — chaque tâche va à une sous-session fraîche au contexte choisi; la session principale orchestre. Pourquoi : les longs contextes se dégradent; les frais, non.
  • Vérification avant complétion — pas de « terminé » sans exécuter les contrôles et montrer la sortie. Pourquoi : la compétence la plus rentable de la pile. Un fichier écrit n'est pas une fonctionnalité qui marche.

2. Partenaires de réflexion

Les compétences que j'utilise avant et autour du code — planification, architecture, compréhension :

  • Grill me — l'IA m'interroge sans relâche sur un plan jusqu'à ce que chaque branche de l'arbre de décision soit résolue. Comment : avant de m'engager sur tout devis ambitieux. Pourquoi : elle trouve les décisions que je ne savais pas ne pas avoir prises.
  • Grill with docs — le même interrogatoire, mais confronté au modèle du domaine et aux décisions passées du projet, en mettant les documents à jour à mesure que les réponses tombent. Comment : sur les bases de code avec un CONTEXT.md et des registres de décisions. Pourquoi : la documentation reste vraie pendant que le plan s'affine — deux corvées, une session.
  • Design an interface — des sous-agents parallèles produisent des designs radicalement différents du même module, puis on compare. Comment : chaque fois que la forme d'un module est réellement ouverte. Pourquoi : le premier design est rarement le meilleur; payer trois brouillons d'avance coûte moins qu'une réécriture.
  • Zoom out — force l'IA à cesser de décrire des arbres et à décrire la forêt. Comment : quand je suis perdu dans une partie inconnue d'une base de code. Pourquoi : l'orientation d'abord, le détail ensuite.
  • Teach — explique un concept en utilisant le vrai code de l'espace de travail comme matériel. Pourquoi : les leçons ancrées dans votre propre dépôt restent; les tutoriels génériques, non.
  • Improve — un survol en lecture seule, en conseiller senior, qui produit des plans d'amélioration priorisés et autonomes qu'une autre session exécutera. Pourquoi : séparer le diagnostic de la chirurgie garde les deux honnêtes.
  • Improve codebase architecture — chasse les occasions de consolidation et d'approfondissement, guidée par le langage du domaine et les registres de décisions du projet. Comment : une passe d'architecture périodique, pas un outil quotidien. Pourquoi : l'entropie est constante; ceci est la riposte planifiée.
  • Request refactor plan — m'interviewe sur une refactorisation, puis produit un plan de petits commits sûrs et le dépose comme ticket GitHub. Pourquoi : les refactorisations big-bang meurent; vingt commits ennuyeux survivent.
  • QA — une session de rapport de bogues en conversation : je décris les problèmes en mots simples, l'IA explore le code en arrière-plan et dépose de vrais tickets GitHub. Pourquoi : la friction est ce qui empêche les bogues d'être notés.
  • Diagnose — la boucle disciplinée pour les bogues coriaces et les régressions de performance : reproduire, réduire, hypothèse, instrumenter, corriger, test de régression. Pourquoi : les bogues coriaces ne cèdent pas à l'intuition.
  • Handoff — compacte une longue session en un document que la suivante reprend. Pourquoi : les fenêtres de contexte finissent; le travail, non.
  • Find skills — cherche des compétences installables quand un besoin émerge. Pourquoi : quelqu'un a généralement déjà encodé le flux de travail.

3. La couche de goût

Les miennes, et la raison pour laquelle deux sessions à des semaines d'écart produisent un travail identique :

  • Goût design — le fichier canonique : règles de typographie (65 caractères par ligne, deux familles), règles de mouvement (transform et opacity seulement, sous 300 ms), et les jetons de design par projet. Invoqué avant tout travail d'interface, sans exception. Pourquoi : le goût gardé dans un fichier se compose; le goût gardé dans ma tête s'évapore à chaque session.
  • Index d'inspiration design — une carte de recherche du besoin vers la source : référence de page de tarifs, idées de barre de navigation, exemples de mouvement. Pourquoi : « pour X, va à Y » bat une heure de défilement. Les sites qu'il contient ont leur propre guide avec captures d'écran.
  • Design frontend — des garde-fous contre l'esthétique IA générique lors de la construction de nouvelles interfaces. Pourquoi : le look IA par défaut est le même partout; les défauts sont l'ennemi.
  • Design web — la référence large pour l'architecture CSS, la typographie, l'accessibilité. Pourquoi : le filet généraliste quand aucune compétence précise ne s'applique.
  • Teach impeccable — une configuration unique qui rassemble le contexte design d'un projet et l'enregistre dans la configuration de l'IA. Pourquoi : exécutée une fois par projet pour que chaque passe de design ultérieure démarre informée.

4. Les verbes design — un verbe, une passe

Une suite de compétences design à usage unique. Parce que chacune fait exactement un travail, la passe se termine vraiment — un prompt « revois tout » ne revoit rien.

Les passes de revue que j'exécute sur presque chaque fonctionnalité :

  • Audit — audit complet de l'interface : accessibilité, performance, thèmes, adaptabilité, avec cotes de gravité.
  • Critique — revue de design avec raisons : hiérarchie, architecture d'information, résonance émotionnelle.
  • Polish — la dernière passe avant la livraison : alignement, espacement, détails de cohérence.
  • Harden — états d'erreur, débordements de texte, cas limites i18n; blindage pour la production.
  • Distill — retirer la complexité jusqu'à ce qu'il ne reste que l'essence.

Les cadrans que je tourne quand un design penche du mauvais côté :

  • Arrange — mise en page, espacement et rythme quand une grille devient monotone.
  • Adapt — tailles d'écran, appareils, contextes.
  • Animate — mouvement justifié et micro-interactions, ajoutés après que le design fonctionne.
  • Bolder / Quieter — cadrans opposés : amplifier un design trop sage, ou calmer un design agressif.
  • Colorize — de la couleur stratégique pour les interfaces monochromes.
  • Clarify — les textes UX : libellés, erreurs, microtextes.
  • Delight — les touches de personnalité qui rendent une interface mémorable.
  • Onboard — premières utilisations et états vides.
  • Optimize — chargement, rendu, taille des paquets.
  • Overdrive — des implémentations délibérément ambitieuses : shaders, physique à ressorts, tableaux virtuels à 60 images par seconde. Utilisé avec parcimonie, sur le seul moment par site qui le mérite.

Les bâtisseurs de système de design — la paire qui garde une bibliothèque de composants en santé :

  • Extract — récolte les motifs répétés en composants réutilisables et jetons de design. Comment : après quelques fonctionnalités livrées, les miner. Pourquoi : un système de design grandit par extraction, pas par invention préalable.
  • Normalize — la direction inverse : ramène les écrans qui ont dérivé dans le rang du système. Pourquoi : la dérive est silencieuse; ceci la rend visible et la corrige.

5. Mouvement — la suite GSAP

Huit compétences officielles, découpées pour que l'IA ne charge que la partie dont la tâche a besoin : core (interpolations, courbes, décalages), timeline (séquençage), ScrollTrigger (animation liée au défilement et épinglage — l'histoire défilante de ce site s'appuie dessus), react (useGSAP, nettoyage au démontage), plugins (Flip, Draggable, SplitText et compagnie), performance (transformations seulement, pas de bousculade de mise en page), utils, et frameworks (Vue/Svelte). Pourquoi une suite compte : les bogues de mouvement sont généralement le mauvais usage d'une API précise, et la compétence précise connaît les règles de cette API.

6. Recherches et génération

  • Base de données UI/UX — une collection interrogeable hors ligne : 84 styles, 161 palettes, 73 accords de polices, 99 lignes directrices UX. « Une palette pour une marque de santé chaleureuse » devient une requête, pas une intuition.
  • Documentation à jour — va chercher la documentation du jour pour la version de bibliothèque réellement installée. Pourquoi : les données d'entraînement vieillissent; vos versions de dépendances s'en moquent.
  • Recherche et génération de composants — la famille 21st.dev : chercher le registre communautaire avant d'écrire un widget à la main, générer des variantes d'interface depuis un prompt, publier ses propres composants et thèmes en retour. Pourquoi : le composant le plus rapide est celui déjà construit.

Et les icônes?

Pas une compétence — une liste de sources. Les ensembles d'icônes, polices, photos et ressources 3D vivent dans le guide des ressources design gratuites; quelle galerie ouvrir pour quel besoin vit dans le guide des sites de composants et d'inspiration. L'index d'inspiration ci-dessus est ce qui aiguille entre les deux.

Écrire les vôtres

Chaque compétence des sections 3 et 4 a commencé comme une correction donnée deux fois à l'IA. Le gabarit reste petit :

---
name: ma-competence
description: Quand l'invoquer - soyez précis, l'IA se déclenche là-dessus
---

## Règles
- Les choses que vous répétez sans cesse, écrites une fois.
- Les chiffres concrets battent les adjectifs : « sous 300 ms », pas « rapide ».

## Liste de contrôle
- [ ] Les étapes obligatoires, dans l'ordre.

Commencez par une seule : la liste que vous récitez déjà avant de livrer. Mettez-la dans .claude/skills/, et arrêtez de la réciter.

Recevez le prochain guide par courriel

Un court courriel quand un nouveau guide paraît. Pas de bruit, pas de pourriel, désabonnement en tout temps.