leolou0512/claude-skills

Übernacht-Autonomie-Protokoll – der Benutzer geht schlafen und der Agent muss unbeaufsichtigt weiterarbeiten: die GPUs mit dem wertvollsten Experiment auslasten, das er vertreten kann, den nächsten Job automatisch starten und morgens einen Bericht parat haben. Einschalten, wenn der Benutzer „Bettzeit“, „/bedtime“, „gehe ins Bett“, „gute Nacht“ oder ähnliches sagt. Nicht für kurze Abwesenheiten („in einer Stunde zurück“) – das ist normaler Away-Modus.

Was ist claude-skills?

Dieses Skill definiert ein formales Übernacht-Autonomie-Protokoll für KI-Agenten, das entwickelt wurde, um die Arbeitslast während des Schlafs des Benutzers (7–8 Stunden) zu maximieren. Es ist für plattformunabhängige KI-Agenten wie Claude Code konzipiert, die über Shell-Zugriff und die Fähigkeit verfügen, CLI-Tools auszuführen. Das Skill verhindert drei Hauptfehler: dass der Agent untätig bleibt, Rechenleistung für sinnlose Aufgaben vergeudet oder dass eine Sitzungsüberwachung mit der Sitzung stirbt und die GPUs im Leerlauf zurücklässt. Es gibt einen schrittweisen Workflow vor: (1) Bestätigung ohne Rückfragen, (2) Bestandsaufnahme der freien Rechenressourcen und Kandidatenexperimente in Prioritätsreihenfolge (beginnend mit Benutzerwarteschlangen), (3) Start mit einem entkoppelten, festplattenbasierten Treiber (nohup/setsid), der einzelne Phasen oder Jobs selbstständig verknüpft, (4) spärliche, robuste Überwachung durch Zeitplanwechsel sowie (5) eine morgendliche Auslieferung: ein Bericht und die erste Nachricht, die auf den Bericht verweist. Es betont die GPU-Auslastung, die Token-Budgetkontrolle, kontrollierte Vergleiche und schließt irreversible oder externe Aktionen (kein Push, kein Löschen, keine Ausgaben) grundsätzlich aus. Das Skill wird durch den Satz des Benutzers „Bettzeit“ (oder Äquivalente) ausgelöst und nicht für kurze Abwesenheiten verwendet.

Funktioniert mit✓Claude Code~Codex CLI~Cursor

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

Dokumentation

/bedtime – Übernacht-Autonomie

Der Benutzer schläft ca. 7–8 h. Der zu vermeidende Fehler: Er wacht auf und nichts ist passiert. Zweiter Fehler: Rechenleistung wurde für etwas Sinnloses verbraucht. Dritter Fehler: Ein Sitzungs-Watcher, der mit der Sitzung um 02:00 Uhr gestorben ist und die GPUs im Leerlauf gelassen hat. Konzeption gegen alle drei Fehler, in dieser Reihenfolge.

1. Bestätigung (≤ 4 Zeilen, keine Fragen)

Der Benutzer geht. Fragen Sie nichts. Stellen Sie fest: was jetzt läuft, was Sie über Nacht tun werden (das ausgewählte Element + Fallback), wo der Morgenbericht sein wird. Wenn eine Entscheidung wirklich seine ist, nehmen Sie die Standardeinstellung, die die Rechenleistung beschäftigt und umkehrbar hält, nennen Sie die Annahme in der Bestätigung und erneut in "BRAUCHE DICH" am Morgen.

2. Bestandsaufnahme – Ressourcen und Kandidaten (≤ 10 min, günstige Checks)

Rechenleistung: nvidia-smi hier (wird mit anderen Benutzern geteilt – nehmen Sie nur freie Karten, schöne lange Jobs, niemals deren anfassen); entfernte Knoten aus der Projekt-Maschinenliste, falls vorhanden; Cluster-Warteschlangen, falls welche im Spiel sind. Notieren Sie, was frei vs. beschäftigt vs. bald fertig ist.
Claude-Budget: Überprüfen Sie das verbleibende Nutzungskontingent. Flotten und Workflows über Nacht können das wöchentliche Limit ausschöpfen; halten Sie sich an die Stopp-Schwelle des Benutzers. Bevorzugen Sie festplattenbasierte Treiber (kosten 0 Token während der Ausführung) gegenüber agentengesteuerten Schleifen.
Kandidaten, in Prioritätsreihenfolge – wählen Sie den höchsten, der in die freie Rechenleistung passt:
1. Vom Benutzer bereits in die Warteschlange gestellte Arbeit: das heutige Gespräch, die nächste Phase des Schlachtplans, die neueste Übergabedatei ("Nächste Sitzung sollte übernehmen"), WRAPUP_PLAN / TODO-Dateien.
2. Das Experiment, das die Unsicherheit für das aktuelle Ziel am meisten reduziert (normalerweise das Paper): die Ablation, die ein Gutachter fordern würde, die fehlende Baseline, die Seed-Wiederholung.
3. Evals/Metriken auf abgeschlossenen Checkpoints (Projektmetriken) – günstig, immer nützlich.
4. Analyse abgeschlossener Ergebnisse → Plots/Bericht im Ordner "reports" des Projekts.
5. Code-Hygiene – nur, wenn keine rechenintensive Arbeit existiert. Bevorzugen Sie GPU-Stunden-fressende Arbeit: Leerlauf-GPU-Stunden sind das, was über Nacht verschwendet wird, nicht Ihre Zeit. Überspringen Sie alles, das die Entscheidung des Benutzers benötigt, um nützlich zu sein, alles bereits als sinnlos Bekannte und alles, was ein Design berührt, das der Benutzer festgelegt hat. Kontrollierte Vergleiche: ein Faktor nach dem anderen, nichts, das die Vergleichbarkeit mit der Baseline bricht.

3. Start – mit der üblichen Hygiene, plus Haltbarkeit

Lösen Sie die Konfiguration auf und legen Sie fest, was eingeht (Zeilen, Filter, Split, jede Abweichung von der Baseline) im Log, nicht nur im Kopf. Testen Sie den genauen Befehl zuerst mit einem Rauchtest.
Entkoppelter Treiber auf der Festplatte, kein Agenten-Loop: nohup setsid <treiber>.sh schreibt state.txt / result.txt / Logs unter <run>/ (das final_now_driver.sh-Muster). Der Treiber verknüpft Phase → Phase und Job → nächsten Job selbst, mit Phasen-Fristen, die laut scheitern. Wenn diese Sitzung stirbt, bleiben die GPUs beschäftigt.
Überprüfen Sie die Wirkung, nicht die Aktion: Prozess lebt nach dem Start, erste Log-Zeilen, erste Wandb-Punkte; Wandb-URL in den Morgenbericht.
Maximal ein Eintrag pro freier GPU; lassen Sie eine Karte frei, wenn ein Mitbewohner-Job offensichtlich bald fertig ist und sie zurückhaben möchte – geteilte Maschine.

4. Überwachung – spärlich, robust

Bewaffnen Sie einen Monitor (Monitor-Tool / ScheduleWakeup ~30–60 min), dessen einzige Aufgabe ist: Tot? → Diagnose; Neustart, wenn die Ursache billig und verstanden ist (OOM → kleinere Batchsize, Pfad-Tippfehler); sonst Fallback zum nächsten Kandidaten. Fertig? → Der Treiber sollte den nächsten Job bereits gestartet haben; wenn nicht, starten Sie ihn. Leerlauf-GPU bei jedem Aufwachen = handeln, nicht notieren.
Erwartung vor Beobachtung bei jedem Aufwachen: Geben Sie den Verlust/Epoche/Schritt an, den Sie erwarten, vergleichen Sie, eine Zeile im Nacht-Log.
Kontext wird knapp → schreiben Sie JETZT eine Übergabedatei YYYY-MM-DD_overnight.md, einschließlich wie man jeden Treiber überprüft, dann weitermachen.
Pushs: keine über Nacht außer einem, wenn der gesamte Plan zusammengebrochen ist und nicht wiederhergestellt werden kann – der Benutzer liest ihn beim Aufwachen. Alles andere wartet auf den Bericht.

5. Morgen-Auslieferung

Eine Berichtsdatei YYYY-MM-DD_overnight.md: was gestartet wurde und warum (die Sprosse der Leiter), was fertig wurde, Zahlen im Vergleich zur Baseline, was gestorben ist und was gerettet wurde, was noch läuft mit absoluten ETAs, Links.
Erste Nachricht, wenn der Benutzer erscheint: /qu format, unaufgefordert, mit Verweis auf diese Datei. Alles, was Sie für ihn entschieden haben → ganz oben in "BRAUCHE DICH" mit der von Ihnen gewählten Standardeinstellung.

Niemals über Nacht

Keine irreversiblen oder nach außen gerichteten Aktionen: kein Push zu main, kein Force-Push, kein Löschen von Runs/Checkpoints/Daten, keine kostenpflichtigen Dienstausgaben über das genehmigte Maß hinaus, kein Wiederöffnen von festgelegten Entscheidungen, keine Änderungen an Paper-Behauptungen. Nichts, das sie braucht, um nützlich zu sein. Nichts an einem anderen Benutzerprozess, GPU oder Konfiguration.