Ein Satz wie “Issue #37 in einem Feature-Branch beheben.” reicht bei uns inzwischen oft als Prompt. Claude Code öffnet das Ticket, legt einen Branch an, schreibt den Code und postet einen Kommentar zurück ins Issue. Wir reviewen und mergen.
Der Hebel dabei ist nicht das Modell, sondern die Kombination aus Claude Code, der GitLab CLI (glab) und dem Editor-Plugin “Git Issues“, welches wir uns für VS Code und Cursor gebaut haben — um die Lücke zwischen Terminal und Issue-Tracker zu schließen.
Plugin im VS Code Marktplatz: https://marketplace.visualstudio.com
Vom Prompt zum Merge Request
Drei Bausteine, die zusammen ein neues Pattern ergeben:
1. Claude Code arbeitet direkt im bestehenden Terminal-Kontext.
Wenn ein Tool per CLI verfügbar ist, kann der Agent es benutzen — ohne spezielle Integration oder Plugins. Wenn glab da ist, kann Claude damit arbeiten. Dasselbe gilt für gh bei GitHub.
2. Die GitLab CLI (glab) kennt Issues, Merge Requests, Labels und Pipelines.
glab issue view 37,glab issue create,glab issue note 37 -m "..."
Selbst gehostete Instanzen werden über glab auth login --hostname gitlab.example.com konfiguriert. Mehrere Instanzen gleichzeitig? Geht auch — glab speichert Tokens pro Host.
3. Ein Prompt-Pattern, das wir uns angewöhnt haben:
„Issue #37 ansehen, einen Branch dafür anlegen, das Problem implementieren, Tests laufen lassen und einen Kommentar mit kurzer Zusammenfassung im Issue posten.“
Das war’s!
Claude liest das Issue (glab issue view 37 --comments), versteht Kontext und Diskussion, legt einen Branch an, implementiert die Änderung, führt Tests aus, committed mit Refs #37 und postet eine kurze Zusammenfassung zurück ins Issue. Wir steigen später ein, reviewen und mergen — oder schicken den Agenten mit einem Detail-Hinweis nochmal zurück.
Der spannende Teil daran ist weniger „AI schreibt Code“, sondern dass bestehende Developer-Workflows plötzlich maschinenlesbar werden: Issues, Labels, Branches, Kommentare, Pipelines.
Und noch etwas ist uns dabei aufgefallen: Issues sind das bessere Briefing als Chat-Nachrichten.
Wenn man sich angewöhnt, Tasks sauber als GitLab-Issue mit Beschreibung, Akzeptanzkriterien und Labels anzulegen, hat ein AI-Agent ein deutlich besseres Verständnis der Aufgabe als bei halb-strukturierten Nachrichten im Chat-Fenster. Das gilt für Menschen genauso — nur sind die toleranter.
Überraschend war für uns vor allem, wie schnell schlechte oder unvollständige Issues sichtbar werden. Der Agent improvisiert dann nicht „intelligent“, sondern läuft einfach konsequent in die falsche Richtung.
Gute Issues waren schon immer hilfreich. Mit AI-Agenten werden sie zur Schnittstelle.
Feedback aus den Apps direkt als Issue
Damit das überhaupt funktioniert, muss aber erst mal ein Issue da sein. Genau hier endet der gute Vorsatz oft: ein Bug fällt auf, jemand notiert ihn als Chat-Nachricht oder im Kopf, und drei Tage später ist die Hälfte des Kontextes weg.
In den meisten unserer Tools und Apps haben wir deshalb ein direktes Feedback-Widget eingebaut. Ein Klick, kurze Beschreibung, optional ein Screenshot — fertig. Was hinter den Kulissen passiert: ein LLM bereitet den Eintrag auf, fügt relevante Metadaten an (Browser, App-Version, betroffene Route, eingeloggter User-Kontext, ggf. ein Stack-Trace) und legt das Ganze als sauber strukturiertes GitLab-Issue im richtigen Projekt an. Mit Labels, mit reproduzierbarem Schritt-Text, mit Screenshot als Attachment.
Das Ergebnis: ein Issue, das ein:e Entwickler:in oder direkt Claude Code abarbeiten kann, ohne nachzufragen. Vom Bug-Sichten bis zum fertigen Branch dauert es im besten Fall keine zehn Minuten — und keine:r muss zwischendurch erklären, “was eigentlich gemeint war”.
Der Teil, den der Agent nicht übernimmt
Der Loop “Issue lesen, Branch, Code, Kommentar, Merge Request” funktioniert exzellent für Aufgaben, die der Agent komplett autonom abarbeitet. Aber: nicht jede Aufgabe ist autonom. Sehr oft ist die Realität:
- Wir schreiben das Issue selbst zu Ende, bevor der Agent loslegt. Akzeptanzkriterien ergänzen, Screenshot anhängen, Labels setzen.
- Wir lesen während der Implementierung mit und kommentieren im Issue, was nachgeschärft werden soll.
- Wir triagieren parallel andere Tickets — was ist heute dran, was schiebt sich nach hinten.
Genau diese Schritte passieren nicht im Terminal mit Claude Code. Die passieren im Editor, neben dem Code. Und damit waren wir wieder beim alten Problem: Cmd+Tab in den Browser, das richtige GitLab finden, Issue öffnen, kommentieren, zurück.
Bei drei parallelen Welten — GitHub.com für Open Source, gitlab.com für Marketplaces, selbst gehostetes GitLab für Kundenprojekte unter NDA — wird das schnell teurer, als es aussieht.
Also haben wir das Plugin gebaut, das diese Lücke füllt.
Gitlab Issue Plugins, was es schon gibt
GitHub Pull Requests and Issues (Microsoft) ist GitHub-only und PR-zentriert. Issues laufen mit, sind aber nicht das Produktthema.
GitLab Workflow ist offiziell und kann Self-Hosted. Laut GitLab-Doku gibt es aber pro Workspace ein aktiver Account und einen Status-Bar-Switcher — nicht “automatisch passendes Token pro Repo-Origin”, was bei mehreren parallelen GitLab-Instanzen schnell zum Problem wird.
Cursor erbt den Open-VSX-Marketplace und hat zusätzlich eine GitLab-MCP-Integration für Agents. Im Cursor-Forum liest sich aber recht klar, dass viele Teams improvisieren: “We’re currently using a Frankenstein-ish solution where we auto-mirror our Gitlab repositories to Github.”
Nachfolgend ein Vergleich vorhandener Plugins und Git Issues:
| Feature | Git Issues | GitHub PR & Issues | GitLab Workflow |
|---|---|---|---|
| GitHub-Issues bedienen | ✅ | ✅ | ❌ |
| Mehrere GitLab-Instanzen gleichzeitig, Token pro Host | ✅ | ❌ | ⚠️ |
| Multi-Repo-Workspace folgt aktivem Editor | ✅ | ⚠️ | ⚠️ |
| Issue-Templates beim Anlegen aus dem Repo | ✅ | ✅ | ⚠️ |
| Reactions auf Issues und Kommentare | ✅ | ✅ | ❌ |
| Linked PRs/MRs neben dem Issue-Body | ✅ | ✅ | ❌ |
| Offline-Cache für Issue-Liste | ✅ | ❌ | ❌ |
Legende: ✅ vorhanden · ❌ nicht vorhanden · ⚠️ teilweise / mit Einschränkung – (Stand: Mai 2026)
Was unser Git Issues Plugin ergänzt
Das Plugin läuft in VS Code und Cursor und füllt genau die Lücke zwischen “Issue-Triage im Browser” und “Issue-Bearbeitung mit Claude Code im Terminal”. Eine Sidebar, die das aktive Repo erkennt, mit dem passenden Provider und dem passenden Token spricht — ohne dass wir manuell switchen.
- Issues durchsuchen, filtern (offen/geschlossen, eigene/fremde, Label, Milestone), sortieren.
- Neue Issues anlegen — wenn das Repo
.github/ISSUE_TEMPLATE/oder.gitlab/issue_templates/mitbringt, kannst du ein Template auswählen. - Kommentieren mit Markdown-Vorschau, Drag & Drop für Bilder bei GitLab, Slash-Commands wie
/closeoder/assignaus einem Quick Pick. - Issues editieren, schließen, wiederöffnen, Reactions setzen, eigene Kommentare nachträglich anpassen.
- Branch aus Issue anlegen — und umgekehrt: wechselst du auf
37-fix-tax-calc, fragt die Extension, ob sie Issue #37 öffnen soll. Genau der Branch, den Claude Code dir vorhin angelegt hat. - Verlinkte Pull/Merge Requests sehen, ohne in den Browser zu wechseln.
- Split-View: Issue rechts neben dem Code, nicht darüber.
Probier es aus
Wenn du mit Claude Code, der GitLab CLI oder einem ähnlichen Setup arbeitest und dich der Browser-Wechsel für Issue-Verwaltung nervt: probier es aus. Open Source, MIT-Lizenz, läuft in VS Code und Cursor. Pull-Requests sind gerne gesehen. 😉
VS Code Marktplatz: https://marketplace.visualstudio.com
Gihub: https://github.com/tabsl/VS-Code-Git-Issues
