fix(skills): drop references to deleted config and .mcp.json files

Closes four PR #135 review findings in skill content.

#2 — plugins/git/config.example.json was deleted in f5e4d0d, but four
git-plugin files still told the agent to read it. The file only ever
carried branching_pattern, commit_style and rebase_strategy, so the
`base_branch` and scope instructions were wrong even before the
deletion. Each site now describes what the skill actually does: base is
`main` under GitHub Flow or `develop` when Gitflow is inferred, the
Gitflow fallback keys off the repo's own branches, the orchestrator
contract's `base` defaults to the inferred base branch, and the commit
scope is inferred from the changed files.

N6 — gitea-prs was the one gitea skill with no permission-scope caveat
on a 404. Added one alongside the existing issue/PR number-space
guidance rather than replacing it: a 404 is only evidence of
"that number is an issue" once write:repository scope is confirmed.

N4 — plugins/kyberforge/bin/README.md pointed at `.mcp.json`, but all
six plugin-root .mcp.json files were deleted in c96ca9c (ADR-0018).
${CLAUDE_PLUGIN_ROOT} itself is still live, so the sentence now points
at .apm/hooks/hooks.json, which kyberforge's own hook already uses.

N7 — not applied. The finding claimed a marketplace field override
emits a verbose BuildDiagnostic that `apm pack -v` surfaces, so
"silently wins" was wrong. apm 0.28.0 does construct the diagnostic in
marketplace/output_mappers.py, but nothing renders it:
_render_marketplace_result in commands/pack.py iterates `warnings`
only, and BuildReport.diagnostics has no consumer. Confirmed on a
fixture — neither `apm pack -v` nor APM_LOG_LEVEL=DEBUG prints the
override, and --check-versions reports [matches]. The existing wording
in configure.md and marketplace.md is correct, so both are unchanged.

Version bumps required by check-skill-version-bump.sh: git-branches
1.0.4 -> 1.0.5, git-commits 0.1.6 -> 0.1.7, gitea-prs 0.1.4 -> 0.1.5.
bin/README.md is outside any skill directory and needs no bump.

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

plugins/git/.apm/skills/git-branches/SKILL.md

@@ -9,7 +9,7 @@ description: >
   Not a Gitea remote's branches -> `gitea-branches`.
 
 metadata:
-  version: "1.0.4"
+  version: "1.0.5"
   category: git
   source_keys:
     - context7-git-htmldocs

plugins/git/.apm/skills/git-branches/references/branch-operations.md

@@ -8,8 +8,8 @@ source_keys:
 One command per action. Where two forms exist, the first is the default and the second the escape
 hatch.
 
-- **create** — `rtk git switch -c <branch> <base>`. Base comes from the config's `base_branch`
-  (`main` under GitHub Flow, usually `develop` under Gitflow).
+- **create** — `rtk git switch -c <branch> <base>`. Base is `main` under GitHub Flow, or `develop`
+  when Gitflow is inferred from the repo — see `references/branch-patterns.md`.
 - **switch** — `rtk git switch <branch>` moves to an existing local branch; it aborts rather than
   clobbering conflicting local changes. `rtk git switch -` returns to the previous branch.
 - **delete (local)** — `rtk git branch -d <branch>` refuses when the branch holds unmerged commits,

plugins/git/.apm/skills/git-branches/references/branch-patterns.md

@@ -9,8 +9,7 @@ source_keys:
 
 Which pattern is in play decides the base branch, the branch name prefix, and whether merges are
 allowed to fast-forward. Default to GitHub Flow — simpler, and what CI/CD-oriented repos expect.
-Fall back to Gitflow only when the config says so or the repo already carries `develop` or
-`release/*` branches.
+Fall back to Gitflow only when the repo already carries `develop` or `release/*` branches.
 
 ## GitHub Flow
 

plugins/git/.apm/skills/git-branches/references/orchestrator-contract.md

@@ -13,7 +13,7 @@ Request:
 {
   "action": "create|switch|delete|rename|track|list|get-intent",
   "branch": "<branch-name>",
-  "base": "<base branch, optional, defaults to config>",
+  "base": "<base branch, optional, defaults to the inferred base branch>",
   "intent": "<human-readable intent, optional>",
   "confirm": "<true for destructive ops, omit for read ops>"
 }

plugins/git/.apm/skills/git-commits/SKILL.md

@@ -8,7 +8,7 @@ description: >
   Not branch lifecycle -> `git-branches`.
 
 metadata:
-  version: "0.1.6"
+  version: "0.1.7"
   category: git
   source_keys:
     - conventional-commits-spec

plugins/git/.apm/skills/git-commits/references/create-commit.md

@@ -9,7 +9,7 @@ source_keys:
 
 1. **Gather context** — what changed and why, from the staged diff, the PR description, or the issue. Confirm the staged diff is one logical, independently reviewable and reversible change that leaves the repository buildable and testable. If it bundles unrelated work, suggest splitting it before going further.
 2. **Determine the type** — read it off the change itself: a new user-visible feature is `feat`, a bug fix is `fix`. For the full 11-type set and each type's SemVer impact, read `references/conventional-commits-spec.md`.
-3. **Determine the scope** — use the scope from plugin config where one is set, otherwise infer it from the files changed (`api`, `db`, `cli`, `config`). Scope is optional, but it identifies which part of the system moved and is worth setting.
+3. **Determine the scope** — infer it from the files changed (`api`, `db`, `cli`, `config`). Scope is optional, but it identifies which part of the system moved and is worth setting.
 4. **Write the description** — imperative mood, no trailing period: "add user authentication", "fix race condition in cache". Neither source spec sets a target below the 100-character header maximum, but convention favours roughly 50 characters so `git log --oneline` stays readable.
 5. **Add a body when the change is non-trivial** — blank line first, wrapped at 100 characters. Explain *why*, not what: the diff already shows what changed, and the message's job is the context the diff cannot carry — motivation, root cause, tradeoffs. Follow the Why / Implementation Notes / Impact structure in `references/commit-template.md`.
 6. **Add footers where they apply** — `Fixes: #123`, `Refs: #123`, `ADR: 0012`, `Co-authored-by: Name <email>`, `BREAKING CHANGE: description`. For the full trailer list, read `references/commit-template.md`.

plugins/gitea/.apm/skills/gitea-prs/SKILL.md

@@ -19,7 +19,7 @@ metadata:
     - gitea-mcp-slim-go
     - context7-websites-gitea
     - context7-gitea-tea-cli
-  version: "0.1.4"
+  version: "0.1.5"
 
 allowed-tools: Bash mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__pull_request_review_write
 ---
@@ -27,6 +27,7 @@ allowed-tools: Bash mcp__gitea__list_pull_requests mcp__gitea__pull_request_read
 ## Gotchas
 
 - **Issues and PRs share one number space.** `#42` may be an issue rather than a PR. When unsure, call `pull_request_read method: "get"` and read a 404 as "that number is an issue" — hand it to `gitea-issues`.
+- **404 may also mean 403.** Gitea masks permission errors as not-found, so a 404 is only evidence of an issue-not-PR once `write:repository` scope is confirmed — check the token scope before reporting a PR missing or handing the number to `gitea-issues`.
 - **`pull_request_write method: "create"` discards most optional parameters in silence.** `milestone`, `assignee`, `assignees`, `reviewers` and `team_reviewers` are accepted, dropped, and left out of the response, so a drop is indistinguishable from never passing them. `labels` *does* apply on `"create"`, so labels landing is no evidence the milestone did.
 
 ## Step 1 — Resolve owner and repo

plugins/kyberforge/bin/README.md

@@ -4,7 +4,8 @@
 
 Use this for CLI tools, helper scripts, or MCP server entry points bundled with the plugin.
 
-Reference files in this directory from `.mcp.json` or hooks using `${CLAUDE_PLUGIN_ROOT}/bin/<file>`.
+Reference files in this directory from a hook command in `.apm/hooks/hooks.json` using
+`${CLAUDE_PLUGIN_ROOT}/bin/<file>`.
 The `${CLAUDE_PLUGIN_ROOT}` variable resolves to the plugin's install cache path at runtime —
 do not use relative paths from the repo root, as they will break after install.