Issue öffnen, Branch anlegen, Worktree erstellen, Agent starten, Ticket Text reinkopieren. Fünf Schritte, bevor der Agent überhaupt anfängt. Mit Desktop 12.4 macht GitKraken daraus einen Klick. Die GitKraken Agent Session aus dem Issue verbindet Ticket, Git und Agent in einem Schritt.
Klingt nach Komfort. Es verändert aber, worauf es ankommt: Das Issue wird zum Prompt. Dieser Beitrag zeigt, wie das funktioniert und wie ihr Issues schreibt, mit denen Agents gute Arbeit liefern. Den Überblick über alle neuen Features gibt unsere Seite GitKraken 2026: Agent Mode, Kepler und KI im Git Client.
Vom Issue zum Agent lernen: Im NCA KI Workshop für Developer üben Teams, Aufgaben so zu schneiden und zu beschreiben, dass Agents zuverlässig liefern. Mit Worktrees, Regeln und Tests. Zum NCA KI Workshop für Developer
So funktioniert der Start aus dem Issue
GitKraken hat zwei Einstiegspunkte: das Launchpad, in dem Pull Requests, Issues und Aufgaben gesammelt sind, und die Issue Liste im linken Panel. Von dort startet ihr eine Agent Session. GitKraken übernimmt dann:
- Branch anlegen: Ein neuer Branch für genau dieses Issue.
- Worktree öffnen: Der Branch bekommt ein eigenes Arbeitsverzeichnis, ein Git Worktree.
- Agent starten: Euer gewählter Coding Agent startet im Worktree.
- Kontext übergeben: Titel und Beschreibung des Issues landen direkt beim Agent. Kein Kopieren mehr.
Ab da läuft die Session wie jede andere im Agent Mode. Ihr seht den Status im Commit Graph und gebt riskante Aktionen frei. Wie das genau aussieht, zeigt der Beitrag zum GitKraken Agent Mode.
Der gleiche Weg in VS Code und im Agent
Auch der GitKraken MCP Server kennt diesen Ablauf. Das Tool gitlens_start_work startet die Arbeit an einem Issue, öffnet einen Worktree und startet einen Agent. Für Pull Requests gibt es gitlens_start_review: Es holt die PR Details, öffnet Worktree und Diff und startet einen Agent für das Review. Damit funktioniert der Start aus dem Issue auch aus einem Agent heraus, nicht nur per Klick.
Das Issue ist jetzt der Prompt
Hier liegt der eigentliche Punkt. Der Agent bekommt genau das, was im Issue steht. Ein Ticket mit dem Titel „Login kaputt“ und ohne Beschreibung liefert einen Agent, der rät. Ein Ticket mit klarem Ziel, Rahmen und Akzeptanzkriterien liefert einen Agent, der liefert.
Was ein agentenfähiges Issue braucht
- Ein Ziel in einem Satz: Was soll nach der Änderung anders sein?
- Akzeptanzkriterien: Konkrete Beispiele, wann die Aufgabe erledigt ist. Example Mapping hilft, sie zu finden.
- Rahmen: Welche Dateien und Module betroffen sind und welche nicht.
- Tests: Welche Tests grün sein müssen, und ob neue dazukommen.
- Größe: Eine Aufgabe, die ein Mensch an einem halben Tag schaffen würde. Größere Tickets teilt ihr auf.
Wer tiefer einsteigen will: Die Dokumentenkette aus ADR, PRD und BDD zeigt, wie Anforderungen vom Fachbereich bis zum Agent durchgereicht werden.
Vorlage: Ein Issue, mit dem Agents arbeiten können
Diese Vorlage könnt ihr als Issue Template in GitHub oder GitLab hinterlegen. Jeder Abschnitt beantwortet eine Frage, die der Agent sonst raten müsste:
## Ziel
Kunden laden ihre Rechnung als PDF herunter.
## Akzeptanzkriterien
- Auf /konto/rechnungen gibt es pro Rechnung einen Button "PDF".
- Das PDF enthält Rechnungsnummer, Datum und Betrag.
- Fremde Rechnungen liefern einen 403.
## Rahmen
- Betroffen: src/Invoice, templates/account
- Nicht anfassen: src/Payment, Konfiguration, Lockfiles
## Tests
- PHPUnit Test für den Controller
- Cypress Test für den DownloadAchtet besonders auf das dritte Akzeptanzkriterium. Ohne diese Zeile baut ein Agent den Download, vergisst aber die Rechteprüfung. Sicherheitsregeln, die für Menschen selbstverständlich sind, müssen für Agents im Issue stehen oder in den Projektregeln.
Regeln gehören ins Repository
Das Issue beschreibt die Aufgabe. Wie im Projekt gearbeitet wird, gehört nicht in jedes Ticket. Das steht einmal im Repository, in AGENTS.md oder rules.md: Coding Standards, Testbefehle, verbotene Dateien. Der Agent liest beides, Issue und Regeln, und arbeitet damit im Rahmen eures Projekts.
Welche Tracker und Agents funktionieren
Das Launchpad sammelt Issues und Pull Requests aus den angebundenen Diensten, etwa GitHub, GitLab, Bitbucket, Azure DevOps und Jira. Den Agent wählt ihr selbst. Live Status liefern derzeit OpenCode, Claude Code und GitHub Copilot CLI. Wer Tasks über mehrere Repositories aus einem Issue starten will, findet das im Agentic Development Environment Kepler.
Die offizielle Beschreibung steht im GitKraken Blog zu Desktop 12.4, die MCP Tools in der MCP Tools Referenz. GitKraken Desktop selbst gibt es auf gitkraken.com. Die Git Grundlagen des Clients erklärt unser GitKraken Eintrag im PHP Glossar.
Häufige Fragen zur Agent Session aus dem Issue
Seit wann kann GitKraken Agents aus Issues starten?
Seit GitKraken Desktop 12.4. Ihr startet die Session aus dem Launchpad oder aus der Issue Liste im linken Panel. GitKraken legt Branch und Worktree an und übergibt den Issue Kontext an den Agent.
Welche Informationen bekommt der Agent aus dem Issue?
Der Agent bekommt den Kontext des Issues, also vor allem Titel und Beschreibung. Deshalb lohnt es sich, Issues mit Ziel, Akzeptanzkriterien und Rahmen zu schreiben. Projektregeln gehören in AGENTS.md im Repository.
Muss ich den Branch danach selbst aufräumen?
GitKraken hilft dabei. Ein Hinweis zeigt, wenn der zugehörige Pull Request gemergt ist. Beim Löschen des Branches bietet GitKraken an, den Worktree gleich mit zu entfernen.
Geht das auch ohne GitKraken Desktop?
Ja. Über den GitKraken MCP Server und das Tool gitlens_start_work startet ein Agent die Arbeit an einem Issue selbst. Im Terminal geht es auch ganz ohne GitKraken: Branch, Worktree und Agent per Skript anlegen.
Bessere Issues, bessere Agents
Wir helfen euch, Anforderungen so zu schreiben, dass Agents sie zuverlässig umsetzen, und sichern das Ergebnis mit Regeln und Tests ab. Das Vorgespräch ist kostenlos.
