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.

Le skill setup-environment :

Vérifie si le fichier existe.
Sinon : le crée avec le template du CLAUDE.md.
Demande à l’utilisateur les paths (chromedriver, clones des repos de l’écosystème d’Ocarina).
Ne devine pas les paths (sauf find ~/ -name chromedriver -type f 2>/dev/null qui est documenté comme aide).

CLAUDE.md :

CLAUDE.local.md is gitignored and stores per-machine paths. If it’s missing, create it with the template below — and ask for the paths, don’t guess.

Étape 5 : smoke-check du runner#

python -u src/main.py --browser firefox --driver-path ./geckodriver --workers 3 --only "valid_login"

Lance juste un test de fumée. Si ça passe : l’environnement est OK.

Le --only valid_login filtre tout le reste. Permet un check rapide plutôt qu’un cycle complet.

Étape 6 : boucle pre-commit#

# faire un edit mineur dans src/
git add src/edited_file.py
git commit -m "test: setup smoke"

Le pre-commit doit s’exécuter. Si fail : signalé, debug ensemble.
En mode « vibe testing », plus le pre-commit est agressif mieux c’est : l’IA se retrouve dans un contexte proche de ce que l’on appelle l’apprentissage par renforcement.

Si le pre-commit a une « grosse » batterie, comme par exemple de croiser les vérifications du formatage du code, du lint et du typage systématiquement, l’IA sera bien plus efficace pour se corriger rapidement et ne pourra jamais commit quelque chose de totalement inapproprié (= qui ne « compile » même pas).

Valeur ajoutée#

Sans skill	Avec skill
Le nouveau venu lit le README, fait les étapes à la main, se trompe, s’énerve, publie une vidéo YouTube pour insulter Ocarina	Étapes séquentielles, vérifiées une par une
Pas de check que tout marche vraiment	Smoke-check confirme
`CLAUDE.local.md` souvent oublié	Le skill force sa création

`profile-environment` — le cadre de la mission#

setup-environment met en place la mécanique. profile-environment répond à une autre question : jusqu’où l’humain laisse-t-il l’IA aller sur ce SUT ?

Par défaut, toute la batterie de skills répond implicitement : le maximum. Le Holy Book a été écrit pour CURA, une démo publique open-source aux identifiants publics codés en dur ; les règles autorisent donc tout : lire la source du SUT, lancer une sonde jetable sur l’application réelle, fouiller le web ouvert, se servir d’identifiants publics. Une vraie mission est plus restreinte.

profile-environment mène un entretien de cadrage sur sept dimensions, tranchées avec l’humain (ce sont des décisions de parties prenantes, pas des faits qu’on déduit du code) :

Dimension	Question
Accès à la source	L’IA peut-elle lire la source du SUT ?
Sondage du système en fonctionnement	Peut-elle lancer une sonde jetable sur l’application réelle ?
Sensibilité des données	Données de démo, ou vraies données personnelles / réglementées ?
Sortie de données & confidentialité	Recherche web autorisée ? NDA en place ?
Seuil des tests de sécurité	Où passe la ligne des tests actifs ?
Autonomie & validation	Faut-il une validation avant chaque exécution ?
Surface de modification (repo, CI, PR)	À quoi l’IA a-t-elle le droit de toucher ?

Il produit un appendice CLAUDE.profile.md versionné que setup-environment concatène dans le CLAUDE.md de la suite. C’est un cliquet vers la restriction : il ne fait que resserrer les règles par défaut (réglées au maximum) et la ligne de sécurité, jamais les desserrer.

À lancer au début de toute mission qui sort du cas de la démo publique ouverte : un site client, une application interne, un projet sous NDA, un SUT manipulant de vraies données personnelles. À relancer dès que les conditions changent : passage de la démo au client, du staging à la prod, signature d’un NDA, repo qui bascule en privé.

« Onboarding scriptable »#

C’est l’incarnation du principe : un projet doit être bootstrappable en suivant une recette. Pas de savoir tribal, pas de « ah oui faut faire ça aussi ».

Citations du Holy Book :

Les étapes d’onboarding (venv, pip install, ruff / mypy / pre-commit, smoke-check du runner) vivent dans setup-environment.

Ocarina est dense, immédiatement opérationnel et strict. Pensé pour que les humains ainsi que les LLMs en comprennent le cœur et l’usage sans friction.

Lien avec la philosophie « auditable en une après-midi »#

Cf. ../../11-independence/02-auditability.md

L’onboarding scriptable est le prélude à l’audit : sans pouvoir faire tourner le projet, on ne peut pas le comprendre.