Einführung

Hören Sie auf, Agenten zu prompten. Fangen Sie an, Loops zu bauen.

Dieser Unterschied ist das ganze Produkt. Ein Prompt liefert eine Antwort, einmal, und nur wenn jemand daran denkt, ihn zu tippen. Ein Loop ist ein Auslöser plus eine Anweisung: Er startet von selbst, erledigt die Arbeit in einer isolierten Cloud-Sandbox, öffnet einen Merge Request, den Sie prüfen, notiert das Gelernte und ist bereit für den nächsten Durchlauf.

Sie öffnen keine App und kopieren keinen Code in ein Chatfenster. Sie verbinden die Werkzeuge, die Ihr Team ohnehin nutzt, und die Arbeit beginnt darin zu passieren.

Ein Loop ist ein Auslöser und eine Anweisung

• Der Auslöser ist entweder ein Ereignis — ein Pull Request wurde geöffnet, ein Issue dem Goblin zugewiesen — oder ein Zeitplan, etwa jeden Werktag um 07:00.
• Die Anweisung ist normale Sprache, keine DSL. „Prüfe diesen Merge Request auf Korrektheit und Sicherheit — melde echte Probleme, keine Stilfragen." Oder: „Prüfe acme/web auf sichere Abhängigkeits-Updates und öffne einen Merge Request."

Alles, was TaskGoblin tut, ist so ein Loop. Das automatische Code-Review ist ein Ereignis-Loop auf Pull Request geöffnet. Ein Issue zuzuweisen und einen Merge Request zurückzubekommen ist ein Ereignis-Loop auf Issue zugewiesen. Die nächtliche Prüfung der Testsuite ist ein Zeitplan-Loop um 06:00. Es gibt kein separates „Automatisierungs-Feature" daneben: Loops sind die Primitive, und die Verhaltensweisen, die eingebaut wirken, sind Loops, die Ihnen gehören und die Sie umschreiben können.

Wenn Sie nur eine weitere Seite lesen, lesen Sie Loops.

Sie starten mit bereits laufenden Loops

Melden Sie sich mit GitLab oder GitHub an, und TaskGoblin richtet Ihre Organisation ein, verbindet Ihre Repositories und installiert die Standard-Loops dieses Anbieters — Merge Requests prüfen, zugewiesene Issues übernehmen. Öffnen Sie einen Pull Request, und er wird geprüft, bevor Sie irgendetwas konfiguriert haben.

Diese Standards sind ganz normale Loops auf Ihrer Loops-Seite. Lesen Sie die Anweisung, schreiben Sie sie in Ihren eigenen Worten um, pausieren Sie sie, löschen Sie sie. Dass das Verhalten Ihnen gehört, ist genau der Punkt.

Wie ein Loop tatsächlich aussieht

Loops werden in normaler Sprache geschrieben. Hier ein echter aus der Vorlagen-Galerie — ein nächtlicher Wächter über Ihre Testsuite:

Auslöser — täglich um 06:00

Anweisung — Klone acme/web und führe die vollständige Testsuite auf dem Standard-Branch aus. Schlägt etwas fehl und die Korrektur ist klein und sicher, öffne einen MR; andernfalls fasse die Fehler zusammen. Läuft alles durch, tue nichts.

Drei Sätze, und sehen Sie, was darin steckt: wo gearbeitet wird, was zu tun ist, wann korrigiert und wann eskaliert wird — und die wichtigste Zeile jeder unbeaufsichtigten Anweisung: die Erlaubnis, nichts zu tun. Diese letzte Klausel ist der Grund, warum Sie an den Morgen, an denen etwas kaputtging, einen Merge Request bekommen und an den anderen Stille.

Die Galerie liefert neun Vorlagen zum Starten: Abhängigkeits-Updates, veraltete Doku, Changelog-Einträge, Tech-Debt-Durchläufe, Aktivitätszusammenfassungen, Erinnerungen an liegengebliebene MRs, Triage-Hinweise. Alle editierbar und Ihre, sobald Sie eine auswählen. Siehe Zeitplan-Loops für den vollständigen Satz.

Warum die Loops in der Cloud laufen

Weil ein Goblin in einer isolierten Cloud-Sandbox läuft und nicht auf jemandes Laptop, ist die Arbeit:

• Asynchron — übergeben und den Rechner zuklappen.
• Isoliert — eine Grenze pro Organisation, und Ihre Zugangsdaten werden um den Agenten herum bereitgestellt, nie an ihn zum Lesen übergeben.
• Parallel — jeder Lauf bekommt eigenen Branch und eigene Sandbox; zehn gleichzeitig startende Loops sind zehn arbeitende Goblins, keine Warteschlange.
• Immer aktiv — die Wartung um 03:00 und das Review des um Mitternacht geöffneten Pull Requests passieren, ohne dass jemand wach ist.

Was am Ende eines Durchlaufs ankommt

Ein Branch und ein Merge Request, geprüft wie der eines Kollegen — oder Inline-Review-Kommentare, oder eine Antwort im Slack-Thread, in dem Sie gefragt haben. Nie eine Textwand, die Sie selbst abarbeiten müssen, und nie ein Commit auf Ihrem Standard-Branch.

Darunter arbeitet ein echter Coding-Agent (Claude Code, Codex oder Gemini) mit einem Checkout Ihres Repositories: liest Dateien, führt Befehle und Tests aus und arbeitet das Problem durch, wie es ein Mitwirkender täte. Weil er in jedem Werkzeug eine eigene Identität hat — @taskgoblin bei GitLab, Slack und Teams, taskgoblin[bot] bei GitHub — kann das ganze Team ihm Arbeit übergeben und das ganze Team sieht, was er getan hat.

Wie es weitergeht

Hier starten

• Schnellstart — von der Anmeldung zum ersten geprüften Pull Request und zum ersten Zeitplan-Loop.
• Loops — die Primitive, und warum sie einen Prompt schlägt.

Ihre Loops bauen

• Ereignis-Loops — Reviews, Zuweisungen und Labels; die Loops, die Sie schon haben, und wie Sie sie ändern.
• Zeitplan-Loops — wiederkehrende Arbeit und Vorlagen zum Starten.
• Ihre Integrationen verbinden — GitLab, GitHub, Linear, Jira, Slack und Microsoft Teams.
• Einzelne Läufe — direkt fragen, wenn die Arbeit wirklich einmalig ist.

Die Maschinerie verstehen

• Wie ein Lauf funktioniert — innerhalb eines einzelnen Loop-Durchlaufs.
• Die Cloud-Sandbox — wo Ihr Code läuft und wie er isoliert bleibt.
• Das Gehirn — wie eine Korrektur für jeden folgenden Goblin gilt.

Abrechnung

• Preise und Guthaben — Sie zahlen für Zeit, nicht für Tokens.
• Eigenes LLM-Konto mitbringen — und weniger zahlen.
• Eigenen Sandbox-Server mitbringen — Goblins auf Ihrer eigenen Infrastruktur.
• Automatische Aufladung — damit unbeaufsichtigte Loops nicht stehenbleiben.