name: create-gh-issue description: GitHub-Issues mit gh issue create strukturiert anlegen, inklusive deutschem Markdown-Body, Emoji-Präfix im Titel und repo-nativen Labels aus gh label list. Verwenden, wenn Codex ein neues GitHub-Issue für Features oder User Stories, Bugs, Refactorings, technische Schulden, Research-Spikes, Dokumentationsaufgaben, Chores oder Epics entwerfen oder direkt erstellen soll.

GitHub Issue anlegen

Das Issue Ende-zu-Ende anlegen, außer der Nutzer verlangt ausdrücklich nur einen Entwurf.

Ablauf

1. Repository-Kontext ermitteln.
   • gh repo view --json nameWithOwner ausführen.
   • gh label list --limit 200 ausführen.
   • Bei spürbarem Duplikat-Risiko zusätzlich gh issue list --limit 200 --search "<keywords>" ausführen.
2. Issue-Typ klassifizieren.
   • Den passendsten Typ wählen: Feature, Bug, Technical Debt oder Refactor, Research oder Spike, Dokumentation, Epic oder Chore beziehungsweise Ops.
   • Nicht alles gewaltsam als User Story formulieren. Die Struktur soll dem Arbeitstyp folgen.
3. Issue-Body auf Deutsch formulieren.
   • references/issue-templates.md laden.
   • Kurzes, gut scanbares Markdown mit klaren Abschnitten und flachen Listen bevorzugen.
   • Lücken mit Annahmen oder offenen Fragen markieren, statt bei kleineren Unklarheiten zu blockieren.
4. Titel bauen.
   • Mit einem passenden Emoji beginnen.
   • Konkret, ergebnisorientiert und eigenständig verständlich formulieren.
   • Füllwörter wie Issue, Ticket, Problem mit oder einen Punkt am Ende vermeiden.
5. Labels aus der Live-Label-Liste auswählen.
   • Nur Labels verwenden, die gh label list tatsächlich liefert.
   • references/label-strategy.md laden.
   • In der Regel 2 bis 5 Labels setzen.
6. Issue erstellen.
   • Den Markdown-Body in eine temporäre Datei schreiben, um Shell-Escaping-Probleme zu vermeiden.
   • gh issue create mit --title, --body-file und je einem --label pro Label ausführen.
   • Bei reinem Entwurfswunsch hier stoppen.
7. Ergebnis zurückmelden.
   • Bei Erstellung Nummer und URL nennen.
   • Typ, gewählte Labels und relevante Annahmen kurz aufführen.

Qualitätsmaßstab

• Das Issue auf Deutsch schreiben, außer der Repository-Kontext verlangt klar etwas anderes.
• Den Titel mit genau einem passenden Emoji beginnen.
• Die Body-Struktur am Issue-Typ ausrichten statt eine Einheitsvorlage zu verwenden.
• Akzeptanzkriterien nur ergänzen, wenn das Issue tatsächlich umsetzbare Arbeit beschreibt.
• Keine Labels, Milestones oder Project-Felder erfinden.
• Die repo-native Taxonomie über generische GitHub-Gewohnheiten stellen.

Typauswahl

• Feature oder User Story: Für neuen Nutzer- oder Operator-Nutzen verwenden.
• Bug: Für defektes oder fehlendes Verhalten mit klarer Lücke zwischen Ist und Erwartung verwenden.
• Technical Debt oder Refactor: Für Wartbarkeit, Architektur, Bereinigung oder Konsistenz ohne primären Endnutzer-Scope verwenden.
• Research oder Spike: Für unbekannte Punkte verwenden, die vor der Umsetzung geklärt werden müssen.
• Dokumentation: Für ADRs, technische Doku, Prozessdoku oder fehlende Dokumentation verwenden.
• Epic: Für übergreifende Planung über mehrere Child-Issues oder Workstreams verwenden.
• Chore oder Ops: Für Tooling, CI, Konfiguration, Deployment, Dependencies oder Housekeeping verwenden.

Wenn zwei Typen plausibel wirken, den Typ wählen, der die Struktur des Issue-Bodys am stärksten verändert.

Kommandomuster

Eine temporäre Datei und explizite Labels verwenden:

tmp_body="$(mktemp /tmp/create-gh-issue.XXXXXX.md)"

cat > "$tmp_body" <<'EOF'
## Ziel
...
EOF

gh issue create \
  --title "✨ Beispieltitel" \
  --body-file "$tmp_body" \
  --label "enhancement" \
  --label "frontend"

rm -f "$tmp_body"

Referenzen

• Body-Vorlagen: references/issue-templates.md
• Label-Strategie: references/label-strategy.md