Bug-Triage-Entscheidungen automatisch in GitHub-Issues übernehmen mit SuperIntern MCP

Stellen Sie sich das Ende Ihres wöchentlichen Bug-Triage-Meetings vor.

Sie haben gerade 30 Minuten lang sorgfältig entschieden: "Das ist ein P1, kommt in den nächsten Milestone", "hier fehlt noch die Reproduktion, erstmal nur das Label", "das müsste längst behoben sein, bitte schließen." Dann endet das Meeting, und keine dieser Entscheidungen existiert irgendwo. Jemand öffnet GitHub, das Protokoll auf dem zweiten Bildschirm, sucht jedes Issue einzeln, tauscht Labels aus, setzt Milestones, weist Verantwortliche zu und schreibt (wenn Zeit bleibt, was nie der Fall ist) einen Kommentar mit der Begründung. An einem Tag mit 20 Issues kostet allein diese Übertragungsarbeit 30 Minuten. Und wird sie aufgeschoben, laufen Tracker und tatsächliche Beschlusslage tagelang auseinander, bis die nächste Triage mit der Frage beginnt: "Moment, hatten wir das nicht auf P1 gesetzt?"

In diesem Leitfaden verbinden wir den MCP von SuperIntern und den MCP-Server von GitHub mit Claude, sodass die Übernahme der Triage-Entscheidungen in GitHub-Issues zu einem einzigen Prompt wird, mit echten Prompt-Beispielen zum Kopieren.

⚠️ Dieser Artikel wurde auf Grundlage öffentlich zugänglicher Informationen und Nutzerfeedbacks mit Stand August 2026 unabhängig zusammengestellt.

Inhalt

• Das Ziel heute: Vorher / Nachher
• So funktioniert es: Drei Rollen
• Setup
• Demo 1: Triage-Entscheidungen in einem Durchgang übernehmen
• Demo 2: Mündlich gemeldete Bugs mit Duplikatprüfung anlegen
• Demo 3: Wöchentlicher Abgleich von Meetings und Tracker
• Tipps für den Alltag
• Über GitHub hinaus: Dasselbe Muster anderswo
• Häufige Fragen

Das Ziel heute: Vorher / Nachher

Vorher: Nach der Triage wechselt jemand zwischen Protokoll und GitHub hin und her, öffnet Issue für Issue und setzt Labels, Milestones und Zuständige von Hand. Für die Begründung bleibt keine Zeit, und drei Wochen später weiß niemand mehr, warum ein Issue P1 wurde.

Nachher: Nach dem Meeting bitten Sie Claude einmal: "Übernimm die heutigen Triage-Entscheidungen in GitHub." Claude liest die Entscheidungen aus dem Protokoll, findet die passenden Issues, aktualisiert Labels, Milestones und Zuständige und hinterlässt auf jedem Issue einen Kommentar mit Begründung und Quellen-Meeting.

Zum Hintergrund: SuperIntern ist eine botless Desktop-App (kein Bot betritt Ihre Meetings), die Transkripte und KI-Protokolle automatisch erfasst. In der Triage diskutieren Sie einfach wie immer. Die Entscheidungen sammeln sich von selbst als Meeting-Daten an; zu automatisieren bleibt nur noch die Übertragung nach GitHub.

So funktioniert es: Drei Rollen

Drei Beteiligte machen das Ganze möglich.

MCP (Model Context Protocol) ist ein offener Standard, um KI-Assistenten sicher mit externen Tools zu verbinden. Der MCP von SuperIntern stellt Ihre Meeting-Daten dem KI-Client nur lesend bereit, während GitHubs offizieller MCP-Server das Suchen, Anlegen und Aktualisieren von Issues übernimmt. Es ist also Claude, der Ihre GitHub-Issues bearbeitet, nicht SuperIntern. Ihre SuperIntern-Daten können über MCP niemals verändert werden, die KI sieht nur Meetings, auf die Sie selbst Zugriff haben, und alle Schreibvorgänge passieren auf der GitHub-Seite. Sie können das ohne Risiko für Ihre Protokolle ausprobieren.

Setup

Sie brauchen genau zwei Verbindungen. Die SuperIntern-Seite kommt ohne API-Schlüssel aus; ein Login im Browser genügt. Bei GitHub melden Sie sich je nach Client per OAuth im Browser an oder verwenden ein Personal Access Token.

1. SuperIntern MCP mit Claude verbinden

Öffnen Sie in Claude die Einstellungen, dann Konnektoren, wählen Sie "Benutzerdefinierten Konnektor hinzufügen" und registrieren Sie die Verbindungs-URL.

https://mcp.app.super-intern.com/mcp

Ein SuperIntern-Login-Fenster öffnet sich; anmelden, bestätigen, fertig. Die Planvoraussetzungen (Plus oder höher für persönliche Workspaces, Admin-Freischaltung bei Enterprise) sowie die Schritte für Claude Code, Cursor und andere Clients finden Sie in unserer MCP-Setup-Anleitung.

2. Den GitHub-MCP-Server mit Claude verbinden

GitHub stellt einen offiziellen MCP-Server bereit. Beachten Sie: Der Remote-Server (https://api.githubcopilot.com/mcp/) setzt OAuth über eine registrierte GitHub App voraus, was Claudes Ablauf "Benutzerdefinierten Konnektor hinzufügen" derzeit nicht unterstützt. Verbinden Sie sich stattdessen über einen der Wege aus der offiziellen Installationsanleitung:

• Claude Desktop: Fügen Sie den lokalen GitHub-MCP-Server (Docker) in die claude_desktop_config.json ein. Beim ersten Start öffnet sich ein Browser-Login bei GitHub (OAuth), ein Token ist nicht nötig
• Claude Code: Verbinden Sie sich mit dem Remote-Server per Personal Access Token:

claude mcp add-json github '{"type":"http","url":"https://api.githubcopilot.com/mcp","headers":{"Authorization":"Bearer YOUR_GITHUB_PAT"}}'

Das genaue Konfigurations-JSON für Claude Desktop sowie die Schritte für Cursor und andere Clients stehen in der offiziellen Installationsanleitung.

Unsicher, ob beides funktioniert? Fragen Sie zuerst:

Zeig mir meine 3 letzten SuperIntern-Meetings und 3 offene Issues in nanohuman/app

Kommt beides zurück, sind Sie startklar.

Demo 1: Triage-Entscheidungen in einem Durchgang übernehmen

Der häufigste Einsatz ist die Sammelübernahme direkt nach der Triage. Triage-Entscheidungen ändern meist den Zustand bestehender Issues; der Kern ist also, das richtige Issue zu identifizieren und zu aktualisieren, nicht neue anzulegen.

Hol das KI-Protokoll des heutigen Meetings "Bug-Triage" und extrahiere die Entscheidung zu jedem Issue.
Finde die passenden Issues in nanohuman/app anhand von Nummer oder Beschreibung.
Setze die beschlossenen Prioritäts-Labels und Milestones und weise die vereinbarten Verantwortlichen zu.
Ergänze auf jedem Issue einen Kommentar mit der Begründung und dem Namen des Quellen-Meetings.
Bei Issues, die wir schließen wollten: erst die Begründung kommentieren, dann schließen.

Claude liest das Protokoll, durchsucht GitHub und meldet zurück:

8 Issues aktualisiert.\

• #482 "Suchergebnisse werden beim Tab-Wechsel zurückgesetzt": P1 und Milestone v0.14 gesetzt, zugewiesen an Sara. Priorisiert, weil drei Kundenkonten den Fehler reproduziert haben\
• #475 "Zeichensalat im CSV-Export": P2 gesetzt, wartet auf Reproduktionsschritte\
• #468 "Tooltip-Versatz in den Einstellungen": P3 und good first issue gesetzt\
• #441 "Layout-Fehler im alten Dashboard": in v0.13 als behoben bestätigt, Begründung kommentiert und geschlossen
  Jedes Issue hat jetzt einen Kommentar mit der Quelle "Bug-Triage-Meeting (14. Aug.)".

Das entscheidende Detail: Es sind nicht nur Labels und Milestones, die Begründung landet als Kommentar. Wer ein Issue öffnet, sieht, wann und warum es seine Priorität bekommen hat. Drei Wochen später muss niemand mehr fragen: "Warum ist das P1?" Und weil SuperInterns KI-Protokolle Entscheidungen sauber strukturieren, bleibt die Extraktion zuverlässig.

Demo 2: Mündlich gemeldete Bugs mit Duplikatprüfung anlegen

Triage-Meetings und Dailys sind voller mündlicher Bug-Meldungen: "Ach übrigens, der Export-Screen macht da so eine komische Sache." Schreibt niemand sofort ein Issue, versinkt die Meldung im Protokoll und stirbt dort.

Hol das Transkript des heutigen "Engineering-Daily" und liste jede mündliche Erwähnung eines Bugs oder Fehlers auf.
Gleiche sie mit den bestehenden Issues in nanohuman/app ab.
Wo es bereits ein Issue gibt, ergänze den neuen Kontext aus dem Meeting als Kommentar.
Nur für Meldungen, die nirgends existieren, lege neue Issues mit Reproduktionsschritten an.
Formuliere Titel, die das Symptom beschreiben, und nenne im Text die meldende Person und das Quellen-Meeting.

Beachten Sie: Dieser Prompt nutzt das Transkript, nicht das Protokoll. Mündliche Bug-Meldungen fallen oft aus der Zusammenfassung heraus, aber das Transkript bewahrt auch die beiläufige Bemerkung. Die Bitte um "Reproduktionsschritte" bringt Claude dazu, den mündlich beschriebenen Ablauf in eine echte Repro-Liste zu übersetzen, was Ihnen die spätere Rückfrage erspart.

Demo 3: Wöchentlicher Abgleich von Meetings und Tracker

Im Meeting hieß es "beheben wir", aber das Issue hat sich nie bewegt. Oder ein Issue, das alle schließen wollten, ist noch offen. Einmal pro Woche decken Sie diese Abweichung zwischen Beschlusslage und GitHub-Zustand auf. Der Blick über mehrere Meetings hinweg ist genau die Stärke von MCP.

Hol alle Meetings dieser Woche im Projekt "Produktteam" und finde jede Stelle,
an der ein GitHub-Issue erwähnt oder eine Entscheidung dazu getroffen wurde.
Vergleiche mit dem aktuellen Zustand der Issues in nanohuman/app.
Zeig mir eine Tabelle der Issues, bei denen die Meeting-Entscheidung noch nicht umgesetzt ist,
mit Meeting-Name, Entscheidung und aktuellem Zustand. Noch nichts anwenden.

Dieser Prompt verlangt bewusst erst eine Tabelle, keine Änderungen. Der Wochenabgleich wirft ein weites Netz aus und erwischt auch beiläufige Bemerkungen; die Tabelle durchzusehen und "übernimm diese drei" zu antworten, ist der sichere Zweischritt. Jeden Freitag ausgeführt, bleibt Ihr Tracker ein ehrliches Abbild dessen, was das Team wirklich entschieden hat.

Tipps für den Alltag

Das Repository ausdrücklich nennen. "In nanohuman/app" im Prompt verhindert in Organisationen mit vielen Repositories zuverlässig Verwechslungen. Verankern Sie Ihre üblichen Repo-Namen in einem gespeicherten Prompt.

Mit einem Probelauf beginnen. Hängen Sie in den ersten Sitzungen "zeig mir die geplanten Änderungen, bevor du sie anwendest" an. Sobald Sie gesehen haben, wie gut Claude Formulierungen aus dem Meeting ("dieser Such-Bug") echten Issues zuordnet, können Sie auf die direkte Übernahme umstellen.

Issue-Nummern laut aussprechen. Teams, die in der Triage "#482" sagen, bringen die Nummern ins Transkript, und Claudes Zuordnung wird nahezu perfekt. Wer während der Triage die Issue-Liste am Bildschirm teilt, macht das vermutlich ohnehin.

Das Label-Schema im Prompt festschreiben. "Priorität als P1/P2/P3, Typ als bug/enhancement" verhindert, dass versehentlich Labels entstehen, die es in Ihrem Schema nicht gibt.

Eigennamen auf der SuperIntern-Seite verbessern. Je genauer Feature- und Screen-Namen transkribiert werden, desto besser die Issue-Zuordnung. Häufige Feature-Namen und Teamkollegen ins benutzerdefinierte Wörterbuch von SuperIntern einzutragen, lohnt die zwei Minuten.

Geschrieben wird nur auf GitHub. Ihre SuperIntern-Daten werden über MCP nie verändert. Landet eine Übernahme falsch, korrigieren Sie sie auf der GitHub-Seite; das Original-Protokoll bleibt die verlässliche Quelle. GitHub führt zudem auf jedem Issue seine eigene Änderungshistorie, was auch für Audits beruhigend ist.

Über GitHub hinaus: Dasselbe Muster anderswo

Das Muster "SuperIntern MCP liefert die Daten, Claude urteilt, ein anderes Tool empfängt die Aktion" reicht weit über GitHub hinaus.

• Andere Tracker: Teams mit Linear folgen fast demselben Ablauf in unserem Linear-Praxisleitfaden
• Slack-Updates: Teilen Sie die Triage-Zusammenfassung direkt im Dev-Kanal. Siehe den Slack-Praxisleitfaden
• Bis zum Code: Verbinden Sie SuperIntern MCP mit Claude Code und kommen Sie von "dieser P1 aus der Triage" zu einem Fix, der die Meeting-Diskussion kennt. Unser Spec-to-Code-Artikel zeigt wie

Wir stellen diese Kombinationen weiterhin eine nach der anderen vor, immer mit echten Prompts.

Häufige Fragen

F: Ist SuperIntern MCP im kostenlosen Tarif verfügbar?
A: Nein. Persönliche Workspaces benötigen den Plus-Tarif oder höher. Team-Workspaces können ihn direkt nutzen, und bei Enterprise muss ein Admin zuerst "MCP-Zugriff" in den Workspace-Einstellungen aktivieren.

F: Schreibt SuperIntern direkt in meine GitHub-Issues?
A: Nein. Alle Issue-Änderungen, Neuanlagen und Kommentare führt Claude über den GitHub-MCP-Server aus. SuperIntern MCP stellt Meeting-Daten nur lesend bereit; SuperIntern selbst schreibt nie in externe Tools.

F: Kann die KI meine Protokolle oder Transkripte verändern?
A: Nein. Alle Tools von SuperIntern MCP sind nur lesend; es gibt keine Operationen zum Erstellen, Bearbeiten oder Löschen. Schreibvorgänge passieren ausschließlich auf der GitHub-Seite.

F: Funktioniert das mit privaten Repositories?
A: Ja. Der GitHub-MCP-Server handelt mit den Berechtigungen der verwendeten Zugangsdaten (OAuth-Login oder Personal Access Token), deckt also genau die Repositories ab, auf die diese Zugangsdaten Zugriff haben, und keines darüber hinaus.

F: Was, wenn massenhaft falsche Änderungen angewendet werden?
A: Nutzen Sie die Probelauf-Gewohnheit aus den Tipps: "Zeig mir die geplanten Änderungen, bevor du sie anwendest" schafft einen menschlichen Kontrollpunkt. Selbst wenn etwas falsch landet, lässt sich der Zustand über die Issue-Historie von GitHub zurücksetzen, und Ihre SuperIntern-Daten bleiben unberührt.

F: Kann ich einen anderen KI-Client als Claude verwenden?
A: Sowohl SuperIntern MCP als auch der GitHub-MCP-Server funktionieren mit MCP-fähigen Clients wie Claude Code, Codex und Cursor. Jeder Client, der sich mit beiden verbinden kann, führt die Prompts dieses Artikels nahezu unverändert aus.

Der Wert eines Triage-Meetings liegt im Entscheiden, nicht im anschließenden Abtippen der Entscheidungen in GitHub. Behalten Sie das Entscheiden; geben Sie das Abtippen ab.

SuperIntern kostenlos testen