Aus einer Slack-Nachricht wird ein GitHub-Issue und ein Fix
Beschreiben Sie einen Bug in Slack in normaler Sprache. Zero schreibt das GitHub-Issue und weist es zu, und wenn die Ursache in einer Komponente liegt, öffnet es einen Pull Request mit dem Fix und einem Regressionstest für Ihr Review.
Was Zero liefert: von der Slack-Nachricht zum Fix im Review
Ein echter Durchlauf zum Öffnen und Lesen. Zero hat eine Woche Slack-Bug-Meldungen in GitHub-Issues verwandelt und, wo es die Ursache festmachen konnte, in Pull Requests mit Regressionstest. Der Bericht zeigt das Diff und sagt, warum drei behoben und die anderen vier nur gemeldet wurden. Beispieldaten in einem echten Ausgabeformat.
Agenten-Zusammenfassung. Zero hat 24 Nachrichten in #bugs, #support-escalation, #design-review und #product gelesen. Neun beschrieben einen Defekt, zwei hatten bereits ein offenes Issue, sieben wurden zu neuen GitHub-Issues. Drei davon bekamen zusätzlich einen Pull Request mit dem Fix und einem Regressionstest, verknüpft mit dem Issue und mit grüner CI. Die anderen vier wurden bewusst nur gemeldet: gemeinsame Datumslogik, ein Design-Token, eine Produktentscheidung und einer ohne Reproduktionsschritte. Gelesene Nachrichten: 24, 9 beschrieben einen Defekt. Angelegte Issues: 7, alle über Slack-Anzeigenamen zugewiesen. Fixes als Pull Request: 3, mit Regressionstest, 0 ungeprüft gemergt.
Vollständigen Bericht zu Meldungen und Fixes öffnenWas heißt es, ein GitHub-Issue aus Slack zu erstellen?
Ein GitHub-Issue aus Slack zu erstellen heißt, einen Bug, den jemand im Gespräch beschrieben hat, in ein sauber strukturiertes Issue in Ihrem Repository zu überführen, ohne dass jemand den Thread verlässt und alles noch einmal tippt. Der schwierige Teil war nie der API-Aufruf, sondern ein klarer Titel, die Trennung von Reproduktionsschritten und erwartetem Verhalten, die Wahl der Labels, die Priorität und die richtige Person. Diese Arbeit übernimmt Zero. Es liest die Slack-Nachricht und die Antworten drumherum, schreibt den Issue-Text, vergibt Labels und eine Priorität, die es begründen kann, ordnet die zuständige Person zu, indem es den Slack-Anzeigenamen mit einem GitHub-Handle abgleicht, und postet den Issue-Link zurück in denselben Thread, damit die meldende Person ihn sofort prüfen kann.
Warum Bug-Meldungen in Slack-Threads versanden
Jemand entdeckt während einer Demo einen Bug, oder ein Kunde meldet sich am Samstag. Der alte Weg ist lang: GitHub öffnen, das Repository suchen, ein sauberes Issue schreiben, jemanden zuweisen und dann warten, bis diese Person es aufnimmt, den Code liest und den Fix schreibt. Aus einer Zehn-Minuten-Änderung wird ein mehrtägiger Umlauf über drei Leute, und die Hälfte der Meldungen verlässt den Thread nie. Beschreiben Sie es stattdessen in Slack. Zero legt das Issue mit Reproduktionsschritten, Labels und Zuständigem an, und wo die Ursache begrenzt ist, öffnet es zusätzlich einen Pull Request mit Fix und Test. Sie prüfen und shippen.
So erstellt Zero ein GitHub-Issue aus Slack
Schritt 1: Tools verbinden
Schritt 2: Zero fragen
Schritt 3: Weiterführende Aktionen
Die Slack- und GitHub-Integrationen hinter dem Workflow
Das ist eine Slack-GitHub-Integration mit einem Agenten in der Mitte: Zero liest das Gespräch in Slack und schreibt den Eintrag in GitHub. Jeder Connector wird einzeln freigegeben und auf das beschränkt, was der Workflow tatsächlich nutzt. Einen Kanal zu lesen bedeutet also nie Schreibzugriff auf Ihre Repositories.
Slack-Integration: das Gespräch, das Zero liest
ErforderlichZero liest die Nachricht, auf die Sie es ansetzen, und die Antworten drumherum – Kontext, der erst drei Nachrichten später kam, landet damit trotzdem im Issue. Es übernimmt angehängte Screenshots, löst über den Anzeigenamen der meldenden Person die Zuständigkeit auf und behält den Nachrichten-Permalink, sodass jedes Issue dorthin zurückverweist, wo die Meldung begann. Geschrieben wird nur eines: eine Antwort im selben Thread mit Issue-Nummer und Link. Zero postet nicht in andere Kanäle, verschickt keine DMs und bearbeitet keine fremden Nachrichten.
GitHub-Integration: das Issue, das Zero anlegt
ErforderlichZero legt das Issue im genannten Repository an – mit einem Titel, der aus der Meldung geschrieben und nicht aus der Rohnachricht kopiert ist, mit Beschreibung, Reproduktionsschritten, erwartetem Verhalten und dem betroffenen Bereich, sofern der Thread einen nennt. Es vergibt die Labels, die Sie festlegen, oder leitet sie aus der Formulierung ab, setzt eine Priorität, die es erklärt, und weist die zuständige Person zu. Vor dem Anlegen durchsucht es offene Issues nach demselben Symptom und kommentiert bei einem Treffer das bestehende Issue. Kann es den Bug auch beheben, pusht es einen Branch und öffnet einen Pull Request, der das Issue schließt und um Review bittet. Der Schreibzugriff ist auf die freigegebenen Repositories beschränkt, und das ist die gesamte Oberfläche: Issues, Kommentare und Pull Requests, die zum Review geöffnet werden. Zero merged nicht, macht keine Force-Pushes und rührt keine Repository-Einstellungen an.
Zero vs. GitHub-App für Slack vs. Automatisierungsbaukasten
Ein Bug von einer Slack-Nachricht nach GitHub zu bringen hat drei Teile: die Meldung einfangen, ein brauchbares Issue schreiben und es an eine zuständige Person leiten. Die bestehenden Optionen lösen jeweils einen davon.
Die GitHub-App für Slack
Mit /github öffnet sich ein Dialog, in dem Sie Titel, Text, Labels und Zuständige selbst eintragen. Das spart den Weg in den Browser, aber Sie schreiben das Issue weiterhin selbst – und ein Formular mitten im Gespräch ist genau die Hürde, die zu „Ich melde das später“ führt.
Ein Automatisierungsbaukasten
Ein No-Code-Baukasten kann eine Slack-Nachricht bei einem Trigger in ein neues Issue kopieren. Kopiert wird die Rohnachricht, das Issue erbt also genau das, was die meldende Person zufällig getippt hat, und die Regeln für Labels, Priorität, Zuordnung und Duplikate müssen Sie pro Kanal selbst definieren und pflegen.
Zeros Slack-zu-GitHub-Workflow
Zero liest den Thread und schreibt das Issue: einen echten Titel, Reproduktionsschritte getrennt vom erwarteten Verhalten, Labels und eine Priorität, die es begründen kann, und eine zuständige Person, abgeglichen über den Anzeigenamen. Ist die Ursache auf eine Komponente begrenzt, macht es weiter und öffnet einen Pull Request mit dem Fix und einem Regressionstest, verknüpft mit dem Issue und bereit für Ihr Review. Es prüft zuerst offene Issues und kommentiert ein Duplikat statt eines anzulegen, und es antwortet im Thread mit dem Link.
Tipps für bessere Ergebnisse
Häufig gestellte Fragen
Wie erstellt man ein GitHub-Issue aus einer Slack-Nachricht?
Verbinden Sie Slack und GitHub mit Zero, beschreiben Sie den Bug im Kanal und erwähnen Sie Zero. Es liest die Nachricht und die umliegenden Antworten, schreibt ein Issue mit Titel, Reproduktionsschritten, erwartetem Verhalten, Labels und Priorität, legt es im genannten Repository an, weist es zu und antwortet im Thread mit Issue-Nummer und Link. Sie füllen kein Formular aus.
Worin unterscheidet sich das von der GitHub-App für Slack?
Die GitHub-App gibt Ihnen einen Dialog zum Ausfüllen: Titel, Text, Labels und Zuständige schreiben Sie selbst. Zero schreibt sie aus dem Gespräch, prüft vor dem Anlegen auf ein bestehendes Issue mit demselben Symptom und kann nach Zeitplan einen ganzen Kanal verarbeiten statt einer Nachricht nach der anderen.
Legt Zero nur das Issue an oder behebt es den Bug auch?
Beides, und es sagt Ihnen, was davon es getan hat und warum. Das Issue legt Zero immer an. Wenn der Thread oder der Code auf eine einzelne Komponente zeigt, das erwartete Verhalten eindeutig ist und sich zuerst ein fehlschlagender Test schreiben lässt, öffnet es zusätzlich einen Pull Request mit dem Fix und diesem Test, verknüpft ihn mit dem Issue und bittet um Review. Gemeinsame Utilities, Design-Tokens und alles, was eine Produktentscheidung braucht, werden gemeldet statt geändert. Zero merged nie; jeder Fix kommt als Pull Request, den Sie prüfen.
Kann Zero das Issue automatisch der richtigen Person zuweisen?
Ja. Zero gleicht den genannten Namen oder den Slack-Anzeigenamen der meldenden Person mit den GitHub-Handles im Repository ab und weist das Issue zu. Am verlässlichsten ist es, die zuständige Person in der Nachricht zu nennen; wird niemand genannt, greift Zero auf die Ownership des betroffenen Bereichs zurück und hält im Issue fest, wie es entschieden hat.
Wie verhindert Zero doppelte GitHub-Issues?
Bevor es etwas anlegt, durchsucht Zero offene Issues nach demselben Symptom, betroffenen Bereich und ähnlicher Formulierung. Bei einem Treffer hängt es den neuen Slack-Thread mit meldender Person und Zeitstempel als Kommentar an dieses Issue und antwortet in Slack mit dem bestehenden Link, statt ein zweites anzulegen.
Was passiert, wenn eine Bug-Meldung keine Reproduktionsschritte enthält?
Zero legt das Issue trotzdem an, damit die Meldung nicht verloren geht, kennzeichnet es als „braucht Reproduktionsschritte“ und fragt im Slack-Thread danach. Die Antwort landet dann in dem Thread, der ohnehin schon aus dem Issue verlinkt ist.
Kann Zero Bugs aus einem ganzen Kanal nach Zeitplan anlegen?
Ja. Setzen Sie Zero auf einen oder mehrere Kanäle an und geben Sie einen Zeitplan vor, zum Beispiel jeden Freitag um 16 Uhr. Es liest die Nachrichten der Woche, legt für jeden beschriebenen Defekt ein Issue an, kommentiert Duplikate, überspringt Feature-Wünsche und Rückfragen und berichtet, was es getan hat.
Funktioniert das auch mit Linear oder Jira statt GitHub?
Dieselbe Workflow-Form gilt für jeden Tracker, mit dem Zero verbunden ist; diese Seite beschreibt den GitHub-Weg über den GitHub-Connector. Linear wird genauso verbunden, und den Tracker nennen Sie in der Anweisung.
Melden Sie den nächsten Bug, ohne Slack zu verlassen
Verbinden Sie Slack und GitHub, beschreiben Sie den Bug so, wie Sie es einem Kollegen erzählen würden, und lassen Sie Zero das Issue schreiben und zuweisen. Ist die Ursache begrenzt, wartet auch schon der Pull Request auf Sie.