xieshuai0817-hub/LanceSkill

Revue à deux axes du diff entre HEAD et un point fixe fourni par l'utilisateur :

• Normes — le code respecte-t-il les standards de codage documentés du dépôt ?
• Spécifications — le code implémente-t-il fidèlement le ticket / PRD / cahier des charges d'origine ?

Les deux axes sont exécutés en tant que sous-agents parallèles afin qu'ils ne polluent pas le contexte l'un de l'autre, puis cette compétence agrège leurs conclusions.

Le tracker de tickets doit 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

Peu importe ce que l'utilisateur a indiqué comme point fixe — un SHA de commit, un nom de branche, un tag, main, HEAD~5, etc. S'il n'en a pas spécifié, demandez-le.

Capturez la commande de diff une fois : git diff <point-fixe>...HEAD (trois points, pour que la comparaison se fasse par rapport à la merge-base). Notez également la liste des commits avec git log <point-fixe>..HEAD --oneline.

Avant d'aller plus loin, vérifiez que le point fixe est résolu (git rev-parse <point-fixe>) et que le diff n'est pas vide. Une référence incorrecte ou un diff vide doit entraîner un échec ici — pas à l'intérieur des deux sous-agents parallèles.

2. Identifier la source de la spécification

Cherchez la spécification d'origine, dans cet ordre :

1. Références aux issues dans les messages de commit (#123, Closes #45, GitLab !67, etc.) — récupérez-les via le workflow dans docs/agents/issue-tracker.md.
2. Un chemin passé comme argument par l'utilisateur.
3. Un fichier PRD / spécification situé sous docs/, specs/ ou .scratch/ correspondant au nom de la branche ou à la fonctionnalité.
4. 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 sautera et signalera « aucune spécification disponible ».

3. Identifier les sources des normes

Tout ce qui, dans le dépôt, documente comment le code doit être écrit, comme CODING_STANDARDS.md ou CONTRIBUTING.md.

En plus de ce que le dépôt documente, l'axe Normes intègre toujours la baseline d'odeurs de code ci-dessous — un ensemble fixe d'odeurs de code de Fowler (Refactoring, ch.3) qui s'applique même si le dépôt ne documente rien. Deux règles encadrent cette baseline :

• Le dépôt prévaut. Une norme documentée du dépôt l'emporte toujours ; lorsqu'elle approuve ce que la baseline signalerait, supprimez l'odeur.
• Toujours une question de jugement. Chaque odeur est une heuristique étiquetée (« possible Feature Envy »), jamais une violation stricte — et, comme pour toute norme ici, ignorez ce que les outils automatisés imposent déjà.

Chaque odeur décrit ce qu'elle est → comment la corriger ; confrontez-la au diff :

• Mysterious Name — une fonction, variable ou type dont le nom ne révèle pas ce qu'il fait ou contient. → renommez-le ; si aucun nom honnête ne vient, c'est que la conception est floue.
• Duplicated Code — la même forme logique apparaît dans plusieurs hunks ou fichiers du changement. → extrayez la forme commune, appelez-la depuis les deux endroits.
• Feature Envy — une méthode qui accède davantage aux données d'un autre objet qu'aux siennes. → déplacez la méthode sur les données qu'elle envie.
• Data Clumps — les mêmes quelques champs ou paramètres voyagent toujours ensemble (un type qui veut naître). → regroupez-les en un seul type, passez celui-ci.
• Primitive Obsession — un type primitif ou une chaîne de caractères représentent un concept métier qui mériterait son propre type. → donnez au concept son propre petit type.
• Repeated Switches — le même switch / cascade de if sur le même type se répète dans le changement. → remplacez par du polymorphisme, ou une seule carte que les deux sites partagent.
• Shotgun Surgery — un changement logique unique force des modifications dispersées dans de nombreux fichiers du diff. → rassemblez ce qui change ensemble dans un seul module.
• Divergent Change — un seul fichier ou module est modifié pour plusieurs raisons sans rapport. → scindez pour que chaque module change pour une seule raison.
• Speculative Generality — abstraction, paramètres ou hooks ajoutés pour des besoins que la spécification n'a pas. → supprimez-les ; simplifiez jusqu'à ce qu'un besoin réel apparaisse.
• Message Chains — longue navigation a.b().c().d() dont l'appelant ne devrait pas dépendre. → cachez le chemin derrière une seule méthode sur le premier objet.
• Middle Man — une classe ou fonction qui ne fait essentiellement que déléguer. → supprimez-la, appelez la cible réelle directement.
• Refused Bequest — une sous-classe ou implémentation qui ignore ou surcharge la plupart de ce qu'elle hérite. → abandonnez l'héritage, utilisez la composition.

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 Normes — incluez :

• La commande de diff complète et la liste des commits.
• La liste des fichiers sources de normes que vous avez trouvés à l'étape 3, ainsi que la baseline d'odeurs de l'étape 3 collée en intégralité — le sous-agent n'y a pas accès autrement.
• La consigne : « Rapportez — par fichier/hunk lorsque pertinent — (a) chaque endroit où le diff viole une norme documentée : citez la norme (fichier + règle) ; et (b) toute odeur de la baseline que vous repérez : nommez-la et citez le hunk. Distinguez les violations strictes des appréciations — les manquements aux normes documentées peuvent être stricts, mais les odeurs de la baseline sont toujours des appréciations, et une norme documentée du dépôt prévaut sur la baseline. Ignorez tout ce que les outils imposent déjà. 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 manquantes ou partielles ; (b) le comportement dans le diff qui n'était pas demandé (scope creep) ; (c) les exigences qui semblent implémentées mais dont l'implémentation semble erronée. Citez la ligne de la spécification pour chaque constat. Moins de 400 mots. »

Si la spécification est manquante, sautez le sous-agent Spécifications et notez-le dans le rapport final.

5. Agréger

Présentez les deux rapports sous les titres ## Normes et ## Spécifications, verbatim ou légèrement nettoyés. Ne fusionnez pas et ne réordonnancez pas les résultats — 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 (s'il y en a un). Ne choisissez pas un seul gagnant entre les axes — c'est le réordonnancement que la séparation vise à empêcher.

Pourquoi deux axes

Un changement peut réussir sur un axe et échouer sur l'autre :

• Du code qui suit toutes les normes mais implémente la mauvaise chose → Normes OK, Spécifications KO.
• Du code qui fait exactement ce que le ticket demandait mais qui enfreint les conventions du projet → Spécifications OK, Normes KO.

Les rapporter séparément empêche un axe de masquer l'autre.