By name: vqo description: > Vibecoding Quality Orchestrator (VQO) — Méthode d'audit itératif multi-agents pour valider la qualité du code avant production. Déclenche ce skill dès que l'utilisateur demande un audit qualité, une revue de code approfondie, une validation avant merge/deploy, ou mentionne "VQO", "audit qualité", "quality gate", "pre-production check", "revue sécurité + perf", ou veut s'assurer qu'un module critique (auth, paiement, API) est solide. Utilise aussi ce skill quand l'utilisateur dit "lance un VQO", "audite mon code", "vérifie la qualité", "est-ce prêt pour la prod", ou toute variante. Le skill fonctionne avec n'importe quel stack (NestJS, Express, Django, Angular, React, Vue, etc.) et détecte automatiquement les technologies du projet.
Vibecoding Quality Orchestrator (VQO)
Méthode d'audit itératif pour valider la qualité du code avant production. Fonctionne sur n'importe quel stack — détecte automatiquement les technologies du projet.
Principe fondamental
Deux rôles alternent dans un cycle itératif :
- ALPHA audite le backend (sécurité, performance, résilience)
- BETA audite le frontend (architecture, qualité, testabilité, accessibilité)
Après chaque audit, les corrections sont appliquées, les tests sont exécutés, puis un nouvel audit vérifie la progression. Le cycle s'arrête quand tous les domaines atteignent 9.5/10 ou après 5 itérations maximum.
Étape 0 — Détection du stack
Avant tout audit, analyse le projet pour identifier :
- Backend : framework (NestJS, Express, Fastify, Django, FastAPI, Rails...), langage, ORM, gestionnaire de packages
- Frontend : framework (Angular, React, Vue, Svelte, Next.js...), langage (TS/JS), bundler, CSS framework
- Tests : frameworks de test présents (Jest, Vitest, Mocha, Pytest, Cypress, Playwright...)
- Build : commandes de build et lint (lire package.json, Makefile, pyproject.toml, etc.)
# Exemples de détection
cat package.json 2>/dev/null # Node.js
cat pyproject.toml 2>/dev/null # Python
cat Gemfile 2>/dev/null # Ruby
ls src/ apps/ lib/ 2>/dev/null # Structure
cat tsconfig.json angular.json next.config.* vite.config.* 2>/dev/null
Adapte les critères d'audit et les commandes de vérification au stack détecté.
Consulte references/stack-profiles.md pour les profils de stack prédéfinis.
Étape 1 — Audit ALPHA (backend)
Consulte references/alpha-audit.md pour les critères détaillés.
Audite le code backend sur 3 domaines pondérés :
| Domaine | Poids | Ce qu'on cherche |
|---|---|---|
| Sécurité | 25% | Validation des entrées, authentification, autorisation, injection, données sensibles exposées, rate limiting, sanitisation des erreurs |
| Performance | 15% | Parallélisation I/O, cache, timeouts, requêtes N+1, structures de données, pagination |
| Résilience | 10% | Gestion d'erreurs exhaustive, circuit breakers, timeouts sans fuites, fallbacks, gestion des cas null/vides |
Pour chaque problème trouvé, génère un ticket au format :
ID : ALPHA-SEC-001 | ALPHA-PERF-002 | ALPHA-RES-003
Sévérité : CRITIQUE / MAJEUR / MINEUR
Fichier : chemin relatif + ligne
Problème : description précise
Fix : code avant → code après
Calcule une note /10 par domaine, puis la note pondérée globale ALPHA.
Étape 2 — Audit BETA (frontend)
Consulte references/beta-audit.md pour les critères détaillés.
Audite le code frontend sur 4 domaines pondérés :
| Domaine | Poids | Ce qu'on cherche |
|---|---|---|
| Architecture | 20% | Séparation des responsabilités, patterns du framework, composants smart/dumb, DRY, gestion d'état |
| Qualité de code | 15% | Typage strict (pas de any), nommage, pas de code mort, commentaires pertinents, validation des données |
| Testabilité | 10% | Couverture des composants clés, cas limites, interactions testées, mocks appropriés |
| Accessibilité | 5% | ARIA labels, navigation clavier, rôles sémantiques, contrastes, sr-only, focus management |
Pour chaque problème trouvé, génère un ticket au format :
ID : BETA-ARCH-001 | BETA-QUAL-002 | BETA-TEST-003 | BETA-A11Y-004
Sévérité : CRITIQUE / MAJEUR / MINEUR
Fichier : chemin relatif + ligne
Problème : description précise
Fix : code avant → code après
Calcule une note /10 par domaine, puis la note pondérée globale BETA.
Étape 3 — Corrections
Applique les corrections dans l'ordre de sévérité :
- Tous les tickets CRITIQUE
- Tous les tickets MAJEUR
- Les tickets MINEUR si le temps/contexte le permet
Pour chaque correction appliquée, indique le ticket résolu (ex: "Fix ALPHA-SEC-001").
Étape 4 — Vérification automatique
Exécute les tests et le build du projet. Les commandes sont adaptées au stack détecté.
# La détection du step 0 détermine les commandes exactes.
# Exemples typiques :
# Node.js backend
npm test -- --passWithNoTests 2>&1 | tail -20
# Frontend Angular
npx tsc --noEmit && npx ng build 2>&1 | tail -20
# Frontend React/Next
npx tsc --noEmit && npm run build 2>&1 | tail -20
# Python
python -m pytest 2>&1 | tail -20
# Lint (si configuré)
npm run lint 2>&1 | tail -20
Si des tests échouent ou que le build casse, corrige immédiatement avant de relancer l'audit.
Étape 5 — Boucle itérative
Score ALPHA >= 9.5 ET Score BETA >= 9.5 ?
→ OUI : Audit terminé. Affiche le rapport final.
→ NON : Retour à l'Étape 1 (itération N+1)
Itération >= 5 ?
→ OUI : Arrêt forcé. Affiche le rapport avec les scores actuels
et la liste des problèmes restants.
Rapport final
À la fin du cycle (succès ou arrêt à 5 itérations), produis un rapport structuré :
══════════════════════════════════════════════
VQO — RAPPORT FINAL
Projet : [nom]
Stack : [backend] + [frontend]
Date : [date]
══════════════════════════════════════════════
Itérations : N/5
Résultat : ✅ VALIDÉ (>= 9.5) | ⚠️ SEUIL NON ATTEINT
┌─────────────────┬──────────┬──────────┐
│ Domaine │ Poids │ Note │
├─────────────────┼──────────┼──────────┤
│ Sécurité │ 25% │ X.X/10 │
│ Performance │ 15% │ X.X/10 │
│ Résilience │ 10% │ X.X/10 │
│ Architecture │ 20% │ X.X/10 │
│ Qualité code │ 15% │ X.X/10 │
│ Testabilité │ 10% │ X.X/10 │
│ Accessibilité │ 5% │ X.X/10 │
├─────────────────┼──────────┼──────────┤
│ SCORE GLOBAL │ 100% │ X.X/10 │
└─────────────────┴──────────┴──────────┘
Tickets résolus : XX
Tickets restants : XX (détail ci-dessous si > 0)
[Liste des tickets non résolus avec sévérité]
Quand utiliser VQO
- Avant un merge de feature significative
- Après un epic complet
- Pour valider un module critique (auth, paiement, API externe)
- Avant un déploiement en production
- Sur demande de l'utilisateur ("lance un VQO", "audite ce code")
Scope partiel
Si le projet n'a qu'un backend ou qu'un frontend, lance uniquement l'audit correspondant (ALPHA ou BETA). Adapte les poids pour que le total fasse toujours 100%.
- Backend seul : Sécurité 50%, Performance 30%, Résilience 20%
- Frontend seul : Architecture 40%, Qualité 30%, Testabilité 20%, Accessibilité 10%