Defame1297
3920dfab20
Closes four PR #135 review findings in skill content. #2 — plugins/git/config.example.json was deleted inf5e4d0d, but four git-plugin files still told the agent to read it. The file only ever carried branching_pattern, commit_style and rebase_strategy, so the `base_branch` and scope instructions were wrong even before the deletion. Each site now describes what the skill actually does: base is `main` under GitHub Flow or `develop` when Gitflow is inferred, the Gitflow fallback keys off the repo's own branches, the orchestrator contract's `base` defaults to the inferred base branch, and the commit scope is inferred from the changed files. N6 — gitea-prs was the one gitea skill with no permission-scope caveat on a 404. Added one alongside the existing issue/PR number-space guidance rather than replacing it: a 404 is only evidence of "that number is an issue" once write:repository scope is confirmed. N4 — plugins/kyberforge/bin/README.md pointed at `.mcp.json`, but all six plugin-root .mcp.json files were deleted inc96ca9c(ADR-0018). ${CLAUDE_PLUGIN_ROOT} itself is still live, so the sentence now points at .apm/hooks/hooks.json, which kyberforge's own hook already uses. N7 — not applied. The finding claimed a marketplace field override emits a verbose BuildDiagnostic that `apm pack -v` surfaces, so "silently wins" was wrong. apm 0.28.0 does construct the diagnostic in marketplace/output_mappers.py, but nothing renders it: _render_marketplace_result in commands/pack.py iterates `warnings` only, and BuildReport.diagnostics has no consumer. Confirmed on a fixture — neither `apm pack -v` nor APM_LOG_LEVEL=DEBUG prints the override, and --check-versions reports [matches]. The existing wording in configure.md and marketplace.md is correct, so both are unchanged. Version bumps required by check-skill-version-bump.sh: git-branches 1.0.4 -> 1.0.5, git-commits 0.1.6 -> 0.1.7, gitea-prs 0.1.4 -> 0.1.5. bin/README.md is outside any skill directory and needs no bump. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01NwD8Egs5r4ndqeFLmhusX2
3.8 KiB
3.8 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. - 404 may also mean 403. Gitea masks permission errors as not-found, so a 404 is only evidence of an issue-not-PR once
write:repositoryscope is confirmed — check the token scope before reporting a PR missing or handing the number 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 from the git remote before any tool call, skipping this when an orchestrating caller already passed them in:
rtk git remote get-url origin
No origin, or 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.