Hacktoberfest 2026:維護者為十月標記出來的 issue,仍然開放、適合新手。 瀏覽 Hacktoberfest issue

feat: add labels support to create_pull_request tool

未關閉
#2,415 1 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

@yashdesai30 已經在處理了。

開始於 2026年5月1日。

  • #2413 來自 @yashdesai30 —— 未關閉

評估

難度
4/5
預估耗時
3-5 天
新手友好度
20/100
Issue 類型
功能
描述清晰度
描述清楚
活躍度
停滯
技術堆疊
go

研究方向

先查看 PR #2413,以及 issue 中提到的 CreatePullRequest InputSchema、AddLabelsToIssue 呼叫、測試和 pr-write MCP App 變更。執行 go test ./... 和 golangci-lint run --new-from-rev=HEAD;完成的標準是選用標籤能正常運作、標籤失敗時明確回報 PR 已建立,並且文件中記載的工具已更新。

由索引模型根據 Issue 內容生成。

描述

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).

主要語言
Go
星號
33.3k
分支
5.1k
平均合併
22 小時 46 分鐘
30 天內合併 PR
17

環境準備

從這裡開始

  1. 先讀完整個 Issue,再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫,在一個分支上完成修改。
  4. 送出 Pull Request,並在描述裡引用這個 Issue 編號。

github/github-mcp-server 的其他 Issue

查看 github/github-mcp-server 的全部 Issue

相似的 Issue

更多 Go Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。