holocron/plugins/gitea/skills/gitea-labels-milestones/SKILL.md

name, description, compatibility, metadata, allowed-tools

name	description	compatibility	metadata	allowed-tools
gitea-labels-milestones	Use when reading or writing Gitea labels or milestones — listing repo/org labels, creating, editing, or deleting a label, resolving label names to the numeric IDs required for applying them to an issue or PR, or listing, creating, updating, closing, or deleting a milestone. This is a cross-cutting shared skill: `gitea-issues` and `gitea-prs` both compose it whenever they need to apply labels or assign a milestone, rather than duplicating label/milestone logic. Also use for label inference — mapping a bug report, feature request, or urgency signal in conversation context to the repo's `Kind/*`/`Priority/*`/`Status/*` label taxonomy. Do not use for applying already-resolved label IDs or milestone IDs to a specific issue or PR — that write goes through `issue_write`/`pull_request_write` in `gitea-issues`/`gitea-prs`, not here.	Requires Gitea MCP server configured with write:issue and write:repository token scopes.	category source_keys version integration gitea-mcp-repo gitea-mcp-slim-go context7-websites-gitea context7-gitea-tea-cli 0.1.1	Bash mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write

Gotchas

• Label writes take IDs, reads return names. label_read is the only tool that returns full label objects (id, name, color, description). Issue/PR responses slim labels down to name strings. Before any label is applied to an issue or PR (in gitea-issues/gitea-prs), resolve names → IDs here via label_read method: "list_repo_labels" — never pass a name string where an ID is expected.
• Milestones are referenced by ID everywhere, never by title. milestone_write update/delete take id. The one place titles show up as the sole handle is the pull_request_read response (see next gotcha).
• Milestone representation differs between issues and PRs. issue_read returns milestone: {id, title} — an object. pull_request_read returns milestone: "title string" — title only, no ID. You cannot recover a milestone ID from a PR response directly; call milestone_read method: "list" and match by title instead.
• Repo labels and org labels are separate pools, never mixed in one call. label_read/label_write take either owner+repo (repo-scoped methods) or org (org-scoped methods) — passing both or neither for a given method is a caller error, not something the schema enforces for you. Repo and org labels can both apply to the same issue, but you list/create/edit them through different method values.
• milestone_write accepts "update" and "edit" as the same operation. Both method values map to the identical update call. Prefer "update" for consistency with issue_write/pull_request_write.
• exclusive is documented as an org-labels-only flag — it isn't what enforces exclusivity here. Gitea's docs scope the settable/server-enforced exclusive flag to org labels only, and the live label_write schema for create_repo_label/edit_repo_label doesn't document accepting it at all. This repo's Kind/*, Priority/*, Status/* groups still behave as one-label-per-scope, but that's a manually-enforced convention this skill implements client-side, not a guaranteed server behavior for repo labels: applying a new label within a scope (e.g. Priority/High) must replace any existing label in that same scope, not add alongside it, and nothing on the server enforces that for you. Label inference (see references/label-inference.md) must respect this — replace, don't stack.
• Pagination is manual on every list call. label_read and milestone_read both default to per_page: 30. Iterate page: 1, 2, ... until the result count is less than per_page — there is no cursor or auto-pagination.
• Schema requiredness differs between the two tool families. milestone_read/milestone_write have owner and repo as hard-required parameters (the call fails validation without them). label_read/label_write only hard-require method — owner/repo/org are functionally required per method but not schema-enforced, so passing none produces a runtime error from Gitea, not a client-side validation error.

Step 1 — Resolve owner and repo

Before any tool call, extract owner and repo from the git remote (skip this if an orchestrating caller already passed them in):

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

Task	Tool	method
List repo labels	label_read	"list_repo_labels"
Get one repo label by ID	label_read	"get_repo_label"
List org labels	label_read	"list_org_labels"
Create a repo/org label	label_write	"create_repo_label" / "create_org_label"
Edit a repo/org label	label_write	"edit_repo_label" / "edit_org_label"
Delete a repo/org label	label_write	"delete_repo_label" / "delete_org_label"
List milestones	milestone_read	"list"
Get one milestone by ID	milestone_read	"get"
Create a milestone	milestone_write	"create"
Update / close a milestone	milestone_write	"update"
Delete a milestone	milestone_write	"delete"

For full parameter detail and step-by-step call sequences, read references/labels.md (label operations) or references/milestones.md (milestone operations). For mapping conversation context to a label to apply, read references/label-inference.md.

Applying resolved label IDs or a milestone ID to a specific issue or PR is out of scope here — that's issue_write/pull_request_write in the composing skill (gitea-issues/gitea-prs).