Design Tally
Un passage de comptage, pas un guide de goût. Les autres compétences anti-slop énoncent des principes ; les principes sont contournés une justification à la fois. Cette compétence rend le contournement visible en imposant un comptage.
Pourquoi ça existe
Un véritable échec à l'origine de cette compétence : huit variantes de design ont été produites en une seule session, chacune utilisant une petite étiquette en capitales espacées pour les titres de section. Chaque instance avait une justification locale qui semblait raisonnable sur le moment. Personne ne les a additionnées. Le total était de 37, réparties sur cinq variantes présentées comme visuellement distinctes. Le principe directeur (« utiliser la hiérarchie avant les étiquettes ») était chargé et disponible pendant tout ce temps.
Un comptage n'est pas contournable comme un jugement. Exécutez le comptage.
La règle
Avant de présenter tout travail d'UI — à chaque fois, sans exception — produisez le tableau ci-dessous et incluez-le dans le message. Pas un résumé. Le tableau, avec les chiffres.
Si un compte est supérieur à zéro, soit corrigez-le, soit écrivez la justification spécifique pour chaque instance. « Ça semblait bien ici » n'est pas une justification. Si le même motif apparaît sur plusieurs écrans ou variantes, c'est le constat, indépendamment de la lecture de chaque instance isolément.
Ne signalez jamais le tableau comme propre sans avoir réellement inspecté la sortie. Lisez le balisage ou les styles ; ne déduisez pas de la mémoire de ce qui a été écrit.
Motifs interdits
Interdictions strictes. Ceux-ci ne sont pas disponibles sauf si l'utilisateur les demande explicitement par leur nom dans la requête en cours. Un brief de design les déclarant ne suffit pas.
| # | Motif | Détection |
|---|---|---|
| 1 | Intertitres en capitales espacées ou monospace | text-transform: uppercase ET (famille monospace OU letter-spacing >= 0.05em) |
| 2 | Monospace sur le texte courant | famille mono sur toute chaîne qui n'est pas du code, une valeur littérale, un identifiant ou un nombre |
| 3 | Poids de titre 700 ou plus | tout titre ou texte d'affichage avec font-weight >= 700 |
| 4 | Texte d'affichage en italique | font-style: italic aux tailles de titre ou d'affichage |
| 5 | Bordure et ombre sur un même élément | à la fois border et box-shadow sur le même nœud |
| 6 | Point de début dans un badge | cercle, point ou petite forme remplie comme premier enfant d'un badge, puce, étiquette ou tag |
| 7 | Icônes Lucide | l'ensemble Lucide, ou SVG dessiné à la main qui reproduit ses formes (trait de 1,5px, extrémités arrondies, glyphes géométriques 24x24). Le dessin à la main converge vers Lucide par défaut — supposez que toute icône dessinée à la main est une violation jusqu'à vérification par rapport à l'ensemble approuvé |
Compté et justifié par instance, pas interdit purement et simplement :
| # | Motif | Détection |
|---|---|---|
| 8 | Séparateurs | comptez chaque règle, filet et bordure comme séparateur par écran. Chacun nécessite une raison pour laquelle les espaces blancs ou la proximité ne pouvaient pas servir |
| 9 | Cartes conteneurs | comptez chaque boîte bordée ou remplie par écran. Signalez toute boîte imbriquée directement dans une autre |
| 10 | Texte excessif | prose qui reformule ce qu'une valeur, une étiquette ou un état adjacent communique déjà |
| 11 | Même emplacement entre variantes | lors de la production de N variantes présentées comme distinctes, tout emplacement — étiquette de section, pied de page, en-tête, forme de bouton, rythme d'espacement — rendu identique dans toutes les N |
La règle 11 est la vérification inter-variantes. Comparez le même emplacement dans chaque variante avant de présenter un ensemble. Des ambiances distinctes avec un traitement d'étiquette identique ne sont pas des variantes distinctes.
Icônes
Ensemble approuvé : Phosphor. Utilisez-le plutôt que de dessiner des glyphes à la main.
Avant d'ajouter une icône, demandez-vous si elle apporte une information qu'un mot ne pourrait pas apporter. Si une étiquette de texte fonctionne, utilisez l'étiquette de texte.
Exécution du linter
Pour l'UI qui existe sous forme de code, exécutez le script avant le comptage manuel :
python3 ~/.claude/skills/design-tally/scripts/tally.py <chemin> [--json] [--quiet]
Il couvre les règles 1 à 6 et affiche le tableau des comptes. Le code de sortie est 1 uniquement lorsqu'une règle prouvable (1, 5, 6) a un résultat, afin qu'il puisse bloquer un hook ou une étape CI sans échouer sur les candidats.
Les règles 2, 3 et 4 sont signalées comme des candidats, pas des violations — le script peut voir une famille mono ou un poids 700 mais ne peut pas distinguer la prose du code, ni un titre d'une étiquette. Classez chaque candidat vous-même et dites comment vous avez tranché.
Le script ne peut pas voir les règles 7 à 11, et ne peut pas du tout lire les plans de travail Paper ou Figma. Pour le travail avec des outils de design, comptez à la main en utilisant get_jsx ou l'équivalent — jamais à partir d'une capture d'écran, et jamais de mémoire de ce que vous avez écrit.
Une exécution propre du script n'est pas un tableau propre. Il couvre 6 des 11 règles uniquement sur le code.
Format de sortie
Signalez chaque règle, y compris celles à zéro — un zéro est une information, et ne lister que les résultats cache si le passage a réellement été effectué.
Design tally
| Règle | Compte | Où |
|-------|--------|----|
| 1 intertitres | 0 | — |
| 2 mono sur prose | 2 | légende sous le héros ; ligne de l'état vide |
| ... | | |
Ensuite, pour chaque compte non nul : corrigez-le, ou énoncez la justification par instance.
Ajout à cette liste
Lorsque l'utilisateur identifie un nouveau motif, ajoutez-le au tableau avec une règle de détection suffisamment spécifique pour être comptée. S'il ne peut pas être énoncé comme une condition détectable, il appartient à une compétence de principes, pas à celle-ci.