gh-issues

Was macht gh-issues?

Verwenden Sie dieses Skill für die Automatisierung von Issue-zu-PR-Workflows. Bevorzugen Sie die gh CLI; weichen Sie nur dann auf gh api aus, wenn ein High-Level-Befehl nicht das benötigte Feld enthält.

Argumente

• Positional owner/repo: optional; sonst aus git remote get-url origin ableiten.
• --label <label>: Filter.
• --limit <n>: Standard 10.
• --milestone <title>: Filter.
• --assignee <login|@me>: Filter.
• --state open|closed|all: Standard open.
• --fork <owner/repo>: Branches in Fork pushen, PR zum Quell-Repository.
• --watch: Issues und Reviews abrufen.
• --interval <minutes>: Standard 5.
• --dry-run: Nur auflisten.
• --yes: Keine Bestätigung.
• --reviews-only: Issue-Fixes überspringen; PR-Reviews bearbeiten.
• --cron: Ausführen und beenden; impliziert --yes.
• --model <id>: An Worker übergeben, wenn unterstützt.
• --notify-channel <id>: Optionales Endbenachrichtigungsziel.

Phase 1: Repository auflösen

git remote get-url origin
if [ -z "${GH_TOKEN:-}" ]; then
  CONFIG_PATH="${OPENCLAW_CONFIG_PATH:-${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/openclaw.json}"
  GH_TOKEN=$(jq -r '.skills.entries["gh-issues"].apiKey // empty' "$CONFIG_PATH" 2>/dev/null || true)
  if [ -n "$GH_TOKEN" ]; then export GH_TOKEN; fi
fi
gh auth status
gh repo view OWNER/REPO --json nameWithOwner,defaultBranchRef

Wenn gh auth status fehlschlägt und GH_TOKEN fehlt, anhalten und nach GitHub-Authentifizierung/Konfiguration fragen.

Abgeleitet:

• SOURCE_REPO: Issue-Repository.
• PUSH_REPO: Fork, falls gesetzt, sonst Quell-Repository.
• BASE_BRANCH: Standard-Branch der Quelle, es sei denn, der Benutzer gibt etwas anderes an.
• PUSH_REMOTE: fork im Fork-Modus, sonst origin.

Bei einem schmutzigen Arbeitsverzeichnis anhalten, es sei denn, der Benutzer bestätigt, dass Worker nicht committete Änderungen ignorieren sollen.

Im Fork-Modus die Remotes vor der Bestätigung oder bei --dry-run nicht ändern.

Nur Authentifizierungs-/Lesezugriff überprüfen:

gh auth token >/dev/null || test -n "${GH_TOKEN:-}"
gh repo view "$PUSH_REPO" --json nameWithOwner
git ls-remote --exit-code origin HEAD

Phase 2: Issues abrufen

Filter erstellen und abrufen:

gh issue list --repo "$SOURCE_REPO" --state open --limit 10 --json number,title,labels,url,body,assignees,milestone

--label, --milestone, --assignee, --state, --limit wie angefordert hinzufügen. gh issue list schließt PRs standardmäßig aus.

Wenn keine gefunden: Keine Treffer melden. Bei --dry-run: kompakte Liste anzeigen und anhalten.

Phase 3: Doppelte Arbeiten vermeiden

Für jeden Kandidaten:

gh pr list --repo "$SOURCE_REPO" --search "$SOURCE_REPO#<n>" --state open --json number,url,title,headRefName
gh pr list --repo "$SOURCE_REPO" --head "fix/issue-<n>" --state open --json number,url
gh api "repos/$PUSH_REPO/branches/fix/issue-<n>" >/dev/null

Kandidaten mit offenem PR, vorhandenem Branch oder aktivem lokalen Claim überspringen.

Claim-Datei:

${OPENCLAW_STATE_DIR:-$HOME/.openclaw}/gh-issues-<owner>-<repo>.json

Claims älter als 2 Stunden ablaufen lassen. Das Elternverzeichnis vor dem Schreiben erstellen.

Phase 4: Bestätigung

Sofern nicht --yes oder --cron, Benutzer zur Auswahl auffordern:

• all
• Komma-getrennte Issue-Nummern
• cancel

Nach der Bestätigung im Fork-Modus den Push-Remote konfigurieren, bevor die Arbeit an Agenten übergeben wird:

gh auth setup-git
git remote get-url fork || git remote add fork "https://github.com/$PUSH_REPO.git"
git remote set-url fork "https://github.com/$PUSH_REPO.git"
git ls-remote --exit-code fork HEAD

Phase 5: Worker starten

Bis zu 8 Hintergrund-Worker starten. Bei --cron nicht auf jeden Worker warten.

Vor jedem Start einen Claim für SOURCE_REPO#<n> mit aktuellem ISO-Zeitstempel schreiben. Nachdem ein Worker einen PR/Fehler gemeldet hat, den Claim entfernen oder aktualisieren. Dies verhindert Überschneidungen bei Watch/Cron, bevor ein Branch oder PR existiert.

Worker-Prompt muss enthalten:

• Issue-URL, Titel, Body, Labels.
• SOURCE_REPO, PUSH_REPO, BASE_BRANCH, PUSH_REMOTE, Fork-Modus.
• Ziel-Branch fix/issue-<n>.
• Erforderlicher Nachweis und PR-Body.
• Benachrichtigungsroute.

Worker-Anweisungen:

Verwenden Sie gh und git. Nicht herumreden.
Checkout/create fix/issue-<n> von BASE_BRANCH.
Minimalen Fix implementieren.
Relevante Tests ausführen.
Mit konventioneller Nachricht committen.
In PUSH_REMOTE pushen.
PR gegen SOURCE_REPO BASE_BRANCH öffnen.
PR-Body: Welches Problem wird gelöst + Warum diese Änderung vorgenommen wurde + Auswirkungen auf den Benutzer + Nachweise + sichtbare Fixes SOURCE_REPO#<n>.
PR-URL oder Fehlergrund melden.
Abschluss/Fehler mit openclaw message send melden, falls Route angegeben.

coding-agent-Startregeln verwenden, wenn verfügbar.

Phase 6: Ergebnisse sammeln

Worker mit process oder Task-Registry abfragen. Melden:

• Issue-Nummer + Titel.
• Status: PR geöffnet, übersprungen, fehlgeschlagen, Zeitüberschreitung.
• PR-URL oder Grund.

Benachrichtigungskanal nur mit finaler kompakter Zusammenfassung.

Nur Reviews / Watch-Modus

Offene PRs finden:

gh pr list --repo "$SOURCE_REPO" --state open --json number,title,url,headRefName,reviewDecision \
  --jq '[.[] | select(.headRefName | startswith("fix/issue-"))]'

Review-Threads/Kommentare abrufen:

gh pr view <n> --repo "$SOURCE_REPO" --json url,headRefName,comments,reviews
gh api "repos/$SOURCE_REPO/pulls/<n>/comments"
gh api "repos/$SOURCE_REPO/issues/<n>/comments"

Nur PRs vom Typ fix/issue-* verarbeiten, die von diesem Workflow erstellt wurden, es sei denn, der Benutzer hat explizit PR-Nummern genannt. Umsetzbare Kommentare nach PR gruppieren. Lob, Status, Duplikate und bereits behandelte Kommentare ignorieren. Einen Worker pro ausgewähltem/abgegrenztem PR starten, gleiche Hintergrundregeln.

Review-Worker-Anweisungen:

PR-Branch auschecken.
Alle umsetzbaren Review-Kommentare lesen.
Minimale Änderungen patchen.
Relevante Tests ausführen.
Normal committen und pushen; kein Force-Push, es sei denn, explizit aufgefordert.
Auf behandelte Kommentare antworten mit Fix + Commit-/Dateiverweis.
Behandelte/übersprungene Kommentare und Nachweise melden.

Watch-Modus

Schleife:

1. Issues abrufen.
2. Berechtigte Issue-Worker starten.
3. Umsetzbare PR-Reviews verarbeiten.
4. --interval schlafen.
5. Anhalten, wenn der Benutzer es sagt.

Kumulative Zusammenfassung klein halten.