Ich habe mal gelesen, dass ein Satz KILLER sein kann. So ein Satz, bei dem du beim Lesen mittendrin innehältst, zurückspulst und ihn noch einmal liest – nur um zu verstehen, wie er gebaut ist.
Was das mit GitHub-Issues zu tun hat?
Alles.
Denn die meisten Issues, die in Repos landen, sind das Gegenteil von KILLER. Sie sind eher ... KILLE. Als in: RIP.
Titel: „Login kaputt“. Body: „Error 500“. Fertig. Viel Spaß.
Das Problem mit Issues ohne Kontext
Ein gutes Issue tut genau das, was ein Killer-Satz tut: Es packt eine komplette, präzise Beobachtung in eine Form, die beim Empfänger sofort Klick macht.
Ein schlechtes Issue ist der kleine Bruder davon. Es deutet an. Es hofft. Es verlässt sich darauf, dass irgendjemand (ein Kollege? ein Coding-Agent? Gott?) schon irgendwie verstehen wird, was gemeint ist.
Spoiler: Versteht keiner.
Und hier wird's spannend: Ein einziger, sorgfältig diktierter Satz kann den Unterschied ausmachen.
Ich meine damit nicht „AI, schreib mir ein Issue.“ Ich meine: Du sprichst deine eigenen Gedanken aus. Deine Beobachtung. Deinen Kontext. Und hältst ihn als Text fest.
Das sind zwei sehr unterschiedliche Dinge.
Diktat ist nicht gleich KI-Generierung
Klarmachen wir das kurz:
- Transkription = deine gesprochenen Worte werden zu Text.
- Korrektur/Glättung = Flüchtigkeitsfehler raus, Satzbau lesbar.
- Generierung = die KI erfindet Inhalte, die du nie gesagt hast.
Der Unterschied zwischen 1+2 und 3 ist gigantisch.
Wenn du ein Issue diktierst, willst du 1 und 2. Du willst deinen Gedanken – nur besser formuliert, als er in deinem Kopf herumschwirrt. Du willst nicht, dass ein Modell dein halbfertiges Hirngespinst zu einem vollständig erfundenen Hirngespinst ausbaut.
Wie du ein Issue diktieren kannst (in 5 Minuten)
Hier ist der praktische Teil. Schnapp dir das nächste nervige Ding aus deinem aktuellen Projekt.
Schritt 1: Erzähl es wie einer Kollegin am Kaffeeautomaten. Sprich laut, als würdest du es einer Person erklären, die das Projekt kennt, aber dieses Problem nicht. Was ist passiert? Wo? Was hast du erwartet?
Schritt 2: Bring die Teile in eine Reihenfolge. Ein brauchbares Issue hat eine einfache Struktur:
- Beobachtet: Was tatsächlich passiert
- Erwartet: Was hätte passieren sollen
- Kontext: Umgebung, Schritte, alles was beim Nachbau hilft
Schritt 3: Gib dem Agenten (oder Kollegen) ein Ziel. Nicht: „Fix das.“ Sondern: „Die Fehlermeldung soll verschwinden, wenn der Nutzer X tut.“
Schritt 4: Schneid es zurecht. Lies dein Diktat noch mal. Streich das Umherspringen. Lass die konkreten Details drin.
Das war's.
KILLER tip: Ein Issue ist keine Frage. „Weiß jemand, warum...?“ ist ein Hilferuf, kein Ticket. Diktier die Beobachtung, nicht die Verwirrung.
Ein (komplett fiktives) Beispiel
Nehmen wir an, du arbeitest an einer fiktiven App namens Schnack – einer Chat-App für Abteilungen, die zu viele Meetings haben. (Vollständig erfunden. Jede Ähnlichkeit mit echten Tools ist Zufall.)
Vorher – so wie Issues oft reinkommen:
Titel: Meldung kommt nicht an Body: Bei mir geht der Chat nicht??
Null brauchbar.
Nachher – diktiert, nachdenklich, konkret:
Titel: Nachricht aus dem mobilen Entwurf wird nach App-Neustart nicht gesendet Body: Beobachtet: Wenn ich eine Nachricht in Schnack tippe, die App minimiere und wieder öffne, steht die Nachricht noch im Eingabefeld, wird aber nicht versendet – auch nach erneutem Antippen des Senden-Buttons. Erwartet: Die Nachricht sollte entweder sofort gesendet oder als Entwurf markiert werden. Kontext: iOS 17, Schnack v2.4.1, passiert nur, wenn der Empfänger offline ist. Desktop-Version betroffen? Unklar. Ziel: Nach dem Neustart der App soll der Entwurf automatisch gesendet werden.
Zwei Versionen desselben Problems. Aber nur eine davon kann ein Coding-Agent – oder ein müder Kollege um 23 Uhr – tatsächlich bearbeiten.
Wo 
ins Bild kommt
ist professionelle Diktiersoftware für Deutsch und für Windows, macOS, Android und iPhone verfügbar.
Aber die Grundidee passt hier: Du sprichst deinen Gedanken aus, die App hält ihn fest, glättet die Sprache. Deine Beobachtung bleibt deine Beobachtung. Sie wird nur besser lesbar.
Das ist der Sweet Spot für Issues, Jira-Tickets oder jedes andere Ticket-System, in das du deinen Kopf entleeren willst.
Der eigentliche Punkt
GitHub-Issues fühlen sich oft an wie ein Pflichtprogramm. Etwas, das man irgendwie ausfüllen muss, weil das Repo sonst unaufgeräumt aussieht.
Aber ein Issue ist eigentlich ein Brief an die Zukunft. An dein Zukunfts-Ich. An einen Kollegen. An einen Agenten, der um 3 Uhr morgens deinen Fehler sucht.
Und Briefe an die Zukunft verdienen einen guten Satz.
Nicht zwanzig. Einer reicht.
(Aber er muss KILLER sein.)
Mehr dazu: Bugs diktieren: In sechs Feldern zu einem brauchbaren Agentenbriefing und Sprechdenken: Ideen diktieren und ordnen.
Beispiel: Aus „Login kaputt“ wird ein brauchbares Issue
Lena klickt auf „New Issue“ und hat eigentlich keine Lust, wieder einen langen Bericht zu tippen. Also spricht sie: „Titel: Login schlägt nach OAuth-Redirect in Safari fehl. Fehler 500. Schritte: 1. Neues Fenster öffnen, 2. GitHub-Login starten, 3. Redirect abwarten. Erwartet: Weiterleitung zum Dashboard. Tatsächlich: leere Seite mit Serverfehler.“ Der dynamische Modus erkennt ihre Struktur, glättet die gesprochenen Satzfragmente und formatiert daraus ein klares Issue. Was vorher nach zwei Zeilen aussah, ist jetzt ein präzises Briefing für das Team – oder für den Agenten um 3 Uhr nachts. Das spart nicht nur Zeit, sondern auch Nerven bei der Fehlersuche.
Ein gutes Issue beginnt mit einem guten Satz – und der entsteht oft schneller gesprochen als getippt. Wenn du deine Beobachtungen präziser festhalten willst, ohne dich in Formularfeldern zu verlieren, schau dir an: https://ohnetippen.de/ Dort siehst du, wie der dynamische Modus aus deinem gesprochenen Gedanken einen strukturierten Bug-Report macht, den dein Team wirklich nutzen kann.
