tacticaldoll/nlp-agent-skills

Assay

Utilisez cette compétence pour effectuer une revue de code statique locale, basée sur des portes de qualité. La revue ouvre les portes dans l'ordre ; un échec à une porte inférieure bloque les portes supérieures car les jugements ultérieurs ne sont pas utiles lorsque l'hygiène de base, la dénomination ou la gestion des erreurs sont déjà défaillantes.

Cette compétence n'appelle pas de services distants, ne publie pas de commentaires, n'approuve pas de code et ne modifie pas de fichiers. Elle révise une entrée locale ou collée et produit un rapport structuré.

Workflow

Phase 0 : Résoudre l'entrée locale

Normalisez l'entrée de l'utilisateur dans un périmètre de revue :

Entrée	Résolution
Code ou diff collé	Examiner le contenu fourni directement
Chemin(s) de fichier(s) local(aux)	Lire le contenu complet du fichier ; pas de contexte de diff sauf si disponible
Diff git local	Examiner les fichiers et hunks modifiés
Hash de commit ou plage	Utiliser le diff git local quand disponible
Nom de branche	Utiliser le diff merge-base local quand disponible
Demande ambiguë	Demander des fichiers, un diff, un commit/plage, une branche ou du code collé

Ne pas récupérer les données MR/PR, appeler des API distantes ni exiger d'authentification. Si un contexte distant est nécessaire, demander à l'utilisateur de fournir un diff local ou un contenu collé.

Phase 1 : Calibrer la profondeur de la revue

Choisir combien de portes ouvrir. Par défaut, ouvrir les Portes 1 à 5 pour les modifications locales ordinaires.

Contexte	Plage de portes
Brouillon, WIP, code exploratoire	Portes 1 à 3
Fonctionnalité ordinaire ou outil interne	Portes 1 à 5
Bibliothèque partagée, chemin de production ou API publique	Portes 1 à 7
Code sensible à la sécurité, authentification, cryptographie, exécution de commandes ou frontière d'entrée utilisateur	Portes 1 à 8

En cas d'ambiguïté, demander quelle est la destination ou le niveau de risque du code.

Phase 2 : Trier les grands périmètres

Lorsque le périmètre de la revue contient plus de 5 fichiers, effectuer un triage rapide avant l'inspection approfondie. Pour 5 fichiers ou moins, ignorer le triage et passer à l'extraction structurelle.

Vérifications du triage :

#	Vérification	Signal d'échec
1	Code mort	Code commenté, importations inutilisées, sortie de débogage
2	Clarté des noms	Les noms publics sont vagues ou trompeurs
3	Profondeur d'imbrication	Imbrication plus profonde que 3 niveaux
4	Longueur des fonctions	Fonctions assez longues pour cacher plusieurs responsabilités
5	Écrasement d'erreur	Catch/except vide ou échec ignoré
6	Mélange de domaines	Entrées-sorties et logique métier mélangés dans une seule unité
7	Assemblage brut de champs	Conditions complexes sans aides sémantiques
8	Odeur de duplication	Logique similaire apparaissant à plusieurs reprises
9	Odeur de sécurité	Secrets, interpolation non sécurisée, logs sensibles, entrée dangereuse non vérifiée

Classifier les fichiers :

Classe	Critères	Action suivante
Rouge	3 vérifications ou plus échouent	Inspection complète de la porte
Jaune	1 à 2 vérifications échouent	Inspecter la porte ciblée et toutes les portes inférieures
Vert	0 vérifications échouent	Réussite, sauf demande spécifique

L'odeur de sécurité est à double voie : la signaler comme une alerte de triage même si la Porte 8 est bloquée par une porte inférieure.

Phase 3 : Extraction structurelle

Avant d'ouvrir les portes, extraire la structure de chaque fonction, classe, module ou unité de code pertinente examinée. Utiliser l'extraction pour guider la revue des portes ; ne pas se fier uniquement au texte brut du diff.

Enregistrer :

• Fermetures, callbacks ou fonctions imbriquées.
• Objets inline ou entités locales avec comportement.
• Opérations d'entrée-sortie et effets de bord externes.
• Imbrication la plus profonde et raison de celle-ci.
• Distribution des domaines : infrastructure, métier, présentation ou mixte.
• Cycle de vie : ponctuel, persistant ou mixte.
• Variables capturées et dépendances cachées.
• Anomalies évidentes découvertes lors de l'extraction.
• Source de vérité disponible pour la Porte 6 : localiser toute spécification ou document de gouvernance (openspec/, PROJECT.md, AGENTS.md, ADRs, un issue lié) pour juger la logique, ou noter qu'aucune n'a été trouvée.

Phase 4 : Revue séquentielle des portes

Lire references/gates.md pour les définitions des portes.

Ouvrir les portes dans l'ordre. Si une porte échoue, arrêter d'ouvrir les portes supérieures pour ce fichier ou ce périmètre de revue. Ne pas inventer de constatations. Le silence signifie conformité pour les sections de détail ; l'index des portes enregistre toujours quelles portes ont été ouvertes, réussies, échouées ou bloquées.

Phase 5 : Rapport

Produire un rapport en utilisant ce format :

## Compte-rendu de revue

**Source** : [référence de l'entrée]
**Calibrage** : Portes 1-[N] ([raison])
**Triage** : [ignoré | Rouge M / Jaune N / Vert K]
**Verdict** : [RÉUSSITE | ÉCHEC à la Porte N]

### Index des portes

| Porte | Axe | Statut |
|---:|---|---|
| 1 | Formatage et hygiène syntaxique | [réussite | échec | bloqué | non inspecté] |
| 2 | Dénomination et lisibilité | [réussite | échec | bloqué | non inspecté] |
| 3 | Gestion des erreurs et observabilité | [réussite | échec | bloqué | non inspecté] |
| 4 | Flux de contrôle et clarté structurelle | [réussite | échec | bloqué | non inspecté] |
| 5 | Responsabilité et limites | [réussite | échec | bloqué | non inspecté] |
| 6 | Intégrité de la logique métier | [réussite | échec | bloqué | non inspecté] |
| 7 | Déduplication et composition | [réussite | échec | bloqué | non inspecté] |
| 8 | Sécurité et intégrité des paramètres | [réussite | échec | bloqué | non inspecté] |

### Alerte de triage sécurité

[Inclure uniquement lorsque la vérification 9 du triage échoue.]

### Porte N : [nom]

| # | Emplacement | Violation | Correction |
|---|---|---|---|
| 1 | `fichier:ligne` | Porte N : norme spécifique violée | Correction concrète |

### Annexe structurelle

[Inclure les résumés des unités de code liées aux constatations.]

Phase 6 : Plan de correction (optionnel)

Produire un plan de correction uniquement lorsque l'utilisateur le demande.

Règles du plan de correction :

• Une violation par correction.
• L'ordre des corrections suit l'ordre des portes.
• Au sein d'une même porte, ordonner par fichier et ligne, sauf si des dépendances logiques imposent un autre ordre.
• Pas de corrections opportunistes.
• Chaque correction inclut des critères de vérification.

Règles

• Revue uniquement ; ne pas modifier le code.
• Utiliser uniquement des entrées locales ou collées ; ne pas appeler d'API MR/PR distantes.
• Ouvrir les portes séquentiellement et s'arrêter à la première porte qui échoue.
• Signaler les alertes de triage sécurité même lorsque l'inspection approfondie de sécurité est bloquée.
• Donner des corrections concrètes ; éviter les suggestions vagues comme « envisager d'améliorer ».
• Si toutes les portes ouvertes réussissent, l'Index des portes est le rapport ; ne pas inventer de constatations.
• Mentionner lorsque les tests, les builds ou les vérifications d'exécution n'ont pas été effectués.
• Rester dans son domaine ; passer le relais à la frontière. Cette compétence est une revue statique et locale uniquement. Pour l'exactitude d'exécution/comportementale, orienter vers verify ; pour une analyse de sécurité approfondie au-delà des vérifications superficielles de la Porte 8, orienter vers security-review. Nommer le transfert plutôt que de faire à moitié le travail de l'autre compétence.