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.