Strukturierte Ausgabe
Jeder Fehlerbericht folgt dieser Struktur:
- Titel — kurze Zusammenfassung (max. 8 Wörter)
- Was passiert — Beschreibung des Bug-Verhaltens
- Git-Kontext — aktueller Branch und letzte Änderungen
- Reproduktions-Schritte — aus der Beschreibung erkannt oder Platzhalter
- Erwartet vs. Tatsächlich — Vergleichsformat
Automatische Severity-Erkennung
Das System leitet die Severity aus deiner Beschreibung ab:
| Severity | Trigger-Wörter | Beispiel |
|---|---|---|
| Critical | crash, Datenverlust, Security, down, blockiert | „App crasht beim Start” |
| High | kaputt, schlägt fehl, geht nicht, Regression | „Login-Form schlägt bei Validierung fehl” |
| Medium | falsch, fehlerhaft, unerwartet, langsam | „API liefert falsche Daten” |
| Low | minor, kosmetisch, Tippfehler, Ausrichtung | „Button auf Mobile nicht ausgerichtet” |
Git-Integration
Ein einziger Bash-Aufruf erfasst:
- Aktuellen Branch-Namen
- Zusammenfassung der letzten Änderungen (letzte Commits)
- Geänderte Dateien, die zum Bug-Bereich passen
Dieser Kontext wandert automatisch in den Bug-Report, sodass die nächste Entwicklerin sofort sieht, was in der Nähe des Bugs geändert wurde.
Wann /note-bug nutzen
Nutze /note-bug statt /note, wenn du willst:
- Automatische Severity-Zuordnung
- Git-Kontext im Bericht
- Strukturiertes Format mit Reproduktions-Schritten
- Pink als Farb-Code zur schnellen Identifikation