09.03.01 — Skills Review#

Lectures statiques, remontent des constats. Une grande famille. Permet à l’IA d’effectuer de la revue sur son projet de manière systématique.

Listing (potentiellement non exhaustif)#

review-dead-code#

input  : base de tests
output : liste des éléments non utilisés (connectors / POMs / scénarios / fragments / constantes)
         + recommandation par élément :
            - supprimer
            - mettre en incubateur (<racine-source>/incubator/, arbre de dépendances préservé)
            - conserver (justifier)

review-report#

input  : une exécution récente (logs + reports)
output : classification de chaque test :
            - PASS                  (rien à faire)
            - SKIP                  (pourquoi ?)
            - intentional gap FAIL  (G-DATA-*, G-SEC-*, ...)
            - cross-browser FAIL    (B-BROWSER-*)
            - transient FAIL        (A-ENV-*)
            - régression            ⚠️ ALERTE

review-watcher-misuse#

input  : tous les watcher.report(...)
output : liste des reports qui semblent positifs (« success », « completed », « ok », ...)
         → recommandation : supprimer ou reformuler en négatif

review-comment-drift#

input  : tous les commentaires du code
output : liste des commentaires qui semblent ne plus correspondre au code adjacent
         (typique : commentaire mentionne foo, code mentionne bar)

Aide à éliminer les commentaires obsolètes.
« Teach the pattern, not the symptom ».

09.03.02 — Skills Analyse#

Analyses dynamiques : utilisent les logs / les rapports d’une exécution récente pour diagnostiquer un échec. Deux skills de diagnostic de cause racine ouvrent la famille — diagnose-root-cause pour un rouge déterministe, diagnose-flake-root-cause pour un échec intermittent — et aiguillent vers les expériences contrôlées analyse-*.

Listing (potentiellement non exhaustif)#

diagnose-root-cause#

input  : un rouge déterministe (échoue à chaque exécution)
output : analyse de cause racine structurée :
            - reprend l'analyse de zéro, sans réutiliser les hypothèses précédentes
            - remonte du synthétique vers le réel (faux driver → vrai navigateur)
            - lit la source, confirme avec une sonde
            - cause racine triée en cinq familles
         passe la main à diagnose-flake-root-cause si l'échec se révèle intermittent

diagnose-flake-root-cause#

input  : un échec intermittent (un flake)
output : analyse de cause racine fondée sur la distribution :
            - établit un taux d'échec (la distribution est la preuve)
            - fixe la signature, corrèle
            - aiguille vers la bonne expérience analyse-*, augmente le taux pour confirmer
            - classe en cinq familles de flakes
         l'orchestrateur de la famille analyse-*

analyse-flakiness#

input  : logs des N dernières exécutions
output : liste de tests qui retry souvent (par % de retries)
         + recommandation :
            - ajouter une exception au tuple transient_errors
            - investiguer un test particulier (peut-être que le problème vient directement du test)

analyse-fixture-flakiness#

input  : tests avec setup/teardown
output : tests dont le setup fail souvent
         + recommandation :
            - vérifier l'idempotence du setup
            - voir si teardown propre (sinon contamination entre tests)
            - sortir le seed du setup vers une init manuelle si trop fragile

analyse-watcher-flakiness#

input  : logs des watcher.report(...) sur N runs
output : watchers à reporting anormal :
            - trop d'émissions (problème de dedupe)
            - aucune émission (le watcher est inutile)
            - faux positifs (élément attendu reporté comme intrus)

analyse-screenshot-flakiness#

input  : screenshots de N runs, groupés par (test, step, browser)
output : flakiness visuelle :
            - tests dont les screenshots varient anormalement entre runs
            - tests qui passent mais dont l'aspect change
            - identifier si la variation est sémantique (vraie diff) ou cosmétique

Utilise des heuristiques (hash, dimensions, palette dominante). Pas une vraie image diff.

09.03.03 — Skills Black-hat (6)#

Idéations de vulnérabilités de logique métier — pas d’exécution : « security testing is functional and static, never active ».

Listing (potentiellement non exhaustif)#

Périmètre#

Tous ces skills imaginent des attaques que l’IA pourrait formuler.

09.03.04 — Skills Comprehend#

Skills qui aident l’IA à comprendre un projet ou un écosystème avant d’agir.

Listing (potentiellement non exhaustif)#

understand-ocarina#

input  : question de l'utilisateur — aiguillée selon sa classe :
            - "comment fait-on un match_page ?"   (référence : ce qu'est une primitive) → Holy Book
            - "pourquoi la suite est-elle bâtie sur Railway ?" (intention / cartographie / pourquoi) → le livre from-ocarina-to-igor
output : Claude charge, selon la classe de question :
            - référence    → les pages Holy Book pertinentes (https://mojo-molotov.github.io/ocarina-holy-book)
            - intention    → les chapitres pertinents du livre from-ocarina-to-igor (https://mojo-molotov.github.io/from-ocarina-to-igor/)
            - comportement → la source d'Ocarina (clone), si la doc ne le couvre pas
            - forme        → l'exemple correspondant à l'adaptateur du projet :
                              Selenium   → ocarina-example, ocarina-with-ai-example
                              Playwright → ocarina-with-playwright-example
         puis répond avec citations (tier + URL de page/chapitre ou file:line)

SKILL.md :

09.03.05 — Skills Pick#

Sélection d’artefacts (screenshots, logs, reports). Toujours par mtime, jamais par nom de fichier.

Listing (potentiellement non exhaustif)#

« mtime »#

Citation du Holy Book :

09.03.06 — Skills Author#

Skills qui produisent un livrable. Tests, sondes, docs, rapports.

Listing (potentiellement non exhaustif)#

empiricism#

input  : intention de l'utilisateur (« écris un test qui assert X »)
output : avant d'encoder X :
            1. vérifier empiriquement que X est vrai
                - sonde
                - gh api du code source
                - curl -v pour inspecter réponses HTTP
                - ...
            2. si X est confirmé → encoder
            3. si X est faux → corriger l'intention
            4. si X est ambigu → demander à l'humain

« Juste remarque, je suppose. Je vérifie empiriquement. »

09.03.07 — Skills Refactor#

Skills qui refactor la base de tests automatisés existante.

Listing (potentiellement non exhaustif)#

refactor-fragmentation#

input  : la base de tests
output : suggestions de refactor DRY :
            - blocs répétés dans 3+ scénarios → extract en fragment
            - connectors quasi-identiques → extract un connector paramétré
            - séquences de log+screenshot répétées → extract un helper
         + recommandation au cas par cas

CLAUDE.md :

09.03.08 — Skill State#

Un seul skill : question-state. Interroge l’environnement avant de croire un résultat.

Le skill#

input  : un résultat surprenant (« le test fail »)
output : une série de questions sur l'état :
            - sur quel browser tourne-t-on ?
            - quel commit ?
            - le SUT est-il warm ou cold ?
            - le Redis est-il disponible ?
            - quel est le wait-timeout configuré ?
            - quelle est la version du driver ?
            - le ChromeDriver a-t-il son fix password-manager-off ?
            - est-ce un run isolé ou un run en parallèle ?
            - est-ce que d'autres tests touchent les mêmes ressources SUT ?

Approche#

CLAUDE.md :

09.03.09 — Skills Setup#

Deux skills : setup-environment (onboarding d’un nouveau contributeur, humain ou IA) et profile-environment (cadre la latitude laissée à l’IA pour une mission donnée). Tous deux alimentent le CLAUDE.md assemblé de la suite.

Le skill#

input  : un repo frais
output : étapes d'onboarding :
            1. venv
            2. pip install (deps dev + ocarina)
            3. ruff / mypy / pre-commit installés
            4. CLAUDE.local.md créé (avec demande paths à l'utilisateur)
            5. smoke-check du runner (un test minimal qui valide que tout marche)
            6. boucle pré-commit testée

Étape 1 : venv#

python -m venv .venv
source .venv/bin/activate

Étape 2 : pip install#

pip install . ruff mypy mypy-extensions typing-extensions pre-commit

Étape 3 : outillage de dev#

pre-commit install --config .pre-commit-config.yaml

Étape 4 : CLAUDE.local.md#

CLAUDE.local.md est gitignored et contient les paths machine-specifiques.

09.03.10 — Skills Run#

Faire remonter les choix à trancher avant un lancement local, composer la commande, et la rendre. Le skill ne lance jamais l’exécution lui-même.

Listing (potentiellement non exhaustif)#

propose-visual-review#

input  : une exécution locale à venir
output : le choix fenêtré vs headless :
            - --not-headless : on regarde le navigateur, utile pour déboguer un flux flaky
            - headless (façon CI) : plus rapide, identique à ce que fait la CI
         + le compromis et ce qu'il faut surveiller pendant une exécution fenêtrée
         + la commande composée, rendue à l'utilisateur pour qu'il la lance

Rôle#

• Faire remonter le choix d’avant-exécution ; expliquer le compromis.
• Composer la commande.
• Ne pas la lancer : c’est l’utilisateur qui exécute.