mr-feedback

Was macht mr-feedback?

Holen Sie sich einen GitLab-Merge-Request, bewerten Sie, wie bereit er für eine Überprüfung ist, und schreiben Sie einen Feedback-Bericht in eine neue Markdown-Datei, die direkt in eine MR-Notiz kopiert werden kann.

Was zu tun ist

Beurteilen Sie die Review-Bereitschaft. Prüfen Sie, ob der MR den Kontext, die Klarheit des Umfangs, Testanweisungen und Reviewer-Hinweise enthält, die es einem Reviewer ermöglichen, ihn effizient aufzunehmen.

Warum

Ein gut vorbereiteter MR signalisiert Sorgfalt und wird schneller und besser überprüft. Der Bericht soll einen guten MR anerkennen und einem schwächeren konkrete, ermutigende Schritte geben, um seine Bereitschaft zu erhöhen.

Was nicht zu tun ist

Überprüfen oder kritisieren Sie nicht den Code selbst und schlagen Sie keine Code-/Logikänderungen vor

Präferenzen

Lesen Sie vor allem anderen reference/preferences.md (relativ zu diesem Skill). Es ist die maßgebliche Quelle für alle konfigurierbaren Verhaltensweisen – Ausgabesprache, Ton, Abrufmethode, erlaubte Tools und Ausgabepfad. Diese SKILL.md wiederholt diese Werte nicht; lesen Sie sie immer aus der Präferenzdatei.

Rangfolge, von höchster zu niedrigster:

1. Eine explizite Anweisung in der aktuellen Anfrage des Benutzers (z.B. „dieses Mal auf Portugiesisch schreiben“).
2. reference/preferences.md.
3. Anweisungen in diesem Skill.

Eingaben

Der Benutzer gibt an:

• Eine vollständige MR-URL: https://gitlab.com/<gruppe>/<untergruppe>/<projekt>/-/merge_requests/<iid>
• Einen Projektpfad + MR iid: gruppe/untergruppe/projekt + 42

Parsen Sie aus der URL:

• project_id = der Pfad zwischen dem Host und /-/merge_requests/ (URL-kodieren als gruppe%2Funtergruppe%2Fprojekt beim Aufruf von Tools)
• mergeRequestIid = die Zahl nach /-/merge_requests/

Wenn etwas fehlt oder mehrdeutig ist, fragen Sie vor dem Abrufen nach.

Arbeitsablauf

Verwenden Sie die Methode und die Tools, die in reference/preferences.md deklariert sind. Die folgenden Schritte geben an, welche Informationen zu sammeln und warum, nicht welches Tool aufzurufen ist – wählen Sie das passende Tool aus den Präferenzen für jeden Schritt aus.

1. MR-Metadaten – Titel, Beschreibung, Autor, Status, Quell-/Ziel-Branch, Entwurfsflag, Labels, Meilenstein, Genehmigungen, Merge-Status.
2. Liste der geänderten Dateien – Pfade + Hinzufügungs-/Löschzahlen; gibt Umfang/Größe ohne jeden Diff zu laden.
3. Beispiel-Diffs zur Bestätigung, dass die Beschreibung der Realität entspricht – in Batches von 3-5 Dateien. Verwenden Sie dies nur, um den Umfang zu überprüfen und ob Tests betroffen waren – nicht um Code zu kritisieren. Überspringen Sie Lockfiles, generierte Dateien und reine Umbenennungen; sampeln Sie, wenn der MR sehr groß ist.
4. Commits – verwenden Sie die bereits in den MR-Metadaten enthaltene Commit-Zusammenfassung (Schritt 1) für Hygiene/Atomizitätssignal (Anzahl der Commits / Zusammenfassung der Hinzufügungen).
5. CI-Status – letzter Pipeline-Status für den MR (bestanden/fehlgeschlagen/keiner).
6. Bewerten Sie anhand der Rubrik in reference/rubric.md.
7. Schreiben Sie den Bericht in eine neue Datei (siehe Ausgabe) unter Verwendung von reference/report-template.md.
8. Teilen Sie dem Benutzer den Dateipfad mit und bieten Sie an, Ton/Länge zu verfeinern, bevor er sie kopiert/einfügt.

Lesen Sie reference/rubric.md vor der Bewertung und reference/report-template.md vor dem Schreiben. Erfinden Sie keine Daten – wenn ein Abruf für eine Kategorie nichts zurückgibt (z.B. keine Pipeline), markieren Sie es als „nicht verfügbar“ anstatt zu raten.

Jede Rubrik-Kategorie enthält einen Grund, der erklärt, warum sie für den Autor wichtig ist. Wenn Sie eine Lücke in „Um die Bereitschaft zu erhöhen“ melden, fügen Sie immer warum es wichtig ist für den Autor hinzu – damit das Feedback den Zweck hinter jeder Anfrage erklärt, nicht nur die Anfrage selbst.

Kopieren Sie den Kategorie-Grund nicht wörtlich. Der Grund ist Hintergrund, der die gesamte Kategorie abdeckt; schreiben Sie ihn um, damit er zum genauen gefundenen Problem passt. Beziehen Sie sich nur auf das spezifische Problem und erwähnen Sie niemals Aspekte der Kategorie, die in Ordnung sind. Wenn der Branch zum Beispiel hinter master zurück ist, aber die Pipeline grün ist, erklären Sie, warum das Zurücksein hinter master wichtig ist – erwähnen Sie die Pipeline überhaupt nicht, da sie bestanden hat. Das „Warum es wichtig ist“ muss für die spezifische Lücke dieses MRs wahr sein, nicht eine allgemeine Aussage über die Kategorie.

Ausgabe

Schreiben Sie in den in reference/preferences.md deklarierten Ausgabepfad, lösen Sie dessen Platzhalter auf und erstellen Sie alle benötigten Ordner.

Leitplanken

• Nur lesen. Dieser Skill erstellt niemals Notizen, genehmigt oder ändert den MR. Er schreibt nur eine lokale Markdown-Datei. Der Benutzer entscheidet, ob er sie einfügt.
• Fügen Sie keine Geheimnisse/Tokens, die in Diffs erscheinen könnten, in den Bericht ein.
• Wenn der MR ein Entwurf ist oder noch keinen Diff hat, können Sie ihn trotzdem bewerten und den Bericht erstellen, aber stellen Sie sicher, dass Sie dies explizit angeben.