Deine Issues liegen bereits in GitHub. Genauso wie der Code, das Pull-Request-Review und die Branch-Regeln, auf die sich dein Team ein Quartal lang geeinigt hat. Niemand will ein zweites Board, das mit dem ersten synchron gehalten werden muss. Was fehlt, ist ein Weg, eines dieser Issues an einen Coding-Agent zu übergeben und einen reviewbaren Pull Request zurückzubekommen – ohne das Repository zu verlassen, aus dem es stammt.
Genau das bewirkt die Verbindung von GitHub mit Sharkly. Sharkly ist eine All-in-One-Plattform für die Steuerung und Verwaltung von Agents: Sie verwandelt ein GitHub-Issue in einen zuweisbaren Task, leitet es an einen Coding-Agent weiter (Claude Code, Codex, Gemini oder welche Runtime dein Team auch einsetzt), führt die Arbeit auf einem Computer in einem isolierten Worktree aus und liefert das Ergebnis als Pull Request zurück, den du wie gewohnt reviewst. Zwei Dinge sind hier am wichtigsten: wer tatsächlich auf das Repository zugreifen darf und wo ein Mensch noch sein Okay geben muss.
Der Kreislauf in einem Satz
Verbinde GitHub, verknüpfe ein Repository mit einem Space – und ein neues Issue wird zum Task. Weise es einem Agent zu, und überall in Sharkly gilt derselbe Vertrag: Der Agent recherchiert, führt aus, testet und berichtet; ein Mensch reviewt den Diff und entscheidet, was ausgeliefert wird.
Zwei Verbindungen – und warum sie nicht dasselbe sind
Die GitHub-Integration hat zwei Ebenen, und sie zu verwechseln ist der schnellste Weg, um durcheinanderzukommen, wer was sehen kann.
Die erste Ebene ist die Organisationsverbindung. Ein Organization Owner oder Admin öffnet die Integrationen, findet GitHub und installiert die GitHub App für die Repositories, die sie sehen soll. Diese Verbindung ist es, die das Verknüpfen von Pull Requests und Linkback-Kommentare möglich macht. Mitglieder können außerdem ein persönliches GitHub-Konto verbinden, aber das ändert nur, wessen Identität bei synchronisierten Kommentaren erscheint, nicht das, was die Organisationsverbindung bereits leistet.
Die zweite Ebene ist die Verknüpfung eines dieser Repositories mit einem Space. Ist das erledigt, tauchen neue GitHub-Issues als Tasks auf; bestehende Issues werden nicht importiert. Ein Repository kann einen Space einseitig versorgen (Issue-Änderungen fließen hinein, nie zurück) oder beidseitig (Issues und Tasks bleiben in beide Richtungen synchron), und ein Space bekommt jeweils nur ein beidseitiges Repository – wähle also mit Bedacht.
Und hier ist die Grenze, über die viele stolpern: Nichts davon verschafft einem Agent die Berechtigung, deinen Code zu klonen. Die GitHub-Integration deckt Pull-Request-Verknüpfungen, Issue-Synchronisierung und Linkback-Kommentare ab. Sie gibt keinem Agent Lese- oder Schreibzugriff auf ein Repository.
Code-Zugriff für den Agent separat vergeben
Der Code-Zugriff ist eine separate Konfiguration, die am Agent oder am Space festgelegt wird – nicht an der GitHub-Verbindung. Ein Agent ohne eigene Repositories greift auf das zurück, was für den Space des Tasks konfiguriert ist. Schränke diese Liste am Agent selbst ein, wenn er von mehreren Codebasen, auf die ein Space verweist, nur eine einzige anfassen soll.
So oder so braucht der Run weiterhin funktionierenden Git-Zugriff auf dem Computer selbst: einen SSH-Schlüssel, ein HTTPS-Token oder dort bereits eingerichtete Host-Zugangsdaten. Die Organisationsverbindung stellt diese nicht bereit und ersetzt sie nicht. Wenn ein Run nicht klonen kann, ist das ein Computer-Problem, keine Einstellung der GitHub App.
Das Issue einem Agent zuweisen
Sobald ein Repository verknüpft ist, landet ein neues GitHub-Issue als Task (Issue, Bug, Feature und Ticket sind alle gültige Task-Typen, je nachdem, was dein Space verwendet). Ihn einem Agent zuzuweisen funktioniert genauso wie die Zuweisung an ein Teammitglied: Öffne das Assignee-Feld und wähle stattdessen den Agent aus.
Ein Agent ist eine gespeicherte Arbeitskonfiguration, kein einmaliger Prompt: Seine Anweisungen, seine Runtime, seine Repositories und seine Run-Einstellungen prägen die Arbeit, so wie eine Rollenbeschreibung prägt, was eine neue Mitarbeiterin tut. Landet der Task im Backlog, läuft noch nichts – das ist ein Wartebereich. Verschiebe ihn in einen Arbeitsstatus, und Sharkly startet den Run, sobald ein Computer und eine Runtime bereit sind.
Wenn zwei Agents dasselbe Repository anfassen
Das ist der Teil, über den sich Teams am meisten Sorgen machen. Der Standardmodus ist Temporary: Jeder Task bekommt ein isoliertes Verzeichnis, und repository-gestützte Runs bereiten einen frischen Worktree vor. Zwei Agents an zwei verschiedenen Issues im selben Repository bekommen jeweils ihr eigenes Checkout, kein gemeinsames, sodass sie sich nicht gegenseitig Dateien überschreiben oder um einen Branch streiten können – selbst auf demselben Computer. Es ist dieselbe Disziplin wie beim manuellen Einsatz von Git-Worktrees mit KI-Coding-Agents, nur automatisch.
Die Nebenläufigkeit hat ihre eigene Obergrenze. Temporary-Runs liegen standardmäßig bei etwa der Hälfte des Gesamtlimits des Computers; erhöhst du es manuell, warnt dich das Produkt, sobald der Wert die verfügbare Verzeichniskapazität übersteigt – und genau dort beginnen tatsächlich Kollisionen. Den Specified-Modus gibt es auch, bei dem ein Agent ein festes Verzeichnis statt eines frischen Worktrees wiederverwendet, aber er bedient nur einen Run gleichzeitig und passt damit schlechter zu einem Repository, auf das mehrere Agents gleichzeitig losgehen.
Was zurückkommt: der Pull Request
Wenn der Agent einen Pull Request öffnet, verbindest du ihn mit dem Task, indem du die Task-ID in den Branch-Namen, den Titel oder den Text schreibst. Eine der drei Stellen genügt; eine bloße ID wie SH-312 funktioniert genauso wie Fixes SH-312, denn Wörter wie fixes, closes oder skip werden nicht gesondert behandelt. In einem öffentlichen Repository wird nur ein vertrauenswürdiger Autor verknüpft – der Owner, ein Mitglied oder ein Collaborator –, damit sich der Pull Request eines Fremden nicht auf deinen Task schummeln kann.
Verknüpfte Pull Requests können außerdem einen Linkback-Kommentar erhalten, der zurück auf den Task verweist. Bei privaten Repositories ist das standardmäßig aktiviert, bei öffentlichen standardmäßig deaktiviert – ein Schalter, der in den GitHub-Einstellungen lebt, unabhängig davon, ob der Space selbst öffentlich oder privat ist.
Das Review-Gate: wo das Urteilsvermögen sitzt
Das Mergen eines Pull Requests ändert den Status des Tasks nicht – und es passiert niemals von allein. Das ist Absicht. Task-Status und Arbeitszustand eines Agents werden getrennt erfasst, sodass ein gestarteter Task zusätzlich Working, Waiting for human reply, Waiting for human review oder Error anzeigen kann, und diese Signale tauchen in der Inbox für die verantwortliche Person auf. Das Schließen oder Wiederöffnen des zugrunde liegenden GitHub-Issues kann den Status eines beidseitig synchronisierten Tasks verschieben; das Mergen des Pull Requests kann das nicht.
Agents recherchieren, führen aus, testen und berichten. Menschen lesen den Diff gegen das ursprüngliche Issue, fordern Änderungen an oder akzeptieren, und treffen die Merge- und Release-Entscheidung selbst. Diese Aufteilung gilt durchgängig, auf GitHub genauso wie überall sonst in Sharkly: Die Automatisierung endet genau dort, wo das Urteilsvermögen des Teams gefragt ist. Die tieferen Mechanismen behandelt Sharklys Human-in-the-Loop-Review-Workflow direkt.
Wann GitHubs eigener Agent-Hub ausreicht
Wenn dein Team voll auf GitHub setzt – Source, CI, Review und ein bezahlter Copilot-Platz –, koordiniert GitHubs eigener Agent HQ Agents innerhalb dieses Ökosystems gut, und du brauchst vielleicht nichts weiter. Der Fall für Sharkly zeigt sich, sobald Arbeit auch über Jira läuft, sobald Agents auf Computern außerhalb von GitHubs Cloud laufen oder sobald dein Team Runtimes mischt und nicht jedes Mal den Workflow neu aufbauen will, wenn sich die beste ändert. Wenn Jira Teil dieses Mixes ist, geht das Zuweisen eines Jira-Tickets an einen KI-Agent dieselbe Schleife von dieser Seite an.
Um es an einem echten Issue auszuprobieren: Öffne Sharklys GitHub-, Jira- und Slack-Integrationen, verbinde deine GitHub-Organisation, verknüpfe ein wenig genutztes Repository mit einem Space und weise das nächste kleine Issue einem Agent statt dir selbst zu.
Häufig gestellte Fragen
Gibt das Verbinden meiner GitHub-Organisation einem Agent Zugriff auf meinen Code? Nein. Die Organisationsverbindung deckt Pull-Request-Verknüpfungen, Issue-Synchronisierung und Linkback-Kommentare ab. Der Code-Zugriff wird separat konfiguriert, am Agent oder am Space, und der Run braucht weiterhin seine eigenen Git-Zugangsdaten auf dem Computer.
Kollidieren zwei Agents, die am selben Repository arbeiten, jemals? Im standardmäßigen Temporary-Modus nicht. Jeder Run bekommt seinen eigenen isolierten Worktree, sodass gleichzeitige Agents nie eine Arbeitskopie teilen – selbst auf demselben Computer nicht.
Schließt das Mergen des Pull Requests das GitHub-Issue oder den Task? Das Mergen ändert den Status des Tasks nie von allein. Das Schließen des zugrunde liegenden GitHub-Issues kann das – in einem beidseitig synchronisierten Repository –, aber das ist eine andere Aktion als das Mergen des PR.
Worauf zielt der Pull Request des Agents eigentlich? Sharkly verknüpft den Pull Request über die Task-ID im Branch, im Titel oder im Text – je nachdem, was deine Runtime schreibt. Es schreibt keine Branch-Strategie vor, also prüfe das Standardverhalten deiner Runtime beim Basis-Branch, bevor du etwas mit höherem Einsatz als ein Test-Issue zuweist.
Kann ich meine bestehenden GitHub-Issues behalten, nicht nur neue? Das Verknüpfen eines Repositories synchronisiert neu erstellte Issues ab diesem Zeitpunkt. Bestehende Issues werden nicht automatisch importiert.
