jamesonedge/senior-design-review

Revue de conception senior

Transformez un vague « améliore ça » en une décision de design falsifiable. Le résultat est une critique structurée qui cite des fichiers réels, des tokens et des motifs de référence, suivie d'un cahier des charges qu'un ingénieur peut implémenter.

Quand l'utiliser

Utilisez ce skill lorsque l'utilisateur vous demande de :

• revoir, critiquer ou « mettre à l'épreuve » un écran, un flux ou un composant existant ;
• évaluer une proposition écrite par quelqu'un d'autre (par exemple un designer junior ou un autre agent) ;
• décider quoi supprimer, ajouter, réviser ou conserver avant l'implémentation ;
• corriger un flux mobile à partir de captures d'écran.

Quand ne pas l'utiliser

• Petites corrections locales comme « augmente le padding de cette carte » ou « remplace ce libellé par 'Enregistrer' ». Faites la modification directement ; une revue complète est du bruit.
• Construire un prototype interactif. Utilisez un workflow de maquette interactive ; ce skill peut l'alimenter.
• Revue de code non liée à l'UI, réglage des performances ou conception back-end.
• Stratégie de marque ou marketing sans interface concrète.

Entrées

Recueillez ce que le dépôt ou l'utilisateur peut fournir en toute sécurité. Les entrées manquantes sont listées comme questions ouvertes, jamais inventées.

1. Tokens de design (couleur, typographie, espacement, rayon, mouvement) — chemins de fichiers.
2. Le(s) composant(s) canonique(s) existant(s) auquel/auxquels la cible doit ressembler.
3. Un exemple approuvé antérieur d'un travail similaire, s'il existe (optionnel, utile).
4. L'implémentation cible et/ou les captures d'écran.
5. Contraintes de plateforme connues (modèle de navigation, conventions OS, cibles minimales).
6. La plainte de l'utilisateur, citée textuellement si possible.

Un formulaire de contexte à remplir se trouve dans templates/context.md.

Flux de travail

1. Rédigez une proposition initiale explicite

Avant toute critique, rédigez la proposition en utilisant templates/proposal.md : problème, points douloureux cités, principes de design, une esquisse d'architecture de l'information, actions et questions ouvertes. Si l'utilisateur a fourni une proposition, utilisez la leur sans modification comme entrée.

2. Effectuez la revue comme un passage à neuf

Le relecteur lit, dans cet ordre : tokens, composant canonique, exemple antérieur, implémentation cible/captures d'écran, contraintes de plateforme, et seulement ensuite la proposition. Lire les preuves d'abord évite l'ancrage dans le cadrage de la proposition.

• Si votre environnement peut lancer un contexte véritablement séparé (un sous-agent ou une nouvelle session sans historique partagé), utilisez-le et précisez-le.
• Sinon, effectuez vous-même un passage séparé et étiquetez-le honnêtement : « Passage séparé par un seul agent — pas une revue indépendante par un pair. »

La personnalité du relecteur est une lentille qualité (un·e designer produit senior exigeant·e). Ne revendiquez jamais d'historique d'emploi, de diplômes ou d'années d'expérience au nom de la personnalité.

3. Rédigez la revue

Utilisez templates/review.md. Sections :

• TL;DR — trois à cinq lignes : verdict et le changement le plus important.
• A. Critique structurelle — est-ce le bon écran/flux tout court ?
• B. Architecture de l'information et hiérarchie
• C. Sémantique des actions — primaire, secondaire, destructrice, annulation, dénomination.
• D. Mécaniques et gestes — tap, balayage, glisser, clavier, découvrabilité.
• E. Visuel et mouvement — tokens, rythme, densité, transitions.
• F. Accessibilité et internationalisation
• G. Questions manquantes — visez cinq, mais n'incluez que les pertinentes.
• H. Cahier des charges affiné plus le registre Supprimer / Ajouter / Réviser / Conserver.

Les conseils détaillés pour chaque lentille se trouvent dans references/review-lenses.md. La checklist d'accessibilité et d'i18n est dans references/accessibility-i18n.md.

Règles qui rendent la revue digne d'être lue

• Mettez à l'épreuve ; ne cautionnez pas automatiquement. Chaque affirmation nécessite une référence spécifique : un chemin de fichier, un nom de token, un nom de composant, une région de capture d'écran ou un motif de référence nommé (par exemple « balayage pour archiver de Mail iOS »).
• Pas de platitudes. « Améliorez la hiérarchie visuelle » n'est pas une conclusion. « La date 'Échéance' utilise text.secondary à la même taille que le titre, donc la date limite est invisible au premier coup d'œil » en est une.
• Pas de suppressions forcées. Si la structure actuelle est bonne, dites-le et enregistrez un Conserver justifié. Changer pour changer est un défaut.
• Pas de mesures inventées. N'indiquez pas de rapports de contraste, de niveaux de réussite/échec WCAG ou de chiffres de performance sauf si vous les avez calculés ou mesurés, et montrez comment. Sinon, écrivez « non mesuré — vérifier avec un outil de contraste ».
• Couvrez les états. Vide, chargement, erreur, hors ligne, contenu long, contenu très court.
• Signaux non chromatiques. Le statut ne doit jamais reposer uniquement sur la couleur.
• Chemins clavier et lecteur d'écran pour chaque action, y compris les gestes personnalisés.
• Expansion du texte (prévoyez environ 30 à 40 % de chaînes plus longues pour de nombreuses langues) et disposition droite-à-gauche le cas échéant.
• Alternative mouvement réduit pour chaque animation.

Optionnel : comparer avec le travail antérieur

S'il existe un exemple approuvé antérieur, ajoutez une courte note « Cohérence avec le travail antérieur » sous E ou H. C'est utile, pas obligatoire.

Résultats

• proposal.md (si vous l'avez rédigé)
• review.md contenant le TL;DR, A–H et le registre
• Un court résumé pour l'utilisateur : verdict, trois changements principaux, et les questions ouvertes qui bloquent l'implémentation

Vérifications d'acceptation

Voir references/review-lenses.md#acceptance-checks. Une revue échoue si une ligne du registre manque de raison et de référence, ou si elle présente des chiffres non mesurés comme des faits.

Avis de licence

L'avis suivant accompagne ce skill autonome et ses fichiers de support.

MIT License

Copyright (c) 2026 jamesonedge

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.