Files
holocron/plugins/gitea/skills/gitea-prs/SKILL.md

69 lines
5.7 KiB
Markdown

---
name: gitea-prs
description: >
Use when listing, reading, creating, updating, merging, or reviewing Gitea pull requests —
getting PR status/diff/changed files/CI status, opening a PR, updating title/body/reviewers,
closing/reopening, merging with a chosen strategy, or submitting/dismissing a code review with
inline comments. Composes `gitea-labels-milestones` to resolve label names or milestone titles
to the numeric IDs `pull_request_write` requires, rather than duplicating that resolution logic.
Do not use for issues (`gitea-issues`) or branch/commit operations (`gitea-branches`) — a number
the user mentions may refer to either an issue or a PR since they share one number space, so
confirm which domain applies before dispatching.
compatibility: Requires Gitea MCP server configured with write:issue and write:repository token scopes.
metadata:
category: integration
source_keys:
- gitea-mcp-repo
- gitea-mcp-slim-go
- context7-websites-gitea
- context7-gitea-tea-cli
version: "0.1.1"
allowed-tools: mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__pull_request_review_write
---
## Gotchas
- **Issues and PRs share one number space.** A number the user mentions (`#42`) might be an issue, not a PR — there is only one counter per repo. If you're not certain, call `pull_request_read method: "get"` and treat a 404 as "this number is an issue, not a PR" (or check `is_pull` on an `issue_read` response first if you already have one).
- **`pull_request_read method: "get"` returns `review_scomments`, not `review_comments`.** Source-level typo in gitea-mcp v1.3.0. Never reference `review_comments` — it will always be undefined.
- **`draft: true` on create prepends `"WIP:"` to the title.** There is no first-class draft field — Gitea implements draft PRs via title prefix. To un-draft, call `update` and pass the title without the `WIP:` prefix.
- **Cross-repo fork PRs require `head` as `"fork-owner:branch-name"`.** A bare branch name causes Gitea to search the base repo for it and return 422. Same-repo PRs use a bare branch name.
- **PR `milestone` is a bare title string, not `{id, title}`.** Unlike issues, you cannot recover a milestone's ID from a PR response. If you need the ID (e.g. to filter or to pass to another write), call into `gitea-labels-milestones` and match by title via `milestone_read method: "list"`.
- **CI status and review/approval state are independent merge gates.** `get_status` only reports CI. Branch-protection rules (required approvals, requested-reviewer coverage, stale-approval handling) are enforced server-side by the merge call itself and will error if unmet — passing CI does not mean the merge will succeed.
- **Reviews move through a state machine, not a single write.** `create` opens a review in `PENDING` state with inline comments attached; `submit` finalizes it with a terminal `state` (`APPROVED`/`REQUEST_CHANGES`/`COMMENT`). A submitted review can be `dismiss`ed afterward, but never deleted — `delete` only removes a review that was never submitted.
- **Merging a PR does not auto-close linked issues.** Unlike GitHub, Gitea has no merge-triggers-close event. It does parse closing keywords (`Fixes #N`, `Closes #N`) in commit messages landing on the default branch, so a non-squash merge that preserves those commit messages may auto-close the issue — but a squash merge rewrites history into one commit, so survival of the keyword depends on the squash commit's message. Always call `issue_read method: "get"` on any referenced issue after merging to check whether it already closed before deciding to close it explicitly.
## Composing `gitea-labels-milestones`
Before any `pull_request_write` call that includes a `labels` or `milestone` parameter, resolve names/titles to numeric IDs via `gitea-labels-milestones` — `label_read method: "list_repo_labels"` for label name → ID, `milestone_read method: "list"` for milestone title → ID. Never pass a label name string or milestone title string directly to `pull_request_write`; both parameters take numeric IDs only. This skill does not duplicate that lookup logic — it composes the shared skill.
## Dispatch
| Task | Tool | method |
|---|---|---|
| List PRs | `list_pull_requests` | — |
| Get PR details | `pull_request_read` | `"get"` |
| Get PR diff | `pull_request_read` | `"get_diff"` |
| Get PR changed files | `pull_request_read` | `"get_files"` |
| Get PR CI status | `pull_request_read` | `"get_status"` |
| Get PR reviews | `pull_request_read` | `"get_reviews"` |
| Get one review | `pull_request_read` | `"get_review"` |
| Get review inline comments | `pull_request_read` | `"get_review_comments"` |
| Create a PR | `pull_request_write` | `"create"` |
| Update a PR | `pull_request_write` | `"update"` |
| Close a PR | `pull_request_write` | `"close"` |
| Reopen a PR | `pull_request_write` | `"reopen"` |
| Merge a PR | `pull_request_write` | `"merge"` |
| Update branch from base | `pull_request_write` | `"update_branch"` |
| Add reviewers | `pull_request_write` | `"add_reviewers"` |
| Remove reviewers | `pull_request_write` | `"remove_reviewers"` |
| Create a review | `pull_request_review_write` | `"create"` |
| Submit a review | `pull_request_review_write` | `"submit"` |
| Delete a review | `pull_request_review_write` | `"delete"` |
| Dismiss a review | `pull_request_review_write` | `"dismiss"` |
For full parameter detail on listing/reading/creating/updating/closing PRs, read `references/pull-requests.md`. For review-specific detail (create/submit/delete/dismiss, inline comment shape), read `references/reviews.md`. For the merge workflow specifically (CI gate, merge styles, branch cleanup, post-merge issue check), read `references/merging.md`.