chore(gitea): regenerate the flat content mirror after the ADR-0020 retrofit

Generated output, not authored content: scripts/sync-plugin-content.sh --all.
Claude Code has no .apm/ awareness, so this compiled mirror must track .apm/ or
the check-plugin-content-sync pre-push hook reports drift.

Deferred to a single commit at the end of the wave on purpose. sync_dir runs
rm -rf before every copy, so running it while seven agents were editing the
same plugin would have raced them; agents were told not to sync for that reason.

Refs #99

plugins/gitea/skills/gitea-workflow/references/number-resolution.md

@@ -0,0 +1,19 @@
+---
+topic: number-resolution
+source_keys:
+  - gitea-mcp-repo
+  - gitea-mcp-slim-go
+  - context7-websites-gitea
+---
+
+# Resolving a bare issue-or-PR number
+
+The user has referenced a bare number without saying "issue" or "PR" (e.g. "what's going on with #42"). Resolve it with a real call — never dispatch to `gitea-issues` or `gitea-prs` by guessing from phrasing alone, because "that sounds like a bug" is not evidence and the two domains share one number space.
+
+1. Invoke `gitea-issues` to run `issue_read method: "get"` on that number.
+2. Check the response's `is_pull` field:
+   - `true` → it's a PR. Invoke `gitea-prs` for full PR detail (status, diff, reviews as appropriate to the request) and present that instead.
+   - `false` or absent → it's an issue. Present the issue detail already retrieved.
+3. If the resolution call 404s, don't conclude the number doesn't exist. Gitea hides permission errors as not-found (documented in `gitea-issues`' Gotchas), so report the 404 and suggest verifying the token carries `write:issue` rather than reporting "no such issue or PR."
+
+Then report per `SKILL.md`'s Report section, saying which domain the number turned out to be before showing detail ("That's a pull request:" / "That's an issue:") — otherwise the user cannot tell the resolution happened.

plugins/gitea/skills/gitea-workflow/references/skill-index.md

@@ -0,0 +1,22 @@
+---
+topic: skill-index
+source_keys:
+  - gitea-mcp-repo
+---
+
+# Domain-skill index
+
+The request names a capability but not obviously which skill owns it. Find the owner here, then invoke it:
+
+| Skill | Covers |
+|---|---|
+| `gitea-issues` | List/read/create/update issues, comments, search across issues and PRs. Composes `gitea-labels-milestones` for label/milestone resolution. |
+| `gitea-labels-milestones` | Label and milestone CRUD, label inference from conversation context, resolving names/titles to the numeric IDs writes require. Cross-cutting — used by both `gitea-issues` and `gitea-prs`. |
+| `gitea-prs` | List/read/create/update/merge PRs, code reviews. Composes `gitea-labels-milestones` the same way `gitea-issues` does. |
+| `gitea-branches` | Branch list/create/delete, plus commit history (list commits, get a single commit by SHA). |
+| `gitea-files` | Read/write/delete individual files, list a directory, walk the full repo tree. |
+| `gitea-releases` | Release and tag CRUD — draft/prerelease flags, release notes, semver tags. |
+
+A request that already names its own owner (e.g. "create a milestone" → `gitea-labels-milestones`, "read this file from the repo" → `gitea-files`) never needed this index — invoke that skill directly rather than routing through here.
+
+Then report per `SKILL.md`'s Report section: name the skill and hand off — don't duplicate its output format, let it report.

plugins/gitea/skills/gitea-workflow/references/sources.md

@@ -3,9 +3,9 @@
 ## gitea-mcp-repo
 
 - **URL:** https://gitea.com/gitea/gitea-mcp
-- **Description:** Official gitea-mcp repository (v1.3.0) — `operation/*.go` source files documenting all 55 MCP tools. This skill's status view relies on `list_issues`/`list_pull_requests` semantics (via `gitea-issues`/`gitea-prs`), and its ambiguous-number resolution relies on `issue_read`'s `is_pull` field, both verified against this source at authoring time.
+- **Description:** Official gitea-mcp repository (v1.3.0) — `operation/*.go` source files documenting all 55 MCP tools. This skill's status view relies on `list_issues`/`list_pull_requests` semantics (via `gitea-issues`/`gitea-prs`), its ambiguous-number resolution relies on `issue_read`'s `is_pull` field, and its domain-skill index groups that tool surface by owning skill — all verified against this source at authoring time.
 - **Research doc:** plugins/gitea/docs/research/docs/gitea/sources.md
-- **Contributing files:** SKILL.md
+- **Contributing files:** references/status-checkin.md, references/number-resolution.md, references/skill-index.md
 - **Status:** `extracted`
 
 ## gitea-mcp-slim-go
@@ -13,7 +13,7 @@
 - **URL:** https://gitea.com/gitea/gitea-mcp/raw/branch/main/operation/issue/slim.go
 - **Description:** Slim response shape structs from gitea-mcp source — confirms `is_pull` is present on a single-item `issue_read` response, the field this skill's resolution step depends on to distinguish an issue from a PR sharing the same number.
 - **Research doc:** plugins/gitea/docs/research/docs/gitea/sources.md
-- **Contributing files:** SKILL.md
+- **Contributing files:** references/number-resolution.md
 - **Status:** `extracted`
 
 ## context7-websites-gitea
@@ -21,7 +21,7 @@
 - **URL:** context7:/websites/gitea
 - **Description:** Official Gitea docs mirror on Context7 — confirms issues and pull requests share a single per-repository number sequence, and that Gitea returns 404 for permission failures rather than a distinct 403, both facts this skill's resolution and error-handling steps depend on.
 - **Research doc:** plugins/gitea/docs/research/docs/gitea/sources.md
-- **Contributing files:** SKILL.md
+- **Contributing files:** references/number-resolution.md
 - **Status:** `extracted`
 
 ## context7-gitea-tea-cli

plugins/gitea/skills/gitea-workflow/references/status-checkin.md

@@ -0,0 +1,15 @@
+---
+topic: status-checkin
+source_keys:
+  - gitea-mcp-repo
+---
+
+# Status check-in (invoked with no request)
+
+Give a repo status check-in:
+
+1. Invoke `gitea-issues` to list open issues (`state: "open"`).
+2. Invoke `gitea-prs` to list open PRs (`state: "open"`). Run this alongside step 1 — the two are independent reads, so serialising them only adds latency.
+3. Report as two sections, "Open Issues" and "Open Pull Requests", each a compact list of number and title.
+
+Then report per `SKILL.md`'s Report section.