Zweck
Wer eine Pipeline mit vielen Projekten periodisch prüfen will (Quellen, Stil, Gesundheit,
Sicherheit, Übersetzungen, …), steht vor einem Verteilungsproblem: Alle Projekte pro Lauf zu
prüfen ist zu teuer; ohne Gedächtnis prüft jeder Lauf zufällig dasselbe. Das Rotations-Muster
löst beides: genau ein Ziel pro Lauf, Auswahl nach „am längsten ungeprüft", Registry als
Gedächtnis. So deckt auch ein seltener Takt (täglich/wöchentlich) über Wochen die ganze
Pipeline ab — nachweisbar und ohne Doppelarbeit.
Bewährt als Rückgrat eines gewachsenen Bestands produktiver Automationen über mehrere
Projekt-Pipelines hinweg.
Bausteine
1. Zwei Dateien pro Pipeline (einmalig anlegen)
| Datei |
Inhalt |
Charakter |
CHECKED-REGISTRY.md |
eine Kompaktzeile pro Check: Ziel, Datum, Checktyp, Ergebnis, nächster Schritt |
Zustandsübersicht — wird VOR jeder Zielauswahl gelesen |
CHECKS-LOG.txt |
kurzer Verlaufseintrag pro Lauf mit Details/Evidenz |
Journal — append-only |
Beide liegen im Pipeline-Root (nicht im Einzelprojekt), damit ein Lauf sie mit einem Read
erfassen kann. Registry-Zeilenformat:
| <ziel> | <YYYY-MM-DD> | <checktyp> | <ok|befund|übersprungen> | <nächster schritt> |
2. Auswahlregel
- Registry und Log lesen (Pflicht, VOR der Auswahl — sonst Doppelprüfung).
- Kandidaten: Ziele, die für DIESEN Checktyp noch nie oder am längsten nicht geprüft wurden.
- Ausweichen, wenn das Ziel kürzlich von einem eng verwandten Check angefasst wurde
(z. B. Zitations-Check direkt nach Quellencheck bringt nichts) oder gerade gesperrt/in
Bearbeitung ist (Locks respektieren).
Geschwister-Cooldown: Laufen mehrere verwandte Checks über dieselbe Zielmenge
(z. B. Entwicklung, Bugsuche und Review derselben Pipeline), eine Karenzzeit vereinbaren
(Erfahrungswert: ~24 h), in der ein von einem Geschwister-Check bearbeitetes Ziel nicht
erneut gewählt wird — verhindert Kollisionen und widersprüchliche Parallel-Änderungen.
- Vorziehen außer der Reihe nur mit gutem Grund (z. B. große Überarbeitung seit letztem
Check) — den Grund im Log nennen.
3. Check durchführen — mit Read-only-Exit
Den eigentlichen Check (frei definierbar: Quellencheck, Style-Check, Security-Audit, …)
auf das EINE gewählte Ziel anwenden. Zwei gültige Ausgänge:
- Befund: beheben was in den Scope passt; Größeres als Folgeaufgabe in die projektlokale
TODO/AUFGABEN-Datei eintragen (der Check muss nicht alles selbst lösen).
- Nichts zu tun: kurz dokumentieren und enden. Ein Leerlauf ist ein Ergebnis, kein
Scheitern — keinesfalls den Scope ausweiten, um „etwas gefunden zu haben".
4. Dokumentieren
- Registry-Zeile ergänzen (kompakt), Log-Eintrag schreiben (Details/Evidenz).
- Log-Hygiene: Werden Registry/Log unübersichtlich (Erfahrungswert: mehrere hundert
Zeilen), alten Stand nach
_archiv/ verschieben, frische Datei anlegen, im Kopf auf den
Vorgänger verweisen (Pfad + Datum).
- Pfad-Drift: Zeigt ein erwarteter Pfad ins Leere (Ziel verschoben/umbenannt), NICHT neu
anlegen — über die maßgebliche Statusdatei/Registry der Pipeline korrigieren und den
Fehlpfad in einem Failure-Log festhalten.
5. Takt
Frequenz an die Änderungsrate des Geprüften koppeln: Rotations-Checks über stabile Bestände
laufen gut wöchentlich (ein Ziel pro Lauf ≈ ganze Pipeline pro Quartal bei ~12 Zielen);
schnelllebige Checks (z. B. auf aktive Arbeit) täglich. Praxiserfahrung: anfangs stündliche
Checks wurden fast alle auf täglich/wöchentlich reduziert — die Abdeckung blieb, die Kosten
fielen.
Prompt-Vorlage (für Scheduler/Automation)
VORBEREITUNG: Lies <PIPELINE_ROOT>/<POLICY-DOKUMENTE> sowie <REGISTRY> und <LOG>.
AUFGABE: Wähle genau ein Ziel aus <ZIELMENGE>. Bevorzuge Ziele, die für den Check
"<CHECKTYP>" noch nie oder am längsten nicht geprüft wurden. Wurde ein Ziel kürzlich
von diesem oder einem eng verwandten Check geprüft oder ist es gesperrt: ausweichen
oder read-only mit Logeintrag enden.
CHECK: <konkrete Prüf-/Pflegeaufgabe und was bei Befund zu tun ist; Folgearbeiten in
die projektlokale TODO-Datei>.
Wenn keine Arbeit anfällt: kurz dokumentieren, Lauf beenden.
DOKUMENTATION: Registry-Zeile in <REGISTRY> (Ziel, Datum, Checktyp, Ergebnis, nächster
Schritt) + Verlaufseintrag in <LOG>. Bei Überlänge: alten Stand nach _archiv/ und
frische Datei mit Verweis.
ABSCHLUSS: Kurzbericht (Ziel | getan | Ergebnis | Folgeaufgaben).
Red Flags
| Gedanke |
Realität |
| „Ich wähle einfach ein interessantes Projekt" |
Auswahl nur über die Registry — sonst Lieblingsprojekt-Bias und blinde Flecken. |
| „Registry lese ich nach dem Check" |
Vorher. Sie ist das Auswahlkriterium, nicht nur das Protokoll. |
| „Mehrere Ziele pro Lauf schaffen mehr" |
Ein Ziel hält Läufe kurz, idempotent und abbrechbar; Menge kommt über die Rotation. |
| „Der Leerlauf war umsonst" |
Ein dokumentierter Leerlauf aktualisiert das Gedächtnis — das ist der halbe Wert des Systems. |
Verwandte Skills
workflow-extract — baut aus Sessions/Fremd-Automationen Automatisierungen; nutzt dieses
Gerüst als Standard-Baustein.pipeline-optimizer — für den strukturellen Umbau einer Pipeline (Rotation-Check pflegt,
Optimizer renoviert).
Changelog
1.1.0 (2026-07-03)
- Geschwister-Cooldown als Auswahlregel ergänzt (Anti-Kollision zwischen verwandten
Checks über dieselbe Zielmenge; Befund aus der Vollklassifikation des Automations-Bestands).
1.0.0 (2026-07-03)
- Initiale Version. Abstrahiert aus dem Codex-Automations-Bestand (Rotations-Muster in
~40 von 77 Automationen: Research-/Software-/Roblox-Checks mit CHECKED-REGISTRY/CHECKS-LOG).
1---2name: rotation-check3description: Standard-Gerüst für rotierende Pipeline-Checks: Pro Lauf genau ein Ziel aus einer Menge (Projekte, Ordner, Repos) wählen — bevorzugt das am längsten ungeprüfte —, den Check durchführen, Ergebnis in einer Check-Registry und einem Verlaufslog festhalten. Nutze diesen Skill, wenn ein wiederkehrender Check über viele Projekte verteilt werden soll („prüfe regelmäßig alle X auf Y"), wenn eine Automatisierung Doppelprüfungen vermeiden muss, wenn eine Check-Registry/CHECKS-LOG-Struktur angelegt oder benutzt wird, oder wenn eine periodische Qualitätsrunde (Quellencheck, Style-Check, Health-Check, Audit) über eine Pipeline fair verteilt werden soll.4---56<img src="banner.png" width="100%" alt="rotation-check banner">7# Rotation-Check — ein Ziel pro Lauf, faire Abdeckung, Gedächtnis89## Zweck1011Wer eine Pipeline mit vielen Projekten periodisch prüfen will (Quellen, Stil, Gesundheit,12Sicherheit, Übersetzungen, …), steht vor einem Verteilungsproblem: Alle Projekte pro Lauf zu13prüfen ist zu teuer; ohne Gedächtnis prüft jeder Lauf zufällig dasselbe. Das Rotations-Muster14löst beides: **genau ein Ziel pro Lauf, Auswahl nach „am längsten ungeprüft", Registry als15Gedächtnis.** So deckt auch ein seltener Takt (täglich/wöchentlich) über Wochen die ganze16Pipeline ab — nachweisbar und ohne Doppelarbeit.1718Bewährt als Rückgrat eines gewachsenen Bestands produktiver Automationen über mehrere19Projekt-Pipelines hinweg.2021## Bausteine2223### 1. Zwei Dateien pro Pipeline (einmalig anlegen)2425| Datei | Inhalt | Charakter |26| --- | --- | --- |27| `CHECKED-REGISTRY.md` | eine Kompaktzeile pro Check: Ziel, Datum, Checktyp, Ergebnis, nächster Schritt | Zustandsübersicht — wird VOR jeder Zielauswahl gelesen |28| `CHECKS-LOG.txt` | kurzer Verlaufseintrag pro Lauf mit Details/Evidenz | Journal — append-only |2930Beide liegen im Pipeline-Root (nicht im Einzelprojekt), damit ein Lauf sie mit einem Read31erfassen kann. Registry-Zeilenformat:3233```text34| <ziel> | <YYYY-MM-DD> | <checktyp> | <ok|befund|übersprungen> | <nächster schritt> |35```3637### 2. Auswahlregel38391. Registry und Log lesen (Pflicht, VOR der Auswahl — sonst Doppelprüfung).402. Kandidaten: Ziele, die für DIESEN Checktyp noch nie oder am längsten nicht geprüft wurden.413. Ausweichen, wenn das Ziel kürzlich von einem **eng verwandten** Check angefasst wurde42 (z. B. Zitations-Check direkt nach Quellencheck bringt nichts) oder gerade gesperrt/in43 Bearbeitung ist (Locks respektieren).44 **Geschwister-Cooldown:** Laufen mehrere verwandte Checks über dieselbe Zielmenge45 (z. B. Entwicklung, Bugsuche und Review derselben Pipeline), eine Karenzzeit vereinbaren46 (Erfahrungswert: ~24 h), in der ein von einem Geschwister-Check bearbeitetes Ziel nicht47 erneut gewählt wird — verhindert Kollisionen und widersprüchliche Parallel-Änderungen.484. Vorziehen außer der Reihe nur mit gutem Grund (z. B. große Überarbeitung seit letztem49 Check) — den Grund im Log nennen.5051### 3. Check durchführen — mit Read-only-Exit5253Den eigentlichen Check (frei definierbar: Quellencheck, Style-Check, Security-Audit, …)54auf das EINE gewählte Ziel anwenden. Zwei gültige Ausgänge:5556- **Befund:** beheben was in den Scope passt; Größeres als Folgeaufgabe in die projektlokale57 TODO/AUFGABEN-Datei eintragen (der Check muss nicht alles selbst lösen).58- **Nichts zu tun:** kurz dokumentieren und enden. Ein Leerlauf ist ein Ergebnis, kein59 Scheitern — keinesfalls den Scope ausweiten, um „etwas gefunden zu haben".6061### 4. Dokumentieren6263- Registry-Zeile ergänzen (kompakt), Log-Eintrag schreiben (Details/Evidenz).64- **Log-Hygiene:** Werden Registry/Log unübersichtlich (Erfahrungswert: mehrere hundert65 Zeilen), alten Stand nach `_archiv/` verschieben, frische Datei anlegen, im Kopf auf den66 Vorgänger verweisen (Pfad + Datum).67- **Pfad-Drift:** Zeigt ein erwarteter Pfad ins Leere (Ziel verschoben/umbenannt), NICHT neu68 anlegen — über die maßgebliche Statusdatei/Registry der Pipeline korrigieren und den69 Fehlpfad in einem Failure-Log festhalten.7071### 5. Takt7273Frequenz an die Änderungsrate des Geprüften koppeln: Rotations-Checks über stabile Bestände74laufen gut wöchentlich (ein Ziel pro Lauf ≈ ganze Pipeline pro Quartal bei ~12 Zielen);75schnelllebige Checks (z. B. auf aktive Arbeit) täglich. Praxiserfahrung: anfangs stündliche76Checks wurden fast alle auf täglich/wöchentlich reduziert — die Abdeckung blieb, die Kosten77fielen.7879## Prompt-Vorlage (für Scheduler/Automation)8081```text82VORBEREITUNG: Lies <PIPELINE_ROOT>/<POLICY-DOKUMENTE> sowie <REGISTRY> und <LOG>.8384AUFGABE: Wähle genau ein Ziel aus <ZIELMENGE>. Bevorzuge Ziele, die für den Check85"<CHECKTYP>" noch nie oder am längsten nicht geprüft wurden. Wurde ein Ziel kürzlich86von diesem oder einem eng verwandten Check geprüft oder ist es gesperrt: ausweichen87oder read-only mit Logeintrag enden.8889CHECK: <konkrete Prüf-/Pflegeaufgabe und was bei Befund zu tun ist; Folgearbeiten in90die projektlokale TODO-Datei>.9192Wenn keine Arbeit anfällt: kurz dokumentieren, Lauf beenden.9394DOKUMENTATION: Registry-Zeile in <REGISTRY> (Ziel, Datum, Checktyp, Ergebnis, nächster95Schritt) + Verlaufseintrag in <LOG>. Bei Überlänge: alten Stand nach _archiv/ und96frische Datei mit Verweis.9798ABSCHLUSS: Kurzbericht (Ziel | getan | Ergebnis | Folgeaufgaben).99```100101## Red Flags102103| Gedanke | Realität |104| --- | --- |105| „Ich wähle einfach ein interessantes Projekt" | Auswahl nur über die Registry — sonst Lieblingsprojekt-Bias und blinde Flecken. |106| „Registry lese ich nach dem Check" | Vorher. Sie ist das Auswahlkriterium, nicht nur das Protokoll. |107| „Mehrere Ziele pro Lauf schaffen mehr" | Ein Ziel hält Läufe kurz, idempotent und abbrechbar; Menge kommt über die Rotation. |108| „Der Leerlauf war umsonst" | Ein dokumentierter Leerlauf aktualisiert das Gedächtnis — das ist der halbe Wert des Systems. |109110## Verwandte Skills111112- `workflow-extract` — baut aus Sessions/Fremd-Automationen Automatisierungen; nutzt dieses113 Gerüst als Standard-Baustein.114- `pipeline-optimizer` — für den strukturellen Umbau einer Pipeline (Rotation-Check pflegt,115 Optimizer renoviert).116117## Changelog118119### 1.1.0 (2026-07-03)120- Geschwister-Cooldown als Auswahlregel ergänzt (Anti-Kollision zwischen verwandten121 Checks über dieselbe Zielmenge; Befund aus der Vollklassifikation des Automations-Bestands).122123### 1.0.0 (2026-07-03)124- Initiale Version. Abstrahiert aus dem Codex-Automations-Bestand (Rotations-Muster in125 ~40 von 77 Automationen: Research-/Software-/Roblox-Checks mit CHECKED-REGISTRY/CHECKS-LOG).
ellmos-ai