docs: trim repeated boilerplate in git, gitea, and bin skills

Finding 13: five blocks of near-identical wording were repeated across
skills within a plugin — the gitea "resolve owner and repo" step (5
skills), the 404-masks-403 note (6 files), the manual pagination
explanation (8 files), the git plugin's main/master force-push refusal
(7 files, some with multiple internal restatements), and the bin
skills' domain-glossary/ADR paragraph (5 skills). Tightened each
instance in place — same meaning, fewer words — rather than extracting
to a shared file, which ADR-0014's one-file-per-skill install
constraint rules out. Left the three git skills' structured-result
JSON shapes alone (coupled to the separate, out-of-scope git-orchestrate
merge candidate, finding 19).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YR2CjVumUbEGWcMikcoXBD

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

@@ -16,30 +16,30 @@ metadata:
     - gitea-mcp-slim-go
     - context7-websites-gitea
     - context7-gitea-tea-cli
-  version: "0.1.5"
+  version: "0.1.6"
 
 allowed-tools: Bash mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write
 ---
 
 ## Gotchas
 
-- **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.
-- **Never assume a `Kind/*`/`Priority/*`/`Status/*` scope is exclusive — read each label's own `exclusive` field.** `list_repo_labels` returns it on every repo label, so it is always *readable* per label; `label_write` documents it as "(org only)" because it is only *settable* through the org create methods. Where it is `true` Gitea enforces one-per-scope itself, and replacing rather than stacking on a label whose `exclusive` is `false` destroys a valid label.
+- **Applying a label needs a numeric ID; issue/PR responses give only name strings.** Resolve name → ID with `label_read` first.
+- **`pull_request_read` returns `milestone` as a bare title string, `issue_read` as `{id, title}`.** Recover the ID by listing milestones and matching the title.
+- **Never assume a `Kind/*`/`Priority/*`/`Status/*` scope is exclusive — read each label's `exclusive` field.** `list_repo_labels` always returns it; `label_write` can only set it via org create methods ("org only"). `true` means Gitea enforces one-per-scope; replacing instead of stacking on a `false` label destroys a valid one.
 
 ## 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):
+Extract `owner` and `repo` from the git remote before any tool call (skip if an orchestrating caller already passed them in):
 
 ```bash
 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."
+No origin, or 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.
+The `*_org_label*` methods take `org`, not `owner`/`repo`. Pass that same `owner` as `org` — it's the org name whenever the owner is an organisation, which the remote URL doesn't say.
 
-Read the failure text before interpreting it. `list_org_labels` needs the `read:organization` token scope, which this skill's declared scopes (`write:issue`, `write:repository`) do not carry, so it fails with `token does not have at least one of required scope(s), required=[read:organization]` *before* it ever determines org-vs-user. Report that: the org pool went unchecked, not empty. Only a not-found response is evidence the owner is a user account with no org pool.
+Read the failure text before interpreting it: `list_org_labels` needs `read:organization`, which this skill's declared scopes don't carry, so it fails with a scope error *before* it ever checks org-vs-user. Report the unchecked scope, not an empty pool — only a genuine not-found means the owner is a user account with no org pool.
 
 ## Step 2 — Dispatch
 
@@ -58,6 +58,6 @@ Read the failure text before interpreting it. `list_org_labels` needs the `read:
 | Update / close a milestone | `milestone_write` | `"update"` |
 | Delete a milestone | `milestone_write` | `"delete"` |
 
-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.
+Every list method paginates manually (`per_page` default 30) — iterate `page: 1, 2, ...` until a page returns fewer than `per_page`. A truncated list silently breaks name → ID resolution.
 
 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`.

plugins/gitea/.apm/skills/gitea-labels-milestones/references/labels.md

@@ -51,8 +51,8 @@ runtime error from Gitea rather than a client-side validation error.
 label_read  method: "list_repo_labels"  owner: <owner>  repo: <repo>  per_page: 50
 ```
 
-Paginate (`page: 1, 2, ...`) until the returned count is less than `per_page`. This is the only way
-to build a complete name → ID map — there is no lookup-by-name endpoint.
+Paginate (`page: 1, 2, ...`) until the count is below `per_page` — the only way to build a complete
+name → ID map, since there's no lookup-by-name endpoint.
 
 Every returned repo label carries its own `exclusive` boolean, so exclusivity is always *readable*
 per repo label. That does not contradict `label_write`'s schema, which annotates `exclusive` as