Wie ein Lauf funktioniert

Jeder Durchlauf eines Loops läuft gleich ab — ob ihn ein Webhook, eine Uhr oder eine direkte Erwähnung ausgelöst hat. Diese Seite beschreibt, was zwischen dem Auslöser und dem Merge Request geschieht.

1. Der Auslöser trifft ein

TaskGoblin findet oder erzeugt den Thread für dieses Stück Arbeit — das Gespräch zu einem Issue, einem Merge Request, einem Loop — und hält den Durchlauf als Nachricht darin fest. Eine Rückfrage zu laufender Arbeit landet im bestehenden Thread statt in einem neuen. Deshalb bittet der Goblin Sie nie, alles noch einmal zu erklären.

2. Die Sandbox fährt hoch

Der Lauf bekommt einen isolierten Cloud-Container mit einem Checkout Ihres Repositories. Sandboxes sind dauerhaft und werden über die Durchläufe eines Threads hinweg wiederverwendet, sodass eine Rückfrage in einer Umgebung landet, die Repository und den Stand des vorigen Durchlaufs bereits hat — der Goblin setzt fort, statt in einer leeren Kiste zu beginnen.

Oft sind sie vorgewärmt, weshalb ein Lauf meist in Sekunden zu arbeiten beginnt, statt auf einen kalten Container zu warten. Die Cloud-Sandbox behandelt Isolation, Persistenz und Self-Hosting im Detail.

3. Er liest, bevor er schreibt

Bevor er Code anfasst, sammelt der Goblin Kontext: das auslösende Issue oder Diff, den Verlauf des Threads, die Übergabenotiz des vorigen Goblins und die Konventionen Ihrer Organisation. Bei einem Ereignis-Loop legt sich Ihre dauerhafte Anweisung über den Kontext des Ereignisses.

Dieser Schritt trennt eine nützliche Änderung von einer bloß plausiblen. Ein Agent, der sieht, wie die letzte Änderung geprüft wurde und warum ein früherer Ansatz zurückgenommen wurde, entscheidet besser als einer, der im leeren Raum anfängt.

4. Ein echter Coding-Agent erledigt die Arbeit

In der Sandbox läuft ein echter Coding-Agent — Claude Code, Codex oder Gemini, je nach Modell-Konto des Laufs. Er hat die Werkzeuge einer Entwicklerin: liest und bearbeitet Dateien, führt Befehle aus und lässt Ihre Tests laufen. Er vervollständigt kein Diff, er arbeitet das Problem durch.

5. Branch, Commit, Push, Merge Request

Der Goblin folgt dem Workflow, den Ihr Team ohnehin nutzt:

1. Er arbeitet auf einem eigenen Branch — 142-taskgoblin für Issue 142 auf GitLab oder GitHub, proj-123-taskgoblin für einen Jira-Schlüssel — nie auf Ihrem Standard-Branch.
2. Er committet und signiert seine Arbeit, damit die Spur lesbar bleibt, und pusht den Branch.
3. Er öffnet einen Merge Request (GitLab) oder Pull Request (GitHub) und meldet den Link dorthin zurück, wo die Arbeit begann.

Die Ausnahme ist ein Lauf, der an einem bestehenden Merge Request ausgelöst wurde: Dann pusht er auf dessen Branch, statt einen konkurrierenden zu öffnen.

Weil das Ergebnis ein Branch und ein Merge Request ist, ist Review genau das, was es für menschliche Beiträge schon ist. Nichts wird ohne Ihr Ja gemerged.

6. Er berichtet dort, wo Sie ohnehin hinsehen

Während des Laufs meldet sich der Goblin über die Oberfläche, zu der die Arbeit gehört: Aktivität an einem Linear-Issue, Inline-Kommentare an einem Merge Request, eine sich selbst aktualisierende Karte in Slack oder Teams. Sie starren nicht auf ein Terminal, und es gibt kein separates Dashboard, an das Sie denken müssten.

7. Er schreibt auf, was passiert ist

Das Letzte, was ein Goblin tut — nach dem Absenden der Antwort, nie davor — ist eine Übergabenotiz: was er gelernt hat, was er entschieden hat, was offen bleibt. Der nächste Durchlauf liest sie zuerst.

Deshalb summiert sich ein Loop, statt sich zu wiederholen. Siehe Das Gehirn.

Geheimnisse bleiben außerhalb des Agenten

Der Goblin sieht Ihre Zugangsdaten nie. Git-Zugriff in der Sandbox wird pro Organisation zur Laufzeit bereitgestellt — ein GitLab-OAuth-Token oder ein frisch erzeugtes GitHub-Installations-Token — und in die Umgebung um den Agenten herum eingespeist, statt ihm zum Lesen gegeben zu werden. Er kann den Zugriff zum Klonen und Pushen nutzen, ohne dass Ihre Geheimnisse je in seinen Kontext oder sein Transkript gelangen.

Dieses Token dient allein dem Git-Transport. Kommentare, Reviews und Issue-Aktualisierungen laufen über TaskGoblins eigene Integrationen, damit sie als Goblin erscheinen und nicht als Sie.

Wenn etwas schiefgeht

Ein fehlgeschlagener Lauf verschwindet nicht. Der Goblin meldet es klar auf der Oberfläche, von der aus Sie ihn ausgelöst haben, der Fehler wird am Lauf festgehalten, und die Übergabenotiz trägt die Wand weiter, gegen die er gelaufen ist, damit der nächste Durchlauf sie nicht neu entdeckt. Ein Lauf, der nie eine Sandbox bekam — etwa wegen aufgebrauchten Guthabens — wird nie berechnet.

Wie es weitergeht

• Die Cloud-Sandbox — Isolation, Persistenz und der Betrieb auf eigener Infrastruktur.
• Das Gehirn — das aufgeschriebene Wissen, das Arbeit weiterträgt.
• Preise und Guthaben — was ein Durchlauf kostet, sekundengenau gemessen.