create-github-issues

name: create-github-issues locale: de source_locale: en source_commit: 6f65f316 translator: claude translation_date: "2026-03-17" description: > Strukturierte GitHub-Issue-Erstellung aus Review-Befunden oder Aufgabenaufschluessen. Gruppiert zusammenhaengende Befunde in logische Issues, vergibt Labels und erzeugt Issues mit Standardvorlagen einschliesslich Zusammenfassung, Befunden und Abnahmekriterien. Konzipiert zum Verarbeiten von Ausgaben aus review-codebase oder aehnlichen Review-Skills. license: MIT allowed-tools: Read Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: git complexity: intermediate language: multi tags: git, github, project-management, issues, review, automation

GitHub-Issues erstellen

Strukturierte GitHub-Issue-Erstellung aus Review-Befunden oder Aufgabenaufschluessen. Wandelt eine Liste von Befunden (aus review-codebase, security-audit-codebase oder manueller Analyse) in wohlgeformte GitHub-Issues mit Labels, Abnahmekriterien und Querverweisen um.

Wann verwenden

Nach einem Codebase-Review das eine Befundtabelle erzeugt hat die nachverfolgt werden muss
Nach einer Planungssitzung die Arbeitspakete identifiziert hat die zu Issues werden sollen
Beim Umwandeln einer TODO-Liste oder eines Backlogs in nachverfolgbare GitHub-Issues
Beim Massenerstellen zusammenhaengender Issues die einheitliche Formatierung und Labels benoetigen

Eingaben

Erforderlich: findings — eine Liste von Eintraegen, jeder mindestens mit Titel und Beschreibung. Idealerweise auch: Schweregrad, betroffene Dateien und vorgeschlagene Labels
Optional:
- group_by — wie Befunde in Issues zusammengefasst werden: severity, file, theme (Standard: theme)
- label_prefix — Praefix fuer automatisch erstellte Labels (Standard: keines)
- create_labels — ob fehlende Labels erstellt werden sollen (Standard: true)
- dry_run — Issues in der Vorschau anzeigen ohne sie zu erstellen (Standard: false)

Vorgehensweise

Schritt 1: Labels vorbereiten

Sicherstellen dass alle benoetigten Labels im Repository vorhanden sind.

Vorhandene Labels auflisten: gh label list --limit 100
Von den Befunden benoetigte Labels identifizieren (aus Schweregrad, Phase oder expliziten Label-Feldern)
Schweregrade auf Labels abbilden falls noch nicht geschehen: critical, high-priority, medium-priority, low-priority
Phasen/Themen auf Labels abbilden: security, architecture, code-quality, accessibility, testing, performance
Wenn create_labels wahr ist, fehlende Labels erstellen: gh label create "name" --color "hex" --description "desc"
Einheitliche Farben verwenden: Rot fuer critical/security, Orange fuer high, Gelb fuer medium, Blau fuer architecture, Gruen fuer testing

Erwartet: Alle von Befunden referenzierten Labels existieren im Repository. Keine doppelten Labels erstellt.

Bei Fehler: Wenn gh-CLI nicht authentifiziert ist, den Benutzer anweisen gh auth login auszufuehren. Wenn Label-Erstellung verweigert wird (unzureichende Berechtigungen), ohne Label-Erstellung fortfahren und vermerken welche Labels fehlen.

Schritt 2: Befunde gruppieren

Zusammenhaengende Befunde in logische Issues buendeln um Issue-Zersiedelung zu vermeiden.

Wenn group_by theme ist: Befunde nach Phase oder Kategorie gruppieren (alle Sicherheitsbefunde -> 1-2 Issues, alle a11y -> 1 Issue)
Wenn group_by severity ist: Befunde nach Schweregrad gruppieren (alle CRITICAL -> 1 Issue, alle HIGH -> 1 Issue)
Wenn group_by file ist: Befunde nach primaer betroffener Datei gruppieren
Innerhalb jeder Gruppe Befunde nach Schweregrad ordnen (CRITICAL zuerst)
Wenn eine Gruppe mehr als 8 Befunde hat, in Untergruppen nach Unterthema aufteilen
Jede Gruppe wird zu einem GitHub-Issue

Erwartet: Eine Reihe von Issue-Gruppen, jede mit 1-8 zusammenhaengenden Befunden. Die Gesamtzahl der Issues sollte ueberschaubar sein (typischerweise 5-15 fuer ein vollstaendiges Codebase-Review).

Bei Fehler: Wenn Befunde keine Gruppierungsmetadaten haben, auf ein Issue pro Befund zurueckfallen. Das ist akzeptabel fuer kleine Befundmengen (< 10), erzeugt aber zu viele Issues fuer groessere Mengen.

Schritt 3: Issues formulieren

Jedes Issue mit einer Standardvorlage aufbauen.

Titel: [Schweregrad] Thema: Kurzbeschreibung — z.B. [HIGH] Security: innerHTML-Injektion in panel.js beseitigen

Inhalt Struktur:

## Zusammenfassung
Ein-Absatz-Ueberblick was dieses Issue behandelt und warum es wichtig ist.

## Befunde
1. **[SCHWEREGRAD]** Befundbeschreibung (`datei.js:zeile`) — kurze Erklaerung
2. **[SCHWEREGRAD]** Befundbeschreibung (`datei.js:zeile`) — kurze Erklaerung

## Abnahmekriterien
- [ ] Kriterium abgeleitet aus Befund 1
- [ ] Kriterium abgeleitet aus Befund 2
- [ ] Alle Aenderungen bestehen vorhandene Tests

## Kontext
Generiert aus Codebase-Review am JJJJ-MM-TT.
Verwandt: #issue_nummern (falls zutreffend)

Labels zuweisen: Schweregrad-Label + Themen-Label + benutzerdefinierte Labels
Wenn Befunde bestimmte Dateien referenzieren, sie im Inhalt erwaehnen (nicht als Zugewiesene)

Erwartet: Jedes Issue hat einen klaren Titel, nummerierte Befunde mit Schweregrad-Markierungen, Checkbox-Abnahmekriterien und passende Labels.

Bei Fehler: Wenn der Inhalt GitHubs Issue-Groessenlimit (65536 Zeichen) ueberschreitet, das Issue in Teile aufteilen und gegenseitig referenzieren.

Schritt 4: Issues erstellen

Die Issues mit dem gh-CLI erstellen und Ergebnisse berichten.

Wenn dry_run wahr ist, jeden Issue-Titel und Inhalt ausgeben ohne zu erstellen, dann stoppen

Fuer jedes formulierte Issue erstellen:

gh issue create --title "titel" --body "$(cat <<'EOF'
inhalt
EOF
)" --label "label1,label2"

Die URL jedes erstellten Issues festhalten
Nach Erstellung aller Issues eine Zusammenfassungstabelle ausgeben: #Nummer | Titel | Labels | Befundanzahl
Wenn Issues sequenziert werden sollen, Querverweise hinzufuegen: das erste Issue bearbeiten um "Blockiert von #X" oder "Siehe auch #Y" zu erwaehnen

Erwartet: Alle Issues erfolgreich erstellt. Eine Zusammenfassungstabelle mit Issue-Nummern und URLs wird ausgegeben.

Bei Fehler: Wenn ein einzelnes Issue nicht erstellt werden kann, den Fehler protokollieren und mit den verbleibenden Issues fortfahren. Fehlschlaege am Ende berichten. Haeufige Ursachen: Authentifizierung abgelaufen, Label nicht gefunden (wenn create_labels falsch war), Netzwerk-Timeout.

Validierung

Alle Befunde sind in mindestens einem Issue vertreten
Jedes Issue hat mindestens ein Label
Jedes Issue hat Checkbox-Abnahmekriterien
Keine doppelten Issues wurden erstellt (Titel gegen vorhandene offene Issues pruefen)
Issue-Anzahl ist angemessen fuer die Befundanzahl (nicht 1:1 fuer grosse Mengen)
Zusammenfassungstabelle wurde mit allen Issue-URLs ausgegeben

Haeufige Stolperfallen

Issue-Zersiedelung: Ein Issue pro Befund erstellen erzeugt 20+ Issues die schwer zu verwalten sind. Aggressiv gruppieren — 5-10 Issues aus einem vollstaendigen Review sind ideal
Fehlende Abnahmekriterien: Issues ohne Checkboxen koennen nicht als abgeschlossen verifiziert werden. Jeder Befund sollte auf mindestens eine Checkbox abgebildet werden
Label-Chaos: Zu viele Labels erstellen macht Filtern nutzlos. Bei Schweregrad + Thema bleiben, nicht Labels pro Befund
Veraltete Referenzen: Wenn Issues aus einem alten Review erstellt werden, vor dem Erstellen ueberpruefen ob die Befunde noch gelten. Der Code koennte sich geaendert haben
Trockenlauf vergessen: Fuer grosse Befundmengen immer zuerst mit dry_run: true vorschauen. Es ist viel leichter einen Plan zu bearbeiten als 15 falsche Issues zu schliessen