EastDong314/agent-skills

Revue de code axée sur la suppression du sur-engineering : standard library réinventée, dépendances inutiles, abstractions spéculatives, flexibilité morte. Un constat par ligne : emplacement, ce qu'il faut enlever, quoi utiliser à la place.

Qu'est-ce que agent-skills ?

Ce skill d'agent (Type: code review, Platforms: Claude Code, Cursor, Codex, etc.) est conçu pour traquer implacablement l'excès de complexité dans les diffs de code. Il se concentre exclusivement sur les signes de sur-engineering – code mort, réimplémentation de la bibliothèque standard, dépendances superflues, abstractions prématurées (YAGNI), et code verbeux – en ignorant délibérément les bugs de correction, les failles de sécurité et les performances. Chaque constat est formaté sur une ligne : `L<ligne>: <tag> <quoi>. <remplacement>.` avec des tags comme `delete:`, `stdlib:`, `native:`, `yagni:` ou `shrink:`. Le skill s'active sur des phrases déclencheuses comme « review for over-engineering », « what can we delete » ou via la commande `/ponytail-review`, et termine son analyse par la métrique « net: -<N> lignes possibles. » ou par « Lean already. Ship. » si rien n'est à couper. Il complète une revue de correction classique, mais ne propose pas d'appliquer les changements – il se contente de les lister.

Compatible avec~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/EastDong314/agent-skills/tree/HEAD/skills/ponytail-review

Documentation

Analyser les diffs pour détecter la complexité inutile. Un constat par ligne : emplacement, ce qu'il faut enlever, quoi utiliser à la place. Le meilleur résultat du diff est de devenir plus court.

Format

L<ligne>: <tag> <quoi>. <remplacement>., ou <fichier>:L<ligne>: ... pour les diffs multi-fichiers.

Tags :

delete: code mort, flexibilité inutilisée, fonctionnalité spéculative. Remplacement : rien.
stdlib: composant fait maison que la bibliothèque standard fournit. Nommer la fonction.
native: dépendance ou code qui fait ce que la plateforme fait déjà. Nommer la fonctionnalité.
yagni: abstraction avec une seule implémentation, configuration que personne ne définit, couche avec un seul appelant.
shrink: même logique, moins de lignes. Montrer la forme plus courte.

Exemples

❌ "Cette classe EmailValidator est peut-être plus complexe que nécessaire, avez-vous envisagé si toutes ces règles de validation sont vraiment utiles à ce stade ?"

✅ L12-38: stdlib: classe de validation de 27 lignes. "@" dans l'email, 1 ligne, la vraie validation est le mail de confirmation.

✅ L4: native: moment.js importé pour un seul appel de format. Intl.DateTimeFormat, 0 dépendances.

✅ repo.py:L88: yagni: AbstractRepository avec une seule implémentation. Inlinez-la jusqu'à ce qu'une seconde apparaisse.

✅ L52-71: delete: wrapper de réessai autour d'un appel local idempotent. Rien ne le remplace.

✅ L30-44: shrink: boucle manuelle construit un dict. dict(zip(keys, values)), 1 ligne.

Scoring

Terminer avec la seule métrique qui compte : net: -<N> lignes possibles.

S'il n'y a rien à couper, dire Déjà léger. Livrez. et s'arrêter.

Limites

Périmètre : uniquement sur-engineering et complexité. Les bugs de correction, failles de sécurité et performances sont explicitement hors scope. Les rediriger vers une revue normale, pas celle-ci. Un test unitaire minimal ou une auto-vérification par assert est le minimum syndical ponytail, ce n'est pas du bloat, ne jamais le signaler pour suppression. N'applique pas les corrections, les liste seulement.

"stop ponytail-review" ou "mode normal" : revenir au style de revue verbose.