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/skills/gitea-files/SKILL.md

@@ -11,7 +11,7 @@ compatibility: Requires the Gitea MCP server configured with a token scoped to a
   is not actually required for any of this domain's five tools.
 
 metadata:
-  version: "1.0.0"
+  version: "1.0.1"
   category: gitea
   source_keys:
     - gitea-mcp-repo
@@ -23,7 +23,7 @@ allowed-tools: mcp__gitea__get_file_contents mcp__gitea__get_dir_contents mcp__g
 
 ## Gotchas
 
-- **A 404 may mean an under-scoped token, not a missing path.** Every tool here gates on `write:repository`, and Gitea masks insufficient scope as 404. Check scopes first.
+- **404 may mean an under-scoped token, not a missing path.** These tools gate on `write:repository`; check scope before concluding the path is missing.
 - **Reads take `ref` (`tree_sha` on `get_repository_tree`), writes take `branch_name`.** One concept, three names — carry the wrong key and the branch is dropped.
 - **`content` is base64 both ways — except under `withLines: true`.** Encode before a write, decode after a read; but with `withLines: true` `content` is already plain JSON text and the reported `"encoding": "base64"` is a lie. Decoding it yields garbage.
 

plugins/gitea/skills/gitea-files/references/reading.md

@@ -32,8 +32,8 @@ size. No recursion, no content, no `sha`.
 `get_repository_tree(owner, repo, tree_sha, recursive)`. Set `recursive: true` to walk
 subdirectories in one call.
 
-The response sets `truncated: true` when one page does not hold every entry. Page through with
-`page`/`per_page` (defaults `1` and `30`) until a page returns fewer entries than `per_page`.
+The response sets `truncated: true` when one page doesn't hold every entry — page with
+`page`/`per_page` (defaults `1`/`30`) until a page returns fewer than `per_page`.
 
 ## Neither listing is a SHA source for a write
 
@@ -44,7 +44,6 @@ the canonical path for a write's SHA: one call returns the decoded content and t
 
 ## A 404 that is really a 403
 
-These reads gate on `write:repository`, not on read access alone, and some Gitea endpoints answer
-an under-scoped token with 404 instead of 403 so they do not leak whether the resource exists. A
-404 on a path you are confident about is a scope problem until proven otherwise — check the token's
-configured scopes before concluding the file or directory does not exist.
+These reads gate on `write:repository`; an under-scoped token gets 404 instead of 403 so the
+endpoint doesn't leak whether the resource exists. On a path you're confident about, check token
+scope before concluding it doesn't exist.