<img src="banner.png" width="100%" alt="workflow-extract banner">

Workflow-Extract — aus Chatverläufen und Fremd-Automationen Automatisierungen bauen

Zweck

Manche Abläufe gehören nicht in einen Skill, den man bei Bedarf lädt, sondern in eine Automatisierung, die von allein läuft: nächtliche Checks, rotierende Projekt-Prüfungen, periodische Pflege-Läufe. Dieser Skill extrahiert solche Workflows aus zwei Quellenarten — Chatverläufen (ein Ablauf wurde interaktiv entwickelt und soll künftig unbeaufsichtigt laufen) und bestehenden Automations-Prompts anderer Systeme (z. B. Codex-Automations, Scheduled Tasks, n8n-Flows) — und macht daraus user-neutrale, robuste Automatisierungs-Prompts oder -Skills.

Der Unterschied zum interaktiven Ablauf: Eine Automatisierung hat niemanden, der korrigiert. Alles, was in der Session der User abgefangen hat, muss die Automatisierung selbst abfangen. Genau dafür gibt es die Bausteine in automation-bausteine.md.

Ablauf

1. Quelle und Zielform klären

| Quelle | typischer Fall | | --- | --- | | Aktuelle Session / Transkript | Ablauf wurde interaktiv entwickelt, soll periodisch weiterlaufen | | Fremd-Automation (Prompt-Datei, Cron-Task, n8n-Flow) | Portierung/Abstraktion auf ein anderes System oder in die Bibliothek |

Zielformen (eine oder mehrere):

• Automations-Prompt: eigenständiger, user-neutraler Prompt-Text, einsetzbar in jedem

Scheduler (Codex-Automations, Claude /schedule/Cron, Scheduled Task, n8n).

• Workflow-Skill: Skill in der Bibliothek, der den Ablauf beschreibt und vom

Automations-Prompt nur noch aufgerufen/parametrisiert wird (bevorzugt, wenn derselbe Ablauf für mehrere Pipelines/Systeme gelten soll — eine Quelle der Wahrheit).

• Command: dünner Slash-Command für manuelle Auslösung desselben Ablaufs.

2. Workflow-Kern extrahieren

Aus der Quelle herausarbeiten:

• Kernaufgabe: Was wird geprüft/gepflegt/erzeugt? (ein Satz)
• Auswahllogik: Worauf wird die Aufgabe angewandt — festes Ziel oder Rotation über eine

Menge (ein Projekt pro Lauf)?

• Vorbedingungen: Was muss vor der Arbeit gelesen/geprüft werden (Root-Dokumente,

Registries, Locks)?

• Dokumentationspflichten: Wohin werden Ergebnis, Log, Folgeaufgaben geschrieben?
• Abbruchpfade: Wann endet der Lauf read-only („nichts zu tun" ist ein gültiges Ergebnis)?

Bei Chatverläufen zusätzlich die Korrekturschleifen auswerten (siehe ../skill-extractor/transcript-quellen.md): Jede User-Korrektur ist ein Kandidat für einen Guard, den die Automatisierung künftig selbst braucht.

3. Neutralisieren

Nach den Regeln in ../skill-extractor/neutralisierung.md: Mechanik von Konfiguration trennen, Pfade/Hosts/Projektnamen in einen Konfigurationsblock ziehen. Automations-Prompts brauchen den Konfigurationsblock besonders dringend, weil sie wörtlich in Scheduler kopiert werden — konkrete Werte gehören an EINE Stelle am Prompt-Anfang.

4. Automations-Bausteine ergänzen

Den extrahierten Kern gegen die Checkliste in automation-bausteine.md halten und fehlende Bausteine ergänzen — insbesondere Rotations-Auswahl mit Check-Registry, Idempotenz, Log-Hygiene, Lock-Respekt, Read-only-Exit und Abschlussbericht. Ein Workflow ohne diese Bausteine funktioniert im Test und degeneriert im Dauerbetrieb (Doppelprüfungen, wachsende Logs, Kollisionen mit parallelen Agenten).

5. Takt und Budget setzen

• Frequenz an Änderungsrate koppeln: Ein Check muss nicht öfter laufen, als sich sein

Gegenstand ändert. Erfahrungswert aus gewachsenen Automations-Beständen: Viele anfangs stündliche Checks wurden auf täglich/wöchentlich reduziert — mit Rotations-Auswahl deckt auch ein seltener Takt die ganze Pipeline ab.

• Nachtfenster für Schweres, kurze Read-only-Checks dürfen häufiger.
• Kostenbewusstsein: Jeder Lauf kostet Tokens/Compute; ein Lauf, der meist read-only

endet, soll das früh feststellen (Registry lesen VOR teurer Analyse).

6. Testen und einsetzen

1. Trockenlauf: Den fertigen Prompt einmal interaktiv ausführen (als wäre man der

Scheduler) und prüfen: Endet er sauber? Schreibt er Registry/Log korrekt? Bleibt er im Scope?

1. Grenzfall-Test: Einen Lauf simulieren, bei dem nichts zu tun ist — er muss read-only

mit kurzem Logeintrag enden, nicht „Arbeit erfinden".

1. Einsetzen: In den Ziel-Scheduler eintragen; bei Skill-Form zusätzlich in Bibliothek

ablegen und deployen.

1. Fehlerpfad beobachten: Nach den ersten 2–3 echten Läufen Log/Registry kontrollieren —

Automatisierungen scheitern am häufigsten an Pfad-Drift (Ziel wurde verschoben) und an wachsenden Logdateien.

Fleet-Audit-Modus: eine laufende Automations-Flotte prüfen

Für „prüfe meine Automatisierungen": nicht extrahieren, sondern den BESTAND betreiben helfen. Über die Automations-Quelle des Zielsystems (Prompt-/Config-Dateien, Schedules, Run-Logs/Memories) systematisch prüfen:

1. Silent-Failure/No-op-Erkennung: Läuft die Automation, tut aber nichts mehr?

(Run-Memories/Logs der letzten Läufe lesen: nur noch Leerläufe, Fehler, tote Pfade?)

1. Redundanz + Ertrag: Überschneiden sich Automationen im Scope? Steht der Ertrag

(Output, behobene Befunde) noch im Verhältnis zum Verbrauch (Tokens, Läufe)?

1. Drift: Passen Prompt-Pfade, Konventionen und Schedules noch zur Realität?

(Ziele verschoben, Policies geändert, Takt zu hoch für die Änderungsrate.)

1. Katalog-Abgleich: Fehlt eine Automation, die es geben sollte (Lücken im

Muster-Raster)? Vorschläge nur freigabe-gegated (Baustein 12), nie selbst scharf schalten.

1. Befund-Bericht: pro Automation eine Zeile (behalten | anpassen | pausieren |

zusammenlegen | löschen) + Begründung; Änderungen selbst nur nach Freigabe.

Bulk-Modus: Automations-Bestände oder viele Transkripte sichten

Für „prüfe alle Automationen von System X auf abstrahierbare Workflows" oder „extrahiere Automatisierungs-Kandidaten aus alten Chatverläufen":

1. Datenreduktion wie im skill-extractor (Map-Reduce über Subagenten,

swarm-operations-Muster): Pro Bündel ein Subagent, der je Quelle meldet: Kernaufgabe | Muster (z. B. Rotation-Check, Health-Check, Ideen-Mining) | einzigartige Elemente | user-neutral abstrahierbar? | abgedeckt durch existierenden Skill?

1. Muster vor Einzelstücken: Wenn viele Quellen dasselbe Gerüst teilen (z. B. 40

Rotations-Checks), wird das GERÜST ein Skill und die Einzelfälle werden Parametrisierungen — nicht 40 Einzel-Skills.

1. Dedup gegen die bestehende Skill-/Command-Landschaft, dann nummerierte

Kandidatenliste an den User vor dem Massenbau.

Beispiel

text
User: „Wir haben heute die Zitationsprüfung für ein Paper durchgespielt —
das soll ab jetzt wöchentlich über alle Paper laufen."

1. Zielform: Automations-Prompt für den Scheduler + Verweis auf rotation-check.
2. Kern: Zitate eines Papers gegen Originalquellen prüfen (Web/Datenbank),
   Korrekturen einpflegen, bei Änderungen Folgeaufgabe „Neu-Upload" in TODO.md.
3. Neutralisieren: Pipeline-Root, Registry-/Log-Pfade → Konfigurationsblock.
4. Bausteine ergänzen: Rotations-Auswahl (ein Paper pro Lauf), Registry lesen VOR
   Auswahl, Read-only-Exit („alle Quellen ok"), Log-Hygiene, Abschlussbericht.
5. Takt: wöchentlich reicht (Papers ändern sich langsam); Trockenlauf + Leerlauf-Test,
   dann in den Scheduler.

Red Flags

| Gedanke | Realität | | --- | --- | | „Der Ablauf lief in der Session, also läuft er auch als Automation" | Ohne User fehlen alle Korrektive — Bausteine-Checkliste ist Pflicht. | | „Stündlich schadet nicht" | Doch: Tokens, Log-Wachstum, Kollisionsrisiko. Takt an Änderungsrate koppeln. | | „Ich baue für jede Variante eine eigene Automation" | Gemeinsames Gerüst als Skill, Varianten als Parameter. | | „Nichts gefunden — dann suche ich mir eben andere Arbeit" | Read-only-Exit mit Logeintrag ist das korrekte Ergebnis eines Leerlaufs. |

Verwandte Skills

• skill-extractor — gleiche Extraktion, Ziel ist ein abrufbarer Skill; teilt

Neutralisierung und Transcript-Quellen (dort dokumentiert).

• rotation-check — das Standard-Gerüst für rotierende Pipeline-Checks (häufigster

Automations-Typ); als Baustein referenzieren statt neu erfinden.

• swarm-operations — Schwarm-Muster für Bulk-Sichtung.

Changelog

1.1.0 (2026-07-03)

• Fleet-Audit-Modus (laufende Automations-Flotte prüfen: Silent-Failures, Redundanz,

Drift, Lücken) — integriert statt als eigener Skill (Dedup-Entscheid).

• Drei neue Bausteine in automation-bausteine.md: Freigabe-Gate über Sentinel-Dateien (12),

Gestaffelte Eskalation mit Handoff-Artefakt (13), Melde-Disziplin für Monitore (14).

1.0.0 (2026-07-03)

• Initiale Version. Entstanden aus der Abstraktion des Codex-Automations-Bestands

(77 Automationen, dominantes Rotations-Check-Muster) in user-neutrale Bausteine.