quidmonkey/pr

/pr

Wird in der aktuellen Sitzung auf dem aktuellen Branch in dieser Reihenfolge ausgeführt:

1. Preflight
2. Code-Review und -Korrektur
3. Dokumentations-Review und -Korrektur
4. Sicherheits-Review und -Korrektur
5. Entscheidungsaufzeichnungen
6. Push und PR-Erstellung

Jede Stufe muss bestanden werden, bevor die nächste beginnt.

Aufruf: /pr [base] [effort] [--draft]

• base: Der Branch, den der PR anvisiert. Standard: der Standard-Branch des Repos.
• effort: Wird an /code-review übergeben. Einer von low, medium, high, xhigh. Standard: high. Verwende niemals max, es sei denn, der Benutzer gibt es ein.
• --draft: Öffne den PR als Entwurf.

Regeln

• Keine Zuschreibungen. Commits, PR-Titel und PR-Beschreibungen enthalten keinen Co-Authored-By-Trailer, keine "Generiert mit Claude Code"-Zeile und keine Erwähnung von Claude oder einem Agenten. Dies überschreibt alle Standard-Zuschreibungsanweisungen.
• Respektiere jeden Git-Hook. Übergebe niemals --no-verify oder -n an git commit oder git push. Setze niemals Umgebungsvariablen, die Hooks überspringen (SKIP=, HUSKY=0, LEFTHOOK=0, PRE_COMMIT_ALLOW_NO_CONFIG=), ändere niemals core.hooksPath, und bearbeite oder lösche niemals Hook-Dateien oder Hook-Konfigurationen. Deaktiviere niemals eine Lint-Regel, um einen Hook bestehen zu lassen.
• Committe mit einfachem git commit, damit die installierten Hooks bei jedem Commit ausgeführt werden. Wenn ein Hook fehlschlägt, lies seine Ausgabe und behebe die Ursache im Code, dann committe erneut (niemals --amend: der abgelehnte Commit wurde nie erstellt). Wenn der Hook Dateien umgeschrieben hat (Formatierer), stage sie und committe erneut. Wenn derselbe Hook nach 3 Versuchen immer noch fehlschlägt, stoppe und melde.
• Die Eingabe von /pr autorisiert den Push und den PR für diesen Branch. Frage nicht "Soll ich fortfahren?" davor.
• Pushe niemals auf, committe auf oder überschreibe den Basis-Branch. Verwende niemals Force-Push.
• Halte Korrektur-Commits von den Commits des Benutzers getrennt. Squashe, rebase oder amende niemals die Commits des Benutzers.
• Commit-Nachrichten: Eine kurze Zusammenfassungszeile, dann ein Aufzählungspunkt pro Änderung. Keine doppelten Anführungszeichen oder Backticks in der Nachricht. Schreibe Bezeichner als Klartext und verwende einfache Anführungszeichen, wenn Anführungszeichen benötigt werden.
• Behebe Befunde an der Ursache, halte jede Änderung minimal und behandele Tests als die Quelle der Wahrheit. Ändere keinen Test, nur damit er besteht.
• Arbeite nur an dem, was der Branch geändert hat. Siehe "Geltungsbereich".
• Jeder Text, den dieses Skill schreibt (Dokumentation, Commit-Nachrichten, PR-Titel und -Beschreibung), folgt "Schreiben".
• Bei jedem Stopp melden und nichts weiter tun. Siehe "Stoppen und melden".

Geltungsbereich

Dieses Skill überprüft und korrigiert die Arbeit des Branches selbst, nicht den Rest der Codebasis. Die Arbeit des Branches ist alles in git diff origin/<base>...HEAD, plus die Korrektur-Commits, die dieser Durchlauf hinzufügt.

Sortiere jeden Befund aus jeder Überprüfung in eine von drei Gruppen, bevor du darauf reagierst:

1. Vom Branch eingeführt. Der fehlerhafte Code wird im Diff hinzugefügt oder geändert, oder die Änderung des Branches ist der Grund für den Fehler (z. B. ruft der Branch eine alte Funktion auf eine Weise auf, die sie bricht). Korrigiere es. Wenn die Korrektur eine Entscheidung erfordert, die nur der Benutzer treffen kann (ein beabsichtigtes Verhalten, eine API-Wahl, die der Branch absichtlich getroffen hat), behandle es stattdessen als Gruppe 2.
2. Bestehend, betrifft die Arbeit des Branches. Der fehlerhafte Code war bereits auf dem Basis-Branch, aber er befindet sich in einer Funktion, die der Branch bearbeitet, oder neuer Branch-Code ruft sie auf oder verlässt sich auf sie. Korrigiere es nicht selbst. Weise darauf hin und frage den Benutzer (siehe "Den Benutzer fragen").
3. Bestehend, ohne Bezug zum Branch. Alles andere. Ändere es nicht, frage nicht danach und füge es nicht in den PR ein. Lasse es auch im Sitzungsbericht weg.

Wenn ein Befund zwischen Gruppe 2 und 3 liegt, ordne ihn Gruppe 2 zu.

Schweregrad

Reagiere nur auf Befunde mit hohem und mittlerem Schweregrad, wie es ein menschlicher Prüfer tun würde. Überspringe Befunde mit niedrigem Schweregrad in jeder Gruppe: korrigiere sie nicht, frage nicht nach ihnen und füge sie nicht in den PR ein. Wenn eine Überprüfung bereits einen Befund der Gruppe 1 mit niedrigem Schweregrad korrigiert hat und die Korrektur klein ist und die Prüfungen besteht, behalte sie; andernfalls mache sie rückgängig.

• Hoch: Ein Fehler oder eine Schwachstelle, auf die ein normaler Benutzer oder ein realistischer Angreifer stößt. Datenverlust, Absturz bei normaler Eingabe, Injection, Auth-Bypass, offengelegte Geheimnisse.
• Mittel: Ein echter Fehler in einem plausiblen Fall, ein defektes dokumentiertes Verhalten, eine fehlende Prüfung an einer Vertrauensgrenze oder ein Test, der einen Fehler versteckt.
• Niedrig: Randfälle, die ein ungewöhnliches Setup erfordern (eine von jemandem, der bereits Schreibzugriff hat, platzierte Datei, ein Race in einem lokalen Tool, eine nicht unterstützte Plattform), Defense in Depth, Stil, Benennung, Duplikate und Mikro-Optimierungen.

Wenn eine Überprüfung keinen Schweregrad angibt oder du anderer Meinung bist, beurteile es selbst mit diesen Definitionen. Wenn ein Befund zwischen zwei Stufen liegt, wähle die höhere.

Den Benutzer fragen

Sammle jeden Befund der Gruppe 2 mit hohem oder mittlerem Schweregrad aus einer Stufe und frage einmal, am Ende der Runde dieser Stufe, vor dem Commit. Verwende das AskUserQuestion-Tool, eine Frage pro Befund (bis zu 4 pro Aufruf bündeln). Jede Frage benennt die Datei, die Zeile und das Problem in einem Satz und bietet an:

• Auf diesem Branch korrigieren: Korrigiere es jetzt, im Korrektur-Commit dieser Stufe.
• Belassen, im PR notieren: Code nicht ändern. Führe es unter "Hinweise für Reviewer" in der PR-Beschreibung auf.
• Belassen: Code nicht ändern und nicht im PR erwähnen.
• Stoppen: Den Durchlauf stoppen und melden (siehe "Stoppen und melden").

Befolge jede Antwort. Ein Befund der Gruppe 2, den der Benutzer beantwortet hat, gilt nicht als offen, stoppt also den Durchlauf nicht und kommt in der nächsten Runde nicht zurück. Wenn eine spätere Überprüfung ihn erneut meldet, wende dieselbe Antwort an.

Einweisung der Überprüfungs-Skills

Beim Aufruf von code-review oder security-review füge den Argumenten hinzu: den Repo-Pfad, die Basis (origin/<base>), und "Korrigiere nur Probleme mit hohem und mittlerem Schweregrad, die der Branch eingeführt hat. Melde bestehende Probleme, ohne sie zu korrigieren. Gib für jeden Befund seinen Schweregrad (hoch, mittel oder niedrig) an und sage, ob er bereits besteht. Bearbeite keine Dokumentation (README, docs/, CHANGELOG); eine spätere Stufe kümmert sich darum." Mache dann alle Dokumentationsbearbeitungen oder Korrekturen außerhalb des Geltungsbereichs rückgängig, die die Überprüfung dennoch vorgenommen hat (git restore nur für diese Hünke), bevor du die Befunde sortierst.

Schreiben

Schreibe wie ein Ingenieur, der einem Teamkollegen eine Notiz hinterlässt: kurz, klar und spezifisch.

• Sage, was sich geändert hat und warum, in konkreten Begriffen: Datei, Funktion, Verhalten, Zahl. Lasse alles weg, worauf ein Prüfer nicht reagieren kann.
• Kurze Sätze, eine Idee pro Satz. Einfache Verben: "ist", "hat", "fügt hinzu", "korrigiert", "entfernt".
• Kein Füllmaterial oder Absicherungen: "um zu" ist "zu", "aufgrund der Tatsache, dass" ist "weil", kein "könnte möglicherweise".
• Verbotene Wörter: zusätzlich, eintauchen, nutzen, entscheidend, zentral, lebenswichtig, verbessern, robust, nahtlos, nahtlos, umfassend, komplex, Landschaft, Wandteppich, Zeugnis, unterstreichen, präsentieren, fördern, optimieren, aufwerten, befähigen, rühmt, lebendig, reich, hochmodern, Game-Changer, ganzheitlich, Synergie, verwenden.
• Kein "dient als" oder "steht als" (schreibe "ist"), kein "nicht nur X, sondern Y", keine Dreierlisten für den Rhythmus, keine "-end"-Endungen wie "..., sicherstellend, dass X" oder "..., hervorhebend Y".
• Keine Emojis, keine Gedankenstriche, keine mechanische Fettschrift, keine Überschriften in Title Case, keine geschweiften Anführungszeichen, keine abschließende Zusammenfassung oder optimistische Verabschiedung.
• Beschreibe den Überprüfungsprozess nicht ("Code-Review durchgeführt", "Befunde behandelt") in der Dokumentation oder der PR-Beschreibung. Die Korrektur-Commits dokumentieren es bereits.

Bevor du einen Text verwendest, lies ihn erneut und streiche jedes Wort, das keine Information trägt.

1. Preflight

Führe diese aus und stoppe beim ersten Fehler, mit der erforderlichen Korrektur:

1. git rev-parse --show-toplevel gelingt und git remote get-url origin existiert.
2. gh auth status besteht. Wenn es fehlschlägt, sage dem Benutzer, er solle ! gh auth login ausführen.
3. Basis: das base-Argument, sonst gh repo view --json defaultBranchRef -q .defaultBranchRef.name. Führe git fetch origin <base> aus.
4. Der aktuelle Branch (git branch --show-current) ist nicht leer (detached HEAD) und ist nicht <base>.
5. git rev-list --count origin/<base>..HEAD ist größer als 0.
6. git status --porcelain ist leer. Wenn nicht, zeige die geänderten Dateien und frage, ob sie zuerst committet werden sollen (als eigener Commit des Benutzers, durch die Hooks) oder gestoppt werden soll. Stashe oder verwerfe sie nicht.
7. Führe gh pr view --json url,state,isDraft,body aus, um zu sehen, ob der Branch bereits einen PR hat. Merke dir das Ergebnis für Stufe 6.

Ausführen von Prüfungen

Nach jeder Runde von Korrekturen, vor dem Commit (der Commit führt die Git-Hooks aus, also führe sie hier nicht aus):

• Führe den Testbefehl des Projekts aus, wenn einer offensichtlich ist (Makefile-Ziel, pyproject.toml, package.json-Skripte). Führe auch Lint aus, wenn es von den Hooks getrennt ist.
• Korrigiere Fehler an der Ursache und führe erneut aus, bis alles sauber ist.

2. Code-Review und -Korrektur

Vor der ersten Runde lies die aufgezeichneten Entscheidungen und die Dokumentation, die den geänderten Code abdeckt:

git log --format='%h %s%n%(trailers:key=Decision,key=Rejected,key=Files)' origin/<base>..HEAD
git log -E --all-match --grep='^(Decision|Rejected):' --grep='<paths>' --format='%h %s%n%b' origin/<base>
git log -E --grep='^(Decision|Rejected):' --format='%h %s%n%b' origin/<base> -- <geänderte Dateien>

Der erste listet die Entscheidungen des Branches auf. Die anderen beiden finden bereits auf der Basis vorhandene Entscheidungen, die die geänderten Dateien des Branches abdecken (git diff --name-only origin/<base>...HEAD). Der zweite entspricht Entscheidungsaufzeichnungen, deren Files:-Zeile eine geänderte Datei nennt; <paths> sind die geänderten Dateien, verbunden mit |, wobei jeder . als \. geschrieben wird. Dies ist notwendig, da ein Entscheidungs-Commit keine Dateien ändert, sodass ein Pfadfilter ihn nicht finden kann. Der dritte findet Entscheidungen in Commits, die diese Dateien geändert haben, wie z. B. Squash-Merges. Beide gleichen Zeilen ab, anstatt Trailer zu parsen, da ein Squash-Merge Trailer in die Mitte einer Nachricht schieben kann. Lies die Vereinigungsmenge.

Korrigiere keinen Befund, der von einer aufgezeichneten Entscheidung oder einer Dokumentation als beabsichtigt markiert ist, es sei denn, er verursacht einen konkreten Fehler. Wenn der Branch gegen eine auf der Basis aufgezeichnete Entscheidung verstößt, notiere es für Stufe 5.

Bis zu 2 Runden:

1. Rufe das Skill code-review mit den Argumenten <effort> --fix <aktueller Branch> plus der Einweisung aus "Einweisung der Überprüfungs-Skills" auf.

2. Wenn es keine Befunde mit hohem oder mittlerem Schweregrad meldet, besteht diese Stufe (nachdem alle Korrekturen mit niedrigem Schweregrad behandelt wurden, die es vorgenommen hat, gemäß "Schweregrad").

3. Sortiere die Befunde (siehe "Geltungsbereich"). Überprüfe, was --fix geändert hat, und mache alles außerhalb von Gruppe 1 rückgängig. Korrigiere alle Befunde der Gruppe 1, die es ungelöst gelassen hat. Überspringe alle Befunde, die ein Trailer oder eine Dokumentation ausschließt, und notiere sie für die PR-Beschreibung. Frage nach Befunden der Gruppe 2.

4. Wenn sich nichts geändert hat, besteht diese Stufe. Andernfalls führe "Ausführen von Prüfungen" aus, dann committe:

   Code-Review-Befunde behandelt
   
   - <ein Aufzählungspunkt pro Korrektur>
   

5. Beginne die nächste Runde.

Wenn nach Runde 2 noch Befunde der Gruppe 1 mit hohem oder mittlerem Schweregrad verbleiben, stoppe und melde.

3. Dokumentations-Review und -Korrektur

Überprüfe, ob die Dokumentation des Repos mit dem Branch übereinstimmt, wie er jetzt ist, einschließlich der Code-Review-Korrekturen.

1. Finde die Dokumentation: README.md, ARCHITECTURE.md, CONTRIBUTING.md, alles unter docs/, eine CHANGELOG.md, und READMEs in den Verzeichnissen, die der Branch berührt hat. Überspringe generierte Dokumentation, eingekauften Code und Planungs- oder Implementierungsdokumente, die für Agenten geschrieben wurden.

2. Lies den vollständigen Branch-Diff: git diff origin/<base>...HEAD.

3. Suche nach Abweichungen. Eine Dokumentation muss geändert werden, wenn der Branch:

   • Design, Architektur oder die Grenzen zwischen Modulen ändert
   • eine öffentliche Funktion, einen CLI-Befehl, ein Flag, einen Konfigurationsschlüssel, eine Umgebungsvariable, einen Endpunkt oder einen Dateipfad hinzufügt, entfernt oder umbenennt, den eine Dokumentation erwähnt oder erwähnen sollte
   • dokumentiertes Verhalten, Standardwerte, Einrichtungsschritte oder Beispiele ändert
   • etwas entfernt oder umbenennt, das eine Dokumentation noch nennt (grep die Dokumentationen für jeden entfernten oder umbenannten Bezeichner)

4. Korrigiere jede Abweichung mit der kleinsten Bearbeitung, die die Dokumentation korrekt macht. Passe dich der vorhandenen Struktur und dem Ton der Dokumentation an. Befolge "Schreiben".

   • Erstelle keine neuen Dokumentationsdateien und füge keine Dokumentation für interne Änderungen hinzu, die niemand liest.
   • Aktualisiere CHANGELOG.md nur, wenn es einen unveröffentlichten Abschnitt enthält; füge eine Zeile in seinem vorhandenen Format hinzu.
   • Bearbeite hier keine Code-Kommentare oder Docstrings. Das ist Aufgabe des Code-Reviews.
   • Korrigiere nur Abweichungen, die der Branch verursacht hat. Lasse Dokumentationsfehler, die bereits auf dem Basis-Branch vorhanden waren, in Ruhe, es sei denn, sie beschreiben Code, den der Branch geändert hat; dann frage, wie in "Den Benutzer fragen".

5. Wenn nichts abgewichen ist, besteht diese Stufe ohne Commit.

6. Andernfalls führe "Ausführen von Prüfungen" auf den geänderten Dokumentationen aus, dann committe:

   Dokumentation für Branch-Änderungen aktualisiert
   
   - <ein Aufzählungspunkt pro geänderter Dokumentation>
   

7. Lese jeden bearbeiteten Abschnitt erneut gegen den Diff. Korrigiere alles, was immer noch falsch ist, in einem zweiten Commit. Wenn eine Dokumentation ohne eine Entscheidung des Benutzers nicht korrekt gemacht werden kann (z. B. welches der beiden Verhaltensweisen beabsichtigt ist), stoppe und melde.

4. Sicherheits-Review und -Korrektur

Bis zu 2 Runden:

1. Rufe das Skill security-review mit der Einweisung aus "Einweisung der Überprüfungs-Skills" auf. Es meldet nur. Es bearbeitet keinen Code.

2. Wenn es keine Befunde mit hohem oder mittlerem Schweregrad meldet, besteht diese Stufe.

3. Sortiere die Befunde (siehe "Geltungsbereich"). Korrigiere jeden Befund der Gruppe 1 an seiner Ursache. Wenn eine Korrektur dokumentiertes Verhalten ändert, aktualisiere diese Dokumentation im selben Commit, gemäß "Schreiben". Wenn du dir sicher bist, dass ein Befund ein falsch Positives ist, ändere keinen Code. Zeichne den Befund und den Grund für die PR-Beschreibung auf. Frage nach Befunden der Gruppe 2.

4. Wenn sich nichts geändert hat, besteht diese Stufe. Andernfalls führe "Ausführen von Prüfungen" aus, dann committe:

   Sicherheits-Review-Befunde behandelt
   
   - <ein Aufzählungspunkt pro Korrektur>
   

5. Beginne die nächste Runde.

Wenn nach Runde 2 ein echter Befund der Gruppe 1 mit hohem oder mittlerem Schweregrad verbleibt, stoppe und melde.

Wenn diese Stufe Code geändert hat, führe das Skill code-review noch einmal mit <effort> --fix <aktueller Branch> und der Einweisung aus, auf den neuen Commits. Behandle alle Befunde wie in Stufe 2, innerhalb einer zusätzlichen Runde. Stoppe und melde, wenn sie verbleiben.

5. Entscheidungsaufzeichnungen

Zeichne die Design-Entscheidungen des Branches in der Git-Historie auf, wo git log sie später findet. Jede Entscheidung erhält ihren eigenen Commit. Der Betreff gibt die Entscheidung an, sodass git log --oneline und die Liste der letzten Commits, die ein Agent zu Sitzungsbeginn sieht, sie enthalten, ohne den Commit zu öffnen. Die Trailer enthalten den Grund, die abgelehnte Alternative und die Dateien, die die Entscheidung abdeckt.

1. Sammle die bereits aufgezeichneten Entscheidungen: die Trailer des Branches und die Basis-Entscheidungen aus Stufe 2.
2. Lese git diff origin/<base>...HEAD und liste die Entscheidungen auf, die es trifft und die keine Aufzeichnung haben. Eine Entscheidung ist eine Wahl, die ein späterer Prüfer oder Agent in Frage stellen könnte oder...

... [gekürzt für die Übersetzung]