fix(gitea): restore routing and sourcing content the retrofit dropped
gitea-issues asserted flatly that a merge never closes an issue, contradicting gitea-prs' references/merging.md, which documents that closing keywords in commits landing on the default branch do close one. The qualifier that made the claim true had been deleted; both sides now agree. gitea-releases had lost an epistemic hedge and its verification step, leaving conventions.md asserting unconfirmed tag auto-creation as fact. Nothing in the research corpus sources it, so the hedge and the verify-afterward instruction are back rather than upgraded. Descriptions were cut 50-240 chars under the 400 budget and shed routing with them: gitea-workflow's boundary named no target, gitea-prs lost the issue/PR number-space directive the suite is built around at 163/400, gitea-releases lost its boundary and every trigger. Restored, inside budget. Also restores delete_branch's hard-refusal strength and gitea-files' Read/Write/Edit pointer. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EJJrm5YmacbwMdzZpXcoti
This commit is contained in:
@@ -2,8 +2,9 @@
|
||||
name: gitea-issues
|
||||
|
||||
description: >
|
||||
Use when reading or writing Gitea issues — even when the user does not say "Gitea".
|
||||
Not pull requests -> `gitea-prs`.
|
||||
Use when reading or writing Gitea issues — "create an issue", "what issues are open",
|
||||
"close issue #N", "comment on issue #N", "search issues for X" — even when the user does not
|
||||
say "Gitea". Not pull requests -> `gitea-prs`.
|
||||
Not label or milestone definitions -> `gitea-labels-milestones`.
|
||||
|
||||
compatibility: Requires Gitea MCP server configured with write:issue and write:repository token
|
||||
@@ -25,14 +26,14 @@ allowed-tools: Bash mcp__gitea__list_issues mcp__gitea__issue_read mcp__gitea__i
|
||||
|
||||
## Gotchas
|
||||
|
||||
- **`list_issues` mixes in PRs unless you filter.** Issues and PRs share one repo number space; pass `type: "issues"` to exclude PRs (or `"pulls"` for only PRs). Nothing on a list item flags which is which — `is_pull` appears only on `issue_read method: "get"`, never on a list item.
|
||||
- **`list_issues` mixes in PRs unless you filter.** Issues and PRs share one repo number space; pass `type: "issues"` to exclude PRs (or `"pulls"` for only PRs). Nothing on a list item flags which is which — `is_pull` appears only on `issue_read method: "get"`.
|
||||
- **Label IDs and names are not interchangeable.** `issue_write` takes numeric IDs only; `list_issues` and `search_issues` filter by name; `issue_read "get"` returns names but `"get_labels"` returns full objects with IDs. Resolve via `gitea-labels-milestones` unless the caller named exact labels.
|
||||
- **A merged PR leaves its issue open.** Gitea does not auto-close on merge the way GitHub does. Re-read the issue's state after a merge before closing it manually.
|
||||
- **A merge does not itself close the issue.** Gitea has no close-on-merge event, but a `Fixes #N` in the merged commits can, depending on merge style (`gitea-prs`). Re-read its state after a merge before closing it manually.
|
||||
- **A 404 may really be a 403.** Gitea hides permission errors as not-found — check the token's `write:issue` scope before concluding the issue does not exist.
|
||||
|
||||
## Step 1 — Resolve owner and repo
|
||||
|
||||
An orchestrating caller may pass `owner` and `repo` in already; if so, skip this. The `search` row is cross-repository and needs only a query, so it skips this too. Otherwise, before any tool call:
|
||||
An orchestrating caller may pass `owner` and `repo` in already, and the `search` row is cross-repository and needs only a query — both skip this step. Otherwise, before any tool call:
|
||||
|
||||
```bash
|
||||
git remote get-url origin
|
||||
@@ -58,7 +59,7 @@ One invocation takes one row. Read only the reference(s) that row names — the
|
||||
|
||||
## Step 3 — Create
|
||||
|
||||
Only the create flow reaches this step; every other row goes straight to its reference.
|
||||
Only the create flow reaches this step.
|
||||
|
||||
1. Take `title` and `body` from conversation context — the most recent task, bug report, or explicit statement. An empty body is an acceptable fallback, an invented one is not.
|
||||
2. Run the enrichments in `references/enrichments.md`, then create with the resolved IDs per `references/issues.md`. Omitting a parameter always beats guessing its value — a wrong milestone or assignee is harder to notice than a missing one.
|
||||
|
||||
Reference in New Issue
Block a user