leolou0512/claude-skills

Protocole d'autonomie nocturne — l'utilisateur dort et l'agent doit continuer à travailler sans supervision : maintenir les GPU occupés avec l'expérience la plus utile justifiable, enchaîner la tâche suivante quand l'une se termine, et préparer un rapport au réveil. Utiliser quand l'utilisateur dit « au lit », « /bedtime », « je vais dormir », « bonne nuit », « gn », « je dors », « continue la nuit », ou « ne laisse pas les GPU inactifs ». Pas pour les absences courtes (« de retour dans une heure ») — c'est le mode absent normal.

Qu'est-ce que claude-skills ?

Cette compétence permet à un agent IA (comme Claude Code) de fonctionner de manière autonome pendant la nuit, lorsque l'utilisateur dort, en exécutant des expériences de calcul intensif sur GPU. Elle est conçue pour éviter trois échecs principaux : que rien ne se soit passé au réveil, que du calcul soit gaspillé sur une tâche futile, ou qu'une session surveillante meure et laisse les GPU inactifs. La compétence invente, lance et enchaîne des expériences (ablation, baseline manquante, répétition de seed, évaluations sur des checkpoints terminés) en priorisant celles qui réduisent l'incertitude sur le projet en cours. Elle assure la durabilité via des pilotes détachés sur disque (shell scripts nohup), surveille l'avancement avec un réveil périodique, et produit un rapport prêt au réveil. Compatible avec tout agent capable d'exécuter des commandes shell et de lire/écrire des fichiers, elle préserve les ressources GPU en ne touchant pas aux jobs des autres utilisateurs et en n'effectuant aucune action irréversible ou vers l'extérieur.

Compatible avec✓Claude Code~Codex CLI~Cursor

npx skills add https://github.com/leolou0512/claude-skills/tree/HEAD/skills/bedtime

Documentation

/bedtime — autonomie nocturne

L'utilisateur dort ~7-8 h. L'échec à éviter : il se réveille et rien ne s'est passé. Deuxième échec : du calcul brûlé sur quelque chose d'inutile. Troisième : un watcher en session qui est mort avec la session à 02:00 et a laissé les GPU inactifs. Concevoir contre ces trois échecs, dans cet ordre.

1. Accuser réception (≤ 4 lignes, pas de questions)

L'utilisateur part. Ne demandez rien. Indiquez : ce qui s'exécute maintenant, ce que vous ferez cette nuit (l'élément choisi + plan de secours), où se trouvera le rapport du matin. Si une décision lui revient vraiment, prenez la valeur par défaut qui maintient le calcul occupé et réversible, nommez l'hypothèse dans l'accusé de réception, et à nouveau dans BESOIN DE VOUS le matin.

2. Inventaire — ressources et candidats (≤ 10 min, vérifications peu coûteuses)

Calcul : nvidia-smi ici (partagé avec d'autres utilisateurs — ne prenez que les cartes libres, nice les jobs longs, ne touchez jamais aux leurs) ; nœuds distants depuis la liste de machines du projet, si elle existe ; files d'attente de cluster si elles sont en jeu. Notez ce qui est libre, occupé, ou se termine bientôt.
Budget Claude : vérifiez l'utilisation restante. Les flottes et workflows nocturnes peuvent épuiser la limite hebdomadaire ; respectez le seuil d'arrêt de l'utilisateur. Préférez les pilotes sur disque (coût zéro tokens pendant leur exécution) aux boucles pilotées par l'agent.
Candidats, par ordre de priorité — choisissez le plus élevé qui correspond au calcul libre :
1. Le travail déjà mis en file par l'utilisateur : la conversation du jour, la phase suivante du plan de bataille, le dernier fichier de passation « la prochaine session devrait reprendre », fichiers WRAPUP_PLAN / TODO.
2. L'expérience qui réduit le plus l'incertitude sur l'objectif actuel (généralement le papier) : l'ablation qu'un relecteur exigerait, la baseline manquante, la répétition de seed.
3. Évaluations/mesures sur les checkpoints terminés (métriques du projet) — peu coûteux, toujours utiles.
4. Analyse des résultats terminés → graphiques/rapport dans le dossier de rapports du projet.
5. Hygiène de code — uniquement s'il n'existe aucun travail adapté au calcul. Préférez le travail gourmand en heures GPU : ce qui est gaspillé la nuit, ce ne sont pas les heures GPU inactives, pas votre temps. Évitez tout ce qui nécessite la décision de l'utilisateur pour être utile, tout ce qui est déjà inutile, et tout ce qui touche à une conception que l'utilisateur a figée. Comparaisons contrôlées : un facteur à la fois, rien qui ne casse la comparabilité avec la baseline.

3. Lancement — avec l'hygiène habituelle, plus la durabilité

Résolvez la configuration et indiquez ce qui entre en jeu (lignes, filtres, split, chaque écart par rapport à la baseline) dans le journal, pas seulement dans votre tête. Testez d'abord la commande exacte avec un smoke test.
Pilote détaché sur disque, pas une boucle agent : nohup setsid <pilote>.sh écrivant state.txt / result.txt / logs sous <run>/ (le modèle final_now_driver.sh). Le pilote enchaîne lui-même les étapes et les jobs suivants, avec des délais par étape qui échouent bruyamment. Si cette session meurt, les GPU restent occupés.
Vérifiez l'effet, pas l'action : processus vivant après le démarrage, premières lignes de log, premiers points wandb ; URL wandb dans le rapport du matin.
Un élément par GPU libre maximum ; laissez une carte libre si le job d'un colocataire se termine clairement et voudra la récupérer — machine partagée.

4. Surveillance — clairsemée, durable

Armez un moniteur (Monitor tool / ScheduleWakeup ~30-60 min) dont le seul travail est : mort ? → diagnostiquer ; relancer si la cause est simple et comprise (OOM → lot plus petit, faute de chemin) ; sinon passer au candidat suivant. Terminé ? → le pilote aurait déjà dû lancer le job suivant ; s'il ne l'a pas fait, lancez-le. GPU inactif à chaque réveil = agir, pas noter.
Attente avant observation à chaque réveil : indiquez la perte/epoch/step que vous attendez, comparez, une ligne dans le journal de nuit.
Si le contexte devient trop long → écrivez un fichier de passation YYYY-MM-DD_overnight.md MAINTENANT, incluant comment vérifier chaque pilote, puis continuez.
Poussées : aucune la nuit, sauf une si tout le plan s'est effondré et ne peut être récupéré — ils la liront au réveil. Tout le reste attend le rapport.

5. Livrable du matin

Un fichier de rapport YYYY-MM-DD_overnight.md : ce qui a été lancé et pourquoi (l'échelon de l'échelle), ce qui s'est terminé, chiffres vs baseline, ce qui est mort et ce qui a été sauvé, ce qui tourne encore avec des ETA absolus, liens.
Premier message lorsque l'utilisateur apparaît : /qu format, sans y être invité, pointant vers ce fichier. Tout ce que vous avez décidé pour lui → en haut de BESOIN DE VOUS avec la valeur par défaut que vous avez prise.

Jamais la nuit

Aucune action irréversible ou tournée vers l'extérieur : pas de push vers main, pas de force-push, pas de suppression de runs/checkpoints/données, pas de dépenses sur service payant au-delà de ce qui a été approuvé, pas de réouverture de décisions verrouillées, pas de modifications des affirmations du papier. Rien qui nécessite leur présence pour être utile. Rien sur le processus, GPU ou configuration d'un autre utilisateur.