next-friday/next-friday-skills

Rebut

Triage der KI-Code-Review-Kommentare auf einem Pull-Request und beantworte sie rigoros. Überprüfe jeden Befund gegen den tatsächlichen Code, behebe die echten, widerlege die falsch-positiven mit Belegen und antworte in jedem Thread, markiert als automatisierte Triage. Der Mensch klickt weiterhin auf "Auflösen".

Dies ist das Gegenstück zum menschlichen Review, keine Kopie davon. KI-Reviewer wie CodeRabbit oder Gemini Code Assist posten weit mehr Befunde, mischen echte Fehler mit falsch-positiven Meldungen und sind Repo-blind. Sie kennen die lokale Konfiguration, Konventionen oder Werkzeuge Ihres Repos nicht, daher markieren sie für Ihr Repo korrekte Muster zuversichtlich als Fehler. Der Schweregrad eines Bots ist nicht seine Korrektheit: ein CRITICAL kann ein falsch-positiver sein, und ein Nit kann einen echten Fehler verbergen.

Warum KI-Reviewer ihre eigene Triage bekommen

• Repo-blind. Der Bot lädt nicht die lokale Konfiguration Ihres Repos — einen Linter-, Formatierer- oder Typprüfer-Konfiguration, was auch immer Ihr Stack verwendet — oder Ihre Hausregeln. Er wird ein Muster markieren, das Ihre eigenen WERKZEUGE ERFORDERN. Reales Beispiel (ein ESLint-Repo): Ein Reviewer markierte meta.defaultOptions als KRITISCH "falsch", aber die require-meta-default-options-Lint-Regel des Repos erzwingt es. Das Anwenden des Vorschlags hätte diesen Build zerstört. Blind anwenden ist genauso gefährlich wie blind verwerfen.
• Hohe Falsch-Positiv-Rate. Viele Befunde sind spekulativ oder stilbezogen. Einige sind echte Fehler, die der Mensch übersehen hat. Die Aufgabe ist es, sie mit Beweisen zu trennen, nicht mit Bauchgefühl.
• Zuversichtlich falsch. Schweregradbezeichnungen sind Heuristiken. Überprüfe ein CRITICAL genauso wie einen Nit.

Wenn der Reviewer ein Mensch ist

Der Ablauf ist derselbe für jeden Reviewer, Bot oder Mensch: Überprüfung gegen den aktuellen Code → Beheben oder Zurückweisen mit Beweisen → Im Thread unter der Attributionszeile antworten → Abdeckung nachweisen. Ein menschlicher Beitragender oder Reviewer ist ebenfalls Teil des Triage-Loops: Wenn eine Person eine Änderung wünscht, behebe sie und antworte mit derselben Strenge und demselben Prüfpfad, den das menschliche Gate beim Merge liest. Nur der Ton ändert sich, weil ein Mensch das Repo kennt, weniger und signalstärkere Befunde postet und ein Gesicht hat, das eine schroffe Zurückweisung bedrohen kann. Wenn der Reviewer also ein Mensch ist:

• Lasse die Bot-Rahmung weg. Behandle ihr Review nicht als Repo-blindes, falsch-positives Rauschen; das ist es meistens nicht.
• Kooperiere, widerlege nicht kurz angebunden. Überprüfe, behebe dann, was richtig ist, und weise zurück, was falsch ist, mit technischer Begründung. Niemals performative Zustimmung, niemals ein kurzes "falsch positiv" an einen Kollegen; gib den Grund in einem nicht-kurzen, technisch begründeten Ton an.
• Poste die Antwort selbst mit der Attributionszeile. Du triagierst menschliche Threads autonom, genauso wie Bot-Threads: poste über das Triage-Konto, geöffnet mit der Attributionszeile, damit der Leser eine automatisierte Triage sieht und nicht die eigene Peer-Review des Maintainers. Die Zeile, die den Kommentar vom Maintainer trennt, macht die automatische Veröffentlichung in einem menschlichen Thread sicher. Die Abdeckung zählt auch menschliche Threads (Schritt 5.5), daher hält ein unbeantworteter menschlicher Befund die Runde offen.

Die folgenden Schritte gelten für Bots und Menschen gleichermaßen; der Attributionsmarker und die automatische Antwort werden für beide verwendet. Die einzige Anpassung pro Reviewer ist der obige Ton.

Preflight

"${CLAUDE_SKILL_DIR}/scripts/preflight.sh"

preflight.sh bestätigt, dass gh authentifiziert ist und das Repo einen GitHub-Remote hat. Bei fehlender Voraussetzung wird die Behebung auf stderr ausgegeben und mit einem Exit-Code ungleich Null beendet; leite das weiter und halte an. Identifiziere den PR: das [pr-number]-Argument, sonst den PR für den aktuellen Branch (gh pr view --json number).

Schritt 1: Jeden Befund sammeln

"${CLAUDE_SKILL_DIR}/scripts/gather-review.sh" <pr>

gather-review.sh gibt einen REVIEWS-Block aus, der Autor, Status und Text jedes Reviews enthält, und einen COMMENTS-Block, der Autor, path:line, id=<id> und Text jedes Inline-Kommentars enthält, über die integrierte --jq-Option von gh, sodass nichts erfunden oder weggelassen wird. Liste jeden Befund mit seinem Autor, path:line, Kommentar id (die zum Antworten benötigt wird) und Text auf. Enthalte die Zusammenfassungen der Top-Level-Reviews und jeden Inline-Kommentar. Verpasse keinen. Markiere den Autor jedes Threads als Bot, erkennbar am [bot]-Login-Suffix in der gesammelten Ausgabe, oder als Mensch: beide folgen den Schritten 4-6, und ein menschlicher Thread erhält zusätzlich die Tonanpassung in "Wenn der Reviewer ein Mensch ist" oben.

Lasse die Runde sich setzen, bevor du triagierst. Reviewer feuern asynchron: Ein zweiter Bot landet seine Welle oft Minuten nach dem ersten, daher erfasst ein Sammellauf direkt nach dem PR-Update nur die Reviewer, die bisher gepostet haben. Lasse die Runde sich nach dem ersten Sammeln mit gh pr checks <pr> --watch || true setzen: es blockiert, bis die Checks des PRs abgeschlossen sind, und verhält sich interaktiv und headless gleich, und das ist das Fenster, in dem asynchrone Reviewer posten (das || true verhindert, dass ein checkloser PR mit einem Exit-Code ungleich Null als Fehler gelesen wird). Führe dann gather-review.sh erneut aus; wenn neue Befunde auftauchen, ist die Runde noch nicht abgeschlossen, also warte und sammle erneut. (Wenn der PR keine Checks hat, kehrt --watch sofort zurück; und ein reiner Review-Bot registriert möglicherweise überhaupt keinen Check-Run, also pausiere in beiden Fällen kurz und sammle erneut, unabhängig vom Check-Status. Die nachfolgende round-übergreifende Automatisierung ist der echte Schutz gegen einen Reviewer, der nach diesem Setzen postet.) Beginne mit der Triage erst, wenn ein erneutes Sammeln nichts Neues hinzufügt. Dies behandelt eine Runde mit mehreren Reviewern als EINEN Triage-Durchgang, anstatt mit den Befunden von Reviewer A zu beginnen, während Reviewer B noch mitten im Posten ist, was einen zweiten vollständigen Durchgang erzwingt. Die Begrenzung verhindert, dass dies ewig wartet; die round-übergreifende Automatisierung im letzten Abschnitt ist die dauerhafte Antwort für Reviewer, die nach Beenden des Skills posten.

Schritt 2: Jeden Befund überprüfen (der Kern dieses Skills)

Überprüfe für jeden Befund zwei Fragen gegen den aktuellen Code, nicht die Rahmung des Bots:

1. Lässt sich das Problem reproduzieren? Reproduziere es, wie ${CLAUDE_SKILL_DIR}/references/debugging.md beschreibt: öffne die Datei in der Zeile, verfolge die Logik, konstruiere die Eingabe, die der Bot beschreibt, und überprüfe das tatsächliche Verhalten. Wenn es ein Fehler ist, muss er demonstrierbar sein.
2. Ist der Vorschlag für DIESES Repo korrekt? Führe das relevante Gate aus, das das Repo definiert (seinen Linter, Typprüfer oder Tests, je nachdem, was existiert). Überprüfe die dokumentierte Konvention. Eine Korrektur, die den Bot passiert, aber ein Repo-Gate nicht besteht, ist hier falsch.

Ändere jeweils eine Sache und überprüfe erneut. Mache keine Stapelverarbeitung.

Schritt 3: Klassifizieren

Urteil	Bedeutung	Aktion
FIX	Echt, reproduziert	Behebe es (Schritt 4)
REFUTE	Falsch positiv für dieses Repo	Antworte mit dem Beleg, der es widerlegt
INTENTIONAL	Bewusste Wahl, die der Bot nicht sieht	Antworte mit Erklärung der Absicht
MINOR	Kosmetisch, nicht gate-relevant	Notiere es; behebe oder überspringe nach Maßgabe des Maintainers

Schritt 4: Die gültigen beheben

• Minimale Änderung, begrenzt auf den Befund. Schreibe für einen Fehler zuerst den fehlschlagenden Test, beobachte, wie er fehlschlägt, behebe, beobachte, wie er besteht.
• Führe die vollständigen Gates des Repos aus. Ein rotes Gate blockiert die Korrektur.
• Lande die gesamte Runde in EINEM Commit und pushe, niemals einen pro Befund. Überprüfe und behebe jeden Befund einzeln wie in Schritt 2, aber stelle jede Korrektur bereit und committe sie gemeinsam, pushe dann einmal, unter dem Konto des Maintainers, demselben Konto, das den PR besitzt und die Antworten postet. Ein Push pro Befund verwandelt einen Review-Zyklus in mehrere: Jeder Push startet die CI erneut und löst jeden Bot erneut aus, sodass fünf Korrekturen fünf CI-Läufe und fünf erneute Review-Wellen werden. Ein Commit pro Runde ist ein CI-Lauf und eine erneute Review-Welle. Erfasse diesen einzelnen SHA; jede Korrekturantwort in Schritt 5 zitiert ihn. Wenn dieser Push als nicht schnell weiterleitbar abgelehnt wird, weil sich der entfernte Branch weiterbewegt hat (ein Release-Bot-Bump oder ein PR-"Branch aktualisieren"-Merge hat während der Runde Commits hinzugefügt), erhole dich, stoppe nicht: git fetch dann git rebase origin/<branch>, führe die Gates erneut aus und pushe erneut, niemals --force; das Rebase schreibt den Commit um, also erfasse den neuen SHA und zitiere diesen in den Antworten von Schritt 5, nicht den veralteten vor dem Rebase.

Schritt 5: In jedem Thread antworten

Antworte auf den ursprünglichen Kommentar, damit es inline eingerückt wird, niemals ein Top-Level-PR-Kommentar.

Jede Antwort mit derselben Attributionszeile eröffnen, in jedem Thread, ohne Ausnahme. Du postest über den gh-Token des Maintainers, daher zeigt GitHub seinen Avatar und ein Leser nimmt an, dass er es geschrieben hat. Die Attributionszeile nennt den Agenten und trennt den Kommentar vom Maintainer, damit automatisierte Triage niemals mit dem persönlichen Review des Maintainers verwechselt wird:

🤖 Automatisierte Triage durch Claude Code, gepostet über das Konto des Maintainers, kein persönliches Review.

Wenn das Repo ein Bot- oder Maschinenkonto hat, poste unter dieser Identität, damit der Autor selbst unpersönlich ist; die Attributionszeile ist der Fallback für ein persönliches Token.

Schreibe den Text in eine Datei. Die Attributionszeile macht den Text mehrzeilig, was Inline- -f body="..."-Zitierung zerbricht. Eine Korrekturantwort:

> 🤖 Automatisierte Triage durch Claude Code, gepostet über das Konto des Maintainers, kein persönliches Review.

**rebut** korrigiert in <sha>: <eine Zeile zur Änderung>.

Eine Widerlegung gibt den Beleg an:

> 🤖 Automatisierte Triage durch Claude Code, gepostet über das Konto des Maintainers, kein persönliches Review.

**rebut** dies nicht geändert: <konkreter Grund, z. B. eine Repo-Lint-Regel erfordert es; das Gate besteht>.

Poste jede Antwort mit post-reply.sh, einen Befund nach dem anderen:

"${CLAUDE_SKILL_DIR}/scripts/post-reply.sh" <pr> <comment_id> /tmp/reply.md

post-reply.sh tempo das Posten unter dem sekundären Rate-Limit von GitHub, bestätigt dann, dass es bestehen geblieben ist, indem es die erstellte Antwort-ID aus der API-Antwort ausliest und bei Drosselung eines Postens mit Backoff wiederholt. Es gibt die Antwort-ID aus und beendet sich mit 0 bei Erfolg; Exit 1 bedeutet, dass die Antwort nicht gepostet wurde (nicht fortfahren, beheben und erneut ausführen), Exit 2 ist ein falsches Argument. Führe den rohen gh api .../replies-Aufruf nicht in einer Schleife selbst aus: Hintereinander erfolgende Posts lösen das Rate-Limit aus und verschwinden, genau der Fehler, den dieses Skript verhindern soll. Ein Befund, ein post-reply.sh-Aufruf, in Sequenz.

Nur antworten, niemals auflösen. Poste Antworten über die API; klicke niemals auf "Konversation auflösen". Der grüne Auflösen-Button gehört dem menschlichen Reviewer, und es ist die Art und Weise, wie sie überprüfen, ob die Arbeit dieses Skills abgeschlossen ist: Sie lesen jeden Thread, bestätigen, dass eine Antwort vorhanden ist, bestätigen, dass der Zusammenfassungskommentar existiert, und lösen erst dann auf. Wenn der Skill auflöst, kann der Mensch nicht sagen, ob er selbst oder der Agent den Thread geschlossen hat, genau die Verwirrung, die sie dazu bringt, die Triage erneut zu überprüfen oder erneut auszuführen. Die gesamte Ausgabe dieses Skills sind Antworten plus ein Zusammenfassungskommentar; der Auflösen-Button bleibt ihr.

Keinen Thread leer lassen. Jeder Befund, der in Schritt 1 gesammelt wurde, erhält eine Antwort: ein FIX mit seinem SHA, oder ein REFUTE / INTENTIONAL / MINOR mit seinem Grund. Ein Befund ohne Antwort, von einem Bot oder einem Menschen, ist von untriagierter Arbeit nicht zu unterscheiden: Ein Reviewer kann nicht sagen, ob der Skill ausgeführt wurde, also rufen sie ihn erneut auf, und die Runde wiederholt sich. Stille ist niemals ein Urteil. Das Ablehnen eines Befunds erfordert dennoch einen genannten Grund, niemals einen leeren Thread.

Schritt 5.5: Abdeckung bestätigen, CI erneut überprüfen, dann die Runde abfangen, die dein Korrektur-Push provoziert hat

Vor dem Zusammenfassen:

• Abdeckung bestätigen (immer). Frage nach dem Posten den PR erneut ab und bestätige, dass jeder Befund, Bot oder Mensch, eine Antwort vom Triage-Konto erhalten hat:

  "${CLAUDE_SKILL_DIR}/scripts/verify-coverage.sh" <pr>
  

  Es gibt eine Zeile pro Befund aus (beantwortet / FEHLT) dann beantwortet N / M. Exit 0 bedeutet, dass jeder Befund eine Antwort hat (die Runde ist abgedeckt); Exit 1 listet jeden FEHLT-Befund auf, also poste diese mit post-reply.sh erneut und führe es erneut aus, bis es beantwortet N / N meldet; Exit 2 ist ein Lese-/Argumentfehler, der keine Abdeckung ist, also zeige ihn an. Dies wird unabhängig von den Urteilen ausgeführt, einschließlich einer reinen REFUTE-Runde, bei der keine Korrektur gepusht wurde: Eine fallengelassene Widerlegungsantwort ist genauso unsichtbar wie eine fallengelassene Korrekturantwort. Gehe niemals zu Schritt 6 über, solange ein Befund FEHLT ist.

• CI erneut überprüfen. Wenn Checks noch andauern, warte mit gh pr checks <pr> --watch, klassifiziere dann mit "${CLAUDE_SKILL_DIR}/scripts/ci-status.sh" <pr>: ci: grün (Exit 0) ist klar; ci: fehlschlagend (Exit 1) blockiert, also debugge es; ci: keine (Exit 3) bedeutet, dass keine CI konfiguriert ist, was KEIN Fehler ist, also notiere es und fahre fort, genau wie das implement-Skill es behandelt; ci: ausstehend (Exit 4) bedeutet, --watch erneut auszuführen, dann erneut zu prüfen; ein Lesefehler (Exit 2) ist nicht "grün", also zeige ihn an. Bestätige Grün mit eigenen Augen; behaupte es niemals ohne den Beweis des Skripts. Wenn Schritt 4 nichts geändert hat, weil jeder Befund REFUTE oder INTENTIONAL war, gibt es keinen neuen Push, daher haben diese CI-Erneutüberprüfung und das folgende Runden-Abfangen nichts, das erneut ausgelöst wird; die obige Abdeckungsbestätigung wird trotzdem ausgeführt.

• Die neue Runde abfangen. Der Korrektur-Push

…

[abgeschnitten für Übersetzung]