GitHub Copilot für Jira erhält benutzerdefinierte Agenten, angepasste Branch-Regeln und Code-Review-Benachrichtigungen

Benutzerdefinierte Agenten und Anpassung pro Jira-Bereich

Die Ankündigung im GitHub Changelog vom 22. April bringt Funktionen, die den Copilot Cloud-Agenten in Jira von der Zone eines generischen Assistenten in Richtung eines Tools verschiebt, das tatsächlich auf die Bedürfnisse jedes Teams kalibriert werden kann. Die wichtigste Neuerung ist die Möglichkeit, benutzerdefinierte Agenten zu definieren — spezialisierte Copilot-Konfigurationen mit eigenen Systemanweisungen und Verhaltensregeln. Ein Team kann einen Agenten für die Bearbeitung von Bug-Tickets haben, der einem strengen Reproduktions- und Regressionstestprotokoll folgt, einen weiteren für die Vorbereitung von Dokumentation und einen dritten für routinemäßige Dependency-Updates.

Neben benutzerdefinierten Agenten hat GitHub auch Unterstützung für Atlassian Custom Fields hinzugefügt. Das bedeutet, dass Copilot Daten aus Feldern lesen und interpretieren kann, die das Unternehmen selbst definiert hat — beispielsweise ein Feld „Regulatorische Auswirkung” oder „Kundentyp” — und auf deren Basis Entscheidungen trifft, wie ein Ticket zu bearbeiten ist. Vor diesem Update stützte sich Copilot nur auf Standard-Jira-Felder, was seinen Nutzen in großen Organisationen mit entwickelten Metadatenschemata einschränkte.

Branch-Regeln und Konventionen in großen Teams

Die zweite bedeutende Neuerung sind angepasste Branch-Regeln auf Jira-Bereichsebene. Viele Unternehmen haben strikte Git-Branch-Namenskonventionen — beispielsweise feature/JIRA-123-kurze-beschreibung, bugfix/JIRA-456-crash oder spezielle Präfixe für Hotfixes. Bisher verwendete Copilot eingebaute Annahmen, was in der Praxis bedeutete, dass Entwickler Branch-Namen manuell änderten, nachdem der Agent sie geöffnet hatte. Jetzt kann ein Bereichsadministrator eine Branch-Regel definieren, der Copilot automatisch folgt, wenn ein neuer Pull Request für ein Ticket geöffnet wird.

Neben Branch-Regeln sind auch benutzerdefinierte Anweisungen auf Bereichsebene verfügbar. Das sind Textleitfäden, die Copilot bei jeder Interaktion innerhalb dieses Jira-Bereichs respektiert — beispielsweise „immer einen Regressionstest einschließen”, „den internen Commit-Nachrichtenstil einhalten” oder „vor dem Merge das CHANGELOG prüfen”. Die Kombination aus benutzerdefinierten Agenten, Custom Fields, Branch-Regeln und Bereichsanweisungen macht Copilot zu einem konfigurierbaren Tool, das sich tatsächlich in ausgereifte Entwicklungsprozesse einfügen lässt.

Code-Review-Benachrichtigungen — die Schleife zum Projektmanagement schließen

Die letzte angekündigte Funktion ist möglicherweise die praktischste für nicht-technische Teammitglieder: Code-Review-Anfragen-Benachrichtigungen kommen direkt in Jira an. Wenn Copilot oder ein Entwickler einen Pull Request öffnet und einen Review anfordert, erscheint die Benachrichtigung im verknüpften Jira-Ticket. Ein Projektmanager oder Product Owner, der das Ticket in Jira verfolgt, sieht nun, dass ein PR geöffnet wurde, wer um einen Review gebeten wurde und in welchem Status er sich befindet — ohne zu GitHub wechseln zu müssen.

Diese Änderung schließt eine der häufigsten Lücken in Entwicklungsprozessen — die Trennung zwischen Aufgaben-Tools und Code-Tools. Bisher standen Tickets oft im Status „In Review”, ohne klare Sichtbarkeit darüber, wer genau den Review durchführt und wie lange — und Manager mussten GitHub manuell prüfen oder Entwickler anschreiben. Durch die Verknüpfung von Review-Benachrichtigungen mit Tickets signalisiert GitHub eine strategische Verschiebung in Richtung tiefer KI-Integration ins Projektmanagement, bei der Projekt-Tool und Code-Repository als einheitliches System agieren und ein KI-Agent gleichzeitig auf beiden Ebenen mitwirkt.