---
name: merge-pr
description: Create a Gitea pull request, monitor CI pipeline status, and merge when green. Use this skill when the user asks to "create a PR", "merge the PR", "ship it", "make it ready to merge", or when you need to open a pull request and wait for CI before merging. Also use when asked to check CI/PR status on Gitea.
---

# Merge PR

Create a pull request on Gitea, monitor the CI pipeline via the Actions API, and merge once all jobs pass.

## Why this skill exists

The Gitea MCP pull request API does not return CI status directly. To know if a PR is ready to merge, you must cross-reference the PR's `head.sha` with the Actions runs API, find the matching run, and check job conclusions. This skill encodes that workflow so it doesn't have to be rediscovered.

## Prerequisites

The Gitea MCP tools must be available. The key tools are:

- `mcp__gitea__pull_request_write` (method: `create`, `merge`)
- `mcp__gitea__pull_request_read` (method: `get`)
- `mcp__gitea__actions_run_read` (methods: `list_runs`, `list_run_jobs`)

If these tools are not yet loaded, use ToolSearch to discover and load them before proceeding.

## Workflow

### 1. Create the PR

Use `mcp__gitea__pull_request_write` with method `create`. Include a clear title, body with summary and test plan, head branch, and base branch (usually `master`).

Save the returned `head.sha` — you need it to find the CI run.

### 2. Find the CI run for the PR

The Actions API has no direct "get CI status for PR" call. Instead:

```
mcp__gitea__actions_run_read(method: "list_runs", owner, repo, perPage: 5)
```

Find the run whose `head_sha` matches the PR's `head.sha`. This is the CI run triggered by the push that the PR points to. If the branch was force-pushed or new commits were added, always match against the latest `head.sha` from a fresh `get` on the PR.

### 3. Monitor job status

Once you have the run ID:

```
mcp__gitea__actions_run_read(method: "list_run_jobs", owner, repo, run_id: <id>)
```

This returns all jobs with their `status` (queued/in_progress/completed) and `conclusion` (success/failure/skipped/null).

Present a status table to the user:

| Job | Status |
|-----|--------|
| backend-test | success |
| frontend-test | in_progress |
| frontend-e2e | queued |

If jobs are still running, wait ~30 seconds and check again. Don't poll in a tight loop.

### 4. Handle failures

If any job has `conclusion: failure`:
- Use `mcp__gitea__actions_run_read` with method `get_job_log_preview` to fetch the failing job's log
- Report the failure to the user with relevant log output
- Do NOT attempt to merge

### 5. Merge when green

Once all jobs show `conclusion: success` (or `skipped` for conditional jobs like `build-and-publish`):

```
mcp__gitea__pull_request_write(
  method: "merge",
  owner, repo,
  index: <pr_number>,
  merge_style: "merge",
  delete_branch: true
)
```

Ask the user for confirmation before merging. They may want to review the PR in the web UI first.

### 6. Post-merge cleanup

After a successful merge, suggest:
- `git checkout master && git pull origin master`
- `git branch -d <feature-branch>` (local cleanup)
- Tagging a release if appropriate (see `/release` skill)

## Abbreviated flow

When the user just wants a quick status check (e.g. "how's the PR?"), skip straight to steps 2-3: find the run by SHA, show the job status table.