Workflow für autonome Sitzungen

Was macht Workflow für autonome Sitzungen?

Eine 5-phasige, wiederholbare Struktur für autonome Agentensitzungen, die doppelte Arbeit verhindert, dauerhafte Erkenntnisspeicherung gewährleistet und den Output auf bedeutungsvolle ausgelieferte Artefakte statt auf bloße Aktivität ausrichtet.

Bewährt in tausenden autonomen Sitzungen auf der gptme-Architektur. Die Phasen sind laufzeitunabhängig – passen Sie die spezifischen Werkzeuge an Ihren Stack an, während Sie die Phasenstruktur intakt lassen.

Wann verwenden

• Zu Beginn jeder autonomen Agentensitzung (kein menschlicher Dirigent)
• Wenn der Agent seine Arbeit aus einem Backlog oder einer Warteschlange selbst auswählen muss
• Wenn Sitzungen unbeaufsichtigt laufen und dauerhafte Artefakte erzeugen müssen

Wann nicht verwenden

• Interaktive Sitzungen, bei denen ein Mensch bei jedem Schritt die nächste Eingabe vorgibt – einfach antworten
• Einmalige Tool-Aufrufe mit festem Ziel (keine Auswahl nötig)
• Unteragent-Aufrufe, die von einer übergeordneten Aufgabe erzeugt wurden (die übergeordnete Aufgabe hat die Arbeit bereits ausgewählt)

Die 5 Phasen

Phase 1: Kontext laden

Laden Sie die Identität des Agenten, den Sitzungszustand und das aktuelle Weltmodell.

# Identitätsdateien lesen – Persona, Ziele, Betriebsbeschränkungen
# (an Ihren Stack anpassen: CLAUDE.md, AGENTS.md, System-Prompt, usw.)

# Dynamischen Kontext lesen – aktuelles Journal, Aufgabenwarteschlange, Git-Status, Benachrichtigungen
# (anpassen: ein Kontextskript, konfigurationsgesteuerte Includes oder Prompt-Injection)

# Offene Enden aus früheren Sitzungen bewerten:
#   - Veraltete Ansprüche, die abgeschlossen oder aufgegeben werden sollten
#   - Ausstehende Antworten auf Issues/PRs, deren Schließung zugesagt wurde
#   - In Arbeit befindliche Branches oder offene Worktrees

Kernfrage: "Was habe ich unerledigt gelassen und was hat sich geändert, während ich offline war?"

Wenn ein offenes Ende in <5 Minuten auflösbar ist, erledigen Sie es hier. Ansonsten notieren Sie es und fahren fort.

Phase 2: Aufgabenauswahl

Probieren Sie die Stufen der Reihe nach durch, bis Sie umsetzbare Arbeit finden. Die Stufen verhindern, dass der Agent Beschäftigungstherapie erfindet, wenn echte Aufgaben existieren, und verhindern Verhungern, wenn alle Aufgaben blockiert sind.

Stufe 1 – Aktive Aufgaben: bereits in Arbeit befindliche; höchste Priorität
Stufe 2 – Backlog-Schnelle Erfolge: abhängigkeitsfreie Elemente, die in dieser Sitzung abgeschlossen werden können
Stufe 3 – Selbstverbesserung: wenn alle Aufgaben extern blockiert sind
  ├─ Ideen-Backlog (die höchstbewertete Idee voranbringen)
  ├─ Selbstüberprüfung / Audit (ein echtes Problem finden und beheben)
  ├─ Verbesserung interner Werkzeuge
  ├─ Dokumentation (nur veraltete Dokumente)
  ├─ Codequalität (Typ-Prüfung, Tests, Lint)
  └─ Lektionsqualität (schädliche oder veraltete Lektionen reparieren)

Monotonie-Schutz: Wenn dieselbe Kategorie in den letzten N Sitzungen dominiert hat, überspringen Sie sie, selbst wenn sie wie die beste Wahl aussieht. Kategoriediversität ist ein Treiber zum Erlernen neuer Fehlermodi.

Wenn alles trocken ist: Wenn alle Aufgaben der Stufen 1/2 extern blockiert sind und die Kanäle von Stufe 3 gesättigt sind (Tageslimits erreicht), schreiben Sie ein kurzes Zurückhaltungsjournal, das dokumentiert, was Sie geprüft und bewusst übersprungen haben. Ein begründeter NOOP ist besser als erfundene Arbeit.

Phase 3: Anspruch

Vor der Ausführung einen exklusiven Koordinationsanspruch erwerben. Dies verhindert, dass zwei gleichzeitige Sitzungen dieselbe Arbeit ausführen, denselben PR-Thread überfluten oder dieselbe Datei schreiben.

# Generisches Koordinationsmuster – das Werkzeug an Ihren Stack anpassen:
claim_key="task:<task-id>"          # für aufgabenbasierte Arbeit
claim_key="github:<owner>/<repo>#<num>"  # für aufgabenbasierte Arbeit
claim_key="content:<slug>:<date>"   # für Inhalte/Artefakterstellung

# Anspruch erwerben (Beispiel mit einem Koordinations-CLI):
koordination work-claim "<session-id>" "$claim_key" --ttl 60
# BEANSPRUCHT → fortfahren
# ABGELEHNT → eine andere Sitzung ist bereits dran; nächsten Kandidaten wählen

Regel: Vor dem Anspruch benachrichtigen: Jede Aktion, die für andere sichtbar ist (Kommentar posten, Nachricht senden, PR eröffnen), muss zuerst durch einen Anspruch abgesichert sein. Soziale Aktionen ohne Ansprüche laufen zusammen und spammen – ein Anspruch-dann-Posten-Muster verhindert Überflutung.

Bei Abschluss: koordination work-complete "<session-id>" "$claim_key" Bei Richtungswechsel/Fehler: koordination work-abandon "<session-id>" "$claim_key"

Phase 4: Ausführen

Echte Arbeit erledigen. Die entscheidende Disziplin ist Ausliefern, nicht Perfektionieren.

- Früh und oft committen (kleine, gut beschriebene Commits)
- Vor dem Commit Tests ausführen (Fehler abfangen, bevor CI es tut)
- Konventionelle Commits verwenden: feat/fix/docs/refactor/chore
- Vor Sitzungsende zu origin pushen
- Bei >10 Minuten Feststecken weitermachen – Budget nicht in Kaninchenlöchern versenken
- Keine nicht angeforderten Features oder Scope-Creep hinzufügen

50-Minuten-Budget: Die meisten autonomen Sitzungen sollten sinnvolle Arbeit innerhalb von 50 Minuten abschließen. Wenn die Aufgabe größer ist, liefern Sie ein inkrementelles Stück aus und erstellen Sie eine Folgeaufgabe für den Rest.

Phase 5: Persistieren

Die am meisten unterschätzte Phase. Alles, was in den Phasen 1–4 getan wurde, verflüchtigt sich zwischen Sitzungen, wenn es nicht dauerhaft festgehalten wird.

# 1. Den Journaleintrag schreiben (sitzungsspezifische Datei, nur anhängen)
cat > journal/$(date +%Y-%m-%d)/session-<HASH>.md << 'EOF'
# Sitzung <HASH>
**Datum**: YYYY-MM-TT
**Ergebnis**: produktiv|blockiert|noop – ein Satz
**Kategorie**: code|forschung|strategisch|wartung|...

## Warum diese Arbeit
[Was hierher geführt hat]

## Was ich gemacht habe
[Konkrete Änderungen mit Commit-/PR-Links]

## Verifizierung
- [Tests erfolgreich? CI grün?]

## Persistierte Erkenntnisse
- Aufgabenstatus: <task> → erledigt/wartend
- Neue Lektionen: [falls vorhanden]
- "Keine dauerhafte Rückmeldung in dieser Sitzung" – wenn wirklich nichts hinzuzufügen ist

## Als Nächstes
[Nächster klarer Schritt oder blockierender Faktor]
EOF

# 2. Aufgabenstatus aktualisieren
task bearbeiten <task-id> --set status erledigt   # oder wartend, wenn blockiert

# 3. Wenn ein wiederkehrendes Fehlermuster entdeckt wurde, eine Lektion/Regel schreiben
#    (stichwortbezogene Kontextdatei, die zu Beginn der nächsten Sitzung eingefügt wird)

# 4. Alle Commits pushen
git push origin master

Regel: Persistieren vor Anwenden: Wenn Sie etwas Nützliches entdeckt haben, schreiben Sie die Lektion, BEVOR Sie sie auf die aktuelle Arbeit anwenden. Sobald der Fix drin ist, fühlt sich der Fehlermodus gelöst an und die Lektion wird übersprungen. Das Journal hält fest, was passiert ist; die Lektion hält fest, wann man sie wiedererkennt.

Installation

Claude Code

Kopieren Sie dieses Skill-Verzeichnis in den Skill-Ordner Ihres Agenten:

cp -R skills/autonomous-session-workflow ~/.claude/skills/autonomous-session-workflow

Dann mit /autonomous-session-workflow aufrufen, um die 5-Phasen-Checkliste in den Kontext zu laden.

Manuell / jede Laufzeit

Kopieren Sie SKILL.md in den Kontextpfad Ihres Agenten und laden Sie es zu Sitzungsbeginn. Die Phasen sind einfaches Markdown – binden Sie die gesamte Datei ein oder extrahieren Sie die für Ihren Stack relevanten Abschnitte.

Häufige Rechtfertigungen

Rechtfertigung	Realität
"Ich überspringe den Anspruch – ich bin gerade die einzige laufende Sitzung"	Sie können andere startende Sitzungen nicht sehen. Gleichzeitiges Spawnen ist auf Produktionslaufzeiten der Standard. Der Anspruch ist das Tor, nicht die Beobachtung.
"Ich schreibe das Journal, nachdem ich die nächste Aufgabe beendet habe"	Sitzungen werden unterbrochen. Das Journal wird übersprungen. Schreiben Sie es vor dem Pushen, nicht nach "noch einer Sache."
"Diese Aufgabe ist fast fertig – ich überspringe Phase 5 und committe einfach"	Lernen verstärkt sich nur, wenn es persistiert wird. Die Sitzung, die die Schleife "fast" geschlossen hat, ist die Sitzung, deren Erkenntnis bis zum nächsten Lauf verschwindet.
"Meine Auswahl ist offensichtlich – ich muss nicht die Stufen durchgehen"	Auswahl, die die Stufen überspringt, ist die Hauptquelle für redundante Arbeit und doppelte PRs. Die Stufen existieren, weil "offensichtlich" oft nicht das ist, was tatsächlich getan werden muss.
"Die Lektion ist zu spezifisch, um wiederverwendbar zu sein"	Spezifische Lektionen (genaue Fehlermeldung, genauer Befehl, genauer Fehlermodus) sind die wertvollsten – sie lösen genau dann aus, wenn sie gebraucht werden.
"Ein begründeter NOOP fühlt sich wie ein Fehlschlag an"	Ist er nicht. Ein Füll-Commit, um das NOOP-Label zu vermeiden, verbraucht Kontingent, nährt Konvergenz-Chaos und verbirgt den Engpass. Ein Zurückhaltungsjournal IST das Arbeitsergebnis.

Warnsignale

• Ausführung vor dem Beanspruchen (Konvergenzrisiko)
• Sitzung endet ohne Journal und ohne aktualisierten Aufgabenstatus
• "In einem Moment committen" – wenn Sie vor Sitzungsende nicht gepusht haben, haben Sie nicht ausgeliefert
• Drei aufeinanderfolgende Sitzungen in derselben Kategorie ohne erzwungene Diversitätspause
• "Ich werde mich erinnern" – werden Sie nicht; schreiben Sie die Lektion jetzt

Verifizierung

Eine gut geführte Sitzung erfüllt vor dem Schließen alle folgenden Kriterien:

• Vor dem Handeln beansprucht (oder begründet, warum kein Anspruch nötig war)
• Sinnvolle Arbeit committet und gepusht
• Tests bestanden (oder ein bekannter Fehler mit Grund dokumentiert)
• Journaleintrag geschrieben mit ausgefülltem Abschnitt Persistierte Erkenntnisse
• Aufgabenstatus aktualisiert (aktiv → erledigt, aktiv → wartend, usw.)
• Anspruch abgeschlossen oder aufgegeben (nicht als verwaistes Lease hinterlassen)

An Ihren Stack anpassen

gptme-Konzept	Ihr Äquivalent
gptodo	jeder Aufgabenmanager mit Zustandsübergängen
koordination work-claim	eine Lock-Datei, Redis SETNX oder ein GitHub-Kommentar-Gate
lessons/<category>/name.md	jede stichwortbezogene Kontextdatei, die zu Sitzungsbeginn eingefügt wird
journal/<date>/session-<hash>.md	jedes nur-anhängende Sitzungslog
cascade-selector.py	Ihre Aufgabenauswahl-Heuristik oder Ihr Scheduler

Das Muster ist der Wert, nicht die spezifischen Werkzeuge.

Verwandte Skills

• self-push (in diesem Katalog) – Trägheits-Check vor dem Ausliefern eines Outputs
• pre-landing-review (in diesem Katalog) – Tor vor dem Mergen wesentlicher Änderungen
• multi-lens-review (in diesem Katalog) – Strukturierte PR-Überprüfung aus mehreren Blickwinkeln
• five-element-spec (in diesem Katalog) – Bereichsdefinition vor Arbeitsbeginn