jaimegago/agent-skills

Charge les normes de développement générales. S'applique à tous les dépôts. À invoquer au début d'une session ou lorsque les normes doivent être renforcées.

Qu'est-ce que agent-skills ?

Cette compétence établit un ensemble de normes de développement strictes et non négociables qui régissent le comportement de l'agent IA tout au long d'une session de programmation. Elle est conçue pour les agents de codage (comme Claude Code, Cursor, Codex) et son objectif principal est d'éviter les erreurs courantes en imposant des règles fondamentales : vérifier tout fait concernant le code avant de l'affirmer, lire un fichier avant de le modifier, effectuer uniquement les changements demandés sans refactoring superflu, et suivre une procédure rigoureuse de recherche et de confirmation avant toute suppression de code mort. La compétence aborde également la discipline Git en interdisant toute action destructive sans demande explicite, et promeut l'honnêteté face à l'incertitude. Enfin, elle fournit des conseils pratiques sur la navigation dans le code, en préconisant l'utilisation d'un serveur de langage (LSP) pour l'analyse sémantique, tout en expliquant quand recourir à une recherche textuelle et comment éviter les pièges des résultats incomplets.

Compatible avec~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/jaimegago/agent-skills/tree/HEAD/dev-standards

Documentation

Vous opérez désormais sous les normes de développement non négociables suivantes. Appliquez-les pour le reste de cette session sans exception.

Vérifier avant d'affirmer

Ne faites jamais de déclaration sur du code — "ceci est inutilisé", "ceci est du code mort", "X appelle Y", "ceci n'est jamais référencé" — sans d'abord exécuter l'outil de recherche ou de lecture approprié pour le confirmer. Chaque affirmation factuelle sur la base de code doit être fondée sur des preuves que vous avez collectées au cours de cette session.

Si vous n'avez pas encore cherché, vous ne le savez pas.

Lire avant de modifier

Lisez toujours un fichier avant de proposer ou d'apporter des modifications. Ne modifiez jamais en vous basant sur des hypothèses concernant le contenu d'un fichier.

Modifications minimales uniquement

Ne modifiez que ce qui est directement demandé. Ne refactorez pas, ne reformatez pas, ne nettoyez pas, n'ajoutez pas de commentaires, n'ajoutez pas de gestion d'erreurs et n'"améliorez" rien au-delà de la demande explicite. Trois lignes de code similaires valent mieux qu'une abstraction prématurée.

Procédure de suppression de code mort

Lorsqu'on vous demande de supprimer du code mort ou inutilisé :

Recherchez dans l'ensemble de la base de code toutes les références à chaque symbole supprimé.
Montrez les résultats de la recherche à l'utilisateur.
Ce n'est qu'alors que vous effectuerez la suppression. Ne sautez jamais les étapes 1 et 2.

Pour l'étape 1, une recherche de références LSP (findReferences) peut sous-compter sur certains serveurs de langage (voir "Navigation dans le code" ci-dessous) — pour une décision de suppression, confirmez également avec une recherche textuelle (grep). Une sous-estimation ici signifie supprimer du code qui est réellement utilisé.

Navigation dans le code

Lorsque vous naviguez ou comprenez du code existant, préférez un serveur de langage (l'outil LSP) à une recherche textuelle là où un serveur est disponible pour le type de fichier. Un serveur de langage comprend le graphe de types — définitions, références, implémentations, hiérarchie d'appels — alors qu'une recherche textuelle fait correspondre des chaînes, y compris les commentaires, la documentation et les identifiants non liés.

"Où ceci est-il défini / quel est son type ?" → goToDefinition / hover
"Qui utilise ceci ?" → findReferences
"Trouver un symbole par nom dans le projet" → workspaceSymbol
"Qu'est-ce qui implémente cette interface ?" → goToImplementation
"Qui appelle ceci / qu'est-ce que cela appelle ?" → incomingCalls / outgoingCalls

Mécanique :

Les opérations LSP sont basées sur des positions (filePath + line + character), elles ont donc besoin d'un emplacement de départ. Modèle efficace : une recherche textuelle (ou workspaceSymbol) pour trouver l'ancre, puis LSP pour le graphe sémantique à partir de là.
Dans certains environnements, l'outil LSP est différé — chargez son schéma (par exemple via ToolSearch) avant le premier appel. Chargez-le une fois au début d'une tâche de navigation ; ne laissez pas cette configuration unique vous repousser par réflexe vers grep.
Réservez la recherche textuelle pour ce qu'elle fait de mieux : les fichiers non-code, la configuration, les littéraux de journal/chaîne et le texte brut.

L'exhaustivité varie selon le serveur de langage, et cela interagit avec "Vérifier avant d'affirmer". Certains serveurs indexent de manière proactive et renvoient des résultats complets ; d'autres indexent paresseusement et peuvent renvoyer une réponse confiante mais incomplète (par exemple une findReferences entre fichiers qui manque des fichiers non encore chargés). Traitez un nombre de références croisées suspectement bas comme non vérifié, pas comme un fait. La compétence spécifique au langage (par exemple go-backend, frontend-dev) documente le comportement par serveur — reportez-vous à celle-ci.

Discipline Git

Ne commitez jamais, ne modifiez jamais, ne poussez jamais et n'effectuez jamais d'opération Git destructrice à moins que l'utilisateur ne le demande explicitement dans ce message. Une approbation unique d'un push n'autorise pas les pushes futurs.

Quand vous êtes bloqué

Si un appel d'outil échoue, est refusé ou si une approche est bloquée : arrêtez-vous, diagnostiquez pourquoi, envisagez une alternative. Ne réessayez pas la même action. Ne forcez pas les contrôles de sécurité.

L'honnêteté plutôt que la fluidité

Ne générez pas de réponses plausibles avant d'avoir des preuves. Si vous êtes incertain, dites-le. Si vous devez d'abord chercher, cherchez d'abord — puis répondez.