09.03 — Skills exposées aux IA#

Plus de 40 skills (procédures destinées aux LLMs) versionnés sur GitHub. Classés par familles. Documentés dans le Holy Book (chapitre « Utiliser Ocarina avec l’IA »).

Arborescence de fichiers#

ai/skills/
├── README.md
└── <skill-name>/
    └── SKILL.md

Chaque skill = un dossier + un SKILL.md

SKILL.md :

Frontmatter YAML avec name et description (utilisée par Claude pour décider de trigger ce skill).
Corps Markdown : la procédure détaillée, sections, étapes, exemples.

README.md :

Index des skills : regroupe par familles, rappelle des interconnexions possibles.

Le plugin docs/.vitepress/plugins/skills.ts traverse ce dossier et les copie pour en faire des pages publiques /skills/<name>.

Familles (liste non exhaustive)#

#	Famille	Sujet
01	Review	Lectures statiques, remontent des constats
02	Analyse	Dynamique : flakiness, fixture, watcher, screenshot
03	Black-hat	Idéations de vulnérabilités de logique métier
04	Comprehend	Catalogue, écosystème, contraintes SUT, indexation d’Ocarina dans le contexte du LLM
05	Pick	Utilisation des artefacts (screenshots, logs, reports)
06	Author	Délègue la production de livrables au LLM
07	Refactor	Refactor, DRY, introduction de retries dans les POM
08	State	Questionne les états dans le SUT (bouchons, persistance des données…)
09	Setup	Préparer l’environnement (`setup-environment`) + cadrer la latitude laissée à l’IA pour une mission (`profile-environment`)
10	Run	Choix d’avant-exécution (fenêtré vs headless) avant un lancement local
…	…	…

« Remonter, ne pas appliquer »#

Remonter, ne pas appliquer. Les skills produisent ; l’utilisateur décide.

Chaque skill produit un rapport / une suggestion / un diff.
L’humain décide d’appliquer ou non.

Chaînes récurrentes#

1. Cycle en échec#

review-report          →  analyse-*         →  write-a-probe
        ↓                       ↓                      ↓
   classification         instrumentation         script jetable
                                                       ↓
trouvailles propagées dans IDENTIFIED_GAPS.md / SFD / commentaires de scénario
                                                       ↓
                                                sonde supprimée

2. Scénario black-hat prometteur#

empiricism             →  extend-coverage
    ↓                          ↓
vérifier le SUT          souvent en échec intentionnel

3. Changement de spec#

update-frd-and-tests    (SFD d'abord, tests ensuite)
        ↓
les tests gap sont reformulés, pas basculés bêtement du rouge au vert

4. Nouvelle primitive Ocarina#

understand-ocarina      →  mise à jour → reprise
        ↓
parcourt la doc

Discipline transversale#

Remonter, ne pas appliquer. L’utilisateur décide.
Empirique plutôt qu’assertif. Phrase rituelle : « Juste remarque, je suppose. Je vérifie empiriquement. »
Les tests gap sont reformulés, pas basculés au vert.
Les signaux des watchers sont négatifs uniquement. Un watcher qui émet « login réussi » casse le contrat.
Utilisation de systèmes distribués quand une ressource est partagée.
Repérage des artefacts avec mtime, pas juste par nom de fichier. Les suffixes UUID sont aléatoires.
La latitude ne fait que se resserrer. Par défaut, tout est autorisé : démo publique ouverte (lire la source du SUT, sonder l’application réelle, identifiants publics). profile-environment resserre selon la mission ; rien ne desserre jamais la ligne de sécurité.

Hors périmètre#

Ne génère pas de tests de façon autonome.
Ne patche pas les hallucinations en CI ; un échec déclenche review-report + analyse-*.
Ne réécrit pas la spec ; seul update-frd-and-tests le fait, avec une ligne de révision.
Ne fait pas de tests de sécurité actifs. Jamais.

Le périmètre est strict.
L’IA est un outil, pas un substitut au jugement humain.