Duplikate-PRs-Issues-Taggen

Mit Tags versehene doppelte PRs und Issues

Verwende diese Fähigkeit, wenn ein Maintainer entscheiden muss, ob ein Pull Request oder Issue eine Dublette bestehender Arbeit ist.

Diese Fähigkeit ist für das Triage und die Gruppierung durch Maintainer gedacht. Sie ist nicht für die Überprüfung der Implementierungsqualität eines PRs.

Erforderliche Einrichtung

Schreibe keine doppelten Gruppen oder Anmerkungen, bevor diese Einrichtung abgeschlossen ist. Ein schreibgeschütztes Entdecken kann weiterhin mit gitcrawl und Live-gh erfolgen.

Begleitfähigkeiten

Verwende zuerst $gitcrawl für die lokale Kandidatensuche. Verwende die Fähigkeit prtags aus dem prtags-Repository unter skills/prtags/SKILL.md, sobald diese verfügbar ist.

Installiere die CLI-Tools

Installiere prtags aus der unten stehenden gepinnten Version. Verlasse dich nicht auf einen alten lokalen Build, es sei denn, der Maintainer möchte ausdrücklich unveröffentlichtes Verhalten testen.

prtags CLI-Installationspfad:

GOBIN="$HOME/.local/bin" go install github.com/dutifuldev/prtags/cmd/[email protected]

prtags lebt außerhalb der OpenClaw-Organisation, daher bleibt diese Installation auf eine überprüfte Version gepinnt, die der Go-Modul-Proxy auflöst und die öffentliche Prüfsummen-Datenbank verifiziert. GOBIN hält die installierte ausführbare Datei im gleichen benutzerlokalen Verzeichnis wie der vorherige Installateur, sodass ein vorhandener $HOME/.local/bin-PATH weiterhin die neu installierte Version auflöst. Installiere sie nicht, indem du ein Remote-Skript in eine Shell leitest, und verweise die Installation nicht auf einen Branch: Bei beiden Methoden wird das ausgeführt, was ein Dritter zur Laufzeit bereitstellt, mit den Berechtigungen des Maintainers. Der Wechsel zu einer neueren prtags-Version ist eine überprüfte Änderung an dieser Datei, kein Zwischenschritt in einer Aufgabe.

Authentifiziere prtags

prtags sollte mit dem eigenen GitHub-Konto des Maintainers über den OAuth-Gerätefluss angemeldet sein. Verwende für interaktives Triage keinen gemeinsamen Maintainer-Token.

prtags auth login
prtags auth status

Das erwartete Ergebnis ist, dass prtags die angemeldete Maintainer-Identität lokal speichert und dieses Konto für authentifizierte Schreibvorgänge verwendet.

Regel für fehlende Einrichtung

Verlange keine vorherige Überprüfung vor dem Start des Workflows. Fahre mit den normalen Schritten fort, bis du tatsächlich ein Tool oder einen Kontostatus benötigst.

Sobald du feststellst, dass prtags fehlt oder beim Schreibschritt nicht angemeldet ist, beende die Arbeit sofort. Setze den Vorgang nicht in einem partiellen Schreibmodus fort.

Wenn prtags fehlt, bitte den Benutzer, den gepinnten Installationsbefehl aus dem Abschnitt CLI-Tools installieren auszuführen. Behalte diesen Abschnitt als die einzige Quelle der installierten Version; improvisiere keinen anderen Installationspfad.

Wenn prtags auth status anzeigt, dass der Benutzer nicht angemeldet ist, bitte den Benutzer, Folgendes auszuführen:

prtags auth login

Setze den Vorgang erst fort, nachdem das fehlende Tool oder der Anmeldestatus behoben wurde.

Standard-Lesepfad

Verwende für die Kandidatensuche in diesem Workflow zuerst gitcrawl. Behandle es als die lokale Historie- und Clustering-Schicht für verwandte Issues, doppelte Versuche und geschlossene Threads.

Verwende Live-gh oder gh api für den Ziel-Thread und für jeden Kandidaten, bevor du eine handlungsrelevante Beurteilung triffst. Verwende Live-GitHub, wenn gitcrawl aus einem konkreten Grund fehlt oder veraltet ist, z.B.:

• das Ziel oder der Kandidat ist noch nicht vorhanden
• die lokalen Daten sind für die benötigte Entscheidung eindeutig veraltet oder unvollständig
• gitcrawl gibt einen Fehler aus, läuft ab oder verfügt nicht über die benötigten Nachbars-/Suchdaten

Wenn du auf eine Live-GitHub-Suche zurückgreifst, notiere, dass du dies getan hast und warum.

Wenn ein späterer prtags-Zielschreibvorgang fehlschlägt, weil der eigene Spiegel nicht aufgeholt hat, stoppe und melde, dass das Kuratierungs-Backend das Zielobjekt vermisst, anstatt einen Fallback-Schreibvorgang zu erzwingen.

Ziel

Für jeden Ziel-PR oder jedes Issue:

1. sammle Doppelnachweise
2. entscheide, ob es eine echte Dublette ist
3. erstelle oder verwende eine prtags-Gruppe für diesen Duplikatscluster
4. speichere die Maintainer-Beurteilung in prtags
5. verlasse dich auf normale prtags-Gruppenschreibvorgänge, um die GitHub-Kommentarsynchronisation zu steuern, wenn diese Integration konfiguriert ist

Werkzeugrollen

Verwende die Werkzeuge mit diesen Grenzen:

• gitcrawl ist die Kandidatengenerierung und der historische Kontext
  • verwende es zuerst für die lokale Titel-/Textsuche, Nachbarn, Cluster und die Suche nach geschlossenen Threads
  • behandle jeden Kandidaten als Hinweis, bis Live-GitHub ihn bestätigt
• gh ist die Live-GitHub-Wahrheit
  • verwende es für den Zielzustand, Körper, Kommentare, Reviews, Dateien, verknüpfte Issues und den aktuellen offen/geschlossen/zusammengeführt Status
  • verwende gh search nur, wenn gitcrawl veraltet ist, Daten fehlen oder die benötigte Abfrage nicht ausdrücken kann
• prtags ist die Kuratierungsschicht des Maintainers
  • verwende es, um eine Duplikatsgruppe zu erstellen oder wiederzuverwenden
  • verwende es, um den Duplikatsstatus, die Sicherheit, die Begründung und die Gruppenzusammenfassung zu speichern
  • verwende es als Wahrheitsquelle für den gruppenbezogenen GitHub-Kommentar

Arbeitsregeln

• Bezeichne etwas nicht nur als Dublette, weil die Titel ähnlich sind.
• Bezeichne etwas nicht nur als Dublette, weil sich dieselben Dateien geändert haben.
• Ein Duplikatscluster sollte auf dem gleichen benutzerseitigen Problem, der gleichen Absicht und einem im Wesentlichen überlappenden Implementierungs- oder Untersuchungskontext basieren.

Eine-Gruppe-Regel

Behandle Duplikatsgruppen als exklusiv. Ein PR oder Issue sollte gleichzeitig zu höchstens einer Duplikatsgruppe gehören.

Das bedeutet:

• bevor du eine neue Gruppe erstellst, suche nach einer bestehenden Gruppe, die bereits dieselbe Duplikatsstory repräsentiert
• wenn das Ziel bereits zu einer anderen Duplikatsgruppe zu gehören scheint, stoppe und löse diesen Konflikt zuerst
• erstelle keine zweite Gruppe für dasselbe Ziel, nur weil die Formulierung geringfügig abweicht
• wenn sich zwei plausible bestehende Gruppen überschneiden und du die Beurteilung nicht sicher zusammenführen kannst, stoppe und frage den Maintainer

Diese Regel ist wichtiger als Geschwindigkeit. Die Fähigkeit sollte einen kohärenten Duplikatscluster pro Problem erhalten, nicht viele nahezu doppelte Cluster.

Was eine gute Duplikatsgruppe repräsentiert

Eine Duplikatsgruppe sollte das zugrunde liegende Problem und die beabsichtigte Fehlerbehebungsrichtung beschreiben. Gruppiere Elemente nicht nur, weil sie ein Schlüsselwort gemeinsam haben.

Gute Gruppenform:

• gleicher benutzerseitiger Fehler oder gleiche maintainerseitige Aufgabe
• gleiches Subsystem oder gleiche Code-Oberfläche
• gleiche beabsichtigte Änderungsrichtung
• gleicher wahrscheinlicher Duplikatsauflösungspfad

Schlechte Gruppenform:

• „alle PRs, die Slack berühren“
• „alle Issues, die Wiederholung erwähnen“
• „alle Authentifizierungselemente“

Der Gruppentitel sollte das eigentliche Problem benennen. Die Gruppenbeschreibung sollte die Absicht und die Code-Oberfläche zusammenfassen.

Beispiele:

• gateway: Startup-Regression vom Kanalstatus-Bootstrap
• whatsapp: QR-Preflight-Timeout-Behandlung
• release: Übergabelücken bei der plattformübergreifenden Validierung

Nachweis-Checkliste

Bevor du eine Dublette erklärst, sammle Nachweise aus mindestens zwei Kategorien. gitcrawl-Nachbarn, Suchergebnisse und Clustermitgliedschaft zählen als Kandidatengenerierung, nicht als ausreichender Beweis allein.

Für PRs:

• gleiches oder nahezu gleiches Problemstatement
• gleiche geänderte Dateien oder überlappende Dateibereiche
• gleiche Fehlerbehebungsrichtung
• gleiches Subsystem und Fehlermodus
• gleiches verknüpftes Issue oder gleiches benutzerseitiges Symptom

Für Issues:

• gleiches benutzerseitiges Problem
• gleiche Reproduktionsstory oder gleicher Fehlermodus
• gleicher wahrscheinlicher Fehlerbehebungsbereich
• gleiche bereits verknüpfte oder diskutierte PRs
• gleicher Maintainer, der bereits auf dieselbe Duplikatsgruppierung hinarbeitet

Wenn du nur ähnliche Formulierungen hast, ist das nicht genug.

Schritt 1: Das Ziel lesen

Beginne damit, das Ziel selbst zu lesen. Verwende Live-GitHub für den aktuellen Zielzustand.

Für einen PR:

gh pr view <nummer> --json number,title,state,mergedAt,body,closingIssuesReferences,files,comments,reviews,statusCheckRollup

Für ein Issue:

gh issue view <nummer> --json number,title,state,body,comments,closedAt

Notiere:

• Zieltyp und -nummer
• Titel
• Problemstatement
• vorgeschlagene Absicht
• Subsystem
• ob es offen, geschlossen oder zusammengeführt ist
• ob es bereits einen wahrscheinlichen von Menschen erwähnten Duplikats-Thread gibt

Schritt 2: Breit mit Gitcrawl suchen

Verwende zuerst gitcrawl, da es die lokale OpenClaw-Historie- und Clustering-Quelle ist. Wechsle nicht zu einer breiten Live-GitHub-Suche, es sei denn, gitcrawl hat fehlende Daten, ist veraltet oder schlägt fehl.

Beginne mit dem Ziel und benachbarten Threads:

gitcrawl threads openclaw/openclaw --numbers <issue-oder-pr-nummer> --include-closed --json
gitcrawl neighbors openclaw/openclaw --number <issue-oder-pr-nummer> --limit 20 --json

Suche dann nach Schlüsselphrasen und Subsystembegriffen:

gitcrawl search openclaw/openclaw --query "<Schlüsselphrase aus Titel oder Text>" --mode hybrid --limit 20 --json
gitcrawl search openclaw/openclaw --query "<Subsystem- oder Fehlerphrase>" --mode hybrid --limit 20 --json

Überprüfe wahrscheinliche Cluster:

gitcrawl cluster-detail openclaw/openclaw --id <cluster-id> --member-limit 20 --body-chars 280 --json

Für PRs, überprüfe wahrscheinliche Code-Überlappungen mit Live-Dateidaten:

gh pr view <kandidat-pr> --json number,title,state,mergedAt,files,body,comments,reviews

Für Issues, überprüfe den Status und die Kommentare des wahrscheinlichen Duplikat-Issues live:

gh issue view <kandidat-issue> --json number,title,state,body,comments,closedAt

Schritt 3: Live-GitHub-Suche für Lücken verwenden

Verwende gezielte Live-GitHub-Suche nach gitcrawl, wenn:

• das Ziel zu neu für den lokalen Speicher ist
• Kommentare oder Reviews wichtig sind und der lokale Speicher diese nicht hat
• die genaue Phrase nicht in lokalen Ergebnissen aufgetreten ist, aber das Issue/der PR aktuell genug ist, dass GitHub es kennen sollte

gh search prs --repo openclaw/openclaw --match title,body --limit 50 -- "<Schlüsselphrase>"
gh search issues --repo openclaw/openclaw --match title,body --limit 50 -- "<Schlüsselphrase>"
gh search issues --repo openclaw/openclaw --match comments --limit 50 -- "<Fehler- oder Maintainerphrase>"

Schritt 4: Das Ergebnis entscheiden

Wähle eines dieser Ergebnisse:

• keine_dublette
• dublette_benötigt_beurteilung
• dublette_bestätigt

Verwende dublette_bestätigt nur, wenn die Beweise stark genug sind, dass der Maintainer das doppelte Element sicher schließen oder neu taggen könnte.

Verwende dublette_benötigt_beurteilung, wenn:

• das Problem gleich aussieht, aber das Implementierungsziel abweicht
• die Code-Überlappung schwach ist
• die Formulierung des Issues mehrdeutig ist
• es zwei gültige Interpretationen des Duplikatsclusters geben könnte
• das Ziel scheinbar zwei bestehende Duplikatsgruppen überschneidet

Schritt 5: Eine prtags-Gruppe wiederverwenden oder erstellen

Bevor du eine Gruppe erstellst, durchsuche prtags nach einer bestehenden.

Beginne mit einer Textsuche in Gruppen:

prtags search text -R openclaw/openclaw "<Problemphrase>" --types group --limit 10
prtags search similar -R openclaw/openclaw "<Problemzusammenfassung>" --types group --limit 10
prtags group list -R openclaw/openclaw

Überprüfe wahrscheinliche Gruppen:

prtags group get <gruppen-id>
prtags group get <gruppen-id> --include-metadata

Verwende eine bestehende Gruppe wieder, wenn:

• sie dasselbe Problem repräsentiert
• sie bereits eindeutig verwandte Mitglieder enthält
• das Hinzufügen des Ziels die Gruppe kohärent halten würde

Erweitere eine bestehende Gruppe nicht nur, weil gitcrawl mehrere PRs oder Issues nahe beieinander platziert hat. Bestätige, dass der tatsächliche Implementierungspfad und die Absicht des Maintainers noch übereinstimmen, bevor du das neue Mitglied hinzufügst.

Erstelle eine neue Gruppe nur, wenn keine bestehende Gruppe eindeutig passt.

Erstelle die Gruppe mit einem problembasierten Titel und einer absichtsbasierten Beschreibung:

prtags group create -R openclaw/openclaw \
  --kind mixed \
  --title "<problemzentrierter Titel>" \
  --description "<gleiche Absicht, Subsystem und Dubletten-Auflösungspfad>" \
  --status open

Füge dann das Ziel und alle bekannten Duplikatsmitglieder hinzu:

prtags group add-pr <gruppen-id> <pr-nummer>
prtags group add-issue <gruppen-id> <issue-nummer>

Wenn ein Ziel scheinbar bereits zu einer anderen Duplikatsgruppe gehört und du diese Gruppe nicht sicher wiederverwenden kannst, stoppe. Erstelle keine zweite Gruppe.

Schritt 6: Sicherstellen, dass die Anmerkungsfelder existieren

Verwende field ensure, damit die Fähigkeit idempotent ist.

Empfohlene Felder auf Zielebene:

prtags field ensure -R openclaw/openclaw --name duplicate_status --scope pull_request --type enum --enum-values not_duplicate,candidate,confirmed --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_status --scope issue --type enum --enum-values not_duplicate,candidate,confirmed --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope pull_request --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope issue --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope pull_request --type text --searchable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope issue --type text --searchable

Empfohlene Felder auf Gruppenebene:

prtags field ensure -R openclaw/openclaw --name duplicate_confidence --scope group --type enum --enum-values low,medium,high --filterable
prtags field ensure -R openclaw/openclaw --name duplicate_rationale --scope group --type text --searchable
prtags field ensure -R openclaw/openclaw --name cluster_summary --scope group --type text --searchable

Schritt 7: Die Maintainer-Beurteilung in prtags speichern

Für einen PR:

prtags annotation pr set -R openclaw/openclaw <pr-nummer> \
  duplicate_status=bestätigt \
  duplicate_confidence=hoch \
  duplicate_rationale="<gleiches Problem, gleiche Fehlerbehebungsrichtung, überlappende Dateien und Kommentare>"

Für ein Issue:

prtags annotation issue set -R openclaw/openclaw <issue-nummer> \
  duplicate_status=bestätigt \
  duplicate_confidence=hoch \
  duplicate_rationale="<gleiches benutzerseitiges Problem und gleicher beabsichtigter Fehlerbehebungspfad>"

Für die Gruppe:

prtags annotation group set <gruppen-id> \
  duplicate_confidence=hoch \
  cluster_summary="<Ein-Satz-Problemzusammenfassung>" \
  duplicate_rationale="<warum diese Elemente in einen Duplikatscluster gehören>"

Wenn die Beweise unvollständig sind, setze duplicate_status=kandidat und senke die Sicherheit.

Wenn ein PR- oder Issue-spezifischer Anmerkungsschreibvorgang fehlschlägt, weil prtags das Ziel nicht auflösen kann, erzwinge keinen Fallback-Schreibpfad. Behalte den Gruppenstatus, den du schreiben konntest, melde, dass das Kuratierungs-Backend das Zielobjekt noch vermisst, und verschiebe den endgültigen Duplikatsstatus auf einen späteren Zeitpunkt, wenn das Zielobjekt synchronisiert ist.