Termin koordinieren
Business Case rechnen

Bug Report strukturieren

Aus der Fehlermeldung wird ein reproduzierbarer Bug Report

So funktioniert dieser Skill

  1. 1Fehler schildernAngaben oben ausfüllen, Beschreibung und Schritte im Chat nachreichen
  2. 2Fehler verstehenDen Kern des Problems von den Begleiterscheinungen trennen
  3. 3Titel und KurzfassungPrägnanter, suchbarer Titel und ein Satz zum Problem
  4. 4Reproduktion schreibenExakte, nummerierte Schritte, mit denen der Fehler auftritt
  5. 5Soll und Ist trennenErwartetes und tatsächliches Verhalten getrennt beschreiben
  6. 6Severity und WorkaroundSchweregrad einschätzen, Umgebung erfassen, Umgehung notieren
  7. 7Fertiger Bug ReportTitel, Schritte, Soll und Ist, Umgebung, Severity und Workaround
  8. 8Prüfen und einstellenAngaben gegenlesen und den Report ins Ticketsystem übernehmen

Prompt zum Kopieren

Trag deine Angaben ein oder klick auf einen Namen im Text. Alles bleibt in deinem Browser — wir sehen und speichern es nicht.

# BESCHREIBUNG
Wandelt Fehlerbeschreibungen in strukturierte, actionable Bug Reports um – mit Fokus auf Reproduzierbarkeit, klare Trennung von Expected vs. Actual und vollständige Umgebungsinformationen.

# EINGABE
- Fehlerbeschreibung (Was passiert? Was sollte passieren?) (Pflicht)
- Schritte zur Reproduktion (grob oder detailliert) (Pflicht)
- Umgebung, z.B. Browser, OS, Version: Umgebung (optional)
- Häufigkeit des Fehlers: Häufigkeit (optional)
- Auswirkung auf Nutzer oder Betrieb: Auswirkung (optional)
- Screenshots oder Logs (optional)

# AUSGABE
Strukturierter Bug Report:
1. Titel – Kurz, beschreibend, suchbar
2. Zusammenfassung – Ein Satz: Was ist das Problem?
3. Schritte zur Reproduktion – Nummerierte, exakte Schritte
4. Erwartetes Verhalten – Was sollte passieren?
5. Tatsächliches Verhalten – Was passiert stattdessen?
6. Umgebung – Browser, OS, Version, Gerät
7. Severity / Priority – Critical/Major/Minor/Trivial
8. Workaround – Umgehungslösung, falls vorhanden
9. Zusätzliche Informationen – Logs, Screenshots, Kontext

# KONTEXT
- Reproduzierbarkeit ist das wichtigste Kriterium
- Severity und Priority sind unterschiedliche Dimensionen
- Ein Bug Report pro Bug – nie mehrere zusammenfassen
- Screenshots und Logs sind extrem wertvoll

# ARBEITSANWEISUNG
## Schritt 1: Fehler verstehen
Aus der Nutzerbeschreibung den Kern des Problems identifizieren und von Symptomen trennen.

## Schritt 2: Titel und Zusammenfassung formulieren
Prägnanten, suchbaren Titel und eine Ein-Satz-Zusammenfassung schreiben.

## Schritt 3: Reproduktionsschritte erstellen
Exakte, nummerierte Schritte zur Reproduktion des Fehlers dokumentieren.

## Schritt 4: Expected vs. Actual dokumentieren
Erwartetes und tatsächliches Verhalten klar und getrennt beschreiben.

## Schritt 5: Severity und Workaround bewerten
Severity einschätzen (Critical/Major/Minor/Trivial), Umgebungsinformationen erfassen und Workaround dokumentieren, falls vorhanden.

# DEFINITION OF DONE
[ ] Titel ist kurz, beschreibend und suchbar
[ ] Reproduktionsschritte exakt und nummeriert
[ ] Expected vs. Actual klar getrennt
[ ] Umgebungsinformationen vollständig
[ ] Severity eingeschätzt
[ ] Nur ein Bug pro Report

# GESPRÄCHSSTART
Beginne das Gespräch mit genau diesen Sätzen:
Hey Dein Name! Ich baue deinen Bug Report — Umgebung: Umgebung. Häufigkeit: Häufigkeit. Auswirkung: Auswirkung. Schick mir nur noch die Fehlerbeschreibung und die Schritte, mit denen du den Fehler auslöst, dann steht er.

Was der Skill genau macht

Fehlermeldungen kommen so an, wie sie jemandem passiert sind: „geht nicht“, „stürzt ab“, „seit gestern komisch“. Wer sie beheben soll, fehlt dann alles — womit man den Fehler auslöst, was stattdessen hätte passieren sollen, auf welchem Gerät. Das Nachfragen kostet mehr Zeit als das Beheben.

Der Skill nimmt die Meldung, wie sie hereinkommt, und baut daraus einen vollständigen Report: einen Titel, unter dem man ihn wiederfindet, nummerierte Schritte zum Nachstellen, erwartetes und tatsächliches Verhalten sauber getrennt, die Umgebung, eine Einschätzung des Schweregrads und einen Workaround, falls es einen gibt. Was in der Meldung fehlte, wird nicht ausgedacht, sondern als Lücke benannt.

Gedacht für alle, die Fehler weitermelden, ohne selbst zu debuggen — Support, QA, Produkt. Am Ende hältst du einen Report in der Hand, den du nur noch gegenliest und ins Ticketsystem stellst.

So arbeitest du damit

  1. Das brauchst du.
  2. Angaben oben ausfüllen und Prompt kopieren —deine Angaben setzen sich beim Kopieren mit ein. Den Prompt selbst kannst du dabei frei ändern — kürzen, ergänzen, umschreiben.
  3. In dein Tool der Wahl einsetzen.
    1. Kopiere den Skill-Text oben über den Kopieren-Button.
    2. Klicke auf dein Profilbild und wähle „Skills“.
    3. Klicke auf „Skill erstellen“ und füge den kopierten Skill-Text als Anweisung ein.
    4. Passe bei Bedarf Eingaben, Ausgaben und das gewünschte Format an.
    5. Speichere den Skill — er ist sofort in allen Chats verfügbar.
    OpenAI Dokumentation: Skills in ChatGPT
  1. Report gegenlesen – Titel, Schritte und die Trennung von Soll und Ist gegen das halten, was du wirklich gesehen hast. Was in der Meldung fehlte, denkt sich der Skill nicht aus, sondern benennt es als Lücke; schließen kann sie nur, wer den Fehler vor Augen hatte.
  2. Severity abstimmen – die Einschätzung mit dem Entwicklungsteam abgleichen. Wie schwer der Fehler wiegt, steht im Report; wie dringend er drankommt, entscheidet ihr.
  3. Ins Ticketsystem stellen – Report in Jira, Linear oder GitHub Issues anlegen und Screenshots und Logs anhängen. Der Titel ist so gebaut, dass man den Bug später über die Suche wiederfindet.
  4. Zur Routine machen – jede Meldung aus Support oder QA hier durchschicken, bevor sie ins Backlog wandert. Dann kommen die Rückfragen einmal am Anfang statt dreimal später.

Alle Skills