lint

Par mkurman · zorai

npx skills add https://github.com/mkurman/zorai --skill lint

name: lint description: Linter et formater du code. Détecte automatiquement ESLint, Biome, Prettier ou les formateurs natifs au langage, les exécute avec auto-correction. Rapporte les problèmes restants avec des suggestions actionnables.

tags: [gsd-2, skills, lint] ---|------|------|---------| | ... | ... | ... | ... |

Avertissements (X problèmes)

Fichier Ligne Règle Message
... ... ... ...

Formatage

  • X fichiers seraient reformatés
  • [liste des fichiers]

Résumé

  • Problèmes totaux : X erreurs, Y avertissements, Z formatage
  • Auto-corrigeables : N problèmes (exécutez /lint --fix pour appliquer)

Étape 4 : Suggérer des corrections pour les problèmes courants

Pour les problèmes les plus fréquents, fournissez des conseils brefs et actionnables :

  • Si la même règle apparaît 5+ fois, suggérez une correction en masse ou un changement de configuration.
  • Pour les imports/variables inutilisés, énumérez-les pour suppression rapide.
  • Pour les problèmes de formatage uniquement, notez que --fix les résoudra sans risque.
  • Pour les problèmes qui ne peuvent pas être auto-corrigés, fournissez une explication d'une ligne sur la façon de résoudre chaque violation de règle unique.

</execution>

<critical_rules>

  1. Ne jamais modifier les fichiers sans --fix : Le mode par défaut est rapport uniquement. Respectez l'espace de travail de l'utilisateur.
  2. Utilisez la configuration du projet : N'inventez pas de règles de lint. Utilisez tout fichier de configuration existant dans le projet.
  3. Utilisez la version installée du projet : Préférez toujours npx, cargo ou le binaire local du projet. N'utilisez pas les outils installés globalement à moins qu'aucune version locale n'existe.
  4. Gérez les outils manquants gracieusement : Si un fichier de configuration existe mais l'outil n'est pas installé, informez l'utilisateur et fournissez la commande d'installation (par ex. npm install --save-dev eslint).
  5. Respectez .gitignore et les motifs d'ignore : Ne lintez pas node_modules, dist, build, target, .git ou d'autres répertoires couramment ignorés. La plupart des outils gèrent cela automatiquement ; vérifiez qu'ils le font.
  6. Limitez la sortie : S'il y a plus de 50 problèmes, affichez les 30 premiers groupés par sévérité, puis résumez le reste avec les comptages par fichier. Ne submergez pas l'utilisateur avec des centaines de lignes.
  7. Terminez proprement : Après avoir présenté les résultats, n'entreprendre aucune action supplémentaire. Laissez l'utilisateur décider des étapes suivantes.

</critical_rules>

Skills similaires