STOP. LISEZ CET INTÉGRALITÉ DE SKILL.MD AVANT D'APPELER UN POINT DE TERMINAISON.
Évaluer
Prenez du recul et réévaluez de manière critique l'état du projet. Fournit un guidage interactif (humain dans la boucle) et une analyse programmatique (pipelines automatisés). Spécialisé dans la taille de documentation et l'alignement doc-code.
Utilisation en CLI
# Évaluation JSON structurée pour les pipelines
.pi/skills/assess/assess.py run . --output assessment.json
# Générer toutes les figures à partir de l'évaluation
create-figure from-assess --input assessment.json --output-dir ./figures/
Flux d'Évaluation
1. Cadrer l'Évaluation
Cadre clair (« évaluer le module d'authentification ») → procéder directement. Cadre ouvert (« prendre du recul ») → demander : préoccupations ? qualité du code vs docs ? problèmes connus à ignorer ? Taille de documentation (« tailler la documentation ») → demander : fonctionnalités obsolètes ? docs manquantes ? alignement ?
2. Trouver la Racine du Projet et Détecter l'Écosystème
Détection via fichiers marqueurs (pyproject.toml, package.json, Cargo.toml, go.mod). Lire les métadonnées spécifiques à l'écosystème, puis les docs universels (README.md, CONTEXT.md, AGENTS.md).
3. Charger le Manifeste de Compétence (Contrôle d'Accès par Route)
Charger .pi/skills-manifest.json pour les évaluations qui pourraient conduire à des recommandations du type « nous devrions construire X ». Ignorer pour les vérifications d'état et les révisions de documentation uniquement.
cat .pi/skills-manifest.json | python3 -c "
import json, sys
data = json.load(sys.stdin)
print(f'Compétences : {data[\"skill_count\"]} (générées : {data[\"generated\"]})')
"
Avertir si le manifeste a plus de 7 jours. Solution de repli : ls .pi/skills/ | wc -l.
4. Analyse Rapide → Point de Vérification → Exploration Approfondie
- Lire les métadonnées du projet, le README, glob pour la structure
- Noter 2-3 observations initiales, faire le point avec l'utilisateur
- Exploration approfondie basée sur les directives de l'utilisateur — pour chaque constat : bloquant ? connu ? complexité de correction ?
5. Rapport Collaboratif
Présenter les constats et demander lesquels corriger. Proposer /create-figure pour la visualisation.
Catégories d'Évaluation
1. Alignement Doc-Code
- Revendications du README vs implémentation
- Validation des références croisées (liens internes, exemples de code)
- Marqueurs d'espace réservé et informations obsolètes
- Obsolescence : docs pour les fonctionnalités supprimées
2. Aspirationnel vs Implémenté
- Stubs (
pass,raise NotImplementedError), notes d'espace réservé - Fonctionnalités dans la structure du code mais sans logique, dépendances inutilisées
3. Code Fragile
- Valeurs codées en dur, gestion des erreurs manquante, regex/analyse fragile
4. Code Non Fonctionnel
- Chemins de code morts, absorption silencieuse d'exceptions, intégrations cassées
5. Code Sur-Ingénieuré
- Abstractions avec une seule implémentation, configuration pour une flexibilité hypothétique
6. Couverture de Test (Non Négociable)
Vérifier chaque fonctionnalité/module pour les fichiers de test, tests passants, cas limites.
Signaler pytest.mark.skip sans raison, « 0 tests collectés », tests qui n'effectuent pas d'assertion.
Audit des fichiers de tâche : Vérifier que chaque tâche a une Définition de Terminé avec un test/assertion spécifique. Bloquer l'exécution si les tâches d'implémentation manquent de Définition de Terminé.
7. Ce qui Fonctionne Bien
Reconnaître le code solide pour calibrer l'évaluation.
Format de Sortie
# Évaluation : <nom-du-projet>
## Résumé
<2-3 phrases : état général, constats clés>
## Constats
### Alignement Doc-Code
| Revendication | Réalité | Action ? |
### Problèmes Trouvés
1. **fichier.py:123** - [Problème] — Gravité : É/M/F — Correctif suggéré : [bref]
### Couverture de Test
| Fonctionnalité | Statut du Test | Action Nécessaire |
### Ce qui Fonctionne Bien
- [Code solide à reconnaître]
## Prochaines Étapes Recommandées
1-4 actions priorisées. Demander par laquelle commencer.
Politiques
- Lecture seule par défaut — ne jamais écrire de fichiers sans consentement explicite
- Imprimer d'abord, écrire avec consentement — montrer le contenu proposé, puis proposer d'écrire
- Collaborer — l'évaluation est un dialogue, pas un monologue
- Demander avant d'exécuter — obtenir la permission avant les tests, builds, services payants
- Escalader judicieusement — suggérer
/review-codepour les problèmes complexes/critiques - Être spécifique — chemins de fichiers et numéros de ligne
- Être actionnable — chaque constat suggère des prochaines étapes
- La couverture de test est non négociable — signaler les tests manquants comme bloquants
Recherche Externe
Disponible lorsque nécessaire (demander avant les services payants) :
/context7— documentation des bibliothèques (gratuit)/brave-search— web général (gratuit)/perplexity— recherche approfondie (payant)
Erreurs Courantes
# FAUX : Traiter tous les constats d'évaluation comme des problèmes bloquants
# → L'agent ajoute automatiquement des docstrings à 12 helpers privés. Gonflement inutile.
# CORRECT : Examiner les constats avec l'utilisateur. Escalader les problèmes complexes vers /review-code.
# FAUX : Sauter /assess après des changements majeurs
# → Les exemples du README utilisent une ancienne signature de fonction. Les utilisateurs rencontrent des erreurs.
# CORRECT : Lancer assess --focus "doc-code-alignment" après avoir modifié les API principales
# FAUX : Lancer /assess et agir sur des résultats obsolètes
# → L'évaluation date de 3 jours. La base de code a changé depuis.
# CORRECT : Toujours relancer assess ; ne jamais mettre en cache les résultats entre sessions