.claude-plugin/marketplace.json

@@ -11,28 +11,28 @@
     {
       "name": "kyberforge",
       "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
-      "version": "1.6.1",
+      "version": "1.6.2",
       "category": "Developer Tools",
       "source": "./plugins/kyberforge"
     },
     {
       "name": "bin",
       "description": "Skills for everyday AI-assisted development work that is not tied to a single tool, forge or language, and has not yet been split into a focused plugin.",
-      "version": "1.1.6",
+      "version": "1.1.7",
       "category": "Utilities",
       "source": "./plugins/bin"
     },
     {
       "name": "git",
       "description": "Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it.",
-      "version": "1.3.6",
+      "version": "1.3.7",
       "category": "Version Control",
       "source": "./plugins/git"
     },
     {
       "name": "gitea",
       "description": "Skills and agents for working with a Gitea forge through its HTTP API — the forge's own objects, as distinct from the local git clone.",
-      "version": "1.3.7",
+      "version": "1.3.8",
       "category": "Version Control",
       "source": "./plugins/gitea"
     },

.github/plugin/marketplace.json

@@ -11,28 +11,28 @@
     {
       "name": "kyberforge",
       "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
-      "version": "1.6.1",
+      "version": "1.6.2",
       "category": "Developer Tools",
       "source": "./plugins/kyberforge"
     },
     {
       "name": "bin",
       "description": "Skills for everyday AI-assisted development work that is not tied to a single tool, forge or language, and has not yet been split into a focused plugin.",
-      "version": "1.1.6",
+      "version": "1.1.7",
       "category": "Utilities",
       "source": "./plugins/bin"
     },
     {
       "name": "git",
       "description": "Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it.",
-      "version": "1.3.6",
+      "version": "1.3.7",
       "category": "Version Control",
       "source": "./plugins/git"
     },
     {
       "name": "gitea",
       "description": "Skills and agents for working with a Gitea forge through its HTTP API — the forge's own objects, as distinct from the local git clone.",
-      "version": "1.3.7",
+      "version": "1.3.8",
       "category": "Version Control",
       "source": "./plugins/gitea"
     },

.pre-commit-config.yaml

@@ -254,17 +254,79 @@ repos:
         entry: bash
         language: system
         files: '^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$'
+        # Pinned by tests/test-skill-frontmatter.sh, which drives this exact
+        # `bash -c <script> <arg0> <files...>` call shape rather than a copy of
+        # the script -- the bug below was invisible to any test that did not.
         args:
           - -c
           - |
+            # Every check reads the FRONTMATTER only, never the whole file. A
+            # `metadata:` / `name:` / `description:` line inside a body code
+            # fence is documentation (skill-author quotes exactly such a block)
+            # and used to satisfy these greps.
             for f in "$@"; do
-              if [[ -f "$f" ]]; then
-                if ! grep -q "^name:" "$f" || ! grep -q "^description:" "$f"; then
-                  echo "ERROR: $f is missing required frontmatter fields (name: and description:)"
+              [[ -f "$f" ]] || continue
+
+              fm="$(awk '
+                { sub(/\r$/, "") }
+                NR == 1 { sub(/^\357\273\277/, "") }
+                !opened && /^[[:blank:]]*$/ { next }
+                !opened {
+                  if ($0 ~ /^---[[:blank:]]*$/) { opened = 1; next }
+                  exit
+                }
+                /^---[[:blank:]]*$/ { closed = 1; exit }
+                { print }
+                END { if (!opened || !closed) exit 3 }
+              ' "$f")" || {
+                echo "ERROR: $f has no closing YAML frontmatter block (expected --- ... --- at the top of the file)"
+                exit 1
+              }
+
+              missing=""
+              printf '%s\n' "$fm" | grep -q "^name:" || missing="${missing}name: "
+              printf '%s\n' "$fm" | grep -q "^description:" || missing="${missing}description: "
+
+              # Scoped to the `metadata:` block and stopped at the next
+              # top-level key, so a `version:` under a following `source:` list
+              # cannot stand in for it; the `^  version:` anchor is exact, so a
+              # deeper-nested `    version:` cannot either. No line budget, so a
+              # long `metadata:` block does not hide the key.
+              ver="$(printf '%s\n' "$fm" | awk '
+                /^metadata:/ { inm = 1; next }
+                inm && /^[A-Za-z]/ { exit }
+                inm && /^  version:/ {
+                  v = $0
+                  sub(/^  version:[[:blank:]]*/, "", v)
+                  sub(/[[:blank:]]+#.*$/, "", v)
+                  sub(/[[:blank:]]+$/, "", v)
+                  print "found:" v
+                  exit
+                }
+              ')"
+              [[ -n "$ver" ]] || missing="${missing}metadata.version "
+
+              if [[ -n "$missing" ]]; then
+                echo "ERROR: $f is missing required frontmatter fields (${missing})"
                 exit 1
               fi
+
+              raw="${ver#found:}"
+              v="$raw"
+              case "$v" in
+                \"*\") v="${v#\"}"; v="${v%\"}" ;;
+                \'*\') v="${v#\'}"; v="${v%\'}" ;;
+              esac
+              if [[ ! "$v" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
+                echo "ERROR: $f has a malformed frontmatter metadata.version (${raw:-<empty>}) -- expected a three-part semver, e.g. \"1.0.0\""
+                exit 1
               fi
             done
+          # arg0 for `bash -c`. WITHOUT it pre-commit's first filename lands in
+          # $0 and is dropped from "$@" -- so a single-file commit, the normal
+          # case, ran the loop zero times and reported Passed having checked
+          # nothing. Do not remove; tests/test-skill-frontmatter.sh pins it.
+          - skill-frontmatter
 
       - id: skill-size-check
         stages: ['pre-commit']
@@ -284,6 +346,21 @@ repos:
         # records for Vale warnings. Costs nothing on a clean file: the script
         # prints only findings.
 
+      - id: check-rtk-prefix
+        stages: ['pre-commit']
+        name: ADR-0023 rtk prefix on executable git commands
+        description: Enforce ADR-0023 clause 1 -- an executable, instructed git command in a shell code fence or a dispatch-table Run cell is written `rtk git`. Clauses 2 and 3 are not machine-decidable; a deliberately bare command opts out with the literal string ADR-0023 on its own line
+        entry: scripts/check-rtk-prefix.sh
+        language: script
+        files: '^plugins/[^/]+/\.apm/(skills/.*\.md|agents/.*\.agent\.md)$'
+        # README.md is excluded on purpose, not by oversight. A skill-directory
+        # README is consumer-facing prose that no agent ever loads, and the
+        # `git clone` lines in the seven tests/README.md files are setup
+        # instructions for a third party who has no rtk installed. Prefixing
+        # those would be actively wrong -- see ADR-0023's consumer section.
+        exclude: '(^|/)README\.md$'
+        pass_filenames: true
+
       - id: vale-audit-prefilter-skill
         stages: ['pre-commit']
         name: Vale audit prefilter (SKILL.md)

LESSONS.md

@@ -60,29 +60,21 @@ write-eval's process requires presenting the full test plan and waiting for user
 
 The write-skill authoring standard required 8 body sections including Role and When/When not. These were assumed to be agentskills.io requirements. Checking the actual spec revealed the body has no format restrictions at all — recommended sections are step-by-step instructions, examples, and edge cases. Role and When/When not were added by convention without verifying the standard. Fix: before encoding any requirement as part of an authoring standard, check the upstream spec directly. The agentskills.io spec also confirmed that negative triggers belong in the description field — not in a separate body section — which eliminates a persistent duplication pattern across all skills.
 
-## 2026-05-18 — Provenance fields in frontmatter are loaded on every skill scan
-
-Fields like `source:`, `references:`, `version:`, `updated:`, and `when:` in SKILL.md frontmatter are loaded at agent startup alongside `name` and `description` for every installed skill. None of these are used for routing or runtime execution — they are audit and upgrade-cycle records. Loading them at startup violates progressive disclosure and wastes tokens proportional to the number of installed skills. Fix: move all non-routing frontmatter to a separate `META.md` file in the skill directory. Frontmatter keeps only `name`, `description`, `metadata.category`, and `allowed-tools` (when applicable) — the four fields the spec actually uses for routing and discovery.
-
 ## 2026-05-18 — Copy-fill is more deterministic than generate for structured skill artifacts
 
-When a skill produces a structured artifact like SKILL.md, the natural approach is to generate it from internalized rules in the Process section. But this means section structure is only as reliable as the agent's instruction-following under token pressure. Copy-fill (copy the template to the target path, then fill in content) separates structure from content: the template mechanically enforces section order and presence, freeing the Process section to focus only on sequencing constraints (what order to decide things) rather than also policing structure. Side benefit: the template is a human-usable artifact that can be adopted independently of the skill. Fix applied in write-skill refactor: SKILL-TEMPLATE.md and META-TEMPLATE.md are the authoritative structure sources; the Process section no longer contains a body structure constraint — the template handles it.
+When a skill produces a structured artifact like SKILL.md, the natural approach is to generate it from internalized rules in the Process section. But this means section structure is only as reliable as the agent's instruction-following under token pressure. Copy-fill (copy the template to the target path, then fill in content) separates structure from content: the template mechanically enforces section order and presence, freeing the Process section to focus only on sequencing constraints (what order to decide things) rather than also policing structure. Side benefit: the template is a human-usable artifact that can be adopted independently of the skill. Fix applied in write-skill refactor: SKILL-TEMPLATE.md is the authoritative structure source; the Process section no longer contains a body structure constraint — the template handles it.
 
 ## 2026-05-17 — HITL gap: agent delegates confirmation to permission system
 
 The agent-level HITL rule ("require explicit confirmation before irreversible shared-state operations") is being bypassed: the agent calls the tool and lets the permission dialog catch it. This means the rule is not firing in agent reasoning — it's the permission system acting as a safety net. If a user selects "don't ask again," the net disappears. Fix: the HITL rule needs to be framed as "do not call the tool" rather than "ask before proceeding" — the agent must ask first, then act only after explicit confirmation.
 
-## 2026-05-26 — META-TEMPLATE uses YAML comments; META.md output retains them
-
-META-TEMPLATE.md uses YAML `#` comments to explain fields inline. SKILL-TEMPLATE.md uses HTML comments inside XML tags, which the agent strips on fill. The structural difference means SKILL.md output is clean but META.md output retains the explanatory `#` lines — an inconsistency. Fix (deferred): restructure META-TEMPLATE.md so all explanatory guidance is prose above the code block (markdown, never copied into the output YAML), and the code block itself uses `<placeholder>` syntax with no `#` comment lines. This makes META.md fill behaviour deterministic for the same reason SKILL.md fill is: `<...>` markers are unambiguously replaceable; prose above the block is not part of the template. Do not apply until the human/copy-fill tradeoff is resolved — see 2026-05-26 session discussion.
-
 ## 2026-05-26 — Overlap checks must scan the deployed directory, not just the source repo
 
 `write-a-skill` existed only in `~/.agents/skills/` (installed from a pre-refactor source) and was invisible during a repo-level scan of `.agents/skills/`. Governance reviews and overlap checks that only look at the source repo will miss skills added by install.sh from other sources or prior runs. Fix: overlap checks must scan the deployed `~/.agents/skills/` directory, not just the repo's `.agents/skills/`.
 
-## 2026-05-26 — `model:` field belongs in SKILL.md frontmatter, not META.md
+## 2026-05-26 — `model:` field belongs in SKILL.md frontmatter, not a sidecar file
 
-Claude Code supports `model:` as a provider extension in SKILL.md frontmatter — it overrides the session model for the skill's turn and reverts after. Attempting to put it in META.md was wrong: META.md is provenance/audit metadata, not runtime config. The boundary: if a field affects agent behaviour at invocation time, it belongs in SKILL.md frontmatter; if it serves upgrade reviews and audit trails, it belongs in META.md.
+Claude Code supports `model:` as a provider extension in SKILL.md frontmatter — it overrides the session model for the skill's turn and reverts after. Attempting to move it out to a provenance sidecar was wrong: a sidecar is audit metadata, not runtime config. The boundary: if a field affects agent behaviour at invocation time, it belongs in SKILL.md frontmatter.
 
 ## 2026-05-26 — Research agents present synthesis as spec fact
 
@@ -126,7 +118,7 @@ Two forks independently fixed `references/sources.md` with different approaches
 
 ## 2026-06-28 — Implementation agents must invoke /skill-author, not write skill files directly
 
-When briefing an agent to implement a new skill, the instinct is to tell it to write the SKILL.md and supporting files directly. This bypasses Step 5 of the skill-author process (provenance), which requires reading all research `sources.md` files and recording every `extracted` slug in META.md. The `validate-provenance.sh` script catches the gap — but only after the commit, requiring a fix round. This pattern recurred twice in one session (plugin-author and marketplace-author initial implementation, then again in the first round of fix agents). Fix: briefs for implementation agents must explicitly say "invoke `/skill-author` (read and follow `plugins/kyberforge/.apm/skills/skill-author/SKILL.md`)" — not "write the skill files." Invoking the skill is the only reliable way to ensure all process gates, including provenance, run.
+When briefing an agent to implement a new skill, the instinct is to tell it to write the SKILL.md and supporting files directly. This bypasses Step 5 of the skill-author process (provenance), which requires reading all research `sources.md` files and recording every `extracted` slug in the skill's own `references/sources.md`. The `validate-provenance.sh` script catches the gap — but only after the commit, requiring a fix round. This pattern recurred twice in one session (plugin-author and marketplace-author initial implementation, then again in the first round of fix agents). Fix: briefs for implementation agents must explicitly say "invoke `/skill-author` (read and follow `plugins/kyberforge/.apm/skills/skill-author/SKILL.md`)" — not "write the skill files." Invoking the skill is the only reliable way to ensure all process gates, including provenance, run.
 
 ## 2026-07-05 — Repo root is a bare checkout; work happens in worktrees only
 

apm.yml

@@ -42,7 +42,7 @@ dependencies:
 # after a kyberforge release, check this first.
 executables:
   allow:
-    kyberforge#1.6.1:
+    kyberforge#1.6.2:
       hooks: true
       bin: true
 
@@ -79,25 +79,25 @@ marketplace:
     - name: kyberforge
       description: Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.
       source: ./plugins/kyberforge
-      version: 1.6.1
+      version: 1.6.2
       category: Developer Tools
 
     - name: bin
       description: Skills for everyday AI-assisted development work that is not tied to a single tool, forge or language, and has not yet been split into a focused plugin.
       source: ./plugins/bin
-      version: 1.1.6
+      version: 1.1.7
       category: Utilities
 
     - name: git
       description: Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it.
       source: ./plugins/git
-      version: 1.3.6
+      version: 1.3.7
       category: Version Control
 
     - name: gitea
       description: Skills and agents for working with a Gitea forge through its HTTP API — the forge's own objects, as distinct from the local git clone.
       source: ./plugins/gitea
-      version: 1.3.7
+      version: 1.3.8
       category: Version Control
 
     - name: core

docs/adr/0022-skill-metadata-version-is-mandatory.md

@@ -0,0 +1,78 @@
+# Every skill's `metadata.version` is mandatory, not a per-plugin option
+
+**Status: accepted (2026-09-07).**
+
+## Context
+
+`metadata.version` is optional SKILL.md frontmatter (`create.md`'s "Optional frontmatter" list:
+"uncomment and fill in, or remove entirely"). `skill-author`'s own bump logic was written
+conditionally — "with `metadata.version` present, bump the minor version on create... and the
+patch version on improve" — which only makes sense if presence is a real per-skill choice.
+
+Adoption never followed a rule; it followed the plugin. Of 39 skills, 12 carry a version:
+
+| Plugin | Has it | Total |
+|---|---|---|
+| `core` | 3 | 3 |
+| `gitea` | 6 | 7 |
+| `lint` | 2 | 2 |
+| `git` | 1 | 9 |
+| `bin` | 0 | 11 |
+| `kyberforge` | 0 | 7 |
+
+`core`, `gitea` and `lint` are consistent adopters (`gitea-files` the one gap); `bin` and
+`kyberforge` are consistent non-adopters; `git` has one outlier (`git-commits`, versioned for no
+plugin-specific reason found on inspection — no comment, no cross-reference, nothing distinguishing
+it from its eight siblings). Issue #127 raised this as an undocumented split: two house norms
+coexisting with no stated rule for which applies where, the same class of defect as an unstated
+`rtk`/bare-`git` convention (#113) found in the same audit pass.
+
+## Decision
+
+**Every skill's frontmatter carries `metadata.version`.** It is no longer optional, and no longer a
+per-plugin choice.
+
+- **The 27 skills that never carried one are seeded at `1.0.0`**, not `0.1.0`. `0.1.0` is
+  `skill-author`'s existing new-skill starting point, chosen for a skill with no revision history to
+  its name yet. These 27 have all been through the ADR-0020 retrofit and repeated audit passes
+  without ever tracking a version; crediting them with `0.1.0` would understate that, and there is
+  no real history to justify seeding higher than a first stable release. `1.0.0` marks "versioned as
+  of this retrofit," `0.1.0` keeps meaning "created and never yet revised."
+- **New skills still start at `0.1.0`.** `skill-author`'s create/improve bump convention is
+  unchanged; only the presence of the field stops being conditional.
+- **The one outlier in the other direction, `git-commits`, keeps its existing value** (`0.1.3`) —
+  it already had real tracked history under the old conditional rule, and this decision does not
+  reset skills that were already compliant.
+- **`bin/write-docs`'s top-level `version:` moves into `metadata:`, normalized to `1.0.0`.** It is
+  the one skill that carried a version outside the `metadata:` block, which is why the table above
+  counts `bin` as 0 — a top-level `version:` is not `metadata.version`, and nothing reads it. #127
+  raised it alongside the split because "does a skill carry a version" and "where does it live" are
+  the same question. Its value (`1.0`) is not semver and carries no more real history than the 27
+  unversioned skills, so it is relocated and reset to the same `1.0.0` seed rather than preserved
+  like `git-commits`'s tracked `0.1.3`.
+- **`skill-frontmatter`'s pre-commit hook gains the check.** It already fails a SKILL.md missing
+  `name:` or `description:`; a missing `metadata.version` is now the same class of failure, not a
+  style nit an audit might or might not catch.
+
+## Considered options
+
+**Leave it per-plugin, document the split.** This was the initial framing of #127 and is coherent —
+`core`/`gitea`/`lint` keep it, `bin`/`kyberforge` don't, two outliers get normalized to match their
+plugin. Rejected on reconsideration: a rule that says "some plugins track this and some don't" is
+strictly harder to state, audit and onboard against than "every skill does," for a field whose entire
+job is answering "did this change since I last read it" — a question with the same shape everywhere
+it's asked, not one that varies by plugin domain.
+
+**Drop the field corpus-wide.** Rejected: `skill-author` already depends on it to decide whether a
+create/improve pass owes a bump, so the 12 skills carrying it are not tracking dead weight — removing
+it discards real revision signal for no gain.
+
+## Consequences
+
+27 SKILL.md files gain `metadata.version: "1.0.0"`, and a 28th — `bin/write-docs` — reaches the same
+value by relocating its top-level `version: "1.0"` into `metadata:`. `skill-author`'s `create.md`
+moves the field from "Optional frontmatter" to the required list, citing this ADR. `skill-author`'s
+own SKILL.md drops the "with `metadata.version` present" conditional in its bump-rule line, since
+presence is no longer in question. `.pre-commit-config.yaml`'s `skill-frontmatter` hook is extended
+to require the field, closing the gap #113 and #118 both named in the same audit pass: a stated rule
+with nothing enforcing it drifts the same way an unstated one does.

docs/adr/0023-rtk-prefix-marks-executable-commands-only.md

@@ -0,0 +1,168 @@
+# The `rtk` prefix marks executable commands only, and is repo-wide
+
+**Status: accepted (2026-09-08).**
+
+## Context
+
+`CLAUDE.md` states the org convention as a golden rule: "Always prefix commands with `rtk`. If RTK
+has a dedicated filter, it uses it. If not, it passes through unchanged. This means RTK is always
+safe to use." Issue #113 observed that the rule had never been written down for skill *prose*, where
+a `git <subcommand>` mention can be either an instruction to execute or a reference to the concept,
+and that the corpus had drifted into carrying both spellings with no stated rule. PR #130 swept the
+`git` plugin and recorded a two-way split in `plugins/git/README.md`.
+
+Review found two defects in that sweep, and both are in the premise rather than the execution.
+
+**RTK is not output-transparent.** `rtk git --help` enumerates twelve filtered subcommands — `diff`,
+`log`, `status`, `show`, `add`, `commit`, `push`, `pull`, `branch`, `fetch`, `stash`, `worktree`.
+Everything else is a true passthrough. Inside that set the filter is not a formatting preference; it
+changes what the command *reports*. Measured against rtk 0.42.4:
+
+| Command | What rtk does to it |
+|---|---|
+| `worktree list --porcelain -z` | discards both flags; no NUL separators, no `locked`/`lock_reason` field at all |
+| `worktree list -v` | abbreviates `/root/…` to `~/…`, collapses column alignment |
+| `branch --list <name>` | emits a phantom `* ` line even on no match |
+| `diff --name-only` / `--name-status` | appends a blank line and a `Changes:` trailer |
+| `diff --word-diff[=color\|=porcelain]` | emits no `[-removed-] {+added+}` markers; substitutes a diffstat |
+| `log -L` | truncates each diff body line at ~72 characters with an ellipsis |
+| `stash pop` (on conflict) | prints only `FAILED: git stash pop`, swallowing `CONFLICT`, `Unmerged paths` and the retained-entry notice |
+| `stash list` (empty) | prints `No stashes` where git prints nothing |
+
+Every one of those falsified a skill that was written against the bare output. `git-worktrees`'s
+Step 2 required `locked` and `lock_reason` from a command whose rtk rendering has never carried
+them; `git-log-format.md` documented `[-removed-] {+added+}` markers beside a command that no longer
+produces them. The two-way split could not see any of this, because both halves of it are about what
+a *sentence* is doing and none of it is about what the *command* does.
+
+**The rule is not `git`-plugin-scoped.** `plugins/git/README.md` claimed the `gitea-*` skills
+"contain no `git`/`rtk` mentions at all". Five `gitea-*` SKILL.md files run `git remote get-url
+origin` in a fenced ```bash Step block — the README's own canonical example of "executable,
+instructed" — plus `git branch --show-current` in a reference file and three `git remote -v` in
+`gitea-orchestrate.agent.md`. A convention stated inside one plugin's README is invisible from the
+plugin next door, which is how those eight sites stayed bare through the sweep that existed to find
+them.
+
+## Decision
+
+**One rule, three clauses, repo-wide** — every `plugins/*/.apm/skills/**` and
+`plugins/*/.apm/agents/**` file, not the `git` plugin alone.
+
+1. **Executable and instructed → `rtk git`.** Anything telling the agent to run a command now: an
+   imperative step, a dispatch-table "Run" cell, a fenced code-block procedure.
+   `rtk git push -u origin <branch>`.
+2. **Illustrative or referential → bare `git`.** Naming a flag's behaviour, quoting a doc's own
+   heading, describing a command in the abstract, warning against an anti-pattern. "`git switch`
+   refuses rather than clobbering conflicting local edits."
+3. **Machine-parsed or interactive → bare `git`, and say why inline.** A command whose output the
+   skill parses, where rtk is in the filtered set above; or a command that hands control to an
+   interactive child process.
+
+Clause 3 is the new one and it looks arbitrary without the table in Context, which is why the
+measurements are recorded here rather than left in a PR thread. It is applied per subcommand and per
+flag, not per skill: `tag --list` stays prefixed because rtk passes it through byte-identically,
+while `branch --list` two words away goes bare because it does not. `git remote get-url origin`,
+`git remote -v`, `git branch --show-current`, `git log --oneline -1` and `git add -u` were all
+re-measured as byte-identical passthroughs and are therefore prefixed, parsing notwithstanding.
+
+Two consequences of that per-subcommand basis are worth stating, because both are load-bearing and
+neither is comfortable:
+
+- **rtk's filtered set is a moving target.** `git rebase` and `git mergetool` are passthroughs on
+  0.42.4 — verified under `script(1)`, both inherit a real TTY, contradicting an earlier report that
+  they did not. They stay bare anyway, on the interactive limb: a token filter has nothing to offer a
+  command that hands control to an editor, and the prefix would only buy exposure to whatever a later
+  rtk version decides to do with those subcommands. The same reasoning makes the *inner* call in
+  `` `rtk git remote add origin-push $(git config remote.origin.url)` `` bare while the outer stays
+  prefixed — `config` passes through cleanly today, but its stdout becomes a remote URL that is then
+  force-pushed to, and that is not a blast radius to lend to a future filter change.
+- **`branch --show-current` sits on the sharp edge.** It is in the filtered set, it is parsed, and it
+  is prefixed — on a measurement, in a subcommand whose sibling `--list` is exactly the defect clause
+  3 exists for. If rtk's `branch` filter is ever extended, that is the first site to break. It is
+  called out rather than hedged, because a rule whose exceptions are unrecorded is the state this ADR
+  is replacing.
+
+**A clause-3 site says so inline, in a few words.** "bare, not `rtk`: rtk prints a phantom `* ` line
+even on no match". Without it the next sweep re-prefixes the command, which is how #113 recurs.
+
+**The rule lives here, and `docs/spec/gates.md` carries the gate.** `plugins/git/README.md` is
+reduced to a pointer. It had also cited `git-workflow/references/hard-rules.md` as a place the rule
+was written down; that file contains no occurrence of "rtk", and the citation is removed rather than
+repaired.
+
+**Clause 1 is enforced by a `check-rtk-prefix` pre-commit hook; clauses 2 and 3 are not enforceable
+and are not gated.** The hook checks the two places a `git` mention is unambiguously an instruction —
+a line in a shell-tagged code fence, and the opening backticked span of a "Run" column cell — and a
+deliberately-bare command opts out with the literal string `ADR-0023` on its own line. Its coverage
+limits are recorded in `docs/spec/gates.md`, not smoothed over.
+
+## Considered options
+
+**Add `compatibility:` frontmatter to every skill.** These six plugins are installable by third
+parties, and a consumer who installs `git` from the marketplace has no `rtk` on their PATH. Every
+prefixed command in the corpus is a plain `git` invocation with a word in front of it, so the prefix
+is *droppable*: delete `rtk ` and the command is correct. A `compatibility:` line per skill would
+state that in a machine-readable field. Rejected on cost. It is 39 lines of frontmatter restating one
+sentence, it is preloaded into every agent's context every session under ADR-0020's budget — the
+field is not free the way a line in a doc is — and it has no consumer: nothing reads
+`compatibility:`, so the field would be a comment with a colon in it. The consumer situation is
+documented here and in `plugins/git/README.md` instead, which is where a human installing a plugin
+actually looks. The same two-line note is owed to the other five plugin READMEs and is not yet
+written.
+
+**Move rtk to the execution layer entirely.** Skills instruct bare `git` throughout; `CLAUDE.md`'s
+session rule handles prefixing at the point of execution. This is the strongest rejected option and
+it deserves the space: it closes the consumer gap and all eight output defects at once, because the
+executing agent knows what it is about to parse and the skill does not have to predict it. It also
+removes clause 3 entirely — there is nothing to except. Rejected because the prefix is lost wherever
+an agent copies a command literally, which is the common case for a fenced procedure block and the
+whole reason dispatch tables exist. The org convention's value is that the prefix is *already there*
+in the text the agent lifts; a rule that relies on the agent remembering to add it is the rule that
+produced the drift in the first place. Worth revisiting if rtk ever ships a shell shim, which would
+make the execution layer transparent and this trade different.
+
+**Keep the two-way split and fix the eight sites by hand.** Rejected: the split has no vocabulary for
+"this command is executable, instructed, and must still be bare", so the eight sites would be
+unexplained exceptions and the next sweep re-prefixes them. That is the failure this ADR exists to
+stop, not a smaller version of it.
+
+**Gate clauses 2 and 3 as well.** Rejected as undecidable. "Run `git switch <branch>`" and "`git
+switch` refuses rather than clobbering local edits" are the same token sequence; separating them is a
+judgement about what a sentence is doing. A gate that guessed would fire on correct content, and a
+gate that fires on correct content gets added to `SKIP`, which disarms clause 1 along with it.
+
+## The boundary the rule does not decide
+
+Two shapes in the corpus resisted the two-way split. The three-clause rule resolves one and does not
+resolve the other; both are recorded so an author meeting a third one knows which kind it is.
+
+**`git-worktrees/SKILL.md`'s tracking row carries both spellings in one Run cell** — `rtk git
+worktree add --track -b <branch> <path> <remote>/<branch>` — always correct. `git worktree add
+<path> <branch>` expands to exactly this. **Resolved: the clauses apply per mention, not per row,
+per cell or per file.** The first is the instruction (clause 1), the second names what the first
+expands to (clause 2), and one table cell can hold one of each. The rule needed no change; the
+*gate* did, and it checks only a Run cell's opening span for exactly this reason.
+
+**`git-submodules/references/setup-and-update.md:80` has a git command inside a quoted argument to
+another command** — `rtk git submodule foreach 'git pull origin main || :'`. **Not resolved: all
+three clauses describe a command the reading agent executes, and the inner `git pull` is not one.**
+It is the literal text of an argument that `git submodule foreach` hands to a subshell running inside
+each submodule's own working tree, where the local convention does not reach. The file already gets
+this right and already justifies it in prose two lines below ("the git calls in it are the
+submodule's own — that is the one place a bare `git` is correct"). **An author meeting this shape
+should do the same: leave the inner command bare and justify it inline.** It is deliberately not
+promoted to a fourth clause on one instance. The gate does not decide it either — it happens to pass
+this line, because the segment containing the inner command begins with `rtk`, and that is an
+accident of the split rather than an understanding of quoting.
+
+## Consequences
+
+Eleven sites in `plugins/git/.apm/skills/**` revert to bare `git` under clause 3, each carrying a
+short inline reason. Eight sites across `plugins/gitea/.apm/skills/**` and
+`plugins/gitea/.apm/agents/gitea-orchestrate.agent.md` gain the prefix under clause 1, and one in
+`pc-run/SKILL.md` that the #130 sweep's grep missed because the backtick opens with `SKIP=` rather
+than `git `. `plugins/git/README.md`'s Conventions section becomes a pointer here, minus a paragraph
+that was false about the `gitea-*` skills and a citation to a file that does not carry the rule.
+A `check-rtk-prefix` pre-commit hook and `tests/test-check-rtk-prefix.sh` land with it; the test runs
+the gate against the pre-sweep corpus on `main` and asserts it fails there, because a gate that only
+passes on the fixed tree proves nothing about the drift it was written for.

docs/notes/factory-integration-decisions.md

@@ -53,8 +53,7 @@ All skills — new and rebuilt — must follow this standard:
 - `name:` — matches directory name
 - `description:` — trigger-tested before writing the body (explicit, implicit, negative cases)
 - `metadata: category:` — from the category table above
-
-`version:`, `updated:`, `when:`, `source:`, and `references:` are provenance/audit fields — they live in `META.md` alongside the SKILL.md (not in frontmatter). See `META-TEMPLATE.md` in `.agents/skills/write-skill/` for the META.md schema.
+- `metadata: version:` — mandatory for every skill (ADR-0022)
 
 **Body required sections:**
 - Constraints (highest-ROI element — prevents overengineering)

docs/notes/skill-implementation-workflow.md

@@ -103,21 +103,21 @@ Do not write the SKILL.md until the human has confirmed every section. The synth
 **c. SKILL.md** (sub-agent)
 Once all sections are confirmed, spawn a write agent to produce the SKILL.md using `write-skill` (or hand-write for bootstrap skills). The agent receives: trigger description, per-section decisions from step b, upstream content to incorporate, authoring standard (see below).
 
-**c. META.md — `source:` and `references:` fields**
-Populate `META.md` after upstream review. Two distinct fields:
-- `source:` — upstream provenance tracking (repo slug, commit SHA, files adopted with inline comments, updated date). Present only if content was adopted. Absence = self-authored.
-- `references:` — general citations (research papers, documentation, standard specifications). Present only if the skill cites external research.
+**d. Provenance — source and reference records**
+Record provenance after upstream review. Two distinct kinds:
+- Upstream provenance (repo slug, commit SHA, files adopted with inline comments, updated date). Present only if content was adopted. Absence = self-authored.
+- General citations (research papers, documentation, standard specifications). Present only if the skill cites external research.
 
-Both fields live in `META.md` alongside the SKILL.md — not in frontmatter. See `META-TEMPLATE.md` in `.agents/skills/write-skill/` for the full schema.
+Both are recorded in the skill's own `references/sources.md`, keyed by the `source_keys:` its SKILL.md and reference files declare. `validate-provenance.sh` checks that chain.
 
-**d. eval.yaml** (sub-agent)
+**e. eval.yaml** (sub-agent)
 Invoke `write-eval` in two steps to preserve its confirmation gate:
 1. Sub-agent proposes test cases and returns the plan to the main conversation.
 2. Human confirms the plan; then sub-agent writes the file.
 
 Do not pass pre-designed test cases directly to a write agent — that collapses the plan-then-confirm gate into a single step, bypassing write-eval's own constraint. Co-located at `.agents/evals/<category>/<skill-name>/eval.yaml`. Must contain all five required test types (see Eval schema below).
 
-**e. HITL behavioral test**
+**f. HITL behavioral test**
 Human opens a fresh Claude session, invokes the skill with its trigger phrase, and verifies output. Do not batch more than 2–3 skills before running behavioral tests — output volume must stay within genuine human review capacity. An approval that cannot be meaningfully evaluated is not an approval.
 
 ### Step 6 — Session handoff
@@ -157,12 +157,11 @@ name: skill-name
 description: <trigger description — routing only; written and tested first; max 1024 chars>
 metadata:
   category: <design|factory|implement|test|review|deploy|operate|cross-cutting|iac>
+  version: <semver — mandatory for every skill; see ADR-0022>
 # allowed-tools: <add only when the skill has a narrow, well-defined tool surface; omit otherwise>
 ---
 ```
 
-Frontmatter contains only these fields. `version`, `updated`, `when`, `source`, and `references` are provenance/audit fields — they are not used for routing or runtime execution. They live in `META.md` alongside the SKILL.md, loaded only when needed. See `META-TEMPLATE.md` in `.agents/skills/write-skill/` for the META.md schema.
-
 ### Body sections
 
 Use `.agents/skills/write-skill/SKILL-TEMPLATE.md` as the authoritative structure reference. The template defines the required sections, correct order, XML grouping, and placeholder comments for each section.
@@ -230,6 +229,6 @@ Upstream review happens per-skill during step 2, not once at chunk start.
 
 ## Open decisions carried forward
 
-- **Bidirectional reference convention** — Chunk 4 (reference scanner tooling; reverse map "what files point to X?"). The `when:` field itself is resolved — it lives in `META.md` alongside every skill.
+- **Bidirectional reference convention** — Chunk 4 (reference scanner tooling; reverse map "what files point to X?").
 - **PRD/issue template scope** — refined during `write-prd` (0020) and `write-issue-spec` (0019) implementation
 - **Merging `zoom-out` into architect role** — revisit at Chunk 5 grill

docs/spec/gates.md

@@ -128,12 +128,43 @@ not an authoring change.
 ### `skill-frontmatter`, the other hook on that scope
 
 A second `repo: local` pre-commit hook, `skill-frontmatter`, runs on the **same** `files:` pattern at
-the same stage. It is a short shell loop: for each file, `grep -q "^name:"` and
-`grep -q "^description:"`, failing with "missing required frontmatter fields" if either is absent.
+the same stage. It is a shell loop that, **for the YAML frontmatter block only** — everything between
+the opening `---` and the next `---` — asserts four things per file:
 
-**It overlaps ADR-0020's "description present and non-empty" FAIL, and the overlap is not clean.**
-The ADR (`:95-101`) requires that question be decided on the **YAML-folded value** and nowhere else,
-precisely because a line regex gets it wrong in both directions. Measured on fixtures:
+| Check | Rejects with |
+|---|---|
+| a `^name:` line is present | "missing required frontmatter fields (name: …)" |
+| a `^description:` line is present | "missing required frontmatter fields (description: …)" |
+| `metadata:` contains a `^  version:` key, anchored, scanning to the next top-level key | "missing required frontmatter fields (metadata.version)" |
+| that version's value is three-part semver (`1.0.0`, quoted or not) | "has a malformed frontmatter metadata.version (…)" |
+
+Every one of those qualifiers is load-bearing, and each replaced a defect that let the hook report
+Passed having measured nothing. `tests/test-skill-frontmatter.sh` pins all of them:
+
+- **Frontmatter-scoped, not whole-file.** The checks used to `grep` the entire file, so a `metadata:`
+  or `name:` block quoted in a **body code fence** satisfied them — `skill-author`'s own docs quote
+  exactly such a block.
+- **Bounded by the next top-level key, not by `-A10`.** The version check was
+  `grep -A10 "^metadata:" | grep -q "  version:"`, which ran ten lines past the end of the block: a
+  `version:` belonging to a following `source:` list entry counted (`write-docs` and `research` both
+  have a `source:` list immediately after `metadata:`), while a `metadata:` block with more than ten
+  lines before its `version:` was reported missing.
+- **`^  version:` anchored.** `"  version:"` was an unanchored substring, so a deeper-nested
+  `    version:` matched too.
+- **The value is asserted, not just the key.** `plugins/bin/.apm/skills/write-docs/SKILL.md` carried
+  `version: "1.0"` — present, correctly nested, and not a version — through an entire PR under a
+  presence-only check. Two-part `1.0` is a YAML float, not a version string.
+- **The call shape is pinned.** `entry: bash` with `args: ['-c', <script>, …]` needs an explicit
+  arg0 placeholder after the script: without it `bash -c` puts pre-commit's **first** filename in
+  `$0`, where `for f in "$@"` never sees it. A single-file commit — the normal case — therefore ran
+  the loop body zero times and exited 0. The third `args` entry (`skill-frontmatter`) exists solely
+  to absorb `$0`; do not remove it.
+- **An unreadable file is an error, not a pass.** A file with no closing `---` fails with "no closing
+  YAML frontmatter block" rather than falling through to a green.
+
+**It still overlaps ADR-0020's "description present and non-empty" FAIL, and the overlap is not
+clean.** The ADR (`:95-101`) requires that question be decided on the **YAML-folded value** and
+nowhere else, precisely because a line regex gets it wrong in both directions. Measured on fixtures:
 
 | Frontmatter | `skill-frontmatter` | `skill-size-check` |
 |---|---|---|
@@ -145,10 +176,34 @@ against, and it is the only one of the two that objects to a quoted key. Neither
 currently live in the corpus, and the honest reading is that presence is `skill-size-check`'s
 question — the grep's contribution to it is noise on one shape and silence on the other.
 
-What the grep does add is the `name:` key, which **no** ADR-0020 check reads: a `SKILL.md` with no
-`name:` passes `skill-size-check` at exit 0. That is its real and only unique coverage, and the
+What the hook adds that **no** ADR-0020 check reads is two keys: `name:` and `metadata.version`. A
+`SKILL.md` missing either passes `skill-size-check` at exit 0. That is its unique coverage, and the
 reason not to fold it into the size gate on the grounds of redundancy.
 
+#### Why this one stays a shell parser
+
+[`python3` and PyYAML are hard requirements](#python3-and-pyyaml-are-hard-requirements) below records
+that a hand-rolled frontmatter reader on this exact `files:` scope was **deliberately deleted**,
+because "a reader that mis-parses an unfamiliar scalar shape reports a clean pass on a file it never
+measured." That reasoning is about `skill-size-check` and does **not** transfer here. Do not delete
+this hook citing it. Three differences:
+
+1. **It answers a strictly narrower question.** `skill-size-check` must know the *folded value* of a
+   `>`-block scalar to count its characters, which is where a line reader diverges from a parser —
+   one corpus description measured 270 characters parsed and 412 unparsed. This hook asks only
+   whether a key is on a line and whether one short **plain scalar** matches `N.N.N`. There is no
+   folding, no multi-line value, and no measurement to get subtly wrong.
+2. **It is frontmatter-scoped.** The failure mode that killed the old fallback was silently reading
+   past or short of the block. This one extracts the block explicitly and errors out when it cannot
+   find a closing marker, so "could not parse" is a red, never a green.
+3. **It is pinned by tests.** `tests/test-skill-frontmatter.sh` drives the hook through pre-commit's
+   real `bash -c <script> <arg0> <files…>` invocation and asserts each defect class above. The
+   deleted fallback had no such suite; that is how its disagreement with a real parser survived.
+
+The trade it buys is that the hook stays repo-local. Moving it to a script would change the
+externally exposed `.pre-commit-hooks.yaml` contract for consumers, for a check that has no need of a
+YAML parser.
+
 ### Two independent gate families, neither replaced the other
 
 **Family 1 — agentskills.io spec backstop** (unchanged, conformance not quality):
@@ -413,6 +468,15 @@ reader that mis-parses an unfamiliar scalar shape reports a clean pass on a file
 which is the exact vacuous-green failure the `python3` check exists to avoid. `pip install pyyaml`
 (or `python3 -m pip install PyYAML`, or the distro's `python3-yaml`) if the hook reports it missing.
 
+**Neither requirement generalises to every hook on this scope, and one deliberate exception sits
+right next to it.** [`skill-frontmatter`](#skill-frontmatter-the-other-hook-on-that-scope) runs on the
+same `files:` pattern as a **shell** parser, on purpose — it asks only whether a key is on a line and
+whether one short plain scalar matches `N.N.N`, with no folding to get wrong, and moving it to a
+script would change the externally exposed `.pre-commit-hooks.yaml` contract for consumers. That
+section carries the full argument. A reader arriving here first should not read this one as
+condemning it. `check-rtk-prefix` needs `python3` but **not** PyYAML: it reads the markdown body and
+never touches frontmatter, so it has no scalar to fold.
+
 ## Agent files take the description gates, not the body gate
 
 `check-apm-agents-valid` runs agent-audit's `validate.sh` over every real
@@ -497,6 +561,91 @@ pre-commit run --all-files                    # size AND Vale
 
 Scoping a retrofit off `skill-size-check` output alone leaves you blocked at the second gate.
 
+## The `rtk` prefix gate (ADR-0023)
+
+`check-rtk-prefix` is a `repo: local` pre-commit hook running `scripts/check-rtk-prefix.sh` over
+`^plugins/[^/]+/\.apm/(skills/.*\.md|agents/.*\.agent\.md)$`, with `README.md` excluded. It enforces
+**ADR-0023 clause 1 and nothing else**: an executable, instructed local git command in plugin skill
+or agent content is written `rtk git`.
+
+It is wider in file scope than the ADR-0020 hooks — every markdown file under a plugin's
+`.apm/skills/` and `.apm/agents/`, not `SKILL.md` alone — because the rule it enforces is about
+commands an agent runs, and most of those live in `references/`, which the ADR-0020 gates do not
+reach ([the `references/` blind spot](#the-blind-spot-references-is-unlinted-for-two-independent-reasons)).
+
+### What it can decide, and what it declines to
+
+ADR-0023 has three clauses and only the first is a pattern:
+
+| Clause | Rule | Gated |
+|---|---|---|
+| 1 | executable + instructed → `rtk git` | yes |
+| 2 | illustrative / referential → bare `git` | no — undecidable |
+| 3 | machine-parsed or interactive → bare `git` | no — opt-out marker |
+
+Clause 2 is a judgement about what a sentence is *doing*. "Run `git switch <branch>`" and "`git
+switch` refuses rather than clobbering local edits" are the same token sequence. A gate that guessed
+would fire on correct prose, and **a gate that fires on correct content gets added to `SKIP`** —
+which disarms clause 1 along with it. So the hook looks only at the two contexts where a `git`
+mention is unambiguously an instruction to execute:
+
+- a line inside a fenced code block whose info string names a shell — `bash`, `sh`, `shell`, `zsh`,
+  `console`, `shell-session`. Fences tagged `text`, `yaml`, `json`, or tagged with nothing, are **not**
+  checked;
+- the **opening** backticked span of a "Run" column cell in a markdown dispatch table, and only the
+  opening span.
+
+That last narrowing is not fussiness. A Run cell routinely carries a command followed by prose about
+it, and the prose is clause 2. `git-worktrees/SKILL.md` has both shapes on adjacent rows — one cell
+reading `` `rtk git worktree add --track …` `` — always correct. `` `git worktree add <path>
+<branch>` `` expands to exactly this (instruction, then reference), and a `**Never** …` row whose Run
+cell is entirely explanation containing a bare `git push`. Checking every backticked span flags both;
+checking only a leading span flags neither, and still catches the ordinary
+`` | List | `git worktree list -v` | `` case the gate exists for.
+
+### The clause-3 opt-out
+
+A command that is deliberately bare — because rtk rewrites the output the skill parses, or because
+the command is interactive — is exempted by putting the literal string `ADR-0023` **on the same
+line**: in a shell comment for a code line, in the cell text for a table row.
+
+Per line, never per block. A fenced procedure routinely mixes `rtk git` steps with one deliberately
+bare command (`git-remotes/references/push.md` does exactly that), and a block-level marker would
+silently disarm every checked line around the marked one. The cost is a repeated `# bare per
+ADR-0023` in the three blocks of `git-log-format.md` where every line is deliberately bare; that
+repetition is the price of the marked line being the only line the marker speaks for.
+
+The marker is a plain substring match, so a line that mentions `ADR-0023` for an unrelated reason is
+also exempt. Accepted deliberately: the marker records an author's opt-out, it is not a security
+boundary, and a stricter form would only move the same trust to a different string.
+
+### What it deliberately does not cover
+
+- **Clause 2.** Nothing checks that an illustrative mention stayed bare. A sweep that re-prefixes a
+  referential `git` passes this gate. The inline reasons ADR-0023 requires on clause-3 sites are the
+  only defence, and they are prose.
+- **Prose bullets.** Most of `branch-operations.md`, `merging.md` and `rewrite-history.md` instruct
+  in list items, not fences. Those are clause-1 sites the gate cannot see, because it cannot
+  distinguish them from clause-2 mentions in the same list.
+- **`README.md`, excluded by pattern.** A skill-directory README is consumer-facing prose no agent
+  loads, and the `git clone https://github.com/bats-core/…` lines in the seven `tests/README.md`
+  files are setup instructions for a third party who has no `rtk`. Prefixing those would be actively
+  wrong, not merely noisy — see ADR-0023's consumer section.
+- **Quoting.** The line splitter breaks on `;`, `|`, `&&`, `||`, `$(` and backticks without tracking
+  quotes, so a git command inside a quoted argument is decided by accident.
+  `rtk git submodule foreach 'git pull origin main || :'` passes because the segment holding the
+  inner command begins with `rtk` — the right answer for the wrong reason. Write
+  `foreach 'git a; git b'` and the second inner command is a false positive needing the marker.
+  ADR-0023 records this shape as one the rule itself does not decide.
+- **Non-git commands.** Only `git` is checked. `rtk` fronts `gh`, `docker`, `kubectl` and others; no
+  gate covers those, and the corpus does not currently instruct them.
+
+`tests/test-check-rtk-prefix.sh` pins all of it, including the false-positive cases. Its first case
+reconstructs the plugin corpus as it stood on `main` before the #113 sweep and asserts the gate
+fails there with at least 20 findings, one of them the `gitea-*` `git remote get-url origin` drift
+the sweep missed — a gate that only passes on the already-fixed tree proves nothing about the drift
+it was written for.
+
 ## Vale
 
 Install the `vale` binary — `brew install vale` (macOS), `snap install vale` (Linux),

plugins/bin/.apm/skills/caveman/SKILL.md

@@ -4,6 +4,8 @@ disable-model-invocation: true
 description: >
   Ultra-compressed output mode that drops articles, filler and pleasantries while
   keeping technical substance exact, cutting token usage by roughly 75%.
+metadata:
+  version: "1.0.0"
 ---
 
 Respond terse like smart caveman. All technical substance stay. Only fluff die.

plugins/bin/.apm/skills/diagnose/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when the user says "diagnose this" or "debug this", reports something
   broken, throwing, or failing, or says something got slow. Not filing or
   triaging a reported bug -> `triage`. Not test-first feature work -> `tdd`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Diagnose

plugins/bin/.apm/skills/grill-me/SKILL.md

@@ -5,6 +5,8 @@ description: >
   relentless interview — one question at a time, down each branch of the
   decision tree. Not a plan to challenge against `CONTEXT.md` and ADRs ->
   `grill-with-docs`.
+metadata:
+  version: "1.0.0"
 ---
 
 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

plugins/bin/.apm/skills/grill-with-docs/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when a plan should be stress-tested against the project's domain model —
   the interview challenges terms against `CONTEXT.md` and writes decisions into
   it and into ADRs as they land. Not a plain interview -> `grill-me`.
+metadata:
+  version: "1.0.0"
 ---
 
 <what-to-do>

plugins/bin/.apm/skills/improve-codebase-architecture/SKILL.md

@@ -6,6 +6,8 @@ description: >
   testable and AI-navigable — deepening opportunities that turn shallow modules
   into deep ones, informed by `CONTEXT.md` and `docs/adr/`. Not debugging a
   failure -> `diagnose`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Improve Codebase Architecture

plugins/bin/.apm/skills/prototype/SKILL.md

@@ -5,6 +5,8 @@ description: >
   a data model, state machine or business logic, or to mock up a UI in several
   variations. Not production code -> `tdd`. Not talking a design through ->
   `grill-me`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Prototype

plugins/bin/.apm/skills/research/SKILL.md

@@ -6,6 +6,7 @@ description: >-
   documentation written from existing code or specs -> `write-docs`. Not a bug
   or incident -> `diagnose`.
 metadata:
+  version: "1.0.0"
   category: research
 allowed-tools:
   - Grep

plugins/bin/.apm/skills/tdd/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when the user wants a feature built or a bug fixed test-first, in a strict
   red-green-refactor loop, one behaviour at a time. Not diagnosing an existing
   bug -> `diagnose`. Not throwaway exploratory code -> `prototype`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Test-Driven Development

plugins/bin/.apm/skills/triage/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when the user wants an issue created, triaged, or moved through the
   tracker's triage states, or an issue prepared for an AFK agent. Not debugging
   the bug itself -> `diagnose`. Not fleshing out a design -> `grill-with-docs`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Triage

plugins/bin/.apm/skills/write-docs/SKILL.md

@@ -6,10 +6,10 @@ description: >
   module", "create docs for this feature", "write a README for this". Not an ADR
   or other decision record -> `grill-with-docs`. Not an external tool researched
   from its docs -> `research`.
-version: "1.0"
 updated: 2026-05-17
 when: invoked by explicit trigger ("write docs for X", "document this module", "create docs for this feature") or implicit request to produce technical documentation from code or spec
 metadata:
+  version: "1.0.0"
   category: implement
 source:
   - repo: anthropics/skills

plugins/bin/.apm/skills/zoom-out/SKILL.md

@@ -2,6 +2,8 @@
 name: zoom-out
 description: Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.
 disable-model-invocation: true
+metadata:
+  version: "1.0.0"
 ---
 
 I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.

plugins/bin/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "bin",
-  "version": "1.1.6",
+  "version": "1.1.7",
   "description": "Skills for everyday AI-assisted development work that is not tied to a single tool, forge or language, and has not yet been split into a focused plugin.",
   "author": {
     "name": "Defame1297",

plugins/bin/.github/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "bin",
-  "version": "1.1.6",
+  "version": "1.1.7",
   "description": "Skills for everyday AI-assisted development work that is not tied to a single tool, forge or language, and has not yet been split into a focused plugin.",
   "author": {
     "name": "Defame1297",

plugins/bin/apm.yml

@@ -1,5 +1,5 @@
 name: bin
-version: 1.1.6
+version: 1.1.7
 description: Skills for everyday AI-assisted development work that is not tied to a single tool, forge or language, and has not yet been split into a focused plugin.
 author:
   name: Defame1297

plugins/bin/skills/caveman/SKILL.md

@@ -4,6 +4,8 @@ disable-model-invocation: true
 description: >
   Ultra-compressed output mode that drops articles, filler and pleasantries while
   keeping technical substance exact, cutting token usage by roughly 75%.
+metadata:
+  version: "1.0.0"
 ---
 
 Respond terse like smart caveman. All technical substance stay. Only fluff die.

plugins/bin/skills/diagnose/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when the user says "diagnose this" or "debug this", reports something
   broken, throwing, or failing, or says something got slow. Not filing or
   triaging a reported bug -> `triage`. Not test-first feature work -> `tdd`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Diagnose

plugins/bin/skills/grill-me/SKILL.md

@@ -5,6 +5,8 @@ description: >
   relentless interview — one question at a time, down each branch of the
   decision tree. Not a plan to challenge against `CONTEXT.md` and ADRs ->
   `grill-with-docs`.
+metadata:
+  version: "1.0.0"
 ---
 
 Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

plugins/bin/skills/grill-with-docs/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when a plan should be stress-tested against the project's domain model —
   the interview challenges terms against `CONTEXT.md` and writes decisions into
   it and into ADRs as they land. Not a plain interview -> `grill-me`.
+metadata:
+  version: "1.0.0"
 ---
 
 <what-to-do>

plugins/bin/skills/improve-codebase-architecture/SKILL.md

@@ -6,6 +6,8 @@ description: >
   testable and AI-navigable — deepening opportunities that turn shallow modules
   into deep ones, informed by `CONTEXT.md` and `docs/adr/`. Not debugging a
   failure -> `diagnose`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Improve Codebase Architecture

plugins/bin/skills/prototype/SKILL.md

@@ -5,6 +5,8 @@ description: >
   a data model, state machine or business logic, or to mock up a UI in several
   variations. Not production code -> `tdd`. Not talking a design through ->
   `grill-me`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Prototype

plugins/bin/skills/research/SKILL.md

@@ -6,6 +6,7 @@ description: >-
   documentation written from existing code or specs -> `write-docs`. Not a bug
   or incident -> `diagnose`.
 metadata:
+  version: "1.0.0"
   category: research
 allowed-tools:
   - Grep

plugins/bin/skills/tdd/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when the user wants a feature built or a bug fixed test-first, in a strict
   red-green-refactor loop, one behaviour at a time. Not diagnosing an existing
   bug -> `diagnose`. Not throwaway exploratory code -> `prototype`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Test-Driven Development

plugins/bin/skills/triage/SKILL.md

@@ -4,6 +4,8 @@ description: >
   Use when the user wants an issue created, triaged, or moved through the
   tracker's triage states, or an issue prepared for an AFK agent. Not debugging
   the bug itself -> `diagnose`. Not fleshing out a design -> `grill-with-docs`.
+metadata:
+  version: "1.0.0"
 ---
 
 # Triage

plugins/bin/skills/write-docs/SKILL.md

@@ -6,10 +6,10 @@ description: >
   module", "create docs for this feature", "write a README for this". Not an ADR
   or other decision record -> `grill-with-docs`. Not an external tool researched
   from its docs -> `research`.
-version: "1.0"
 updated: 2026-05-17
 when: invoked by explicit trigger ("write docs for X", "document this module", "create docs for this feature") or implicit request to produce technical documentation from code or spec
 metadata:
+  version: "1.0.0"
   category: implement
 source:
   - repo: anthropics/skills

plugins/bin/skills/zoom-out/SKILL.md

@@ -2,6 +2,8 @@
 name: zoom-out
 description: Tell the agent to zoom out and give broader context or a higher-level perspective. Use when you're unfamiliar with a section of code or need to understand how it fits into the bigger picture.
 disable-model-invocation: true
+metadata:
+  version: "1.0.0"
 ---
 
 I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.

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

@@ -9,6 +9,7 @@ description: >
   Not a Gitea remote's branches -> `gitea-branches`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - context7-git-htmldocs
@@ -20,7 +21,7 @@ metadata:
 ## Gotchas
 
 - **Uncommitted changes abort a switch.** `git switch` refuses rather than clobbering conflicting local edits. Offer to stash and retry — forcing the checkout past it is how work disappears.
-- **A branch and a tag can carry the same name.** Detect it before acting — `git branch --list <name>` and `git tag --list <name>`; output from both means the name is ambiguous. Prefer `git switch` over `git checkout`, and where a command accepts either ref, disambiguate with `refs/heads/<name>` or `refs/tags/<name>`.
+- **A branch and a tag can carry the same name.** Detect it before acting — `git branch --list <name>` (bare, not `rtk`: rtk prints a phantom `* ` line even on no match, which reports every name as ambiguous — ADR-0023) and `rtk git tag --list <name>`; output from both means the name is ambiguous. Prefer `git switch` over `git checkout`, and where a command accepts either ref, disambiguate with `refs/heads/<name>` or `refs/tags/<name>`.
 - **`main` and `master` are a refusal, not a gate.** Force-pushing, force-deleting, or renaming them is rejected even when the caller passes `confirm: true` — no flag makes the remote's history recoverable. Offer a new branch instead.
 
 ## Step 1 — Determine the branching pattern
@@ -51,7 +52,7 @@ These gates are passable. The `main`/`master` refusal in Gotchas is not.
 
 ## Step 4 — Set tracking
 
-A new branch's first push must be `git push -u origin <branch>`. The push itself is `git-remotes`' — every remote-side gate lives there, which is why Step 2's remote-delete row hands off the same way — but the upstream requirement originates here, so carry it in the handoff. Without an upstream, later pushes and pulls either fail or silently target the wrong remote branch, and the caller has no way to tell which happened.
+A new branch's first push must be `rtk git push -u origin <branch>`. The push itself is `git-remotes`' — every remote-side gate lives there, which is why Step 2's remote-delete row hands off the same way — but the upstream requirement originates here, so carry it in the handoff. Without an upstream, later pushes and pulls either fail or silently target the wrong remote branch, and the caller has no way to tell which happened.
 
 ## Step 5 — Return a structured result
 

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

@@ -8,21 +8,21 @@ source_keys:
 One command per action. Where two forms exist, the first is the default and the second the escape
 hatch.
 
-- **create** — `git switch -c <branch> <base>`. Base comes from the config's `base_branch`
+- **create** — `rtk git switch -c <branch> <base>`. Base comes from the config's `base_branch`
   (`main` under GitHub Flow, usually `develop` under Gitflow).
-- **switch** — `git switch <branch>` moves to an existing local branch; it aborts rather than
-  clobbering conflicting local changes. `git switch -` returns to the previous branch.
-- **delete (local)** — `git branch -d <branch>` refuses when the branch holds unmerged commits,
-  which is why it is the default. `git branch -D <branch>` forces the deletion and discards that
+- **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,
+  which is why it is the default. `rtk git branch -D <branch>` forces the deletion and discards that
   work — only after the destructive-operation gates pass and `confirm: true` is set.
 - **delete (remote)** — not this skill's. Deleting a remote branch is a push, and every remote-side
   gate lives in `git-remotes`; hand it there rather than running the push from here. Its
   `references/push.md` carries the command and the refspec form.
-- **rename** — `git branch -m <old> <new>`.
-- **list** — `git branch` (local), `-a` (local plus remote-tracking), `-r` (remote-tracking only),
+- **rename** — `rtk git branch -m <old> <new>`.
+- **list** — `rtk git branch` (local), `-a` (local plus remote-tracking), `-r` (remote-tracking only),
   `--merged` / `--no-merged` (filter by merge status into the current branch).
-- **track** — `git branch --set-upstream-to=origin/<branch>` sets an upstream without pushing.
-  `git branch -vv` shows the tracking state of every local branch.
+- **track** — `rtk git branch --set-upstream-to=origin/<branch>` sets an upstream without pushing.
+  `rtk git branch -vv` shows the tracking state of every local branch.
 
 ## get-intent
 
@@ -40,17 +40,20 @@ intent is worse than one built on none.
 A switch aborts rather than clobbering conflicting local changes (see Gotchas). Stash is the way
 past it: it shelves the working tree and index so the branch pointer can move.
 
-- **save** — `git stash push -m "<message>"`. Add `-u` to include untracked files; verified on Git
+- **save** — `rtk git stash push -m "<message>"`. Add `-u` to include untracked files; verified on Git
   2.39.5, a plain `push` leaves them in place, and a plain `push` with *only* untracked changes
   reports `No local changes to save` and stashes nothing. Bare `git stash` is `push` with no message.
-- **restore** — `git stash pop` applies the newest entry and deletes it. `git stash apply stash@{n}`
+- **restore** — `git stash pop` applies the newest entry and deletes it. Bare, not `rtk`: on a
+  conflict rtk prints only `FAILED: git stash pop` and swallows the conflict report the paragraph
+  below tells you to read (ADR-0023). `rtk git stash apply stash@{n}`
   applies without deleting, for replaying one shelf onto more than one branch.
-- **list** — `git stash list`; `git stash show -p stash@{n}` prints that entry's diff.
-- **drop** — `git stash drop stash@{n}` deletes one entry. `git stash clear` deletes all of them
+- **list** — `git stash list` — bare, not `rtk`: rtk prints `No stashes` where git prints nothing,
+  so an empty-output test misfires (ADR-0023). `rtk git stash show -p stash@{n}` prints that entry's diff.
+- **drop** — `rtk git stash drop stash@{n}` deletes one entry. `rtk git stash clear` deletes all of them
   and nothing recovers them — confirm before running it.
-- **branch from a stash** — `git stash branch <branch> stash@{n}` creates a branch at the commit the
+- **branch from a stash** — `rtk git stash branch <branch> stash@{n}` creates a branch at the commit the
   stash was taken from and pops it there. Use it when the stash no longer applies to the current tip.
 
 **A conflicting `pop` keeps the entry.** Verified on 2.39.5: it exits 1, writes conflict markers,
 prints "The stash entry is kept in case you need it again", and `git stash list` still shows it.
-Resolve, `git add`, then `git stash drop` the entry by hand — otherwise it silently accumulates.
+Resolve, `rtk git add`, then `rtk git stash drop` the entry by hand — otherwise it silently accumulates.

plugins/git/.apm/skills/git-branches/references/comparing-branches.md

@@ -8,9 +8,9 @@ source_keys:
 The two-dot and three-dot forms mean different things and are easy to swap by accident — check the
 direction before reporting a result.
 
-- `git log main..feature` — commits on `feature` that are not on `main`.
-- `git log feature..main` — the reverse direction: commits on `main` not on `feature`.
-- `git log --left-right main...feature` — both diverging sets at once (symmetric difference).
-- `git diff main...feature` — the diff from the common ancestor to `feature`'s tip, which is what
+- `rtk git log main..feature` — commits on `feature` that are not on `main`.
+- `rtk git log feature..main` — the reverse direction: commits on `main` not on `feature`.
+- `rtk git log --left-right main...feature` — both diverging sets at once (symmetric difference).
+- `rtk git diff main...feature` — the diff from the common ancestor to `feature`'s tip, which is what
   a reviewer sees, rather than the diff between the two tips.
-- `git merge-base main feature` — print the common ancestor commit.
+- `rtk git merge-base main feature` — print the common ancestor commit.

plugins/git/.apm/skills/git-branches/references/merging.md

@@ -9,22 +9,23 @@ source_keys:
 Scope is fast-forward and merge-commit mechanics plus conflict resolution. Rebase and cherry-pick
 belong to `git-commits`; revert to `git-history`.
 
-- **Fast-forward** — `git merge <branch>` advances the pointer with no merge commit when the
+- **Fast-forward** — `rtk git merge <branch>` advances the pointer with no merge commit when the
   target has not diverged.
-- **True merge** — `git merge --no-ff <branch>` forces a merge commit even when a fast-forward is
+- **True merge** — `rtk git merge --no-ff <branch>` forces a merge commit even when a fast-forward is
   possible. Gitflow requires it on every supporting-branch merge.
-- **Squash merge** — `git merge --squash <branch>` stages the combined diff without committing.
-  Follow it with a `git commit`.
-- **Octopus merge** — `git merge branch-a branch-b branch-c` merges more than two branches at
+- **Squash merge** — `rtk git merge --squash <branch>` stages the combined diff without committing.
+  Follow it with a `rtk git commit`.
+- **Octopus merge** — `rtk git merge branch-a branch-b branch-c` merges more than two branches at
   once, but fails outright on any conflict. Use sequential two-way merges when conflicts are
   likely.
 
 ## Conflict resolution
 
-When Git cannot auto-merge it writes conflict markers and stops mid-merge. Run `git status` to
-list the conflicted files, edit each to resolve its markers, then `git add <file>` and
-`git merge --continue`.
+When Git cannot auto-merge it writes conflict markers and stops mid-merge. Run `rtk git status` to
+list the conflicted files, edit each to resolve its markers, then `rtk git add <file>` and
+`rtk git merge --continue`.
 
-- `git merge --abort` restores the pre-merge state.
-- `git mergetool` opens the configured merge tool.
-- `git diff --diff-filter=U` shows only the still-conflicted files.
+- `rtk git merge --abort` restores the pre-merge state.
+- `git mergetool` opens the configured merge tool — bare, not `rtk`: it hands control to an
+  interactive child process, and a token filter has nothing to offer there (ADR-0023).
+- `rtk git diff --diff-filter=U` shows only the still-conflicted files.

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

@@ -8,7 +8,7 @@ description: >
   Not branch lifecycle -> `git-branches`.
 
 metadata:
-  version: "0.1.3"
+  version: "0.1.4"
   category: git
   source_keys:
     - conventional-commits-spec
@@ -21,7 +21,7 @@ allowed-tools: Bash
 
 ## Gotchas
 
-- **Run git as `rtk git <subcommand>`, never bare `git`** — org convention, in `&&` chains too.
+- **Run git as `rtk git <subcommand>`, never bare `git`** — org convention, in `&&` chains too. Exceptions: ADR-0023 clause 3.
 - **Refuse to force-push `main`/`master`** — a rewrite leaves the branch diverged and the reflex is to force it back; safe only where nobody else has based work on it.
 - **`reset --hard` is a confirmation gate, not a default.** It overwrites the working tree, and uncommitted edits it discards were never in git, so no reflog recovers them. Name what will be lost and offer a stash first.
 - **Never add `--no-verify`** — using it when a hook fails bypasses the QA gate the pipeline depends on. Only on the user's explicit demand, with a warning.

plugins/git/.apm/skills/git-commits/references/rewrite-history.md

@@ -21,9 +21,9 @@ Prefer this whenever a commit is written to be folded, because git does the mark
 
 1. `rtk git commit --fixup=<commit>` keeps the target's message; `rtk git commit --squash=<commit>` lets you edit the combined message later. Both prefix the message with `fixup!`/`squash!` and name the target commit.
 2. Get explicit approval — the rebase still rewrites history.
-3. Run `rtk git rebase -i --autosquash HEAD~N`. Git pre-fills the todo list with the tagged commits already reordered against their targets; save it unchanged to apply.
+3. Run `git rebase -i --autosquash HEAD~N` — bare, not `rtk`: `-i` opens an interactive sequence editor (ADR-0023). Git pre-fills the todo list with the tagged commits already reordered against their targets; save it unchanged to apply.
 
-**`-i` is not optional here.** On Git 2.39.5, `rtk git rebase --autosquash HEAD~N` without `-i` prints `Successfully rebased and updated refs/heads/<branch>.` and exits 0 while leaving the `fixup!` commit in place at its original SHA — `--autosquash` is honoured only by the interactive machinery, and the false success is the trap: the fold is reported as done, and the surviving `fixup!` subject then fails the Conventional Commits `commit-msg` hook. Later Git versions taught the non-interactive rebase to honour the flag, but `-i --autosquash` is correct on every version, so always write that.
+**`-i` is not optional here.** On Git 2.39.5, `git rebase --autosquash HEAD~N` without `-i` prints `Successfully rebased and updated refs/heads/<branch>.` and exits 0 while leaving the `fixup!` commit in place at its original SHA — `--autosquash` is honoured only by the interactive machinery, and the false success is the trap: the fold is reported as done, and the surviving `fixup!` subject then fails the Conventional Commits `commit-msg` hook. Later Git versions taught the non-interactive rebase to honour the flag, but `-i --autosquash` is correct on every version, so always write that.
 
 ## Squash by hand (interactive rebase)
 
@@ -31,7 +31,7 @@ Use this when the commits were not tagged at commit time. **Interactive rebase h
 
 1. Identify the commits to squash — typically the last N on the current branch.
 2. Get explicit approval.
-3. Run `rtk git rebase -i HEAD~N`, marking the older commits `squash` to keep their messages for editing, or `fixup` to discard them.
+3. Run `git rebase -i HEAD~N` — bare, not `rtk`, for the same interactive-editor reason — marking the older commits `squash` to keep their messages for editing, or `fixup` to discard them.
 4. Compose the combined message when the rebase stops to ask. For a non-trivial combined message, follow the structure in `references/commit-template.md`.
 
 ## When a rebase halts on a conflict

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

@@ -8,6 +8,7 @@ description: >
   `git-commits`. Not a Gitea server's history -> `gitea-branches`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - git-scm-bisect-docs
@@ -34,13 +35,13 @@ allowed-tools: Bash
 
 ## Step 2 — Query the log
 
-Default to `git log --oneline`, then narrow by whatever is known:
+Default to `rtk git log --oneline`, then narrow by whatever is known:
 
-- **Content**: `git log -S"string"`, or `-G"regex"` to match any diff line. `--pickaxe-regex` makes the `-S` argument a POSIX ERE; `--pickaxe-all` shows every file in a matching changeset.
-- **A line or function**: `git log -L <start>,<end>:<file>` or `git log -L :<function>:<file>`. Confirm the range resolves before reporting on it — an off-by-one silently omits the target.
-- **A file across renames**: `git log --follow -- <file>`. Without `--follow` the history stops at the rename boundary.
+- **Content**: `rtk git log -S"string"`, or `-G"regex"` to match any diff line. `--pickaxe-regex` makes the `-S` argument a POSIX ERE; `--pickaxe-all` shows every file in a matching changeset.
+- **A line or function**: `git log -L <start>,<end>:<file>` or `git log -L :<function>:<file>` — bare, not `rtk`: rtk truncates each diff line at ~72 characters (ADR-0023). Confirm the range resolves before reporting on it — an off-by-one silently omits the target.
+- **A file across renames**: `rtk git log --follow -- <file>`. Without `--follow` the history stops at the rename boundary.
 - **Mainline only**: `--first-parent` follows the integration branch and skips commits merged in from side branches.
-- **Structured output**: `git log --format="%h | %s | %an (%ar)"`.
+- **Structured output**: `rtk git log --format="%h | %s | %an (%ar)"`.
 
 If you need the placeholder catalogue, format presets, `--diff-filter` letters, full `-L` syntax, ancestry filters, pickaxe binary-file behaviour, or `git diff` output-control flags such as `--stat`, `--word-diff` and the whitespace options, read `references/git-log-format.md`.
 
@@ -49,8 +50,8 @@ If you need the placeholder catalogue, format presets, `--diff-filter` letters,
 Offer the operation and its consequence; run it only once the user has chosen.
 
 - Backporting the commit to another branch is a cherry-pick, and cherry-pick is `git-commits`' — it owns the destination-branch check, the `rtk git` wrapper and the `--abort` path. Hand it the SHA; do not run `git cherry-pick` from here.
-- `git revert <commit>` adds a new commit undoing it — for un-applying merged work without rewriting history.
-- `git blame <file>` attributes each line to the commit that last touched it, when the question is which commit introduced one specific line.
+- `rtk git revert <commit>` adds a new commit undoing it — for un-applying merged work without rewriting history.
+- `rtk git blame <file>` attributes each line to the commit that last touched it, when the question is which commit introduced one specific line.
 
 For diff output control on the located commit, read `references/git-log-format.md`.
 

plugins/git/.apm/skills/git-history/references/bisect.md

@@ -12,43 +12,43 @@ or line range to search the log for. Binary search reduces the trials from O(N)
 ## Manual flow
 
 ```bash
-git bisect start
-git bisect bad [HEAD]        # mark current (or specified) as broken
-git bisect good <commit>     # mark known-good baseline
+rtk git bisect start
+rtk git bisect bad [HEAD]        # mark current (or specified) as broken
+rtk git bisect good <commit>     # mark known-good baseline
 # Git checks out the midpoint; test it
-git bisect good              # test passes
-git bisect bad               # test fails
+rtk git bisect good              # test passes
+rtk git bisect bad               # test fails
 # Repeat until git reports "X is the first bad commit"
-git bisect reset             # return to the original HEAD
+rtk git bisect reset             # return to the original HEAD
 ```
 
 ## Automated
 
-With a test command available, use `git bisect run <cmd>`. Git reads the exit code: `0` good,
+With a test command available, use `rtk git bisect run <cmd>`. Git reads the exit code: `0` good,
 `1`–`124` bad, `125` skip (build broken), `126`–`127` POSIX shell errors, treated as bad, and
 `128` or above aborts the session outright rather than marking the commit bad.
 
 ## Untestable commits
 
-`git bisect skip` excludes a commit that cannot be built or tested without deciding good or bad
+`rtk git bisect skip` excludes a commit that cannot be built or tested without deciding good or bad
 for it. When the first bad commit is adjacent to a skipped range, bisect reports that it cannot
 pinpoint the culprit and lists the candidates — that is the precise answer the skip range allows,
 not a failure.
 
 ## Undoing a wrong good/bad call
 
-`git bisect log` prints the session's decision history. Save it, edit out the mistaken entry, and
+`rtk git bisect log` prints the session's decision history. Save it, edit out the mistaken entry, and
 resume from the corrected log rather than restarting the search:
 
 ```bash
-git bisect log > bisect.log
+rtk git bisect log > bisect.log
 # edit bisect.log, removing the wrong decision
-git bisect reset && git bisect replay bisect.log
+rtk git bisect reset && rtk git bisect replay bisect.log
 ```
 
 ## Narrowing and speeding up
 
-- `git bisect start HEAD v1.2 -- src/` restricts bisection to a path, cutting the trial count.
+- `rtk git bisect start HEAD v1.2 -- src/` restricts bisection to a path, cutting the trial count.
 - `--no-checkout` updates the `BISECT_HEAD` ref instead of checking out a working tree — useful
   for tests that do not need one, and automatic in bare repos.
 - `--first-parent` follows only first parents at merges, finding the integration commit that
@@ -56,12 +56,12 @@ git bisect reset && git bisect replay bisect.log
 
 ## Inspecting the remaining candidates
 
-`git bisect visualize` (alias `view`) opens the suspects in gitk, falling back to `git log` when
+`rtk git bisect visualize` (alias `view`) opens the suspects in gitk, falling back to `git log` when
 no graphical display is detected. Add `--stat` or `-p` for a diffstat or full patches.
 
 ## Hunting a non-bug property change
 
-`git bisect start --term-new <new> --term-old <old>` searches for any property change — a
+`rtk git bisect start --term-new <new> --term-old <old>` searches for any property change — a
 performance regression, say — instead of a bug. Use the custom terms in place of `good` and `bad`
 for the rest of the session.
 

plugins/git/.apm/skills/git-history/references/git-log-format.md

@@ -116,15 +116,15 @@ source_keys:
 **`-S<string>`** — finds commits where the **count** of `<string>` changed (i.e. the string was added or removed net). Does not match commits where the string merely appears in a diff hunk without a count change.
 
 ```bash
-git log -S"my_function"
-git log -S"my_function" --pickaxe-regex    # treat as POSIX ERE
-git log -S"my_function" --pickaxe-all      # show all files in matching changesets
+rtk git log -S"my_function"
+rtk git log -S"my_function" --pickaxe-regex    # treat as POSIX ERE
+rtk git log -S"my_function" --pickaxe-all      # show all files in matching changesets
 ```
 
 **`-G<regex>`** — finds commits where any added or removed **line** in the patch matches `<regex>`. Broader than `-S`: matches whenever the pattern appears in diff text regardless of count.
 
 ```bash
-git log -G"frotz\(nitfol"
+rtk git log -G"frotz\(nitfol"
 ```
 
 **Critical distinction:** given a diff that removes one occurrence of `foo` and adds one occurrence of `foo` (net change = 0):
@@ -151,8 +151,8 @@ Selects commits (in `git log`) or files (in `git diff`) by change type:
 
 Lowercase letters **exclude** that type:
 ```bash
-git log --diff-filter=ad       # exclude added and deleted files
-git log --diff-filter=M        # only show commits with modified files
+rtk git log --diff-filter=ad       # exclude added and deleted files
+rtk git log --diff-filter=M        # only show commits with modified files
 ```
 
 `C` and `R` only appear when copy/rename detection is enabled (`-C`, `-M` flags or `diff.renames` config).
@@ -161,11 +161,15 @@ git log --diff-filter=M        # only show commits with modified files
 
 Traces the evolution of a specific range of lines or a named function through commits. Implies `--patch`.
 
+Bare `git`, not `rtk git`, on every `-L` form below: rtk truncates each diff body
+line at roughly 72 characters with an ellipsis, on the one query whose whole point
+is showing line content.
+
 ```bash
-git log -L 10,20:file.txt
-git log -L /start_pattern/,/end_pattern/:file.txt
-git log -L :myfunction:src/app.c
-git log -L /init/,+15:config.py          # 15 lines after first match of /init/
+git log -L 10,20:file.txt                          # bare per ADR-0023
+git log -L /start_pattern/,/end_pattern/:file.txt  # bare per ADR-0023
+git log -L :myfunction:src/app.c                   # bare per ADR-0023
+git log -L /init/,+15:config.py                    # bare per ADR-0023; 15 lines after first /init/ match
 ```
 
 Range formats:
@@ -182,12 +186,12 @@ Limitations: incompatible with `--raw`, `--numstat`, `--shortstat`, `--name-only
 ## Graph and Ancestry Filters
 
 ```bash
-git log --first-parent            # at merges, follow only first parent (mainline evolution)
-git log --merges                  # only merge commits (≥2 parents); equivalent to --min-parents=2
-git log --no-merges               # only non-merge commits; equivalent to --max-parents=1
-git log --ancestry-path D..M      # only commits actually on the path from D to M
-git log --min-parents=<n>         # include only commits with ≥ n parents
-git log --max-parents=<n>         # include only commits with ≤ n parents
+rtk git log --first-parent            # at merges, follow only first parent (mainline evolution)
+rtk git log --merges                  # only merge commits (≥2 parents); equivalent to --min-parents=2
+rtk git log --no-merges               # only non-merge commits; equivalent to --max-parents=1
+rtk git log --ancestry-path D..M      # only commits actually on the path from D to M
+rtk git log --min-parents=<n>         # include only commits with ≥ n parents
+rtk git log --max-parents=<n>         # include only commits with ≤ n parents
 ```
 
 `--ancestry-path` is significant: without it, `D..M` includes all commits reachable from M but not D — including side branches that merged into the path. With it, only commits directly between D and M are shown.
@@ -197,28 +201,34 @@ git log --max-parents=<n>         # include only commits with ≤ n parents
 ### --stat
 
 ```bash
-git diff --stat                   # diffstat: file names + ± bar
-git diff --stat=<width>,<name-width>,<count>
-git diff --compact-summary        # alongside --stat: shows new/gone, +x/-x (executable), +l (symlink)
-git diff --numstat                # machine-readable: <added>\t<deleted>\t<path>; - for binary
+rtk git diff --stat                   # diffstat: file names + ± bar
+rtk git diff --stat=<width>,<name-width>,<count>
+rtk git diff --compact-summary        # alongside --stat: shows new/gone, +x/-x (executable), +l (symlink)
+rtk git diff --numstat                # machine-readable: <added>\t<deleted>\t<path>; - for binary
 ```
 
 ### --name-only / --name-status
 
+Bare `git`, not `rtk git`: rtk appends a blank line and a `Changes:` trailer, so
+the output is no longer one record per line.
+
 ```bash
-git diff --name-only              # only filenames, one per line
-git diff --name-status            # status letter + filename per line
+git diff --name-only      # bare per ADR-0023; only filenames, one per line
+git diff --name-status    # bare per ADR-0023; status letter + filename per line
 ```
 
 `--name-status` uses the same status letters as `--diff-filter`.
 
 ### --word-diff
 
+Bare `git`, not `rtk git`: rtk replaces the word-diff with its own diffstat
+renderer and emits none of the `[-removed-] {+added+}` markers.
+
 ```bash
-git diff --word-diff              # inline word-level diff with [-removed-] {+added+} markers
-git diff --word-diff=color        # color only, no markers
-git diff --word-diff=porcelain    # machine-readable: +/- prefixed lines, ~ for newlines
-git diff --word-diff-regex=<re>   # define what counts as a "word"
+git diff --word-diff             # bare per ADR-0023; inline word-level diff, [-removed-] {+added+} markers
+git diff --word-diff=color       # bare per ADR-0023; color only, no markers
+git diff --word-diff=porcelain   # bare per ADR-0023; machine-readable: +/- prefixed lines, ~ for newlines
+git diff --word-diff-regex=<re>  # bare per ADR-0023; define what counts as a "word"
 ```
 
 ### Whitespace Flags

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

@@ -10,6 +10,7 @@ description: >
   Not submodule pointers -> `git-submodules`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - git-scm-remote-docs
@@ -27,7 +28,7 @@ metadata:
 
 ## Step 1 — Clear the force-push gate
 
-`main` and `master` are a hard refusal: decline a force-push targeting either, whatever confirmation accompanies it, because no local approval can restore what the remote loses. On any other branch, `git push --force` and `-f` run only after the caller passes `confirm: true` for that specific push — for a human caller, prompt instead of failing.
+`main` and `master` are a hard refusal: decline a force-push targeting either, whatever confirmation accompanies it, because no local approval can restore what the remote loses. On any other branch, `rtk git push --force` and `-f` run only after the caller passes `confirm: true` for that specific push — for a human caller, prompt instead of failing.
 
 ## Step 2 — Dispatch
 

plugins/git/.apm/skills/git-remotes/references/fetch.md

@@ -11,19 +11,19 @@ Fetch **with no refspec** updates remote-tracking branches (`refs/remotes/<name>
 
 That safety comes from the default refspec, not from `fetch` itself. Give it an explicit one and it writes to local branches: verified on Git 2.39.5, `git fetch origin main:probe` fast-forwarded the local `probe` branch, and a `+` prefix force-updates the destination, discarding whatever commits it held. Treat any `fetch` carrying a `<src>:<dst>` refspec as a branch update, not a read.
 
-- **One remote**: `git fetch <remote>` — all branches
-- **One branch**: `git fetch <remote> <branch>` — the result lands in `FETCH_HEAD`, not a tracking ref
-- **All remotes**: `git fetch --all`
-- **Prune properly**: `git fetch --all --prune --prune-tags` cleans stale branches *and* tags
-- **Auto-prune**: `git config --global fetch.prune true` (or `remote.<name>.prune` to scope it to one remote), and `fetch.pruneTags true` for tags
+- **One remote**: `rtk git fetch <remote>` — all branches
+- **One branch**: `rtk git fetch <remote> <branch>` — the result lands in `FETCH_HEAD`, not a tracking ref
+- **All remotes**: `rtk git fetch --all`
+- **Prune properly**: `rtk git fetch --all --prune --prune-tags` cleans stale branches *and* tags
+- **Auto-prune**: `rtk git config --global fetch.prune true` (or `remote.<name>.prune` to scope it to one remote), and `fetch.pruneTags true` for tags
 
 ## Shallow and partial fetch
 
 ```bash
-git fetch --depth=<n>             # deepen history, or create a shallow clone
-git fetch --unshallow             # convert a shallow clone to full history
-git fetch --update-shallow        # allow the fetch to update the shallow boundary
-git fetch --refmap='' <remote> <branch>  # fetch without updating any tracking ref (FETCH_HEAD only)
+rtk git fetch --depth=<n>             # deepen history, or create a shallow clone
+rtk git fetch --unshallow             # convert a shallow clone to full history
+rtk git fetch --update-shallow        # allow the fetch to update the shallow boundary
+rtk git fetch --refmap='' <remote> <branch>  # fetch without updating any tracking ref (FETCH_HEAD only)
 ```
 
 ## Default fetch refspec

plugins/git/.apm/skills/git-remotes/references/pull.md

@@ -9,11 +9,11 @@ source_keys:
 
 Default strategy: `--ff-only`. It fails on divergence, which forces a conscious choice instead of an accidental merge commit.
 
-- **Fast-forward only**: `git pull --ff-only` — the recommended default
-- **Rebase**: `git pull --rebase` replays your commits on top for linear history, but rewrites SHAs. Verify nothing being replayed has been pushed: rebasing published commits breaks everyone downstream.
-- **Merge**: `git pull --no-rebase` — three-way merge commit, preserves original commits, non-linear
-- **Rebase preserving merges**: `git pull --rebase=merges` keeps intentional local merge commits during the replay
-- **Stage without committing**: `git pull --squash` collapses incoming commits into staged changes; you write the message
+- **Fast-forward only**: `rtk git pull --ff-only` — the recommended default
+- **Rebase**: `rtk git pull --rebase` replays your commits on top for linear history, but rewrites SHAs. Verify nothing being replayed has been pushed: rebasing published commits breaks everyone downstream.
+- **Merge**: `rtk git pull --no-rebase` — three-way merge commit, preserves original commits, non-linear
+- **Rebase preserving merges**: `rtk git pull --rebase=merges` keeps intentional local merge commits during the replay
+- **Stage without committing**: `rtk git pull --squash` collapses incoming commits into staged changes; you write the message
 - **Merge strategy**: Git 2.34+ defaults to `ort` (`recursive` is now an alias for it). Strategy options such as `-X ours`, `-X theirs`, `-X ignore-space-change` pass through unchanged.
 - **Submodules**: `--recurse-submodules` only fetches submodules already checked out. Newly added ones are not initialized — use the `git-submodules` skill for those.
 
@@ -37,7 +37,7 @@ Highest wins:
 4. `branch.autoSetupRebase` (set automatically when the tracking branch was created)
 
 ```bash
-git config pull.ff only                  # deterministic default across Git versions
-git config --global pull.rebase true
-git config branch.develop.rebase false   # develop always merges, regardless of the global default
+rtk git config pull.ff only                  # deterministic default across Git versions
+rtk git config --global pull.rebase true
+rtk git config branch.develop.rebase false   # develop always merges, regardless of the global default
 ```

plugins/git/.apm/skills/git-remotes/references/push.md

@@ -9,14 +9,14 @@ source_keys:
 
 Default: safe push to the same-named branch on the remote.
 
-- **Force-push**: never bare `--force`. Use `git push --force-with-lease --force-if-includes <remote> <branch>`, after the SKILL.md Step 1 gate.
-- **Basic**: `git push <remote> <branch>`
-- **Set upstream**: `git push -u <remote> <branch>` — push and configure tracking
-- **Multi-remote**: push sequentially (`git push origin develop`, `git push staging develop`), or add a second push URL with `git remote set-url --add <name> <url>` to reach both in one command
-- **Delete a remote branch**: `git push <remote> --delete <branch>` — clearer than the `:<branch>` form
-- **Bulk**: `git push --all` (all local branches), `git push --tags` (all tags), `git push origin <tag>` (one tag)
-- **Delete remote branches with no local counterpart**: `git push --prune origin 'refs/heads/*:refs/heads/*'`
-- **Force only part of a multi-ref push**: prefix the one refspec that needs it with `+` — `git push origin +release develop` forces `release` while safe-pushing `develop`. A `+` prefix is a force-push and passes the SKILL.md Step 1 gate like any other.
+- **Force-push**: never bare `--force`. Use `rtk git push --force-with-lease --force-if-includes <remote> <branch>`, after the SKILL.md Step 1 gate.
+- **Basic**: `rtk git push <remote> <branch>`
+- **Set upstream**: `rtk git push -u <remote> <branch>` — push and configure tracking
+- **Multi-remote**: push sequentially (`rtk git push origin develop`, `rtk git push staging develop`), or add a second push URL with `rtk git remote set-url --add <name> <url>` to reach both in one command
+- **Delete a remote branch**: `rtk git push <remote> --delete <branch>` — clearer than the `:<branch>` form
+- **Bulk**: `rtk git push --all` (all local branches), `rtk git push --tags` (all tags), `rtk git push origin <tag>` (one tag)
+- **Delete remote branches with no local counterpart**: `rtk git push --prune origin 'refs/heads/*:refs/heads/*'`
+- **Force only part of a multi-ref push**: prefix the one refspec that needs it with `+` — `rtk git push origin +release develop` forces `release` while safe-pushing `develop`. A `+` prefix is a force-push and passes the SKILL.md Step 1 gate like any other.
 
 ## Refspec syntax — `[+]<src>[:<dst>]`
 
@@ -48,19 +48,21 @@ Two mitigations:
 # Option 1 — dedicated push-only remote: background tools fetch `origin`, you push
 # through a separate remote that nothing else touches, so its tracking ref can't be
 # poisoned by an unrelated fetch.
-git remote add origin-push $(git config remote.origin.url)
-git push --force-with-lease origin-push
+# The inner `git config` is bare: its stdout becomes a remote URL, so any
+# output rewriting would poison the remote silently.
+rtk git remote add origin-push $(git config remote.origin.url)   # inner bare per ADR-0023
+rtk git push --force-with-lease origin-push
 
 # Option 2 — explicit SHA via a local tag, unaffected by tracking-branch state
-git fetch
-git tag base master
-git rebase -i master
-git push --force-with-lease=master:base master:master
+rtk git fetch
+rtk git tag base master
+git rebase -i master   # bare, not `rtk` (ADR-0023): interactive sequence editor
+rtk git push --force-with-lease=master:base master:master
 ```
 
 `--force-if-includes` adds a second check on top of bare `--force-with-lease`: it verifies the remote-tracking tip actually appears in your local branch's reflog, i.e. you genuinely integrated it before rewriting. It is a no-op without `--force-with-lease`, and has no effect with the `--force-with-lease=<ref>:<sha>` form, which already pins an exact SHA.
 
-Safest combination: `git push --force-with-lease --force-if-includes origin`.
+Safest combination: `rtk git push --force-with-lease --force-if-includes origin`.
 
 ## Server-side policy
 

plugins/git/.apm/skills/git-remotes/references/remote-config.md

@@ -9,31 +9,31 @@ source_keys:
 
 Which remotes exist, where they point, and what they track.
 
-`git remote show <name>` needs network access — use `-n` for cached data offline, or `git remote -v`, which lists URLs without querying.
+`rtk git remote show <name>` needs network access — use `-n` for cached data offline, or `rtk git remote -v`, which lists URLs without querying.
 
 ## Add, remove, rename, inspect
 
-- **Add**: `git remote add <name> <url>`, or `-f` to fetch immediately
-- **Remove**: `git remote remove <name>` — deletes the remote, all its tracking refs, and its config
-- **Rename**: `git remote rename <old> <new>`
-- **Inspect**: `git remote -v` (URLs, offline) or `git remote show <name>` (live tracking status)
-- **Effective URLs**: `git remote get-url <name>` shows the URL after `insteadOf` rewrites; `git remote get-url --push --all <name>` lists every push URL
+- **Add**: `rtk git remote add <name> <url>`, or `-f` to fetch immediately
+- **Remove**: `rtk git remote remove <name>` — deletes the remote, all its tracking refs, and its config
+- **Rename**: `rtk git remote rename <old> <new>`
+- **Inspect**: `rtk git remote -v` (URLs, offline) or `rtk git remote show <name>` (live tracking status)
+- **Effective URLs**: `rtk git remote get-url <name>` shows the URL after `insteadOf` rewrites; `rtk git remote get-url --push --all <name>` lists every push URL
 
 ## Tracking, mirroring, housekeeping
 
-- **Track one branch**: `git remote add -t <branch> <name> <url>` (repeatable); `--no-tags` suppresses tag import entirely
+- **Track one branch**: `rtk git remote add -t <branch> <name> <url>` (repeatable); `--no-tags` suppresses tag import entirely
 - **Mirror**: `--mirror=fetch` mirrors all refs locally (bare repos only); `--mirror=push` makes every push behave like `--mirror`
-- **Prune stale tracking refs without fetching**: `git remote prune <name>`, with `--dry-run` to preview
-- **Default branch pointer**: `git remote set-head <name> -a` (auto-detect, needs a prior fetch), `... <branch>` (explicit), `... -d` (delete `refs/remotes/<name>/HEAD`)
+- **Prune stale tracking refs without fetching**: `rtk git remote prune <name>`, with `--dry-run` to preview
+- **Default branch pointer**: `rtk git remote set-head <name> -a` (auto-detect, needs a prior fetch), `... <branch>` (explicit), `... -d` (delete `refs/remotes/<name>/HEAD`)
 
 ## `set-url` — full form
 
 ```bash
-git remote set-url <name> <newurl>                  # replace the first fetch URL
-git remote set-url <name> <newurl> <oldurl-regex>   # replace only the URL matching regex
-git remote set-url --push <name> <url>              # change push URL only (must point at same repo)
-git remote set-url --add <name> <url>               # add an extra push URL (push to multiple remotes)
-git remote set-url --delete <name> <regex>          # remove URLs matching regex
+rtk git remote set-url <name> <newurl>                  # replace the first fetch URL
+rtk git remote set-url <name> <newurl> <oldurl-regex>   # replace only the URL matching regex
+rtk git remote set-url --push <name> <url>              # change push URL only (must point at same repo)
+rtk git remote set-url --add <name> <url>               # add an extra push URL (push to multiple remotes)
+rtk git remote set-url --delete <name> <regex>          # remove URLs matching regex
 ```
 
 `--push` changes only where pushes go — fetch and push URLs must still reference the same repository. For genuine fetch-from-A / push-to-B workflows, use two separate named remotes instead; `--push` cannot do this.

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

@@ -9,6 +9,7 @@ description: >
   Not the superproject's own remotes -> `git-remotes`.
 
 metadata:
+  version: "1.0.0"
   category: git
   source_keys:
     - git-scm-submodule-docs

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

@@ -8,6 +8,7 @@ description: >
   agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
 
 metadata:
+  version: "1.0.0"
   category: git
   source_keys:
     - nvie-gitflow-post

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

@@ -8,6 +8,7 @@ description: >
   Not interactive multi-step git guidance -> `git-workflow`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - git-scm-worktree-docs
@@ -16,7 +17,7 @@ metadata:
 ## Gotchas
 
 - **A branch can be checked out in only one worktree at a time.** `git worktree add` on an already-checked-out branch fails; `--force` is the only override, so use it only deliberately.
-- **Never `rm -rf` a worktree directory.** That strands metadata in `$GIT_DIR/worktrees/`. Use `git worktree remove`, or `git worktree prune` afterwards.
+- **Never `rm -rf` a worktree directory.** That strands metadata in `$GIT_DIR/worktrees/`. Use `rtk git worktree remove`, or `rtk git worktree prune` afterwards.
 - **Submodules break worktree support.** A worktree containing submodules cannot be moved at all, and needs `--force` to remove.
 - **`extensions.worktreeConfig = true` is a one-way door.** Without it, `git config --worktree` errors; with it, that flag writes to the worktree's own `config.worktree` file, and `core.bare`/`core.worktree` are forced there too. It also breaks older Git. Leave it off unless per-worktree config is needed.
 
@@ -24,19 +25,19 @@ metadata:
 
 | Operation | Run |
 |---|---|
-| Create on a branch that already exists locally | `git worktree add <path> <branch>` |
-| Create on a new branch | `git worktree add -b <branch> <path>` |
-| Create on the branch named after the path basename | `git worktree add <path>` — checks that branch out if it exists, else creates it from HEAD |
-| Create and reset an existing branch to HEAD — discards its commits | `git worktree add -B <branch> <path>` |
-| Create a local branch tracking a remote one | `git worktree add --track -b <branch> <path> <remote>/<branch>` — always correct. `git worktree add <path> <branch>` expands to exactly this, but **only** under the conditions in `references/worktrees.md` |
-| Throwaway experiment, no branch | `git worktree add -d <path>` — detached HEAD |
+| Create on a branch that already exists locally | `rtk git worktree add <path> <branch>` |
+| Create on a new branch | `rtk git worktree add -b <branch> <path>` |
+| Create on the branch named after the path basename | `rtk git worktree add <path>` — checks that branch out if it exists, else creates it from HEAD |
+| Create and reset an existing branch to HEAD — discards its commits | `rtk git worktree add -B <branch> <path>` |
+| Create a local branch tracking a remote one | `rtk git worktree add --track -b <branch> <path> <remote>/<branch>` — always correct. `git worktree add <path> <branch>` expands to exactly this, but **only** under the conditions in `references/worktrees.md` |
+| Throwaway experiment, no branch | `rtk git worktree add -d <path>` — detached HEAD |
 | **Never** `git worktree add <path> <remote>/<branch>` | That ref resolves, so the shortcut never fires and you get **a detached HEAD, no branch, no upstream**. Commits there go unreachable once HEAD moves, and `git push` needs an explicit refspec. Use the tracking row above |
-| List | `git worktree list -v`, or `--porcelain -z` to parse |
-| Lock or unlock | `git worktree lock [--reason <str>] <path>` / `git worktree unlock <path>` |
-| Move | `git worktree move <from> <to>` |
-| Remove | `git worktree remove <path>` |
-| Prune stale metadata | `git worktree prune --dry-run`, then without the flag |
-| Repair after a manual move | `git worktree repair` — in the main worktree if *it* moved, or inside a linked worktree that moved. `git worktree repair <path>...` — from any worktree, naming each moved linked worktree's new path |
+| List | `git worktree list -v` to read, or `git worktree list --porcelain -z` to parse — both bare per ADR-0023: rtk re-renders the output and drops the porcelain flags |
+| Lock or unlock | `rtk git worktree lock [--reason <str>] <path>` / `rtk git worktree unlock <path>` |
+| Move | `rtk git worktree move <from> <to>` |
+| Remove | `rtk git worktree remove <path>` |
+| Prune stale metadata | `rtk git worktree prune --dry-run`, then without the flag |
+| Repair after a manual move | `rtk git worktree repair` — in the main worktree if *it* moved, or inside a linked worktree that moved. `rtk git worktree repair <path>...` — from any worktree, naming each moved linked worktree's new path |
 
 If the operation needs anything the table does not carry — the full `add` flag
 table, orphan branches, sparse-checkout, locking for removable media, remote
@@ -48,7 +49,7 @@ Gates:
 
 - **`move`, `remove` — the main worktree cannot be moved or removed.** Only linked worktrees, the ones `git worktree add` created, are candidates.
 - **`add`, `move`, `remove` — escalate force flags one step at a time.** `-f` overrides a safeguard such as an unclean tree; `move` and `remove` need `-ff` on top of that when the worktree is locked. Confirm with the user before either — both discard state.
-- **`add` — lock at creation, not after.** `git worktree add --lock` is atomic, where add-then-`lock` leaves a window in which the worktree is unprotected.
+- **`add` — lock at creation, not after.** `rtk git worktree add --lock` is atomic, where add-then-`lock` leaves a window in which the worktree is unprotected.
 
 ## Step 2 — Report
 
@@ -61,6 +62,7 @@ worktrees:
     lock_reason: <reason or empty>
 ```
 
-Derive those fields from `git worktree list --porcelain -z`. For a single
+Derive those fields from `git worktree list --porcelain -z` — bare, not `rtk`:
+rtk drops both flags and never emits `locked`/`lock_reason` (ADR-0023). For a single
 operation, report its outcome instead — `created: true`, `moved: true`,
 `removed: true`.

plugins/git/.apm/skills/git-worktrees/references/worktrees.md

@@ -23,17 +23,17 @@ that are usable.
 ## `add` forms
 
 ```bash
-git worktree add <path> <branch>              # <branch> exists locally: check it out — non-destructive
-git worktree add -b <branch> <path>           # create a new branch; fails if it exists
-git worktree add <path>                       # branch named after $(basename <path>): checked out
+rtk git worktree add <path> <branch>              # <branch> exists locally: check it out — non-destructive
+rtk git worktree add -b <branch> <path>           # create a new branch; fails if it exists
+rtk git worktree add <path>                       # branch named after $(basename <path>): checked out
                                               # if it exists, else created from HEAD
-git worktree add -B <branch> <path>           # create the branch, or reset an existing one to HEAD,
+rtk git worktree add -B <branch> <path>           # create the branch, or reset an existing one to HEAD,
                                               # discarding the commits it carried
-git worktree add --track -b <branch> <path> <remote>/<branch>
+rtk git worktree add --track -b <branch> <path> <remote>/<branch>
                                               # new local branch tracking the remote — always works
-git worktree add <path> <branch>              # <branch> absent locally and in exactly one remote:
+rtk git worktree add <path> <branch>              # <branch> absent locally and in exactly one remote:
                                               # Git expands this to the --track -b form above
-git worktree add -d <path>                    # detached HEAD, no branch
+rtk git worktree add -d <path>                    # detached HEAD, no branch
 ```
 
 The same `git worktree add <path> <branch>` spelling appears twice above and does two
@@ -65,19 +65,19 @@ Using `-` as `<commit-ish>` is shorthand for `@{-1}` (the branch checked out bef
 ## New unborn branch
 
 ```bash
-git worktree add --orphan -b <branch> <path>
+rtk git worktree add --orphan -b <branch> <path>
 ```
 Creates an empty branch with no commits. **`--orphan` needs Git 2.42 or later** — it was added
 upstream in 2.42, and on 2.39.5 this fails with `error: unknown option 'orphan'` and exit 129.
-Check `git --version` before reaching for it.
+Check `rtk git --version` before reaching for it.
 
 Fallback on older Git, verified on 2.39.5 — detach first, then orphan the linked worktree in place,
 which leaves the main worktree on its own branch throughout:
 
 ```bash
-git worktree add -d <path>       # linked worktree, detached HEAD
+rtk git worktree add -d <path>       # linked worktree, detached HEAD
 cd <path>
-git switch --orphan <branch>     # unborn branch: empty index, empty working tree
+rtk git switch --orphan <branch>     # unborn branch: empty index, empty working tree
 ```
 
 `git worktree list` then shows the new worktree at `0000000 [<branch>]` until its first commit.
@@ -88,25 +88,25 @@ the disruption worktrees exist to avoid.
 
 Suppress the initial checkout to configure sparse-checkout first:
 ```bash
-git worktree add --no-checkout ../sparse main
+rtk git worktree add --no-checkout ../sparse main
 cd ../sparse
-git sparse-checkout init --cone
-git sparse-checkout set src/
-git checkout main
+rtk git sparse-checkout init --cone
+rtk git sparse-checkout set src/
+rtk git checkout main
 ```
 
 ## Worktree on removable media
 
 ```bash
-git worktree add --lock --reason "external SSD" <path> <branch>
-git worktree unlock <path>  # when reconnected
+rtk git worktree add --lock --reason "external SSD" <path> <branch>
+rtk git worktree unlock <path>  # when reconnected
 ```
 
 ## Remote-branch disambiguation
 
 ```bash
-git worktree add --track -b <branch> <path> <remote>/<branch>   # explicit: no guessing at all
-git worktree add <path> <branch>                                # shortcut: needs one clear remote
+rtk git worktree add --track -b <branch> <path> <remote>/<branch>   # explicit: no guessing at all
+rtk git worktree add <path> <branch>                                # shortcut: needs one clear remote
 ```
 **The bare-name shortcut needs exactly one remote.** It fires only when `<branch>` is not found
 locally, none of `-b`/`-B`/`--detach` were given, and a tracking branch of that name exists in
@@ -122,10 +122,10 @@ exactly one remote has it, and marks that branch as upstream. Its default comes
 ## Repair after a manual move
 
 ```bash
-git worktree repair            # the MAIN worktree moved: run it there to reconnect every linked
+rtk git worktree repair            # the MAIN worktree moved: run it there to reconnect every linked
                                # worktree back to the main worktree
-git worktree repair            # a LINKED worktree moved: run it inside that recently-moved worktree
-git worktree repair <path>...  # reconnect a specific linked worktree — runnable from any worktree,
+rtk git worktree repair            # a LINKED worktree moved: run it inside that recently-moved worktree
+rtk git worktree repair <path>...  # reconnect a specific linked worktree — runnable from any worktree,
                                # naming each moved tree's new path
 ```
 
@@ -133,10 +133,10 @@ Which form applies depends on what moved:
 
 | What moved | Remedy |
 |---|---|
-| The main worktree (or bare repo) | `git worktree repair` in the main worktree |
-| One linked worktree | `git worktree repair` inside that worktree |
-| Several linked worktrees | `git worktree repair <path>...` from any worktree, listing each new path |
-| Both main and linked worktrees | `git worktree repair <path>...` in the main worktree, naming each linked worktree's new path — this restores the connections in both directions |
+| The main worktree (or bare repo) | `rtk git worktree repair` in the main worktree |
+| One linked worktree | `rtk git worktree repair` inside that worktree |
+| Several linked worktrees | `rtk git worktree repair <path>...` from any worktree, listing each new path |
+| Both main and linked worktrees | `rtk git worktree repair <path>...` in the main worktree, naming each linked worktree's new path — this restores the connections in both directions |
 
 Only the no-argument form is tied to the current directory. The `<path>...` form is not — it
 reestablishes the connection to every path you name, run from any worktree.
@@ -157,20 +157,20 @@ reestablishes the connection to every path you name, run from any worktree.
 untouched throughout:
 
 ```bash
-git worktree add -b emergency-fix ../temp main
+rtk git worktree add -b emergency-fix ../temp main
 cd ../temp
 # fix, then commit
-git commit -a -m "fix: critical production bug"
+rtk git commit -a -m "fix: critical production bug"
 cd -
-git worktree remove ../temp
+rtk git worktree remove ../temp
 ```
 
 **Review a PR branch alongside your own work** — both branches stay checked out, so there is no
 context switch:
 
 ```bash
-git worktree add ../review-pr-123 origin/feature-xyz          # detached HEAD — read-only review
-git worktree add --track -b feature-xyz ../review-pr-123 origin/feature-xyz   # if you will commit
+rtk git worktree add ../review-pr-123 origin/feature-xyz          # detached HEAD — read-only review
+rtk git worktree add --track -b feature-xyz ../review-pr-123 origin/feature-xyz   # if you will commit
 # open ../review-pr-123 in a second editor window or terminal
 ```
 

plugins/git/.apm/skills/pc-author/SKILL.md

@@ -6,6 +6,7 @@ description: >
   shellcheck"). Not running, installing, or updating hooks -> `pc-run`.
 allowed-tools: Bash Read Write Edit
 metadata:
+  version: "1.0.0"
   category: devtools
   source_keys:
     - context7-pre-commit-com

plugins/git/.apm/skills/pc-author/references/create-config.md

@@ -15,7 +15,7 @@ flow's file is not needed here. `SKILL.md`'s three common gates still apply.
    inferring them from the project's name or README:
 
    ```bash
-   git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
+   rtk git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
    ```
 
 2. Read `references/hooks-by-language.md` and map the detected extensions to recommended hooks.

plugins/git/.apm/skills/pc-author/references/modify-config.md

@@ -17,7 +17,7 @@ Read the existing `.pre-commit-config.yaml` before editing. Note any stale `rev`
 1. Run a shallow extension scan, so the addition is judged against the languages actually present:
 
    ```bash
-   git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
+   rtk git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
    ```
 
 2. Read `references/hooks-by-language.md` for the correct repo URL, `rev` and recommended args

plugins/git/.apm/skills/pc-run/SKILL.md

@@ -8,6 +8,7 @@ description: >
 compatibility: Requires pre-commit installed and available on PATH.
 
 metadata:
+  version: "1.0.1"
   category: devtools
   source_keys:
     - context7-pre-commit-com
@@ -18,9 +19,9 @@ allowed-tools: Bash Read
 
 ## Gotchas
 
-- The `SKIP` env var takes exact hook `id` values, comma-separated with no spaces: `SKIP=check-yaml,gitleaks git commit -m "msg"`. A space after a comma silently skips nothing instead of erroring.
+- The `SKIP` env var takes exact hook `id` values, comma-separated with no spaces: `SKIP=check-yaml,gitleaks rtk git commit -m "msg"`. A space after a comma silently skips nothing instead of erroring.
 - Never bypass a failing hook with `git commit --no-verify` (or `-n`). Hooks are the automated QA gate, so a bypassed commit pushes the failure downstream where it costs more — diagnose it instead.
-- `- files were modified by this hook` is not a bug. A fixer hook rewrote a staged file, so the staged snapshot is stale and the commit is blocked on purpose. Re-stage and re-run the same commit: `git add -u && git commit`. Do NOT reach for `pre-commit install -f` here — it overwrites `.git/hooks/` and has nothing to do with re-staging.
+- `- files were modified by this hook` is not a bug. A fixer hook rewrote a staged file, so the staged snapshot is stale and the commit is blocked on purpose. Re-stage and re-run the same commit: `rtk git add -u && rtk git commit`. Do NOT reach for `pre-commit install -f` here — it overwrites `.git/hooks/` and has nothing to do with re-staging.
 
 ## Gate — `pre-commit clean`
 

plugins/git/.apm/skills/pc-run/references/failure-patterns.md

@@ -14,8 +14,8 @@ Cause: A fixer hook (e.g. `trailing-whitespace`, `end-of-file-fixer`, `pretty-fo
 
 Fix: Re-stage and recommit.
 ```bash
-git add -u
-git commit -m "same message"
+rtk git add -u
+rtk git commit -m "same message"
 ```
 
 Do NOT reach for `pre-commit install -f` here. That flag overwrites existing hook files in `.git/hooks/`; it has nothing to do with re-staging.

plugins/git/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "git",
-  "version": "1.3.6",
+  "version": "1.3.7",
   "description": "Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it.",
   "author": {
     "name": "Defame1297",

plugins/git/.github/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "git",
-  "version": "1.3.6",
+  "version": "1.3.7",
   "description": "Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it.",
   "author": {
     "name": "Defame1297",

plugins/git/README.md

@@ -0,0 +1,48 @@
+# git
+
+Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it.
+
+## Install
+
+**Claude Code:**
+
+```bash
+claude plugin marketplace add <owner>/<repo>
+claude plugin install git@<marketplace-name>
+```
+
+**GitHub Copilot CLI:**
+
+```bash
+copilot plugin marketplace add <owner>/<repo>
+copilot plugin install git
+```
+
+**Local (development):**
+
+```bash
+# Claude Code
+claude --plugin-dir ./plugins/git
+
+# GitHub Copilot CLI
+copilot plugin install ./plugins/git
+```
+
+## Conventions
+
+Skills here run local git commands through the org's `rtk` wrapper. **When a command is prefixed, when it stays bare, and why some executable commands must stay bare are all decided by ADR-0023** (`docs/adr/0023-rtk-prefix-marks-executable-commands-only.md`), which is repo-wide and not specific to this plugin. `check-rtk-prefix` enforces the part of it that is machine-decidable.
+
+Installing this plugin without `rtk`? Every prefixed command is a plain `git` invocation with a word in front of it — drop the `rtk ` and it is correct.
+
+## Contents
+
+| Component | Path | Description |
+|---|---|---|
+| Skills | `.apm/skills/` → `skills/` | `git-commits`, `git-branches`, `git-history`, `git-remotes`, `git-submodules`, `git-workflow`, `git-worktrees`, `pc-author`, `pc-run` |
+| Agents | `.apm/agents/` → `agents/` | `git-orchestrate` |
+
+`.apm/` is the authoring source; `skills/`/`agents/` are the generated mirrors plugin hosts scan (ADR-0017) — edit only under `.apm/`.
+
+## Author
+
+Defame1297

plugins/git/apm.yml

@@ -1,5 +1,5 @@
 name: git
-version: 1.3.6
+version: 1.3.7
 description: Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it.
 author:
   name: Defame1297

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

@@ -9,6 +9,7 @@ description: >
   Not a Gitea remote's branches -> `gitea-branches`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - context7-git-htmldocs
@@ -20,7 +21,7 @@ metadata:
 ## Gotchas
 
 - **Uncommitted changes abort a switch.** `git switch` refuses rather than clobbering conflicting local edits. Offer to stash and retry — forcing the checkout past it is how work disappears.
-- **A branch and a tag can carry the same name.** Detect it before acting — `git branch --list <name>` and `git tag --list <name>`; output from both means the name is ambiguous. Prefer `git switch` over `git checkout`, and where a command accepts either ref, disambiguate with `refs/heads/<name>` or `refs/tags/<name>`.
+- **A branch and a tag can carry the same name.** Detect it before acting — `git branch --list <name>` (bare, not `rtk`: rtk prints a phantom `* ` line even on no match, which reports every name as ambiguous — ADR-0023) and `rtk git tag --list <name>`; output from both means the name is ambiguous. Prefer `git switch` over `git checkout`, and where a command accepts either ref, disambiguate with `refs/heads/<name>` or `refs/tags/<name>`.
 - **`main` and `master` are a refusal, not a gate.** Force-pushing, force-deleting, or renaming them is rejected even when the caller passes `confirm: true` — no flag makes the remote's history recoverable. Offer a new branch instead.
 
 ## Step 1 — Determine the branching pattern
@@ -51,7 +52,7 @@ These gates are passable. The `main`/`master` refusal in Gotchas is not.
 
 ## Step 4 — Set tracking
 
-A new branch's first push must be `git push -u origin <branch>`. The push itself is `git-remotes`' — every remote-side gate lives there, which is why Step 2's remote-delete row hands off the same way — but the upstream requirement originates here, so carry it in the handoff. Without an upstream, later pushes and pulls either fail or silently target the wrong remote branch, and the caller has no way to tell which happened.
+A new branch's first push must be `rtk git push -u origin <branch>`. The push itself is `git-remotes`' — every remote-side gate lives there, which is why Step 2's remote-delete row hands off the same way — but the upstream requirement originates here, so carry it in the handoff. Without an upstream, later pushes and pulls either fail or silently target the wrong remote branch, and the caller has no way to tell which happened.
 
 ## Step 5 — Return a structured result
 

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

@@ -8,21 +8,21 @@ source_keys:
 One command per action. Where two forms exist, the first is the default and the second the escape
 hatch.
 
-- **create** — `git switch -c <branch> <base>`. Base comes from the config's `base_branch`
+- **create** — `rtk git switch -c <branch> <base>`. Base comes from the config's `base_branch`
   (`main` under GitHub Flow, usually `develop` under Gitflow).
-- **switch** — `git switch <branch>` moves to an existing local branch; it aborts rather than
-  clobbering conflicting local changes. `git switch -` returns to the previous branch.
-- **delete (local)** — `git branch -d <branch>` refuses when the branch holds unmerged commits,
-  which is why it is the default. `git branch -D <branch>` forces the deletion and discards that
+- **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,
+  which is why it is the default. `rtk git branch -D <branch>` forces the deletion and discards that
   work — only after the destructive-operation gates pass and `confirm: true` is set.
 - **delete (remote)** — not this skill's. Deleting a remote branch is a push, and every remote-side
   gate lives in `git-remotes`; hand it there rather than running the push from here. Its
   `references/push.md` carries the command and the refspec form.
-- **rename** — `git branch -m <old> <new>`.
-- **list** — `git branch` (local), `-a` (local plus remote-tracking), `-r` (remote-tracking only),
+- **rename** — `rtk git branch -m <old> <new>`.
+- **list** — `rtk git branch` (local), `-a` (local plus remote-tracking), `-r` (remote-tracking only),
   `--merged` / `--no-merged` (filter by merge status into the current branch).
-- **track** — `git branch --set-upstream-to=origin/<branch>` sets an upstream without pushing.
-  `git branch -vv` shows the tracking state of every local branch.
+- **track** — `rtk git branch --set-upstream-to=origin/<branch>` sets an upstream without pushing.
+  `rtk git branch -vv` shows the tracking state of every local branch.
 
 ## get-intent
 
@@ -40,17 +40,20 @@ intent is worse than one built on none.
 A switch aborts rather than clobbering conflicting local changes (see Gotchas). Stash is the way
 past it: it shelves the working tree and index so the branch pointer can move.
 
-- **save** — `git stash push -m "<message>"`. Add `-u` to include untracked files; verified on Git
+- **save** — `rtk git stash push -m "<message>"`. Add `-u` to include untracked files; verified on Git
   2.39.5, a plain `push` leaves them in place, and a plain `push` with *only* untracked changes
   reports `No local changes to save` and stashes nothing. Bare `git stash` is `push` with no message.
-- **restore** — `git stash pop` applies the newest entry and deletes it. `git stash apply stash@{n}`
+- **restore** — `git stash pop` applies the newest entry and deletes it. Bare, not `rtk`: on a
+  conflict rtk prints only `FAILED: git stash pop` and swallows the conflict report the paragraph
+  below tells you to read (ADR-0023). `rtk git stash apply stash@{n}`
   applies without deleting, for replaying one shelf onto more than one branch.
-- **list** — `git stash list`; `git stash show -p stash@{n}` prints that entry's diff.
-- **drop** — `git stash drop stash@{n}` deletes one entry. `git stash clear` deletes all of them
+- **list** — `git stash list` — bare, not `rtk`: rtk prints `No stashes` where git prints nothing,
+  so an empty-output test misfires (ADR-0023). `rtk git stash show -p stash@{n}` prints that entry's diff.
+- **drop** — `rtk git stash drop stash@{n}` deletes one entry. `rtk git stash clear` deletes all of them
   and nothing recovers them — confirm before running it.
-- **branch from a stash** — `git stash branch <branch> stash@{n}` creates a branch at the commit the
+- **branch from a stash** — `rtk git stash branch <branch> stash@{n}` creates a branch at the commit the
   stash was taken from and pops it there. Use it when the stash no longer applies to the current tip.
 
 **A conflicting `pop` keeps the entry.** Verified on 2.39.5: it exits 1, writes conflict markers,
 prints "The stash entry is kept in case you need it again", and `git stash list` still shows it.
-Resolve, `git add`, then `git stash drop` the entry by hand — otherwise it silently accumulates.
+Resolve, `rtk git add`, then `rtk git stash drop` the entry by hand — otherwise it silently accumulates.

plugins/git/skills/git-branches/references/comparing-branches.md

@@ -8,9 +8,9 @@ source_keys:
 The two-dot and three-dot forms mean different things and are easy to swap by accident — check the
 direction before reporting a result.
 
-- `git log main..feature` — commits on `feature` that are not on `main`.
-- `git log feature..main` — the reverse direction: commits on `main` not on `feature`.
-- `git log --left-right main...feature` — both diverging sets at once (symmetric difference).
-- `git diff main...feature` — the diff from the common ancestor to `feature`'s tip, which is what
+- `rtk git log main..feature` — commits on `feature` that are not on `main`.
+- `rtk git log feature..main` — the reverse direction: commits on `main` not on `feature`.
+- `rtk git log --left-right main...feature` — both diverging sets at once (symmetric difference).
+- `rtk git diff main...feature` — the diff from the common ancestor to `feature`'s tip, which is what
   a reviewer sees, rather than the diff between the two tips.
-- `git merge-base main feature` — print the common ancestor commit.
+- `rtk git merge-base main feature` — print the common ancestor commit.

plugins/git/skills/git-branches/references/merging.md

@@ -9,22 +9,23 @@ source_keys:
 Scope is fast-forward and merge-commit mechanics plus conflict resolution. Rebase and cherry-pick
 belong to `git-commits`; revert to `git-history`.
 
-- **Fast-forward** — `git merge <branch>` advances the pointer with no merge commit when the
+- **Fast-forward** — `rtk git merge <branch>` advances the pointer with no merge commit when the
   target has not diverged.
-- **True merge** — `git merge --no-ff <branch>` forces a merge commit even when a fast-forward is
+- **True merge** — `rtk git merge --no-ff <branch>` forces a merge commit even when a fast-forward is
   possible. Gitflow requires it on every supporting-branch merge.
-- **Squash merge** — `git merge --squash <branch>` stages the combined diff without committing.
-  Follow it with a `git commit`.
-- **Octopus merge** — `git merge branch-a branch-b branch-c` merges more than two branches at
+- **Squash merge** — `rtk git merge --squash <branch>` stages the combined diff without committing.
+  Follow it with a `rtk git commit`.
+- **Octopus merge** — `rtk git merge branch-a branch-b branch-c` merges more than two branches at
   once, but fails outright on any conflict. Use sequential two-way merges when conflicts are
   likely.
 
 ## Conflict resolution
 
-When Git cannot auto-merge it writes conflict markers and stops mid-merge. Run `git status` to
-list the conflicted files, edit each to resolve its markers, then `git add <file>` and
-`git merge --continue`.
+When Git cannot auto-merge it writes conflict markers and stops mid-merge. Run `rtk git status` to
+list the conflicted files, edit each to resolve its markers, then `rtk git add <file>` and
+`rtk git merge --continue`.
 
-- `git merge --abort` restores the pre-merge state.
-- `git mergetool` opens the configured merge tool.
-- `git diff --diff-filter=U` shows only the still-conflicted files.
+- `rtk git merge --abort` restores the pre-merge state.
+- `git mergetool` opens the configured merge tool — bare, not `rtk`: it hands control to an
+  interactive child process, and a token filter has nothing to offer there (ADR-0023).
+- `rtk git diff --diff-filter=U` shows only the still-conflicted files.

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

@@ -8,7 +8,7 @@ description: >
   Not branch lifecycle -> `git-branches`.
 
 metadata:
-  version: "0.1.3"
+  version: "0.1.4"
   category: git
   source_keys:
     - conventional-commits-spec
@@ -21,7 +21,7 @@ allowed-tools: Bash
 
 ## Gotchas
 
-- **Run git as `rtk git <subcommand>`, never bare `git`** — org convention, in `&&` chains too.
+- **Run git as `rtk git <subcommand>`, never bare `git`** — org convention, in `&&` chains too. Exceptions: ADR-0023 clause 3.
 - **Refuse to force-push `main`/`master`** — a rewrite leaves the branch diverged and the reflex is to force it back; safe only where nobody else has based work on it.
 - **`reset --hard` is a confirmation gate, not a default.** It overwrites the working tree, and uncommitted edits it discards were never in git, so no reflog recovers them. Name what will be lost and offer a stash first.
 - **Never add `--no-verify`** — using it when a hook fails bypasses the QA gate the pipeline depends on. Only on the user's explicit demand, with a warning.

plugins/git/skills/git-commits/references/rewrite-history.md

@@ -21,9 +21,9 @@ Prefer this whenever a commit is written to be folded, because git does the mark
 
 1. `rtk git commit --fixup=<commit>` keeps the target's message; `rtk git commit --squash=<commit>` lets you edit the combined message later. Both prefix the message with `fixup!`/`squash!` and name the target commit.
 2. Get explicit approval — the rebase still rewrites history.
-3. Run `rtk git rebase -i --autosquash HEAD~N`. Git pre-fills the todo list with the tagged commits already reordered against their targets; save it unchanged to apply.
+3. Run `git rebase -i --autosquash HEAD~N` — bare, not `rtk`: `-i` opens an interactive sequence editor (ADR-0023). Git pre-fills the todo list with the tagged commits already reordered against their targets; save it unchanged to apply.
 
-**`-i` is not optional here.** On Git 2.39.5, `rtk git rebase --autosquash HEAD~N` without `-i` prints `Successfully rebased and updated refs/heads/<branch>.` and exits 0 while leaving the `fixup!` commit in place at its original SHA — `--autosquash` is honoured only by the interactive machinery, and the false success is the trap: the fold is reported as done, and the surviving `fixup!` subject then fails the Conventional Commits `commit-msg` hook. Later Git versions taught the non-interactive rebase to honour the flag, but `-i --autosquash` is correct on every version, so always write that.
+**`-i` is not optional here.** On Git 2.39.5, `git rebase --autosquash HEAD~N` without `-i` prints `Successfully rebased and updated refs/heads/<branch>.` and exits 0 while leaving the `fixup!` commit in place at its original SHA — `--autosquash` is honoured only by the interactive machinery, and the false success is the trap: the fold is reported as done, and the surviving `fixup!` subject then fails the Conventional Commits `commit-msg` hook. Later Git versions taught the non-interactive rebase to honour the flag, but `-i --autosquash` is correct on every version, so always write that.
 
 ## Squash by hand (interactive rebase)
 
@@ -31,7 +31,7 @@ Use this when the commits were not tagged at commit time. **Interactive rebase h
 
 1. Identify the commits to squash — typically the last N on the current branch.
 2. Get explicit approval.
-3. Run `rtk git rebase -i HEAD~N`, marking the older commits `squash` to keep their messages for editing, or `fixup` to discard them.
+3. Run `git rebase -i HEAD~N` — bare, not `rtk`, for the same interactive-editor reason — marking the older commits `squash` to keep their messages for editing, or `fixup` to discard them.
 4. Compose the combined message when the rebase stops to ask. For a non-trivial combined message, follow the structure in `references/commit-template.md`.
 
 ## When a rebase halts on a conflict

plugins/git/skills/git-history/SKILL.md

@@ -8,6 +8,7 @@ description: >
   `git-commits`. Not a Gitea server's history -> `gitea-branches`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - git-scm-bisect-docs
@@ -34,13 +35,13 @@ allowed-tools: Bash
 
 ## Step 2 — Query the log
 
-Default to `git log --oneline`, then narrow by whatever is known:
+Default to `rtk git log --oneline`, then narrow by whatever is known:
 
-- **Content**: `git log -S"string"`, or `-G"regex"` to match any diff line. `--pickaxe-regex` makes the `-S` argument a POSIX ERE; `--pickaxe-all` shows every file in a matching changeset.
-- **A line or function**: `git log -L <start>,<end>:<file>` or `git log -L :<function>:<file>`. Confirm the range resolves before reporting on it — an off-by-one silently omits the target.
-- **A file across renames**: `git log --follow -- <file>`. Without `--follow` the history stops at the rename boundary.
+- **Content**: `rtk git log -S"string"`, or `-G"regex"` to match any diff line. `--pickaxe-regex` makes the `-S` argument a POSIX ERE; `--pickaxe-all` shows every file in a matching changeset.
+- **A line or function**: `git log -L <start>,<end>:<file>` or `git log -L :<function>:<file>` — bare, not `rtk`: rtk truncates each diff line at ~72 characters (ADR-0023). Confirm the range resolves before reporting on it — an off-by-one silently omits the target.
+- **A file across renames**: `rtk git log --follow -- <file>`. Without `--follow` the history stops at the rename boundary.
 - **Mainline only**: `--first-parent` follows the integration branch and skips commits merged in from side branches.
-- **Structured output**: `git log --format="%h | %s | %an (%ar)"`.
+- **Structured output**: `rtk git log --format="%h | %s | %an (%ar)"`.
 
 If you need the placeholder catalogue, format presets, `--diff-filter` letters, full `-L` syntax, ancestry filters, pickaxe binary-file behaviour, or `git diff` output-control flags such as `--stat`, `--word-diff` and the whitespace options, read `references/git-log-format.md`.
 
@@ -49,8 +50,8 @@ If you need the placeholder catalogue, format presets, `--diff-filter` letters,
 Offer the operation and its consequence; run it only once the user has chosen.
 
 - Backporting the commit to another branch is a cherry-pick, and cherry-pick is `git-commits`' — it owns the destination-branch check, the `rtk git` wrapper and the `--abort` path. Hand it the SHA; do not run `git cherry-pick` from here.
-- `git revert <commit>` adds a new commit undoing it — for un-applying merged work without rewriting history.
-- `git blame <file>` attributes each line to the commit that last touched it, when the question is which commit introduced one specific line.
+- `rtk git revert <commit>` adds a new commit undoing it — for un-applying merged work without rewriting history.
+- `rtk git blame <file>` attributes each line to the commit that last touched it, when the question is which commit introduced one specific line.
 
 For diff output control on the located commit, read `references/git-log-format.md`.
 

plugins/git/skills/git-history/references/bisect.md

@@ -12,43 +12,43 @@ or line range to search the log for. Binary search reduces the trials from O(N)
 ## Manual flow
 
 ```bash
-git bisect start
-git bisect bad [HEAD]        # mark current (or specified) as broken
-git bisect good <commit>     # mark known-good baseline
+rtk git bisect start
+rtk git bisect bad [HEAD]        # mark current (or specified) as broken
+rtk git bisect good <commit>     # mark known-good baseline
 # Git checks out the midpoint; test it
-git bisect good              # test passes
-git bisect bad               # test fails
+rtk git bisect good              # test passes
+rtk git bisect bad               # test fails
 # Repeat until git reports "X is the first bad commit"
-git bisect reset             # return to the original HEAD
+rtk git bisect reset             # return to the original HEAD
 ```
 
 ## Automated
 
-With a test command available, use `git bisect run <cmd>`. Git reads the exit code: `0` good,
+With a test command available, use `rtk git bisect run <cmd>`. Git reads the exit code: `0` good,
 `1`–`124` bad, `125` skip (build broken), `126`–`127` POSIX shell errors, treated as bad, and
 `128` or above aborts the session outright rather than marking the commit bad.
 
 ## Untestable commits
 
-`git bisect skip` excludes a commit that cannot be built or tested without deciding good or bad
+`rtk git bisect skip` excludes a commit that cannot be built or tested without deciding good or bad
 for it. When the first bad commit is adjacent to a skipped range, bisect reports that it cannot
 pinpoint the culprit and lists the candidates — that is the precise answer the skip range allows,
 not a failure.
 
 ## Undoing a wrong good/bad call
 
-`git bisect log` prints the session's decision history. Save it, edit out the mistaken entry, and
+`rtk git bisect log` prints the session's decision history. Save it, edit out the mistaken entry, and
 resume from the corrected log rather than restarting the search:
 
 ```bash
-git bisect log > bisect.log
+rtk git bisect log > bisect.log
 # edit bisect.log, removing the wrong decision
-git bisect reset && git bisect replay bisect.log
+rtk git bisect reset && rtk git bisect replay bisect.log
 ```
 
 ## Narrowing and speeding up
 
-- `git bisect start HEAD v1.2 -- src/` restricts bisection to a path, cutting the trial count.
+- `rtk git bisect start HEAD v1.2 -- src/` restricts bisection to a path, cutting the trial count.
 - `--no-checkout` updates the `BISECT_HEAD` ref instead of checking out a working tree — useful
   for tests that do not need one, and automatic in bare repos.
 - `--first-parent` follows only first parents at merges, finding the integration commit that
@@ -56,12 +56,12 @@ git bisect reset && git bisect replay bisect.log
 
 ## Inspecting the remaining candidates
 
-`git bisect visualize` (alias `view`) opens the suspects in gitk, falling back to `git log` when
+`rtk git bisect visualize` (alias `view`) opens the suspects in gitk, falling back to `git log` when
 no graphical display is detected. Add `--stat` or `-p` for a diffstat or full patches.
 
 ## Hunting a non-bug property change
 
-`git bisect start --term-new <new> --term-old <old>` searches for any property change — a
+`rtk git bisect start --term-new <new> --term-old <old>` searches for any property change — a
 performance regression, say — instead of a bug. Use the custom terms in place of `good` and `bad`
 for the rest of the session.
 

plugins/git/skills/git-history/references/git-log-format.md

@@ -116,15 +116,15 @@ source_keys:
 **`-S<string>`** — finds commits where the **count** of `<string>` changed (i.e. the string was added or removed net). Does not match commits where the string merely appears in a diff hunk without a count change.
 
 ```bash
-git log -S"my_function"
-git log -S"my_function" --pickaxe-regex    # treat as POSIX ERE
-git log -S"my_function" --pickaxe-all      # show all files in matching changesets
+rtk git log -S"my_function"
+rtk git log -S"my_function" --pickaxe-regex    # treat as POSIX ERE
+rtk git log -S"my_function" --pickaxe-all      # show all files in matching changesets
 ```
 
 **`-G<regex>`** — finds commits where any added or removed **line** in the patch matches `<regex>`. Broader than `-S`: matches whenever the pattern appears in diff text regardless of count.
 
 ```bash
-git log -G"frotz\(nitfol"
+rtk git log -G"frotz\(nitfol"
 ```
 
 **Critical distinction:** given a diff that removes one occurrence of `foo` and adds one occurrence of `foo` (net change = 0):
@@ -151,8 +151,8 @@ Selects commits (in `git log`) or files (in `git diff`) by change type:
 
 Lowercase letters **exclude** that type:
 ```bash
-git log --diff-filter=ad       # exclude added and deleted files
-git log --diff-filter=M        # only show commits with modified files
+rtk git log --diff-filter=ad       # exclude added and deleted files
+rtk git log --diff-filter=M        # only show commits with modified files
 ```
 
 `C` and `R` only appear when copy/rename detection is enabled (`-C`, `-M` flags or `diff.renames` config).
@@ -161,11 +161,15 @@ git log --diff-filter=M        # only show commits with modified files
 
 Traces the evolution of a specific range of lines or a named function through commits. Implies `--patch`.
 
+Bare `git`, not `rtk git`, on every `-L` form below: rtk truncates each diff body
+line at roughly 72 characters with an ellipsis, on the one query whose whole point
+is showing line content.
+
 ```bash
-git log -L 10,20:file.txt
-git log -L /start_pattern/,/end_pattern/:file.txt
-git log -L :myfunction:src/app.c
-git log -L /init/,+15:config.py          # 15 lines after first match of /init/
+git log -L 10,20:file.txt                          # bare per ADR-0023
+git log -L /start_pattern/,/end_pattern/:file.txt  # bare per ADR-0023
+git log -L :myfunction:src/app.c                   # bare per ADR-0023
+git log -L /init/,+15:config.py                    # bare per ADR-0023; 15 lines after first /init/ match
 ```
 
 Range formats:
@@ -182,12 +186,12 @@ Limitations: incompatible with `--raw`, `--numstat`, `--shortstat`, `--name-only
 ## Graph and Ancestry Filters
 
 ```bash
-git log --first-parent            # at merges, follow only first parent (mainline evolution)
-git log --merges                  # only merge commits (≥2 parents); equivalent to --min-parents=2
-git log --no-merges               # only non-merge commits; equivalent to --max-parents=1
-git log --ancestry-path D..M      # only commits actually on the path from D to M
-git log --min-parents=<n>         # include only commits with ≥ n parents
-git log --max-parents=<n>         # include only commits with ≤ n parents
+rtk git log --first-parent            # at merges, follow only first parent (mainline evolution)
+rtk git log --merges                  # only merge commits (≥2 parents); equivalent to --min-parents=2
+rtk git log --no-merges               # only non-merge commits; equivalent to --max-parents=1
+rtk git log --ancestry-path D..M      # only commits actually on the path from D to M
+rtk git log --min-parents=<n>         # include only commits with ≥ n parents
+rtk git log --max-parents=<n>         # include only commits with ≤ n parents
 ```
 
 `--ancestry-path` is significant: without it, `D..M` includes all commits reachable from M but not D — including side branches that merged into the path. With it, only commits directly between D and M are shown.
@@ -197,28 +201,34 @@ git log --max-parents=<n>         # include only commits with ≤ n parents
 ### --stat
 
 ```bash
-git diff --stat                   # diffstat: file names + ± bar
-git diff --stat=<width>,<name-width>,<count>
-git diff --compact-summary        # alongside --stat: shows new/gone, +x/-x (executable), +l (symlink)
-git diff --numstat                # machine-readable: <added>\t<deleted>\t<path>; - for binary
+rtk git diff --stat                   # diffstat: file names + ± bar
+rtk git diff --stat=<width>,<name-width>,<count>
+rtk git diff --compact-summary        # alongside --stat: shows new/gone, +x/-x (executable), +l (symlink)
+rtk git diff --numstat                # machine-readable: <added>\t<deleted>\t<path>; - for binary
 ```
 
 ### --name-only / --name-status
 
+Bare `git`, not `rtk git`: rtk appends a blank line and a `Changes:` trailer, so
+the output is no longer one record per line.
+
 ```bash
-git diff --name-only              # only filenames, one per line
-git diff --name-status            # status letter + filename per line
+git diff --name-only      # bare per ADR-0023; only filenames, one per line
+git diff --name-status    # bare per ADR-0023; status letter + filename per line
 ```
 
 `--name-status` uses the same status letters as `--diff-filter`.
 
 ### --word-diff
 
+Bare `git`, not `rtk git`: rtk replaces the word-diff with its own diffstat
+renderer and emits none of the `[-removed-] {+added+}` markers.
+
 ```bash
-git diff --word-diff              # inline word-level diff with [-removed-] {+added+} markers
-git diff --word-diff=color        # color only, no markers
-git diff --word-diff=porcelain    # machine-readable: +/- prefixed lines, ~ for newlines
-git diff --word-diff-regex=<re>   # define what counts as a "word"
+git diff --word-diff             # bare per ADR-0023; inline word-level diff, [-removed-] {+added+} markers
+git diff --word-diff=color       # bare per ADR-0023; color only, no markers
+git diff --word-diff=porcelain   # bare per ADR-0023; machine-readable: +/- prefixed lines, ~ for newlines
+git diff --word-diff-regex=<re>  # bare per ADR-0023; define what counts as a "word"
 ```
 
 ### Whitespace Flags

plugins/git/skills/git-remotes/SKILL.md

@@ -10,6 +10,7 @@ description: >
   Not submodule pointers -> `git-submodules`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - git-scm-remote-docs
@@ -27,7 +28,7 @@ metadata:
 
 ## Step 1 — Clear the force-push gate
 
-`main` and `master` are a hard refusal: decline a force-push targeting either, whatever confirmation accompanies it, because no local approval can restore what the remote loses. On any other branch, `git push --force` and `-f` run only after the caller passes `confirm: true` for that specific push — for a human caller, prompt instead of failing.
+`main` and `master` are a hard refusal: decline a force-push targeting either, whatever confirmation accompanies it, because no local approval can restore what the remote loses. On any other branch, `rtk git push --force` and `-f` run only after the caller passes `confirm: true` for that specific push — for a human caller, prompt instead of failing.
 
 ## Step 2 — Dispatch
 

plugins/git/skills/git-remotes/references/fetch.md

@@ -11,19 +11,19 @@ Fetch **with no refspec** updates remote-tracking branches (`refs/remotes/<name>
 
 That safety comes from the default refspec, not from `fetch` itself. Give it an explicit one and it writes to local branches: verified on Git 2.39.5, `git fetch origin main:probe` fast-forwarded the local `probe` branch, and a `+` prefix force-updates the destination, discarding whatever commits it held. Treat any `fetch` carrying a `<src>:<dst>` refspec as a branch update, not a read.
 
-- **One remote**: `git fetch <remote>` — all branches
-- **One branch**: `git fetch <remote> <branch>` — the result lands in `FETCH_HEAD`, not a tracking ref
-- **All remotes**: `git fetch --all`
-- **Prune properly**: `git fetch --all --prune --prune-tags` cleans stale branches *and* tags
-- **Auto-prune**: `git config --global fetch.prune true` (or `remote.<name>.prune` to scope it to one remote), and `fetch.pruneTags true` for tags
+- **One remote**: `rtk git fetch <remote>` — all branches
+- **One branch**: `rtk git fetch <remote> <branch>` — the result lands in `FETCH_HEAD`, not a tracking ref
+- **All remotes**: `rtk git fetch --all`
+- **Prune properly**: `rtk git fetch --all --prune --prune-tags` cleans stale branches *and* tags
+- **Auto-prune**: `rtk git config --global fetch.prune true` (or `remote.<name>.prune` to scope it to one remote), and `fetch.pruneTags true` for tags
 
 ## Shallow and partial fetch
 
 ```bash
-git fetch --depth=<n>             # deepen history, or create a shallow clone
-git fetch --unshallow             # convert a shallow clone to full history
-git fetch --update-shallow        # allow the fetch to update the shallow boundary
-git fetch --refmap='' <remote> <branch>  # fetch without updating any tracking ref (FETCH_HEAD only)
+rtk git fetch --depth=<n>             # deepen history, or create a shallow clone
+rtk git fetch --unshallow             # convert a shallow clone to full history
+rtk git fetch --update-shallow        # allow the fetch to update the shallow boundary
+rtk git fetch --refmap='' <remote> <branch>  # fetch without updating any tracking ref (FETCH_HEAD only)
 ```
 
 ## Default fetch refspec

plugins/git/skills/git-remotes/references/pull.md

@@ -9,11 +9,11 @@ source_keys:
 
 Default strategy: `--ff-only`. It fails on divergence, which forces a conscious choice instead of an accidental merge commit.
 
-- **Fast-forward only**: `git pull --ff-only` — the recommended default
-- **Rebase**: `git pull --rebase` replays your commits on top for linear history, but rewrites SHAs. Verify nothing being replayed has been pushed: rebasing published commits breaks everyone downstream.
-- **Merge**: `git pull --no-rebase` — three-way merge commit, preserves original commits, non-linear
-- **Rebase preserving merges**: `git pull --rebase=merges` keeps intentional local merge commits during the replay
-- **Stage without committing**: `git pull --squash` collapses incoming commits into staged changes; you write the message
+- **Fast-forward only**: `rtk git pull --ff-only` — the recommended default
+- **Rebase**: `rtk git pull --rebase` replays your commits on top for linear history, but rewrites SHAs. Verify nothing being replayed has been pushed: rebasing published commits breaks everyone downstream.
+- **Merge**: `rtk git pull --no-rebase` — three-way merge commit, preserves original commits, non-linear
+- **Rebase preserving merges**: `rtk git pull --rebase=merges` keeps intentional local merge commits during the replay
+- **Stage without committing**: `rtk git pull --squash` collapses incoming commits into staged changes; you write the message
 - **Merge strategy**: Git 2.34+ defaults to `ort` (`recursive` is now an alias for it). Strategy options such as `-X ours`, `-X theirs`, `-X ignore-space-change` pass through unchanged.
 - **Submodules**: `--recurse-submodules` only fetches submodules already checked out. Newly added ones are not initialized — use the `git-submodules` skill for those.
 
@@ -37,7 +37,7 @@ Highest wins:
 4. `branch.autoSetupRebase` (set automatically when the tracking branch was created)
 
 ```bash
-git config pull.ff only                  # deterministic default across Git versions
-git config --global pull.rebase true
-git config branch.develop.rebase false   # develop always merges, regardless of the global default
+rtk git config pull.ff only                  # deterministic default across Git versions
+rtk git config --global pull.rebase true
+rtk git config branch.develop.rebase false   # develop always merges, regardless of the global default
 ```

plugins/git/skills/git-remotes/references/push.md

@@ -9,14 +9,14 @@ source_keys:
 
 Default: safe push to the same-named branch on the remote.
 
-- **Force-push**: never bare `--force`. Use `git push --force-with-lease --force-if-includes <remote> <branch>`, after the SKILL.md Step 1 gate.
-- **Basic**: `git push <remote> <branch>`
-- **Set upstream**: `git push -u <remote> <branch>` — push and configure tracking
-- **Multi-remote**: push sequentially (`git push origin develop`, `git push staging develop`), or add a second push URL with `git remote set-url --add <name> <url>` to reach both in one command
-- **Delete a remote branch**: `git push <remote> --delete <branch>` — clearer than the `:<branch>` form
-- **Bulk**: `git push --all` (all local branches), `git push --tags` (all tags), `git push origin <tag>` (one tag)
-- **Delete remote branches with no local counterpart**: `git push --prune origin 'refs/heads/*:refs/heads/*'`
-- **Force only part of a multi-ref push**: prefix the one refspec that needs it with `+` — `git push origin +release develop` forces `release` while safe-pushing `develop`. A `+` prefix is a force-push and passes the SKILL.md Step 1 gate like any other.
+- **Force-push**: never bare `--force`. Use `rtk git push --force-with-lease --force-if-includes <remote> <branch>`, after the SKILL.md Step 1 gate.
+- **Basic**: `rtk git push <remote> <branch>`
+- **Set upstream**: `rtk git push -u <remote> <branch>` — push and configure tracking
+- **Multi-remote**: push sequentially (`rtk git push origin develop`, `rtk git push staging develop`), or add a second push URL with `rtk git remote set-url --add <name> <url>` to reach both in one command
+- **Delete a remote branch**: `rtk git push <remote> --delete <branch>` — clearer than the `:<branch>` form
+- **Bulk**: `rtk git push --all` (all local branches), `rtk git push --tags` (all tags), `rtk git push origin <tag>` (one tag)
+- **Delete remote branches with no local counterpart**: `rtk git push --prune origin 'refs/heads/*:refs/heads/*'`
+- **Force only part of a multi-ref push**: prefix the one refspec that needs it with `+` — `rtk git push origin +release develop` forces `release` while safe-pushing `develop`. A `+` prefix is a force-push and passes the SKILL.md Step 1 gate like any other.
 
 ## Refspec syntax — `[+]<src>[:<dst>]`
 
@@ -48,19 +48,21 @@ Two mitigations:
 # Option 1 — dedicated push-only remote: background tools fetch `origin`, you push
 # through a separate remote that nothing else touches, so its tracking ref can't be
 # poisoned by an unrelated fetch.
-git remote add origin-push $(git config remote.origin.url)
-git push --force-with-lease origin-push
+# The inner `git config` is bare: its stdout becomes a remote URL, so any
+# output rewriting would poison the remote silently.
+rtk git remote add origin-push $(git config remote.origin.url)   # inner bare per ADR-0023
+rtk git push --force-with-lease origin-push
 
 # Option 2 — explicit SHA via a local tag, unaffected by tracking-branch state
-git fetch
-git tag base master
-git rebase -i master
-git push --force-with-lease=master:base master:master
+rtk git fetch
+rtk git tag base master
+git rebase -i master   # bare, not `rtk` (ADR-0023): interactive sequence editor
+rtk git push --force-with-lease=master:base master:master
 ```
 
 `--force-if-includes` adds a second check on top of bare `--force-with-lease`: it verifies the remote-tracking tip actually appears in your local branch's reflog, i.e. you genuinely integrated it before rewriting. It is a no-op without `--force-with-lease`, and has no effect with the `--force-with-lease=<ref>:<sha>` form, which already pins an exact SHA.
 
-Safest combination: `git push --force-with-lease --force-if-includes origin`.
+Safest combination: `rtk git push --force-with-lease --force-if-includes origin`.
 
 ## Server-side policy
 

plugins/git/skills/git-remotes/references/remote-config.md

@@ -9,31 +9,31 @@ source_keys:
 
 Which remotes exist, where they point, and what they track.
 
-`git remote show <name>` needs network access — use `-n` for cached data offline, or `git remote -v`, which lists URLs without querying.
+`rtk git remote show <name>` needs network access — use `-n` for cached data offline, or `rtk git remote -v`, which lists URLs without querying.
 
 ## Add, remove, rename, inspect
 
-- **Add**: `git remote add <name> <url>`, or `-f` to fetch immediately
-- **Remove**: `git remote remove <name>` — deletes the remote, all its tracking refs, and its config
-- **Rename**: `git remote rename <old> <new>`
-- **Inspect**: `git remote -v` (URLs, offline) or `git remote show <name>` (live tracking status)
-- **Effective URLs**: `git remote get-url <name>` shows the URL after `insteadOf` rewrites; `git remote get-url --push --all <name>` lists every push URL
+- **Add**: `rtk git remote add <name> <url>`, or `-f` to fetch immediately
+- **Remove**: `rtk git remote remove <name>` — deletes the remote, all its tracking refs, and its config
+- **Rename**: `rtk git remote rename <old> <new>`
+- **Inspect**: `rtk git remote -v` (URLs, offline) or `rtk git remote show <name>` (live tracking status)
+- **Effective URLs**: `rtk git remote get-url <name>` shows the URL after `insteadOf` rewrites; `rtk git remote get-url --push --all <name>` lists every push URL
 
 ## Tracking, mirroring, housekeeping
 
-- **Track one branch**: `git remote add -t <branch> <name> <url>` (repeatable); `--no-tags` suppresses tag import entirely
+- **Track one branch**: `rtk git remote add -t <branch> <name> <url>` (repeatable); `--no-tags` suppresses tag import entirely
 - **Mirror**: `--mirror=fetch` mirrors all refs locally (bare repos only); `--mirror=push` makes every push behave like `--mirror`
-- **Prune stale tracking refs without fetching**: `git remote prune <name>`, with `--dry-run` to preview
-- **Default branch pointer**: `git remote set-head <name> -a` (auto-detect, needs a prior fetch), `... <branch>` (explicit), `... -d` (delete `refs/remotes/<name>/HEAD`)
+- **Prune stale tracking refs without fetching**: `rtk git remote prune <name>`, with `--dry-run` to preview
+- **Default branch pointer**: `rtk git remote set-head <name> -a` (auto-detect, needs a prior fetch), `... <branch>` (explicit), `... -d` (delete `refs/remotes/<name>/HEAD`)
 
 ## `set-url` — full form
 
 ```bash
-git remote set-url <name> <newurl>                  # replace the first fetch URL
-git remote set-url <name> <newurl> <oldurl-regex>   # replace only the URL matching regex
-git remote set-url --push <name> <url>              # change push URL only (must point at same repo)
-git remote set-url --add <name> <url>               # add an extra push URL (push to multiple remotes)
-git remote set-url --delete <name> <regex>          # remove URLs matching regex
+rtk git remote set-url <name> <newurl>                  # replace the first fetch URL
+rtk git remote set-url <name> <newurl> <oldurl-regex>   # replace only the URL matching regex
+rtk git remote set-url --push <name> <url>              # change push URL only (must point at same repo)
+rtk git remote set-url --add <name> <url>               # add an extra push URL (push to multiple remotes)
+rtk git remote set-url --delete <name> <regex>          # remove URLs matching regex
 ```
 
 `--push` changes only where pushes go — fetch and push URLs must still reference the same repository. For genuine fetch-from-A / push-to-B workflows, use two separate named remotes instead; `--push` cannot do this.

plugins/git/skills/git-submodules/SKILL.md

@@ -9,6 +9,7 @@ description: >
   Not the superproject's own remotes -> `git-remotes`.
 
 metadata:
+  version: "1.0.0"
   category: git
   source_keys:
     - git-scm-submodule-docs

plugins/git/skills/git-workflow/SKILL.md

@@ -8,6 +8,7 @@ description: >
   agent caller -> `git-orchestrate`. Not Gitea -> `gitea-workflow`.
 
 metadata:
+  version: "1.0.0"
   category: git
   source_keys:
     - nvie-gitflow-post

plugins/git/skills/git-worktrees/SKILL.md

@@ -8,6 +8,7 @@ description: >
   Not interactive multi-step git guidance -> `git-workflow`.
 
 metadata:
+  version: "1.0.1"
   category: git
   source_keys:
     - git-scm-worktree-docs
@@ -16,7 +17,7 @@ metadata:
 ## Gotchas
 
 - **A branch can be checked out in only one worktree at a time.** `git worktree add` on an already-checked-out branch fails; `--force` is the only override, so use it only deliberately.
-- **Never `rm -rf` a worktree directory.** That strands metadata in `$GIT_DIR/worktrees/`. Use `git worktree remove`, or `git worktree prune` afterwards.
+- **Never `rm -rf` a worktree directory.** That strands metadata in `$GIT_DIR/worktrees/`. Use `rtk git worktree remove`, or `rtk git worktree prune` afterwards.
 - **Submodules break worktree support.** A worktree containing submodules cannot be moved at all, and needs `--force` to remove.
 - **`extensions.worktreeConfig = true` is a one-way door.** Without it, `git config --worktree` errors; with it, that flag writes to the worktree's own `config.worktree` file, and `core.bare`/`core.worktree` are forced there too. It also breaks older Git. Leave it off unless per-worktree config is needed.
 
@@ -24,19 +25,19 @@ metadata:
 
 | Operation | Run |
 |---|---|
-| Create on a branch that already exists locally | `git worktree add <path> <branch>` |
-| Create on a new branch | `git worktree add -b <branch> <path>` |
-| Create on the branch named after the path basename | `git worktree add <path>` — checks that branch out if it exists, else creates it from HEAD |
-| Create and reset an existing branch to HEAD — discards its commits | `git worktree add -B <branch> <path>` |
-| Create a local branch tracking a remote one | `git worktree add --track -b <branch> <path> <remote>/<branch>` — always correct. `git worktree add <path> <branch>` expands to exactly this, but **only** under the conditions in `references/worktrees.md` |
-| Throwaway experiment, no branch | `git worktree add -d <path>` — detached HEAD |
+| Create on a branch that already exists locally | `rtk git worktree add <path> <branch>` |
+| Create on a new branch | `rtk git worktree add -b <branch> <path>` |
+| Create on the branch named after the path basename | `rtk git worktree add <path>` — checks that branch out if it exists, else creates it from HEAD |
+| Create and reset an existing branch to HEAD — discards its commits | `rtk git worktree add -B <branch> <path>` |
+| Create a local branch tracking a remote one | `rtk git worktree add --track -b <branch> <path> <remote>/<branch>` — always correct. `git worktree add <path> <branch>` expands to exactly this, but **only** under the conditions in `references/worktrees.md` |
+| Throwaway experiment, no branch | `rtk git worktree add -d <path>` — detached HEAD |
 | **Never** `git worktree add <path> <remote>/<branch>` | That ref resolves, so the shortcut never fires and you get **a detached HEAD, no branch, no upstream**. Commits there go unreachable once HEAD moves, and `git push` needs an explicit refspec. Use the tracking row above |
-| List | `git worktree list -v`, or `--porcelain -z` to parse |
-| Lock or unlock | `git worktree lock [--reason <str>] <path>` / `git worktree unlock <path>` |
-| Move | `git worktree move <from> <to>` |
-| Remove | `git worktree remove <path>` |
-| Prune stale metadata | `git worktree prune --dry-run`, then without the flag |
-| Repair after a manual move | `git worktree repair` — in the main worktree if *it* moved, or inside a linked worktree that moved. `git worktree repair <path>...` — from any worktree, naming each moved linked worktree's new path |
+| List | `git worktree list -v` to read, or `git worktree list --porcelain -z` to parse — both bare per ADR-0023: rtk re-renders the output and drops the porcelain flags |
+| Lock or unlock | `rtk git worktree lock [--reason <str>] <path>` / `rtk git worktree unlock <path>` |
+| Move | `rtk git worktree move <from> <to>` |
+| Remove | `rtk git worktree remove <path>` |
+| Prune stale metadata | `rtk git worktree prune --dry-run`, then without the flag |
+| Repair after a manual move | `rtk git worktree repair` — in the main worktree if *it* moved, or inside a linked worktree that moved. `rtk git worktree repair <path>...` — from any worktree, naming each moved linked worktree's new path |
 
 If the operation needs anything the table does not carry — the full `add` flag
 table, orphan branches, sparse-checkout, locking for removable media, remote
@@ -48,7 +49,7 @@ Gates:
 
 - **`move`, `remove` — the main worktree cannot be moved or removed.** Only linked worktrees, the ones `git worktree add` created, are candidates.
 - **`add`, `move`, `remove` — escalate force flags one step at a time.** `-f` overrides a safeguard such as an unclean tree; `move` and `remove` need `-ff` on top of that when the worktree is locked. Confirm with the user before either — both discard state.
-- **`add` — lock at creation, not after.** `git worktree add --lock` is atomic, where add-then-`lock` leaves a window in which the worktree is unprotected.
+- **`add` — lock at creation, not after.** `rtk git worktree add --lock` is atomic, where add-then-`lock` leaves a window in which the worktree is unprotected.
 
 ## Step 2 — Report
 
@@ -61,6 +62,7 @@ worktrees:
     lock_reason: <reason or empty>
 ```
 
-Derive those fields from `git worktree list --porcelain -z`. For a single
+Derive those fields from `git worktree list --porcelain -z` — bare, not `rtk`:
+rtk drops both flags and never emits `locked`/`lock_reason` (ADR-0023). For a single
 operation, report its outcome instead — `created: true`, `moved: true`,
 `removed: true`.

plugins/git/skills/git-worktrees/references/worktrees.md

@@ -23,17 +23,17 @@ that are usable.
 ## `add` forms
 
 ```bash
-git worktree add <path> <branch>              # <branch> exists locally: check it out — non-destructive
-git worktree add -b <branch> <path>           # create a new branch; fails if it exists
-git worktree add <path>                       # branch named after $(basename <path>): checked out
+rtk git worktree add <path> <branch>              # <branch> exists locally: check it out — non-destructive
+rtk git worktree add -b <branch> <path>           # create a new branch; fails if it exists
+rtk git worktree add <path>                       # branch named after $(basename <path>): checked out
                                               # if it exists, else created from HEAD
-git worktree add -B <branch> <path>           # create the branch, or reset an existing one to HEAD,
+rtk git worktree add -B <branch> <path>           # create the branch, or reset an existing one to HEAD,
                                               # discarding the commits it carried
-git worktree add --track -b <branch> <path> <remote>/<branch>
+rtk git worktree add --track -b <branch> <path> <remote>/<branch>
                                               # new local branch tracking the remote — always works
-git worktree add <path> <branch>              # <branch> absent locally and in exactly one remote:
+rtk git worktree add <path> <branch>              # <branch> absent locally and in exactly one remote:
                                               # Git expands this to the --track -b form above
-git worktree add -d <path>                    # detached HEAD, no branch
+rtk git worktree add -d <path>                    # detached HEAD, no branch
 ```
 
 The same `git worktree add <path> <branch>` spelling appears twice above and does two
@@ -65,19 +65,19 @@ Using `-` as `<commit-ish>` is shorthand for `@{-1}` (the branch checked out bef
 ## New unborn branch
 
 ```bash
-git worktree add --orphan -b <branch> <path>
+rtk git worktree add --orphan -b <branch> <path>
 ```
 Creates an empty branch with no commits. **`--orphan` needs Git 2.42 or later** — it was added
 upstream in 2.42, and on 2.39.5 this fails with `error: unknown option 'orphan'` and exit 129.
-Check `git --version` before reaching for it.
+Check `rtk git --version` before reaching for it.
 
 Fallback on older Git, verified on 2.39.5 — detach first, then orphan the linked worktree in place,
 which leaves the main worktree on its own branch throughout:
 
 ```bash
-git worktree add -d <path>       # linked worktree, detached HEAD
+rtk git worktree add -d <path>       # linked worktree, detached HEAD
 cd <path>
-git switch --orphan <branch>     # unborn branch: empty index, empty working tree
+rtk git switch --orphan <branch>     # unborn branch: empty index, empty working tree
 ```
 
 `git worktree list` then shows the new worktree at `0000000 [<branch>]` until its first commit.
@@ -88,25 +88,25 @@ the disruption worktrees exist to avoid.
 
 Suppress the initial checkout to configure sparse-checkout first:
 ```bash
-git worktree add --no-checkout ../sparse main
+rtk git worktree add --no-checkout ../sparse main
 cd ../sparse
-git sparse-checkout init --cone
-git sparse-checkout set src/
-git checkout main
+rtk git sparse-checkout init --cone
+rtk git sparse-checkout set src/
+rtk git checkout main
 ```
 
 ## Worktree on removable media
 
 ```bash
-git worktree add --lock --reason "external SSD" <path> <branch>
-git worktree unlock <path>  # when reconnected
+rtk git worktree add --lock --reason "external SSD" <path> <branch>
+rtk git worktree unlock <path>  # when reconnected
 ```
 
 ## Remote-branch disambiguation
 
 ```bash
-git worktree add --track -b <branch> <path> <remote>/<branch>   # explicit: no guessing at all
-git worktree add <path> <branch>                                # shortcut: needs one clear remote
+rtk git worktree add --track -b <branch> <path> <remote>/<branch>   # explicit: no guessing at all
+rtk git worktree add <path> <branch>                                # shortcut: needs one clear remote
 ```
 **The bare-name shortcut needs exactly one remote.** It fires only when `<branch>` is not found
 locally, none of `-b`/`-B`/`--detach` were given, and a tracking branch of that name exists in
@@ -122,10 +122,10 @@ exactly one remote has it, and marks that branch as upstream. Its default comes
 ## Repair after a manual move
 
 ```bash
-git worktree repair            # the MAIN worktree moved: run it there to reconnect every linked
+rtk git worktree repair            # the MAIN worktree moved: run it there to reconnect every linked
                                # worktree back to the main worktree
-git worktree repair            # a LINKED worktree moved: run it inside that recently-moved worktree
-git worktree repair <path>...  # reconnect a specific linked worktree — runnable from any worktree,
+rtk git worktree repair            # a LINKED worktree moved: run it inside that recently-moved worktree
+rtk git worktree repair <path>...  # reconnect a specific linked worktree — runnable from any worktree,
                                # naming each moved tree's new path
 ```
 
@@ -133,10 +133,10 @@ Which form applies depends on what moved:
 
 | What moved | Remedy |
 |---|---|
-| The main worktree (or bare repo) | `git worktree repair` in the main worktree |
-| One linked worktree | `git worktree repair` inside that worktree |
-| Several linked worktrees | `git worktree repair <path>...` from any worktree, listing each new path |
-| Both main and linked worktrees | `git worktree repair <path>...` in the main worktree, naming each linked worktree's new path — this restores the connections in both directions |
+| The main worktree (or bare repo) | `rtk git worktree repair` in the main worktree |
+| One linked worktree | `rtk git worktree repair` inside that worktree |
+| Several linked worktrees | `rtk git worktree repair <path>...` from any worktree, listing each new path |
+| Both main and linked worktrees | `rtk git worktree repair <path>...` in the main worktree, naming each linked worktree's new path — this restores the connections in both directions |
 
 Only the no-argument form is tied to the current directory. The `<path>...` form is not — it
 reestablishes the connection to every path you name, run from any worktree.
@@ -157,20 +157,20 @@ reestablishes the connection to every path you name, run from any worktree.
 untouched throughout:
 
 ```bash
-git worktree add -b emergency-fix ../temp main
+rtk git worktree add -b emergency-fix ../temp main
 cd ../temp
 # fix, then commit
-git commit -a -m "fix: critical production bug"
+rtk git commit -a -m "fix: critical production bug"
 cd -
-git worktree remove ../temp
+rtk git worktree remove ../temp
 ```
 
 **Review a PR branch alongside your own work** — both branches stay checked out, so there is no
 context switch:
 
 ```bash
-git worktree add ../review-pr-123 origin/feature-xyz          # detached HEAD — read-only review
-git worktree add --track -b feature-xyz ../review-pr-123 origin/feature-xyz   # if you will commit
+rtk git worktree add ../review-pr-123 origin/feature-xyz          # detached HEAD — read-only review
+rtk git worktree add --track -b feature-xyz ../review-pr-123 origin/feature-xyz   # if you will commit
 # open ../review-pr-123 in a second editor window or terminal
 ```
 

plugins/git/skills/pc-author/SKILL.md

@@ -6,6 +6,7 @@ description: >
   shellcheck"). Not running, installing, or updating hooks -> `pc-run`.
 allowed-tools: Bash Read Write Edit
 metadata:
+  version: "1.0.0"
   category: devtools
   source_keys:
     - context7-pre-commit-com

plugins/git/skills/pc-author/references/create-config.md

@@ -15,7 +15,7 @@ flow's file is not needed here. `SKILL.md`'s three common gates still apply.
    inferring them from the project's name or README:
 
    ```bash
-   git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
+   rtk git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
    ```
 
 2. Read `references/hooks-by-language.md` and map the detected extensions to recommended hooks.

plugins/git/skills/pc-author/references/modify-config.md

@@ -17,7 +17,7 @@ Read the existing `.pre-commit-config.yaml` before editing. Note any stale `rev`
 1. Run a shallow extension scan, so the addition is judged against the languages actually present:
 
    ```bash
-   git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
+   rtk git ls-files | grep -oE '\.[a-z]+$' | sort | uniq -c | sort -rn
    ```
 
 2. Read `references/hooks-by-language.md` for the correct repo URL, `rev` and recommended args

plugins/git/skills/pc-run/SKILL.md

@@ -8,6 +8,7 @@ description: >
 compatibility: Requires pre-commit installed and available on PATH.
 
 metadata:
+  version: "1.0.1"
   category: devtools
   source_keys:
     - context7-pre-commit-com
@@ -18,9 +19,9 @@ allowed-tools: Bash Read
 
 ## Gotchas
 
-- The `SKIP` env var takes exact hook `id` values, comma-separated with no spaces: `SKIP=check-yaml,gitleaks git commit -m "msg"`. A space after a comma silently skips nothing instead of erroring.
+- The `SKIP` env var takes exact hook `id` values, comma-separated with no spaces: `SKIP=check-yaml,gitleaks rtk git commit -m "msg"`. A space after a comma silently skips nothing instead of erroring.
 - Never bypass a failing hook with `git commit --no-verify` (or `-n`). Hooks are the automated QA gate, so a bypassed commit pushes the failure downstream where it costs more — diagnose it instead.
-- `- files were modified by this hook` is not a bug. A fixer hook rewrote a staged file, so the staged snapshot is stale and the commit is blocked on purpose. Re-stage and re-run the same commit: `git add -u && git commit`. Do NOT reach for `pre-commit install -f` here — it overwrites `.git/hooks/` and has nothing to do with re-staging.
+- `- files were modified by this hook` is not a bug. A fixer hook rewrote a staged file, so the staged snapshot is stale and the commit is blocked on purpose. Re-stage and re-run the same commit: `rtk git add -u && rtk git commit`. Do NOT reach for `pre-commit install -f` here — it overwrites `.git/hooks/` and has nothing to do with re-staging.
 
 ## Gate — `pre-commit clean`
 

plugins/git/skills/pc-run/references/failure-patterns.md

@@ -14,8 +14,8 @@ Cause: A fixer hook (e.g. `trailing-whitespace`, `end-of-file-fixer`, `pretty-fo
 
 Fix: Re-stage and recommit.
 ```bash
-git add -u
-git commit -m "same message"
+rtk git add -u
+rtk git commit -m "same message"
 ```
 
 Do NOT reach for `pre-commit install -f` here. That flag overwrites existing hook files in `.git/hooks/`; it has nothing to do with re-staging.

plugins/gitea/.apm/agents/gitea-orchestrate.agent.md

@@ -14,7 +14,7 @@ disallowedTools: Edit, Write, NotebookEdit
 
 You are the orchestrator for the gitea plugin — a composable workflow dispatcher designed for other agents to invoke multi-step Gitea operations reliably. Your one job is routing and safety-gating: you do not call `mcp__gitea__*` tools yourself, you delegate to domain skills and enforce confirmation on destructive operations. You never edit files. Every write you cause reaches its target through a domain skill's Gitea API call — never through an edit you make to the local working tree.
 
-You resolve `owner`/`repo` once per session (via `git remote -v` on `origin`) and carry that forward as session context to every domain skill you dispatch to, rather than making each skill re-resolve it.
+You resolve `owner`/`repo` once per session (via `rtk git remote -v` on `origin`) and carry that forward as session context to every domain skill you dispatch to, rather than making each skill re-resolve it.
 
 **Scope:** this orchestrator routes Gitea-object operations across the six domain skills only: `gitea-issues`, `gitea-labels-milestones`, `gitea-prs`, `gitea-branches`, `gitea-files`, `gitea-releases`. `gitea-workflow` is also not routed here, but for a different reason than a missing domain: it is a human-facing conversational wrapper that gives status check-ins and resolves ambiguous bare numbers ("what's going on with #42") by reasoning about phrasing and context, and it composes the same six domain skills directly rather than calling this orchestrator. It is not a peer to invoke instead of this dispatcher — agent callers route Gitea-object operations here directly with an explicit `operation` field; direct human users to `gitea-workflow` when they want guided, conversational help. Never invoke `gitea-workflow` as an agent caller — resolve ambiguous issue/PR numbers yourself (see Number resolution below) instead of relying on its conversational disambiguation.
 
@@ -30,7 +30,7 @@ These are non-negotiable regardless of `confirm` or any skill-local override:
 - Issues and PRs share one number space. Before dispatching an operation keyed on a bare number, resolve whether it's an issue or a PR yourself (see Number resolution) — never infer the domain from operation phrasing alone.
 - `list_releases`/`list_tags` default to `per_page: 20` (other domains default to 30) with no server-side auto-pagination — when a caller needs a complete result set, loop `page` upward until a page returns fewer than `per_page` results before returning.
 - Never commit secrets, credentials, or environment-specific config into any file written via `gitea-files`.
-- You are read-only against the local working tree. Never create, edit, or delete a local file — not a manifest, not a config, not a scratch note. Local state is the caller's, and you only read it (e.g. `git remote -v`) to resolve context.
+- You are read-only against the local working tree. Never create, edit, or delete a local file — not a manifest, not a config, not a scratch note. Local state is the caller's, and you only read it (e.g. `rtk git remote -v`) to resolve context.
 
 ### Number resolution
 
@@ -68,7 +68,7 @@ When invoked, you:
 1. Validate the request structure and check if `operation` is known
 2. Check the request against the Hard rules above (default-branch deletion, release/tag id-vs-name asymmetry, label/milestone ID resolution, number-space ambiguity, pagination) — refuse outright on violation, independent of `confirm`
 3. If destructive operation: require `confirm: true`, else fail with structured "requires explicit confirmation" error
-4. Resolve `owner`/`repo` via `git remote -v` on `origin` if not already present in `context`, and reuse the resolution for the remainder of the request
+4. Resolve `owner`/`repo` via `rtk git remote -v` on `origin` if not already present in `context`, and reuse the resolution for the remainder of the request
 5. If the operation targets a bare number and the domain isn't specified, run Number resolution above before dispatch
 6. Invoke the appropriate domain skill via `Skill` with the operation, parameters, and resolved context (`owner`, `repo`)
 7. Catch and handle Gitea errors: disambiguate 404s (not-found vs. permission-hidden), retry transient failures, loop pagination for `list_releases`/`list_tags` until exhausted

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

@@ -12,7 +12,7 @@ compatibility: Requires Gitea MCP server configured with a token with write:repo
 
 metadata:
   category: integration
-  version: "0.1.2"
+  version: "0.1.3"
   source_keys:
     - gitea-mcp-repo
     - gitea-mcp-slim-go
@@ -32,7 +32,7 @@ allowed-tools: Bash mcp__gitea__list_branches mcp__gitea__create_branch mcp__git
 Before any tool call, extract `owner` and `repo` from the git remote:
 
 ```bash
-git remote get-url origin
+rtk git remote get-url origin
 ```
 
 `get_me` and `list_my_repos` are blocked under the token scope this skill assumes, so the remote is the only source. 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."

plugins/gitea/.apm/skills/gitea-branches/references/branches.md

@@ -48,7 +48,7 @@ create_branch owner: <owner> repo: <repo> branch: <new-name> old_branch: <source
 
 Default dispatch: if the user gives a base ("branch off of X", "from X"), pass it as `old_branch`.
 If they don't specify a base and you're mid-task on a local branch, pass your current branch
-(`git branch --show-current`) as `old_branch` so the new branch forks from where you're actually
+(`rtk git branch --show-current`) as `old_branch` so the new branch forks from where you're actually
 working, rather than silently falling back to the repo default. If neither applies (e.g. a fresh
 top-level request with no working branch context), omit `old_branch` and let it default server-side.
 

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

@@ -11,6 +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"
   category: gitea
   source_keys:
     - gitea-mcp-repo

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

@@ -14,7 +14,7 @@ compatibility: Requires Gitea MCP server configured with write:issue and write:r
 
 metadata:
   category: integration
-  version: "0.1.3"
+  version: "0.1.4"
   source_keys:
     - gitea-mcp-repo
     - gitea-mcp-slim-go
@@ -36,7 +36,7 @@ allowed-tools: Bash mcp__gitea__list_issues mcp__gitea__issue_read mcp__gitea__i
 An orchestrating caller may pass `owner` and `repo` in already, and the `search` row is cross-repository and needs only a query — both skip this step. Otherwise, before any tool call:
 
 ```bash
-git remote get-url origin
+rtk git remote get-url origin
 ```
 
 If origin is unset or the URL is not a Gitea URL, stop and report: "No Gitea remote found — set origin to your Gitea instance URL."

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

@@ -16,7 +16,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__label_read mcp__gitea__label_write mcp__gitea__milestone_read mcp__gitea__milestone_write
 ---
@@ -32,7 +32,7 @@ allowed-tools: Bash mcp__gitea__label_read mcp__gitea__label_write mcp__gitea__m
 Before any tool call, extract `owner` and `repo` from the git remote (skip this if an orchestrating caller already passed them in):
 
 ```bash
-git remote get-url origin
+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."

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.2"
+  version: "0.1.3"
 
 allowed-tools: Bash mcp__gitea__list_pull_requests mcp__gitea__pull_request_read mcp__gitea__pull_request_write mcp__gitea__pull_request_review_write
 ---
@@ -34,7 +34,7 @@ allowed-tools: Bash mcp__gitea__list_pull_requests mcp__gitea__pull_request_read
 Extract them from the git remote before any tool call, skipping this when an orchestrating caller already passed them in:
 
 ```bash
-git remote get-url origin
+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."

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

@@ -14,7 +14,7 @@ compatibility: Requires Gitea MCP server configured with a token with write:repo
 
 metadata:
   category: integration
-  version: "0.1.0"
+  version: "0.1.1"
   source_keys:
     - gitea-mcp-repo
     - gitea-mcp-slim-go
@@ -36,7 +36,7 @@ allowed-tools: Bash mcp__gitea__list_releases mcp__gitea__get_release mcp__gitea
 `owner` and `repo` are required on every tool below. Extract them from the git remote, unless an orchestrating caller passed them in already:
 
 ```bash
-git remote get-url origin
+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."

plugins/gitea/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gitea",
-  "version": "1.3.7",
+  "version": "1.3.8",
   "description": "Skills and agents for working with a Gitea forge through its HTTP API \u2014 the forge's own objects, as distinct from the local git clone.",
   "author": {
     "name": "Defame1297",

plugins/gitea/.github/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "gitea",
-  "version": "1.3.7",
+  "version": "1.3.8",
   "description": "Skills and agents for working with a Gitea forge through its HTTP API \u2014 the forge's own objects, as distinct from the local git clone.",
   "author": {
     "name": "Defame1297",

plugins/gitea/agents/gitea-orchestrate.agent.md

@@ -14,7 +14,7 @@ disallowedTools: Edit, Write, NotebookEdit
 
 You are the orchestrator for the gitea plugin — a composable workflow dispatcher designed for other agents to invoke multi-step Gitea operations reliably. Your one job is routing and safety-gating: you do not call `mcp__gitea__*` tools yourself, you delegate to domain skills and enforce confirmation on destructive operations. You never edit files. Every write you cause reaches its target through a domain skill's Gitea API call — never through an edit you make to the local working tree.
 
-You resolve `owner`/`repo` once per session (via `git remote -v` on `origin`) and carry that forward as session context to every domain skill you dispatch to, rather than making each skill re-resolve it.
+You resolve `owner`/`repo` once per session (via `rtk git remote -v` on `origin`) and carry that forward as session context to every domain skill you dispatch to, rather than making each skill re-resolve it.
 
 **Scope:** this orchestrator routes Gitea-object operations across the six domain skills only: `gitea-issues`, `gitea-labels-milestones`, `gitea-prs`, `gitea-branches`, `gitea-files`, `gitea-releases`. `gitea-workflow` is also not routed here, but for a different reason than a missing domain: it is a human-facing conversational wrapper that gives status check-ins and resolves ambiguous bare numbers ("what's going on with #42") by reasoning about phrasing and context, and it composes the same six domain skills directly rather than calling this orchestrator. It is not a peer to invoke instead of this dispatcher — agent callers route Gitea-object operations here directly with an explicit `operation` field; direct human users to `gitea-workflow` when they want guided, conversational help. Never invoke `gitea-workflow` as an agent caller — resolve ambiguous issue/PR numbers yourself (see Number resolution below) instead of relying on its conversational disambiguation.
 
@@ -30,7 +30,7 @@ These are non-negotiable regardless of `confirm` or any skill-local override:
 - Issues and PRs share one number space. Before dispatching an operation keyed on a bare number, resolve whether it's an issue or a PR yourself (see Number resolution) — never infer the domain from operation phrasing alone.
 - `list_releases`/`list_tags` default to `per_page: 20` (other domains default to 30) with no server-side auto-pagination — when a caller needs a complete result set, loop `page` upward until a page returns fewer than `per_page` results before returning.
 - Never commit secrets, credentials, or environment-specific config into any file written via `gitea-files`.
-- You are read-only against the local working tree. Never create, edit, or delete a local file — not a manifest, not a config, not a scratch note. Local state is the caller's, and you only read it (e.g. `git remote -v`) to resolve context.
+- You are read-only against the local working tree. Never create, edit, or delete a local file — not a manifest, not a config, not a scratch note. Local state is the caller's, and you only read it (e.g. `rtk git remote -v`) to resolve context.
 
 ### Number resolution
 
@@ -68,7 +68,7 @@ When invoked, you:
 1. Validate the request structure and check if `operation` is known
 2. Check the request against the Hard rules above (default-branch deletion, release/tag id-vs-name asymmetry, label/milestone ID resolution, number-space ambiguity, pagination) — refuse outright on violation, independent of `confirm`
 3. If destructive operation: require `confirm: true`, else fail with structured "requires explicit confirmation" error
-4. Resolve `owner`/`repo` via `git remote -v` on `origin` if not already present in `context`, and reuse the resolution for the remainder of the request
+4. Resolve `owner`/`repo` via `rtk git remote -v` on `origin` if not already present in `context`, and reuse the resolution for the remainder of the request
 5. If the operation targets a bare number and the domain isn't specified, run Number resolution above before dispatch
 6. Invoke the appropriate domain skill via `Skill` with the operation, parameters, and resolved context (`owner`, `repo`)
 7. Catch and handle Gitea errors: disambiguate 404s (not-found vs. permission-hidden), retry transient failures, loop pagination for `list_releases`/`list_tags` until exhausted

plugins/gitea/apm.yml

@@ -1,5 +1,5 @@
 name: gitea
-version: 1.3.7
+version: 1.3.8
 description: Skills and agents for working with a Gitea forge through its HTTP API — the forge's own objects, as distinct from the local git clone.
 author:
   name: Defame1297

plugins/gitea/skills/gitea-branches/SKILL.md

@@ -12,7 +12,7 @@ compatibility: Requires Gitea MCP server configured with a token with write:repo
 
 metadata:
   category: integration
-  version: "0.1.2"
+  version: "0.1.3"
   source_keys:
     - gitea-mcp-repo
     - gitea-mcp-slim-go
@@ -32,7 +32,7 @@ allowed-tools: Bash mcp__gitea__list_branches mcp__gitea__create_branch mcp__git
 Before any tool call, extract `owner` and `repo` from the git remote:
 
 ```bash
-git remote get-url origin
+rtk git remote get-url origin
 ```
 
 `get_me` and `list_my_repos` are blocked under the token scope this skill assumes, so the remote is the only source. 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."

plugins/gitea/skills/gitea-branches/references/branches.md

@@ -48,7 +48,7 @@ create_branch owner: <owner> repo: <repo> branch: <new-name> old_branch: <source
 
 Default dispatch: if the user gives a base ("branch off of X", "from X"), pass it as `old_branch`.
 If they don't specify a base and you're mid-task on a local branch, pass your current branch
-(`git branch --show-current`) as `old_branch` so the new branch forks from where you're actually
+(`rtk git branch --show-current`) as `old_branch` so the new branch forks from where you're actually
 working, rather than silently falling back to the repo default. If neither applies (e.g. a fresh
 top-level request with no working branch context), omit `old_branch` and let it default server-side.