Feature request: batch-fetch pull request review comment threads for an explicit PR list
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 48/100
Rechercherichtung
Beginne damit, das bestehende Verhalten von pull_request_read und get_review_comments zu lesen, und überprüfe anschließend die Repository-Konventionen für Aktualisierungen von script/generate-docs und toolsnap. Definiere und dokumentiere die begrenzte Anzahl von PRs sowie das Verhalten bei fehlenden oder 404-PRs, füge Tests hinzu und aktualisiere generierte Dokumentation oder toolsnap-Artefakte. Erledigt ist die Aufgabe, wenn das Batch-Verhalten der expliziten Liste getestet und dokumentiert ist.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Problem
Today, pulling inline review threads for multiple PRs means N separate pull_request_read calls (get_review_comments per PR). For agent workflows (team playbooks, review digests, distilling recurring conventions into docs or rules), that is slow, error-prone, and uses more API round-trips than necessary.
Proposed solution (v1)
Add a tool (name up to maintainers) that accepts:
owner,repopull_numbers: array of integers (bounded, e.g. configurable max such as 20–50)- Optional pagination parameters consistent with existing
get_review_commentsbehavior
Behavior: For each PR number, return the same structured data as today’s per-PR get_review_comments (threads + metadata such as resolved/outdated), keyed by pull_number.
Explicit non-goals (v1):
- No semantic ranking, clustering, or “top comments” inside the server.
- No implicit full-repo scan; the caller supplies an explicit list (e.g. from
search_pull_requests/list_pull_requests/ git).
Why this matters
- Documents a single supported pattern for agents: select PRs → one batch read → summarize offline.
- Reduces N+1 calls for engineering hygiene (guidelines derived from real review text).
Acceptance criteria (suggestion)
- Documented max PR count and behavior for missing/404 PRs (partial success vs fail-all—pick one and document).
- Tests +
script/generate-docs/ toolsnap updates per repo conventions.
Related issues
- Reply to review comments (still one thread at a time today): https://github.com/github/github-mcp-server/issues/1323
- Copilot suggestion changesets not in API (platform/API gap): https://github.com/github/github-mcp-server/issues/2235
- Companion (batch PR metadata for changelogs): https://github.com/github/github-mcp-server/issues/2302
Note
We are happy to prototype a PR if maintainers agree on v1 scope (explicit pull_numbers[], caps, and error semantics).
- Vorherrschende Sprache
- Go
- Sterne
- 33.1k
- Forks
- 5k
- Ø Merge
- 2 T. 1 Std.
- Gemergte PRs (30 T.)
- 25
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus github/github-mcp-server
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
github/github-mcp-server#3235 ·
-
enhancement
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 88/100
github/github-mcp-server#3042 · 2 Kommentare ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
github/github-mcp-server#3032 · 1 Reaktion ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
github/github-mcp-server#2803 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
github/github-mcp-server#2740 ·
Alle Issues in github/github-mcp-server
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
-
bug group: validation priority: low
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
codecheckers/chekhov#51 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100