From leoweb-dev
S'active automatiquement quand l'implémentation est terminée — quand tu es sur le point de dire à l'utilisateur "ça devrait marcher", "c'est fait", "tu devrais avoir le résultat attendu", ou toute conclusion similaire. Ne JAMAIS annoncer la fin du travail sans avoir d'abord exécuté ce workflow de vérification. S'applique après l'implémentation d'un plan, la correction d'un bug, l'ajout d'une fonctionnalité, ou tout changement qui produit un comportement observable.
npx claudepluginhub leoweb57/cc-plugins --plugin leoweb-devThis skill uses the workspace's default tool permissions.
Tu DOIS activer ce skill avant d'annoncer à l'utilisateur que le travail est terminé.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Checks Next.js compilation errors using a running Turbopack dev server after code edits. Fixes actionable issues before reporting complete. Replaces `next build`.
Tu DOIS activer ce skill avant d'annoncer à l'utilisateur que le travail est terminé. Si tu es sur le point d'écrire "ça devrait marcher", "c'est bon normalement", "les modifications sont en place" — ARRÊTE. Exécute ce workflow d'abord. L'utilisateur attend des résultats vérifiés, pas des suppositions optimistes.
Utiliser Serena (get_symbols_overview) pour lister les symboles modifiés ou ajoutés sans relire tous les fichiers, et find_referencing_symbols pour vérifier que les appelants existants ne sont pas cassés par les changements.
Liste concrètement ce qui a été modifié :
Si un plan ou une spec existe (ex: spec.md, plan.md, ou instructions de l'utilisateur) :
Si aucun critère explicite n'existe (demande ad-hoc, bugfix, modification rapide) :
Pour chaque critère, choisir la méthode de vérification la plus adaptée :
| Ce qui a changé | Comment vérifier |
|---|---|
| UI / visuel / composant frontend | Playwright MCP : naviguer, interagir, prendre des captures d'écran |
| Endpoint API | curl / httpie via Bash : appeler l'endpoint, vérifier la réponse |
| Schéma ou données en base | Requête SQL via Bash : vérifier la structure des tables, l'intégrité des données |
| Méthode / logique backend | Lancer les tests existants (vitest, pytest, etc.) ou écrire un script rapide |
| Configuration / environnement | Vérifier le service en cours : redémarrer si nécessaire, vérifier le comportement |
| Docker / infrastructure | Commandes docker compose : vérifier que les services sont up et healthy |
| Pipeline CI/CD | MCP GitHub (get_pull_request_status, list_commits) ou MCP GitLab (get_pipeline, get_pipeline_job_output) : vérifier que les jobs passent |
| Dépendances ajoutées ou modifiées | Skill check-deps : vérifier que les versions sont correctes et que les APIs utilisées correspondent à la version installée |
| Imports, signatures, appels | Serena (find_referencing_symbols) : vérifier que tous les appelants existants sont compatibles avec les changements de signatures ou de modules |
| Génération / transformation de fichiers | Lire le fichier de sortie et vérifier son contenu |
Utiliser plusieurs outils si un critère couvre plusieurs couches (ex: "la soumission du formulaire sauvegarde en BDD" = Playwright + SQL).
Pour chaque critère d'acceptation :
Si un test ÉCHOUE :
Ne PAS passer au rapport après une correction — relancer TOUS les scénarios pour détecter les régressions.
Uniquement quand TOUS les scénarios passent, rapporter à l'utilisateur :
Vérification terminée — tous les tests passent.
Testé :
- [critère 1] : PASS (méthode utilisée)
- [critère 2] : PASS (méthode utilisée)
- ...
[Inclure les captures d'écran ou extraits de sortie comme preuve]
Si certains scénarios n'ont pas pu être testés (ex: nécessite l'environnement de production, un service tiers, des identifiants utilisateur) :