From 37382cb72a0a8b72bdbb5fa62d870880e35dc029 Mon Sep 17 00:00:00 2001 From: Defame1297 Date: Sun, 30 Aug 2026 12:29:18 +0000 Subject: [PATCH] refactor(gitea-labels-milestones): retrofit to the ADR-0020 context contract Description 835 -> 214 chars, body 669 -> 426 words, Gotchas 8 entries/63% of body -> 3/20.4%. Clears the description FAIL, all three Vale CompositionNote errors and both Gotchas suggestions. 63% was the worst Gotchas ratio in the corpus. Cut the composition sentence to README -- it changes no routing decision and an agent picks this skill because the user asked about labels, not because two other skills call it. Cut the capability enumeration; 'list, create, edit, delete' decompose 'reading or writing' and add no trigger. Boundary clauses are now one arrow per target. The resolver extracts only the first name per arrow clause, so the previous '-> gitea-issues / gitea-prs' left gitea-prs neither dangling nor checked while validate.sh reported 1 of 1. Now 2 of 2. Makes org-scoped label resolution executable. The org label pool was reachable in principle -- four *_org_label* methods, and a claim to own name-to-ID resolution -- but list_org_labels takes org, and Step 1 derived only owner and repo, so both resolution procedures stalled at the fallback. Fixed once at the identity step rather than per-procedure. get_user_orgs is outside allowed-tools, so the failing call is the discriminator: a failure means the owner is a user account with no org pool, which is an answer, not an error. Corrects a Gotcha that was false for create_repo_label/create_org_label and collided with the literal tool name label_write. Same false claim removed from README. Refs #99 --- .../skills/gitea-labels-milestones/README.md | 8 ++++- .../skills/gitea-labels-milestones/SKILL.md | 34 +++++++------------ .../references/label-inference.md | 6 +++- .../references/labels.md | 12 +++++-- 4 files changed, 34 insertions(+), 26 deletions(-) diff --git a/plugins/gitea/.apm/skills/gitea-labels-milestones/README.md b/plugins/gitea/.apm/skills/gitea-labels-milestones/README.md index 30fb502..d509c71 100644 --- a/plugins/gitea/.apm/skills/gitea-labels-milestones/README.md +++ b/plugins/gitea/.apm/skills/gitea-labels-milestones/README.md @@ -4,7 +4,13 @@ Read and write Gitea labels and milestones, and resolve label/milestone identity ## What it does -This skill handles label and milestone CRUD (`label_read`/`label_write`, `milestone_read`/`milestone_write`) — listing repo or org labels, creating/editing/deleting a label, resolving a label name to the numeric ID required for any write, and listing/creating/updating/closing/deleting a milestone. It also owns label inference: mapping conversation context (bug report, feature request, urgency language) to this repo's `Kind/*`/`Priority/*`/`Status/*` taxonomy. It is a cross-cutting shared skill composed by `gitea-issues` and `gitea-prs`, which call into it for label/milestone resolution before their own `issue_write`/`pull_request_write` calls apply the resolved IDs. +This skill handles label and milestone CRUD (`label_read`/`label_write`, `milestone_read`/`milestone_write`) — listing repo or org labels, creating/editing/deleting a label, resolving a label name to the numeric ID required to apply it to an issue or PR, and listing/creating/updating/closing/deleting a milestone. It also owns label inference: mapping conversation context (bug report, feature request, urgency language) to this repo's `Kind/*`/`Priority/*`/`Status/*` taxonomy. + +## Composition + +This is a cross-cutting shared skill. `gitea-issues` and `gitea-prs` both compose it whenever they need to apply a label or assign a milestone, rather than duplicating label/milestone logic: they call in for name/title → ID resolution, then their own `issue_write`/`pull_request_write` calls apply the resolved IDs. The split is deliberate — identity resolution lives here once, and the write that attaches an ID to a specific issue or PR lives with the skill that owns that object. + +That relationship is documented here rather than in the skill description, which is preloaded into every session and carries routing information only: an agent reaches this skill because the user asked about labels or milestones, not because two other skills call it. ## Usage diff --git a/plugins/gitea/.apm/skills/gitea-labels-milestones/SKILL.md b/plugins/gitea/.apm/skills/gitea-labels-milestones/SKILL.md index b9844dc..67fd8d8 100644 --- a/plugins/gitea/.apm/skills/gitea-labels-milestones/SKILL.md +++ b/plugins/gitea/.apm/skills/gitea-labels-milestones/SKILL.md @@ -2,15 +2,9 @@ name: gitea-labels-milestones description: > - 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. + Use when reading or writing Gitea labels or milestones — resolve names to IDs, or infer + labels — even when the user does not say "Gitea". + Not applying them to an issue -> `gitea-issues`. Not to a PR -> `gitea-prs`. compatibility: Requires Gitea MCP server configured with write:issue and write:repository token scopes. @@ -21,23 +15,18 @@ metadata: - gitea-mcp-slim-go - context7-websites-gitea - context7-gitea-tea-cli - version: "0.1.1" + version: "0.1.4" allowed-tools: 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. +- **Applying a label takes a numeric ID, but issue/PR responses slim labels down to name strings.** An issue's existing labels yield no IDs — resolve name → ID with `label_read`. +- **`pull_request_read` returns `milestone` as a bare title string** where `issue_read` returns `{id, title}` — recover the milestone's ID by listing milestones and matching the title. +- **`Kind/*`/`Priority/*`/`Status/*` exclusivity is a client-side convention.** `exclusive` is an org-labels-only flag, so applying a label in such a scope must replace the one already there, not stack on it. -## Step 1 — Resolve owner and repo +## Step 1 — Resolve owner, repo and org Before any tool call, extract `owner` and `repo` from the git remote (skip this if an orchestrating caller already passed them in): @@ -47,10 +36,13 @@ 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." +The `*_org_label*` methods take `org`, not `owner`/`repo`. Pass that same `owner` as `org` — it is the org name whenever the owner is an organisation, and the remote URL does not say whether it is one. So let the call itself decide: a failure means the owner is a user account with no org label pool, which is an answer, not an error to report. + ## Step 2 — Dispatch | Task | Tool | method | |---|---|---| +| Resolve a label name to its ID | `label_read` | `"list_repo_labels"`, then `"list_org_labels"` | | 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"` | @@ -63,6 +55,6 @@ If origin is not set or the URL is not a Gitea URL, stop and report: "No Gitea r | 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`. +Every list method paginates manually — `per_page` defaults to 30, so iterate `page: 1, 2, ...` until a page returns fewer results than `per_page`. A truncated list silently breaks name → ID resolution. -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`). +If the task is a label operation, read `references/labels.md`; if a milestone operation, read `references/milestones.md`. If the label to apply has to be derived from conversation context rather than named, read `references/label-inference.md`. diff --git a/plugins/gitea/.apm/skills/gitea-labels-milestones/references/label-inference.md b/plugins/gitea/.apm/skills/gitea-labels-milestones/references/label-inference.md index ba4665b..0f7ddab 100644 --- a/plugins/gitea/.apm/skills/gitea-labels-milestones/references/label-inference.md +++ b/plugins/gitea/.apm/skills/gitea-labels-milestones/references/label-inference.md @@ -57,7 +57,11 @@ scope applied at once. 1. Read the conversation context (issue/PR title, body, or the triggering discussion) for the signals above. 2. Call `label_read method: "list_repo_labels"` (see `references/labels.md`) to get the current - label set with IDs — inference must never guess an ID, only a name, then resolve it. + label set with IDs — inference must never guess an ID, only a name, then resolve it. Because + `exclusive` is an org-labels-only flag, this taxonomy plausibly lives at org scope too: for any + inferred name absent from the repo pool, also call `label_read method: "list_org_labels"` with + `org` set to the repo's `owner` before treating it as unresolved. A failure there means the owner + is a user account, not an organisation, so no org pool exists and the name is genuinely absent. 3. Match inferred label names against the resolved list (case-insensitive). If a scope group already has a different label applied on the target and a new one is inferred for that same scope, plan to replace rather than add (see above). diff --git a/plugins/gitea/.apm/skills/gitea-labels-milestones/references/labels.md b/plugins/gitea/.apm/skills/gitea-labels-milestones/references/labels.md index 56b129e..63939f4 100644 --- a/plugins/gitea/.apm/skills/gitea-labels-milestones/references/labels.md +++ b/plugins/gitea/.apm/skills/gitea-labels-milestones/references/labels.md @@ -62,9 +62,15 @@ label_read method: "get_repo_label" owner: repo: id: ## Resolve a name to an ID There is no direct name lookup. List all repo labels (paginating if needed), scan for a -case-insensitive name match, and extract `id`. This is the required first step before any label -application on an issue or PR — the actual `add_labels`/`replace_labels`/`remove_label` call lives -in `gitea-issues`/`gitea-prs` via `issue_write`/`pull_request_write`, which take numeric IDs only. +case-insensitive name match, and extract `id`. Both pools can apply to one issue: if the name is +not in `list_repo_labels`, also check `list_org_labels` before reporting it unresolved. That method +takes `org`, not `owner`/`repo` — pass the repo's `owner` as `org`, which is what it means when the +owner is an organisation. If that call fails, the owner is a user account, there is no org pool, and +the miss is a real miss. + +Resolution is the required first step before any label application on an issue or PR — the actual +`add_labels`/`replace_labels`/`remove_label` call lives in `gitea-issues`/`gitea-prs` via +`issue_write`/`pull_request_write`, which take numeric IDs only. ## Create a label