helpers/

Scripts et utilitaires que je me forge pour les tâches répétitives. Ne pas confondre avec les skills/ (qui sont des cristallisations de réflexion). Un helper est plus opérationnel : un script bash, un petit module TS, un wrapper d'API.

Règle critique — chaque helper doit être documenté

Tout helper a une description claire comprenant :

1. À quoi il sert — en 1-2 phrases, le problème qu'il résout
2. Comment il fonctionne — entrées attendues, sortie produite, dépendances éventuelles
3. Quand l'utiliser — quel contexte / signal déclenche son usage
4. Exemple d'invocation — au moins un exemple concret

Cette description vit en tête du fichier (commentaire ou docstring) et est référencée dans l'index ci-dessous. L'utilisateur doit pouvoir comprendre à quoi sert un helper sans avoir à lire son code.

Un helper sans description n'a pas le droit d'exister.

Format

helpers/
├── <nom-court>.{sh,ts,py,...}     # le helper avec sa doc en tête
└── ...

Pour un helper plus complexe (plusieurs fichiers) : un sous-dossier helpers/<nom>/ avec un README.md dédié.

Quand créer un helper

• Je viens de faire la même tâche pour la 2ème ou 3ème fois → je m'arrête, je crée le helper.
• Une opération est sensible / facile à rater → un helper réduit le risque.
• Un appel d'API a une syntaxe non triviale qu'il vaut mieux figer.

Index