Revue bidimensionnelle du diff entre HEAD et un point fixe fourni par l'utilisateur :
- Standards — le code respecte-t-il les règles de codage documentées du dépôt ?
- Spécifications — le code implémente-t-il fidèlement le ticket, le document de spécification (PRD) ou la spécification d'origine ?
Les deux axes s'exécutent comme sous-agents parallèles, afin de ne pas polluer mutuellement leur contexte, puis ce skill agrège leurs conclusions.
Le système de suivi des tickets devrait vous avoir été fourni — exécutez /setup-matt-pocock-skills si docs/agents/issue-tracker.md est manquant.
Processus
1. Définir le point fixe
Quel que soit le point fixe mentionné par l'utilisateur — un SHA de commit, un nom de branche, un tag, main, HEAD~5, etc. S'il n'en spécifie pas, demandez-le.
Capturez la commande de diff une fois : git diff <point-fixe>...HEAD (trois points, pour comparer avec la base de fusion). Notez également la liste des commits via git log <point-fixe>..HEAD --oneline.
Avant d'aller plus loin, confirmez que le point fixe est valide (git rev-parse <point-fixe>) et que le diff n'est pas vide. Une référence invalide ou un diff vide doit échouer ici — pas dans les deux sous-agents parallèles.
2. Identifier la source de la spécification
Cherchez la spécification d'origine, dans cet ordre :
- Références aux tickets dans les messages de commit (
#123,Closes #45, GitLab!67, etc.) — récupérez via le workflow dansdocs/agents/issue-tracker.md. - Un chemin passé par l'utilisateur comme argument.
- Un fichier PRD/spécification sous
docs/,specs/, ou.scratch/correspondant au nom de branche ou à la fonctionnalité. - Si rien n'est trouvé, demandez à l'utilisateur où se trouve la spécification. S'il dit qu'il n'y en a pas, le sous-agent Spécifications ignorera et signalera « aucune spécification disponible ».
3. Identifier les sources des standards
Tout fichier dans le dépôt documentant comment le code doit être écrit, comme CODING_STANDARDS.md ou CONTRIBUTING.md.
4. Lancer les deux sous-agents en parallèle
Envoyez un seul message avec deux appels d'outil Agent. Utilisez le sous-agent general-purpose pour les deux.
Invite du sous-agent Standards — incluez :
- La commande de diff complète et la liste des commits.
- La liste des fichiers sources de standards trouvés à l'étape 3.
- La consigne : « Rapportez — par fichier/tronçon lorsque pertinent — chaque endroit où le diff viole un standard documenté. Citez le standard (fichier + règle). Distinguez les violations claires des jugements subjectifs. Ignorez tout ce qui est imposé par un outil. Moins de 400 mots. »
Invite du sous-agent Spécifications — incluez :
- La commande de diff et la liste des commits.
- Le chemin ou le contenu récupéré de la spécification.
- La consigne : « Rapportez : (a) les exigences demandées par la spécification qui sont absentes ou partielles ; (b) les comportements dans le diff qui n'étaient pas demandés (dépassement de périmètre) ; (c) les exigences qui semblent implémentées mais dont l'implémentation semble incorrecte. Citez la ligne de la spécification pour chaque constat. Moins de 400 mots. »
Si la spécification est absente, ignorez le sous-agent Spécifications et notez-le dans le rapport final.
5. Agréger
Présentez les deux rapports sous les titres ## Standards et ## Spécifications, textuellement ou légèrement nettoyés. Ne fusionnez pas et ne reclassifiez pas les constats — les deux axes sont délibérément séparés (voir Pourquoi deux axes).
Terminez par un résumé d'une ligne : nombre total de constats par axe, et le pire problème au sein de chaque axe (le cas échéant). Ne choisissez pas un seul gagnant entre les axes — c'est le reclassement que la séparation vise à éviter.
Pourquoi deux axes
Un changement peut réussir un axe et échouer sur l'autre :
- Code qui suit tous les standards mais implémente la mauvaise chose → Standards OK, Spécifications KO.
- Code qui fait exactement ce que le ticket demandait mais brise les conventions du projet → Spécifications OK, Standards KO.
Les rapporter séparément empêche un axe de masquer l'autre.