fete/.claude/skills/merge-pr/SKILL.md

name, description

name	description
merge-pr	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.