agentkitco/agentkit-dev-skills

Auditer un fichier d'instructions d'agent

Objectif : trouver dans un fichier d'instructions les lignes qui sont erronées, obsolètes, vagues ou risquées, et proposer une version plus courte et précise. Ne "corrigez" jamais une commande que vous n'avez pas exécutée ou un chemin que vous n'avez pas vérifié.

Étapes

1. Trouver les fichiers. Recherchez AGENTS.md, CLAUDE.md, CLAUDE.local.md, .claude/rules/*.md, .cursor/rules/*.mdc, .cursorrules, .github/copilot-instructions.md et .github/instructions/*.md. Listez ce que vous avez trouvé et qui lit chaque fichier.
2. Exécuter le vérificateur depuis la racine du dépôt pour obtenir d'abord les résultats mécaniques : python3 scripts/audit_instructions.py <fichier> [<fichier> ...] (Le chemin est relatif au dossier de cette compétence ; utilisez le chemin complet de la compétence installée.) Il signale la longueur, les chemins de fichiers cassés, les commandes qui nomment un script ou une cible make qui n'existe pas, les phrases vagues, les espaces réservés [BRACKET], les doublons et les chaînes ressemblant à des secrets. Si Python n'est pas disponible, effectuez les mêmes vérifications manuellement.
3. Vérifier chaque commande vous-même. Pour chaque commande du fichier, confirmez qu'elle existe (script dans package.json, cible dans Makefile, entrée dans pyproject.toml). Exécutez les commandes simples et sûres (lint, tests unitaires, vérification de type). N'exécutez pas les commandes de déploiement, de migration ou de suppression ; listez-les comme "non vérifiées".
4. Vérifier les jugements que le script ne peut pas faire :
   • Règles déjà appliquées par un linter ou un formateur (candidates à la suppression).
   • Règles qui se contredisent, ou qui contredisent un autre fichier d'instructions.
   • Faits que l'agent peut lire dans le dépôt en quelques secondes (nom du framework, liste des dossiers).
   • Règles sans signification testable ("écrire du code propre").
   • Tout ce qui appartient à une règle limitée à un chemin plutôt qu'au fichier racine.
5. Rapporter, puis attendre l'approbation avant de modifier.

Format du rapport

## Audit du fichier d'instructions : <fichier>
Longueur : <n> lignes (<verdict>)

### Doit être corrigé (erroné ou dangereux)
- ligne <n> : <ce qui ne va pas>, <preuve : sortie de commande ou chemin manquant>

### Devrait être réduit (faible valeur)
- ligne <n> : <pourquoi cela peut disparaître>

### Contradictions
- <fichier A ligne n> vs <fichier B ligne m> : <le conflit>

### Non vérifié
- <commande> : <pourquoi vous ne l'avez pas exécutée>

### Version proposée
<le fichier plus court, ou un diff>

Règles

• Preuve plutôt qu'opinion : chaque "doit être corrigé" cite une sortie ou un fichier manquant.
• Conservez la voix du propriétaire et toute règle qui encode un incident réel ou une contrainte forte.
• N'ajoutez pas de nouvelles règles pendant un audit. Suggérez-les séparément à la fin, au maximum trois.
• Traitez une chaîne ressemblant à un secret comme réelle : dites à l'utilisateur de la faire pivoter, et ne répétez pas la valeur dans votre rapport.