Ereignis-Loops

Ein Ereignis-Loop löst aus, wenn in einem verbundenen Werkzeug etwas passiert. Kein Zeitplan, kein Zuweisungsritual, niemand tippt einen Prompt: Ein Pull Request wird geöffnet, und das Review läuft schon, bevor jemand den Tab gewechselt hat.

Seine Anweisung ist dauerhafte Vorgabe, die sich über das legt, was das Ereignis ohnehin mitbringt. Der Goblin bekommt den Merge Request oder das Issue automatisch als Kontext; Ihre Anweisung sagt ihm, was Sie damit getan haben wollen.

Die Ereignisse, auf die Sie loopen können

Ereignis	Quelle	Löst aus, wenn
Merge Request geöffnet	GitLab	Ein MR geöffnet, wiedereröffnet oder um neue Commits ergänzt wird
Issue zugewiesen	GitLab	Ein Issue dem Bot @taskgoblin zugewiesen wird
Pull Request geöffnet	GitHub	Ein PR geöffnet, wiedereröffnet oder um neue Commits ergänzt wird
Issue gelabelt	GitHub	Das Label taskgoblin an ein Issue vergeben wird
Issue zugewiesen	Linear	Ein Issue dem TaskGoblin-Agenten zugewiesen wird
Issue zugewiesen	Jira	Ein Issue dem TaskGoblin-Konto zugewiesen wird

Weil die „Geöffnet"-Ereignisse auch Aktualisierungen abdecken, gleicht ein Review-Loop ab, statt sich zu wiederholen: Im zweiten Durchgang liest er die Befunde, die er zuvor hinterlassen hat, schließt die von Ihnen behobenen und postet nur, was wirklich neu ist.

Die Loops, die Sie schon haben

Sie starten nicht mit einem leeren Blatt. Sobald ein Anbieter für Ihre Organisation existiert, installiert TaskGoblin dessen Standard-Loops:

• GitLab — Merge Requests prüfen und Zugewiesene Issues bearbeiten.
• GitHub — Pull Requests prüfen und Gelabelte Issues bearbeiten.
• Linear — Zugewiesene Issues bearbeiten.
• Jira — Zugewiesene Issues bearbeiten.

Sie bilden ab, was man von einem Coding-Agenten ab Werk erwartet. Der Unterschied: Sie gehören Ihnen — echte Loops auf Ihrer Loops-Seite, mit Anweisungen, die Sie lesen und ändern können.

Das Installieren passiert genau einmal, für immer. Löschen Sie einen Standard-Loop, bleibt er gelöscht — ein erneutes Verbinden des Anbieters holt ihn nicht klammheimlich zurück.

Die Anweisung umzuschreiben ist der Punkt

Die Standard-Review-Anweisung verlangt Korrektheit, Sicherheit und Wartbarkeit und weist den Goblin an, zu schweigen, wenn eine Änderung solide ist. Das ist eine vernünftige Ausgangsposition, keine Vorgabe, an die Sie gebunden sind. Teams verengen oder erweitern sie routinemäßig:

• „Melde nur Sicherheitsprobleme und Datenverlustrisiken. Sonst nichts."
• „Sei streng bei der Testabdeckung — jede Verhaltensänderung braucht einen Test; sag es, wenn einer fehlt."
• „Prüfe zusätzlich, ob jeder neue Endpunkt durch unsere Rate-Limiting-Middleware läuft."

Die Anweisung ist freier Text, kann also abbilden, was ein Linter nicht kann: Ihre Konventionen, Ihre vergangenen Vorfälle, den Fehler, den dieses Team immer wieder macht.

Der Standard und eine gehärtete Fassung davon

Das wird ausgeliefert:

Prüfe diesen Merge Request. Konzentriere dich auf Korrektheit, Sicherheit und Wartbarkeit — melde echte Probleme, keine Stilfragen, die ein Linter abfängt. Hinterlasse Inline-Kommentare nur dort, wo sie etwas beitragen, halte sie konkret und umsetzbar, und schweige, wenn die Änderung solide ist.

Sie ist bewusst zurückhaltend, denn ein Reviewer, der alles kommentiert, wird stummgeschaltet. Und so sieht derselbe Loop aus, nachdem ein Team einen Monat damit gelebt und einen Vorfall gehabt hat:

Prüfe diesen Merge Request auf Korrektheit, Sicherheit und Wartbarkeit. Melde echte Probleme, keine Stilfragen.

Prüfe zusätzlich immer: Jede Verhaltensänderung hat einen Test; kein neuer Endpunkt geht ohne unsere Rate-Limiting-Middleware live; keine Migration verändert eine bestehende Migrationsdatei; nichts loggt einen vollständigen Request-Body. Stufe das als kritisch ein, auch wenn der Rest der Änderung in Ordnung ist.

Ist der MR über 400 Zeilen lang, sag das in der Zusammenfassung und prüfe zuerst die riskantesten Dateien, statt alles zu überfliegen. Schweige, wenn die Änderung solide ist.

Nichts an der zweiten Fassung ist exotisch — es ist institutionelles Wissen, das vorher in einem Wiki lag, das niemand öffnete, und jetzt an dem Moment hängt, in dem es zählt. Das ist der Unterschied zwischen einem geerbten Loop und einem, der Ihnen gehört.

Der Ausschalter

Diesen Teil sollte man zweimal lesen, weil er ein Verhalten erklärt, das sonst wie ein Fehler aussähe.

Ein geloopetes Ereignis ohne passenden aktiven Loop startet keinen Lauf. Pausieren Sie Ihren Review-Loop, werden Merge Requests nicht mehr geprüft. Löschen Sie ihn, ebenso. TaskGoblin nimmt den Webhook weiterhin an — es gibt nur keine dauerhafte Anweisung, auf die hin gehandelt werden könnte, also wacht kein Goblin auf und es wird nichts berechnet.

Das ist der Preis dafür, dass das Verhalten Ihnen gehört, statt Ihnen zu widerfahren. Wenn das automatische Review ausgeblieben ist, schauen Sie zuerst nach, ob sein Loop noch aktiv ist.

Was nie gefiltert wird

Ausdrückliche menschliche Anfragen laufen immer, ob ein Loop existiert oder nicht:

• @taskgoblin erwähnt in einem Merge Request, Pull Request oder Issue-Kommentar
• Eine Nachricht oder Erwähnung in Slack oder Microsoft Teams
• Ein Folgekommentar an einem Linear-Issue, an dem der Goblin bereits arbeitet
• Eine Erwähnung in einem Jira-Issue-Kommentar
• Eine Antwort @taskgoblin fix auf einen seiner eigenen Review-Kommentare

Wenn ein Mensch direkt gefragt hat, antwortet ein Goblin. Loops regeln die unaufgeforderte Arbeit, und nur die.

Wenn mehrere Loops passen

Nichts hindert Sie daran, mehr als einen Loop auf dasselbe Ereignis laufen zu lassen — einen allgemeinen Review-Loop plus einen strengeren für Sicherheit etwa. Passen mehrere, bekommt der Goblin alle infrage kommenden Anweisungen zu sehen und beurteilt, welche greift; die Wahl wird am Lauf festgehalten, damit die Historie ehrlich bleibt. Die Arbeit passiert trotzdem als ein einziger Lauf: Loops vervielfachen sich nicht zu doppelten Reviews an einem Merge Request.

Wie es weitergeht

• Zeitplan-Loops — die andere Auslöserart, für Arbeit, die kein Ereignis ankündigt.
• Ihre Integrationen verbinden — auf welche Anbieter Sie loopen können und was jeder freischaltet.
• Einzelne Läufe — die direkten Anfragen, die Loops komplett umgehen.