Adressieren von GitLab MR Review-Kommentaren (Inline-Kommentare)

Überblick

Inline-Review-Kommentare in einem GitLab MR leben in Diskussionen (Threads, die an eine Datei+Zeile gebunden sind). Der gesamte Ablauf (Abrufen mit Position → Korrektur → Antwort → Auflösen) läuft über glab api. Dieses Skill ist die bewährte Befehlssequenz; die Falle ist, dass der naheliegende Befehl (glab mr view --comments) zwar den Kommentartext, aber nicht die Datei-/Zeilenposition liefert – Sie können also nicht erkennen, worauf sich ein Kommentar bezieht.

ERFORDERLICHER HINTERGRUND: Verwenden Sie superpowers:receiving-code-review für den Bewertungsteil: Bewerten Sie jeden Kommentar mit technischer Strenge und vergewissern Sie sich, dass er korrekt ist, bevor Sie ihn anwenden. Dieses Skill deckt nur die GitLab-Mechanik ab.

Einrichtung

MR=511                                          # die MR iid
PROJ="<group>%2F<subgroup>%2F<project>"         # URL-codierter vollständiger Pfad
API="projects/$PROJ/merge_requests/$MR"

Codieren Sie den Pfad URL (/ → %2F). Wenn Sie unsicher sind, holen Sie ihn mit glab repo view.

1. Kommentare MIT Position abrufen

glab mr view $MR --comments enthält KEINE Zeilenpositionen, verwenden Sie es daher nicht für Inline-Kommentare. Greifen Sie auf die Discussions-API zu und parsen Sie position. --paginate ist zwingend erforderlich: Der Endpunkt gibt 20 Threads pro Seite zurück, und ohne Paginierung werden die restlichen ohne Fehlermeldung verworfen. Bereits aufgelöste Threads werden übersprungen:

glab api --paginate --output ndjson "$API/discussions" | python3 -c '
import sys, json
for line in sys.stdin:
    d = json.loads(line)
    n = d["notes"][0]
    if n.get("system") or n.get("resolved"): continue
    p = n.get("position") or {}
    print(d["id"], "|", n["author"]["username"], "|", n["body"])
    if p: print("   ->", p.get("new_path"), "new_line:", p.get("new_line"), "old_line:", p.get("old_line"))
'

new_line = die Zeile in der aktuellen (nach der Änderung) Datei → das ist es, was Sie lesen, um den Kommentar zu interpretieren.
Ein Kommentar zu einer geänderten Zeile enthält sowohl old_line als auch new_line; verankern Sie ihn an new_path + new_line.
Kein position → es handelt sich um einen allgemeinen (nicht-Inline-)Kommentar.

2. Lesen Sie den Code an jedem `new_path:new_line`, dann korrigieren

Öffnen Sie die Datei an der genannten Zeile, damit der Kommentar im Kontext Sinn ergibt. Wenden Sie die Korrektur erst nach Bewertung an (siehe receiving-code-review). Erstellen Sie einen einzelnen Review-Fix-Commit und pushen Sie:

git add <dateien>
git commit -m "fix(<bereich>): review zu <sache> umgesetzt"   # Conventional Commits, Ticket-ID im Body
git fetch origin <target> && git rebase origin/<target>
git push --force-with-lease   # ein einfaches `git push` reicht nur, wenn das Rebase ein No-Op war

3. Auf jeden Thread antworten und ihn auflösen

Das Posten an den notes-Endpunkt einer Diskussion erstellt automatisch eine Antwort im Thread (kein in_reply_to_id erforderlich). Anschließend PUT resolved=true:

DISC="<diskussions-id aus Schritt 1>"
glab api -X POST "$API/discussions/$DISC/notes" -f "body=Erledigt: <was geändert wurde>."
glab api -X PUT  "$API/discussions/$DISC?resolved=true"

Wickeln Sie glab niemals in eine Shell-Funktion ein: Berechtigungsregeln erkennen nur den wörtlichen Befehl, daher schreiben Sie beide Aufrufe für jeden Thread vollständig aus.

Schreiben der Antwort

Halten Sie sich an das, was geändert wurde und warum. Ein Reviewer möchte das Delta, nicht die Untersuchung.

Angewendet: ein oder zwei Sätze. Was Sie geändert haben, alles, was Sie über die zitierte Zeile hinaus erweitert haben, den Commit-SHA. Erledigt, Block-Stil überall: alle sechs Komponenten, nicht nur diese Zeile. Ausgabe unverändert. f6511f29
Widersprochen oder verschoben: zuerst die entscheidende Tatsache, dann die Option, dann der Ball zurück beim Reviewer. Zwei kurze Absätze sind die Obergrenze. Streichen Sie die Retentions-Seitenbemerkung, das dritte unterstützende Argument, den Abschlusssatz „gerne diskutieren“. Sie können das letzte Beispiel auch weglassen, wenn es redundant ist.
Erzählen Sie niemals die Abfolge Ihrer eigenen Korrekturen, und wiederholen Sie niemals den Kommentar des Reviewers.

Welche Threads aufgelöst werden

Lösen Sie nur diejenigen auf, die Sie tatsächlich abgeschlossen haben.

Änderung angewendet -> antworten + auflösen.
Eine Frage beantwortet und die Antwort erledigt sie -> antworten + auflösen.
Eine Entscheidung, die nicht Ihre ist (Zielumgebung, Umfang, Priorität) -> antworten, nicht auflösen. Einen Thread aufzulösen, den der Reviewer noch entscheiden muss, wirkt wie ein Abtun und er verschwindet von der Review-Liste.

Kurzreferenz

Schritt	Befehl
Inline-Kommentare + Position auflisten	`glab api --paginate --output ndjson "$API/discussions"` → parse `.notes[].position.{new_path,new_line,old_line}`
Auf einen Thread antworten	`glab api -X POST "$API/discussions/<id>/notes" -f "body=..."`
Einen Thread auflösen	`glab api -X PUT "$API/discussions/<id>?resolved=true"`

Häufige Fehler

Verwendung von glab mr view --comments für Inline-Kommentare: liefert Text ohne Datei/Zeile; Sie können sie nicht lokalisieren. Verwenden Sie die Discussions-API.
Erfinden von glab mr note resolve: auflösen über glab api -X PUT ".../discussions/<id>?resolved=true".
Lesen von old_line statt new_line: für einen Kommentar zu einer geänderten Zeile befindet sich der aktuelle Code bei new_line.
Vergessen von --paginate: ab 20 Threads gibt die Discussions-API stillschweigend nur die erste Seite zurück.
Bloßes --force nach dem Rebase: verwenden Sie --force-with-lease, damit ein zwischenzeitlich vom Reviewer gepushter Commit nicht überschrieben wird.
Blindes Anwenden von Kommentaren: zuerst bewerten (receiving-code-review). Antworten Sie mit dem, was Sie tatsächlich geändert haben, dann auflösen.
Abschneiden der Diskussions-ID beim Auflisten von Threads: die API erwartet die vollständige 40-Zeichen-ID, ein 8-Zeichen-Präfix gibt 404 Discussion Not Found. Geben Sie d["id"] komplett aus.
Zu ausführliche Erklärung in der Antwort: siehe „Schreiben der Antwort'. Die Begründung gehört in die MR-Beschreibung oder das Ticket.
Auflösen einer vertagten Entscheidung: wenn der Reviewer noch wählen muss, lassen Sie den Thread offen.

{
  "target_locale": "de",
  "name": "PixiBixi/claude-skills",
  "description": "Use when a reviewer left inline or line-anchored comments on a GitLab merge request, or when asked to address, fix, reply to or resolve MR review threads.",
  "aiSummary": "This skill automates the handling of inline review comments on GitLab merge requests. It fetches comments with file and line positions via the Discussions API, identifies the location using new_path and new_line, and guides the user to read the code, apply fixes, reply to each thread, and resolve it. It supports Claude Code, Cursor, and Codex, as well as other glab-based workflows.",
  "skillMarkdown": "# Adressieren von GitLab MR Review-Kommentaren (Inline-Kommentare)\n\n## Überblick\n\nInline-Review-Kommentare in einem GitLab MR leben in **Diskussionen** (Threads, die an eine Datei+Zeile gebunden sind). Der gesamte Ablauf (Abrufen mit Position → Korrektur → Antwort → Auflösen) läuft über `glab api`. Dieses Skill ist die bewährte Befehlssequenz; die Falle ist, dass der naheliegende Befehl (`glab mr view --comments`) zwar den Kommentartext, aber **nicht die Datei-/Zeilenposition** liefert – Sie können also nicht erkennen, worauf sich ein Kommentar bezieht.\n\n**ERFORDERLICHER HINTERGRUND:** Verwenden Sie `superpowers:receiving-code-review` für den Bewertungsteil: Bewerten Sie jeden Kommentar mit technischer Strenge und vergewissern Sie sich, dass er korrekt ist, *bevor* Sie ihn anwenden. Dieses Skill deckt nur die GitLab-Mechanik ab.\n\n## Einrichtung\n\n```bash\nMR=511                                          # die MR iid\nPROJ="<group>%2F<subgroup>%2F<project>"         # URL-codierter vollständiger Pfad\nAPI="projects/$PROJ/merge_requests/$MR"\n```\nCodieren Sie den Pfad URL (`/` → `%2F`). Wenn Sie unsicher sind, holen Sie ihn mit `glab repo view`.\n\n## 1. Kommentare MIT Position abrufen\n\n`glab mr view $MR --comments` enthält KEINE Zeilenpositionen, verwenden Sie es daher nicht für Inline-Kommentare. Greifen Sie auf die Discussions-API zu und parsen Sie `position`. `--paginate` ist zwingend erforderlich: Der Endpunkt gibt 20 Threads pro Seite zurück, und ohne Paginierung werden die restlichen ohne Fehlermeldung verworfen. Bereits aufgelöste Threads werden übersprungen:\n\n```bash\nglab api --paginate --output ndjson \"$API/discussions\" | python3 -c '\nimport sys, json\nfor line in sys.stdin:\n    d = json.loads(line)\n    n = d[\"notes\"][0]\n    if n.get(\"system\") or n.get(\"resolved\"): continue\n    p = n.get(\"position\") or {}\n    print(d[\"id\"], \"|\", n[\"author\"][\"username\"], \"|\", n[\"body\"])\n    if p: print(\"   ->\", p.get(\"new_path\"), \"new_line:\", p.get(\"new_line\"), \"old_line:\", p.get(\"old_line\"))\n'\n```\n\n- **`new_line`** = die Zeile in der *aktuellen* (nach der Änderung) Datei → das ist es, was Sie lesen, um den Kommentar zu interpretieren.\n- Ein Kommentar zu einer geänderten Zeile enthält sowohl `old_line` als auch `new_line`; verankern Sie ihn an `new_path` + `new_line`.\n- Kein `position` → es handelt sich um einen allgemeinen (nicht-Inline-)Kommentar.\n\n## 2. Lesen Sie den Code an jedem `new_path:new_line`, dann korrigieren\n\nÖffnen Sie die Datei an der genannten Zeile, damit der Kommentar im Kontext Sinn ergibt. Wenden Sie die Korrektur erst nach Bewertung an (siehe receiving-code-review). Erstellen Sie einen einzelnen Review-Fix-Commit und pushen Sie:\n\n```bash\ngit add <dateien>\ngit commit -m \"fix(<bereich>): review zu <sache> umgesetzt\"   # Conventional Commits, Ticket-ID im Body\ngit fetch origin <target> && git rebase origin/<target>\ngit push --force-with-lease   # ein einfaches `git push` reicht nur, wenn das Rebase ein No-Op war\n```\n\n## 3. Auf jeden Thread antworten und ihn auflösen\n\nDas Posten an den `notes`-Endpunkt einer Diskussion erstellt automatisch eine Antwort im Thread (kein `in_reply_to_id` erforderlich). Anschließend PUT `resolved=true`:\n\n```bash\nDISC=\"<diskussions-id aus Schritt 1>\"\nglab api -X POST \"$API/discussions/$DISC/notes\" -f \"body=Erledigt: <was geändert wurde>.\"\nglab api -X PUT  \"$API/discussions/$DISC?resolved=true\"\n```\n\nWickeln Sie `glab` niemals in eine Shell-Funktion ein: Berechtigungsregeln erkennen nur den wörtlichen Befehl, daher schreiben Sie beide Aufrufe für jeden Thread vollständig aus.\n\n## Schreiben der Antwort\n\nHalten Sie sich an das, was geändert wurde und warum. Ein Reviewer möchte das Delta, nicht die Untersuchung.\n\n- **Angewendet**: ein oder zwei Sätze. Was Sie geändert haben, alles, was Sie über die zitierte Zeile hinaus erweitert haben, den Commit-SHA. `Erledigt, Block-Stil überall: alle sechs Komponenten, nicht nur diese Zeile. Ausgabe unverändert. f6511f29`\n- **Widersprochen oder verschoben**: zuerst die entscheidende Tatsache, dann die Option, dann der Ball zurück beim Reviewer. Zwei kurze Absätze sind die Obergrenze. Streichen Sie die Retentions-Seitenbemerkung, das dritte unterstützende Argument, den Abschlusssatz „gerne diskutieren". Sie können das letzte Beispiel auch weglassen, wenn es redundant ist.\n- Erzählen Sie niemals die Abfolge Ihrer eigenen Korrekturen, und wiederholen Sie niemals den Kommentar des Reviewers.\n\n## Welche Threads aufgelöst werden\n\nLösen Sie nur diejenigen auf, die Sie tatsächlich abgeschlossen haben.\n\n- **Änderung angewendet** -> antworten + auflösen.\n- **Eine Frage beantwortet und die Antwort erledigt sie** -> antworten + auflösen.\n- **Eine Entscheidung, die nicht Ihre ist** (Zielumgebung, Umfang, Priorität) -> antworten, **nicht auflösen**. Einen Thread aufzulösen, den der Reviewer noch entscheiden muss, wirkt wie ein Abtun und er verschwindet von der Review-Liste.\n\n## Kurzreferenz\n\n| Schritt | Befehl |\n|--------|--------|\n| Inline-Kommentare + Position auflisten | `glab api --paginate --output ndjson \"$API/discussions\"` → parse `.notes[].position.{new_path,new_line,old_line}` |\n| Auf einen Thread antworten | `glab api -X POST \"$API/discussions/<id>/notes\" -f \"body=...\"` |\n| Einen Thread auflösen | `glab api -X PUT \"$API/discussions/<id>?resolved=true\"` |\n\n## Häufige Fehler\n\n- **Verwendung von `glab mr view --comments` für Inline-Kommentare**: liefert Text ohne Datei/Zeile; Sie können sie nicht lokalisieren. Verwenden Sie die Discussions-API.\n- **Erfinden von `glab mr note resolve`**: auflösen über `glab api -X PUT \".../discussions/<id>?resolved=true\"`.\n- **Lesen von `old_line` statt `new_line`**: für einen Kommentar zu einer geänderten Zeile befindet sich der aktuelle Code bei `new_line`.\n- **Vergessen von `--paginate`**: ab 20 Threads gibt die Discussions-API stillschweigend nur die erste Seite zurück.\n- **Bloßes `--force` nach dem Rebase**: verwenden Sie `--force-with-lease`, damit ein zwischenzeitlich vom Reviewer gepushter Commit nicht überschrieben wird.\n- **Blindes Anwenden von Kommentaren**: zuerst bewerten (receiving-code-review). Antworten Sie mit dem, was Sie tatsächlich geändert haben, dann auflösen.\n- **Abschneiden der Diskussions-ID beim Auflisten von Threads**: die API erwartet die vollständige 40-Zeichen-ID, ein 8-Zeichen-Präfix gibt `404 Discussion Not Found`. Geben Sie `d[\"id\"]` komplett aus.\n- **Zu ausführliche Erklärung in der Antwort**: siehe „Schreiben der Antwort". Die Begründung gehört in die MR-Beschreibung oder das Ticket.\n- **Auflösen einer vertagten Entscheidung**: wenn der Reviewer noch wählen muss, lassen Sie den Thread offen."\n}

{
  "target_locale": "de",
  "name": "PixiBixi/claude-skills",
  "description": "Use when a reviewer left inline or line-anchored comments on a GitLab merge request, or when asked to address, fix, reply to or resolve MR review threads.",
  "aiSummary": "This skill automates the handling of inline review comments on GitLab merge requests. It fetches comments with file and line positions via the Discussions API, identifies the location using new_path and new_line, and guides the user to read the code, apply fixes, reply to each thread, and resolve it. It supports Claude Code, Cursor, and Codex, as well as other glab-based workflows.",
  "skillMarkdown": "# Adressieren von GitLab MR Review-Kommentaren (Inline-Kommentare)\n\n## Überblick\n\nInline-Review-Kommentare in einem GitLab MR leben in **Diskussionen** (Threads, die an eine Datei+Zeile gebunden sind). Der gesamte Ablauf (Abrufen mit Position → Korrektur → Antwort → Auflösen) läuft über `glab api`. Dieses Skill ist die bewährte Befehlssequenz; die Falle ist, dass der naheliegende Befehl (`glab mr view --comments`) zwar den Kommentartext, aber **nicht die Datei-/Zeilenposition** liefert – Sie können also nicht erkennen, worauf sich ein Kommentar bezieht.\n\n**ERFORDERLICHER HINTERGRUND:** Verwenden Sie `superpowers:receiving-code-review` für den Bewertungsteil: Bewerten Sie jeden Kommentar mit technischer Strenge und vergewissern Sie sich, dass er korrekt ist, *bevor* Sie ihn anwenden. Dieses Skill deckt nur die GitLab-Mechanik ab.\n\n## Einrichtung\n\n```bash\nMR=511                                          # die MR iid\nPROJ="<group>%2F<subgroup>%2F<project>"         # URL-codierter vollständiger Pfad\nAPI="projects/$PROJ/merge_requests/$MR"\n```\nCodieren Sie den Pfad URL (`/` → `%2F`). Wenn Sie unsicher sind, holen Sie ihn mit `glab repo view`.\n\n## 1. Kommentare MIT Position abrufen\n\n`glab mr view $MR --comments` enthält KEINE Zeilenpositionen, verwenden Sie es daher nicht für Inline-Kommentare. Greifen Sie auf die Discussions-API zu und parsen Sie `position`. `--paginate` ist zwingend erforderlich: Der Endpunkt gibt 20 Threads pro Seite zurück, und ohne Paginierung werden die restlichen ohne Fehlermeldung verworfen. Bereits aufgelöste Threads werden übersprungen:\n\n```bash\nglab api --paginate --output ndjson \"$API/discussions\" | python3 -c '\nimport sys, json\nfor line in sys.stdin:\n    d = json.loads(line)\n    n = d[\"notes\"][0]\n    if n.get(\"system\") or n.get(\"resolved\"): continue\n    p = n.get(\"position\") or {}\n    print(d[\"id\"], \"|\", n[\"author\"][\"username\"], \"|\", n[\"body\"])\n    if p: print(\"   ->\", p.get(\"new_path\"), \"new_line:\", p.get(\"new_line\"), \"old_line:\", p.get(\"old_line\"))\n'\n```\n\n- **`new_line`** = die Zeile in der *aktuellen* (nach der Änderung) Datei → das ist es, was Sie lesen, um den Kommentar zu interpretieren.\n- Ein Kommentar zu einer geänderten Zeile enthält sowohl `old_line` als auch `new_line`; verankern Sie ihn an `new_path` + `new_line`.\n- Kein `position` → es handelt sich um einen allgemeinen (nicht-Inline-)Kommentar.\n\n## 2. Lesen Sie den Code an jedem `new_path:new_line`, dann korrigieren\n\nÖffnen Sie die Datei an der genannten Zeile, damit der Kommentar im Kontext Sinn ergibt. Wenden Sie die Korrektur erst nach Bewertung an (siehe receiving-code-review). Erstellen Sie einen einzelnen Review-Fix-Commit und pushen Sie:\n\n```bash\ngit add <dateien>\ngit commit -m \"fix(<bereich>): review zu <sache> umgesetzt\"   # Conventional Commits, Ticket-ID im Body\ngit fetch origin <target> && git rebase origin/<target>\ngit push --force-with-lease   # ein einfaches `git push` reicht nur, wenn das Rebase ein No-Op war\n```\n\n## 3. Auf jeden Thread antworten und ihn auflösen\n\nDas Posten an den `notes`-Endpunkt einer Diskussion erstellt automatisch eine Antwort im Thread (kein `in_reply_to_id` erforderlich). Anschließend PUT `resolved=true`:\n\n```bash\nDISC=\"<diskussions-id aus Schritt 1>\"\nglab api -X POST \"$API/discussions/$DISC/notes\" -f \"body=Erledigt: <was geändert wurde>.\"\nglab api -X PUT  \"$API/discussions/$DISC?resolved=true\"\n```\n\nWickeln Sie `glab` niemals in eine Shell-Funktion ein: Berechtigungsregeln erkennen nur den wörtlichen Befehl, daher schreiben Sie beide Aufrufe für jeden Thread vollständig aus.\n\n## Schreiben der Antwort\n\nHalten Sie sich an das, was geändert wurde und warum. Ein Reviewer möchte das Delta, nicht die Untersuchung.\n\n- **Angewendet**: ein oder zwei Sätze. Was Sie geändert haben, alles, was Sie über die zitierte Zeile hinaus erweitert haben, den Commit-SHA. `Erledigt, Block-Stil überall: alle sechs Komponenten, nicht nur diese Zeile. Ausgabe unverändert. f6511f29`\n- **Widersprochen oder verschoben**: zuerst die entscheidende Tatsache, dann die Option, dann der Ball zurück beim Reviewer. Zwei kurze Absätze sind die Obergrenze. Streichen Sie die Retentions-Seitenbemerkung, das dritte unterstützende Argument, den Abschlusssatz „gerne diskutieren". Sie können das letzte Beispiel auch weglassen, wenn es redundant ist.\n- Erzählen Sie niemals die Abfolge Ihrer eigenen Korrekturen, und wiederholen Sie niemals den Kommentar des Reviewers.\n\n## Welche Threads aufgelöst werden\n\nLösen Sie nur diejenigen auf, die Sie tatsächlich abgeschlossen haben.\n\n- **Änderung angewendet** -> antworten + auflösen.\n- **Eine Frage beantwortet und die Antwort erledigt sie** -> antworten + auflösen.\n- **Eine Entscheidung, die nicht Ihre ist** (Zielumgebung, Umfang, Priorität) -> antworten, **nicht auflösen**. Einen Thread aufzulösen, den der Reviewer noch entscheiden muss, wirkt wie ein Abtun und er verschwindet von der Review-Liste.\n\n## Kurzreferenz\n\n| Schritt | Befehl |\n|--------|--------|\n| Inline-Kommentare + Position auflisten | `glab api --paginate --output ndjson \"$API/discussions\"` → parse `.notes[].position.{new_path,new_line,old_line}` |\n| Auf einen Thread antworten | `glab api -X POST \"$API/discussions/<id>/notes\" -f \"body=...\"` |\n| Einen Thread auflösen | `glab api -X PUT \"$API/discussions/<id>?resolved=true\"` |\n\n## Häufige Fehler\n\n- **Verwendung von `glab mr view --comments` für Inline-Kommentare**: liefert Text ohne Datei/Zeile; Sie können sie nicht lokalisieren. Verwenden Sie die Discussions-API.\n- **Erfinden von `glab mr note resolve`**: auflösen über `glab api -X PUT \".../discussions/<id>?resolved=true\"`.\n- **Lesen von `old_line` statt `new_line`**: für einen Kommentar zu einer geänderten Zeile befindet sich der aktuelle Code bei `new_line`.\n- **Vergessen von `--paginate`**: ab 20 Threads gibt die Discussions-API stillschweigend nur die erste Seite zurück.\n- **Bloßes `--force` nach dem Rebase**: verwenden Sie `--force-with-lease`, damit ein zwischenzeitlich vom Reviewer gepushter Commit nicht überschrieben wird.\n- **Blindes Anwenden von Kommentaren**: zuerst bewerten (receiving-code-review). Antworten Sie mit dem, was Sie tatsächlich geändert haben, dann auflösen.\n- **Abschneiden der Diskussions-ID beim Auflisten von Threads**: die API erwartet die vollständige 40-Zeichen-ID, ein 8-Zeichen-Präfix gibt `404 Discussion Not Found`. Geben Sie `d[\"id\"]` komplett aus.\n- **Zu ausführliche Erklärung in der Antwort**: siehe „Schreiben der Antwort". Die Begründung gehört in die MR-Beschreibung oder das Ticket.\n- **Auflösen einer vertagten Entscheidung**: wenn der Reviewer noch wählen muss, lassen Sie den Thread offen."\n}

PixiBixi/claude-skills

Was ist claude-skills?

In Ihrer bevorzugten KI fragen

Dokumentation