fix(gitea): make gitea-releases executable and correct misleading domain claims

gitea-releases was the weakest skill in the plugin: no allowed-tools, no
owner/repo resolution, and a checkbox list where a dispatch table belongs, so
an agent reaching it had to guess both its permissions and its inputs. The
id-vs-tag_name trap — deleting by tag name where the API wants the numeric id —
is restored as an explicit Gotcha because it destroys the wrong release
silently.

Elsewhere the `exclusive` flag was documented on the wrong side of the
read/write split, and label data from one instance was presented as though it
were universal, which invites an agent to assume a taxonomy that does not
exist on the target repo. rename_branch was missing from the branch surface.
Reference prose and fences are cleaned up in passing.

plugins/gitea/skills/gitea-prs/README.md

@@ -8,11 +8,17 @@ This skill handles the pull request lifecycle within the Gitea integration suite
 
 ## Usage
 
-```
+```text
 /gitea-prs
 ```
 
-Describe the PR or review task: list PRs, get a PR's status/diff/reviews, create or update a PR, merge one, or create/submit/dismiss a code review. The skill will determine owner/repo from context and resolve any label or milestone names via `gitea-labels-milestones` before writing them.
+Describe the PR or review task: list PRs, get a PR's status/diff/reviews, create or update a PR, merge one, or create/submit/dismiss a code review. The skill resolves `owner`/`repo` from the `origin` git remote (or takes them from an orchestrating caller) and resolves any label or milestone names via `gitea-labels-milestones` before writing them.
+
+## Before you start
+
+Requires a Gitea MCP server configured with a token holding `write:issue` + `write:repository`.
+Requires a git remote named `origin` pointing at the Gitea instance, unless an orchestrating caller
+(e.g. `gitea-workflow`) already resolved `owner`/`repo` for you.
 
 ## Files
 

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

@@ -5,7 +5,10 @@ description: >
   Use when listing, reading, creating, updating, merging, or reviewing Gitea pull requests — even
   when the user does not say "Gitea". Not issues -> `gitea-issues`.
 
-compatibility: Requires Gitea MCP server configured with write:issue and write:repository token scopes.
+compatibility: Requires Gitea MCP server configured with write:issue and write:repository token
+  scopes. Requires git remote "origin" pointing to the Gitea instance for owner/repo resolution when
+  invoked directly by a human; an orchestrating caller (e.g. gitea-workflow) may pass owner/repo
+  already resolved.
 
 metadata:
   category: integration
@@ -16,7 +19,7 @@ metadata:
     - context7-gitea-tea-cli
   version: "0.1.2"
 
-allowed-tools: mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__pull_request_review_write
+allowed-tools: Bash mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__pull_request_review_write
 ---
 
 ## Gotchas
@@ -24,9 +27,19 @@ allowed-tools: mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp_
 - **Issues and PRs share one number space.** `#42` may be an issue rather than a PR. When unsure, call `pull_request_read method: "get"` and read a 404 as "that number is an issue" — hand it to `gitea-issues`.
 - **`pull_request_write method: "create"` discards most optional parameters in silence.** `milestone`, `assignee`, `assignees`, `reviewers` and `team_reviewers` are accepted, dropped, and left out of the response, so a drop is indistinguishable from never passing them. `labels` *does* apply on `"create"`, so labels landing is no evidence the milestone did.
 
-## Dispatch
+## Step 1 — Resolve owner and repo
 
-Resolve `owner` and `repo` from context first, and confirm the number names a PR before writing to it.
+Extract them from the git remote before any tool call, skipping this when an orchestrating caller already passed them in:
+
+```bash
+git remote get-url origin
+```
+
+If origin is not set or the URL is not a Gitea URL, stop and report: "No Gitea remote found — set origin to your Gitea instance URL."
+
+## Step 2 — Dispatch
+
+Confirm the number names a PR, not an issue, before writing to it.
 
 | Task | Tool | Reference |
 |---|---|---|
@@ -36,11 +49,9 @@ Resolve `owner` and `repo` from context first, and confirm the number names a PR
 | Merge a PR, or judge whether it can merge | `pull_request_write method: "merge"` | `references/merging.md` |
 | Read, create, submit, dismiss or delete a code review, or reply to and resolve a review comment thread | `pull_request_read`, `pull_request_review_write` | `references/reviews.md` |
 
-Whatever `"create"` dropped takes a second call once the PR exists — `"update"` for milestone and assignees, `"add_reviewers"` for reviewers.
-
 Read the reference for the row you land on before making the call. Each carries the parameter signatures, the per-method behaviour and the response-shape quirks the row cannot, and every write method has at least one parameter that behaves differently from its issue-side counterpart.
 
-## Resolving labels and milestones
+## Step 3 — Resolving labels and milestones
 
 `labels` and `milestone` take numeric IDs, never name or title strings. Before a `pull_request_write` call carrying either, resolve them through `gitea-labels-milestones`: `label_read method: "list_repo_labels"` for a label name, `milestone_read method: "list"` for a milestone title.
 

plugins/gitea/skills/gitea-prs/references/pull-requests.md

@@ -68,7 +68,7 @@ List responses trim PRs down to summary fields — `head`/`base` are bare ref st
 
 Merge-specific parameters (`merge_style`, `delete_branch`, `force_merge`, `merge_when_checks_succeed`, `head_commit_id`, `message` as merge commit message) are covered in `references/merging.md`.
 
-**`"create"` silently drops most optional parameters.** `"create"` reads only `owner`, `repo`, `title`, `body`, `head`, `base`, `draft`, `labels`, and `deadline`. Every other optional parameter — including `assignee`, `assignees`, `milestone`, `reviewers`, `team_reviewers` and `remove_deadline` — is accepted without error and discarded. There is no error, no warning, and nothing in the response distinguishing a dropped parameter from one that was never passed: the response simply omits the key. Setting any of them requires a second call after the PR exists — `"update"` for `assignee`/`assignees`/`milestone`, `"add_reviewers"` for `reviewers`/`team_reviewers`.
+**`"create"` silently drops most optional parameters.** `"create"` reads only `owner`, `repo`, `title`, `body`, `head`, `base`, `draft`, `labels`, and `deadline`. Every other optional parameter — including `assignee`, `assignees`, `milestone`, `reviewers`, `team_reviewers` and `remove_deadline` — is accepted without error and discarded. Nothing marks the drop: no error, no warning, and nothing in the response distinguishing a dropped parameter from one that was never passed — the response simply omits the key. Setting any of them requires a second call after the PR exists — `"update"` for `assignee`/`assignees`/`milestone`, `"add_reviewers"` for `reviewers`/`team_reviewers`.
 
 Two things make this easy to miss: