Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

feat: add labels support to create_pull_request tool

Offen
  • Stimmt etwas nicht?
#2,415 1 Kommentar 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
20/100
Issue-Typ
Feature
Klarheit
Klar beschrieben
Aktivitätsstatus
Veraltet
Tech-Stack
go
Bereich
api, developer-experience, tooling

Rechercherichtung

Beginne mit der Durchsicht von PR #2413 sowie des CreatePullRequest InputSchema, des AddLabelsToIssue-Aufrufs, der Tests und der in der Issue genannten pr-write MCP App-Änderungen. Führe go test ./... und golangci-lint run --new-from-rev=HEAD aus; abgeschlossen ist die Aufgabe, wenn optionale Labels funktionieren, Label-Fehler eindeutig melden, dass der PR erstellt wurde, und die dokumentierten Tools aktualisiert sind.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

enhancement request ai review
Describe the feature or problem you'd like to solve

The create_pull_request tool currently does not support adding labels during PR creation. Users who want to label PRs at creation time must make a separate add_label tool call after creating the PR, which adds friction in agentic workflows where a PR should be created with appropriate labels in a single step.

This is especially common in real-world usage — developers naturally say "create a PR and label it as bug" rather than thinking of it as two separate operations.

Proposed solution

Add an optional labels parameter (string array) to the create_pull_request tool. Since the GitHub REST API (POST /repos/{owner}/{repo}/pulls) does not natively support labels, the implementation uses a two-step approach:

  1. Create the PR via the existing pulls endpoint
  2. Apply labels via POST /repos/{owner}/{repo}/issues/{issue_number}/labels

If label application fails after PR creation, the error clearly indicates the PR was created successfully but labels could not be applied, so no work is silently lost.

Benefits:

  • Reduces tool calls needed for a common workflow (2 → 1)
  • Aligns with how developers naturally think about PR creation
  • Fully backwards-compatible — the parameter is optional
  • Consistent with issue_write which already supports labels at creation time
Example prompts or workflows (for tools/toolsets only)

  1. "Create a pull request from my feature branch to main and label it as bug and priority:high" — Single-step PR creation with classification labels, common in triage workflows.

  2. "Open a PR for this hotfix, mark it as draft, and add the urgent label" — Combines draft mode with labeling for time-sensitive fixes.

  3. "Create a PR titled 'Add user auth' from feat/auth to develop with labels enhancement and security" — Full PR creation with multiple labels in one natural request.

  4. "Submit a pull request for my changes and tag it as documentation" — Simple single-label use case that feels natural to say but currently requires two tool calls.

  5. "Create PRs for each of my feature branches and label them with their respective area labels" — Batch automation scenario where reducing tool calls per PR matters.

Additional context

I have a working implementation in PR #2413 that includes:

  • Backend: labels array property in CreatePullRequest InputSchema + AddLabelsToIssue post-creation call
  • Tests: 2 new test cases (success with labels, label failure after PR creation)
  • UI: Labels input field in the pr-write MCP App
  • Docs: Updated toolsnap + auto-generated README via script/generate-docs

All tests pass (go test ./...) and lint is clean (golangci-lint run --new-from-rev=HEAD → 0 issues).

Vorherrschende Sprache
Go
Sterne
33.1k
Forks
5k
Ø Merge
2 T. 3 Std.
Gemergte PRs (30 T.)
18

Entwicklungsumgebung

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus github/github-mcp-server

Alle Issues in github/github-mcp-server

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.