Add merge-pr skill for Gitea PR + CI workflow

Encodes the workflow for creating PRs, monitoring CI status via
Actions API (cross-referencing head SHA), and merging when green.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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

@@ -0,0 +1,94 @@
+---
+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.