Skill: Diff Audit

Audite ce qui vient d'être écrit, pas le projet entier. Deux moitiés : la conformité des changements aux blueprints, et l'achèvement de la tâche.

Périmètre

$ARGUMENTS peut nommer une base de comparaison (main, un SHA, une branche). Sans argument, le périmètre est le travail non commité.

Établir la liste des fichiers touchés — les trois sources ne se recouvrent pas :

git status --porcelain          # staged, unstaged ET non suivis
git diff HEAD                   # contenu modifié des fichiers suivis
git diff --stat HEAD

⚠️ Un fichier non suivi n'apparaît pas dans git diff HEAD : il ne remonte que par git status --porcelain (préfixe ??) et se lit en entier. Un fichier créé pendant la tâche est précisément celui qui n'a jamais été relu.

Avec une base : git diff <base>...HEAD pour les commits, plus le travail non commité par-dessus.

Hors dépôt git : auditer les fichiers créés ou modifiés pendant la session.

Auditer la conformité

Les règles s'appliquent aux fichiers touchés dans leur ensemble, pas aux seules lignes ajoutées : une violation d'isolation de couche ou de taille de fichier naît d'une ligne mais ne se voit qu'au niveau du fichier.

Ne charger que les domaines concernés par le diff :

Un diff qui touche un fichier de configuration mérite une attention particulière : une option retirée du tsconfig ou un ignore ajouté à Knip désactive silencieusement une règle pour tout le projet, bien au-delà des lignes changées.

Sur un diff qui dépasse quelques fichiers, déléguer aux agents architecture-auditor, design-auditor et clean-code-auditor en parallèle, en leur donnant la liste exacte des fichiers à auditer. Ils sont read-only et rendent un diagnostic sourcé.

Sur un petit diff, auditer directement — spawner trois agents pour deux fichiers coûte plus que ça ne rapporte.

S'auto-auditer

La conformité ne dit pas si le travail est fini. Vérifier, dans cet ordre :

1. La demande est-elle entièrement traitée ? Relire la demande initiale et lister ce qui a été livré en face. Une partie silencieusement omise est le défaut le plus coûteux — plus qu'une violation de style.
2. La vérification du projet passe-t-elle ? Lancer la commande de check du projet (bun run check dans la stack de référence, sinon ce que déclare package.json). Un audit qui conclut « conforme » sur du code qui ne compile pas n'a rien audité.
3. Les tests couvrent-ils le changement ? Un comportement ajouté sans test, ou un test existant que le changement invalide.
4. Reste-t-il des traces de travail ? Code commenté, console.log, TODO sans suite, fichiers de brouillon, imports morts.
5. Le changement en casse-t-il un autre ? Chercher les appelants de ce qui a changé de signature ou de comportement.

Traiter ses propres décisions comme suspectes : un raccourci pris en cours de route se justifie sur le moment et se voit mal après coup. Chercher activement ce qu'on a bâclé plutôt que confirmer que tout va bien.

Rendu

Court par construction — un audit de diff qui produit trois pages n'est pas lu :

1. Verdict : la tâche est-elle livrable en l'état ? Une phrase.
2. Bloquants — ce qui doit être corrigé avant de rendre la main : demande non traitée, check qui échoue, régression, violation HIGH.
3. À corriger — violations MEDIUM/LOW avec fichier:ligne et l'action.
4. Écarts assumés — ce qui dévie d'un blueprint mais est justifié ici, avec la justification. Un écart que tu ne peux pas justifier est un bloquant, pas un écart.

Ne rien signaler qui préexistait au diff : le périmètre est ce qui vient d'être écrit. Un défaut préexistant croisé au passage se mentionne en une ligne, hors du rapport.

Principes

• Non-destructif : cette skill diagnostique. Les corrections viennent après, sur décision.
• Basé sur preuves : fichier:ligne, ou pas de finding.
• Honnête sur soi : signaler ce qu'on a soi-même écrit de travers est le seul intérêt de l'exercice. Un rapport qui ne trouve rien après un changement non trivial est un rapport qui n'a pas cherché.