Defame1297
ed8c99efbd
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
3.6 KiB
3.6 KiB
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 — even when the user does not say "Gitea". A number the user names may be an issue or a PR — they share one number space — so confirm which domain applies before dispatching. Not issues -> `gitea-issues`. Not branch or commit operations -> `gitea-branches`. | 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_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.
#42may be an issue rather than a PR. When unsure, callpull_request_read method: "get"and read a 404 as "that number is an issue" — hand it togitea-issues. pull_request_write method: "create"discards most optional parameters in silence.milestone,assignee,assignees,reviewersandteam_reviewersare accepted, dropped, and left out of the response, so a drop is indistinguishable from never passing them.labelsdoes apply on"create", so labels landing is no evidence the milestone did.
Step 1 — Resolve owner and repo
Extract them from the git remote before any tool call, skipping this when an orchestrating caller already passed them in:
rtk 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 |
|---|---|---|
| List PRs; read a PR's details, diff, changed files or CI status | list_pull_requests, pull_request_read |
references/pull-requests.md |
| Create a PR — subject to the silent-drop Gotcha above | pull_request_write |
references/pull-requests.md |
| Update, close, reopen or retarget a PR, sync it with its base, or add/remove reviewers | pull_request_write |
references/pull-requests.md |
| 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 |
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.
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.
Resolve a milestone only when the call is an "update" — on "create" the lookup is wasted, per the Gotcha above. Recovering an existing PR's milestone ID needs the same lookup, because pull_request_read returns milestone as a bare title string and never an ID.