nicolasroy-fr/mr-description

MR / PR Titel und Beschreibung

Alles, was in den MR/PR (Titel, Beschreibung) geschrieben wird, und jede Frage, die dem Benutzer gestellt wird, ist auf Französisch. Sage « MR » für GitLab und « PR » für GitHub.

Argumente (optional)

Empfangener Inhalt: $ARGUMENTS

Argument	Ziel
https://github.com/<owner>/<repo>/pull/<n>	GitHub PR
https://<host>/<group>/<repo>/-/merge_requests/<iid>	GitLab MR
#<n> / <n> allein	MR oder PR des aktuellen Repos: Plattform aus git remote -v ableiten
nichts	MR oder PR des aktuellen Branches: Plattform aus git remote -v ableiten

Wenn die Plattform nicht abgeleitet werden kann (selbst gehosteter Host, mehrere Remotes), nachfragen.

Harte Regeln

• Den MR/PR niemals ohne explizite Bestätigung des Titels und der Beschreibung ändern, dann eine separate explizite Genehmigung zum Senden einholen.
• Keine Fakten erfinden (Kartennummer, Kontext, Tests). Nachfragen oder weglassen.
• Keine Erwähnung von Claude im MR/PR-Inhalt.

Schritte

1. MR/PR identifizieren und abrufen

Das Ziel aus den Argumenten auflösen (Tabelle oben), dann die entsprechende Referenz vor dem Ausführen eines Befehls lesen:

• references/sources/gitlab.md
• references/sources/github.md

Wenn die CLI (glab / gh) fehlt oder nicht authentifiziert ist, den Benutzer informieren (! glab auth login / ! gh auth login vorschlagen), anstatt zu raten.

Aktuellen Titel, aktuelle Beschreibung, Quell-/Zielbranches und die Änderungen (Diff und Commit-Liste) gemäß der Referenz abrufen. Den Diff lesen, um den tatsächlichen Inhalt des MR/PR zu verstehen.

Bestimmen:

• Repo-Name: letztes Segment des Projektpfads, in GROSSBUCHSTABEN.
• Kartennummer: im vorhandenen Titel, Branchnamen, Commits und Beschreibung suchen (z. B. ABC-123, #123). Wenn keine gefunden wird, einmal nachfragen; wenn der Benutzer sagt, dass es keine gibt, die Klammern komplett weglassen.

2. Titel

Muster (auf beiden Plattformen gleich):

[<Kartennummer>] <REPO-NAME> - <Betreff> - kurze Beschreibung

• Klammern und Kartennummer nur, wenn eine Karte existiert.
• <REPO-NAME>: Repo-Name in Großbuchstaben.
• <Betreff>: immer den Benutzer fragen (einen Vorschlag aus dem Diff ableiten und als Standardoption anbieten, aber nicht alleine entscheiden). Wenn der aktuelle Titel bereits einen Betreff enthält, vorschlagen, ihn zu behalten.
• Kurze Beschreibung: prägnant, auf Französisch, kleingeschriebener Anfang, kein Punkt am Ende.
• Wenn ein vorhandener Titel bereits gut geformt ist und noch zum Inhalt des MR/PR passt, ihn behalten und dies mitteilen. Wenn er nicht mehr passt, einen geänderten vorschlagen und das Vorher/Nachher zeigen.

3. Beschreibung

Struktur (Markdown, auf Französisch):

# Description

<Ein oder zwei Sätze, die das Ziel des MR/PR zusammenfassen.>

## Contexte

<Aktueller Stand des Codes bei einer Änderung; erwartetes Ergebnis: Einschränkungen, Ziele, Architektur, Strategie.>

## Changements

- <Änderung auf hoher Ebene>
- ...

## Tests

- <Geschriebene Tests oder durchgeführte manuelle Tests>

Abschnittsanleitung:

• Description: 1–2 Sätze zum Ziel. Einen Entwurf vorschlagen und den Benutzer bitten, ihn zu validieren oder zu korrigieren.
• Contexte: beschreibt den Zustand vor (bei einer Änderung) und das erwartete Ergebnis (Einschränkungen, Ziele, Architektur, Strategie). Punkt für Punkt vorgehen: jeden Punkt dem Benutzer zur Validierung vorlegen und eine Frage stellen, wann immer ein Punkt geklärt werden könnte (warum diese Wahl, welche Einschränkung, welche abgelehnte Alternative). Nicht mit unvalidierten Annahmen fortfahren.
• Changements: nur Liste auf hoher Ebene. Nur dann ins Detail gehen, wenn die Änderung genau dieses Detail betrifft oder es zum Verständnis des gesamten MR/PR wesentlich ist.
• Tests: grobe Angaben zu den geschriebenen automatisierten Tests (abgedeckte Dateien/Bereiche) und den durchgeführten manuellen Tests. Wenn unbekannt, nachfragen; niemals Tests behaupten, die nicht durchgeführt wurden.

Zusammenhängende Fragen mit AskUserQuestion bündeln (Betreff, Kartennummer, Kontextpunkte) anstatt viele Roundtrips zu machen.

4. Vorhandene Beschreibung (Aktualisierungsfall)

Wenn der MR/PR bereits eine Beschreibung hat:

• Zeigen, was sich ändern würde, Abschnitt für Abschnitt (hinzugefügt / geändert / entfernt), nicht nur den neuen Text.
• Nützliche Inhalte, die der Benutzer geschrieben hat, erhalten (Links, Screenshots, Checklisten, Vorlagenabschnitte, Schlüsselwörter zum Schließen wie Closes #12); erwähnen, falls etwas entfernt würde.
• Vor dem Fortfahren um Bestätigung der Änderungen bitten.

5. Bestätigen, dann senden

1. Den endgültigen Titel, den Ziel-MR/PR (URL, Branches) und die vollständige Beschreibung präsentieren und um Bestätigung aller drei bitten.
2. Erst danach eine separate Frage stellen: Genehmigung zum Senden der Änderungen an die Plattform.
3. Nach Genehmigung die Beschreibung in eine temporäre Datei schreiben und den MR/PR mit dem Befehl aus der Plattformreferenz aktualisieren. Diese Befehle sind absichtlich nicht in allowed-tools, damit der Benutzer eine Berechtigungsabfrage erhält.
4. Das Ergebnis und die MR/PR-URL melden. Bei Fehlschlag den Fehler zeigen; nicht stillschweigend wiederholen.