shape
par pbakausshape est une skill UX/UI axée sur la planification, qui mène un entretien de découverte puis transforme les réponses en brief de design avant toute phase de code. Utilisez-la avec /impeccable pour clarifier les objectifs utilisateur, les contraintes, les états et la direction d’implémentation en UI Design.
Cette skill obtient une note de 78/100, ce qui en fait une fiche solide pour l’annuaire : les agents disposent d’un déclencheur clair, d’un objectif précis avant le codage et d’un résultat structuré. En revanche, les adoptants doivent prévoir un flux centré sur la documentation, qui dépend d’une autre skill pour le contexte complet et l’exécution en aval.
- Déclencheur et périmètre clairs : la skill est explicitement conçue pour cadrer une fonctionnalité avant d’écrire du code, avec `user-invocable: true` et un indice d’argument pour la fonctionnalité.
- Résultat réellement exploitable : la skill promet un brief de design concret, capable de guider l’implémentation et d’être transmis à d’autres skills.
- Cadrage procédural solide : elle définit une préparation obligatoire, une phase d’entretien de découverte et des contraintes telles que l’interdiction d’écrire du code pendant la découverte.
- Dépendance forte à `/impeccable` : la skill nécessite d’invoquer cette skill parente et éventuellement `/impeccable teach`, ce qui limite son utilité en autonome.
- Aucun fichier d’appui, exemple ou guide d’installation n’est fourni ; les utilisateurs doivent donc déduire le déroulé exact de l’entretien et le format du brief à partir du seul texte descriptif.
Vue d’ensemble de shape skill
Ce que fait shape
Le shape skill est un workflow UX/UI centré d’abord sur la planification, pour définir une fonctionnalité avant d’écrire la moindre ligne de code. Au lieu de passer directement aux layouts ou aux composants, il mène un entretien de découverte structuré puis transforme les réponses en brief de conception. C’est particulièrement utile quand votre équipe sait globalement quoi construire, sans avoir encore clarifié les objectifs utilisateurs, les contraintes, les états, les cas limites ou la direction d’implémentation.
À qui s’adresse shape skill
Le shape skill convient surtout aux profils orientés produit, aux designers, aux ingénieurs frontend et aux équipes assistées par l’IA qui veulent prendre de meilleures décisions avant le prototypage. Il est particulièrement pertinent pour shape for UI Design lorsqu’une fonctionnalité reste floue : nouveaux flows, dashboards, formulaires, onboarding, paramètres, ou toute interface où « générer une UI » trop vite risquerait de passer à côté du vrai besoin utilisateur.
Pourquoi choisir shape plutôt qu’un prompt générique
Un prompt classique produit souvent immédiatement des mockups ou des idées de composants. shape, lui, ralentit volontairement le processus. Sa vraie différence, c’est d’imposer d’abord la collecte du contexte, puis de produire un brief de conception que vous pourrez transmettre ensuite à des skills d’implémentation. Le repo est clair sur le périmètre : ici, on est dans la planification design, pas dans le code. Cette frontière est précieuse si vous voulez moins de suggestions d’UI superficielles et davantage de décisions produit défendables.
Comment utiliser shape skill
Contexte d’installation et prérequis obligatoire
Installez le skill depuis le repository pbakaus/impeccable via votre workflow de skills, par exemple :
npx skills add pbakaus/impeccable --skill shape
Le point d’adoption le plus important est le prérequis indiqué dans SKILL.md : shape requires /impeccable first. Le skill précise que vous devez invoquer /impeccable, suivre son Context Gathering Protocol, et, si aucun contexte design n’existe encore, exécuter /impeccable teach avant d’utiliser le shape skill. Si vous sautez cette étape, vous utilisez le skill en dehors du workflow prévu.
De quelles entrées shape a besoin pour bien fonctionner
L’indication d’argument est [feature to shape], mais un simple nom de fonctionnalité sur une ligne suffit rarement. Un bon usage de shape commence plutôt par :
- l’objectif de la fonctionnalité
- l’utilisateur cible ou le rôle concerné
- le workflow actuel ou le point de douleur
- les critères de réussite
- les contraintes fortes comme la plateforme, les permissions, la conformité ou le design system existant
- les cas limites connus ou ce qui ne fait pas partie du périmètre
Une entrée faible :
Shape a notifications page.
Une entrée plus solide :
Shape a notifications center for account admins who miss urgent billing and security events. It must work on desktop first, reuse our existing table and filter patterns, and avoid adding real-time infrastructure in v1.
Workflow pratique et fichiers à lire en premier
Commencez par lire SKILL.md et considérez-le comme le contrat opératoire. Dans cet instantané du repository, seul ce fichier est exposé ; l’essentiel de la valeur consiste donc à respecter correctement sa séquence :
- Rassembler le contexte design via
/impeccable. - Utiliser shape pendant la phase de planification, pas pendant l’implémentation.
- Le laisser mener l’entretien de découverte.
- Transformer l’entretien en brief de conception.
- Transmettre ce brief à
/impeccable craft,/impeccableou à un autre workflow d’implémentation.
C’est important, car le skill est optimisé pour réduire les suppositions avant le début du travail UI, pas pour produire des écrans peaufinés en une seule passe.
Un pattern de prompt qui donne de meilleurs résultats
Pour invoquer efficacement le shape skill, demandez explicitement l’entretien et le livrable final. Structure type :
- la fonctionnalité à cadrer
- qui est l’utilisateur principal
- le problème actuel
- les contraintes incontournables
- les décisions que vous voulez voir tranchées dans le brief
Exemple :
Use shape to plan a bulk-edit inventory feature for operations managers. Interview me first. Focus on user intent, error prevention, empty/loading/failure states, permissions, and what the v1 interaction model should be. Output a design brief I can hand to implementation.
Cette approche fonctionne mieux que « design a UI for X », parce qu’elle laisse au skill l’espace nécessaire pour poser des questions de clarification avant de figer une direction.
FAQ sur shape skill
shape skill sert-il au code ou à la planification ?
Le shape skill sert à la planification. Le repository l’indique explicitement : il n’écrit pas de code. Sa sortie est un brief de conception qui guide l’implémentation ensuite. Si vous voulez du code immédiatement, ce n’est pas le bon point de départ ; si vous voulez d’abord de meilleures décisions produit et UI, c’est un très bon choix.
Quand shape est-il meilleur qu’un prompt ordinaire ?
Utilisez shape quand la fonctionnalité est mal définie, risquée, orientée utilisateur, ou susceptible d’impliquer des états et des arbitrages complexes. Un prompt générique peut être plus rapide pour un mockup jetable. shape est meilleur quand vous avez besoin de réflexion sur le workflow, les besoins utilisateurs, les contraintes et la qualité du handoff.
shape convient-il aux débutants ?
Oui, avec une réserve : les débutants doivent quand même disposer d’un minimum de contexte produit pour bien répondre à l’entretien de découverte. Le skill apporte une structure, mais il ne peut pas inventer vos utilisateurs, vos contraintes ou vos métriques de succès. Si vous débutez en planification UX, son approche guidée par entretien est justement utile, car elle fait remonter les questions auxquelles vous auriez dû répondre de toute façon.
Quand ne faut-il pas utiliser shape for UI Design ?
Évitez shape for UI Design si le problème est déjà entièrement spécifié, si vous n’avez besoin que d’un minuscule ajustement visuel, ou si la tâche est purement technique et ne concerne pas l’interaction utilisateur. C’est aussi un mauvais choix si vous refusez l’étape préalable de collecte de contexte, car le skill repose sur cette base.
Comment améliorer shape skill
Donner à shape de meilleures entrées de planification
Le principal levier de qualité, c’est la qualité des entrées. Pour shape, de bonnes entrées ne se limitent pas à un nom de fonctionnalité. Incluez le type d’utilisateur, la fréquence de la tâche, le coût de l’échec, les patterns existants, les règles métier et ce qui doit rester hors périmètre. Le skill vous interviewera quand même, mais un contexte initial plus riche produit un brief plus net et moins de recommandations génériques.
Éviter le principal mode d’échec : les solutions prématurées
L’avertissement le plus fort du repo est de ne pas prendre de décisions de design trop tôt. Un mésusage fréquent du shape skill consiste à demander des écrans, des cartes, des onglets ou des layouts avant d’avoir clarifié le problème utilisateur. Si vous voyez la conversation basculer trop vite vers des patterns d’interface, recadrez-la : demandez d’abord les besoins utilisateurs non couverts, le flux de tâche, les états, les arbitrages et les contraintes.
Itérer sur le brief de conception, pas seulement sur le prompt
Après une première passe, améliorez le brief en remettant en question les décisions floues :
- Quel objectif utilisateur est prioritaire ?
- Quels états manquent ?
- Quelles hypothèses doivent être validées ?
- Qu’est-ce qui est volontairement exclu de la v1 ?
- Qu’est-ce qui rendrait l’implémentation ambiguë ?
Ce type d’itération améliore davantage l’usage de shape que le fait de redemander encore et encore « une meilleure UI ».
Associer shape à l’exécution en aval
La meilleure façon d’augmenter la valeur d’installation de shape skill est de le traiter comme la première étape d’une chaîne. Utilisez shape pour créer le brief, puis transmettez ce brief à /impeccable craft ou à un autre skill d’implémentation. Plus votre artefact de handoff est bon, plus le code ou la génération design qui suit a des chances de rester aligné sur les besoins utilisateurs, au lieu de dériver vers une UI crédible en apparence mais faible dans le fond.