The #113 sweep rested on CLAUDE.md's premise that rtk either filters or passes through unchanged, so prefixing is always safe. Measured against rtk 0.42.4, that premise is false for several of the commands the sweep prefixed, and two skills were left giving wrong answers silently. Why: - `rtk git worktree list --porcelain -z` discards both flags and renders its own format. The `locked`/`lock_reason` fields git-worktrees Step 2 must emit are absent entirely, and paths under $HOME are abbreviated to `~/`. - `rtk git branch --list <name>` prints a phantom `* ` line even when nothing matches, so git-branches' stated ambiguity test — "output from both means the name is ambiguous" — reported every name as ambiguous. `tag --list` is a clean passthrough, so only one half broke. - `rtk git diff --name-only`/`--name-status` append a `Changes:` trailer to output documented as "one per line"; `--word-diff` emits none of the `[-removed-] {+added+}` markers its table describes; `rtk git log -L` truncates each line at ~72 chars, on the one command whose purpose is showing line content. - `rtk git stash pop` prints only `FAILED: git stash pop`, swallowing the conflict diagnostic and retained-entry message the surrounding prose tells the agent to rely on. Implementation notes: - Eleven sites reverted to bare `git`, each carrying its reason inline so the next sweep does not undo it. `mergetool` and `rebase -i` are reverted on clause 3's interactive limb only: the TTY defect does not reproduce — rtk filters exactly twelve subcommands and execs the rest — and ADR-0023 records that measurement rather than a convenient one. - ADR-0023 states the rule repo-wide with a third clause: a command whose output the skill parses, or which is interactive, stays bare. `plugins/git/README.md` is reduced to a pointer; its claim that gitea skills "contain no git/rtk mentions at all" was false, and its citation of `hard-rules.md` pointed at a file containing no occurrence of "rtk". - Eight gitea sites swept, all verified byte-identical passthroughs first. - `scripts/check-rtk-prefix.sh` gates clause 1. Run against main's pre-sweep corpus it reports 99 findings including every gitea site, so it would have caught the drift #113 was filed about. Impact: the gate covers clause 1 only, in shell-tagged fences and the opening span of Run cells. Clause 2 is not gateable — "Run `git switch`" and "`git switch` refuses" are the same tokens — and prose bullets are invisible to it. Both limits are recorded in gates.md rather than left implied. Refs: #113 ADR: 0023 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
4.6 KiB
name, description, compatibility, metadata, allowed-tools
| name | description | compatibility | metadata | allowed-tools | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| gitea-issues | Use when reading or writing Gitea issues — "create an issue", "what issues are open", "close issue #N", "comment on issue #N", "label 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`. | 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. |
|
Bash mcp__gitea__list_issues mcp__gitea__issue_read mcp__gitea__issue_write mcp__gitea__search_issues |
Gotchas
list_issuesmixes in PRs unless you filter. Issues and PRs share one number space; passtype: "issues"to exclude PRs (or"pulls").is_pullis returned only byissue_read method: "get"— on a list item the only tell ishtml_url's path segment (/issues/vs/pulls/).- Label IDs and names are not interchangeable.
issue_writetakes numeric IDs only;list_issuesandsearch_issuesfilter by name;issue_read "get"returns names but"get_labels"returns full objects with IDs. Resolve viagitea-labels-milestonesunless the caller named exact labels. - A merge does not itself close the issue. Gitea has no close-on-merge event, but a
Fixes #Nin 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:issuescope before concluding the issue does not exist.
Step 1 — Resolve owner and repo
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:
rtk git remote get-url origin
If origin is unset 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
One invocation takes one row. Read only the reference(s) that row names — the call signatures were verified against the live MCP schema and differ from the published API docs in ways the body does not restate.
| Invocation | Flow | Read |
|---|---|---|
/gitea-issues or /gitea-issues list |
List issues with type: "issues" so PRs are excluded, optionally filtered by state |
references/issues.md |
/gitea-issues <N> |
Get one issue, routing to gitea-prs when the number turns out to be a PR |
references/issues.md |
/gitea-issues <N> comments |
Get an issue's comments | references/issues.md |
/gitea-issues <N> labels |
Get an issue's labels as full objects, IDs included | references/issues.md |
/gitea-issues close <N> |
Close an issue by updating its state | references/issues.md |
/gitea-issues comment <N> |
Add a comment drawn from conversation context, never one invented to fill the gap — a comment on a live issue is not cheap to undo | references/issues.md |
/gitea-issues label <N> |
Apply, replace or remove labels using IDs resolved by gitea-labels-milestones |
references/issues.md |
/gitea-issues create |
Create an issue — Step 3 first | references/enrichments.md, then references/issues.md |
/gitea-issues search <query> |
Cross-repo search, narrowed by owner, state, type or labels | references/search.md |
Step 3 — Create
Only the create flow reaches this step.
- Take
titleandbodyfrom conversation context — the most recent task, bug report, or explicit statement. An empty body is an acceptable fallback, an invented one is not. - Run the enrichments in
references/enrichments.md, then create with the resolved IDs perreferences/issues.md. Omitting a parameter always beats guessing its value — a wrong milestone or assignee is harder to notice than a missing one. - Fire immediately, with no confirmation step. A create is cheap to undo by closing, so a gate here only costs a round trip.
Step 4 — Report
Reads: a compact table or numbered list — number, title, state, labels, milestone.
Writes: what was created or updated, with the issue number and the URL when one is returned.
Errors: the HTTP code and message as returned, without paraphrasing either.