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

name, description, compatibility, metadata, allowed-tools

name	description	compatibility	metadata	allowed-tools
gitea-prs	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.	Requires Gitea MCP server configured with write:issue and write:repository token scopes.	category source_keys version integration gitea-mcp-repo gitea-mcp-slim-go context7-websites-gitea context7-gitea-tea-cli 0.1.0	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 dismissed 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.