Issue-Assistent¶

Sichere KI-Triage von Issues für GitHub. Eine KI, die nur liest, schreibt eine erste Analyse jedes neuen Issues, und ein Job ohne KI prüft sie, bevor irgendetwas gepostet wird. Labels, Duplikate, Erinnerungen und das Schließen behobener Issues mit dem Release gibt es dazu.

Loslegen Live ansehen Neuestes Release

Was er tut¶

Eine erste Analyse jedes neuen Issues

Eine KI, die nur liest, schreibt eine Zusammenfassung, die wahrscheinliche Ursache mit Links zum betroffenen Code und zur Dokumentation, was die meldende Person versuchen kann und was noch fehlt, in der Sprache der meldenden Person.
Labels

Labels aus den Issue-Formularen und aus der Analyse, jedes mit seinem Grund. Die Labels selbst sind Code, in .github/labels.toml.
Duplikate

Ein sicheres Duplikat eines Issues, das ein Maintainer geöffnet oder gesichtet hat, bekommt einen Hinweis und schließt drei Tage später, verlinkt mit dem Original, sofern niemand widerspricht. Andere werden zu Vorschlägen für den Maintainer.
Offene Fragen

Offene Fragen markieren ein Issue mit needs-info. Nach 15 Tagen bekommt die meldende Person eine Erinnerung, die den Tag nennt, an dem das Issue schließt, und nach 30 Tagen schließt es an diesem Tag. Eine Antwort, als Kommentar oder durch eine Bearbeitung, beendet das Warten und öffnet ein Issue wieder, das wegen einer fehlenden Antwort geschlossen wurde.
Vom Fix zum Release

Ein gemergter Pull Request mit Fixes #12 markiert das Issue mit fixed-in-next-release. Das Issue schließt mit einem Link zum Release, das den Fix ausliefert, und öffnet sich wieder, wenn das Problem bleibt.
Slash-Befehle

Ein Kommentar wie /assistant again, /assistant ask mit einer Frage, /assistant duplicate #12 oder /assistant mute steuert den Assistenten auf seinem Issue. Maintainer geben jeden Befehl; die meldende Person kann einmal um eine neue Analyse bitten.
Eine erste Antwort in den Discussions

Wo config.toml Kategorien nennt, etwa Q&A, bekommt eine neue Frage dort eine Antwort derselben KI mit denselben Prüfungen, nie als Antwort markiert; ein Fehler oder ein Funktionswunsch bekommt den Link zu einem Issue-Formular.
Befunde des Code-Scannings

Die Befunde, die .github/findings.toml akzeptiert, werden mit ihrem Grund verworfen, auch in einem Pull Request, wo ihre Review-Threads den Merge blockieren würden. Jeder andere offene Befund lässt einen Lauf scheitern, den ersten nach seinem Auftauchen, damit GitHub einmal darüber mailt, ohne öffentliches Issue.

Der Maintainer liest jedes Issue und hat das letzte Wort.

Im Einsatz bei HomeDarts for Autodarts, Player Switch for Autodarts, Paperless Unified Search, Paperless Sync, Repo Pager, dem Repository-Blueprint, der Website dennis-otto.github.io und dem Issue-Assistenten selbst. Live ansehen: erste Analysen eines Fehlers, bis in den Code verfolgt, eines Funktionswunsches und einer im Chinesisch des Meldenden, mit Zusammenfassung für den Maintainer, gepostet 2 min 32 s, 2 min 39 s und 3 min 7 s nach dem Öffnen des Issues.

Vorsichtig gebaut¶

Was der Assistent von sich aus tut, damit eine Antwort die Lage nie verschlimmert:

Spam bekommt keine Antwort

Ein Issue, das die KI für Werbung oder Unsinn hält, bekommt das Label invalid und keinen Kommentar, damit sein Autor keine Antwort bekommt. Schließen oder Löschen bleibt beim Maintainer.
Secrets und persönliche Daten

Ein Token, ein Schlüssel oder ein Passwort in einem Issue bekommt eine Warnung, es zu entfernen, auch aus dem Bearbeitungsverlauf, und es zu ersetzen. Persönliche Daten, etwa eine E-Mail-Adresse, bekommen einen Hinweis, wie man sie entfernt. Die KI wiederholt beides nie.
Sicherheitslücken bleiben privat

Eine mögliche Meldung einer Sicherheitslücke bekommt nur einen Verweis auf die private Meldung der Sicherheitsrichtlinie: keine Analyse, keine Fragen, keine Duplikate und einen festen Grund für ihre Labels.
Das Issue eines Maintainers bekommt nur Labels

Issues, die der Besitzer, ein Mitglied oder ein Collaborator öffnet, bekommen die Labels ihres Formulars, aber keine Analyse. Ein Lauf von Hand gibt trotzdem eine.
Das Gespräch bleibt beim Maintainer

Wenn die meldende Person seine Fragen beantwortet, fragt der Assistent höchstens zweimal nach, und nie, sobald der Maintainer sich am Gespräch beteiligt hat.
Nichts doppelt, nichts auf geschlossenen Issues

Eine Analyse wird nicht auf einem Issue gepostet, das inzwischen geschlossen oder gesperrt wurde, und eine Aufgabe, die ihren Kommentar schon hat, bekommt keinen zweiten, es sei denn, ein Maintainer startet sie von Hand mit dem Override.

Schnellstart¶

Installiere das neueste Release im Wurzelordner deines Repositorys, mit Python 3.12 oder neuer, PyYAML (pip install pyyaml) oder yq zum Lesen von YAML, git und der GitHub CLI:
```
tag="$(gh release view --repo Dennis-Otto/issue-assistant --json tagName --jq .tagName)"
dir="$(mktemp -d)"
git clone --quiet --depth 1 --branch "$tag" https://github.com/Dennis-Otto/issue-assistant "$dir" &&
  PYTHONPATH="$dir" python3 -P -m issue_assistant install --setup
```
install pinnt die Workflows auf Commit und Tag des Checkouts und schreibt die fehlenden Einstellungen und Vorlagen. --setup legt die Umgebung issue-assistant an, die nur der Standard-Branch nutzen darf, und fragt nach dem Secret der Engine: für Claude das Token eines Claude-Abos aus claude setup-token, CLAUDE_CODE_OAUTH_TOKEN, oder einen API-Schlüssel, ANTHROPIC_API_KEY. Für eine andere Engine setze zuerst ihren name in config.toml, wie Die Engine wechseln zeigt. Jeder Schritt prüft erst, ein zweiter Lauf ändert nur die Workflows.
Beschreibe das Projekt in .github/issue-assistant/project.md: was es tut, wo Code, Dokumentation, Fehlerbehebung und Changelog liegen, welche Versionen und Logs ein Fehlerbericht braucht, und wie Meldende angesprochen werden, wenn anders als in den Katalogen der Sprachen, etwa mit Sie. Die KI liest die Datei vor jeder Aufgabe. Passe dann die Vorlagen an Projekt, Labels und Issue-Formulare an, bis die Prüfung besteht:
```
PYTHONPATH="$dir" python3 -P -m issue_assistant check
```
Lass das Release behobene Issues schließen: Entferne unter Settings → General → Issues den Haken bei Auto-close issues with merged linked pull requests, damit ein behobenes Issue bis zum Release mit dem Fix offen bleibt. Dafür hat GitHub keine API. Ein Repository ohne Releases setzt stattdessen close_with_release = false in config.toml.

Schalte ein, worauf die Auswahl verlinkt, wenn install .github/ISSUE_TEMPLATE/config.yml geschrieben hat, da beide Links sonst ins Leere führen: Settings → General → Features → Discussions und Settings → Advanced Security → Private vulnerability reporting. Private Meldungen gibt es nur für öffentliche Repositorys, ein privates streicht ihn.

Schalte Updates ein durch Dependabot oder Renovate, falls sich noch keins von beiden um das Repository kümmert.
Probiere es aus: Committe die Einrichtung, pushe sie auf den Standard-Branch und gib unter Actions → Issue assistant → Run workflow die Nummer eines Issues ein. Ein Lauf von Hand startet als Probelauf, der nichts schreibt; die Zusammenfassung des Jobs Check and post the analysis (apply) zeigt die Labels und den Kommentar, die er posten würde:

Loslegen hat die Voraussetzungen eines Repositorys, jeden Schritt im Detail und wie du prüfst, dass er läuft; Configuration hat die Einstellungen. Die Action ist auch im GitHub Marketplace gelistet, wo ihr Schritt allein check ausführt: Die Workflows kommen von install oben.

Mehr erfahren¶

Loslegen

Was ein Repository braucht, die Einrichtung Schritt für Schritt und wie du prüfst, dass er läuft, bevor die erste Meldung kommt.

Loslegen
Funktionen

Eine Seite für alles, was er tut, von der ersten Analyse eines Issues bis zum Release, das seinen Fix ausliefert, jede mit einem Bild.

Funktionen
Wie er funktioniert

Die vier Workflows, die Aufgabe, die jedes Ereignis der KI gibt, und was die KI im Zaum hält.

How it works
Konfiguration und Referenz

Die Labels, die Einstellungen und die akzeptierten Befunde mit jedem Schlüssel, die Befehle, jede Eingabe und Ausgabe der Action und die Engines.

Configuration · Reference
Was Meldende sehen

Jeder Kommentar, den der Assistent postet, von der ersten Analyse bis zum Release, das den Fix ausliefert, auf Englisch und auf Deutsch.

Was Meldende sehen
Fragen und Fehlerbehebung

Was er kostet, welche Daten GitHub verlassen und was zu tun ist, wenn ein Issue keinen Kommentar bekommt.

FAQ
Im Vergleich mit anderen Werkzeugen

Die Beispiele der Actions von Claude Code und Gemini CLI, GitHubs AI assessment labeler, GitHub Agentic Workflows, copilot-triage, Copilots Automatisierungen für die Triage, actions/stale, Dosu und GitHubs Erkennung von Duplikaten, Zelle für Zelle mit Quellen.

Comparison
Architektur

Die Action, ihre Befehle und die vier Workflows, die sie in einem Repository aufrufen.

Architecture
Sicherheitsdesign

Was der Assistent schützt, wem er vertraut, die Bedrohungen mit ihren Gegenmaßnahmen und die Risiken, die bleiben.

Security design
Roadmap und Entscheidungen

Was der Assistent in den nächsten zwölf Monaten vorhat und was er nicht tun wird, und die Entscheidungen, die ihn prägen, jede mit ihren Gründen.

Roadmap · Decisions
Releases und Changelog

Jedes Release mit seinen Notes auf GitHub und die Änderungen jeder Version.

Releases · Changelog

Die Seiten der Anleitung, der Referenz, der Funktionen und der Sicherheit gibt es auf Englisch; diese Seite, Loslegen, die FAQ und Was Meldende sehen auch auf Deutsch.