github / github/github-mcp-server

Add MCP tools for GitHub Stacked PRs (gh stack link / sync / view)

未关闭
#2,905 2 条评论 9 个 reaction 已指派 0 人 在 GitHub 查看
主要语言
Go
星标
33k
派生
5k
平均合并
2 天 1 小时
30 天内合并 PR
52

描述

## Describe the feature or problem you’d like to solve

Agents that manage **stacked / dependent PRs** (each PR’s `base` is the branch below it) can already create and re-base-point individual PRs via `create_pull_request` / `update_pull_request`, but they have **no first-class way** to:

1. Discover or read a GitHub **native stack** (the stack object / annotations created by `gh stack link` / `gh stack submit`)
2. Create or update that stack as a unit
3. Cascade-rebase / sync the tower when trunk moves (`gh stack sync` / `gh stack rebase`)
4. Merge bottom-up with stack-aware ordering

Today the only path to native stacks is the `gh stack` CLI extension (`github/gh-stack`), which many agent environments intentionally don’t expose (token stays on a host proxy; container `gh` is stubbed; agents talk to GitHub through this MCP).

## Proposed solution

Add a small **stack toolset** (or extend `pull_requests`) that mirrors the operations agents already need from `gh stack`, without shelling out:

| Tool | Purpose |
|---|---|
| `list_stacks` / `get_stack` | Resolve a stack by number, PR number, or head branch; return ordered PRs + trunk |
| `link_stack` | Create/update a stack from an ordered list of PR numbers or branches (`gh stack link`) |
| `update_stack` | Reorder / reparent / drop layers |
| `sync_stack` | Cascade-rebase onto trunk + push with lease semantics (`gh stack sync`) — or return structured rebase instructions if server-side git is out of scope |
| `merge_stack` | Merge bottom-up, stopping on the first non-mergeable layer |

Minimum useful v1: **read + link** (`get_stack`, `link_stack`). Agents can already do Path-B base-chaining with `update_pull_request(base=…)`; what’s missing is the **native stack object** and a single call that wires N PRs correctly.

## Example

```text
link_stack(
owner: "org",
repo: "app",
base: "develop", # trunk
pull_numbers: [7609, 7797, 7810, 7815, …] # bottom → top
)
→ { stack_number: 7928, prs: [...] }

get_stack(owner, repo, stack_number: 7928)
→ ordered layers with number, head, base, mergeable, reviewDecision

贡献指南

打开贡献指南

调研方向

Start by reviewing the existing create_pull_request and update_pull_request tools, then compare their base-chaining behavior with the proposed get_stack and link_stack operations. A minimum v1 is complete when agents can read a native stack and create or update one from an ordered list of pull requests or branches, with ordered layers and trunk returned.

由索引模型根据 Issue 内容生成。

评估

技术栈
go
领域
api, backend
Issue 类型
功能
难度
5/5
预计耗时
一周以上
活跃度
活跃
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。