docs: fix two more stale commit hashes in simplification audit

Findings 13 and 21 cited b4c3d5e and 4bbd8a5, both dangling (not
reachable from HEAD) -- an amend after ace2d66 changed the hashes of
the underlying commits to 6cfc357 and f5e4d0d without updating the
self-reference. Corrected both.

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

.claude-plugin/marketplace.json

@@ -1,7 +1,7 @@
 {
   "name": "holocron",
   "description": "AI development skills for Claude Code and GitHub Copilot CLI — factory, design, implement, review, and cross-cutting workflows.",
-  "version": "0.4.5",
+  "version": "0.4.6",
   "owner": {
     "name": "Defame1297",
     "email": "defame1297@rkdr.net",
@@ -11,35 +11,35 @@
     {
       "name": "kyberforge",
       "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
-      "version": "1.6.0",
+      "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.5",
+      "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.5",
+      "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.6",
+      "version": "1.3.8",
       "category": "Version Control",
       "source": "./plugins/gitea"
     },
     {
       "name": "core",
       "description": "Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.",
-      "version": "1.1.1",
+      "version": "1.1.2",
       "category": "Productivity",
       "source": "./plugins/core"
     },
@@ -59,7 +59,7 @@
     {
       "name": "lint",
       "description": "Skills and agents for configuring and running linters.",
-      "version": "1.1.6",
+      "version": "1.1.7",
       "category": "Developer Tools",
       "source": "./plugins/lint"
     }

.github/plugin/marketplace.json

@@ -1,7 +1,7 @@
 {
   "name": "holocron",
   "description": "AI development skills for Claude Code and GitHub Copilot CLI — factory, design, implement, review, and cross-cutting workflows.",
-  "version": "0.4.5",
+  "version": "0.4.6",
   "owner": {
     "name": "Defame1297",
     "email": "defame1297@rkdr.net",
@@ -11,35 +11,35 @@
     {
       "name": "kyberforge",
       "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
-      "version": "1.6.0",
+      "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.5",
+      "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.5",
+      "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.6",
+      "version": "1.3.8",
       "category": "Version Control",
       "source": "./plugins/gitea"
     },
     {
       "name": "core",
       "description": "Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.",
-      "version": "1.1.1",
+      "version": "1.1.2",
       "category": "Productivity",
       "source": "./plugins/core"
     },
@@ -59,7 +59,7 @@
     {
       "name": "lint",
       "description": "Skills and agents for configuring and running linters.",
-      "version": "1.1.6",
+      "version": "1.1.7",
       "category": "Developer Tools",
       "source": "./plugins/lint"
     }

.pre-commit-config.yaml

@@ -75,15 +75,6 @@ repos:
         pass_filenames: false
         always_run: true
 
-      - id: check-manifests
-        name: Check plugin manifests
-        description: Validate marketplace.json and plugin.json paths
-        entry: bash scripts/check-manifests.sh
-        language: system
-        stages: [pre-push]
-        pass_filenames: false
-        always_run: true
-
       - id: check-plugin-content-sync
         name: Check plugin content sync
         description: Verify each plugin's flat skills/agents/commands/hooks/hooks.json mirror is in sync with .apm/ -- Claude Code has no .apm/ awareness so this compiled mirror must stay current (see issue #90)
@@ -113,7 +104,7 @@ repos:
 
       - id: apm-marketplace-check
         name: apm marketplace check
-        description: Validate every marketplace.packages[] entry resolves, including network reachability of remote refs -- catches stale/unreachable remote package references that check-manifests.sh deliberately skips (local-source checks only)
+        description: Validate every marketplace.packages[] entry resolves, including network reachability of remote refs -- the only hook that checks remote package references rather than local-source paths
         entry: apm marketplace check
         language: system
         stages: [pre-push]
@@ -247,25 +238,6 @@ repos:
         pass_filenames: false
         always_run: true
 
-      - id: skill-frontmatter
-        stages: ['pre-commit']
-        name: SKILL.md frontmatter validation
-        description: Ensure SKILL.md files have required frontmatter fields
-        entry: bash
-        language: system
-        files: '^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$'
-        args:
-          - -c
-          - |
-            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:)"
-                  exit 1
-                fi
-              fi
-            done
-
       - id: skill-size-check
         stages: ['pre-commit']
         name: SKILL.md size and context-budget ceilings
@@ -284,6 +256,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)

AGENTS.md

@@ -36,11 +36,7 @@ Fall back to raw shell only when no skill covers it.
 - **Do not add repo-owned keys to `.claude/settings.json`.** apm treats it as its own deployed artifact and `apm audit --ci` replays the install and diffs, so anything apm would not have written is permanent drift that fails the `apm-audit-ci` pre-push hook. A hook you want here is authored in `plugins/<name>/.apm/hooks/` and deployed by apm, never hand-written into that file. The `SessionStart` entry already in it is exactly that: kyberforge authors it in `plugins/kyberforge/.apm/hooks/hooks.json` and apm merges it in, so it is apm's own output, it is what the replay expects, and it belongs in the commit — do not strip it (ADR-0019). Machine-specific settings go in the gitignored `.claude/settings.local.json`; shared enforcement goes in `.pre-commit-config.yaml`.
 - **`apm.lock.yaml` turning up modified is expected, not a bug.** kyberforge's `SessionStart` hook runs `apm outdated` at startup and `apm update --yes` when something is behind, which rewrites the lock. Commit or discard it deliberately.
 - **A `.apm/` edit is not live in this session until it is pushed.** The six dependencies resolve from the holocron remote, unpinned against the default branch. `apm install` deploys from the lock; `apm update` is what re-resolves refs.
-- **The ADR-0020 skill gates ship hot, with no baseline.** 26 of 39 descriptions and 9 of 39 bodies exceed their FAIL tier, and the `Kyberforge.CompositionNote` Vale rule fires 10 errors across `gitea-issues`, `gitea-labels-milestones`, `gitea-prs` and `gitea-workflow`. Editing any of those skills *for any reason* means retrofitting it to the contract first — a one-line fix cannot be committed until the skill complies. Deliberate; tracked as Gitea issue #99. `skill-size-check` will not warn you about the Vale half, so check both: `pre-commit run --all-files`.
-- **Run `bash tests/run-tests.sh --strict` before considering any change done.** Keep the flag: without it a suite whose dependency is missing exits 77 and is counted SKIPPED rather than failed, so the run goes green having verified less than it claims.
-- **Before pushing, rehearse the gate locally:** `pre-commit run --hook-stage pre-push --all-files`. It runs the 14 pre-push hooks this repo authors itself plus pre-commit's 2 `meta` hooks, so it prints 16; `check-release-needed` passes without checking anything, because it needs a real push to `main`. `docs/spec/gates.md` reconciles both.
 - **Pushing without a network** needs `SKIP=apm-marketplace-check,apm-pack-check-clean git push` — those two resolve a remote marketplace entry via `git ls-remote`. Skip only those two; the rest are real local checks, and adding one to `SKIP` disarms it silently.
-- **Author commits with `git-commits`** — it validates Conventional Commits, which `commit-msg` enforces.
 - **This repo and Gitea are the only source of truth.** All project state, decisions, and working conventions live here. Do not use an external memory system for this project — cached state diverges from the repo and you get a split brain. Before answering any design or architecture question, check `docs/adr/` for an existing decision.
 
 ## Key documents

CONTEXT.md

@@ -16,8 +16,12 @@ decisions.
 
 **Preload tax**:
 The always-on context cost of every installed skill's `name` and `description`, charged from the
-first token of every session whether the skill is invoked or not. Measurement method and current
-figure: ADR-0020.
+first token of every session whether the skill is invoked or not. Measurement method: ADR-0020. Its
+**23,427 characters is the pre-retrofit baseline, not a current reading** — measured at the decision
+commit, before #99. Across the same 39 skills it is **10,478 characters** (~2,620 tokens) as of
+2026-09-01. Both figures move with the corpus, so re-derive rather than quote either: sum
+`len(name) + len(description)` over the frontmatter of every `plugins/*/.apm/skills/*/SKILL.md`,
+folding block scalars as `scripts/skill-size-check.sh` does.
 _Avoid_: context cost, token overhead
 
 **Skill context contract**:
@@ -26,6 +30,14 @@ trigger clause, at most one capability clause, and a boundary clause, and nothin
 and the target-resolution walk: `docs/spec/gates.md`.
 _Avoid_: skill budget, size limit
 
+**Routing target**:
+The skill or agent name a boundary clause sends work to. It **resolves** when a skill or agent of
+that name is reachable from the file being checked, and **dangles** when none is — a route the router
+cannot take. Dangling is a blocking ERROR in route notation (`/name`, `→ name`) and a SUGGESTION for
+a bare name nothing else in the sentence corroborates. Verdicts and the resolution walk:
+`docs/spec/gates.md`.
+_Avoid_: route, pointer, cross-reference
+
 **Dispatch body**:
 The body pattern a skill with two or more mutually exclusive flows must use — the body carries only
 the dispatch table and the gates common to every branch, and each flow lives in its own
@@ -35,7 +47,9 @@ _Avoid_: router body, thin body
 **Hand-invoked skill**:
 A skill reached only by typing its slash command, declared `disable-model-invocation: true`. The host
 withholds it from the model-visible listing entirely, so it pays no preload tax and its description
-becomes human-facing text. Exemplar: `zoom-out`.
+becomes human-facing text. The flag also hard-blocks the Skill tool, so **no other skill can route to
+a hand-invoked skill** — a `` Call `x` `` step in another skill's body stops working the moment `x`
+takes the flag. Check inbound routes before declaring one. Exemplar: `zoom-out`.
 _Avoid_: manual skill, disabled skill
 
 **Delegation discipline**:

LESSONS.md

@@ -10,254 +10,122 @@ Patterns observed during development of this repo. Three or more entries on the
 
 ---
 
-## 2026-05-17 — Workflow documents should prescribe sub-agent usage, not just allow it
-
-When writing workflow documents (like `docs/notes/skill-implementation-workflow.md`), the natural tendency is to describe steps at a high level and leave sub-agent usage as an implementation detail. But if the workflow doesn't explicitly prescribe "spawn a sub-agent here," practitioners default to doing everything in the main context — accumulating token cost and losing the isolation benefit. Fix: make sub-agent usage a named step in the workflow, specifying what the agent receives, what it returns, and why it's isolated. This makes the workflow reproducible rather than dependent on the practitioner remembering to use agents.
-
-## 2026-05-17 — Conflict check before synthesis grill, not during
-
-When combining upstream sources into a skill, conflicts with governing documents (AI constitution, factory principles) tend to surface in the middle of the synthesis grill — disrupting the combining discussion and requiring context switches. Fix: run a dedicated conflict-check step before the grill. A sub-agent reads the governing documents, checks the upstream content against them, and returns a numbered list of tensions. The grill then starts with those items as explicit agenda points, making it faster and more systematic. An empty conflict list is also valuable — it confirms the upstreams are clean before co-writing begins.
-
-## 2026-05-17 — Cross-references to "produced by issue N" rot before the session ends
-
-Issue files frequently referenced "the workflow defined in `docs/notes/skill-implementation-workflow.md` (produced by issue 0016)." Within the same session that closes issue 0016, that parenthetical is already stale — the document exists and is the authoritative reference. Fix: reference the document path directly, not the issue that produced it. The git history records the producing issue; cross-references should point to the artifact that persists.
-
-## 2026-05-17 — "Read at session start" is a behavioral hope, not a guarantee
-
-The repo CLAUDE.md instructs agents to read CONTEXT.md at session start, but agents skip this in practice — defaulting to reading only what's directly relevant to the immediate prompt (e.g. the skills folder). The governance.md works because `@import` is technically enforced by Claude Code. Fix: (1) add `@CONTEXT.md` to repo CLAUDE.md using `@import` to make it always-loaded; (2) add a "Key decisions" section to CONTEXT.md with one-line resolved-ADR summaries so locked choices are always in context.
-
-**Status (2026-08-14): neither part landed.** Root `CLAUDE.md` imports `@AGENTS.md` only — no `@CONTEXT.md` — and `CONTEXT.md` has no "Key decisions" section. The behavioral hope this entry diagnosed is still the only mechanism in place: `AGENTS.md` carries the line "Read `CONTEXT.md` at the start of every session," which is loaded but is itself an instruction, not an import. The proposal above is open work, not a record of a completed change.
-
 ## 2026-05-17 — Instruction rules lose to RLHF defaults without specificity
 
-Behavioral tests (2026-05-17) showed three communication/behavior rules failing: exploratory question format (gave verbose multi-bullet answer instead of 2-3 sentences), file edit intent (asked for clarification instead of stating intent and proceeding), and push confirmation (went straight to tool call instead of asking first). All three rules are present in `providers/claude-code/CLAUDE.md` as one-liner statements. The RLHF-trained defaults (thorough answers, risk-averse clarification seeking, fast execution) consistently outcompete thin rules. Fix: rewrite failing rules with specificity, a counter-example, and a boundary statement — not just a single-line imperative.
+Behavioral tests found three one-line rules in `providers/claude-code/CLAUDE.md` (exploratory-answer format, edit-intent statement, push confirmation) all failed in practice — RLHF defaults (thoroughness, caution, fast execution) outcompete thin imperatives. Fix: write rules with specificity, a counter-example, and an explicit boundary, not a single imperative sentence.
 
 ## 2026-05-17 — Secrets rule gap: response text not covered
 
-The secrets prohibition in `core/instructions/governance.md` fired correctly when asked to write a password to a file, but the agent then reproduced the literal credential in its response text (in a shell `export` example). The rule was interpreted as "don't write to files" not "don't output at all." Fix: the rule needs to explicitly state "never produce the credential value in any output" and give an example showing placeholder usage (`export DB_PASSWORD='<your-password>'`).
-
-## 2026-05-17 — Synthesis grill and SKILL.md co-write are two separate conversations
-
-The synthesis grill (step 4) answers schema-level questions: how to combine upstreams, which eval schema to use, merge behaviour. Step 5b is a different conversation: how upstream content maps to each SKILL.md body section, what options each section had, and which was chosen. Collapsing them — writing the SKILL.md immediately after the grill without a per-section walk-through — means the human never sees the upstream options for the body and has no opportunity to redirect before the file is written. Fix: step 5b is now a named gate in the workflow. Walk through every body section one at a time, cite the upstream source, present alternatives, get confirmation. Only then write. Applies to both hand-written (bootstrap) and write-skill-produced skills.
-
-## 2026-05-17 — Skill-calls-skill composition must be a named process step
-
-When a skill invokes another skill as part of its work (e.g. write-skill invoking write-eval to produce the eval), that call must be a numbered step in the Process section — not left as an implicit external workflow step. If it isn't named, practitioners either forget it or do it manually outside the skill, breaking the composition chain. The user caught this during the write-skill co-write; it was absent from the process despite being in the workflow doc. Fix: when designing any skill that composes another, list each composed call explicitly as a numbered step with a "do not mark complete until X exists" constraint.
-
-## 2026-05-17 — AGPL-3.0 repos appear prominently in community skill search results
-
-When searching GitHub for agent skill upstreams, AGPL-3.0 repos (e.g. dceoy/speckit-agent-skills) appear alongside permissive-licensed ones without obvious visual distinction. AGPL imposes copyleft obligations on adopted content. Always run a licence check (GitHub API `/license` endpoint) before extracting any content from a new upstream. An AGPL finding is a hard exclude — record the repo, SHA, and licence in source review notes so future sessions don't re-review it.
-
-## 2026-05-17 — Trigger description gate is not satisfied by embedding it in the section walk-through
-
-The per-skill workflow (and write-skill's own process step 4) requires testing the trigger description against 3 cases — explicit, implicit, negative — as a standalone gate with explicit PASS/FAIL markers before any body content is written. During write-docs (issue 0018 phase 2), the trigger description was included in the section walk-through (step 5b) rather than tested first as a named gate. The gate never had explicit pass/fail output, which means neither the human nor the agent confirmed the trigger was sound before section content was written. Fix: treat the trigger test as a numbered standalone step with per-case PASS/FAIL output before step 5b begins. A section walk-through that happens to include the description field is not a substitute.
-
-## 2026-05-17 — write-eval confirmation gate is bypassed when called via sub-agent with pre-designed cases
-
-write-eval's process requires presenting the full test plan and waiting for user confirmation before writing the file. When write-eval is invoked by passing pre-designed test cases directly to a write sub-agent, this gate is skipped — the file is written before the user sees the plan. This happened during write-docs (issue 0018 phase 2). Fix: when orchestrating write-eval as part of a larger workflow, split into two steps: (1) sub-agent proposes test cases and returns to the main conversation; (2) after user confirmation, sub-agent writes the file. Or: design cases in the main conversation, present them to the user, then spawn the write agent. The plan-then-write separation is the gate — collapsing it into a single sub-agent call silently removes it.
-
-## 2026-05-18 — Skill body sections were cargo-culted, not spec-defined
-
-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.
+The governance.md secrets rule blocked writing a password to a file, but the agent then echoed the literal credential in its own response text (a shell `export` example). The rule read as "don't write files," not "don't output at all." Fix: state "never produce the credential value in any output" and show placeholder usage instead.
 
 ## 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.
+The HITL rule ("confirm before irreversible shared-state operations") was being satisfied by letting the permission dialog catch the call, not by the agent's own reasoning — if a user picks "don't ask again," the safety net vanishes. Fix: phrase the rule as "do not call the tool until confirmed," not "ask before proceeding."
 
 ## 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/`.
+A skill installed only to `~/.agents/skills/` (not the repo's `.agents/skills/`) was invisible to a repo-level overlap scan. Skills added by `install.sh` or prior runs live in the deployed directory, not just the source. Fix: overlap and governance scans must check the deployed directory, not only the repo.
 
-## 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.
+`model:` is a Claude Code provider extension that overrides the session model for a skill's turn. Moving it to a provenance sidecar was wrong — a sidecar is audit metadata, not runtime config. Rule: if a field affects invocation-time behaviour, it belongs in SKILL.md frontmatter, not a sidecar.
 
 ## 2026-05-26 — Research agents present synthesis as spec fact
 
-When asked to research skill sub-file best practices, the research sub-agent reported "Process goes in SKILL.md. Context goes in reference files" as if it were verbatim from the Claude Code docs or the Agent Skills spec. Checking agentskills.io directly showed the spec says: "There are no format restrictions" on the body. The principle is a reasonable synthesis, not a quoted rule — but it nearly landed in write-skill's constraints as authoritative spec language. Fix: always verify research agent claims against the primary source before encoding them as rules, especially for spec or documentation claims. Plausible synthesis is the hardest fabrication to catch because it's often correct in spirit.
+A research sub-agent reported "Process goes in SKILL.md, context in reference files" as if quoted from the agentskills.io spec; the spec actually says there are no body format restrictions. Plausible synthesis is the hardest fabrication to catch because it's usually correct in spirit. Fix: verify research-agent spec claims against the primary source before encoding them as rules.
 
 ## 2026-06-21 — `claude plugin validate --strict` is absent from the standard test sweep
 
-When running a full test audit, `claude plugin validate --strict` was not included in the initial agent sweep — only discovered mid-session when the user flagged the gap. The command catches warnings that normal mode tolerates (missing `version` fields, non-agent `.md` files in `agents/`) and will cause CI to fail when strict mode is enforced in Chunk 6. Fix: include `claude plugin validate --strict` on all plugin paths and marketplace manifests as a named step in any plugin audit. It belongs in the pre-push hook alongside `check-manifests.sh` — currently only `check-manifests.sh` runs there. See `tests/test-plugin-validate.sh` (pending, Gitea issue #2).
+`claude plugin validate --strict` was left out of the standard plugin audit sweep and only discovered when the user flagged the gap. It catches warnings (missing `version` fields, stray non-agent `.md` files) that will fail CI once strict mode is enforced. Fix: run it on every plugin path and marketplace manifest as a named audit step.
 
 ## 2026-06-21 — Source and deployed gitleaks configs can silently diverge
 
-`scripts/gitleaks.toml` (source, in git, deployed to repo root by `setup-gitleaks.sh`) and `.gitleaks.toml` (deployed root copy, read by the hook, also tracked in git) were found with different allowlist states — someone had updated the deployed file directly without updating the source. Running `setup-gitleaks.sh` again would overwrite the deployed file with the stale source, silently deleting the existing allowlist and re-exposing a known false positive as a blocking pre-commit failure. Fix: treat `scripts/gitleaks.toml` as the single source of truth; never edit `.gitleaks.toml` directly. When making allowlist changes, always update source and deployed copy together in the same commit. Longer-term fix: `setup-gitleaks.sh` should merge rather than overwrite, or detect divergence and warn when `.gitleaks.toml` is tracked in git.
+`scripts/gitleaks.toml` (source) and `.gitleaks.toml` (deployed, hook-read) drifted after someone edited the deployed copy directly; rerunning `setup-gitleaks.sh` would have overwritten it, silently deleting the allowlist. Fix: treat the source as sole truth, never hand-edit the deployed copy, and update both together in the same commit.
 
-## 2026-06-21 — `shellcheck` without `-x` blocks pre-commit on any script using `source` (LEGACY SHELL HOOKS)
+## 2026-06-21 — `shellcheck` without `-x` blocks pre-commit on scripts using `source` (historical)
 
-**Status:** Historical. Shell-hook-based pre-commit was replaced by pre-commit framework (Chunk 5, .pre-commit-config.yaml). Modern repos no longer affected. Documented for reference when supporting legacy repos.
-
-The pre-commit hook ran `shellcheck "$f"` without `-x`. Without `-x`, shellcheck fires SC1091 for every `source` statement and exits non-zero, blocking the commit. This was a latent bug in legacy shell hooks, only triggered when `install.sh` (which sources `deploy-manifest.sh`) was staged for the first time. Compounding it: the `# shellcheck source=` directive in `install.sh` pointed to `deploy-manifest.sh` (bare filename, resolved from CWD = repo root) rather than `scripts/deploy-manifest.sh` (correct repo-root-relative path), so even with `-x` the file wasn't found on the first attempt.
-
-**Lesson for future work:** When writing a `source=` directive, use a path that resolves correctly from the CWD where shellcheck will be invoked — verify with `shellcheck -x <file>` before committing. Pre-commit framework hooks include `-x` by default in the ecosystem's shellcheck integration.
+Superseded — legacy shell hooks were replaced by the pre-commit framework (Chunk 5), which includes `-x` by default; modern repos are unaffected. Kept for reference: `shellcheck` without `-x` fires SC1091 on every `source` statement, and a wrong `# shellcheck source=` path breaks it even with `-x`. Verify with `shellcheck -x <file>` when supporting legacy scripts.
 
 ## 2026-06-22 — Plugin cache isolation rules out shared/ directories between skills
 
-When two skills in the same plugin share a resource (e.g. validate.sh), the instinct is to put it in a shared/ directory and reference it with a relative path. This breaks silently after install: plugins are copied to a cache, and `../` paths across skill directories stop resolving. The correct pattern is duplication with clear ownership — one skill owns the canonical copy and the other delegates to it via a skill invocation (e.g. /skill-audit) rather than a file path. If delegation is not possible, duplicate the file and note the owning skill in a comment.
+Skills sharing a resource (e.g. `validate.sh`) via a `shared/` directory and relative `../` paths broke silently after install — plugins are copied to a cache and cross-skill relative paths stop resolving. Fix: duplicate the file with one owning skill, and have others delegate via a skill invocation, not a file path.
 
-## 2026-06-22 — Qualitative rubrics should be grounded in upstream spec docs, not derived from in-repo usage
+## 2026-06-22 — Qualitative rubrics should be grounded in upstream spec docs, not in-repo usage
 
-When skill-audit's qualitative checks for description quality and body discipline were first written, they were derived from skill-write's own authoring conventions — a circular dependency. Any drift in skill-write's conventions would silently propagate into the audit criteria. Fix: extract condensed reference files directly from the upstream spec (agentskills.io) and load them conditionally from the audit skill. The rubric is then grounded in the authoritative source and independent of in-repo convention drift.
+`skill-audit`'s description and body-discipline rubrics were derived from `skill-write`'s own conventions — circular, so drift in one silently propagated to the other. Fix: extract condensed reference files directly from the upstream spec (agentskills.io) into the audit skill, so the rubric is independent of in-repo convention drift.
 
 ## 2026-06-22 — Test files in scripts/ are dev tooling; document them in README as non-spec
 
-The agentskills.io spec defines scripts/ for bundled executable scripts — it says nothing about test infrastructure. Bats test files placed in scripts/ (or scripts/tests/) are invisible to auditors following the spec and create silent README drift if not documented. Fix: place test files directly in scripts/ (no subdirectory), add a row to the README file table for each with a "dev tooling, not shipped with the plugin" note, and don't nest them in a tests/ subdirectory since that creates a non-spec directory structure.
+The agentskills.io spec defines `scripts/` for bundled executables, not test infrastructure — bats files placed there are invisible to spec-following auditors and cause README drift. Fix: place test files directly in `scripts/` (no subdirectory), and add a README row noting each as "dev tooling, not shipped."
 
 ## 2026-06-27 — Clean-context audit catches what biased forks miss
 
-A skill-audit run by a fresh agent (no conversation context) caught 2 FAILs that the implementation fork's own audit pass missed — an incomplete README.md file table and `references/sources.md` paths invalid in the plugin cache. Forks that built the artifact are biased toward their own output: they know what was intended and fill in gaps silently. A fresh agent has no such priors and audits what is actually written. Fix: always run a clean-context audit as a named final step after implementation forks complete. It is not redundant with the in-process audit — it is a different check.
+A fresh-context skill-audit caught two FAILs (an incomplete README table, invalid cache paths) that the implementing fork's own audit missed — the fork that built the artifact knows what was intended and fills gaps silently. Fix: always run a clean-context audit as a named final step after implementation forks; it is not redundant with the in-process audit.
 
 ## 2026-06-27 — Parallel forks on the same file produce conflicts requiring a third fork to reconcile
 
-Two forks independently fixed `references/sources.md` with different approaches — one added a header comment, the other replaced the paths with relative references. Both were plausible; neither read the spec first. Reconciling required a third fork to read the authoritative source and revert to the correct format (repo-root-relative, per skill-author Step 5). Fix: when multiple forks are in scope for the same file, either (a) scope them to non-overlapping files explicitly, or (b) sequence them rather than parallelise. If a fix is spec-governed, always read the spec before applying it — the "obvious" fix is wrong as often as it is right.
+Two forks independently "fixed" `references/sources.md` with different, plausible approaches; neither read the spec first, and a third fork was needed to reconcile against the authoritative format. Fix: scope forks to non-overlapping files or sequence them. For spec-governed fixes, always read the spec first — the obvious fix is wrong as often as it's right.
 
 ## 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.
+Briefing an agent to "write the SKILL.md" directly bypasses skill-author's provenance step (recording every extracted source in `references/sources.md`), caught only by `validate-provenance.sh` after the commit — this recurred twice in one session. Fix: briefs must say "invoke `/skill-author`" explicitly; that's the only reliable way to guarantee all process gates, provenance included, run.
 
 ## 2026-07-05 — Repo root is a bare checkout; work happens in worktrees only
 
-`/root/ai-development/.git` has `core.bare = true` — the root directory itself has no working tree. Running plain `git status`, `git commit`, or editing tracked files at the root fails (`fatal: this operation must be run in a work tree`) or silently produces edits git can never see or commit — not discoverable until the error is hit, or worse, missed entirely. All real work — including one-line docs fixes — requires `git worktree add <path> -b <branch> origin/main` first. Fresh worktrees also don't have submodules (`tests/bats`, `docs/wiki`, etc.) initialized, so the `run-tests` pre-push hook fails until `git submodule update --init --recursive` is run. Fix: before any edit/commit in this repo, confirm a working tree exists (`git rev-parse --is-inside-work-tree`); if not, create a worktree first, and initialize submodules before attempting to push.
+This repo's root `.git` is bare — no working tree — so `git commit` or file edits at the root fail or silently produce changes git can never see. Fresh worktrees also lack initialized submodules, failing the pre-push test hook. Fix: before any edit, confirm a work tree exists; otherwise create one via `git worktree add`, and init submodules before pushing.
 
 ## 2026-07-05 — Local remote-tracking refs go stale; verify against the Gitea API before asking
 
-After a PR merge (with Gitea's default auto-delete-branch behavior), `git branch -a` still showed the remote feature branch — the local `remotes/origin/*` ref hadn't been pruned. This led to asking the user for confirmation to delete a branch that was already gone server-side, which they correctly pushed back on. Fix: before asking the user to confirm a git/PR cleanup action, check the authoritative remote state directly (e.g. `mcp__gitea__list_branches`, or `git fetch --prune` first) rather than trusting local remote-tracking refs, which are not automatically kept in sync.
+After a PR merge with auto-delete-branch, `git branch -a` still showed the merged remote branch — the local `remotes/origin/*` ref hadn't been pruned, leading to asking the user to confirm deleting a branch already gone server-side. Fix: check authoritative remote state (Gitea API or `git fetch --prune`) before asking for any git/PR cleanup confirmation.
 
 ## 2026-05-18 — Planning meta-commentary does not belong in deployed artifacts
 
-During write-skill refactor, an "open thread" note (about a deferred research step) was written directly into the SKILL.md Process section. The user caught it. The rule it violated: a deployed artifact (SKILL.md, a runtime file loaded by agents) must not contain planning meta-commentary — deferred items, open threads, and implementation notes belong in the issue file, which is the planning artifact. The skill body should contain only content relevant to runtime execution. If a decision is deferred, record it in the issue and leave no trace in the skill. The distinction: issue = planning record; skill = executable instruction.
+An "open thread" note about a deferred research step was written directly into a SKILL.md Process section during a refactor. Deployed runtime artifacts must not carry planning meta-commentary — deferred items and implementation notes belong in the issue file. Rule: issue = planning record; skill = executable instruction only.
 
-## 2026-08-08 — A clean linter result can mean "nothing was checked"
+## 2026-08-08 — A clean linter result can mean "nothing was checked" [graduated → core/instructions/testing.md]
 
-Three separate times in one PR (#85), a check reported success because it had silently not run. (1) Vale's `text.frontmatter.description` scope stops matching once the value is a multi-line YAML block scalar — the style most skills here use — so a repo-wide sweep returned 0 alerts across 49 files and was read as a clean repo. (2) Five of six rules were `level: warning`, but Vale's exit code keys on `error` alone and pre-commit hides output from passing hooks, so those rules were invisible and blocked nothing for two review rounds while the ADR described them as "enforcing immediately." (3) `.vale.ini`'s globs matched no file outside `plugins/`, so Vale printed "0 files" and exited 0, which both audit skills read as "no findings" and used to skip their own judgment passes. Each time the green result was worse than no check at all, because it was cited as positive evidence of cleanliness. Fix: for any new check, prove it fails before trusting that it passes — run it against a deliberately-bad fixture, confirm the failure, then run the real corpus. Where a check can scan zero inputs, assert on the input count, not just the exit code. **[graduated → core/instructions/testing.md]** (4th instance below, kept for audit trail).
-
-**5th instance (2026-08-09, PR #85 round 6):** `tests/test-vale-hooks-consumer.sh` asserted `grep -c "VagueWording" >= 2` across the *combined* output of both shipped Vale hooks, and the SKILL.md fixture alone raised two alerts — so one working hook satisfied the threshold and the agent hook could be disabled entirely (glob retargeted to match nothing) while the suite still reported `3 passed` under the message "both hooks flatten and flag". The `Skipped` guard did not catch it: the hook still *matched* the file, Vale simply linted nothing, reported `0 errors in 1 file`, and exited 0, which pre-commit renders as `Passed`. The general shape: **an assertion that aggregates over N subjects proves nothing about any individual subject** — a total is satisfiable by a proper subset. Fix: attribute each signal to its source before asserting (alerts are now filed by path, with a distinct trigger token per fixture so one hook's alert cannot be credited to another), and assert per subject. Corollary technique, now standing practice for any check whose failure mode is silence: run the mutation sweep in *reverse* as well — neuter each assertion in turn and confirm exactly one test case fails. Applied to `check-vale-style-sync.sh` it exposed two assertions bound to no failing case at all, one of them masked by a stronger check that ran first.
-
-**4th instance (2026-08-09, ADR-0014):** splitting the single root `.vale.ini` into two skill-scoped copies (skill-audit: `SKILL.md` only; agent-audit: agent files only) meant a single retargeted pre-commit hook pointed at agent-audit's copy alone would have silently scanned 0 `SKILL.md` files and exited 0 — caught only because the full corpus was dry-run against both the old and new config and the outputs diffed before the old config was deleted, not because any test asserted on file counts. Standing practice going forward: when a Vale (or any linter) config that serves multiple file-glob scopes is split or moved, dry-run the full corpus through both the old and new config and diff the outputs before removing the superseded source — a hook silently scanning 0 files looks identical to a clean pass.
+Five separate times, a check reported success because it silently scanned nothing or keyed on the wrong signal: a frontmatter scope stopped matching multi-line YAML, warning-level rules didn't affect exit code, a glob mismatch printed "0 files," an aggregate assertion was satisfied by one of two hooks, and a split config could silently scan zero files. Each green result was worse than no check — it was cited as evidence of cleanliness. Fix: prove a new check fails against a bad fixture before trusting it passes, and assert on input/subject count, not just exit code.
 
 ## 2026-08-08 — One signal, two consumers, no named distinction
 
-Vale's output fed two consumers with different contracts: the audit skills read severity *strings* to grade a report (`error`→FAIL, `warning`→SUGGESTION), while the pre-commit hook read the process *exit code* to allow or block a commit. Severities were tuned for the first consumer; the second silently inherited whatever exit code that produced, which was always 0. CONTEXT.md described both as a single mechanism under one heading, which is precisely why the divergence went unnoticed — there was no vocabulary in which "the gate" and "the prefilter" were different things that could disagree. Fix: when one output feeds two consumers, name them separately in the domain language and state each contract explicitly. If they cannot be given independent contracts, collapse them into one — which is what happened here: every rule became `level: error`, so the gate and the audit now share a single verdict with nothing to keep in sync.
+Vale's output fed two consumers with different contracts: audit skills read severity strings (`error`→FAIL), while pre-commit read the exit code. Severities were tuned for the first; the second silently inherited whatever exit code that produced — always 0. Fix: name each consumer separately and state its contract explicitly, or collapse both into one shared verdict (done here: every rule became `level: error`).
 
 ## 2026-08-08 — Measure a rule's false-positive rate at the severity you will ship it at
 
-`Kyberforge.VagueQualifier` was cherry-picked from `write-good` after being trialled as "low-noise against this repo's corpus" — but the trial ran at `level: warning`, where a false positive costs nothing because nobody ever sees it. Shipped at `error`, the same false positive costs a blocked commit and a permanent suppression comment. Re-measured at the severity it actually shipped at, the rule scored one marginal true positive and one unfixable false positive across 41 files (`caveman/SKILL.md` *quotes* filler words as its subject matter — a mention, not a use), and was deleted. Fix: trial conditions must match shipping conditions. A noise measurement taken where false positives are free does not transfer to a context where they are expensive, and "low-noise" is not a property of a rule alone — it is a property of the rule at a severity.
+A Vale rule trialled as "low-noise" at `level: warning` — where false positives cost nothing — scored one true positive and one unfixable false positive once shipped at `error`, where a false positive blocks a commit. It was deleted. Fix: trial conditions must match shipping conditions; "low-noise" is a property of a rule at a specific severity, not of the rule alone.
 
 ## 2026-08-09 — Exercising a config's "local" mode proves nothing about the mode that ships
 
-The root `.pre-commit-hooks.yaml` shipped Vale hooks whose `entry:` carried a `--config <repo-relative-path>` argument. pre-commit prefixes only `entry[0]` with the hook-repo clone path (`cmd = (prefix.path(cmd[0]), *cmd[1:])`), so every later argument resolves against the *consuming* repo's root: each external consumer hard-failed with `E100 [--config] Runtime error ... does not exist`, and two of the three hooks ADR-0014 promised were unusable. The defect survived three review rounds of PR #85 and a green `pre-commit run --all-files` every time, because this repo consumes the same hooks through `repo: local`, where the clone prefix, the cwd, and the repo root are one directory — the byte-identical `entry:` string worked locally for a reason that exists only locally. Nothing under `tests/` exercised the manifest as a hook repo at all. The sharp part: the local run was not weaker evidence of the same thing, it was evidence of a different thing, and the two were indistinguishable by reading either file. Fix: when a config has a local mode whose resolution semantics differ from the shipped mode, test the shipped mode against a real consumer — `tests/test-vale-hooks-consumer.sh` stands up a `file://` clone of this repo and runs the hooks from it — and then delete the divergence rather than living with it: `vale-wrap.sh` now self-locates its config from `${BASH_SOURCE[0]}`, and the local and shipped `entry:` lines are identical, so the local run no longer exercises a path no consumer takes.
+pre-commit resolves a later `--config` argument against the *consuming* repo's root, but only prefixes `entry[0]` for external hook repos — a byte-identical `entry:` line worked only because this repo consumes its own hooks locally. Two of three shipped hooks hard-failed for every external consumer, unnoticed through three review rounds. Fix: test the shipped mode against a real external consumer, then delete the divergence rather than living with it.
 
 ## 2026-08-09 — Deleting a token from a shared artifact breaks whatever parses it, silently
 
-Dropping the `--config` argument from `.pre-commit-hooks.yaml` was the right fix, but `scripts/check-release-needed.sh` derived its release-relevant path list by scanning those same `entry:` lines for `--config` and taking the target's `dirname` — that parse was the only thing giving the bundled `.vale.ini` and its sibling `styles/` tree release coverage. With the token gone the loop simply never fired: no error, no failing test, no warning, just a path list that shrank from six entries to four and lost both `assets/vale/` trees. Consequence: a change to a Vale *rule* could land on `main` without demanding a release tag, leaving external consumers pinned to an old `rev:` with stale rules — the exact drift the gate exists to prevent. It surfaced only because the agent making the change reported it as a suspected side effect of its own edit, and was confirmed by diffing the derived path list before and after. Fix: before removing a token from an artifact more than one script reads, grep for everything that *parses* the artifact, not just everything that consumes its documented purpose. The smell to watch for is a loop that builds a list, where an empty or short list is indistinguishable from a correct one — assert on the expected members, so a derivation whose input vanished fails loudly instead of quietly covering less.
+Removing a `--config` argument from `.pre-commit-hooks.yaml` was the right fix, but `check-release-needed.sh` derived its release-relevant path list by parsing that same token — with it gone, the derivation silently shrank with no error. Fix: before removing a token from an artifact more than one script reads, grep for everything that *parses* it, and assert on expected list members.
 
 ## 2026-08-09 — A documented impossibility is a claim, not a constraint
 
-`vale-wrap.sh` flattens multi-line YAML `description:` scalars so Vale's `text.frontmatter.description` scope keeps matching. Its last-resort branch rewrote ASCII `'` to U+2019, justified at the emission site and in review as "the single combination no YAML scalar can carry verbatim" — an accepted-by-design residual, documented and test-covered, which is exactly why nobody retested it. The claim was false: a `|-` literal block with one indented content line carries `'`, `"`, `\` and `: ` verbatim, keeps the scope alive, and the wrapper's own header docstring already said literal blocks were unaffected. The cost of the unexamined claim was a silent underlint on 12 of 54 in-scope files — any rule whose token contained an apostrophe simply never fired, and the covering test (case 20) pinned only "the scope stays alive", so it passed either way. Fix: when a residual is accepted because something is "impossible", write down the specific claim in a falsifiable form and test *that*, not the workaround built on top of it. The tell here was that the residual and its justification were documented in the same breath by the same author — documentation records a belief, and a belief adjacent to a workaround is the one most worth attacking. Related: an assertion written to cover an accepted residual tends to assert the residual's *presence* rather than the behaviour it costs; case 20b asserted the scope survived flattening, never that a rule matching the rewritten characters still fired.
+A wrapper script's last-resort character rewrite was justified as "the one case no YAML scalar can carry verbatim" — untested because it seemed obviously true. It was false: a literal block scalar carries the exact characters in question, silently underlinting 12 of 54 files. Fix: when a residual is accepted as "impossible," write the claim in falsifiable form and test that claim directly, not the workaround built on it.
 
 ## 2026-08-14 — A fix handed down with authority is the least-reviewed code in the change
 
-Across one review round, four fixes specified by the orchestrating reviewer were wrong, and every one would have shipped a guard that looked correct and caught nothing — the same defect class the guard was written to close. `nproc([[:space:]]|$)` does not match `$(nproc)`, the only spelling that occurs in real code. `grep -E ... | grep -Evq ...` under `set -o pipefail` returns 141 because `-q` exits on first match and SIGPIPEs the upstream, and 141 as an `if` condition reads as "no findings" — worse, it is *size-dependent*, so on the real 4-line `.vale.ini` the broken form behaves correctly and only fails once the input grows. `FUNCNAME` and `BASH_ARGC` were proposed as never-empty shell arrays to exempt from an unguarded-expansion scan; both are empty in reachable states (outside a function; `BASH_ARGC` measured 1 at top level and 0 inside a function), so exempting them suppresses a real bash 3.2 abort. `sed 's/#.*//'` as a comment-stripper truncates at the `#` in `${var#prefix}` — a form this repo actually uses at `check-manifests.sh:58` — reintroducing the exact blind spot being fixed. Each was caught only because the implementing agent re-derived the fix and measured, rather than applying what it was told; each had survived being written down confidently in a numbered finding with a reproduction attached. The asymmetry is the point: a finding arrives with evidence and gets scrutinised, while the fix beside it arrives with the same authority and gets implemented. Fix: state a proposed fix as a hypothesis with its own falsifiable check, and require the implementer to verify the fix mechanism independently of the defect reproduction — the two are different claims. The tell is a fix whose correctness depends on a regex boundary, a shell exit-status rule, or an "always/never" property of a builtin: measure it at the size, scope, and spelling it will actually meet, because the small case and the shipped case can disagree.
+Four fixes specified by an orchestrating reviewer were all wrong — a regex that didn't match the real code shape, a pipefail exit code misread as "no findings," two "never-empty" shell arrays that were empty in reachable states, and a comment-stripping `sed` that truncated `${var#prefix}`. Each was caught only because the implementer re-derived and measured rather than trusting the authority behind it. Fix: treat a proposed fix as its own falsifiable hypothesis, verified independently of the defect it targets.
 
 ## 2026-08-14 — Every assertion needs a revert it provably fails against [graduation candidate]
 
-Mutation testing a review round's own fixes found repeatedly that a passing test was pinning nothing. Deleting `sync_dir`'s stale-directory wipe, its check-mode stale branch, or three of five `MIRROR_DIRS` entries each left the suite at 18/18 green; so did replacing the hooks trailing-newline normalisation with plain `cp`. A pair of concurrency assertions written to guard a reentrancy defect caught it 0 times in 10 runs against the deliberately broken script — and one of them was structurally incapable of ever catching it, because the broken code wrote to the system temp dir while the assertion inspected `$TMPDIR`. A fixture-leak fix ran green with and without the fix, verified only by external observation. Two manifest fixtures passed with the canonicalisation they claimed to cover deleted, rescued by an unrelated name-matching axis. In each case the test named the right behaviour in its description and asserted something adjacent to it. The cheap discipline that finds all of these: for every assertion, construct the revert it is supposed to catch and confirm it fails — and when an assertion survives every revert you can think of, that is not reassurance, it is the finding (one test only revealed itself as decoration once a sixth, differently-targeted revert was built for it). Fix: treat "which revert does this fail against?" as a required answer at the time an assertion is written, and record it where the assertion lives, since a test's own description is exactly the artifact that made the gap invisible.
-
-Graduation candidate: this overlaps 2026-08-09's "an assertion written to cover an accepted residual tends to assert the residual's presence rather than the behaviour it costs" and the same date's "assert on the expected members, so a derivation whose input vanished fails loudly instead of quietly covering less." Three entries circling one pattern — human review for promotion to `core/instructions/testing.md`.
+Mutation testing repeatedly found tests passing green with the behaviour they claimed to guard deleted — a stale-directory wipe, a reentrancy guard, a fixture-leak fix, canonicalization logic. Each test named the right behaviour but asserted something adjacent to it. Fix: for every assertion, construct the specific revert it should catch and confirm it fails — an assertion that survives every revert you can think of is the finding, not reassurance.
 
 ## 2026-08-14 — Vale's `existence` extension concatenates `raw:` entries, it does not alternate them
 
-A new `Kyberforge.CompositionNote` rule was first written with seven `raw:` entries, one per banned
-phrasing. Vale loaded it without a diagnostic and it matched **zero of 43 files** — an outcome
-indistinguishable from a clean corpus, and the exact shape of 2026-08-08's "a clean linter result can
-mean nothing was checked". The cause is that `existence` joins multiple `raw:` entries into one
-pattern rather than OR-ing them, so the rule was searching for all seven phrases concatenated. Every
-pre-existing rule in this style has exactly one `raw:` entry, so nothing in the repo demonstrated the
-difference, and the multi-entry form looks natural beside them. `tokens:` is the alternated form,
-which is why `VagueWording` uses it. Fix: a new Vale rule is not landed until it has been shown to
-*fire* — the standing revert-check applies to linter rules as much as to tests, and the revert here
-is the broken multi-`raw:` form, which `tests/test-vale-hooks-consumer.sh` now fails against.
+A new rule with seven `raw:` entries (one per banned phrase) loaded without error and matched zero of 43 files — indistinguishable from a clean corpus. `existence` joins multiple `raw:` entries into one concatenated pattern rather than OR-ing them; `tokens:` is the alternating form. Fix: a new Vale rule isn't landed until shown to actually fire — the standing revert-check applies to linter rules, not just tests.
 
 ## 2026-08-14 — Un-anchoring a description rule to reach mid-sentence text is unshippable
 
-Widening `DescriptionOpener` to catch `gitea-workflow`'s mid-description "This is the human-facing
-entry point…" looked like a one-character change. Both that skill and `gitea-labels-milestones`
-*open* with "Use when…" and satisfy the opener rule; the offending clause sits at character 377 and
-300 of the folded value respectively, so the rule was never violated and never silently passed — it
-simply had no jurisdiction, which is a different defect and takes a different fix.
-Under `scope: text.frontmatter.description`, `^`
-anchors to the start of the whole description value — and `vale-wrap.sh` has already flattened that
-value to one physical line, so `(?m)` changes nothing. Un-anchoring is therefore the only route to
-mid-description text, and measured across the corpus it scores 5 hits and 5 false positives: skills
-legitimately quote user phrasings (`says "audit this skill"`) and write boundary clauses (`do not use
-this skill to manage label definitions`). That is the `Kyberforge.VagueQualifier` deletion repeating.
-Fix: keep the opener rule opener-anchored and give mid-description prose its own rule with its own
-token list. A rule's scope anchor is part of its contract, not an implementation detail to relax when
-a new case does not fit.
+Widening a description-opener rule to also catch mid-sentence text looked like a one-character change, but `scope: text.frontmatter.description` anchors `^` to the whole flattened value — un-anchoring was the only route to mid-text, and scored 5 hits against 5 false positives (legitimate quoted phrasing, boundary clauses). Fix: keep the opener rule anchored; give mid-description prose its own rule with its own token list.
 
 ## 2026-08-14 — A formatter in the commit path manufactures drift on a file with a clean git diff
 
-`apm audit --ci` failed on `.claude/settings.json` while `git diff` on that file was empty — the worst
-possible pairing of signals, because the file matched HEAD exactly and every instinct says "nothing
-changed here". The content was identical to apm's output to the byte; only the JSON key order
-differed. `pretty-format-json --autofix` sorts object keys unless `--no-sort-keys` is passed, and its
-`exclude:` listed fifteen generated manifests but not this file, so from the commit that first wrote
-a hook entry there onward, apm's insertion-ordered output was silently re-sorted on the way in. apm
-then replayed the install, produced its own order, and reported drift against a file no human had
-touched.
-
-The provenance matters as much as the mechanism, and the first account of this entry got it wrong in
-both directions. `git log --format='%h %ad %s' --date=iso` puts the introducing commit `2e395a4` at
-2026-08-14 18:47 and the fix `7607522` at 21:54 — roughly three hours, not "weeks". And `2e395a4` is
-the **first commit of the `refactor/trim-skills-agents-context` branch**, eleven minutes after the
-base merge `f9b919d`; `git branch -a --contains 2e395a4` returns only that branch and its own
-`remotes/origin/` tracking copy — two lines naming one branch, and `main` is not among them. So
-this was not a latent defect inherited from `main`, it was manufactured inside the same PR that
-diagnosed it, and the fixing commit's own message calling it "pre-existing … red at HEAD before
-ADR-0020 work began" is the mis-attribution rather than the record. Two cheap commands would have
-settled it before either sentence was written.
-
-Three general points. First, a tool-owned generated file that passes through an autofixing formatter
-is drifted by construction, and the diff that would reveal it never appears in `git diff` — it only
-exists between the formatter's input and its output, which nothing stores. Second, the fix is
-self-undoing unless the exclude lands in the same commit: correcting the file alone means the hook
-re-breaks it as it is staged. Third — the one this entry had to learn twice — "pre-existing" is a
-claim about history, and history is queryable; a defect found while working on a branch feels
-inherited, and the feeling is not evidence. A three-hour-old self-inflicted bug and a months-old
-inherited one call for different responses, and writing the wrong one down converts a process failure
-into a story about someone else's neglect. Fix: when a tool declares ownership of a path, add that
-path to every autofixing hook's `exclude` at the moment ownership is declared, not when the drift is
-noticed — and before describing any defect as pre-existing, run `git log -S` or
-`git branch --contains` on the commit that introduced it. This repo gates marketplace-mirror,
-plugin-content and vale-style drift deterministically and has no equivalent gate asserting tool-owned
-paths stay out of formatter scope — `.claude/settings.json` was the sixteenth exclude and nothing
-prevents a seventeenth.
+`apm audit --ci` failed on `.claude/settings.json` with an empty `git diff` — `pretty-format-json --autofix` silently re-sorts JSON keys, and this generated file was missing from its exclude list, so every commit re-sorted apm's insertion-ordered output before apm compared against it. Separately, a defect introduced 3 hours earlier on the same branch was first mis-described as "pre-existing," an unverified claim about history. Fix: add tool-owned paths to every autofixing hook's exclude the moment ownership is declared, and verify "pre-existing" claims with `git log -S` or `git branch --contains` before writing them down.
 
 ## 2026-08-16 — A rule reversed inside a retrofit leaves no trace unless someone writes it down
 
-`skill-author/SKILL.md:204` on `main` said "Keep reference chains one level deep — a reference file
-that references another reference file is rarely loaded correctly." The ADR-0020 retrofit replaced it
-with "Two hops from `SKILL.md`, never three" in `references/create.md` and `references/retrofit.md`,
-which permits exactly the chain the old rule banned. The looser rule is the right one and the
-retrofit could not have shipped without it: dispatch pushes each flow into its own file, so the
-shipped structure is `SKILL.md` → `improve.md` → `retrofit.md`, and a one-level ceiling would have
-made the mandatory dispatch pattern illegal. But ADR-0020 says nothing about chain depth, so the
-reversal was carried entirely by the diff — the new text asserts the new rule with no sign that a
-contradicting rule ever existed, and a reader who remembers the old one has no way to tell whether it
-was overturned or overlooked. Fix: when a change inverts a standing authoring rule rather than
-tightening or restating it, record the inversion where the rule's rationale lives — the ADR if the
-ADR is the reason, here otherwise. A rule that quietly flips is indistinguishable from a rule that
-was forgotten, and the second reading is the one that gets it re-added later.
+A retrofit replaced "keep reference chains one level deep" with "two hops, never three" — the opposite rule, needed because the new dispatch pattern requires `SKILL.md` → `improve.md` → `retrofit.md`. The ADR never mentioned chain depth, so the reversal was carried entirely by the diff with no sign a contradicting rule ever existed. Fix: when a change inverts a standing rule, record the inversion where the rule's rationale lives, or it reads as forgotten rather than overturned.

README.md

@@ -31,7 +31,7 @@ Install all of these before setting up. Each one is a hard dependency of a git h
 | Tool | Why | Install |
 | --- | --- | --- |
 | `apm` CLI | Four pre-push hooks shell out to it (`apm-marketplace-check`, `apm-audit-ci`, `apm-pack-check-clean`, and `check-plugin-content-sync` via `scripts/sync-plugin-content.sh`) | The `apm-install` skill, or `curl -sSL https://aka.ms/apm-unix \| sh`. Verify with `apm --version` |
-| `jq` | Required by `scripts/check-manifests.sh` and `scripts/sync-plugin-content.sh`, both pre-push | Your package manager |
+| `jq` | Required by `scripts/sync-plugin-content.sh`, pre-push | Your package manager |
 | `python3` + PyYAML | Required by `scripts/skill-size-check.sh` (the `skill-size-check` pre-commit hook), which reads folded YAML frontmatter | `python3` is usually present — pre-commit is itself a Python application. `pip install pyyaml` if the hook reports PyYAML missing |
 | `vale` | Required by the `vale-audit-prefilter-skill` / `-agent` pre-commit hooks and the `check-vale-style-sync` pre-push hook | `brew install vale` (macOS), `snap install vale` (Linux), `choco install vale` (Windows), or https://vale.sh/docs/vale-cli/installation/ |
 | `claude` CLI | Required by the `validate-plugins` and `validate-marketplace` pre-push hooks | Claude Code |

SIMPLIFICATION-AUDIT.md

@@ -0,0 +1,190 @@
+# Simplification audit
+
+Date: 2026-09-10. Read-only analysis; nothing has been changed. Purpose: a hand-off for deciding what to remove, merge, and shrink. Findings are ranked by payoff within each area; effort is S/M/L. Claims were independently re-verified against the repo by a clean reviewer; corrections have been applied.
+
+Assumptions agreed before analysis: anything is on the table, Claude Code and Copilot CLI both stay supported, findings are ranked with effort.
+
+Counting convention: line counts are hand-edited `.apm/` source unless marked "incl. mirror". Every `.apm/` file has a byte-identical generated copy at the plugin root, so plugin cuts count double in the repo total.
+
+## 1. The shape of the problem
+
+| Measure                                                                   | Value                                                                                   |
+| ---------------------------------------------------------------------------| -----------------------------------------------------------------------------------------|
+| Tracked files / lines                                                     | 820 / 102,000                                                                           |
+| Lines in `plugins/`                                                       | 70,600 (69% of repo)                                                                    |
+| Of which the 39 `SKILL.md` files a model actually loads                   | ~2,600 lines (under 4% of plugin lines)                                                 |
+| Generated flat mirror files (byte copies of `.apm/`)                      | 263 files, ~22,000 lines                                                                |
+| `docs/research/` vendored inside plugins                                  | ~19,000 lines, nothing executable reads it                                              |
+| Repo-level `docs/research/` + `docs/notes/`                               | 4,500 lines, 47% of all prose words, 6 of 11 research files linked only from each other |
+| Enforcement: hook entries in `.pre-commit-config.yaml` / pre-push hooks   | 33 / 14                                                                                 |
+| Enforcement: `tests/*.sh` + runners + `scripts/`                          | 12,400 + 475 + 4,500 lines                                                              |
+| Validator scripts inside kyberforge (+ their bats tests)                  | 6,800 + 5,300 lines                                                                     |
+| Preload tax (39 skill names + descriptions)                               | 10,987 chars, ~2,750 tokens per session                                                 |
+| Commits since 2026-05-10 / share touching hook, test, gate, vale, or sync | 447 / ~25%                                                                              |
+
+The pattern across every area is the same: the payload (skill bodies, rules, decisions) is small and the scaffolding around it (mirrors, research dumps, sync gates, tests of tests, justification prose) is 10 to 30 times larger. A quarter of all commits have gone into maintaining the scaffolding.
+
+## 2. Measured baseline: hooks and tests
+
+Measured on this machine, clean tree, all hooks passing. `pre-commit run --all-files` per stage.
+
+| Gate | Wall time |
+|---|---|
+| **Full pre-push stage (everything below, sequential)** | **~5 min 10 s** |
+| `run-tests` (26 bash suites + 351 bats tests) | 276 s |
+| `apm-audit-ci` (7 manifests) | 12.2 s |
+| `validate-plugins` (6 × `claude plugin validate`) | 4.9 s |
+| `check-plugin-content-sync` | 4.5 s |
+| `apm-pack-check-clean` | 3.1 s |
+| Other 9 pre-push hooks combined | 7.6 s |
+| **Full pre-commit stage, all files** | **18.2 s** |
+
+`run-tests` is 90% of the wall time. Every push pays it in full: the runner has no change detection and the config sets `always_run: true`. `apm-audit-ci` is the second-slowest hook; per its own comment block its earlier description overclaimed, and what it verifies today is that seven manifests parse and the lockfile exists.
+
+Where the 276 s goes (each suite run alone, sequential):
+
+| Suite | Time | Note |
+|---|---|---|
+| `test-sync-plugin-content.sh` | 83 s | 14 temp trees, 2 `git init`, repeated `apm pack` |
+| all 351 bats tests (10 files, kyberforge and core validators) | 64 s | mostly `validate.sh` / `validate-provenance.sh` fixtures |
+| `test-adr0020-differential.sh` | 29 s | 12 assertions; re-runs two validators over the live corpus and a fixture tree |
+| `test-check-vale-style-sync.sh` | 25 s | guards a byte-identical copy |
+| `test-vale-wrap.sh` | 14 s | |
+| `test-adr0020-frontmatter.sh` + `-targets.sh` | 25 s | |
+| Remaining 20 suites | 36 s | 12 of them run in under 2 s each |
+
+Five suites account for 215 s of 276 s. Three of those five (sync-plugin-content, vale-style-sync, adr0020-differential) test tooling that findings 2, 7, and 14 propose to delete or shrink, so the fastest path to a quick pre-push is removing the duplication those tests guard rather than optimising the tests.
+
+## 3. Enforcement layer: hooks, tests, scripts
+
+This is the area you named as hardest to understand and slowest. Root cause: most pre-push hooks exist to keep two copies of something in sync, or to re-validate what another hook already validates.
+
+1. **Six hooks validate overlapping sets of the same manifests.** `check-manifests`, `validate-plugins`, `validate-marketplace`, `apm-pack-check-clean`, `apm-marketplace-check`, `apm-audit-ci`. Keep the two `claude plugin validate` hooks plus `apm-pack-check-clean`. ~~Delete `check-manifests` (282 lines + 771 test lines; its `lib/marketplace-plugins.sh` stays because `sync-plugin-content.sh` sources it).~~ `apm-audit-ci` spends 12 s confirming that manifests `apm pack` already parses do parse; drop or keep on that basis. Move the network-dependent `apm-marketplace-check` to a release checklist. Effort S.
+   > **Done (2026-09-12):** see commit `e647f14` on `docs/simplification-audit`. Deleted the `check-manifests` pre-commit hook entry, `scripts/check-manifests.sh` (282 lines), and `tests/test-check-manifests.sh` (771 lines); kept `scripts/lib/marketplace-plugins.sh`, still sourced by `sync-plugin-content.sh`. Updated the now-stale `check-manifests.sh` mentions in `README.md` and `docs/spec/gates.md` (hook table row and hook counts). The `apm-audit-ci` and `apm-marketplace-check` decisions in this finding remain open — out of scope for this change.
+
+2. **Four "keep two copies in sync" gates: 1,100 script lines + 1,600 test lines.** Each one is a symptom of duplication that could be removed instead of guarded:
+   - `check-vale-style-sync`: 413 lines + 798 test lines guarding a byte-identical 526-line `vale-wrap.sh` and style directory copied between skill-audit and agent-audit. About 350 of its lines run Vale glob probes against the hook file patterns. Disappears if the two audit skills merge (finding 14); the probes belong in `test-vale-wrap.sh`.
+   - `check-scope-walkup-sync`: 365 lines cross-checking four independent ports of the same package-root walk-up. Disappears if the ports share one script or the skills merge.
+   - `check-marketplace-mirror-sync`: guards `.github/plugin/marketplace.json`. The script header calls it Copilot's legacy convention path and says Copilot also accepts the Claude path; the vendored Copilot docs list it as primary. Verify against current Copilot CLI before deleting hook, script, test, and mirror file.
+   - `check-executables-allow-sync`: 474 lines to assert one string equals kyberforge's version. A six-line grep, or drop it (the failure mode is visible and recoverable).
+   Effort S each, M for the walk-up.
+
+3. **Tests of the test harness: 1,090 lines testing 475 lines.** `test-run-tests.sh` and `test-run-bats.sh` defend "green either way" holes that exist only because the runners hand-roll TAP parsing and set-equality checks. Replace both runners with about 40 lines (`bats -r plugins` plus a parallel `find | xargs` over `test-*.sh`) and delete the meta-tests. `lib/batch-run.sh` stays; `sync-plugin-content.sh` sources it. Effort M.
+
+4. [x] ~~**`skill-frontmatter` is a 62-line bash script inlined in YAML** with its own 366-line test. `skill-size-check.sh` already parses the same frontmatter with PyYAML. Fold it in (about 15 Python lines), delete the inline hook, its test, and the 79 lines in `gates.md` arguing for the split. Effort S.~~
+   > **Done (2026-09-12):** see commit `c8a7c9e` on `docs/simplification-audit`. Added a ~20-line required-frontmatter check (`name`, `description`, `metadata.version` as three-part semver) to `scripts/skill-size-check.sh`, reusing the YAML mapping `description_value()` already parses. Removed the inline `skill-frontmatter` hook (~80 lines) from `.pre-commit-config.yaml` and deleted `tests/test-skill-frontmatter.sh` (366 lines). Removed the 79-line "the other hook on that scope" discussion from `docs/spec/gates.md` and its now-dangling cross-reference, replacing both with a one-line note of the fold; updated the pre-push hook counts there. Updated fixture builders in `tests/test-skill-size-check.sh`, `tests/test-adr0020-body-checks.sh`, `tests/test-adr0020-targets.sh`, `tests/test-adr0020-differential.sh`, and `tests/test-vale-hooks-consumer.sh` to carry valid `metadata.version` so the new check doesn't spuriously fail existing fixtures.
+
+5. **`skill-size-check.sh` has six test files totalling 3,589 lines for one 1,497-line script**, split by ADR section rather than behaviour. `test-adr0020-differential.sh` is 452 lines for 12 assertions. Merge to two files. Effort M.
+
+6. [x] ~~**Prose-grep tests.** `test-governance-layer.sh` and `test-instructions-and-docs.sh` (583 lines) grep markdown for phrases, including a one-shot "issue 0015 refactor incomplete" assertion made permanent and an assertion that `docs/notes/` exists. Delete both.~~ `check-apm-agents-valid.sh` (161 + 264 test lines) is a loop plus fail-closed guards around `validate.sh`; it folds into the merged audit skill's own tests (finding 14). Effort S.
+   > **Done (2026-09-12):** see commit `5f9f2b3` on `docs/simplification-audit`. Deleted `tests/test-governance-layer.sh` (270 lines) and `tests/test-instructions-and-docs.sh` (313 lines); no other file referenced either. `check-apm-agents-valid.sh` was left untouched — its fate is tied to the separate, out-of-scope skill-merge finding 14.
+
+7. **`check-plugin-content-sync.sh` is 813 lines wrapping `apm pack`, with a 1,291-line test.** The mirror itself must stay (Claude Code marketplace installs need flat directories), and the script does real work a bare `git diff` would lose: it strips `tests/` from the mirror, regenerates both `plugin.json` files with `mcpServers` reinjected, and packs into a scratch copy so `--check` never mutates. Even so, 2,100 lines for that is disproportionate; target a third. Effort M.
+
+8. **`docs/spec/gates.md` (1,048 lines) is roughly 15% "what is enforced" and 85% post-mortems** of defects already fixed and pinned by tests. The 60-line hook table is the useful part. Target 200 lines. The same applies to the 106 comment lines in `.pre-commit-config.yaml` and to `scripts/`, where 8 of 15 files are 40 to 60% comments. Effort M.
+
+**Proposed target.** Pre-push 14 hooks to 6: `run-tests`, `validate-plugins`, `validate-marketplace`, `apm-pack-check-clean`, `check-plugin-content-sync`, `check-release-needed`. Pre-commit stays roughly as is minus `skill-frontmatter`, and minus `check-ast` once finding 9 removes the only `.py` files. Tests 26 files to about 10 (12,400 to about 5,000 lines). Keep bats and its three submodules; the 351 bats tests ship inside plugins and are the right tool there. Do not port the bash suites to bats; delete them instead.
+
+## 4. Plugins
+
+The shared pattern: per-skill `README.md` files no model reads, a `docs/research/` dump per plugin, a `sources.md` provenance chain with its own validator, and reference files that restate man pages.
+
+### 4.1 Cross-plugin (apply everywhere)
+
+9. [ ] **Delete `docs/research/` from every plugin (~19,000 lines).** kyberforge's alone is 14,143 lines, 32% of the plugin, and about 8,900 of those are vendored third-party content (Anthropic `skill-creator` including a 1,325-line `viewer.html` and ten `.py` files, obra/superpowers, mattpocock). The rest is copied tool documentation. The gitea references explicitly say the research doc "has a known history of drifting from the deployed server". Every `apm.yml` uses `includes: auto`; whether the directory ships to consumers needs one check. Keep upstream URLs in one line per plugin README; git history keeps the rest. Check obra/superpowers licence if anything is retained. Goes together with finding 11: 32 `sources.md` files carry "Research doc" paths into these directories. Effort S.
+   > **Decision (2026-09-12):** Keep. `docs/research/` is retained on purpose — it's read by agents doing work sourced from those docs. Not proceeding.
+
+10. [x] ~~**Delete per-skill `README.md` and `references/README.md` (48 files, 1,574 lines).** They restate the SKILL.md in narrative form. The pre-commit config itself notes a skill README "is consumer-facing prose that no agent ever loads". Keep one plugin-level README with one line per skill. Requires dropping the README criterion in `skill-audit/references/file-structure.md` and the README step in `new-skill.sh`. Effort S.~~
+   > **Done (2026-09-12):** see commit `edcc57c` on `docs/simplification-audit`. Deleted the 48 per-skill/reference READMEs plus 2 scaffold templates; dropped the README criterion from `skill-audit`'s `file-structure.md` and `finding-criteria.md` and the README-generation step from `new-skill.sh`; updated `new-skill.bats` to match. Plugin-root READMEs were kept, not part of this finding.
+
+11. **Drop the provenance chain: `sources.md`, `source_keys` frontmatter, `validate-provenance.sh`.** 32 plugin and skill `sources.md` files (about 1,300 lines) plus 9 research indexes, 216 source files with `source_keys`, two copies of the validator (1,198 and 632 lines) with ten checks, and 125 bats tests exist to track which upstream informed which file. Git blame and a URL in the README do the same job. This is more code than the content it tracks. Effort M (touches skill-audit, both validator copies, two repo tests, and every skill's frontmatter).
+
+12. [x] ~~**Strip ADR and changelog narration from model-facing files.** `ADR-0020` is cited in 3 of 7 kyberforge SKILL.md files and 16 references; ADR-0023 is cited inline 21 times in the git plugin. Examples: "was the old house rule and ADR-0020 deleted it", "were removed per ADR-0015 once issue #90 landed", "this file previously recorded `list_issues` as having neither a `type` nor a `milestones` parameter". `skill-author/references/retrofit.md` (197 lines) is a one-time migration guide; it is loaded from `improve.md` and listed in `sources.md`, so remove those in the same change. These belong in git history or the ADR, not in context. Effort S.~~
+   > **Done (2026-09-12):** see commit `edcc57c` on `docs/simplification-audit`. Historical narration stripped from kyberforge (ADR-0020) and git (ADR-0023) skill content; `retrofit.md` deleted along with its load-step and `sources.md` entries. Caught in review: some `ADR-0023` tags were not narration but the `check-rtk-prefix` hook's required opt-out marker for intentionally-bare git commands — those 12 were restored, not left stripped.
+
+13. [x] ~~**State repeated boilerplate once or delete it.** A near-identical "Resolve owner and repo" block in 5 of 7 gitea skills; 404-masks-403 in 6 files; manual pagination in 7; main/master refusal in 9 git files; the "use the project's domain glossary, respect ADRs" paragraph in 5 bin skills. Three git skills define three different structured-result JSON shapes whose only consumer is `git-orchestrate` (finding 19). Effort S.~~
+    > **Done (2026-09-12):** see commit `6cfc357`. Trimmed each repeated instance in place — same meaning, fewer words — rather than extracting to a shared file (blocked by the one-file-per-skill install constraint, ADR-0014): the "Resolve owner and repo" block across 5 `gitea-*` skills, the 404-masks-403 note across 6 gitea files, the manual-pagination explanation across 8 gitea files, the main/master force-push refusal across 7 git plugin files (some with multiple internal restatements), and the domain-glossary/ADR paragraph across 5 `bin` skills. This was a trim-in-place pass, not a merge: the cross-skill duplication itself remains and is coupled to the (out-of-scope) skill-merge findings 19/20. Left the three git skills' structured-result JSON shapes untouched, as directed. Verified no regressions with `scripts/skill-size-check.sh` (pre/post diff) and `claude plugin validate` on both plugins.
+
+### 4.2 kyberforge (290 files, 44,568 lines incl. mirror; the 7 SKILL.md bodies are 333 lines, under 1%)
+
+14. **Merge `skill-audit` + `agent-audit` into one `audit` skill (removes about 3,300 lines and two pre-push hooks).** `vale-wrap.sh` is byte-identical in both; five Vale rules byte-identical (agent-audit carries one extra, so it is the superset); `validate.sh` shares a 1,061-line boundary-target resolver block that diffs as zero lines; SKILL.md steps 1, 3, 4 and the gotchas are the same text. Each copy is hard-wired to one mode, so the merged script needs a path switch. The duplication exists because a plugin-cache install copies only each skill's own files (the rule ADR-0014 follows), so a script cannot be shared across skills; merging the skills is the only way to remove the copy. Effort M.
+
+15. **Merge `skill-author` + `agent-author` likewise.** `contract.md` shares most of its Description section; `new-skill.sh` and `new-agent.sh` implement the same package-root walk-up with different mode names; step 1 dispatch tables and step 3 gates are near-identical. Keep the agent scope logic (plugin vs project/user) as its own reference. Effort M.
+
+16. **Cut the validators by an order of magnitude.** `validate.sh` is 1,677 lines of bash with embedded Python, ported twice; `skill-size-check.sh` is 1,497. Target about 200 lines total: frontmatter present, size ceilings, boundary targets resolve. The 526-line `vale-wrap.sh` exists to work around folded `>` scalars in descriptions; writing descriptions as `|` literal blocks removes the folding problem, but the wrapper is also the exported hook entry in `.pre-commit-hooks.yaml` and carries the NOT RUN guard the audits depend on, so it shrinks rather than disappears. This is where the real complexity lives and is the item most worth discussing. Effort L.
+
+17. **Fold `forge` and `apm-install`.** `forge` is a four-row routing table plus 207 lines of references explaining fork vs inline; it should be 25 lines with no references. `apm-install` (53 lines + 17-line sources) becomes a sixth dispatch row in `apm-workflow`. Effort S.
+
+18. **Delete prose the model already knows.** "Valid characters: lowercase letters, numbers, hyphens"; what pipx does and PEP 668; "code blocks carry a language tag"; "data to stdout, diagnostics to stderr". Ironically `body-discipline.md` instructs auditors not to include "concepts the agent already knows". Effort S.
+
+### 4.3 git and gitea (153 + 93 files, 9,889 + 6,047 lines incl. mirror; source 3,288 + 2,286)
+
+19. **Delete the two router skills and two orchestrate agents (309 lines + 195 reference lines).** No skill invokes them as a step; they appear only in boundary clauses (`AGENTS.md`, `git-worktrees`, `gitea-issues`, `gitea-prs`) and as worked examples in agent-audit references, all of which must change in the same commit or `skill-size-check` fails on the dangling target. Claude Code already routes on descriptions. The chain today is `git-workflow` step 5 invokes `git-orchestrate`, whose step 5 invokes `git-commits`, which runs `rtk git commit`: three hops. Both agents exceed 900 words; ADR-0020 deliberately sets no agent body gate. Effort S.
+
+20. **Collapse git 7 skills to 1; gitea 7 to 2.** Git references are man-page restatement: `git-log-format.md` (242 lines listing `%H`, `%ar`), `conventional-commits-spec.md` (170 lines), `worktrees.md` (178), `merging.md` explaining fast-forward. Roughly 60% of the plugin is generic. The genuinely house-specific content fits in about 150 lines: the `rtk` rule and ADR-0023 exceptions, main/master refusal, `--no-verify`, the `-i --autosquash` 2.39.5 trap, `--force-with-lease --force-if-includes`, bisect exit codes, submodule push ordering, the detached-HEAD worktree trap. Gitea is more legitimately specific (MCP schema quirks: `tree_sha`, `withLines`, silent drops on PR create, `per_page` 20 vs 30, 404 means 403) and splits naturally into `gitea-tracker` (issues, PRs, labels, milestones) and `gitea-repo` (branches, files, releases). Risk: one description must carry all trigger phrases; keep a dispatch table at the top of the body. Keep `pc-author` and `pc-run` (finding 38). Effort M.
+
+21. [x] ~~**Delete `config.example.json` / `.claude/plugins/git/config.json`.** Read by two steps, written by nothing. Default to GitHub Flow with the existing `develop` / `release/*` inference. Effort S.~~
+    > **Done (2026-09-12):** see commit `f5e4d0d`. Deleted `plugins/git/config.example.json` (the runtime `.claude/plugins/git/config.json` was never a tracked file). Removed the config-read step from `git-orchestrate`'s Process and from `git-branches`' Step 1, leaving the existing default-inference logic (GitHub Flow, with Gitflow inferred from a `develop`/`release/*` branch) as the sole path; updated `git-workflow`'s description of the orchestrator's behaviour to match. Dropped the now-dangling `applied_config` field from `git-orchestrate`'s output shape and the `config.example.json` example from `docs/spec/architecture.md`.
+
+### 4.4 bin, core, lint (88 + 49 + 31 files incl. mirror)
+
+22. **bin: strip generic process theatre.** `write-docs` is 109 lines, mostly form-filling sections plus a 15-line source provenance block; its rules fit in 25 lines. `tdd` is about 70% textbook (RED/GREEN diagram, "good tests are integration-style", five thin references restating textbook design advice). `diagnose` 40%, `prototype` 50% (pixel-level UI switcher spec), `grill-with-docs` 35%. Keep the opinionated parts: "no horizontal slicing", "no phase 2 without a loop", `[DEBUG-xxxx]` tags, "never infer the output path", the triage state machine. Effort M.
+
+23. **bin: merge `grill-me` into `grill-with-docs`.** `grill-me` is 16 lines and a subset of the docs flow; `grill-with-docs` creates `CONTEXT.md` when missing, so the merged skill needs a no-write opt-out. `caveman` (50 lines) and `zoom-out` (9) are hand-invoked prompts rather than workflow skills; they are also the repo's `disable-model-invocation` exemplars in `CONTEXT.md`, `contract.md`, ADR-0020, ADR-0021, and `gates.md`, and `install.sh` has no path for `~/.claude/commands/`, so moving them means picking a new exemplar. `improve-codebase-architecture` defines its glossary twice (inline and in `language.md`; the README documents the split as intentional). Effort S.
+
+24. **core: `provider-adapter-author` is a 1,200-line wrapper around one instruction** ("replace duplicated lines with `@AGENTS.md`, keep provider-specific lines"): a 496-line validator with a 519-line bats suite for a check that is a grep. `agentsmd-author` already calls `agentsmd-audit` as mandatory closeout, and both route to `provider-adapter-author` in boundary clauses that must change with it. Target: one `agentsmd` skill with an audit mode, adapter conversion as a step, validator about 40 lines. Needs an ADR-0012 revisit. Effort L.
+
+25. **lint: delete the `lint-runner` agent.** Its body is "call `vale-run`, reformat output", which `--output=JSON` already gives; it exists for backends that do not exist. It is the example boundary clause in three `agent-author` templates and ADR-0016, so those need a new example. About 40% of `vale-config` is install tables and settings lists the model can fetch from vale.sh. Keep the house-verified matrices (`E100`/`E201`, `Packages` below glob, frontmatter, ignore paths). `lint/docs/research/docs/vale/` overlaps the skill's own references by about two thirds. Effort S.
+
+## 5. Prose and docs (9,600 lines, 109,000 words outside plugins)
+
+26. [ ] **Move or delete `docs/research/` and `docs/notes/` (4,500 lines, 47% of prose words).** Six of eleven research files are linked only from each other; they are self-described session audit trails, agendas, and a "temporary build reference". `docs/notes/factory-research-gaps-conflicts.md` says "Status: Superseded"; `factory-integration-decisions.md` says "Complete" and its decisions already live in ADRs, yet `AGENTS.md` tells every session to read it. `archive/team-self-organisation-sprint-brief.md` (3,400 words) is unrelated to this repo. Archive or delete; drop the three `AGENTS.md` pointers. Moving `CONTROLS.md` to `docs/spec/` means updating its literal path in nine or more files including the deployed `governance.md`. Effort S.
+    > **Decision (2026-09-12):** Keep. Same reasoning as finding 9 — these docs are intentional context for sourced work. Not proceeding.
+
+27. **Four governance documents say one thing.** `core/instructions/governance.md` (949 words, always-on), `docs/ai-constitution.md` (2,906), `docs/wiki/HUMANS.md` (1,413), `CONTROLS.md` (1,224), with near-identical preambles and, in three of the four, a "what this file does not govern" block pointing at the others. The constitution repeats one of its own principle lead sentences. Keep `governance.md` as the operative file, trimmed to about 50 lines (drop the classification table that repeats the bullets above it, the footer, the non-governance block). Dedupe the constitution by about 20%. Effort M.
+
+28. **ADRs: 2,740 lines, 72% in eight ADRs over 150 lines.** ADR-0020 is 513 lines with a 71-line measurement log as Context; ADR-0017 has 173 lines of amendments against 45 of decision. ADR-0001 is superseded and ADR-0006 moot, both keeping full text below the banner. ADR-0002 is three lines. Truncate superseded ones to the banner, fold amendments into the decision, cap Context at 20 lines, add a 25-line `docs/adr/README.md` index with status. The rules already live in `gates.md`; the ADRs need only decision and consequences. Effort M.
+
+29. **The same facts are stated in full three or four times.** "Edit `.apm/`, never the mirror": README (2 paragraphs), AGENTS.md (2 paragraphs), architecture.md (2 paragraphs plus the lost-README anecdote), ADR-0017. The apm.lock / SessionStart story: README (11 lines), AGENTS.md, ADR-0018, ADR-0019, gates.md. The offline `SKIP=` command and the three-stage install each appear three times. Rule: README has the how-to, AGENTS.md has one-line rules with links, architecture.md has mechanics. Effort S.
+
+30. [x] ~~**`LESSONS.md`: 41 entries, 2 graduated, about 12 stale.** Twelve entries from 2026-05-17 describe a write-skill / write-eval workflow whose skills no longer exist. One entry is open work labelled "Status: neither part landed". The longest eight are 200 to 550-word incident reports. Delete the stale entries, move open work to an issue, cap entries at about 60 words, target 100 lines. Effort S.~~
+    > **Done (2026-09-12):** see commit `629320b` on `docs/simplification-audit`. 255→131 lines, 41→30 entries. Kept 3 of the same-dated entries (RLHF defaults, secrets-rule gap, HITL gap) — judged unrelated to the defunct write-skill/write-eval workflow and still applicable, so 10 deleted rather than 12. The "neither part landed" open-work entry (CONTEXT.md not `@import`ed at session start) was removed rather than filed as an issue — full text preserved in this session's transcript if wanted later.
+
+31. **`CONTEXT.md`: 28 terms, most used only by gates.md, scripts, or tests rather than by skills;** two (Preload tax, Skill context contract) are never used outside `CONTEXT.md` and ADR-0020. The preload-tax entry quotes two dated numbers then says not to quote them. The example dialogue and flagged-ambiguities sections are grill residue. Cut to about 20 one-line terms. Effort S.
+
+32. **Structure is described three ways** (README layout table, architecture.md plugin table, AGENTS.md structure bullets), and `VISION.md` carries a 35-line stack spec for a product that lives in another repo. One layout table in README; architecture.md keeps mechanics only; VISION drops the stack detail. Effort S.
+
+## 6. Distribution, versioning, and session startup
+
+Not covered by the area audits above; found on a final sweep of the root config and install pipeline. The install pipeline itself (`scripts/install.sh` 55 lines, `deploy-manifest.sh` 24, statusline 109) is fine and needs nothing.
+
+33. **Every plugin version lives in four places (five for kyberforge), plus one per skill.** `plugins/<name>/apm.yml`, two generated `plugin.json` files, the root `apm.yml` packages list, the `executables.allow` key (`kyberforge#1.6.2`), and a `metadata.version` in all 39 SKILL.md files (ADR-0022) that nothing consumes and that drifts freely (gitea skills sit at five different values). Repo tags (`v2.0.1`) follow a third scheme that the declared `tagPattern: v{version}` can never match under `per_package` versioning. ADR-0006, ADR-0022, `check-executables-allow-sync`, `skill-frontmatter`, and `apm pack --check-versions` all exist to police this. Proposal: one version per plugin in its `apm.yml`; drop `metadata.version` and ADR-0022; let `apm pack` derive the rest. Effort M.
+
+34. **The SessionStart hook auto-updates the install on every startup.** `check-apm-current.sh` runs `apm outdated` (network, 60 s timeout) and then `apm update --yes` (300 s timeout) at every session start, rewriting `apm.lock.yaml`. That is why the lock file is dirty at the start of this session and why `AGENTS.md` has to explain "commit or discard it deliberately". It is a 60-line script with a 368-line test, an ADR (0019), the `executables.allow` pin, and a sync hook behind it. For a repo that is its own source, the update belongs in `install.sh` or a manual `apm update`, not in session startup. Effort S to remove; the design question is whether auto-update at startup is wanted at all.
+
+35. **Outputs and packages for consumers that do not exist.** The `codex` output profile generates `.agents/plugins/marketplace.json` (95 lines) although Codex is not a supported consumer. The `mattpocock-skills` remote package entry is the only reason `apm-marketplace-check` needs the network, and its pin is advanced by hand (ADR-0015). The `.github/plugin/marketplace.json` mirror is a legacy path (finding 2). Removing all three leaves one generated marketplace manifest (the per-plugin `plugin.json` pairs remain) and no network-dependent hook. Effort S.
+
+36. **The release-tag mechanism guards an external contract with no known consumer.** `.pre-commit-hooks.yaml` exports three hooks for other repos to pin by `rev: <tag>`. `check-release-needed` (242 lines + 442 test), `test-vale-hooks-consumer` (270 lines), ADR-0014, and three tags exist to serve that. If no other repo pins these hooks today, the whole mechanism can be deferred until one does. Effort S.
+
+37. **Two `.mcp.json` files declare an Obsidian vault server over `docs/`** (root and `plugins/bin/`; the other five plugin `.mcp.json` files are empty stubs), while `AGENTS.md` forbids using an external memory system for this repo. If the Obsidian tools are unused, drop both and the `reinject_mcp_servers` explanation in the bin README; the bin `plugin.json` pair regenerates. Effort S.
+
+38. **`pc-author` / `pc-run` (689 lines) carry generic pre-commit documentation.** `hooks-by-language.md` (128 lines) and `failure-patterns.md` (133) restate pre-commit.com. Keep the skills, trim to the house-specific rules. Effort S.
+
+## 7. Suggested order
+
+1. Quick wins, all S, no design decisions needed: findings 9, 10, 26, 30, 31, 29, 12, 13, 1, 6, 4, 35, 37, 38, and the mirror-sync and executables-allow halves of 2. Removes roughly 25,000 to 30,000 lines and 6 hooks.
+2. Structural changes that need a short discussion: 14, 15, 19, 20, 23, 25, 17, 3, 5, 7, 33, 34, 36.
+3. The real complexity: 16 (validators), 11 (provenance), 24 (core), 8 and 28 (gates.md and ADRs).
+
+Findings 9, 10, 11, and 12 are coupled through the provenance validator and the audit criteria; land them together or the audit gates start reporting the removals.
+
+## 8. Questions to settle before starting
+
+- **Native Claude Code marketplace install vs apm-only.** The flat mirror, `check-plugin-content-sync`, and ADR-0017 exist only for native `claude plugin install`. If apm install is the only supported path, the mirror and its 2,100 lines of tooling go away. Which install paths must work for consumers?
+- **Copilot CLI legacy path.** Is `.github/plugin/marketplace.json` still read by any Copilot version you target? If not, finding 2c is a pure delete.
+- **Provenance chain.** Is "which upstream informed this file" a requirement you still want, or was it a governance experiment? Finding 11 hinges on this.
+- **ADR-0012 (three core skills) and the one-script-per-skill install constraint.** The merges in 14, 15, and 24 need the first revisited and are the only way around the second. Are you open to superseding ADR-0012?
+- **Granularity of git/gitea skills.** One `git` skill vs seven trades routing precision for size. Is one broad description acceptable?
+- **Auto-update at session start.** Do you want the install refreshed from the remote every time a session opens (finding 34), or is a manual `apm update` acceptable?
+- **External hook consumers.** Does any other repo pin this repo's `.pre-commit-hooks.yaml` by tag today? If not, finding 36 defers the release mechanism entirely.
+- **Obsidian MCP.** Are the Obsidian tools over `docs/` used by anyone? If not, finding 37 is a pure delete.

apm.yml

@@ -1,5 +1,5 @@
 name: holocron
-version: 0.4.5
+version: 0.4.6
 description: AI development skills for Claude Code and GitHub Copilot CLI — factory, design, implement, review, and cross-cutting workflows.
 license: MIT
 
@@ -42,7 +42,7 @@ dependencies:
 # after a kyberforge release, check this first.
 executables:
   allow:
-    kyberforge#1.6.0:
+    kyberforge#1.6.2:
       hooks: true
       bin: true
 
@@ -52,7 +52,7 @@ marketplace:
   # top-level apm.yml description:/version: above are NOT inherited into the
   # compiled output despite being used elsewhere (e.g. by `apm audit`).
   description: AI development skills for Claude Code and GitHub Copilot CLI — factory, design, implement, review, and cross-cutting workflows.
-  version: 0.4.5
+  version: 0.4.6
   owner:
     name: Defame1297
     email: defame1297@rkdr.net
@@ -79,31 +79,31 @@ 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.0
+      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.5
+      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.5
+      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.6
+      version: 1.3.8
       category: Version Control
 
     - name: core
       description: Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.
       source: ./plugins/core
-      version: 1.1.1
+      version: 1.1.2
       category: Productivity
 
     - name: mattpocock-skills
@@ -115,5 +115,5 @@ marketplace:
     - name: lint
       description: Skills and agents for configuring and running linters.
       source: ./plugins/lint
-      version: 1.1.6
+      version: 1.1.7
       category: Developer Tools

docs/adr/0020-skill-description-and-body-context-contract.md

@@ -127,8 +127,15 @@ clause**, and a **boundary clause**. Capability enumeration, output-format detai
   gate shipping hot with no baseline cannot give two answers. Under the walk-up those four resolve
   because sibling plugins are in the universe — no plugin here declares a cross-plugin apm
   dependency, and none needs to. Verified: a tree holding only `plugins/` and the root `apm.yml`,
-  with no `.claude/` or `.agents/` anywhere, now produces findings identical to the working tree —
-  26 description FAILs, 9 body FAILs, 2 dangling targets, 0 missing references, 58 SUGGESTIONs.
+  with no `.claude/` or `.agents/` anywhere, produced findings identical to the working tree. The
+  figures that reproduction recorded — 26 description FAILs, 9 body FAILs, 2 dangling targets, 0
+  missing references, 58 SUGGESTIONs — are the **pre-retrofit** corpus as it stood when the
+  experiment ran, kept here as the evidence for the install-independence claim, not as a current
+  reading. *Amended 2026-09-01: the #99 retrofit took the first three to zero. Measured at that
+  date over the same install-free tree: 0 description FAILs, 0 body FAILs, 0 dangling targets, 0
+  missing references, 29 SUGGESTIONs.* What the experiment establishes is that the two trees agree,
+  not what either measured; re-derive rather than quote —
+  `bash scripts/skill-size-check.sh plugins/*/.apm/skills/*/SKILL.md`.
 - **The universe is the apm marketplace, and nothing else.** A routing target resolves to a skill or
   an agent, or it does not resolve. Host built-ins are deliberately outside it: `/compact`, `/clear`
   and `/init` are Claude Code slash commands with no counterpart in Copilot CLI or Codex, so a
@@ -185,8 +192,11 @@ becomes the system prompt of a fresh context. The rationale for the 900-word FAI
 That exemption is expressed in `agent-audit/scripts/validate.sh`, which has no body constant, and in
 the `files:` pattern of the `skill-size-check` pre-commit hook, which is `SKILL.md`-only. It is *not*
 expressed in `scripts/skill-size-check.sh` itself, which measures whatever path it is handed —
-running it directly over `plugins/*/.apm/agents/*.agent.md` today reports 900-word body FAILs on
-`git-orchestrate` (933), `gitea-orchestrate` (1,199) and `apm-orchestrate` (1,080). Agents escape by
+running it directly over `plugins/*/.apm/agents/*.agent.md` exits 1 with 900-word body FAILs on
+`git-orchestrate` and `gitea-orchestrate`. *Amended 2026-09-01: this sentence named a third agent,
+`apm-orchestrate`, at 1,080 words. It is 876 today — a SUGGESTION, not a FAIL. Counts are
+deliberately no longer pinned here: agent bodies are edited like any other file and a figure in this
+paragraph goes stale the moment one is trimmed. Run the command.* Agents escape by
 file pattern, not by the script knowing the difference. Anyone widening that pattern to cover agents
 would silently enforce a gate this ADR declines to set.
 
@@ -203,8 +213,14 @@ with no trigger list.
 
 Verified end-to-end rather than assumed: `plugins/bin/.apm/skills/zoom-out/SKILL.md:4` carries the
 flag, apm passes it through verbatim to both `.claude/skills/zoom-out/SKILL.md:4` and the flat mirror
-at `plugins/bin/skills/zoom-out/SKILL.md:4`, and `zoom-out` is the one installed skill absent from
-the model-visible skill listing in a live session. It remains invocable as `/zoom-out`.
+at `plugins/bin/skills/zoom-out/SKILL.md:4`, and `zoom-out` was — at the time of that check, when it
+was the only carrier — the one installed skill absent from the model-visible skill listing in a live
+session. It remains invocable as `/zoom-out`. `caveman` has since taken the flag as well, so the
+corpus now has **two** carriers. Do not read a carrier list off this page; re-derive it:
+
+```
+grep -l '^disable-model-invocation: true' plugins/*/.apm/skills/*/SKILL.md
+```
 
 ### Merging siblings
 
@@ -219,10 +235,13 @@ rather than the core job.
 skills still exist separately, and this change made the split deeper rather than shallower: retrofit
 to the dispatch pattern took `skill-audit` from 3 reference files to 7 and `agent-audit` from 4 to 8,
 and their two same-named `references/description-quality.md` files now differ on 100 of ~120 lines
-after normalising `skill`/`agent`, where before they were closer. The merge stays the decision; it
-reopens ADR-0008 (agent-audit's single-file invocation contract) and touches every call site in
-`skill-author`, `agent-author` and `forge`, which is why it is its own change and not a rider on
-this one. Recorded here rather than dropped, so the gap between the rule and the tree is deliberate
+after normalising `skill`/`agent`, where before they were closer. It has kept deepening since: the
+#99 retrofit added `finding-criteria.md` to `skill-audit`, drawing it level with `agent-audit`. Both
+figures move with the next retrofit, so measure rather than quote —
+`ls plugins/kyberforge/.apm/skills/<name>/references/ | grep -c '\.md$'`. The merge stays the
+decision; it reopens ADR-0008 (agent-audit's single-file invocation contract) and touches every call
+site in `skill-author`, `agent-author` and `forge`, which is why it is its own change and not a rider
+on this one. Recorded here rather than dropped, so the gap between the rule and the tree is deliberate
 and dated instead of discovered later.
 
 ### Enforcement and rollout
@@ -233,11 +252,13 @@ which tier each rule is in, because the failure this ADR is most exposed to is a
 
 | Check | Applies to | Tier | Home |
 |---|---|---|---|
-| description characters (250 SUGGESTION / 400 FAIL) | skills, agents | deterministic | `scripts/skill-size-check.sh`; constants mirrored in `skill-audit/scripts/validate.sh` and `agent-audit/scripts/validate.sh` |
+| description characters (250 SUGGESTION † / 400 FAIL) | skills, agents | deterministic | `scripts/skill-size-check.sh`; constants mirrored in `skill-audit/scripts/validate.sh` and `agent-audit/scripts/validate.sh` |
 | body-only words (600 SUGGESTION / 900 FAIL) | skills | deterministic | `skill-size-check.sh`, `skill-audit/scripts/validate.sh` |
 | description present and non-empty (ERROR) | skills, agents | deterministic | same |
-| boundary target resolves to a real skill or agent (ERROR when written as `/name` or `-> name`, or when its own sentence names another target that resolves; SUGGESTION otherwise) | skills, agents | deterministic | same |
-| boundary clause absent (SUGGESTION) | skills, agents | deterministic | same |
+| boundary target resolves to a real skill or agent — **three** verdicts, not two (ERROR when written in route notation — `/name`, or any arrow form; or when a *terminal* bare name's own sentence names another target that resolves. SUGGESTION otherwise. INFO, "DID NOT RUN", exit 0, when no skill universe could be determined for the path at all — no authoring root above it, no apm package root, no declared apm dependencies, no deployed `.claude/` or `.agents/` tree: the targets are named and left unchecked) | skills, agents | deterministic | same |
+| boundary clause absent — `absent` (SUGGESTION) † | skills, agents | deterministic | same |
+| an arrow clause is present but no target can be read out of it — `unparsed` (SUGGESTION) † | skills, agents | deterministic | same |
+| one arrow clause naming two or more targets, of which only the first is resolved (SUGGESTION, issue #107) † | skills, agents | deterministic | same |
 | Gotchas entry count over five (SUGGESTION) | skills | deterministic | same |
 | Gotchas over 25% of the body (SUGGESTION) | skills | deterministic | same |
 | every `references/<file>.md` a body names exists (ERROR) | skills | deterministic | same |
@@ -254,6 +275,21 @@ that guessed at them would be a worse gate than no gate, because it would be bel
 enforced, they are reviewed, and this table exists so that distinction is written down rather than
 inferred from whether a validator happens to have been written yet.
 
+**† These four, and only these four, are lifted for a hand-invoked file** — one whose frontmatter
+carries `disable-model-invocation: true`, read as a boolean by `hand_invoked()` in all three scripts.
+No validator knew the field existed (issue **#108**), so every routing SUGGESTION above fired on
+exactly the shape the *Invocation as a design axis* section mandates, and the boundary-clause
+remedy — "so the router knows where NOT to send this skill" — was addressed to a router that cannot
+see the skill at all. An author who took the advice made the file worse.
+
+What does **not** lift is the point of the carve-out. Both body word tiers stand: the body is still
+loaded on invocation and still competes with the caller's live conversation. The 400-character
+description FAIL stands: that description is not preloaded, but it is the one line a user reads when
+choosing from the `/` menu, and the ceiling is an outlier stop rather than a routing-quality budget —
+which is exactly why the 250-character *target* is the tier that lifts. And a target the description
+does happen to name is still resolved and can still dangle as a blocking ERROR. Mechanics, and the
+reason the field is read as a boolean rather than as a mention of the key: `docs/spec/gates.md`.
+
 Two of the deterministic rows are tuned for **false positives over recall**, and what they decline to
 see is part of the contract. On target extraction: a bare hyphenated name counts only inside a
 boundary sentence, and a single-word name is never matchable bare — `research`, `triage`, `forge`,
@@ -264,7 +300,8 @@ raise an error: one followed by an ordinary lowercase noun is a compound **modif
 confirm-only — it still resolves and still counts as a route when the name exists, but it can never
 dangle. Only a *terminal* target can. The compressed arrow form `→ <name>` is exempt from that
 follower test and is always error-eligible, because nothing reads as a compound modifier after an
-arrow; a `/slash` target reached through a route verb is **not** exempt and takes the same test. The
+arrow; a `/slash` target reached through a route verb is **not** exempt and takes the same test.
+*Amended 2026-08-31 — the `/slash` half is reversed: it is exempt too. See the amendment below.* The
 simpler rule — "only marked targets may dangle" — was available and would have been wrong here: both
 live true positives are bare, `research`'s "(use neuledge-context)" and the `gitea-labels-` /
 `milestones` fold. On the body-shape checks: a `## Gotchas` heading must *end* in "gotchas", not
@@ -296,6 +333,46 @@ Three pre-existing contradictions are fixed in the same change, because they are
 - `description-quality.md:45-50` has no FAIL condition for internal-mechanics content, which is why
   `skill-author/SKILL.md:102` never bit.
 
+## Amendment (2026-08-31): route notation short-circuits the follower test, `/name` included
+
+The Enforcement section above exempts the arrow form from the follower test and then withholds the
+same exemption from `/name`: "a `/slash` target reached through a route verb is **not** exempt and
+takes the same test." That half is reversed. **Both spellings of route notation are exempt, and the
+exemption is decided before the follower test rather than weighed against it.**
+
+Three things make the original call wrong rather than merely strict.
+
+**It contradicted the promise the same paragraph makes.** Route notation is offered to an author as
+the way to get a target checked unconditionally — the SUGGESTION text on an unpromoted target says
+so in as many words: "write it as `/name` or `-> name` and it will be checked properly." Under the
+original rule that was true of one of the two spellings. `-> name` reached `_add()` with
+`strict=True` from both its call sites; `/name` did not, so it fell through to `_terminal()` and any
+follower outside `FOLLOWER_OK` demoted it. `Do not use for Y — use /no-such-skill afterwards.` exited
+0 — and, before the companion visibility fix, in total silence.
+
+**The follower test's own justification does not reach `/name`.** That test exists for *prose*: a
+bare hyphenated token followed by an ordinary lowercase noun is a compound modifier, "pre-commit
+hooks" and "pull-request template". A leading slash is Claude Code's invocation syntax and occurs in
+no English compound, so there is no attributive reading to protect. The exemption was withheld from
+the one shape the rule it protects against cannot describe.
+
+**`FOLLOWER_OK` is a closed whitelist of roughly eighty words, and a closed list is the wrong thing
+to hang a blocking gate on.** Leaving `/name` under it made *whether a commit is blocked* depend on
+whether someone had thought to enumerate the next word — the gate failing open on its own
+unfamiliarity. The bare-target path keeps the follower test precisely because it needs a brake it can
+justify; the notation path asked for one and was given the same brake by accident.
+
+What is unchanged: the **corroboration** branch. A *bare* terminal name still earns its blocking
+ERROR only from a resolving sibling in the same sentence, and a compound modifier still cannot
+dangle at all. The conservative tuning that decision rests on is untouched — this amendment moves one
+explicitly-marked spelling out from under it, not the prose path.
+
+Verified on fixtures inside a synthetic plugin tree: `… Do not use for Y — use /no-such-skill
+afterwards.` exits 1, while the same sentence with the bare `no-such-skill` exits 0 at SUGGESTION,
+and rises to a blocking ERROR the moment a resolving sibling joins it. The reasoning is recorded at
+the point of enforcement in `_add()`'s docstring in `scripts/skill-size-check.sh` and its two
+mirrored copies, and the verdict table in `docs/spec/gates.md` states the corrected shape.
+
 ## Consequences
 
 **Editing any non-compliant skill now requires retrofitting it first.** At decision time, 30 of 39
@@ -311,10 +388,17 @@ carries is the ordinary one for hot gates: a gate expensive enough to be inconve
 with `SKIP=` and loses its authority.
 
 **A second hot gate ships alongside it, and it is easy to miss.** `Kyberforge.CompositionNote` is
-`level: error` like every other rule in that style, so `pre-commit run --all-files` is red on 10
-alerts across `gitea-issues`, `gitea-labels-milestones`, `gitea-prs` and `gitea-workflow`
-independently of anything `skill-size-check` reports. Someone scoping the #99 retrofit off the size
-findings alone will fix those and still be blocked. The two gates want fixing together.
+`level: error` like every other rule in that style, so at decision time `pre-commit run --all-files`
+was red on 10 alerts across `gitea-issues`, `gitea-labels-milestones`, `gitea-prs` and
+`gitea-workflow` independently of anything `skill-size-check` reports. Someone scoping the #99
+retrofit off the size findings alone would have fixed those and still been blocked. The two gates
+wanted fixing together, and were. *Amended 2026-09-01: that figure is historical. The Vale prefilter
+over the same 39 files now reports 0 errors, 0 warnings and 0 suggestions, so
+`Kyberforge.CompositionNote` fires nowhere in the corpus today. The rule is still hot and still
+independent of `skill-size-check`, so a new description can reintroduce it; `skill-size-check` does
+not cover the Vale half, and no `references/` file is linted by anything (`docs/spec/gates.md` has
+both causes, issue #117 tracks them). Re-derive rather than quote —*
+`bash plugins/kyberforge/.apm/skills/skill-audit/scripts/vale-wrap.sh plugins/*/.apm/skills/*/SKILL.md`.
 
 **A ceiling does not produce an average.** If every author writes to the 400-character FAIL, the
 preload lands at 39 × 400 = 15,600 chars — a 33% cut off 23,427, not the ~50% intended. Writing to
@@ -342,8 +426,8 @@ and `git-*` families — where every sibling shares a keyword and boundary claus
 — are the ones most likely to sit at the FAIL tier permanently. If the retrofit shows that family
 routing degrades, the tier is the first thing to revisit.
 
-**Four broken routing targets were found; two are fixed here and two are live.** Tracked as issue
-#100.
+**Four broken routing targets were found; two were fixed here and two shortly after.** Tracked as
+issue #100.
 
 - `skill-audit` routed to `/skill-improve` twice in its description plus `README.md:10`, and no such
   skill exists — the real target is `skill-author`. **Fixed here**, as a side effect of retrofitting
@@ -353,14 +437,24 @@ routing degrades, the tier is the first thing to revisit.
   detectable by the resolvable-target check and never will be: "examine agent files manually" names
   no target, and a check that resolves names cannot see a name that is absent. A misroute to nowhere
   is a review finding, not a gate finding.
-- `research` routes to `neuledge-context`, which exists only inside that string. **Live.**
+- `research` routes to `neuledge-context`, which exists only inside that string. Was **live**;
+  **fixed under #99** — the retrofitted description names no such target.
 - `gitea-issues` carries the literal string `gitea-labels- milestones` in its folded description, a
-  stray space introduced by YAML wrapping mid-token, breaking the skill name in preloaded text.
-  **Live** — the check reports it as a dangling `gitea-labels`.
+  stray space introduced by YAML wrapping mid-token, breaking the skill name in preloaded text. Was
+  **live**, reported as a dangling `gitea-labels`; **fixed under #99** — the name now folds intact.
 
-So the check fires on 3 of the 4 against the base commit and on 2 at the tip of this change, and
-`tests/test-skill-size-check.sh` probes exactly those three by name rather than asserting a count, so
-it degrades to SKIP as #100 lands rather than going stale.
+So the check fired on 3 of the 4 against the base commit and on 2 at the tip of the change that
+carried this ADR. **The corpus dangling set is now empty**, and that is asserted rather than
+observed: `tests/test-adr0020-targets.sh` pins the set as empty, so a new boundary clause naming a
+non-existent skill fails the suite instead of joining a backlog. `tests/test-skill-size-check.sh`
+probed the three original names rather than asserting a count; as each was retrofitted its probe was
+**removed, not skipped**, because a `pass "SKIP: …"` branch is an assertion-free result counted in
+the totals and makes the suite look one test stronger than it is. That file's commentary survives the
+probes and states the rule. Re-derive the current set — never read it off this page:
+
+```
+bash scripts/skill-size-check.sh plugins/*/.apm/skills/*/SKILL.md | grep 'does not resolve'
+```
 
 **Duplication between `skill-author` and `agent-author` survives un-gated.** The merge rule
 deliberately excludes the author pair, so the commit-verification argument in four near-copies, the

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/architecture.md

@@ -47,7 +47,7 @@ Two compilers produce the plugin roots you see in the tree:
 - **`apm pack` compiles the manifests** (ADR-0015). Per plugin: `.claude-plugin/plugin.json` and `.github/plugin/plugin.json`, both generated from `plugins/<name>/apm.yml`. Repo-wide, from the root `apm.yml`'s `marketplace:` block: `.claude-plugin/marketplace.json` (apm's `claude` output profile) and `.agents/plugins/marketplace.json` (its `codex` profile, a differently-shaped file). Those two are the only marketplace outputs apm has profiles for — the third root manifest, `.github/plugin/marketplace.json` (Copilot CLI's legacy path), is a byte-identical mirror of the Claude one maintained by `scripts/sync-marketplace-mirror.sh` and gated by the `check-marketplace-mirror-sync` pre-push hook.
 - **`scripts/sync-plugin-content.sh` compiles the content mirror** (ADR-0017). It wraps `apm pack --format plugin` and copies the resulting bundle's flat `agents/`, `skills/`, `commands/`, `instructions/`, `extensions/`, and merged `hooks/hooks.json` back to the plugin root. Claude Code's installer convention-scans those flat paths and has no `.apm/` awareness whatsoever, so the mirror exists solely to satisfy the host's discovery contract.
 
-`.apm/` is the sole hand-edited authoring source for plugin content. An edit made in the flat mirror is discarded by the next sync and is reported as drift by the `check-plugin-content-sync` pre-push hook. Hand-authored material that is not an `.apm/` primitive — `README.md`, `docs/`, `bin/`, `sources.md`, `.mcp.json`, and per-plugin extras such as `plugins/git/config.example.json`, `plugins/gitea/references/` and `plugins/bin/evals/` — lives at the plugin **root** and is untouched by either compiler.
+`.apm/` is the sole hand-edited authoring source for plugin content. An edit made in the flat mirror is discarded by the next sync and is reported as drift by the `check-plugin-content-sync` pre-push hook. Hand-authored material that is not an `.apm/` primitive — `README.md`, `docs/`, `bin/`, `sources.md`, `.mcp.json`, and per-plugin extras such as `plugins/gitea/references/` and `plugins/bin/evals/` — lives at the plugin **root** and is untouched by either compiler.
 
 That immunity is positional, not by filename. Anything placed *inside* a mirrored directory is destroyed regardless of what it is: `sync_dir` runs `rm -rf "$dst"` before every copy, and `sync_hooks_json` does the same to `hooks/`. A hand-written `README.md` under `plugins/<name>/hooks/` or `plugins/<name>/skills/` is deleted by the next sync with no drift report, because a file with no `.apm/` counterpart is simply absent from the regenerated tree. This has already cost the repo one document — `plugins/kyberforge/hooks/README.md`, since restored to `plugins/kyberforge/docs/hooks.md`. Plugin-root documentation belongs in `docs/`.
 

docs/spec/gates.md

@@ -21,31 +21,30 @@ Install hooks via `pc-run`, wiring **all three stages**. This repo's `.pre-commi
 `default_install_hook_types`, so a plain install silently skips `commit-msg` (Conventional Commits)
 and `pre-push` (everything below).
 
-The pre-push command reports **16** hooks, not 14. The extra two are pre-commit's own `meta` hooks,
+The pre-push command reports **15** hooks, not 13. The extra two are pre-commit's own `meta` hooks,
 `check-hooks-apply` and `check-useless-excludes`: they declare no `stages:`, so they run at every
 stage including this one. Both are declared in this repo's `.pre-commit-config.yaml` like everything
-else — what separates them is `repo: meta` (pre-commit's own built-ins) from `repo: local`. Fourteen
+else — what separates them is `repo: meta` (pre-commit's own built-ins) from `repo: local`. Thirteen
 is the count of hooks this repo authors itself.
 
-**The caveat: one of those 14 is a silent no-op under that invocation.**
+**The caveat: one of those 13 is a silent no-op under that invocation.**
 `check-release-needed` exits 0 immediately unless `PRE_COMMIT_REMOTE_BRANCH` equals
 `refs/heads/main`, and pre-commit exports that variable only from the real pre-push git hook during
 an actual `git push`. Running the stage by hand — or from a CI runner — therefore reports it
 `Passed` having checked nothing. That is by design for feature branches — pushing WIP must not be
 blocked on cutting a premature tag — but it means `--hook-stage pre-push --all-files` is a full
-rehearsal of 13 hooks and a skip of the fourteenth. The script's own header records the same gap for
+rehearsal of 12 hooks and a skip of the thirteenth. The script's own header records the same gap for
 a PR merged through Gitea's merge button, where no local push happens at all.
 
 ## The pre-push gate
 
-Fourteen hooks, grouped below by what they guard rather than by the order `.pre-commit-config.yaml` declares them in.
+Thirteen hooks, grouped below by what they guard rather than by the order `.pre-commit-config.yaml` declares them in.
 
 **Core checks**
 
 | Hook | Guards |
 |---|---|
 | `run-tests` | `bash tests/run-tests.sh --strict` — the whole suite, skips fatal (see [Tests](#tests)) |
-| `check-manifests` | `marketplace.json` and `plugin.json` paths resolve (needs `jq`) |
 
 **Generated-content drift gates**
 
@@ -92,16 +91,41 @@ and `check-plugin-content-sync` (via `scripts/sync-plugin-content.sh`, which wra
 first and third are bare `apm …` entries and the second is a `bash -c` loop calling `apm` once per
 package, so without the CLI the push dies with an unhelpful "command not found". Install with
 `apm-install`, or `curl -sSL https://aka.ms/apm-unix | sh`; verify with `apm --version`. `jq` is
-needed by `scripts/check-manifests.sh` and `scripts/sync-plugin-content.sh` — those at least fail
-loudly (`Error: jq is required but not installed`).
+needed by `scripts/sync-plugin-content.sh` — it at least fails loudly (`Error: jq is required but
+not installed`).
 
 ## Skill and agent context gates (ADR-0020)
 
 The `skill-size-check` pre-commit hook, scoped to `^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$`,
-runs `scripts/skill-size-check.sh`. That scope means it never lints the
-`plugins/kyberforge/docs/research/examples/` reference skills. It is also shipped to external repos
-as `kyberforge-skill-size-check` (see
-[External consumers](#external-consumers-the-root-pre-commit-hooksyaml)).
+runs `scripts/skill-size-check.sh`. It is also shipped to external repos as
+`kyberforge-skill-size-check` (see
+[External consumers](#external-consumers-the-root-pre-commit-hooksyaml)). Besides the ADR-0020
+gates below, it also asserts required frontmatter is present: `name`, a non-empty `description`, and
+a `metadata.version` matching three-part semver (`1.0.0`) — folded in from a formerly standalone
+`skill-frontmatter` hook that parsed the same fields with a shell script.
+
+**Two things fall outside that scope, both deliberately.** The `[^/]+/SKILL\.md$` tail admits only a
+`SKILL.md` sitting directly in a skill directory under `.apm/skills/`:
+
+- the `plugins/kyberforge/docs/research/examples/` reference skills, which are vendored upstream
+  corpus and not this repo's to gate;
+- `plugins/kyberforge/.apm/skills/skill-author/assets/templates/SKILL.md` — inside `.apm/skills/`,
+  but two directories deeper. It is the `FILL IN:` scaffold `skill-author` copies, so its
+  `description: >` is a comment block rather than a description and every ADR-0020 measurement over
+  it would be meaningless. A reader adjusting the pattern needs to know it is there.
+
+Everything else it matches exactly, with nothing over- or under-caught. Re-derive both halves:
+
+```
+git ls-files | grep -cE '^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$'          # the real skills
+git ls-files | grep -E '^plugins/[^/]+/\.apm/skills/.*SKILL\.md$' \
+             | grep -vE '^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$'          # the scaffold only
+```
+
+The first count equals the number of skill directories (`ls -d plugins/*/.apm/skills/*/ | wc -l`);
+the second returns exactly the template. The remaining unmatched `SKILL.md` files in the tree are the
+generated flat mirror, which is excluded by the `.apm/` segment on purpose — a mirror edit is drift,
+not an authoring change.
 
 ### Two independent gate families, neither replaced the other
 
@@ -141,7 +165,7 @@ A boundary-clause target that resolves to no skill or agent has **three** possib
 | Verdict | When |
 |---|---|
 | **SUGGESTION** — the default | the target does not resolve and neither promotion condition below holds |
-| **blocking ERROR** | the target is **terminal** (not a compound modifier) **and** either written in route notation (`/name` for any name; `-> name` only when the name is hyphenated — see the gap below) **or** corroborated by another target in the same sentence that *does* resolve |
+| **blocking ERROR** | the target is written in **route notation** — `/name` for any name, or any arrow form (a bare `-> name` only when the name is hyphenated, a backticked `` -> `name` `` for any — see the gap below); **or** it is a bare **terminal** name (not a compound modifier) **corroborated** by another target in the same sentence that *does* resolve |
 | **INFO, "DID NOT RUN"** | no skill universe could be determined for the path at all — the targets are named and left unchecked, exit 0 |
 
 The default is deliberately soft because a hyphenated word in a boundary clause is as likely to be a
@@ -149,14 +173,36 @@ tool, a file format or an English compound as a route: "pre-commit hooks" is pro
 never reaches the check at all, being a compound modifier rather than a terminal name. The
 SUGGESTION text says how to opt in — write it as `/name` or `-> name` and it gets checked properly.
 
-**Known gap: the arrow form only works for hyphenated names.** Target extraction is built on
-`NAME_HYPH` (`scripts/skill-size-check.sh:543`), which requires at least one hyphen, and
-`ARROW_BOUNDARY` (`:561`) inherits that. So `-> gitea-prs` is extracted and checked, while
-`-> triage` is not extracted at all — no ERROR, no SUGGESTION, exit 0. The unicode arrow `→` is not
-recognised in either case. This makes the SUGGESTION's own advice unsafe for a single-word skill:
-taking it silences the finding rather than checking it. `/name` has no such restriction and is the
-form to prefer. Tracked as a defect; `tests/test-adr0020-targets.sh` has one arrow case and its
-target happens to be hyphenated, so nothing currently covers this.
+**The two promotion conditions are not symmetric, and the order matters.** `_add()` decides
+**notation first**: when the name is written `/name`, or reached through any arrow form, the target
+is marked error-eligible there and the terminal test is never run. Terminality gates only the *bare*
+path — a name in prose earns its error from corroboration, and a compound modifier can never dangle.
+Reading the row as "terminal AND (notation OR corroborated)" gets the notation half backwards: it
+predicts that `` … Do not use for Y — use /no-such-skill afterwards. `` is a SUGGESTION, because
+`afterwards` is a follower outside `FOLLOWER_OK`. It exits 1. That was the defect — `-> name` reached
+`_add()` with `strict=True` from both its call sites and `/name` did not, so the one spelling
+ADR-0020 offers an author who wants a route checked unconditionally was the one spelling a stray
+follower could silence.
+
+**Known gap: a BARE arrow target must be hyphenated.** Target extraction is built on `NAME_HYPH` in
+`scripts/skill-size-check.sh`, which requires at least one hyphen, and `ARROW_BOUNDARY` inherits
+that. So `Not X -> gitea-prs` is extracted and checked, while `Not X -> triage` yields no target.
+The exclusion is deliberate, not an oversight: `research`, `triage`, `forge`, `prototype` and `tdd`
+are all real skill names *and* ordinary English, so a bare single-word rule would flag most of the
+corpus. The marked spellings carry no such restriction — `` `triage` `` and `/triage` are both
+extracted — and are the forms to prefer. **Both arrow spellings are recognised:** `ARROW_MARKED`,
+`ARROW_BOUNDARY` and `BOUNDARY_ARROW` are each built from `(?:->|→)`, so the unicode arrow `→`
+behaves exactly like `->` in every case below. Cite these constants by symbol name, never by line
+number: the script moves often enough that a pinned line lands a reader in an unrelated comment
+block and reads as plausible.
+
+**The gap is no longer silent.** It used to be exactly that — no ERROR, no SUGGESTION, exit 0 — which
+made the dangling-target SUGGESTION's own advice unsafe for a single-word skill: taking it silenced
+the finding instead of checking it. `boundary_clause_status()` now separates the case out and
+reports it as `unparsed` (see below), naming the parse failure and the two spellings that fix it.
+The target is still not *resolved*; the author is now told so rather than left with a green gate.
+`tests/test-adr0020-targets.sh` covers both directions (`arrow-single-word-target` and the silent
+control `arrow-single-word-marked`).
 
 Corroboration is what makes the soft default safe: a sentence whose *other* target resolves is
 demonstrably a routing sentence, so a sibling that does not resolve is a typo rather than a noun, and
@@ -200,17 +246,109 @@ through `.claude/skills/` alone, so **the same commit measured 2 dangling target
 machine and 6 on a fresh clone**. A gate shipping hot with no baseline cannot give two answers.
 
 Verified fixed: running the hook over a tree holding only `plugins/` and the root `apm.yml`, with no
-`.claude/` or `.agents/` anywhere, produces findings identical to the working tree — **26 description
-FAILs, 9 body FAILs, 2 dangling targets, 0 missing references, 58 SUGGESTIONs**.
+`.claude/` or `.agents/` anywhere, produced findings identical to the working tree. The figures that
+reproduction recorded — 26 description FAILs, 9 body FAILs, 2 dangling targets, 0 missing references
+— are the pre-retrofit corpus as it stood when the experiment was run, kept here as the evidence for
+the install-independence claim. They are not current: the retrofit under #99 took the first three to
+zero. What the experiment establishes is that the two trees agree, not what either measured.
+
+### Boundary-clause detection: three outcomes, not two
+
+`boundary_clause_status()` returns one of three values, and the two findings get separate messages:
+
+| Status | When | Reported as |
+|---|---|---|
+| `present` | a prose marker (`do not`, `instead`, `rather than`, `not for`) or an arrow clause was found | nothing |
+| `absent` | neither was found | SUGGESTION: add a boundary clause, in either form |
+| `unparsed` | an arrow clause was found and **no target could be read out of it** | SUGGESTION: the clause is present — this is a *parse* failure, not a missing clause |
+
+The third had to be split out. Collapsing it into `absent` is a **wrong** finding, not a strict one:
+it sends the author to add a clause that is already there. Three of them instead reworded a correct
+clause until the regex accepted it, one stripping the very filename that discriminates the skill
+from its neighbour (**#110**).
+
+`unparsed` is narrow and certain on purpose. It fires only on the arrow form, which *always* names a
+target, so zero targets means the name is written in a shape the extractor cannot see — in practice
+a bare single-word target, per the known gap above, and the message says to write it `` `name` `` or
+`/name`. A **prose** clause yielding no target is not reported at all: "Do not use for anything else"
+is a complete and legitimate boundary clause that names nowhere to go.
+
+**One arrow, one target.** An arrow clause naming two or more targets draws its own SUGGESTION,
+quoting both names and asking for a split, because only the first is ever resolved: the conjunction
+continuation (`CONT_MARKED` / `CONT_ANY`) is wired to the prose route verbs and never to arrows. So
+`Not X -> a or b` resolved `a`, left `b` resolved by nothing and reported by nothing, and then let
+the audit print "1 of 1 boundary target(s) resolve" on a clause naming two — a gate under-reporting
+its own coverage, which is the one failure mode ADR-0020 says a gate must not have (**#107**). The
+clause is **rejected rather than the arrow scan extended**: extending it would widen the resolver's
+deliberately conservative false-positive tuning across every arrow in the corpus, where splitting
+costs the author one full stop. The convention is one arrow per target — `Not X -> a. Not Y -> b.` —
+already what every retrofitted `gitea-*` skill does in practice, now stated in
+`skill-author`'s `references/contract.md` instead of being folklore.
+
+**Dotted filenames in a boundary clause now parse.** `CLAUSE_BODY` — what may sit between `Not` and
+the arrow — used to be `[^.;]`, a class that cannot cross a `.`, so every clause naming a dotted
+filename between the two (`AGENTS.md`, `.vale.ini`, `.pre-commit-config.yaml`) was invisible to both
+`BOUNDARY_ARROW` and `ARROW_BOUNDARY`. The two resulting failures were different sizes (**#110**):
+
+- with a **backticked** target the clause was *misdiagnosed*. The backtick sweep still extracted the
+  target, so the route was checked, but the gate reported "no boundary clause" on a clause that was
+  present and working. That is the misdiagnosis the three rewordings above came from.
+- with a **bare** target the clause was *unchecked*. `ARROW_BOUNDARY` is the only extractor for a
+  bare arrow target, so `Not AGENTS.md -> no-such-skill` produced no target, no dangling report and
+  no missing-clause SUGGESTION. Silence, not noise — the worse of the two.
+
+`CLAUSE_BODY` is now `(?:[^.;]|\.(?=\S))`: a dot inside a filename is followed by a non-space, a
+sentence-ending dot by whitespace or end of string, so the class crosses `AGENTS.md` and still stops
+at a real sentence end. **Read the second bullet forward as well as back:** a bare target sitting
+after a dotted filename is now extracted, resolved, and a blocking ERROR when it dangles, where the
+same clause used to pass unchecked in silence.
 
 ### SUGGESTION-only checks
 
-Three more, deterministic to measure but judgment to act on:
+Deterministic to measure, judgment to act on:
 
-- a description with **no boundary clause at all**;
+- a description with **no boundary clause at all** (`absent`);
+- an **arrow clause whose target could not be read** (`unparsed`);
+- an **arrow clause naming more than one target**;
 - a `## Gotchas` section with **more than five entries**;
 - a `## Gotchas` section over **25% of the body**.
 
+### Hand-invoked skills are exempt from the routing rules, and only those
+
+A skill or agent whose frontmatter carries `disable-model-invocation: true` skips three checks:
+
+- the boundary-clause check, `absent` and `unparsed` alike;
+- the multi-target arrow check;
+- the 250-character description **target** (`hand_invoked()` in `scripts/skill-size-check.sh`).
+
+It keeps the 400-character description FAIL and **both** body word tiers, and if its description
+does happen to name a target, that target is still resolved and can still dangle.
+
+Why the exemption is right: `disable-model-invocation: true` removes the skill from the
+model-visible listing entirely — it is not preloaded, and the Skill tool refuses to call it — so its
+description is never matched against user intent. ADR-0020 and `skill-author`'s contract therefore
+give such a skill **one plain human-facing sentence**: no trigger list, no boundary clause. No
+validator knew the field existed (**#108**), so the boundary-clause SUGGESTION fired on exactly the
+shape the contract mandates, and its remedy — "so the router knows where NOT to send this skill" —
+was addressed to a router that cannot see the skill at all. An author who followed the advice made
+the file worse. There is no router to inform.
+
+The half that does **not** lift is the point. The body is still loaded on invocation and still
+competes with the caller's live conversation, so neither body tier moves. The 400-character ceiling
+stands too: a hand-invoked description is not preloaded, but it is still the one line the user reads
+when choosing from the `/` menu, and that ceiling is an outlier stop rather than a routing-quality
+budget — which is precisely why the 250-character target is the tier that lifts.
+
+The field is read as a **boolean**, not as a mention of the key. PyYAML already resolves the
+unquoted YAML 1.1 booleans, so the extra handling catches a quoted `"true"`, which a host reads as
+truthy; `disable-model-invocation: false` is the model-invoked case written out longhand and buys
+nothing. A frontmatter parse failure returns false rather than raising — the flag is a *modifier* on
+other checks, and `description_value()` on the same text already reports the broken frontmatter, so
+raising here would diagnose one file twice two different ways.
+
+`caveman` and `zoom-out` are the two carriers here. `tests/test-skill-size-check.sh` pins both
+halves — what the carve-out lifts, each with a flag-removed control, and what it must not.
+
 ### `verbose: true` is load-bearing
 
 The hook is declared `verbose: true` so the SUGGESTION tier is audible. pre-commit prints nothing at
@@ -253,6 +391,10 @@ 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 in this repo.** `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
@@ -281,8 +423,10 @@ script.** `scripts/skill-size-check.sh` applies its body gate to whatever path i
 bash scripts/skill-size-check.sh plugins/*/.apm/agents/*.agent.md
 ```
 
-exits 1 today with 900-word body FAILs on `git-orchestrate` (933), `gitea-orchestrate` (1,199) and
-`apm-orchestrate` (1,080). Agent files escape only because the hook definitions filter on `SKILL.md`
+exits 1 today with 900-word body FAILs on `git-orchestrate` and `gitea-orchestrate`. (Counts are
+deliberately not pinned here — agent bodies are edited like any other file, and a figure in this
+paragraph goes stale the moment one is trimmed. Run the command.) Agent files escape only because
+the hook definitions filter on `SKILL.md`
 — a file-pattern accident that happens to implement the design, not the design itself. **Do not
 "extend" that hook's `files:` pattern to cover agents** on the assumption that the script already
 knows the difference; doing so silently enforces a gate ADR-0020 declines to set.
@@ -292,20 +436,39 @@ knows the difference; doing so silently enforces a gate ADR-0020 declines to set
 **The ADR-0020 gates ship hot, with no baseline file.** A shrinking baseline recording each
 non-compliant skill's current numbers was considered and rejected in favour of hot gates.
 
-Two independent hot gates are currently red, and the first will not warn you about the second.
+**The corpus is now clean on both gates.** Issue **#99** retrofitted all 39 skills plugin by plugin;
+`kyberforge` was the last wave, after which the corpus was swept as a whole rather than per plugin.
+Each sweep is followed by an **independent review round**: a fresh agent with no memory of the
+retrofit re-measures the corpus and files what it finds, and the round repeats until one lands no
+findings. The rounds are recorded as comments on **#99** — read the current state off that thread,
+which is why no round count is pinned here.
 
 | Gate | Current findings |
 |---|---|
-| `skill-size-check` | **26 of 39** descriptions and **9 of 39** bodies exceed their FAIL tier; 2 dangling targets; 58 SUGGESTIONs |
-| `Kyberforge.CompositionNote` (Vale) | **10 errors across four skills**: `gitea-issues`, `gitea-labels-milestones`, `gitea-prs`, `gitea-workflow` |
+| `skill-size-check` | **0 of 39** descriptions and **0 of 39** bodies exceed their FAIL tier; 0 dangling targets; SUGGESTIONs outstanding (count not pinned — see below) |
+| `Kyberforge.CompositionNote` (Vale) | **0 errors** — the four `gitea-*` carriers were all retrofitted |
+
+**The SUGGESTION count is deliberately not recorded here.** It moves with every skill edit *and*
+with every change to the gate's own tiering, so any figure written down is stale by the next commit.
+Measure it instead:
+
+```
+bash scripts/skill-size-check.sh plugins/*/.apm/skills/*/SKILL.md | grep -c '^SUGGESTION'
+pre-commit run skill-size-check --all-files    # same findings, via the hook
+```
+
+A non-zero count is the expected steady state, not a regression. SUGGESTIONs exit 0 and block
+nothing; only the two FAIL tiers, the dangling-target ERROR and the missing-`references/` ERROR do.
+Read the count as a work queue, and the FAIL columns above as the gate.
 
 `Kyberforge.CompositionNote` is the ADR-0020 Vale rule banning composition and architecture prose
-from a description. Every Vale rule here is `level: error` with no ignorable tier, so touching any of
-those four skills means fixing its prose findings as well as its size findings.
+from a description. Every Vale rule here is `level: error` with no ignorable tier, so a description
+that reintroduces one blocks the commit even though no skill carries one today.
 
-Consequence: editing a non-compliant skill *for any reason* means retrofitting it to the contract
-first — a one-line fix to `gitea-prs` cannot be committed until that skill complies. This is
-deliberate; it guarantees convergence and avoids a half-state. Tracked as Gitea issue **#99**.
+Because nothing is grandfathered, the gates now bite on **first commit**: a new skill, or an edit
+that pushes a description past 400 characters or a body past 900 words, is blocked until it
+complies. That is the steady state the retrofit was for — it is no longer true that an unrelated
+one-line fix to a skill requires retrofitting that skill first.
 
 Check where a skill stands before starting, and check **both** gates:
 
@@ -316,6 +479,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),
@@ -434,6 +682,35 @@ passing one explicit file per invocation. The two manifests scope **differently
 Narrowing a `.vale.ini` glob to a `plugins/`-shaped path to "tighten" it breaks the consumer case,
 and `check-vale-style-sync`'s probe set is built to catch exactly that.
 
+### The blind spot: `references/` is unlinted, for two independent reasons
+
+Every `references/*.md` file in the corpus is outside the prose gate. Count them with
+`git ls-files | grep -cE '^plugins/[^/]+/\.apm/skills/[^/]+/references/.*\.md$'` rather than reading
+a figure here; it moves with every retrofit. This is the gap that matters most, because the context
+contract's own remedy for an over-long body is to move prose **into** `references/` — the gate pushes
+text across its own boundary and then stops watching it.
+
+**Closing either cause alone changes nothing.** There are two, and they are independent:
+
+| Cause | Where | Effect on a `references/` file |
+|---|---|---|
+| the `Kyberforge` style is scoped `[**/SKILL.md]` | `skill-audit/assets/vale/.vale.ini` | matches no section, so Vale lints 0 files and exits 0 |
+| the hook's `files:` regex is `^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$` | `vale-audit-prefilter-skill` in `.pre-commit-config.yaml` | the file is never handed to Vale at all |
+
+Verified both ways. Handing skill-audit's `vale-wrap.sh` a reference file directly — bypassing
+pre-commit entirely, so only the style scope is in play — prints `0 errors … in 0 files` and exits 0,
+where the same wrapper on a `SKILL.md` reports `in 1 file`. And the hook's `files:` regex, applied to
+`git ls-files`, selects only the skill-directory `SKILL.md` files scoped at the top of this page, so
+pre-commit never hands Vale a reference file to begin with. Widening the glob to `[**/*.md]` would
+still lint nothing through the hook; widening the hook's `files:` alone would hand Vale files its own
+config declines to match, which is the [0-file NOT RUN](#a-0-file-vale-run-is-not-run) shape — a
+green run that measured nothing. **Issue #117** records the style-scope half; the hook half has to
+land in the same change or the fix is cosmetic.
+
+The consumer manifest is a third axis and does not rescue this either: `.pre-commit-hooks.yaml`'s
+`(^|/)SKILL\.md$` is layout-agnostic but still filename-shaped, so an external repo running
+`kyberforge-vale-audit-skill` has the same gap.
+
 ### `vale-wrap.sh`, never bare `vale`
 
 Both audit skills' Step 1 and both pre-commit hooks call **each copy's own**

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

@@ -1,17 +1,18 @@
 ---
 name: caveman
+disable-model-invocation: true
 description: >
-  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
-  filler, articles, and pleasantries while keeping full technical accuracy.
-  Use when user says "caveman mode", "talk like caveman", "use caveman",
-  "less tokens", "be brief", or invokes /caveman.
+  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.
 
 ## Persistence
 
-ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
+ACTIVE EVERY RESPONSE once user type `/caveman`. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
 
 ## Rules
 

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

@@ -1,13 +1,18 @@
 ---
 name: diagnose
-description: Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
+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.1"
 ---
 
 # Diagnose
 
 A discipline for hard bugs. Skip phases only when explicitly justified.
 
-When exploring the codebase, use the project's domain glossary to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
+When exploring the codebase, use the domain glossary for a clear mental model of the relevant modules, and check ADRs in the area.
 
 ## Phase 1 — Build a feedback loop
 
@@ -15,40 +20,11 @@ When exploring the codebase, use the project's domain glossary to get a clear me
 
 Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give up.**
 
-### Ways to construct one — try them in roughly this order
+**If you do not yet have such a signal, read `references/feedback-loops.md`** — ten ways to build one ordered by cost, and what to ask the user for when the bug resists reproduction entirely.
 
-1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
-2. **Curl / HTTP script** against a running dev server.
-3. **CLI invocation** with a fixture input, diffing stdout against a known-good snapshot.
-4. **Headless browser script** (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network.
-5. **Replay a captured trace.** Save a real network request / payload / event log to disk; replay it through the code path in isolation.
-6. **Throwaway harness.** Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug code path with a single function call.
-7. **Property / fuzz loop.** If the bug is "sometimes wrong output", run 1000 random inputs and look for the failure mode.
-8. **Bisection harness.** If the bug appeared between two known states (commit, dataset, version), automate "boot at state X, check, repeat" so you can `git bisect run` it.
-9. **Differential loop.** Run the same input through old-version vs new-version (or two configs) and diff outputs.
-10. **HITL bash script.** Last resort. If a human must click, drive _them_ with `scripts/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you.
+**If you do have one, it is probably not sharp enough yet.** Make it faster and more deterministic, and make it assert on the exact symptom rather than "didn't crash" — a 30-second flaky loop is barely better than no loop. If it stays slow or intermittent after that, read that file's "Iterate on the loop itself" and "Intermittent bugs" sections.
 
-Build the right feedback loop, and the bug is 90% fixed.
-
-### Iterate on the loop itself
-
-Treat the loop as a product. Once you have _a_ loop, ask:
-
-- Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
-- Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
-- Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
-
-A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
-
-### Non-deterministic bugs
-
-The goal is not a clean repro but a **higher reproduction rate**. Loop the trigger 100×, parallelise, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
-
-### When you genuinely cannot build a loop
-
-Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
-
-Do not proceed to Phase 2 until you have a loop you believe in.
+Do not proceed to Phase 2 until you have a loop you believe in. If you cannot build one, stop and say so explicitly, listing what you tried — never hypothesise without a signal.
 
 ## Phase 2 — Reproduce
 
@@ -57,7 +33,7 @@ Run the loop. Watch the bug appear.
 Confirm:
 
 - [ ] The loop produces the failure mode the **user** described — not a different failure that happens to be nearby. Wrong bug = wrong fix.
-- [ ] The failure is reproducible across multiple runs (or, for non-deterministic bugs, reproducible at a high enough rate to debug against).
+- [ ] The failure is reproducible across multiple runs. If it is intermittent, `references/feedback-loops.md` defines the rate high enough to debug against — go back to Phase 1 and raise it.
 - [ ] You have captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix actually addresses it.
 
 Do not proceed until you reproduce the bug.
@@ -90,19 +66,17 @@ Tool preference:
 
 ## Phase 5 — Fix + regression test
 
-Write the regression test **before the fix** — but only if there is a **correct seam** for it.
+Write the regression test **before the fix** — but only at a **correct seam**: one where the test exercises the real bug pattern as it occurs at the call site. If the available seam looks too shallow, or you cannot tell whether it is, read `references/regression-seams.md`.
 
-A correct seam is one where the test exercises the **real bug pattern** as it occurs at the call site. If the only available seam is too shallow (single-caller test when the bug needs multiple callers, unit test that can't replicate the chain that triggered the bug), a regression test there gives false confidence.
+**If no correct seam exists, that itself is the finding.** Note it and carry it into Phase 6 — the architecture is preventing the bug from being locked down.
 
-**If no correct seam exists, that itself is the finding.** Note it. The codebase architecture is preventing the bug from being locked down. Flag this for the next phase.
+At a correct seam:
 
-If a correct seam exists:
-
-1. Turn the minimised repro into a failing test at that seam.
+1. Turn the Phase 1 loop into a failing test at that seam, narrowed to the symptom captured in Phase 2.
 2. Watch it fail.
 3. Apply the fix.
 4. Watch it pass.
-5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.
+5. Re-run the Phase 1 feedback loop against the original, un-narrowed scenario.
 
 ## Phase 6 — Cleanup + post-mortem
 

plugins/bin/.apm/skills/diagnose/references/feedback-loops.md

@@ -0,0 +1,40 @@
+# Constructing and sharpening a feedback loop
+
+A feedback loop is a fast, deterministic, agent-runnable pass/fail signal for the bug. Build the right one and the bug is 90% fixed. This file covers the whole arc: building a loop, sharpening one you already have, and escalating when the bug resists reproduction.
+
+## Ways to construct one — try them in roughly this order
+
+1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
+2. **Curl / HTTP script** against a running dev server.
+3. **CLI invocation** with a fixture input, diffing stdout against a known-good snapshot.
+4. **Headless browser script** (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network.
+5. **Replay a captured trace.** Save a real network request / payload / event log to disk; replay it through the code path in isolation.
+6. **Throwaway harness.** Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug code path with a single function call.
+7. **Property / fuzz loop.** If the bug is "sometimes wrong output", run 1000 random inputs and look for the failure mode.
+8. **Bisection harness.** If the bug appeared between two known states (commit, dataset, version), automate "boot at state X, check, repeat" so you can `git bisect run` it.
+9. **Differential loop.** Run the same input through old-version vs new-version (or two configs) and diff outputs.
+10. **HITL bash script.** Last resort. If a human must click, drive _them_ with `assets/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you.
+
+## Iterate on the loop itself
+
+Treat the loop as a product. Once you have _a_ loop, ask:
+
+- Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
+- Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
+- Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
+
+A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
+
+## Intermittent bugs — raise the reproduction rate
+
+If the loop only sometimes fails, the goal is not a clean repro but a **higher reproduction rate**. Loop the trigger 100×, parallelise, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
+
+## When you genuinely cannot build a loop
+
+Stop and say so explicitly. List what you tried. Ask the user for:
+
+- access to whatever environment reproduces it,
+- a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or
+- permission to add temporary production instrumentation.
+
+Do **not** proceed to hypothesise without a loop. A hypothesis you cannot falsify against a signal is a guess, and the fix that follows it is unverifiable.

plugins/bin/.apm/skills/diagnose/references/regression-seams.md

@@ -0,0 +1,24 @@
+# Judging a regression-test seam
+
+Read this when Phase 5 leaves you unsure whether the seam available for the regression test is the correct one — either because the obvious seam looks shallow, or because there appears to be no seam at all.
+
+## What makes a seam correct
+
+A correct seam is one where the test exercises the **real bug pattern** as it occurs at the call site: the same entry point, the same participants, the same ordering, and the same state the real caller holds when it goes wrong.
+
+## Seams that are too shallow
+
+- A single-caller test when the bug only appears with multiple callers.
+- A unit test that cannot replicate the chain of calls that triggered the bug.
+- A test that reproduces the symptom by construction — asserting on a value the test itself set — rather than by driving the code path that produces it.
+- A test that mocks out the collaborator the bug actually lives in.
+
+A regression test at a shallow seam gives false confidence. It passes forever, including after a change reintroduces the bug at the real call site, and it will be read by the next maintainer as proof the bug is locked down.
+
+## When there is no correct seam
+
+Do not force one, and do not settle for a shallow seam to have something green. Instead:
+
+1. Apply the fix and verify it against the Phase 1 loop directly.
+2. Write down which seams you considered and why each was too shallow.
+3. Carry that into Phase 6's "what would have prevented this bug" question. A missing seam is an architecture finding — tangled callers, hidden coupling, or a module with no testable boundary — and the handoff is the `improve-codebase-architecture` skill, with those specifics attached.

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

@@ -1,6 +1,12 @@
 ---
 name: grill-me
-description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+description: >
+  Use when the user says "grill me" or wants a plan or design stress-tested by
+  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

@@ -1,6 +1,11 @@
 ---
 name: grill-with-docs
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+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>
@@ -71,7 +76,7 @@ When the user states how something works, check whether the code agrees. If you
 
 ### Update CONTEXT.md inline
 
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [context-format.md](references/context-format.md).
 
 Don't couple `CONTEXT.md` to implementation details. Only include terms that are meaningful to domain experts.
 
@@ -83,6 +88,6 @@ Only offer to create an ADR when all three are true:
 2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
 
-If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+If any of the three is missing, skip the ADR. Use the format in [adr-format.md](references/adr-format.md).
 
 </supporting-info>

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

@@ -1,6 +1,13 @@
 ---
 name: improve-codebase-architecture
-description: Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
+description: >
+  Use when the user wants to improve architecture, find refactoring
+  opportunities, consolidate tightly-coupled modules, or make a codebase more
+  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.1"
 ---
 
 # Improve Codebase Architecture
@@ -9,7 +16,7 @@ Surface architectural friction and propose **deepening opportunities** — refac
 
 ## Glossary
 
-Use these terms exactly in every suggestion. Consistent language is the point — don't drift into "component," "service," "API," or "boundary." Full definitions in [LANGUAGE.md](LANGUAGE.md).
+Use these terms exactly in every suggestion. Consistent language is the point — don't drift into "component," "service," "API," or "boundary."
 
 - **Module** — anything with an interface and an implementation (function, class, package, slice).
 - **Interface** — everything a caller must know to use the module: types, invariants, error modes, ordering, config. Not just the type signature.
@@ -20,19 +27,21 @@ Use these terms exactly in every suggestion. Consistent language is the point
 - **Leverage** — what callers get from depth.
 - **Locality** — what maintainers get from depth: change, bugs, knowledge concentrated in one place.
 
-Key principles (see [LANGUAGE.md](LANGUAGE.md) for the full list):
+Key principles:
 
 - **Deletion test**: imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.
 - **The interface is the test surface.**
 - **One adapter = hypothetical seam. Two adapters = real seam.**
 
+If a term or principle above is ambiguous in the case in front of you, or you need the definitions and the principles the two lists leave out, read `references/language.md`.
+
 This skill is _informed_ by the project's domain model. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate.
 
 ## Process
 
 ### 1. Explore
 
-Read the project's domain glossary and any ADRs in the area you're touching first.
+Read the domain glossary and any ADRs in the area first.
 
 Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
 
@@ -53,7 +62,7 @@ Present a numbered list of deepening opportunities. For each candidate:
 - **Solution** — plain English description of what would change
 - **Benefits** — explained in terms of locality and leverage, and also in how tests would improve
 
-**Use CONTEXT.md vocabulary for the domain, and [LANGUAGE.md](LANGUAGE.md) vocabulary for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
+**Use CONTEXT.md vocabulary for the domain, and the architecture glossary above for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
 
 **ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly (e.g. _"contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
 
@@ -65,7 +74,7 @@ Once the user picks a candidate, drop into a grilling conversation. Walk the des
 
 Side effects happen inline as decisions crystallize:
 
-- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md` — same discipline as `/grill-with-docs` (see [CONTEXT-FORMAT.md](../grill-with-docs/CONTEXT-FORMAT.md)). Create the file lazily if it doesn't exist.
+- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md` — same discipline as `grill-with-docs`, in the format `grill-with-docs`'s `references/context-format.md` defines. Create the file lazily if it doesn't exist.
 - **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.
-- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones. See [ADR-FORMAT.md](../grill-with-docs/ADR-FORMAT.md).
-- **Want to explore alternative interfaces for the deepened module?** See [INTERFACE-DESIGN.md](INTERFACE-DESIGN.md).
+- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones. See `grill-with-docs`'s `references/adr-format.md`.
+- **Want to explore alternative interfaces for the deepened module?** Read `references/interface-design.md`.

plugins/bin/.apm/skills/improve-codebase-architecture/references/deepening.md

@@ -1,6 +1,6 @@
 # Deepening
 
-How to deepen a cluster of shallow modules safely, given its dependencies. Assumes the vocabulary in [LANGUAGE.md](LANGUAGE.md) — **module**, **interface**, **seam**, **adapter**.
+How to deepen a cluster of shallow modules safely, given its dependencies. Assumes the vocabulary in [language.md](language.md) — **module**, **interface**, **seam**, **adapter**.
 
 ## Dependency categories
 

plugins/bin/.apm/skills/improve-codebase-architecture/references/interface-design.md

@@ -2,7 +2,7 @@
 
 When the user wants to explore alternative interfaces for a chosen deepening candidate, use this parallel sub-agent pattern. Based on "Design It Twice" (Ousterhout) — your first idea is unlikely to be the best.
 
-Uses the vocabulary in [LANGUAGE.md](LANGUAGE.md) — **module**, **interface**, **seam**, **adapter**, **leverage**.
+Uses the vocabulary in [language.md](language.md) — **module**, **interface**, **seam**, **adapter**, **leverage**.
 
 ## Process
 
@@ -11,7 +11,7 @@ Uses the vocabulary in [LANGUAGE.md](LANGUAGE.md) — **module**, **interface**,
 Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
 
 - The constraints any new interface would need to satisfy
-- The dependencies it would rely on, and which category they fall into (see [DEEPENING.md](DEEPENING.md))
+- The dependencies it would rely on, and which category they fall into (see [deepening.md](deepening.md))
 - A rough illustrative code sketch to ground the constraints — not a proposal, just a way to make the constraints concrete
 
 Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
@@ -20,21 +20,21 @@ Show this to the user, then immediately proceed to Step 2. The user reads and th
 
 Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
 
-Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
+Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [deepening.md](deepening.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
 
 - Agent 1: "Minimize the interface — aim for 1–3 entry points max. Maximise leverage per entry point."
 - Agent 2: "Maximise flexibility — support many use cases and extension."
 - Agent 3: "Optimise for the most common caller — make the default case trivial."
 - Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
 
-Include both [LANGUAGE.md](LANGUAGE.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
+Include both [language.md](language.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
 
 Each sub-agent outputs:
 
 1. Interface (types, methods, params — plus invariants, ordering, error modes)
 2. Usage example showing how callers use it
 3. What the implementation hides behind the seam
-4. Dependency strategy and adapters (see [DEEPENING.md](DEEPENING.md))
+4. Dependency strategy and adapters (see [deepening.md](deepening.md))
 5. Trade-offs — where leverage is high, where it's thin
 
 ### 3. Present and compare

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

@@ -1,6 +1,12 @@
 ---
 name: prototype
-description: Build a throwaway prototype to flush out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
+description: >
+  Use when the user wants a throwaway prototype to answer a design question about
+  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
@@ -9,10 +15,12 @@ A prototype is **throwaway code that answers a question**. The question decides
 
 ## Pick a branch
 
-Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around:
+| Question being answered | Build | Reference |
+|---|---|---|
+| "Does this logic / state model feel right?" | A tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper | `references/logic.md` |
+| "What should this look like?" | Several radically different UI variations on one route, switchable via a URL search param and a floating bottom bar | `references/ui.md` |
 
-- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper.
-- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
+Resolve the row from the user's prompt, the surrounding code, or by asking if the user is around, then read only that reference — each is self-contained.
 
 The two branches produce fundamentally different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
 

plugins/bin/.apm/skills/prototype/references/logic.md

@@ -9,7 +9,7 @@ A tiny interactive terminal app that lets the user drive a state model by hand.
 - "I want to feel out what the API should look like before writing it."
 - Anything where the user wants to **press buttons and watch state change**.
 
-If the question is "what should this look like" — wrong branch. Use [UI.md](UI.md).
+If the question is "what should this look like" — wrong branch. Read `references/ui.md`.
 
 ## Process
 

plugins/bin/.apm/skills/prototype/references/ui.md

@@ -2,7 +2,7 @@
 
 Generate **several radically different UI variations** on a single route, switchable from a floating bottom bar. The user flips between variants in the browser, picks one (or steals bits from each), then throws the rest away.
 
-If the question is about logic/state rather than what something looks like — wrong branch. Use [LOGIC.md](LOGIC.md).
+If the question is about logic/state rather than what something looks like — wrong branch. Read `references/logic.md`.
 
 ## When this is the right shape
 

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

@@ -1,15 +0,0 @@
-```yaml
-version: "1.1"
-updated: 2026-06-21
-
-when: >-
-  Invoked when the user wants to gather structured reference documentation for a
-  tool, library, or API from MCP documentation indexes or web sources. Typically
-  run before writing a new skill that wraps an external tool, or any time
-  reference files are needed for a topic. Triggered explicitly
-  ("/research <topic> <path>") or implicitly when the user asks to look up,
-  gather, or pull docs for a topic before implementing something.
-
-references:
-  - .agents/skills/context7-mcp/SKILL.md  # context7-mcp — MCP source channel integrated at step 2
-```

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

@@ -1,97 +1,79 @@
 ---
 name: research
 description: >-
-  Use when the user wants to research a topic and generate structured reference
-  markdown files. Handles: finding canonical docs for a tool/library/API via
-  Context7 MCP or web sources, reading and deepening into linked pages,
-  organizing extracted content into topic files (overview, installation,
-  configuration, cli-reference, api-reference, examples, troubleshooting). Do
-  NOT use when the user wants to write documentation from existing code or specs
-  (use write-docs), install or manage the neuledge-context MCP server (use
-  neuledge-context), or research a bug/incident (use diagnose).
+  Use when the user wants a tool, library, or API researched from canonical
+  documentation into structured per-topic reference markdown files. Not
+  documentation written from existing code or specs -> `write-docs`. Not a bug
+  or incident -> `diagnose`.
 metadata:
+  version: "1.0.0"
   category: research
 allowed-tools:
-  - WebSearch
-  - WebFetch
+  - Grep
+  - Glob
   - Read
   - Write
+  - WebSearch
+  - WebFetch
   - mcp__context7__resolve-library-id
   - mcp__context7__query-docs
 model: sonnet
 ---
 
-<requirements>
+## Gotchas
 
-## Required inputs
+- Never infer the output path. A run writes a directory's worth of files, and a guessed destination scatters them through someone's source tree. If the user named no path, stop and ask.
+- Write nothing outside the given output path. A file placed beside the agreed directory is one the user never asked for and will not think to look for.
+- Never write an empty topic file. A stub `troubleshooting.md` reads downstream as researched and closed.
+- A Context7 response that is a "no results" message, a redirect notice, or header-only boilerplate is not coverage. A topic area counts as covered only when the response carries at least one substantive paragraph.
 
-- **Topic** — the subject to research (tool, library, API, concept); inferred from user description if clear, ask if ambiguous
-- **Output path** — directory where reference files will be written; must be provided explicitly — do not infer or default
-- **Starting URLs** — optional; if provided, skip discovery websearch and read these first
+## Step 1 — Scope against the working directory
 
-## Constraints
+Search for existing use of the topic — imports, config files, version pins, reference files already written — and narrow the research to what is missing: the version actually in use, the topics not yet documented.
 
-- Never write files outside the explicitly provided output path
-- Skip any default topic file if no relevant content is found for it — do not create empty files
-- Create additional topic files beyond the default list when content warrants it (e.g. `webhooks.md`, `rate-limits.md`)
-- Subagents handle parallel source reading and link deepening — the orchestrator writes all files; subagents return summaries only, never write directly
-- Context7 MCP calls (`resolve-library-id`, `query-docs`) are made only by the orchestrator at step 2 — subagents must not call them
-- `sources.md` is always written, even if only one source was read
-- Each topic file must have frontmatter with `topic` and `source_keys`; body is prose only — no inline URLs
-- Source keys in `sources.md` must be kebab-case slugs: derived from the source domain or page title for web sources; for Context7 sources use `context7-<library-slug>` (e.g. `context7-vercel-next-js`)
-- Default topic list and file format spec live in `references/` sub-files — read them at step 1
+The default topic areas are `overview`, `installation`, `configuration`, `cli-reference`,
+`api-reference`, `examples` and `troubleshooting` — one file each, and only where content exists.
+If what belongs in one of them is unclear, or the topic needs a file outside that set, read
+`references/topics.md` for the per-topic coverage table and the custom-topic naming rule.
 
-</requirements>
+## Step 2 — Resolve against Context7
 
-<steps>
+If the topic is a library, framework, or API and the user gave no starting URLs, call `resolve-library-id` with the topic name and the user's full question — match quality depends on the question, not the bare name — then `query-docs` once per default topic area. Record each response as a source with slug `context7-<library-slug>`, and mark which topic areas it covered — those skip the web reads at step 4.
 
-## Process
+If the library does not resolve, or the user gave starting URLs, go to step 3. Explicit URLs are a source choice; do not second-guess them with a resolution attempt.
 
-1. **Scan codebase.** Search the working directory for existing usage of the topic — imports, config files, version pins, existing reference files. Use findings to narrow research scope (e.g. target the version already in use, skip topics already documented). Read `references/topics.md` for the default topic list and `references/file-format.md` for the output file format spec.
+## Step 3 — Discover sources
 
-2. **Try Context7.** If the topic is a library, framework, or API and no starting URLs were provided, call `resolve-library-id` with the topic name and the user's question. If a match resolves, call `query-docs` once per default topic area (see `references/topics.md`). Treat each response as a source summary with slug `context7-<library-slug>` (e.g. `context7-vercel-next-js`). A topic area has sufficient content when the Context7 response contains at least one substantive paragraph — not a "no results" message, redirect notice, or header-only boilerplate. Mark covered topic areas — skip their subagent web reads in step 4. If the library does not resolve, or starting URLs were provided (explicit source choice by the user), skip this step entirely.
+If the user gave starting URLs, skip discovery: those URLs are the source list and go straight to step 4.
 
-3. **Discover sources.** For topics not covered by Context7 (or when no starting URLs were provided and Context7 did not resolve), websearch for canonical documentation (prefer `llms.txt`, developer docs, official API references over tutorials or blog posts). Collect 3–5 candidate URLs before reading any.
+Otherwise, for every topic area Context7 did not cover, websearch for canonical documentation — `llms.txt`, official developer docs, and API references ahead of tutorials or blog posts. Collect three to five candidate URLs before reading any of them.
 
-4. **Read sources in parallel.** Spawn one subagent per source URL. Each subagent fetches the page, extracts relevant content, identifies links worth deepening, and returns a structured summary (content by topic area + links to follow). Subagents do not write files.
+If nothing usable comes back, stop and report what was searched, then ask for starting URLs rather than settling for tutorials.
 
-5. **Deepen.** For each subagent that returned links worth following, spawn child subagents per branch. Continue until content becomes repetitive or out of scope. Cap at ~10 additional pages total across all branches.
+## Step 4 — Read the sources
 
-6. **Consolidate.** Merge all subagent summaries (Context7 and web) by topic area. Identify which default topics have sufficient content and which custom topics emerged.
+`WebFetch` each URL in turn. No subagent tool is granted here, so the reads are serial and every fetched page lands in this context: reduce each page to notes by topic area, plus the links worth deepening, before fetching the next one.
 
-7. **Write topic files.** For each topic with content, write `<output-path>/<topic>.md` using the format in `references/file-format.md`. Orchestrator writes all files — never delegate file writing to a subagent.
+## Step 5 — Deepen
 
-8. **Write `sources.md`.** Write `<output-path>/sources.md` mapping each source slug to its URL (use `context7:<library-id>` as the URL for Context7 sources), description, and list of topic files it contributed to. Include sources that yielded no content, marked `no content extracted`.
+`WebFetch` the links worth following, still one at a time and still reducing each page to notes. Stop a branch once its content turns repetitive or leaves the topic, and cap the whole step at roughly ten additional pages — serial reads make that cap a real budget, not a formality.
 
-## Output format
+## Step 6 — Write
 
-- `<output-path>/<topic>.md` per topic with content — formatted per `references/file-format.md`
-- `<output-path>/sources.md` — always produced; maps slug → URL, description, contributing files
+Merge every set of notes, Context7 and web alike, by topic area, then write, in the output path:
 
-</steps>
+- `<topic>.md` for each topic area that has content, default or custom. Frontmatter carries `topic:` (the filename without `.md`) and `source_keys:` (kebab-case slugs matching `sources.md`); the body is prose in `##` sections, with no inline URLs.
+- `sources.md`, always, one `##` section per source — including sources that yielded nothing — with exactly these four fields:
 
-<checks>
+  ```markdown
+  - **URL:** <full URL>
+  - **Description:** <one-line summary>
+  - **Contributing files:** <topic files this source contributed to>
+  - **Status:** `extracted` | `no content extracted`
+  ```
 
-## Failure handling
+Spell those four field names exactly as given. The downstream provenance validator matches them literally; prose in their place parses as nothing, and the check passes having verified nothing.
 
-- Output path not provided — stop and ask; do not infer or default
-- No sources found after websearch — report what was searched, ask user to provide starting URLs
-- Subagent returns no usable content — skip that source, log in `sources.md` as `no content extracted`
-- All topic files would be empty — stop, report what was searched, do not write any files
+Read `references/file-format.md` when the four fields above do not settle the case: what a slug should be, the `context7-<library-slug>` slug and `context7:<library-id>` URL convention for a Context7 source, or what belongs in a topic body versus a verbatim copy of the source.
 
-## Self-check
-
-- [ ] Codebase scanned before any websearch was performed
-- [ ] Output path was explicitly provided — not inferred
-- [ ] `references/topics.md` and `references/file-format.md` read at step 1
-- [ ] Context7 resolution attempted before websearch when topic is a library/framework/API
-- [ ] Context7 calls made only at orchestrator step 2 — no subagent called `resolve-library-id` or `query-docs`
-- [ ] Context7 sources recorded in `sources.md` with `context7:<library-id>` as URL
-- [ ] No topic file written without content
-- [ ] `sources.md` written with all sources read (including those with no content extracted)
-- [ ] All file writes performed by the orchestrator, not subagents
-- [ ] Each topic file has `topic` and `source_keys` frontmatter fields
-- [ ] All source keys in topic files have a matching entry in `sources.md`
-- [ ] No files written outside the provided output path
-
-</checks>
+If no topic area has content, write nothing at all, `sources.md` included, and report what was searched.

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

@@ -1,6 +1,11 @@
 ---
 name: tdd
-description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
+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.1"
 ---
 
 # Test-Driven Development
@@ -13,7 +18,7 @@ description: Test-driven development with red-green-refactor loop. Use when user
 
 **Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
 
-See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
+If you need worked examples of the difference — a behaviour-level test beside the implementation-coupled version of the same check — read `references/tests.md`. If a test needs a collaborator faked, read `references/mocking.md` before reaching for a mock.
 
 ## Anti-Pattern: Horizontal Slices
 
@@ -44,14 +49,14 @@ RIGHT (vertical):
 
 ### 1. Planning
 
-When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.
+When exploring the codebase, use the domain glossary so test names and interface vocabulary match the project's language, and respect ADRs in the area.
 
 Before writing any code:
 
 - [ ] Confirm with user what interface changes are needed
 - [ ] Confirm with user which behaviors to test (prioritize)
-- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
-- [ ] Design interfaces for [testability](interface-design.md)
+- [ ] Identify opportunities for [deep modules](references/deep-modules.md) (small interface, deep implementation)
+- [ ] Design interfaces for [testability](references/interface-design.md)
 - [ ] List the behaviors to test (not implementation steps)
 - [ ] Get user approval on the plan
 
@@ -88,7 +93,7 @@ Rules:
 
 ### 4. Refactor
 
-After all tests pass, look for [refactor candidates](refactoring.md):
+After all tests pass, look for [refactor candidates](references/refactoring.md):
 
 - [ ] Extract duplication
 - [ ] Deepen modules (move complexity behind simple interfaces)

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

@@ -1,6 +1,11 @@
 ---
 name: triage
-description: Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
+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.1"
 ---
 
 # Triage
@@ -15,8 +20,8 @@ Every comment or issue posted to the issue tracker during triage **must** start
 
 ## Reference docs
 
-- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs
-- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope/` knowledge base works
+- [agent-brief.md](references/agent-brief.md) — how to write durable agent briefs
+- [out-of-scope.md](references/out-of-scope.md) — how the `.out-of-scope/` knowledge base works
 
 ## Roles
 
@@ -35,7 +40,7 @@ Five **state** roles:
 
 Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
 
-These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you - run `/setup-matt-pocock-skills` if not.
+These are canonical role names — the actual label strings used in the issue tracker may differ. Resolve each canonical name against the tracker's live label set before applying it, using whichever tracker skill this install provides. If a name has no counterpart there, report the gap and ask the maintainer for the mapping — never substitute a guess.
 
 State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
 
@@ -60,7 +65,7 @@ Show counts and a one-line summary per issue. Let the maintainer pick.
 
 ## Triage a specific issue
 
-1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
+1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
 
 2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
 
@@ -69,11 +74,11 @@ Show counts and a one-line summary per issue. Let the maintainer pick.
 4. **Grill (if needed).** If the issue needs fleshing out, run a `/grill-with-docs` session.
 
 5. **Apply the outcome:**
-   - `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).
+   - `ready-for-agent` — post an agent brief comment ([agent-brief.md](references/agent-brief.md)).
    - `ready-for-human` — same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).
    - `needs-info` — post triage notes (template below).
    - `wontfix` (bug) — polite explanation, then close.
-   - `wontfix` (enhancement) — write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).
+   - `wontfix` (enhancement) — write to `.out-of-scope/`, link to it from a comment, then close ([out-of-scope.md](references/out-of-scope.md)).
    - `needs-triage` — apply the role. Optional comment if there's partial progress.
 
 ## Quick state override

plugins/bin/.apm/skills/triage/references/agent-brief.md

@@ -1,6 +1,6 @@
 # Writing Agent Briefs
 
-An agent brief is a structured comment posted on a GitHub issue when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original issue body and discussion are context — the agent brief is the contract.
+An agent brief is a structured comment posted on an issue in the issue tracker when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original issue body and discussion are context — the agent brief is the contract.
 
 ## Principles
 
@@ -27,7 +27,7 @@ Describe **what** the system should do, not **how** to implement it. The agent w
 
 The agent needs to know when it's done. Every agent brief must have concrete, testable acceptance criteria. Each criterion should be independently verifiable.
 
-- **Good:** "Running `gh issue list --label needs-triage` returns issues that have been through initial classification"
+- **Good:** "Querying the issue tracker for the `needs-triage` label returns issues that have been through initial classification"
 - **Bad:** "Triage should work correctly"
 
 ### Explicit scope boundaries

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

@@ -1,10 +1,15 @@
 ---
 name: write-docs
-description: Write documentation for X, document this module, create docs for this feature. Use when the user wants to produce or update technical documentation derived from code, spec, or existing artifacts. Do NOT use when the user wants a PRD, ADR, decision doc, or skill file — those have dedicated skills.
-version: "1.0"
+description: >
+  Use when the user wants technical documentation produced or updated from code
+  or spec, every claim traced to a source — "write docs for X", "document this
+  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`.
 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
@@ -35,7 +40,8 @@ You are a technical writer that produces documentation by reading code and spec
 - User says "write docs for X", "document this", "create docs for this feature", "write a README for this"
 
 **Do not use when:**
-- User wants a PRD, decision doc, or architecture proposal → `to-prd` or `grill-me`
+- User wants an ADR, decision doc, or architecture proposal → `grill-with-docs`, which writes ADRs
+- User wants a PRD → no skill in this set produces one; say so rather than redirecting
 - User wants to document a skill file (skill files are self-describing)
 - User wants marketing or blog copy
 - Documentation requires tacit organisational knowledge that cannot be read from code or spec
@@ -88,7 +94,7 @@ You are a technical writer that produces documentation by reading code and spec
 - Stage skipped without a logged reason → flag and require the one-sentence log before continuing
 - Code behaviour is undocumentable (internal implementation detail, no public spec) → note as out-of-scope in the doc; do not invent an explanation
 - Reader Testing sub-agent fails on multiple questions → surface the failures, return to step 4; do not mark complete
-- Requested output is a PRD, decision doc, or architecture proposal → redirect to `to-prd`, `grill-me`, or `grill-with-docs`
+- Requested output is an ADR, decision doc, or architecture proposal → redirect to `grill-with-docs`; for a PRD, say no skill here produces one instead of redirecting
 
 ## Self-check
 

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.1"
 ---
 
-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.
+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.

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

@@ -1,6 +1,6 @@
 {
   "name": "bin",
-  "version": "1.1.5",
+  "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.5",
+  "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.5
+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/evals/research/research/eval.yaml

@@ -26,11 +26,6 @@ trigger_tests:
     query: "Research why these integration tests are failing"
     should_trigger: false
 
-  - id: negative-neuledge
-    name: "Negative — MCP server setup goes to neuledge-context"
-    query: "Install the neuledge context server and set it up"
-    should_trigger: false
-
   - id: negative-context7-direct-question
     name: "Negative — direct doc question goes to context7-mcp, not research"
     query: "What are the Next.js middleware options?"

plugins/bin/skills/caveman/SKILL.md

@@ -1,17 +1,18 @@
 ---
 name: caveman
+disable-model-invocation: true
 description: >
-  Ultra-compressed communication mode. Cuts token usage ~75% by dropping
-  filler, articles, and pleasantries while keeping full technical accuracy.
-  Use when user says "caveman mode", "talk like caveman", "use caveman",
-  "less tokens", "be brief", or invokes /caveman.
+  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.
 
 ## Persistence
 
-ACTIVE EVERY RESPONSE once triggered. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
+ACTIVE EVERY RESPONSE once user type `/caveman`. No revert after many turns. No filler drift. Still active if unsure. Off only when user says "stop caveman" or "normal mode".
 
 ## Rules
 

plugins/bin/skills/diagnose/SKILL.md

@@ -1,13 +1,18 @@
 ---
 name: diagnose
-description: Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.
+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.1"
 ---
 
 # Diagnose
 
 A discipline for hard bugs. Skip phases only when explicitly justified.
 
-When exploring the codebase, use the project's domain glossary to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
+When exploring the codebase, use the domain glossary for a clear mental model of the relevant modules, and check ADRs in the area.
 
 ## Phase 1 — Build a feedback loop
 
@@ -15,40 +20,11 @@ When exploring the codebase, use the project's domain glossary to get a clear me
 
 Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give up.**
 
-### Ways to construct one — try them in roughly this order
+**If you do not yet have such a signal, read `references/feedback-loops.md`** — ten ways to build one ordered by cost, and what to ask the user for when the bug resists reproduction entirely.
 
-1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
-2. **Curl / HTTP script** against a running dev server.
-3. **CLI invocation** with a fixture input, diffing stdout against a known-good snapshot.
-4. **Headless browser script** (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network.
-5. **Replay a captured trace.** Save a real network request / payload / event log to disk; replay it through the code path in isolation.
-6. **Throwaway harness.** Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug code path with a single function call.
-7. **Property / fuzz loop.** If the bug is "sometimes wrong output", run 1000 random inputs and look for the failure mode.
-8. **Bisection harness.** If the bug appeared between two known states (commit, dataset, version), automate "boot at state X, check, repeat" so you can `git bisect run` it.
-9. **Differential loop.** Run the same input through old-version vs new-version (or two configs) and diff outputs.
-10. **HITL bash script.** Last resort. If a human must click, drive _them_ with `scripts/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you.
+**If you do have one, it is probably not sharp enough yet.** Make it faster and more deterministic, and make it assert on the exact symptom rather than "didn't crash" — a 30-second flaky loop is barely better than no loop. If it stays slow or intermittent after that, read that file's "Iterate on the loop itself" and "Intermittent bugs" sections.
 
-Build the right feedback loop, and the bug is 90% fixed.
-
-### Iterate on the loop itself
-
-Treat the loop as a product. Once you have _a_ loop, ask:
-
-- Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
-- Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
-- Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
-
-A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
-
-### Non-deterministic bugs
-
-The goal is not a clean repro but a **higher reproduction rate**. Loop the trigger 100×, parallelise, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
-
-### When you genuinely cannot build a loop
-
-Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
-
-Do not proceed to Phase 2 until you have a loop you believe in.
+Do not proceed to Phase 2 until you have a loop you believe in. If you cannot build one, stop and say so explicitly, listing what you tried — never hypothesise without a signal.
 
 ## Phase 2 — Reproduce
 
@@ -57,7 +33,7 @@ Run the loop. Watch the bug appear.
 Confirm:
 
 - [ ] The loop produces the failure mode the **user** described — not a different failure that happens to be nearby. Wrong bug = wrong fix.
-- [ ] The failure is reproducible across multiple runs (or, for non-deterministic bugs, reproducible at a high enough rate to debug against).
+- [ ] The failure is reproducible across multiple runs. If it is intermittent, `references/feedback-loops.md` defines the rate high enough to debug against — go back to Phase 1 and raise it.
 - [ ] You have captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix actually addresses it.
 
 Do not proceed until you reproduce the bug.
@@ -90,19 +66,17 @@ Tool preference:
 
 ## Phase 5 — Fix + regression test
 
-Write the regression test **before the fix** — but only if there is a **correct seam** for it.
+Write the regression test **before the fix** — but only at a **correct seam**: one where the test exercises the real bug pattern as it occurs at the call site. If the available seam looks too shallow, or you cannot tell whether it is, read `references/regression-seams.md`.
 
-A correct seam is one where the test exercises the **real bug pattern** as it occurs at the call site. If the only available seam is too shallow (single-caller test when the bug needs multiple callers, unit test that can't replicate the chain that triggered the bug), a regression test there gives false confidence.
+**If no correct seam exists, that itself is the finding.** Note it and carry it into Phase 6 — the architecture is preventing the bug from being locked down.
 
-**If no correct seam exists, that itself is the finding.** Note it. The codebase architecture is preventing the bug from being locked down. Flag this for the next phase.
+At a correct seam:
 
-If a correct seam exists:
-
-1. Turn the minimised repro into a failing test at that seam.
+1. Turn the Phase 1 loop into a failing test at that seam, narrowed to the symptom captured in Phase 2.
 2. Watch it fail.
 3. Apply the fix.
 4. Watch it pass.
-5. Re-run the Phase 1 feedback loop against the original (un-minimised) scenario.
+5. Re-run the Phase 1 feedback loop against the original, un-narrowed scenario.
 
 ## Phase 6 — Cleanup + post-mortem
 

plugins/bin/skills/diagnose/references/feedback-loops.md

@@ -0,0 +1,40 @@
+# Constructing and sharpening a feedback loop
+
+A feedback loop is a fast, deterministic, agent-runnable pass/fail signal for the bug. Build the right one and the bug is 90% fixed. This file covers the whole arc: building a loop, sharpening one you already have, and escalating when the bug resists reproduction.
+
+## Ways to construct one — try them in roughly this order
+
+1. **Failing test** at whatever seam reaches the bug — unit, integration, e2e.
+2. **Curl / HTTP script** against a running dev server.
+3. **CLI invocation** with a fixture input, diffing stdout against a known-good snapshot.
+4. **Headless browser script** (Playwright / Puppeteer) — drives the UI, asserts on DOM/console/network.
+5. **Replay a captured trace.** Save a real network request / payload / event log to disk; replay it through the code path in isolation.
+6. **Throwaway harness.** Spin up a minimal subset of the system (one service, mocked deps) that exercises the bug code path with a single function call.
+7. **Property / fuzz loop.** If the bug is "sometimes wrong output", run 1000 random inputs and look for the failure mode.
+8. **Bisection harness.** If the bug appeared between two known states (commit, dataset, version), automate "boot at state X, check, repeat" so you can `git bisect run` it.
+9. **Differential loop.** Run the same input through old-version vs new-version (or two configs) and diff outputs.
+10. **HITL bash script.** Last resort. If a human must click, drive _them_ with `assets/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you.
+
+## Iterate on the loop itself
+
+Treat the loop as a product. Once you have _a_ loop, ask:
+
+- Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
+- Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
+- Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
+
+A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
+
+## Intermittent bugs — raise the reproduction rate
+
+If the loop only sometimes fails, the goal is not a clean repro but a **higher reproduction rate**. Loop the trigger 100×, parallelise, add stress, narrow timing windows, inject sleeps. A 50%-flake bug is debuggable; 1% is not — keep raising the rate until it's debuggable.
+
+## When you genuinely cannot build a loop
+
+Stop and say so explicitly. List what you tried. Ask the user for:
+
+- access to whatever environment reproduces it,
+- a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or
+- permission to add temporary production instrumentation.
+
+Do **not** proceed to hypothesise without a loop. A hypothesis you cannot falsify against a signal is a guess, and the fix that follows it is unverifiable.

plugins/bin/skills/diagnose/references/regression-seams.md

@@ -0,0 +1,24 @@
+# Judging a regression-test seam
+
+Read this when Phase 5 leaves you unsure whether the seam available for the regression test is the correct one — either because the obvious seam looks shallow, or because there appears to be no seam at all.
+
+## What makes a seam correct
+
+A correct seam is one where the test exercises the **real bug pattern** as it occurs at the call site: the same entry point, the same participants, the same ordering, and the same state the real caller holds when it goes wrong.
+
+## Seams that are too shallow
+
+- A single-caller test when the bug only appears with multiple callers.
+- A unit test that cannot replicate the chain of calls that triggered the bug.
+- A test that reproduces the symptom by construction — asserting on a value the test itself set — rather than by driving the code path that produces it.
+- A test that mocks out the collaborator the bug actually lives in.
+
+A regression test at a shallow seam gives false confidence. It passes forever, including after a change reintroduces the bug at the real call site, and it will be read by the next maintainer as proof the bug is locked down.
+
+## When there is no correct seam
+
+Do not force one, and do not settle for a shallow seam to have something green. Instead:
+
+1. Apply the fix and verify it against the Phase 1 loop directly.
+2. Write down which seams you considered and why each was too shallow.
+3. Carry that into Phase 6's "what would have prevented this bug" question. A missing seam is an architecture finding — tangled callers, hidden coupling, or a module with no testable boundary — and the handoff is the `improve-codebase-architecture` skill, with those specifics attached.

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

@@ -1,6 +1,12 @@
 ---
 name: grill-me
-description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
+description: >
+  Use when the user says "grill me" or wants a plan or design stress-tested by
+  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

@@ -1,6 +1,11 @@
 ---
 name: grill-with-docs
-description: Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
+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>
@@ -71,7 +76,7 @@ When the user states how something works, check whether the code agrees. If you
 
 ### Update CONTEXT.md inline
 
-When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [CONTEXT-FORMAT.md](./CONTEXT-FORMAT.md).
+When a term is resolved, update `CONTEXT.md` right there. Don't batch these up — capture them as they happen. Use the format in [context-format.md](references/context-format.md).
 
 Don't couple `CONTEXT.md` to implementation details. Only include terms that are meaningful to domain experts.
 
@@ -83,6 +88,6 @@ Only offer to create an ADR when all three are true:
 2. **Surprising without context** — a future reader will wonder "why did they do it this way?"
 3. **The result of a real trade-off** — there were genuine alternatives and you picked one for specific reasons
 
-If any of the three is missing, skip the ADR. Use the format in [ADR-FORMAT.md](./ADR-FORMAT.md).
+If any of the three is missing, skip the ADR. Use the format in [adr-format.md](references/adr-format.md).
 
 </supporting-info>

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

@@ -1,6 +1,13 @@
 ---
 name: improve-codebase-architecture
-description: Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
+description: >
+  Use when the user wants to improve architecture, find refactoring
+  opportunities, consolidate tightly-coupled modules, or make a codebase more
+  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.1"
 ---
 
 # Improve Codebase Architecture
@@ -9,7 +16,7 @@ Surface architectural friction and propose **deepening opportunities** — refac
 
 ## Glossary
 
-Use these terms exactly in every suggestion. Consistent language is the point — don't drift into "component," "service," "API," or "boundary." Full definitions in [LANGUAGE.md](LANGUAGE.md).
+Use these terms exactly in every suggestion. Consistent language is the point — don't drift into "component," "service," "API," or "boundary."
 
 - **Module** — anything with an interface and an implementation (function, class, package, slice).
 - **Interface** — everything a caller must know to use the module: types, invariants, error modes, ordering, config. Not just the type signature.
@@ -20,19 +27,21 @@ Use these terms exactly in every suggestion. Consistent language is the point
 - **Leverage** — what callers get from depth.
 - **Locality** — what maintainers get from depth: change, bugs, knowledge concentrated in one place.
 
-Key principles (see [LANGUAGE.md](LANGUAGE.md) for the full list):
+Key principles:
 
 - **Deletion test**: imagine deleting the module. If complexity vanishes, it was a pass-through. If complexity reappears across N callers, it was earning its keep.
 - **The interface is the test surface.**
 - **One adapter = hypothetical seam. Two adapters = real seam.**
 
+If a term or principle above is ambiguous in the case in front of you, or you need the definitions and the principles the two lists leave out, read `references/language.md`.
+
 This skill is _informed_ by the project's domain model. The domain language gives names to good seams; ADRs record decisions the skill should not re-litigate.
 
 ## Process
 
 ### 1. Explore
 
-Read the project's domain glossary and any ADRs in the area you're touching first.
+Read the domain glossary and any ADRs in the area first.
 
 Then use the Agent tool with `subagent_type=Explore` to walk the codebase. Don't follow rigid heuristics — explore organically and note where you experience friction:
 
@@ -53,7 +62,7 @@ Present a numbered list of deepening opportunities. For each candidate:
 - **Solution** — plain English description of what would change
 - **Benefits** — explained in terms of locality and leverage, and also in how tests would improve
 
-**Use CONTEXT.md vocabulary for the domain, and [LANGUAGE.md](LANGUAGE.md) vocabulary for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
+**Use CONTEXT.md vocabulary for the domain, and the architecture glossary above for the architecture.** If `CONTEXT.md` defines "Order," talk about "the Order intake module" — not "the FooBarHandler," and not "the Order service."
 
 **ADR conflicts**: if a candidate contradicts an existing ADR, only surface it when the friction is real enough to warrant revisiting the ADR. Mark it clearly (e.g. _"contradicts ADR-0007 — but worth reopening because…"_). Don't list every theoretical refactor an ADR forbids.
 
@@ -65,7 +74,7 @@ Once the user picks a candidate, drop into a grilling conversation. Walk the des
 
 Side effects happen inline as decisions crystallize:
 
-- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md` — same discipline as `/grill-with-docs` (see [CONTEXT-FORMAT.md](../grill-with-docs/CONTEXT-FORMAT.md)). Create the file lazily if it doesn't exist.
+- **Naming a deepened module after a concept not in `CONTEXT.md`?** Add the term to `CONTEXT.md` — same discipline as `grill-with-docs`, in the format `grill-with-docs`'s `references/context-format.md` defines. Create the file lazily if it doesn't exist.
 - **Sharpening a fuzzy term during the conversation?** Update `CONTEXT.md` right there.
-- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones. See [ADR-FORMAT.md](../grill-with-docs/ADR-FORMAT.md).
-- **Want to explore alternative interfaces for the deepened module?** See [INTERFACE-DESIGN.md](INTERFACE-DESIGN.md).
+- **User rejects the candidate with a load-bearing reason?** Offer an ADR, framed as: _"Want me to record this as an ADR so future architecture reviews don't re-suggest it?"_ Only offer when the reason would actually be needed by a future explorer to avoid re-suggesting the same thing — skip ephemeral reasons ("not worth it right now") and self-evident ones. See `grill-with-docs`'s `references/adr-format.md`.
+- **Want to explore alternative interfaces for the deepened module?** Read `references/interface-design.md`.

plugins/bin/skills/improve-codebase-architecture/references/deepening.md

@@ -1,6 +1,6 @@
 # Deepening
 
-How to deepen a cluster of shallow modules safely, given its dependencies. Assumes the vocabulary in [LANGUAGE.md](LANGUAGE.md) — **module**, **interface**, **seam**, **adapter**.
+How to deepen a cluster of shallow modules safely, given its dependencies. Assumes the vocabulary in [language.md](language.md) — **module**, **interface**, **seam**, **adapter**.
 
 ## Dependency categories
 

plugins/bin/skills/improve-codebase-architecture/references/interface-design.md

@@ -2,7 +2,7 @@
 
 When the user wants to explore alternative interfaces for a chosen deepening candidate, use this parallel sub-agent pattern. Based on "Design It Twice" (Ousterhout) — your first idea is unlikely to be the best.
 
-Uses the vocabulary in [LANGUAGE.md](LANGUAGE.md) — **module**, **interface**, **seam**, **adapter**, **leverage**.
+Uses the vocabulary in [language.md](language.md) — **module**, **interface**, **seam**, **adapter**, **leverage**.
 
 ## Process
 
@@ -11,7 +11,7 @@ Uses the vocabulary in [LANGUAGE.md](LANGUAGE.md) — **module**, **interface**,
 Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
 
 - The constraints any new interface would need to satisfy
-- The dependencies it would rely on, and which category they fall into (see [DEEPENING.md](DEEPENING.md))
+- The dependencies it would rely on, and which category they fall into (see [deepening.md](deepening.md))
 - A rough illustrative code sketch to ground the constraints — not a proposal, just a way to make the constraints concrete
 
 Show this to the user, then immediately proceed to Step 2. The user reads and thinks while the sub-agents work in parallel.
@@ -20,21 +20,21 @@ Show this to the user, then immediately proceed to Step 2. The user reads and th
 
 Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
 
-Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [DEEPENING.md](DEEPENING.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
+Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category from [deepening.md](deepening.md), what sits behind the seam). The brief is independent of the user-facing problem-space explanation in Step 1. Give each agent a different design constraint:
 
 - Agent 1: "Minimize the interface — aim for 1–3 entry points max. Maximise leverage per entry point."
 - Agent 2: "Maximise flexibility — support many use cases and extension."
 - Agent 3: "Optimise for the most common caller — make the default case trivial."
 - Agent 4 (if applicable): "Design around ports & adapters for cross-seam dependencies."
 
-Include both [LANGUAGE.md](LANGUAGE.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
+Include both [language.md](language.md) vocabulary and CONTEXT.md vocabulary in the brief so each sub-agent names things consistently with the architecture language and the project's domain language.
 
 Each sub-agent outputs:
 
 1. Interface (types, methods, params — plus invariants, ordering, error modes)
 2. Usage example showing how callers use it
 3. What the implementation hides behind the seam
-4. Dependency strategy and adapters (see [DEEPENING.md](DEEPENING.md))
+4. Dependency strategy and adapters (see [deepening.md](deepening.md))
 5. Trade-offs — where leverage is high, where it's thin
 
 ### 3. Present and compare

plugins/bin/skills/prototype/SKILL.md

@@ -1,6 +1,12 @@
 ---
 name: prototype
-description: Build a throwaway prototype to flush out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
+description: >
+  Use when the user wants a throwaway prototype to answer a design question about
+  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
@@ -9,10 +15,12 @@ A prototype is **throwaway code that answers a question**. The question decides
 
 ## Pick a branch
 
-Identify which question is being answered — from the user's prompt, the surrounding code, or by asking if the user is around:
+| Question being answered | Build | Reference |
+|---|---|---|
+| "Does this logic / state model feel right?" | A tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper | `references/logic.md` |
+| "What should this look like?" | Several radically different UI variations on one route, switchable via a URL search param and a floating bottom bar | `references/ui.md` |
 
-- **"Does this logic / state model feel right?"** → [LOGIC.md](LOGIC.md). Build a tiny interactive terminal app that pushes the state machine through cases that are hard to reason about on paper.
-- **"What should this look like?"** → [UI.md](UI.md). Generate several radically different UI variations on a single route, switchable via a URL search param and a floating bottom bar.
+Resolve the row from the user's prompt, the surrounding code, or by asking if the user is around, then read only that reference — each is self-contained.
 
 The two branches produce fundamentally different artifacts — getting this wrong wastes the whole prototype. If the question is genuinely ambiguous and the user isn't reachable, default to whichever branch better matches the surrounding code (a backend module → logic; a page or component → UI) and state the assumption at the top of the prototype.
 

plugins/bin/skills/prototype/references/logic.md

@@ -9,7 +9,7 @@ A tiny interactive terminal app that lets the user drive a state model by hand.
 - "I want to feel out what the API should look like before writing it."
 - Anything where the user wants to **press buttons and watch state change**.
 
-If the question is "what should this look like" — wrong branch. Use [UI.md](UI.md).
+If the question is "what should this look like" — wrong branch. Read `references/ui.md`.
 
 ## Process
 

plugins/bin/skills/prototype/references/ui.md

@@ -2,7 +2,7 @@
 
 Generate **several radically different UI variations** on a single route, switchable from a floating bottom bar. The user flips between variants in the browser, picks one (or steals bits from each), then throws the rest away.
 
-If the question is about logic/state rather than what something looks like — wrong branch. Use [LOGIC.md](LOGIC.md).
+If the question is about logic/state rather than what something looks like — wrong branch. Read `references/logic.md`.
 
 ## When this is the right shape
 

plugins/bin/skills/research/META.md

@@ -1,15 +0,0 @@
-```yaml
-version: "1.1"
-updated: 2026-06-21
-
-when: >-
-  Invoked when the user wants to gather structured reference documentation for a
-  tool, library, or API from MCP documentation indexes or web sources. Typically
-  run before writing a new skill that wraps an external tool, or any time
-  reference files are needed for a topic. Triggered explicitly
-  ("/research <topic> <path>") or implicitly when the user asks to look up,
-  gather, or pull docs for a topic before implementing something.
-
-references:
-  - .agents/skills/context7-mcp/SKILL.md  # context7-mcp — MCP source channel integrated at step 2
-```

plugins/bin/skills/research/SKILL.md

@@ -1,97 +1,79 @@
 ---
 name: research
 description: >-
-  Use when the user wants to research a topic and generate structured reference
-  markdown files. Handles: finding canonical docs for a tool/library/API via
-  Context7 MCP or web sources, reading and deepening into linked pages,
-  organizing extracted content into topic files (overview, installation,
-  configuration, cli-reference, api-reference, examples, troubleshooting). Do
-  NOT use when the user wants to write documentation from existing code or specs
-  (use write-docs), install or manage the neuledge-context MCP server (use
-  neuledge-context), or research a bug/incident (use diagnose).
+  Use when the user wants a tool, library, or API researched from canonical
+  documentation into structured per-topic reference markdown files. Not
+  documentation written from existing code or specs -> `write-docs`. Not a bug
+  or incident -> `diagnose`.
 metadata:
+  version: "1.0.0"
   category: research
 allowed-tools:
-  - WebSearch
-  - WebFetch
+  - Grep
+  - Glob
   - Read
   - Write
+  - WebSearch
+  - WebFetch
   - mcp__context7__resolve-library-id
   - mcp__context7__query-docs
 model: sonnet
 ---
 
-<requirements>
+## Gotchas
 
-## Required inputs
+- Never infer the output path. A run writes a directory's worth of files, and a guessed destination scatters them through someone's source tree. If the user named no path, stop and ask.
+- Write nothing outside the given output path. A file placed beside the agreed directory is one the user never asked for and will not think to look for.
+- Never write an empty topic file. A stub `troubleshooting.md` reads downstream as researched and closed.
+- A Context7 response that is a "no results" message, a redirect notice, or header-only boilerplate is not coverage. A topic area counts as covered only when the response carries at least one substantive paragraph.
 
-- **Topic** — the subject to research (tool, library, API, concept); inferred from user description if clear, ask if ambiguous
-- **Output path** — directory where reference files will be written; must be provided explicitly — do not infer or default
-- **Starting URLs** — optional; if provided, skip discovery websearch and read these first
+## Step 1 — Scope against the working directory
 
-## Constraints
+Search for existing use of the topic — imports, config files, version pins, reference files already written — and narrow the research to what is missing: the version actually in use, the topics not yet documented.
 
-- Never write files outside the explicitly provided output path
-- Skip any default topic file if no relevant content is found for it — do not create empty files
-- Create additional topic files beyond the default list when content warrants it (e.g. `webhooks.md`, `rate-limits.md`)
-- Subagents handle parallel source reading and link deepening — the orchestrator writes all files; subagents return summaries only, never write directly
-- Context7 MCP calls (`resolve-library-id`, `query-docs`) are made only by the orchestrator at step 2 — subagents must not call them
-- `sources.md` is always written, even if only one source was read
-- Each topic file must have frontmatter with `topic` and `source_keys`; body is prose only — no inline URLs
-- Source keys in `sources.md` must be kebab-case slugs: derived from the source domain or page title for web sources; for Context7 sources use `context7-<library-slug>` (e.g. `context7-vercel-next-js`)
-- Default topic list and file format spec live in `references/` sub-files — read them at step 1
+The default topic areas are `overview`, `installation`, `configuration`, `cli-reference`,
+`api-reference`, `examples` and `troubleshooting` — one file each, and only where content exists.
+If what belongs in one of them is unclear, or the topic needs a file outside that set, read
+`references/topics.md` for the per-topic coverage table and the custom-topic naming rule.
 
-</requirements>
+## Step 2 — Resolve against Context7
 
-<steps>
+If the topic is a library, framework, or API and the user gave no starting URLs, call `resolve-library-id` with the topic name and the user's full question — match quality depends on the question, not the bare name — then `query-docs` once per default topic area. Record each response as a source with slug `context7-<library-slug>`, and mark which topic areas it covered — those skip the web reads at step 4.
 
-## Process
+If the library does not resolve, or the user gave starting URLs, go to step 3. Explicit URLs are a source choice; do not second-guess them with a resolution attempt.
 
-1. **Scan codebase.** Search the working directory for existing usage of the topic — imports, config files, version pins, existing reference files. Use findings to narrow research scope (e.g. target the version already in use, skip topics already documented). Read `references/topics.md` for the default topic list and `references/file-format.md` for the output file format spec.
+## Step 3 — Discover sources
 
-2. **Try Context7.** If the topic is a library, framework, or API and no starting URLs were provided, call `resolve-library-id` with the topic name and the user's question. If a match resolves, call `query-docs` once per default topic area (see `references/topics.md`). Treat each response as a source summary with slug `context7-<library-slug>` (e.g. `context7-vercel-next-js`). A topic area has sufficient content when the Context7 response contains at least one substantive paragraph — not a "no results" message, redirect notice, or header-only boilerplate. Mark covered topic areas — skip their subagent web reads in step 4. If the library does not resolve, or starting URLs were provided (explicit source choice by the user), skip this step entirely.
+If the user gave starting URLs, skip discovery: those URLs are the source list and go straight to step 4.
 
-3. **Discover sources.** For topics not covered by Context7 (or when no starting URLs were provided and Context7 did not resolve), websearch for canonical documentation (prefer `llms.txt`, developer docs, official API references over tutorials or blog posts). Collect 3–5 candidate URLs before reading any.
+Otherwise, for every topic area Context7 did not cover, websearch for canonical documentation — `llms.txt`, official developer docs, and API references ahead of tutorials or blog posts. Collect three to five candidate URLs before reading any of them.
 
-4. **Read sources in parallel.** Spawn one subagent per source URL. Each subagent fetches the page, extracts relevant content, identifies links worth deepening, and returns a structured summary (content by topic area + links to follow). Subagents do not write files.
+If nothing usable comes back, stop and report what was searched, then ask for starting URLs rather than settling for tutorials.
 
-5. **Deepen.** For each subagent that returned links worth following, spawn child subagents per branch. Continue until content becomes repetitive or out of scope. Cap at ~10 additional pages total across all branches.
+## Step 4 — Read the sources
 
-6. **Consolidate.** Merge all subagent summaries (Context7 and web) by topic area. Identify which default topics have sufficient content and which custom topics emerged.
+`WebFetch` each URL in turn. No subagent tool is granted here, so the reads are serial and every fetched page lands in this context: reduce each page to notes by topic area, plus the links worth deepening, before fetching the next one.
 
-7. **Write topic files.** For each topic with content, write `<output-path>/<topic>.md` using the format in `references/file-format.md`. Orchestrator writes all files — never delegate file writing to a subagent.
+## Step 5 — Deepen
 
-8. **Write `sources.md`.** Write `<output-path>/sources.md` mapping each source slug to its URL (use `context7:<library-id>` as the URL for Context7 sources), description, and list of topic files it contributed to. Include sources that yielded no content, marked `no content extracted`.
+`WebFetch` the links worth following, still one at a time and still reducing each page to notes. Stop a branch once its content turns repetitive or leaves the topic, and cap the whole step at roughly ten additional pages — serial reads make that cap a real budget, not a formality.
 
-## Output format
+## Step 6 — Write
 
-- `<output-path>/<topic>.md` per topic with content — formatted per `references/file-format.md`
-- `<output-path>/sources.md` — always produced; maps slug → URL, description, contributing files
+Merge every set of notes, Context7 and web alike, by topic area, then write, in the output path:
 
-</steps>
+- `<topic>.md` for each topic area that has content, default or custom. Frontmatter carries `topic:` (the filename without `.md`) and `source_keys:` (kebab-case slugs matching `sources.md`); the body is prose in `##` sections, with no inline URLs.
+- `sources.md`, always, one `##` section per source — including sources that yielded nothing — with exactly these four fields:
 
-<checks>
+  ```markdown
+  - **URL:** <full URL>
+  - **Description:** <one-line summary>
+  - **Contributing files:** <topic files this source contributed to>
+  - **Status:** `extracted` | `no content extracted`
+  ```
 
-## Failure handling
+Spell those four field names exactly as given. The downstream provenance validator matches them literally; prose in their place parses as nothing, and the check passes having verified nothing.
 
-- Output path not provided — stop and ask; do not infer or default
-- No sources found after websearch — report what was searched, ask user to provide starting URLs
-- Subagent returns no usable content — skip that source, log in `sources.md` as `no content extracted`
-- All topic files would be empty — stop, report what was searched, do not write any files
+Read `references/file-format.md` when the four fields above do not settle the case: what a slug should be, the `context7-<library-slug>` slug and `context7:<library-id>` URL convention for a Context7 source, or what belongs in a topic body versus a verbatim copy of the source.
 
-## Self-check
-
-- [ ] Codebase scanned before any websearch was performed
-- [ ] Output path was explicitly provided — not inferred
-- [ ] `references/topics.md` and `references/file-format.md` read at step 1
-- [ ] Context7 resolution attempted before websearch when topic is a library/framework/API
-- [ ] Context7 calls made only at orchestrator step 2 — no subagent called `resolve-library-id` or `query-docs`
-- [ ] Context7 sources recorded in `sources.md` with `context7:<library-id>` as URL
-- [ ] No topic file written without content
-- [ ] `sources.md` written with all sources read (including those with no content extracted)
-- [ ] All file writes performed by the orchestrator, not subagents
-- [ ] Each topic file has `topic` and `source_keys` frontmatter fields
-- [ ] All source keys in topic files have a matching entry in `sources.md`
-- [ ] No files written outside the provided output path
-
-</checks>
+If no topic area has content, write nothing at all, `sources.md` included, and report what was searched.

plugins/bin/skills/tdd/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: tdd
-description: Test-driven development with red-green-refactor loop. Use when user wants to build features or fix bugs using TDD, mentions "red-green-refactor", wants integration tests, or asks for test-first development.
+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.1"
 ---
 
 # Test-Driven Development
@@ -13,7 +18,7 @@ description: Test-driven development with red-green-refactor loop. Use when user
 
 **Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavior.
 
-See [tests.md](tests.md) for examples and [mocking.md](mocking.md) for mocking guidelines.
+If you need worked examples of the difference — a behaviour-level test beside the implementation-coupled version of the same check — read `references/tests.md`. If a test needs a collaborator faked, read `references/mocking.md` before reaching for a mock.
 
 ## Anti-Pattern: Horizontal Slices
 
@@ -44,14 +49,14 @@ RIGHT (vertical):
 
 ### 1. Planning
 
-When exploring the codebase, use the project's domain glossary so that test names and interface vocabulary match the project's language, and respect ADRs in the area you're touching.
+When exploring the codebase, use the domain glossary so test names and interface vocabulary match the project's language, and respect ADRs in the area.
 
 Before writing any code:
 
 - [ ] Confirm with user what interface changes are needed
 - [ ] Confirm with user which behaviors to test (prioritize)
-- [ ] Identify opportunities for [deep modules](deep-modules.md) (small interface, deep implementation)
-- [ ] Design interfaces for [testability](interface-design.md)
+- [ ] Identify opportunities for [deep modules](references/deep-modules.md) (small interface, deep implementation)
+- [ ] Design interfaces for [testability](references/interface-design.md)
 - [ ] List the behaviors to test (not implementation steps)
 - [ ] Get user approval on the plan
 
@@ -88,7 +93,7 @@ Rules:
 
 ### 4. Refactor
 
-After all tests pass, look for [refactor candidates](refactoring.md):
+After all tests pass, look for [refactor candidates](references/refactoring.md):
 
 - [ ] Extract duplication
 - [ ] Deepen modules (move complexity behind simple interfaces)

plugins/bin/skills/triage/SKILL.md

@@ -1,6 +1,11 @@
 ---
 name: triage
-description: Triage issues through a state machine driven by triage roles. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
+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.1"
 ---
 
 # Triage
@@ -15,8 +20,8 @@ Every comment or issue posted to the issue tracker during triage **must** start
 
 ## Reference docs
 
-- [AGENT-BRIEF.md](AGENT-BRIEF.md) — how to write durable agent briefs
-- [OUT-OF-SCOPE.md](OUT-OF-SCOPE.md) — how the `.out-of-scope/` knowledge base works
+- [agent-brief.md](references/agent-brief.md) — how to write durable agent briefs
+- [out-of-scope.md](references/out-of-scope.md) — how the `.out-of-scope/` knowledge base works
 
 ## Roles
 
@@ -35,7 +40,7 @@ Five **state** roles:
 
 Every triaged issue should carry exactly one category role and one state role. If state roles conflict, flag it and ask the maintainer before doing anything else.
 
-These are canonical role names — the actual label strings used in the issue tracker may differ. The mapping should have been provided to you - run `/setup-matt-pocock-skills` if not.
+These are canonical role names — the actual label strings used in the issue tracker may differ. Resolve each canonical name against the tracker's live label set before applying it, using whichever tracker skill this install provides. If a name has no counterpart there, report the gap and ask the maintainer for the mapping — never substitute a guess.
 
 State transitions: an unlabeled issue normally goes to `needs-triage` first; from there it moves to `needs-info`, `ready-for-agent`, `ready-for-human`, or `wontfix`. `needs-info` returns to `needs-triage` once the reporter replies. The maintainer can override at any time — flag transitions that look unusual and ask before proceeding.
 
@@ -60,7 +65,7 @@ Show counts and a one-line summary per issue. Let the maintainer pick.
 
 ## Triage a specific issue
 
-1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the project's domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
+1. **Gather context.** Read the full issue (body, comments, labels, reporter, dates). Parse any prior triage notes so you don't re-ask resolved questions. Explore the codebase using the domain glossary, respecting ADRs in the area. Read `.out-of-scope/*.md` and surface any prior rejection that resembles this issue.
 
 2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
 
@@ -69,11 +74,11 @@ Show counts and a one-line summary per issue. Let the maintainer pick.
 4. **Grill (if needed).** If the issue needs fleshing out, run a `/grill-with-docs` session.
 
 5. **Apply the outcome:**
-   - `ready-for-agent` — post an agent brief comment ([AGENT-BRIEF.md](AGENT-BRIEF.md)).
+   - `ready-for-agent` — post an agent brief comment ([agent-brief.md](references/agent-brief.md)).
    - `ready-for-human` — same structure as an agent brief, but note why it can't be delegated (judgment calls, external access, design decisions, manual testing).
    - `needs-info` — post triage notes (template below).
    - `wontfix` (bug) — polite explanation, then close.
-   - `wontfix` (enhancement) — write to `.out-of-scope/`, link to it from a comment, then close ([OUT-OF-SCOPE.md](OUT-OF-SCOPE.md)).
+   - `wontfix` (enhancement) — write to `.out-of-scope/`, link to it from a comment, then close ([out-of-scope.md](references/out-of-scope.md)).
    - `needs-triage` — apply the role. Optional comment if there's partial progress.
 
 ## Quick state override

plugins/bin/skills/triage/references/agent-brief.md

@@ -1,6 +1,6 @@
 # Writing Agent Briefs
 
-An agent brief is a structured comment posted on a GitHub issue when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original issue body and discussion are context — the agent brief is the contract.
+An agent brief is a structured comment posted on an issue in the issue tracker when it moves to `ready-for-agent`. It is the authoritative specification that an AFK agent will work from. The original issue body and discussion are context — the agent brief is the contract.
 
 ## Principles
 
@@ -27,7 +27,7 @@ Describe **what** the system should do, not **how** to implement it. The agent w
 
 The agent needs to know when it's done. Every agent brief must have concrete, testable acceptance criteria. Each criterion should be independently verifiable.
 
-- **Good:** "Running `gh issue list --label needs-triage` returns issues that have been through initial classification"
+- **Good:** "Querying the issue tracker for the `needs-triage` label returns issues that have been through initial classification"
 - **Bad:** "Triage should work correctly"
 
 ### Explicit scope boundaries

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

@@ -1,10 +1,15 @@
 ---
 name: write-docs
-description: Write documentation for X, document this module, create docs for this feature. Use when the user wants to produce or update technical documentation derived from code, spec, or existing artifacts. Do NOT use when the user wants a PRD, ADR, decision doc, or skill file — those have dedicated skills.
-version: "1.0"
+description: >
+  Use when the user wants technical documentation produced or updated from code
+  or spec, every claim traced to a source — "write docs for X", "document this
+  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`.
 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
@@ -35,7 +40,8 @@ You are a technical writer that produces documentation by reading code and spec
 - User says "write docs for X", "document this", "create docs for this feature", "write a README for this"
 
 **Do not use when:**
-- User wants a PRD, decision doc, or architecture proposal → `to-prd` or `grill-me`
+- User wants an ADR, decision doc, or architecture proposal → `grill-with-docs`, which writes ADRs
+- User wants a PRD → no skill in this set produces one; say so rather than redirecting
 - User wants to document a skill file (skill files are self-describing)
 - User wants marketing or blog copy
 - Documentation requires tacit organisational knowledge that cannot be read from code or spec
@@ -88,7 +94,7 @@ You are a technical writer that produces documentation by reading code and spec
 - Stage skipped without a logged reason → flag and require the one-sentence log before continuing
 - Code behaviour is undocumentable (internal implementation detail, no public spec) → note as out-of-scope in the doc; do not invent an explanation
 - Reader Testing sub-agent fails on multiple questions → surface the failures, return to step 4; do not mark complete
-- Requested output is a PRD, decision doc, or architecture proposal → redirect to `to-prd`, `grill-me`, or `grill-with-docs`
+- Requested output is an ADR, decision doc, or architecture proposal → redirect to `grill-with-docs`; for a PRD, say no skill here produces one instead of redirecting
 
 ## Self-check
 

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.1"
 ---
 
-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.
+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.

plugins/core/.apm/skills/agentsmd-audit/README.md

@@ -1,35 +0,0 @@
-# agentsmd-audit
-
-Audit a target repo's AGENTS.md file(s) for embedded secrets, structural completeness, and drift.
-
-## What it does
-
-Runs a single combined pass across every AGENTS.md file in a repo (root and any nested monorepo files): flags embedded secrets/credentials, checks structure against the agents.md common-sections checklist, and resolves referenced commands/paths against the actual repo to catch stale documentation. Outputs a compact findings report — findings only, grouped by dimension, each with Why and Fix. Never inspects provider-specific adapter files (CLAUDE.md, etc.) and never writes or fixes anything.
-
-## Usage
-
-```
-/agentsmd-audit
-```
-
-Provide the path to the repo root to audit when invoking.
-
-## Files
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Skill instructions for agents |
-| `scripts/validate-secrets.sh` | Scans AGENTS.md files for embedded secrets, API keys, tokens, connection strings |
-| `scripts/validate-structure.sh` | Checks for empty/placeholder content, common-sections checklist, nested-vs-root duplication |
-| `scripts/validate-drift.sh` | Resolves referenced npm/make commands and file paths against the repo |
-| `references/sources.md` | Provenance record — sources that informed this skill and which files each contributed to |
-| `scripts/README.md` | Directory documentation for `scripts/` |
-| `tests/README.md` | (source-only) Bats test dependency and run instructions |
-| `tests/validate-secrets.bats` | (source-only) Bats test suite for `scripts/validate-secrets.sh` |
-| `tests/validate-structure.bats` | (source-only) Bats test suite for `scripts/validate-structure.sh` |
-| `tests/validate-drift.bats` | (source-only) Bats test suite for `scripts/validate-drift.sh` |
-
-Rows marked **(source-only)** exist in the authoring source (`.apm/skills/agentsmd-audit/`) but are
-not present in an installed plugin: `scripts/sync-plugin-content.sh` strips `<category>/<name>/tests`
-when it generates the flat mirror, because these are dev-time fixtures no plugin host needs to
-discover (ADR-0017). Run them from a repo checkout, not from an install.

plugins/core/.apm/skills/agentsmd-audit/SKILL.md

@@ -1,20 +1,11 @@
 ---
 name: agentsmd-audit
 description: >
-  Use when the user wants to review a repo's AGENTS.md file, says "audit this
-  AGENTS.md", "check my AGENTS.md", "is this AGENTS.md any good", or wants to
-  know if AGENTS.md is safe to commit — even if they don't use the word
-  "audit". Also invoke proactively after agentsmd-author creates or updates
-  AGENTS.md, or after a hand-edit made outside agentsmd-author. Audits a
-  target repo's AGENTS.md file(s) — root and any nested monorepo files — for
-  embedded secrets/credentials, structural completeness against the
-  agents.md common-sections checklist, and drift (referenced commands or
-  paths that no longer resolve against the repo). Produces a compact
-  findings report (findings only, no PASS noise) with Why and Fix per
-  finding. Do not use to audit CLAUDE.md, .cursor/rules, or other
-  provider-specific adapter files — that's provider-adapter-author's
-  self-contained concern. Do not use to fix or write AGENTS.md content — use
-  agentsmd-author instead.
+  Use when the user wants a repo's AGENTS.md audited for secrets, structure
+  and drift — "is this AGENTS.md safe to commit" — or after a hand-edit
+  outside `agentsmd-author`.
+  Not converting a provider file -> `provider-adapter-author`.
+  Not writing AGENTS.md -> `agentsmd-author`.
 allowed-tools: Bash Read
 metadata:
   category: docs
@@ -23,14 +14,13 @@ metadata:
     - context7-websites-agents-md
     - context7-agentsmd-agents-md
     - governance-secrets-hard-prohibition
-  version: "0.1.1"
+  version: "0.1.2"
 ---
 
 ## Gotchas
 
 - Always run all three checks — this skill does a single combined pass, not staged/gated passes. Don't skip structure or drift checks just because a secrets FAIL was found.
-- Never inspect or mention provider-specific adapter files (`CLAUDE.md`, `.cursor/rules/*.mdc`, `copilot-instructions.md`, etc.) — that's out of scope. If one exists and duplicates AGENTS.md content, that's `provider-adapter-author`'s concern, not this skill's.
-- A missing common section (e.g. no "Security" heading) is informational, not a failure — not every repo needs every section from the checklist. Only flag a FAIL when the file is empty, entirely unfilled placeholder text, or contains a real embedded secret/stale reference.
+- Never inspect or mention provider-specific adapter files (`CLAUDE.md`, `.cursor/rules/*.mdc`, `copilot-instructions.md`, etc.) — that's out of scope.
 - Gather findings internally; don't narrate PASS/FAIL per check as you go — surface them only in the final report.
 
 ## Step 1 — Run the validators
@@ -41,7 +31,7 @@ bash scripts/validate-structure.sh <repo-root>
 bash scripts/validate-drift.sh <repo-root>
 ```
 
-Each script walks the repo for every `AGENTS.md` file (root and nested, excluding `.git`, `node_modules`, `vendor`, and similar) and prints `FAIL`/`INFO`/`SUGGESTION` lines with `Why`/`Fix` (or `Note`) per finding. A nonzero exit means at least one FAIL was found in that dimension. If a script cannot execute (`python3` unavailable, Bash denied), fall back to manual review: scan for real-looking credentials, check common sections are present, and spot-check a few referenced commands/paths by hand.
+Each script walks the repo for every `AGENTS.md` file (root and nested, excluding `.git`, `node_modules`, `vendor`, and similar) and prints `FAIL` lines, plus `INFO`/`SUGGESTION` where applicable, with `Why`/`Fix` (or `Note`) per finding. A nonzero exit means at least one FAIL was found in that dimension. If a script cannot execute (`python3` unavailable, Bash denied), fall back to manual review: scan for real-looking credentials, check common sections are present, and spot-check a few referenced commands/paths by hand. Grade a manual finding the way the scripts grade theirs: a missing common section (e.g. no "Security" heading) is informational, not a failure — not every repo needs every section from the checklist. Only flag a FAIL when the file is empty, entirely unfilled placeholder text, or contains a real embedded secret/stale reference.
 
 ## Step 2 — Report
 
@@ -53,16 +43,4 @@ Checked: secrets · structure · drift
 
 Then output only findings that were found, in this order within a repo: `### Secrets`, `### Structure`, `### Drift`. Omit a dimension heading entirely if it produced nothing — its absence confirms it passed. Report each finding verbatim as emitted by the scripts (they already carry file:line, Why/Fix or Note).
 
-Close with a result block:
-
-```text
-## Result
-
-PASS
-PASS · P info
-PASS (N suggestions) · P info
-FAIL (N fails)
-FAIL (N fails) · P info
-```
-
-INFO and SUGGESTION findings are observational — they never flip PASS to FAIL. Do not fix anything — this skill reports and proposes only. Point the user to `agentsmd-author` to apply fixes.
+Close with a `## Result` block holding one line: `PASS`, `PASS (N suggestions)`, or `FAIL (N fails · M suggestions)`, each optionally followed by ` · P info`. Omit the suggestion count when there are none, and omit `· P info` when there are none. INFO and SUGGESTION findings are observational — they never flip PASS to FAIL. Do not fix anything — this skill reports and proposes only. Point the user to `agentsmd-author` to apply fixes.

plugins/core/.apm/skills/agentsmd-author/README.md

@@ -1,27 +0,0 @@
-# agentsmd-author
-
-Create or update a target repo's AGENTS.md file(s) by exploring the repo for real conventions.
-
-## What it does
-
-Explores a target repo (package manager scripts, Makefile/task runner, CI config, linter config, existing docs) and writes or updates `AGENTS.md` with only verified commands and conventions — never invented ones. Supports nested monorepo placement, following the agents.md standard's nearest-file-wins precedence. Closes every run by invoking `agentsmd-audit` inline, and hands off to `provider-adapter-author` when an existing provider-specific file (CLAUDE.md, etc.) now duplicates content AGENTS.md owns.
-
-## Before you start
-
-The `agentsmd-audit` skill must be available (co-installed in the `core` plugin) — this skill invokes it as a mandatory closeout step.
-
-## Usage
-
-```
-/agentsmd-author
-```
-
-Provide the target repo root (defaults to the current directory) and, if relevant, which subdirectory should get a nested AGENTS.md.
-
-## Files
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Skill instructions for agents |
-| `references/content-guide.md` | Section-by-section AGENTS.md content guidance, a worked example, and monorepo/nested-file precedence rules |
-| `references/sources.md` | Provenance record — sources that informed this skill and which files each contributed to |

plugins/core/.apm/skills/agentsmd-author/SKILL.md

@@ -1,20 +1,10 @@
 ---
 name: agentsmd-author
 description: >
-  Use when the user wants to create or update a repo's AGENTS.md file
-  ("write an AGENTS.md for this repo", "add setup/test instructions for
-  agents", "update AGENTS.md", "give this package its own AGENTS.md") — even
-  if they don't name the file explicitly, e.g. "document this for AI coding
-  tools" or "make sure agents know how to run tests here". Writes/updates
-  AGENTS.md by exploring the target repo for real build, test, lint, and
-  style conventions — never invents commands. Supports nested monorepo
-  placement (a subdirectory can get its own AGENTS.md following
-  nearest-file-wins precedence). Closes every run by invoking agentsmd-audit
-  inline, and calls provider-adapter-author when an existing provider file
-  (CLAUDE.md, etc.) now duplicates what AGENTS.md owns. Do not use to review
-  an existing AGENTS.md without changing it — use agentsmd-audit instead. Do
-  not use to convert CLAUDE.md/.cursor/rules into a thin adapter — use
-  provider-adapter-author instead.
+  Use when the user wants a repo's AGENTS.md written or updated, root or
+  nested, including "document this for AI coding tools". Writes only verified
+  conventions. Not review-only -> `agentsmd-audit`. Not converting CLAUDE.md ->
+  `provider-adapter-author`.
 allowed-tools: Bash Read Write Edit
 metadata:
   category: docs
@@ -22,16 +12,13 @@ metadata:
     - agents-md-official
     - context7-websites-agents-md
     - context7-agentsmd-agents-md
-  version: "0.1.1"
+  version: "0.1.2"
 ---
 
 ## Gotchas
 
 - Never invent a command. Every line under a setup/test/build section must come from something you actually found in the repo (`package.json` scripts, a `Makefile` target, a CI workflow step, a README). If you can't verify a command, don't include it.
-- AGENTS.md has no required schema — don't force every common-sections-checklist heading into every repo. Include only sections that reflect something real about this repo; a thin, accurate file beats a padded, generic one.
-- Nested placement is for genuinely different conventions, not convenience. Only create a subdirectory AGENTS.md when that subtree has its own build tool, stack, or conventions distinct from the root — otherwise you're duplicating content the root already covers, which the nearest-file-wins rule doesn't merge back together.
-- This skill never touches CLAUDE.md, `.cursor/rules/*.mdc`, `copilot-instructions.md`, or similar provider files directly — that's `provider-adapter-author`'s job. Detect and hand off; don't reconcile it yourself.
-- This skill never audits on its own judgment — the closing `agentsmd-audit` invocation is mandatory, not optional, even when the change looks trivial.
+- Never write to a provider file yourself, in any circumstance: `CLAUDE.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md` and their equivalents are `provider-adapter-author`'s to own. That holds even when the user asks for one in the same breath as AGENTS.md, and even when the file is merely stale or missing a pointer rather than duplicating anything. Detect it and hand off.
 
 ## Step 1 — Explore the target repo
 
@@ -40,17 +27,17 @@ Before writing anything, gather real facts: package manager and scripts (`packag
 ## Step 2 — Decide placement
 
 - No `AGENTS.md` at the repo root yet → create one there first, covering whole-repo conventions.
-- A subdirectory has materially different build/test tooling or conventions than the root → create or update a nested `AGENTS.md` there, scoped to what's different. Don't repeat root-level content — the nearest-file-wins rule means the nested file is read alone, not merged with the root.
+- A subdirectory has materially different build/test tooling or conventions than the root → create or update a nested `AGENTS.md` there, scoped to what's different. Convenience is not a reason to create one — without a distinct stack you are duplicating content the root already covers. **Don't repeat root-level content** in a nested file: the nearest-file-wins rule means it is read alone, never merged back with the root.
 - Otherwise → update the existing file(s) in place.
 
 ## Step 3 — Write or update
 
-Use only sections that reflect something real about the repo — never fill in every common-sections-checklist heading just because it exists. Read `references/content-guide.md` for section-by-section guidance, a worked example, and what separates useful content from generic padding, before writing.
+AGENTS.md has no required schema. Use only sections that reflect something real about the repo — never fill in every common-sections-checklist heading just because it exists, because a thin accurate file beats a padded generic one. Read `references/content-guide.md` for section-by-section guidance, a worked example, and what separates useful content from generic padding, before writing.
 
 ## Step 4 — Check for an existing provider file
 
-Look for `CLAUDE.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, or similar in the target repo. If one exists and now duplicates content the AGENTS.md you just wrote/updated already owns, invoke the `provider-adapter-author` skill on it to reconcile — don't rewrite it yourself.
+Look for `CLAUDE.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, or similar in the target repo. If one exists, invoke the `provider-adapter-author` skill on it to reconcile — whether it duplicates content the AGENTS.md you just wrote/updated now owns, or is merely stale or missing a pointer to it. Never edit it yourself in either case.
 
 ## Step 5 — Audit and report
 
-Invoke the `agentsmd-audit` skill directly on the AGENTS.md file(s) you just wrote or updated. Resolve any FAIL findings before considering the work done — re-invoke this skill's own writing steps to fix them, then re-run the audit, same as any other close-the-loop check. Report what was created/changed, whether a provider file was reconciled, and the audit's final result.
+Invoke the `agentsmd-audit` skill on the target repo root — its validators take a `<repo-root>` and walk the tree for every AGENTS.md themselves; there is no per-file entry point. This closeout is mandatory, not optional, even when the change looks trivial — never sign the work off on your own judgment. Resolve any FAIL findings before considering the work done — re-invoke this skill's own writing steps to fix them, then re-run the audit, same as any other close-the-loop check. Report what was created/changed, whether a provider file was reconciled, and the audit's final result.

plugins/core/.apm/skills/provider-adapter-author/README.md

@@ -1,35 +0,0 @@
-# provider-adapter-author
-
-Convert a target repo's provider-specific instruction file (CLAUDE.md, .cursor/rules, copilot-instructions.md, etc.) into a thin adapter over AGENTS.md.
-
-## What it does
-
-Detects a provider-specific AI instruction file in a target repo, diffs it against the repo's `AGENTS.md`, and rewrites it down to a minimal reference — an `@AGENTS.md`-style import for providers that support one, or a text pointer for those that don't — plus only genuinely provider-specific additions. Self-validates its own output with a bundled deterministic script (no LLM judgment, no separate audit skill) before finishing.
-
-## Before you start
-
-The target repo must already have an `AGENTS.md`. If it doesn't, run `agentsmd-author` first — this skill never creates or edits `AGENTS.md` itself.
-
-## Usage
-
-```
-/provider-adapter-author
-```
-
-Provide the path to the provider-specific file to convert (and the target repo root, if not inferable). Can be invoked directly, or composed into by `agentsmd-author` when it detects an existing provider file with content overlapping AGENTS.md.
-
-## Files
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Skill instructions for agents |
-| `references/sources.md` | Provenance record — the in-repo ADR precedent this skill's design is modeled on |
-| `scripts/validate-adapter.sh` | Self-check gate: reference to AGENTS.md present, no excessive duplication, adapter stays thin |
-| `scripts/README.md` | Directory documentation for `scripts/` |
-| `tests/README.md` | (source-only) Bats test dependency and run instructions |
-| `tests/validate-adapter.bats` | (source-only) Bats test suite for `scripts/validate-adapter.sh` |
-
-Rows marked **(source-only)** exist in the authoring source (`.apm/skills/provider-adapter-author/`)
-but are not present in an installed plugin: `scripts/sync-plugin-content.sh` strips
-`<category>/<name>/tests` when it generates the flat mirror, because these are dev-time fixtures no
-plugin host needs to discover (ADR-0017). Run them from a repo checkout, not from an install.

plugins/core/.apm/skills/provider-adapter-author/SKILL.md

@@ -1,43 +1,41 @@
 ---
 name: provider-adapter-author
 description: >
-  Use when the user wants to convert a provider-specific AI instruction file
-  (CLAUDE.md, .cursor/rules/*.mdc, copilot-instructions.md, etc.) into a
-  thin adapter that defers to a repo's AGENTS.md — e.g. "reduce duplication
-  between CLAUDE.md and AGENTS.md", "make CLAUDE.md just import AGENTS.md"
-  — even if the pattern isn't named explicitly. Also invoke when
-  agentsmd-author detects an existing provider file overlapping with
-  AGENTS.md it just wrote. Detects redundant content in a provider file
-  relative to AGENTS.md and rewrites it down to a minimal reference (an
-  `@AGENTS.md`-style import where supported, or a text pointer otherwise)
-  plus genuinely provider-specific additions. Self-validates via a bundled
-  deterministic script before finishing. Do not use to write or audit
-  AGENTS.md itself — use agentsmd-author or agentsmd-audit.
+  Use when a provider file (CLAUDE.md, .cursor rules, copilot-instructions)
+  duplicating the repo's AGENTS.md should be cut to a thin adapter — "make
+  CLAUDE.md just import AGENTS.md".
+  Not writing the AGENTS file -> `agentsmd-author`.
+  Not auditing the AGENTS file -> `agentsmd-audit`.
 allowed-tools: Bash Read Edit Write
 metadata:
   category: docs
   source_keys:
     - adr-0002-0003-two-tier-claude-md
-  version: "0.1.0"
+  version: "0.1.1"
 ---
 
 ## Gotchas
 
-- Not every provider supports cross-file imports. Claude Code does — a `CLAUDE.md` can consist of nothing but one or more `@path` lines (e.g. `@AGENTS.md`), with no other content required. Cursor's `.cursor/rules/*.mdc` and GitHub Copilot's `copilot-instructions.md` have no native import mechanism as of current tooling — for those, "thin" means a short text pointer to AGENTS.md plus only what that tool actually needs, not a literal import line. Pass `--no-import-syntax` to `scripts/validate-adapter.sh` for these providers.
-- This skill never creates or edits `AGENTS.md` itself. If the target repo has no `AGENTS.md` yet, stop and point the user to `agentsmd-author` first — there's nothing to adapt to.
-- Only strip content from the provider file that's genuinely redundant with AGENTS.md. Provider-specific material (IDE settings, tool-only syntax, model-specific instructions) stays — the goal is thin, not empty.
-- Works standalone or composed-into by `agentsmd-author` — behave identically either way; don't assume a caller skill exists.
+- Assume a provider has no cross-file import mechanism until you have confirmed it has one. Claude Code is the exception, not the rule: a `CLAUDE.md` may consist of nothing but `@path` lines, while the same `@AGENTS.md` line in a Cursor rule or a Copilot instructions file is inert text no tool resolves. Pass `--no-import-syntax` to `scripts/validate-adapter.sh` for those providers.
+
+- Works standalone or composed-into by `agentsmd-author` — behave identically either way; do not assume a caller skill exists. Detect the provider file, confirm `AGENTS.md`, and run the closeout validator yourself in both cases (`references/provider-matrix.md`).
 
 ## Step 1 — Detect
 
-Look for known provider instruction files in the target repo: `CLAUDE.md` (repo root, and any deployed copies), `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, and similar tool-specific files. Confirm `AGENTS.md` exists at the repo root — if not, stop and tell the user to run `agentsmd-author` first.
+Find the provider instruction file to convert. Before searching, read `references/provider-matrix.md` — skip it only when the target is already a known root `CLAUDE.md`, which is the common case.
+
+Then confirm `AGENTS.md` exists at the repo root. If it does not, stop and tell the user to run `agentsmd-author` first — there is nothing to adapt to.
 
 ## Step 2 — Diff and rewrite
 
 Read the provider file and `AGENTS.md` side by side. Separate the provider file's content into two buckets: lines that restate what `AGENTS.md` already owns (universal rules, conventions, project overview) versus lines that are genuinely provider-specific (tool syntax, IDE behavior, model-specific instructions). Rewrite the provider file:
 
-- **Providers with import syntax** (Claude Code): replace the redundant bucket with an `@AGENTS.md` (or correct relative path) import line, keep the provider-specific bucket below it.
-- **Providers without import syntax** (Cursor, Copilot, etc.): replace the redundant bucket with a short pointer sentence mentioning `AGENTS.md`, keep the provider-specific bucket.
+- **Providers with import syntax** (Claude Code): replace the redundant bucket with an `@AGENTS.md` (or correct relative path) import on a line of its own, keep the provider-specific bucket below it. An import folded into a sentence is not the thin-adapter shape and `scripts/validate-adapter.sh` will not credit it — nor one inside a code fence, an indented block, or an HTML comment, nor one whose path does not resolve to a real, non-empty file on disk.
+- **Providers without import syntax** (Cursor, Copilot, etc.): replace the redundant bucket with a short sentence pointing at `AGENTS.md` ("See AGENTS.md at the repo root for ..."), keep the provider-specific bucket. A bare or negated mention is not a pointer and will not be credited.
+
+The provider file is the only file this skill ever writes. Never create or edit `AGENTS.md` — not in this step, not in any step, whatever the payoff looks like.
+
+Strip only what is genuinely redundant. Provider-specific material stays even when it is short — the goal is thin, not empty.
 
 ## Step 3 — Self-validate
 
@@ -47,7 +45,7 @@ Run the bundled check before finishing — this is the skill's own closeout gate
 bash scripts/validate-adapter.sh [--no-import-syntax] [--max-lines N] <adapter-file> <agents-md-file>
 ```
 
-Fix any `FAIL` and re-run until it exits `0`.
+Fix any `FAIL` by editing the provider file, and re-run until it exits `0`. Exits `2` and `3` are not `FAIL`s and nothing was graded under either, so neither is a reason to touch the adapter: `2` means the invocation or the input is wrong (a bad, missing, or extra argument, an unknown option, or a file that is not UTF-8), and `3` means a named file exists but could not be read.
 
 ## Step 4 — Report
 

plugins/core/.apm/skills/provider-adapter-author/references/provider-matrix.md

@@ -0,0 +1,32 @@
+---
+source_keys:
+  - adr-0002-0003-two-tier-claude-md
+---
+
+# Known provider instruction files
+
+Which files to look for when detecting a provider-specific instruction file, whether each provider
+resolves a cross-file import, and what a thin adapter therefore looks like for it.
+
+| Provider | File(s) | Import syntax | Thin adapter shape | Validator flag |
+|---|---|---|---|---|
+| Claude Code | `CLAUDE.md` at the repo root, plus any deployed copies | Yes — `@path` lines, e.g. `@AGENTS.md` | One or more `@` import lines; no other content is required | none |
+| Cursor | `.cursor/rules/*.mdc` | No | A short sentence pointing at `AGENTS.md`, plus the rule's own frontmatter and provider-specific body | `--no-import-syntax` |
+| GitHub Copilot | `.github/copilot-instructions.md` | No | A short sentence pointing at `AGENTS.md`, plus Copilot-only instructions | `--no-import-syntax` |
+| Anything else | tool-specific instruction file at whatever path the tool documents | Assume no | Text pointer, as above | `--no-import-syntax` |
+
+A provider not listed here is not evidence it has an import mechanism. Confirm against that tool's
+own documentation before emitting an `@`-style line; an unresolved import reads as literal text and
+silently drops every rule the adapter was supposed to defer to.
+
+Detection is a search, not a lookup: a repo may hold more than one of these, and each one converts
+independently against the same `AGENTS.md`.
+
+## Standalone and composed runs behave identically
+
+This skill is reached two ways: invoked directly by a user, and composed into by `agentsmd-author`
+once it has written or updated the repo's `AGENTS.md`. Behave identically either way — do not
+assume a caller skill exists. Detect the provider file yourself, confirm `AGENTS.md` yourself, and
+run the closeout validator yourself, rather than treating any step as already done by the caller or
+as something the caller will do afterwards. No handshake exists to rely on, and no state is
+passed in beyond the file paths.

plugins/core/.apm/skills/provider-adapter-author/references/sources.md

@@ -5,5 +5,5 @@
 - **URL:** (in-repo precedent — not an external source or plugin research corpus entry)
 - **Description:** This repo's own two-tier CLAUDE.md/AGENTS.md pattern: AGENTS.md is the provider-agnostic source of always-on rules; provider-specific files (CLAUDE.md) become thin adapters that import it (`@AGENTS.md` plus provider-specific additions). Grounds this skill's entire adapter-conversion design — the "thin adapter" shape, the `@`-import convention, and the size/duplication expectations enforced by `scripts/validate-adapter.sh`.
 - **Research doc:** docs/adr/0002-two-tier-claude-md.md, docs/adr/0003-agents-md-provider-agnostic-entry-point.md, providers/claude-code/CLAUDE.md (in-repo ADRs and a live example, not a plugin research corpus entry; referenced here since this skill's design is modeled directly on an existing implementation rather than external research)
-- **Contributing files:** SKILL.md
+- **Contributing files:** SKILL.md, references/provider-matrix.md
 - **Status:** `extracted`

plugins/core/.apm/skills/provider-adapter-author/scripts/README.md

@@ -4,6 +4,25 @@ Deterministic self-check this skill shells out to instead of relying on LLM judg
 
 | File | Purpose |
 |------|---------|
-| `validate-adapter.sh` | Checks a rewritten provider file (CLAUDE.md, etc.) has a reference to AGENTS.md, doesn't duplicate its content, and stays under a thin-file line threshold |
+| `validate-adapter.sh` | Checks a rewritten provider file (CLAUDE.md, etc.) has a working reference to AGENTS.md, doesn't duplicate its content, and stays under a thin-file line threshold |
 
-Takes `<adapter-file> <agents-md-file>`, with optional `--no-import-syntax` and `--max-lines N` flags. Prints `FAIL` findings to stdout and exits non-zero on any failure.
+Takes exactly `<adapter-file> <agents-md-file>`, with optional `--no-import-syntax` and `--max-lines N` flags (also accepted as `--max-lines=N`). A third positional argument or an unknown option is an error, not something quietly ignored.
+
+## What counts as a reference to AGENTS.md
+
+Both modes require the named path to be a real path segment ending in `AGENTS.md` — `AGENTS.md` or `…/AGENTS.md`, not `NOTAGENTS.md` — that resolves on disk, relative to the adapter file, to a non-empty file. An adapter deferring to a path that is not there defers to nothing, so the check has to touch the disk rather than pattern-match the line.
+
+A reference only counts where something would actually resolve it. A line inside a fenced code block, an indented code block, or an HTML comment is not credited in either mode: Claude Code resolves an import in none of those, so a fenced `@AGENTS.md` is the silent-drop failure this gate exists to catch, not a pass.
+
+Default mode wants a real import: `@AGENTS.md` alone on its own line, indented no more than three spaces. `--no-import-syntax` wants a prose pointer that reads as one — the sentence naming `AGENTS.md` must carry a deference cue (see, read, refer to, documented in, conventions, …) and must not be negated. `Do NOT read AGENTS.md; it is obsolete.` and `We deleted AGENTS.md last year.` name the file while pointing the reader away from it, and neither is a pointer.
+
+## Exit codes
+
+The distinction matters because the skill's closeout tells the agent to fix any non-zero exit by editing the provider file. That is right for exactly one of these.
+
+| Code | Meaning | What to do |
+|------|---------|------------|
+| `0` | Passes every check | Nothing |
+| `1` | One or more `FAIL` findings printed to stdout — empty adapter, no working reference to AGENTS.md, excessive duplication, or not thin | Edit the provider file |
+| `2` | Usage or input error: a bad, missing, or extra argument, an unknown option, a path that is not a file, or a file that is not UTF-8. Nothing was graded, so there is no `FAIL` line | Fix the invocation or the file's encoding — do not edit the adapter |
+| `3` | A named input file exists but could not be read (permissions, I/O error). Nothing was graded and the adapter's contents are unknown | Fix the file's readability — do not edit the adapter |

plugins/core/.apm/skills/provider-adapter-author/scripts/validate-adapter.sh

@@ -14,27 +14,85 @@ Arguments:
   adapter-file     Path to the provider-specific file to check.
   agents-md-file   Path to the AGENTS.md file it should defer to.
 
+  Exactly two positional arguments are accepted. Extra ones are rejected
+  rather than ignored: a third path silently graded nothing but the first
+  two, so a typo'd invocation passed against the wrong file.
+
 Options:
   --no-import-syntax  The target provider has no native cross-file import
-                       mechanism. Accept a plain-text pointer mention of
-                       "AGENTS.md" instead of requiring an @import-style line.
+                       mechanism. Require a plain-text pointer line naming
+                       "AGENTS.md" instead of an @import-style line; an
+                       @AGENTS.md line alone does not satisfy it, because
+                       such a provider never resolves it. Without this flag
+                       an actual @import line is required, and naming
+                       AGENTS.md in prose alone does not satisfy it.
   --max-lines N        Max non-blank lines allowed in the adapter file before
-                       it's considered no longer "thin". Default: 60.
+                       it's considered no longer "thin". Must be a
+                       non-negative integer. Default: 60.
   --help, -h           Show this help and exit 0.
+  --                   End of options; every later argument is positional.
+
+Both flags also accept the --flag=value form (--max-lines=40). An unknown
+option is reported as an unknown option, not as a missing file.
+
+What counts as a reference:
+
+  In both modes the named path must be a real path segment ending in
+  AGENTS.md ("AGENTS.md" or ".../AGENTS.md" — not NOTAGENTS.md), and it must
+  resolve on disk, relative to the adapter file, to a non-empty file. An
+  adapter deferring to a path that is not there defers to nothing.
+
+  A mention inside a fenced code block, an indented code block, or an HTML
+  comment is not credited in either mode. Nothing resolves those, so an
+  adapter whose only "import" is fenced silently defers to nothing.
+
+  With --no-import-syntax the pointer must read as a pointer: the sentence
+  naming AGENTS.md has to carry a deference cue (see, read, refer to,
+  documented in, conventions, ...) and must not be a negation ("do not read
+  AGENTS.md", "we deleted AGENTS.md"). A bare mention is not a pointer.
 
 Exit codes:
   0  Adapter file passes all checks
   1  One or more checks failed (empty file, no reference to AGENTS.md,
      excessive duplication, or file too long)
+  2  Usage or input error — a bad, missing, or extra argument, an unknown
+     option, a path that is not a file, or a file that is not UTF-8. Nothing
+     was graded, so there is no FAIL line and no adapter edit to make: fix
+     the invocation or the file's encoding and re-run. Kept distinct from 1
+     because the skill's own closeout tells the agent to fix every non-zero
+     exit by editing the provider file, which for a mistyped flag edits the
+     wrong file forever.
+  3  A named input file exists but could not be read (permissions, a
+     directory swapped in mid-run, I/O error). Also not a FAIL: nothing was
+     graded and the adapter's contents are unknown, so editing it is
+     guesswork. Fix the file's readability and re-run.
 EOF
 }
 
 NO_IMPORT_SYNTAX=0
 MAX_LINES=60
 ARGS=()
+END_OF_OPTS=0
+
+require_int() {
+  # $1 = the value to validate
+  if [[ ! "$1" =~ ^[0-9]+$ ]]; then
+    echo "Error: --max-lines expects a non-negative integer, got '$1'." >&2
+    exit 2
+  fi
+}
 
 while [[ $# -gt 0 ]]; do
+  if [[ $END_OF_OPTS -eq 1 ]]; then
+    ARGS+=("$1")
+    shift
+    continue
+  fi
   case "$1" in
+    --)
+      END_OF_OPTS=1
+      shift
+      ;;
     --help|-h)
       usage
       exit 0
@@ -43,10 +101,38 @@ while [[ $# -gt 0 ]]; do
       NO_IMPORT_SYNTAX=1
       shift
       ;;
+    --no-import-syntax=*)
+      echo "Error: --no-import-syntax is a flag and takes no value (got '$1')." >&2
+      exit 2
+      ;;
     --max-lines)
-      MAX_LINES="${2:-}"
+      if [[ $# -lt 2 ]]; then
+        echo "Error: --max-lines requires a value (a non-negative integer)." >&2
+        exit 2
+      fi
+      MAX_LINES="$2"
+      require_int "$MAX_LINES"
       shift 2
       ;;
+    --max-lines=*)
+      MAX_LINES="${1#--max-lines=}"
+      if [[ -z "$MAX_LINES" ]]; then
+        echo "Error: --max-lines requires a value (a non-negative integer)." >&2
+        exit 2
+      fi
+      require_int "$MAX_LINES"
+      shift
+      ;;
+    -*)
+      # Reported as an unknown option rather than falling through to the
+      # positional bucket, where it used to surface as "'--bogus' is not a
+      # file" — the right exit code attached to a diagnostic that sends the
+      # reader looking for a path they never typed.
+      echo "Error: unknown option '$1'." >&2
+      echo "" >&2
+      usage >&2
+      exit 2
+      ;;
     *)
       ARGS+=("$1")
       shift
@@ -58,7 +144,14 @@ if [[ ${#ARGS[@]} -lt 2 ]]; then
   echo "Error: adapter-file and agents-md-file are required." >&2
   echo "" >&2
   usage >&2
-  exit 1
+  exit 2
+fi
+
+if [[ ${#ARGS[@]} -gt 2 ]]; then
+  echo "Error: expected exactly 2 positional arguments (adapter-file and agents-md-file), got ${#ARGS[@]}: ${ARGS[*]}." >&2
+  echo "" >&2
+  usage >&2
+  exit 2
 fi
 
 python3 -u - "${ARGS[0]}" "${ARGS[1]}" "$NO_IMPORT_SYNTAX" "$MAX_LINES" <<'PYTHON'
@@ -70,17 +163,80 @@ adapter_path, agents_md_path, no_import_syntax, max_lines = sys.argv[1:5]
 no_import_syntax = no_import_syntax == "1"
 max_lines = int(max_lines)
 
+EXIT_FAIL = 1
+EXIT_USAGE = 2
+EXIT_UNREADABLE = 3
+
 if not os.path.isfile(adapter_path):
     print(f"Error: '{adapter_path}' is not a file.", file=sys.stderr)
-    sys.exit(1)
+    sys.exit(EXIT_USAGE)
 if not os.path.isfile(agents_md_path):
     print(f"Error: '{agents_md_path}' is not a file.", file=sys.stderr)
-    sys.exit(1)
+    sys.exit(EXIT_USAGE)
 
-with open(adapter_path, encoding="utf-8", errors="replace") as f:
-    adapter_content = f.read()
-with open(agents_md_path, encoding="utf-8", errors="replace") as f:
-    agents_md_content = f.read()
+
+def read_text(path):
+    r"""File contents as text, UTF-8, every BOM stripped.
+
+    The BOM strip is not cosmetic. IMPORT_RE anchors on `^ {0,3}@`, and a BOM
+    is not whitespace in Python, so a CLAUDE.md saved by an editor that emits
+    one had its first line — the `@AGENTS.md` import, which is the whole
+    adapter — silently treated as prose. The check then said "no reference to
+    AGENTS.md" and told the author to add the line already sitting in front of
+    them. Same class of silent BOM miss recorded in scripts/skill-size-check.sh;
+    strip it at the reader so no later check has to know about it.
+
+    Every U+FEFF goes, not just one at offset 0. Stripping exactly the first
+    one left the mirror-image false FAIL for a doubled BOM (two concatenated
+    files, or a tool that re-adds one) and for a BOM mid-file at the head of
+    the import line. U+FEFF has no meaning as a character in a markdown
+    instruction file, so removing all of them cannot lose signal.
+
+    Decoding is strict, not errors="replace". Replacement mangles the file and
+    the checks then grade the mangling: a UTF-16 adapter whose first line is
+    `@AGENTS.md` decoded to interleaved NULs and failed as "no reference",
+    which is a true FAIL for a false reason and points the fix at the wrong
+    thing. But strict UTF-8 alone does not catch it — BOM-less UTF-16LE/BE and
+    UTF-32LE are *valid* UTF-8, because NUL is a legal code point, so they
+    decoded clean and produced exactly that false diagnosis anyway. The NUL
+    byte is the complete signal and is checked first: no plausible markdown
+    adapter contains one, and every UTF-16/32 encoding of ASCII is full of
+    them. A file this gate cannot read gets an encoding diagnostic and exit 2,
+    the same policy the ADR-0020 validators' read_text() uses.
+
+    A file that exists but cannot be read at all is neither a pass nor a FAIL —
+    nothing was graded — so it exits 3 rather than 1. Exit 1 sends the skill's
+    closeout into "fix the FAIL by editing the provider file", which for a file
+    it cannot open is an instruction to edit blind.
+    """
+    try:
+        with open(path, "rb") as fh:
+            raw = fh.read()
+    except OSError as exc:
+        print(f"Error: '{path}' exists but could not be read ({exc.strerror}). "
+              "Nothing was checked — fix whatever is blocking the read "
+              "(permissions, ownership, the underlying device) and re-run; do "
+              "not edit the adapter on the strength of this.", file=sys.stderr)
+        sys.exit(EXIT_UNREADABLE)
+    if b"\x00" in raw:
+        print(f"Error: '{path}' is not valid UTF-8 — it contains NUL bytes, so "
+              "it is almost certainly UTF-16 or UTF-32 (with or without a BOM). "
+              "Re-save it as UTF-8; this check does not guess at other "
+              "encodings.", file=sys.stderr)
+        sys.exit(EXIT_USAGE)
+    try:
+        text = raw.decode("utf-8")
+    except UnicodeDecodeError as exc:
+        print(f"Error: '{path}' is not valid UTF-8 ({exc.reason} at byte "
+              f"{exc.start}) — re-save it as UTF-8; this check does not guess "
+              "at other encodings.", file=sys.stderr)
+        sys.exit(EXIT_USAGE)
+    return text.replace("\ufeff", "")
+
+
+adapter_content = read_text(adapter_path)
+agents_md_content = read_text(agents_md_path)
+adapter_dir = os.path.dirname(os.path.abspath(adapter_path))
 
 has_fail = False
 
@@ -89,30 +245,229 @@ if not adapter_content.strip():
     print("      Why: An empty adapter carries no reference to AGENTS.md and no provider-specific content.")
     print("      Fix: Add at least an import (or text pointer) to AGENTS.md.")
     print()
-    sys.exit(1)
+    sys.exit(EXIT_FAIL)
 
-IMPORT_RE = re.compile(r'(?m)^\s*@\S*AGENTS\.md\s*$')
-lines = adapter_content.splitlines()
-import_lines = [ln for ln in lines if IMPORT_RE.match(ln)]
+
+# --- Inert regions -----------------------------------------------------------
+#
+# A reference only counts where something would actually resolve it. Fenced
+# code blocks, indented code blocks and HTML comments are shown to the reader
+# (or hidden from them) as literal text; Claude Code resolves an @import in
+# none of them. Without this, a ```-fenced `@AGENTS.md` — the exact
+# copy-the-example-into-the-file mistake this gate exists to catch — exited 0
+# with the adapter deferring to nothing.
+#
+# Indented code blocks are handled by IMPORT_RE's `^ {0,3}` instead of by the
+# mask: four leading spaces is what opens an indented code block in CommonMark,
+# so an import has to sit within three. The mask deliberately does not apply
+# that rule to prose pointers, where four-space indentation is ordinary list
+# continuation rather than code.
+FENCE_RE = re.compile(r'^( {0,3})(`{3,}|~{3,})(.*)$')
+COMMENT_RE = re.compile(r'<!--.*?(?:-->|\Z)', re.DOTALL)
+
+
+def line_offsets(text):
+    """[(char offset, line without its terminator)] over `text`."""
+    out = []
+    off = 0
+    for raw in text.splitlines(keepends=True):
+        out.append((off, raw.rstrip("\r\n")))
+        off += len(raw)
+    return out
+
+
+def build_inert_mask(text, offsets):
+    """Per-character flags: 1 where a reference would never be resolved."""
+    mask = bytearray(len(text))
+    fence = None  # (fence char, opening run length)
+    for start, line in offsets:
+        m = FENCE_RE.match(line)
+        if fence is None:
+            if m:
+                fence = (m.group(2)[0], len(m.group(2)))
+                for i in range(start, start + len(line)):
+                    mask[i] = 1
+            continue
+        for i in range(start, start + len(line)):
+            mask[i] = 1
+        if (m and m.group(2)[0] == fence[0]
+                and len(m.group(2)) >= fence[1]
+                and not m.group(3).strip()):
+            fence = None
+    for m in COMMENT_RE.finditer(text):
+        if m.start() < len(mask) and mask[m.start()]:
+            continue  # a literal "<!--" printed inside a fence opens nothing
+        for i in range(m.start(), min(m.end(), len(mask))):
+            mask[i] = 1
+    return mask
+
+
+# --- Reference shapes --------------------------------------------------------
+#
+# `\S*AGENTS\.md` had no path-separator boundary, so `@NOTAGENTS.md` and
+# `@zzzAGENTS.md` counted as imports of AGENTS.md. The matched path must end in
+# AGENTS.md as a whole segment.
+IMPORT_RE = re.compile(r'^ {0,3}@(?P<path>\S+?)\s*$')
+# A mention in prose: an optional relative path, then AGENTS.md, with no
+# identifier character glued to the front (so NOTAGENTS.md does not match) and
+# nothing glued to the back.
+MENTION_RE = re.compile(r'(?<![0-9A-Za-z_.\-/])((?:[\w.\-~]+/)*AGENTS\.md)(?![0-9A-Za-z])')
+
+# A pointer has to read as a pointer. `"AGENTS.md" in ln` passed
+# "Do NOT read AGENTS.md; it is obsolete." and "We deleted AGENTS.md last
+# year." — both of which point the reader away from the file. Require a
+# deference cue in the naming sentence, and reject a negated one.
+DIRECTIVE_RE = re.compile(
+    r'\b(see|read|refer|refers|referring|consult|consults|follow|follows|'
+    r'defer|defers|deferring|described|documented|documents|covered|covers|'
+    r'found|listed|specified|defined|governed|per|use|uses|using|apply|obey|'
+    r'start|check|live|lives|contains|holds|carries|inherit|inherits|import|'
+    r'imports|conventions|instructions|guidelines|guidance|rules|standards|'
+    r'reference|setup)\b', re.I)
+NEGATION_RE = re.compile(
+    r"(\bnot\b|n't\b|\bnever\b|\bno longer\b|\bdeleted\b|\bremoved\b|"
+    r"\bobsolete\b|\bdeprecated\b|\bignore\b|\bignores\b|\bignoring\b|"
+    r"\bdisregard\b|\bsuperseded\b|\bgone\b|\bunused\b|\bstale\b)", re.I)
+SENTENCE_SPLIT_RE = re.compile(r'(?<=[.;:!?])\s+')
+
+
+def sentence_around(line, index):
+    """(sentence of `line` containing character `index`, its start offset)."""
+    bounds = [0]
+    for m in SENTENCE_SPLIT_RE.finditer(line):
+        bounds.append(m.end())
+    bounds.append(len(line) + 1)
+    for i in range(len(bounds) - 1):
+        if bounds[i] <= index < bounds[i + 1]:
+            return line[bounds[i]:bounds[i + 1]], bounds[i]
+    return line, 0
+
+
+def reads_as_pointer(line, match):
+    """Does the sentence naming AGENTS.md actually point the reader at it?
+
+    The matched path is blanked out before the cues are applied. It is a
+    filename, not prose, and leaving it in let its own characters vote: the
+    perfectly ordinary `docs/does/not/exist/AGENTS.md` tripped the negation
+    cue on the `not` path segment, so a pointer got rejected for the wrong
+    reason and the near-miss line then reported the wrong diagnosis.
+    """
+    sentence, sentence_start = sentence_around(line, match.start())
+    rel_start = match.start() - sentence_start
+    rel_end = match.end() - sentence_start
+    probe = sentence[:rel_start] + " AGENTS.md " + sentence[rel_end:]
+    if NEGATION_RE.search(probe):
+        return False
+    return bool(DIRECTIVE_RE.search(probe))
+
+
+def resolve(raw_path):
+    """An import/pointer path resolved the way the provider would resolve it."""
+    p = os.path.expanduser(raw_path)
+    if not os.path.isabs(p):
+        p = os.path.join(adapter_dir, p)
+    return os.path.normpath(p)
+
+
+def target_problem(raw_path):
+    """None if `raw_path` names a real, non-empty file; else why not."""
+    resolved = resolve(raw_path)
+    if not os.path.isfile(resolved):
+        return f"'{raw_path}' resolves to {resolved}, which does not exist"
+    try:
+        if os.path.getsize(resolved) == 0:
+            return f"'{raw_path}' resolves to {resolved}, which is empty"
+        with open(resolved, "rb") as fh:
+            if not fh.read().strip():
+                return f"'{raw_path}' resolves to {resolved}, which is blank"
+    except OSError as exc:
+        return f"'{raw_path}' resolves to {resolved}, which cannot be read ({exc.strerror})"
+    return None
+
+
+def names_agents_md(path):
+    return path == "AGENTS.md" or path.endswith("/AGENTS.md")
+
+
+offsets = line_offsets(adapter_content)
+lines = [line for _, line in offsets]
+mask = build_inert_mask(adapter_content, offsets)
+
+
+def is_inert(abs_index):
+    return abs_index < len(mask) and bool(mask[abs_index])
+
+
+# Lines shaped like an @AGENTS.md import, whether or not the target resolves.
+# Used to exclude them from the duplication denominator and from the prose
+# pointer scan, both of which only care about the shape.
+import_shaped_lines = set()
+# (line, raw path) for every import whose target actually resolves.
+live_imports = []
+# Diagnostics for imports that are the right shape but resolve to nothing.
+dead_imports = []
+# Imports that exist only inside a fence or an HTML comment.
+inert_imports = []
+
+for start, line in offsets:
+    m = IMPORT_RE.match(line)
+    if not m or not names_agents_md(m.group("path")):
+        continue
+    at_index = start + line.index("@")
+    if is_inert(at_index):
+        inert_imports.append(line.strip())
+        continue
+    import_shaped_lines.add(line)
+    problem = target_problem(m.group("path"))
+    if problem:
+        dead_imports.append(problem)
+    else:
+        live_imports.append(line)
+
+live_pointers = []
+dead_pointers = []
+inert_pointers = []
+mention_only = []
+
+for start, line in offsets:
+    if line in import_shaped_lines:
+        continue
+    for m in MENTION_RE.finditer(line):
+        if is_inert(start + m.start()):
+            inert_pointers.append(line.strip())
+            continue
+        if not reads_as_pointer(line, m):
+            mention_only.append(sentence_around(line, m.start())[0].strip())
+            continue
+        problem = target_problem(m.group(1))
+        if problem:
+            dead_pointers.append(problem)
+        else:
+            live_pointers.append(line)
 
 if no_import_syntax:
-    has_reference = "AGENTS.md" in adapter_content
+    has_reference = bool(live_pointers)
+    near_misses = dead_pointers + [f"{d} (inside a code fence or HTML comment)" for d in inert_pointers]
+    near_misses += [f"'{s}' names AGENTS.md but does not point at it" for s in mention_only]
 else:
-    has_reference = bool(import_lines) or "AGENTS.md" in adapter_content
+    has_reference = bool(live_imports)
+    near_misses = dead_imports + [f"'{d}' is inside a code fence or HTML comment, where no import is resolved" for d in inert_imports]
 
 if not has_reference:
     has_fail = True
     print(f"FAIL  Adapter has no reference to AGENTS.md — {adapter_path}")
     if no_import_syntax:
-        print("      Why: This provider has no import syntax, so the adapter must at least mention AGENTS.md as a text pointer.")
-        print("      Fix: Add a sentence like \"See AGENTS.md at the repo root for shared conventions.\"")
+        print("      Why: This provider resolves no cross-file import, so the adapter must point at AGENTS.md in prose; an `@AGENTS.md` line here is inert text. The pointer has to read as a pointer and name a file that is really there — a bare or negated mention (\"we deleted AGENTS.md\") defers nothing, and neither does a mention buried in a code fence or an HTML comment.")
+        print("      Fix: Add a sentence like \"See AGENTS.md at the repo root for shared conventions.\", outside any fence, naming a path that exists relative to this file.")
     else:
-        print("      Why: A thin adapter must import AGENTS.md (e.g. `@AGENTS.md`) rather than silently omitting it.")
-        print("      Fix: Add an `@AGENTS.md` (or equivalent relative path) import line.")
+        print("      Why: A thin adapter must import AGENTS.md with an `@AGENTS.md` line of its own, indented no more than three spaces, and the path must resolve to a real non-empty file. Naming the file mid-sentence or inside backticks is prose this check will not credit; putting the line inside a ``` fence, an indented code block, or an HTML comment is worse, because nothing resolves it and it looks right.")
+        print("      Fix: Put `@AGENTS.md` (or the equivalent relative path) alone on its own line at the top level of the file, or pass --no-import-syntax if this provider resolves no imports.")
+    for miss in near_misses:
+        print(f"      Near miss: {miss}")
     print()
 
 # --- Duplication check ---
-non_import_lines = [ln for ln in lines if not IMPORT_RE.match(ln)]
+non_import_lines = [ln for ln in lines if ln not in import_shaped_lines]
 adapter_lines = [ln.strip() for ln in non_import_lines if ln.strip()]
 agents_lines = {ln.strip() for ln in agents_md_content.splitlines() if ln.strip()}
 
@@ -132,10 +487,10 @@ if non_blank_count > max_lines:
     has_fail = True
     print(f"FAIL  Adapter is not thin — {adapter_path}")
     print(f"      Why: {non_blank_count} non-blank lines exceeds the {max_lines}-line threshold for a thin adapter.")
-    print("      Fix: Move provider-agnostic content into AGENTS.md; keep only genuinely provider-specific additions here.")
+    print("      Fix: Delete the lines already covered by AGENTS.md; keep only genuinely provider-specific additions here.")
     print()
 
 if has_fail:
-    sys.exit(1)
+    sys.exit(EXIT_FAIL)
 sys.exit(0)
 PYTHON

plugins/core/.apm/skills/provider-adapter-author/tests/validate-adapter.bats

@@ -115,6 +115,51 @@ EOF
     assert_output --partial "no reference"
 }
 
+@test "the two --no-import-syntax branches disagree: a text-pointer-only adapter fails in default mode" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+See AGENTS.md at the repo root for setup, style, and testing conventions.
+
+## Copilot-specific
+Prefer inline suggestions over chat for one-line edits.
+EOF
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure
+    assert_output --partial "no reference"
+
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_success
+}
+
+@test "with --no-import-syntax, an inert @AGENTS.md line alone is not a prose pointer" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+@AGENTS.md
+
+## Copilot-specific
+Prefer inline suggestions over chat for one-line edits.
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure
+    assert_output --partial "no reference"
+}
+
+@test "--max-lines as the final argument reports a real error instead of failing silently" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@AGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD" --max-lines
+    assert_failure 2
+    assert_output --partial "--max-lines requires a value"
+}
+
+@test "--max-lines rejects a non-numeric value with a real error" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@AGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" --max-lines abc "$ADAPTER" "$AGENTS_MD"
+    assert_failure 2
+    assert_output --partial "non-negative integer"
+}
+
 @test "--help exits 0 and documents usage" {
     run bash "$SCRIPT" --help
     assert_success
@@ -123,6 +168,352 @@ EOF
 
 @test "fails with a clear error when the adapter file argument is missing" {
     run bash "$SCRIPT"
-    assert_failure
+    assert_failure 2
     assert_output --partial "required"
 }
+
+@test "a UTF-8 BOM before the @import line does not hide it" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    python3 -c "import sys; open(sys.argv[1], 'w', encoding='utf-8-sig').write('@AGENTS.md\n')" "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_success
+}
+
+@test "a usage error exits 2, a genuine finding exits 1" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@AGENTS.md" > "$ADAPTER"
+
+    run bash "$SCRIPT" --max-lines -3 "$ADAPTER" "$AGENTS_MD"
+    assert_failure 2
+    refute_output --partial "FAIL"
+
+    : > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "FAIL"
+}
+
+@test "a non-UTF-8 adapter is reported as an encoding error, not as a missing reference" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    python3 -c "import sys; open(sys.argv[1], 'wb').write('@AGENTS.md\n'.encode('utf-16'))" "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 2
+    assert_output --partial "not valid UTF-8"
+    refute_output --partial "no reference"
+}
+
+@test "an @AGENTS.md folded into a sentence fails, and the message says the import needs its own line" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    cat > "$ADAPTER" <<'EOF'
+See @AGENTS.md for shared conventions.
+EOF
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+    assert_output --partial "line of its own"
+}
+
+# --- Q1: a reference only counts where something would resolve it -------------
+
+@test "an @AGENTS.md inside a backtick code fence is not credited as an import" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    cat > "$ADAPTER" <<'EOF'
+# Claude notes
+
+Put this at the top of the file:
+
+```
+@AGENTS.md
+```
+EOF
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "an @AGENTS.md inside a tilde code fence is not credited as an import" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    cat > "$ADAPTER" <<'EOF'
+~~~
+@AGENTS.md
+~~~
+EOF
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "an @AGENTS.md in a four-space indented code block is not credited as an import" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    cat > "$ADAPTER" <<'EOF'
+# Claude notes
+
+    @AGENTS.md
+EOF
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "an @AGENTS.md inside a multi-line HTML comment is not credited as an import" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    cat > "$ADAPTER" <<'EOF'
+# Claude notes
+
+<!--
+@AGENTS.md
+-->
+EOF
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "an @AGENTS.md indented up to three spaces is still credited" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    printf '   @AGENTS.md\n' > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_success
+}
+
+# --- Q2: encodings that decode as valid UTF-8 but are not UTF-8 ---------------
+
+@test "a BOM-less UTF-16LE adapter is an encoding error, not a missing reference" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    python3 -c "import sys; open(sys.argv[1], 'wb').write('@AGENTS.md\n'.encode('utf-16-le'))" "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 2
+    assert_output --partial "not valid UTF-8"
+    refute_output --partial "no reference"
+}
+
+@test "a BOM-less UTF-32LE adapter is an encoding error, not a missing reference" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    python3 -c "import sys; open(sys.argv[1], 'wb').write('@AGENTS.md\n'.encode('utf-32-le'))" "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 2
+    assert_output --partial "not valid UTF-8"
+    refute_output --partial "no reference"
+}
+
+@test "a doubled UTF-8 BOM does not hide the @import line" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    python3 -c "import sys; open(sys.argv[1], 'wb').write(('@AGENTS.md\n').encode('utf-8'))" "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_success
+}
+
+@test "a BOM in front of a mid-file @import line does not hide it" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    python3 -c "import sys; open(sys.argv[1], 'wb').write(('# Claude notes\n\n@AGENTS.md\n').encode('utf-8'))" "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_success
+}
+
+# --- Q3: a file that exists but cannot be read is not a FAIL -----------------
+
+@test "an adapter that exists but cannot be read exits 3 with a diagnostic and no FAIL" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@AGENTS.md" > "$ADAPTER"
+    chmod 000 "$ADAPTER"
+    # chmod is not enough under a uid that bypasses it (root in CI containers).
+    # /proc/self/mem is a regular file whose read returns EIO for every uid, so
+    # it exercises the same branch where chmod cannot.
+    if cat "$ADAPTER" >/dev/null 2>&1; then
+        if [ -e /proc/self/mem ]; then
+            ADAPTER=/proc/self/mem
+        else
+            chmod 644 "$TMPDIR/CLAUDE.md"
+            skip "no way to make a readable-by-stat, unreadable-by-open file here"
+        fi
+    fi
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    chmod 644 "$TMPDIR/CLAUDE.md"
+    assert_failure 3
+    assert_output --partial "could not be read"
+    refute_output --partial "FAIL"
+}
+
+# --- Q4: the reference has to name, and resolve to, a real AGENTS.md ---------
+
+@test "an @import naming a path that does not exist is not credited" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@docs/does/not/exist/AGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+    assert_output --partial "does not exist"
+}
+
+@test "@NOTAGENTS.md and @zzzAGENTS.md are not imports of AGENTS.md" {
+    # The decoys are real files, so the on-disk resolution check cannot be what
+    # rejects them. Only the path-segment boundary can — without the fixtures
+    # this test passes against a substring match and proves nothing.
+    cp "$AGENTS_MD" "$TMPDIR/NOTAGENTS.md"
+    cp "$AGENTS_MD" "$TMPDIR/zzzAGENTS.md"
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@NOTAGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+
+    echo "@zzzAGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "an @import resolving to a zero-byte AGENTS.md is not credited" {
+    SUB="$TMPDIR/empty"
+    mkdir -p "$SUB"
+    : > "$SUB/AGENTS.md"
+    ADAPTER="$SUB/CLAUDE.md"
+    echo "@AGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+    assert_output --partial "empty"
+}
+
+@test "an @import naming a real relative path to AGENTS.md is credited" {
+    mkdir -p "$TMPDIR/docs"
+    cp "$AGENTS_MD" "$TMPDIR/docs/AGENTS.md"
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@docs/AGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD"
+    assert_success
+}
+
+# --- Q5: --no-import-syntax needs a pointer, not a mention -------------------
+
+@test "with --no-import-syntax, a negated mention of AGENTS.md is not a pointer" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+Do NOT read AGENTS.md; it is obsolete.
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "with --no-import-syntax, a past-tense mention of a deleted AGENTS.md is not a pointer" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+We deleted AGENTS.md last year.
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "with --no-import-syntax, a pointer inside a code fence is not credited" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+Example of what to write:
+
+```
+See AGENTS.md at the repo root for shared conventions.
+```
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "with --no-import-syntax, a pointer inside an HTML comment is not credited" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+# Copilot instructions
+
+<!-- See AGENTS.md at the repo root for shared conventions. -->
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "with --no-import-syntax, a name merely ending in AGENTS.md is not a pointer to it" {
+    # Real decoy files, so the on-disk resolution check cannot be what rejects
+    # these — only the token boundary in the mention pattern can. zzzAGENTS.md
+    # is the load-bearing case: dropping the boundary from NOTAGENTS.md leaves
+    # the fragment "NOT" behind, which the negation cue then rejects for an
+    # unrelated reason, so that case alone would prove nothing.
+    cp "$AGENTS_MD" "$TMPDIR/zzzAGENTS.md"
+    cp "$AGENTS_MD" "$TMPDIR/NOTAGENTS.md"
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+See zzzAGENTS.md at the repo root for shared conventions.
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+
+    cat > "$ADAPTER" <<'EOF'
+See NOTAGENTS.md at the repo root for shared conventions.
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}
+
+@test "with --no-import-syntax, a pointer naming a path that does not exist is not credited" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+See docs/does/not/exist/AGENTS.md for shared conventions.
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+    assert_output --partial "does not exist"
+}
+
+# --- argument handling -------------------------------------------------------
+
+@test "a third positional argument is rejected instead of silently ignored" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@AGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" "$ADAPTER" "$AGENTS_MD" "$TMPDIR/also-not-graded.md"
+    assert_failure 2
+    assert_output --partial "exactly 2 positional arguments"
+    # The usage text this prints mentions the word FAIL, so refute the shape of
+    # a real finding line rather than the bare word.
+    refute_output --partial "FAIL  Adapter"
+}
+
+@test "an unknown option is reported as an unknown option, not as a missing file" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    echo "@AGENTS.md" > "$ADAPTER"
+    run bash "$SCRIPT" --bogus "$ADAPTER" "$AGENTS_MD"
+    assert_failure 2
+    assert_output --partial "unknown option '--bogus'"
+    refute_output --partial "'--bogus' is not a file"
+    refute_output --partial "FAIL  Adapter"
+}
+
+@test "--max-lines=N is accepted in the equals form" {
+    ADAPTER="$TMPDIR/CLAUDE.md"
+    {
+        echo "@AGENTS.md"
+        for i in $(seq 1 10); do echo "Provider-specific line $i unrelated to AGENTS.md content."; done
+    } > "$ADAPTER"
+    run bash "$SCRIPT" --max-lines=5 "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "thin"
+
+    run bash "$SCRIPT" --max-lines=40 "$ADAPTER" "$AGENTS_MD"
+    assert_success
+}
+
+@test "with --no-import-syntax, a bare mention with no deference cue is not a pointer" {
+    ADAPTER="$TMPDIR/copilot-instructions.md"
+    cat > "$ADAPTER" <<'EOF'
+# Copilot instructions
+
+This repo also has an AGENTS.md.
+
+Prefer inline suggestions over chat for one-line edits.
+EOF
+    run bash "$SCRIPT" --no-import-syntax "$ADAPTER" "$AGENTS_MD"
+    assert_failure 1
+    assert_output --partial "no reference"
+}

plugins/core/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "core",
-  "version": "1.1.1",
+  "version": "1.1.2",
   "description": "Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.",
   "author": {
     "name": "Defame1297",

plugins/core/.github/plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "core",
-  "version": "1.1.1",
+  "version": "1.1.2",
   "description": "Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.",
   "author": {
     "name": "Defame1297",

plugins/core/apm.yml

@@ -1,5 +1,5 @@
 name: core
-version: 1.1.1
+version: 1.1.2
 description: Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.
 author:
   name: Defame1297

plugins/core/skills/agentsmd-audit/README.md

@@ -1,35 +0,0 @@
-# agentsmd-audit
-
-Audit a target repo's AGENTS.md file(s) for embedded secrets, structural completeness, and drift.
-
-## What it does
-
-Runs a single combined pass across every AGENTS.md file in a repo (root and any nested monorepo files): flags embedded secrets/credentials, checks structure against the agents.md common-sections checklist, and resolves referenced commands/paths against the actual repo to catch stale documentation. Outputs a compact findings report — findings only, grouped by dimension, each with Why and Fix. Never inspects provider-specific adapter files (CLAUDE.md, etc.) and never writes or fixes anything.
-
-## Usage
-
-```
-/agentsmd-audit
-```
-
-Provide the path to the repo root to audit when invoking.
-
-## Files
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Skill instructions for agents |
-| `scripts/validate-secrets.sh` | Scans AGENTS.md files for embedded secrets, API keys, tokens, connection strings |
-| `scripts/validate-structure.sh` | Checks for empty/placeholder content, common-sections checklist, nested-vs-root duplication |
-| `scripts/validate-drift.sh` | Resolves referenced npm/make commands and file paths against the repo |
-| `references/sources.md` | Provenance record — sources that informed this skill and which files each contributed to |
-| `scripts/README.md` | Directory documentation for `scripts/` |
-| `tests/README.md` | (source-only) Bats test dependency and run instructions |
-| `tests/validate-secrets.bats` | (source-only) Bats test suite for `scripts/validate-secrets.sh` |
-| `tests/validate-structure.bats` | (source-only) Bats test suite for `scripts/validate-structure.sh` |
-| `tests/validate-drift.bats` | (source-only) Bats test suite for `scripts/validate-drift.sh` |
-
-Rows marked **(source-only)** exist in the authoring source (`.apm/skills/agentsmd-audit/`) but are
-not present in an installed plugin: `scripts/sync-plugin-content.sh` strips `<category>/<name>/tests`
-when it generates the flat mirror, because these are dev-time fixtures no plugin host needs to
-discover (ADR-0017). Run them from a repo checkout, not from an install.

plugins/core/skills/agentsmd-audit/SKILL.md

@@ -1,20 +1,11 @@
 ---
 name: agentsmd-audit
 description: >
-  Use when the user wants to review a repo's AGENTS.md file, says "audit this
-  AGENTS.md", "check my AGENTS.md", "is this AGENTS.md any good", or wants to
-  know if AGENTS.md is safe to commit — even if they don't use the word
-  "audit". Also invoke proactively after agentsmd-author creates or updates
-  AGENTS.md, or after a hand-edit made outside agentsmd-author. Audits a
-  target repo's AGENTS.md file(s) — root and any nested monorepo files — for
-  embedded secrets/credentials, structural completeness against the
-  agents.md common-sections checklist, and drift (referenced commands or
-  paths that no longer resolve against the repo). Produces a compact
-  findings report (findings only, no PASS noise) with Why and Fix per
-  finding. Do not use to audit CLAUDE.md, .cursor/rules, or other
-  provider-specific adapter files — that's provider-adapter-author's
-  self-contained concern. Do not use to fix or write AGENTS.md content — use
-  agentsmd-author instead.
+  Use when the user wants a repo's AGENTS.md audited for secrets, structure
+  and drift — "is this AGENTS.md safe to commit" — or after a hand-edit
+  outside `agentsmd-author`.
+  Not converting a provider file -> `provider-adapter-author`.
+  Not writing AGENTS.md -> `agentsmd-author`.
 allowed-tools: Bash Read
 metadata:
   category: docs
@@ -23,14 +14,13 @@ metadata:
     - context7-websites-agents-md
     - context7-agentsmd-agents-md
     - governance-secrets-hard-prohibition
-  version: "0.1.1"
+  version: "0.1.2"
 ---
 
 ## Gotchas
 
 - Always run all three checks — this skill does a single combined pass, not staged/gated passes. Don't skip structure or drift checks just because a secrets FAIL was found.
-- Never inspect or mention provider-specific adapter files (`CLAUDE.md`, `.cursor/rules/*.mdc`, `copilot-instructions.md`, etc.) — that's out of scope. If one exists and duplicates AGENTS.md content, that's `provider-adapter-author`'s concern, not this skill's.
-- A missing common section (e.g. no "Security" heading) is informational, not a failure — not every repo needs every section from the checklist. Only flag a FAIL when the file is empty, entirely unfilled placeholder text, or contains a real embedded secret/stale reference.
+- Never inspect or mention provider-specific adapter files (`CLAUDE.md`, `.cursor/rules/*.mdc`, `copilot-instructions.md`, etc.) — that's out of scope.
 - Gather findings internally; don't narrate PASS/FAIL per check as you go — surface them only in the final report.
 
 ## Step 1 — Run the validators
@@ -41,7 +31,7 @@ bash scripts/validate-structure.sh <repo-root>
 bash scripts/validate-drift.sh <repo-root>
 ```
 
-Each script walks the repo for every `AGENTS.md` file (root and nested, excluding `.git`, `node_modules`, `vendor`, and similar) and prints `FAIL`/`INFO`/`SUGGESTION` lines with `Why`/`Fix` (or `Note`) per finding. A nonzero exit means at least one FAIL was found in that dimension. If a script cannot execute (`python3` unavailable, Bash denied), fall back to manual review: scan for real-looking credentials, check common sections are present, and spot-check a few referenced commands/paths by hand.
+Each script walks the repo for every `AGENTS.md` file (root and nested, excluding `.git`, `node_modules`, `vendor`, and similar) and prints `FAIL` lines, plus `INFO`/`SUGGESTION` where applicable, with `Why`/`Fix` (or `Note`) per finding. A nonzero exit means at least one FAIL was found in that dimension. If a script cannot execute (`python3` unavailable, Bash denied), fall back to manual review: scan for real-looking credentials, check common sections are present, and spot-check a few referenced commands/paths by hand. Grade a manual finding the way the scripts grade theirs: a missing common section (e.g. no "Security" heading) is informational, not a failure — not every repo needs every section from the checklist. Only flag a FAIL when the file is empty, entirely unfilled placeholder text, or contains a real embedded secret/stale reference.
 
 ## Step 2 — Report
 
@@ -53,16 +43,4 @@ Checked: secrets · structure · drift
 
 Then output only findings that were found, in this order within a repo: `### Secrets`, `### Structure`, `### Drift`. Omit a dimension heading entirely if it produced nothing — its absence confirms it passed. Report each finding verbatim as emitted by the scripts (they already carry file:line, Why/Fix or Note).
 
-Close with a result block:
-
-```text
-## Result
-
-PASS
-PASS · P info
-PASS (N suggestions) · P info
-FAIL (N fails)
-FAIL (N fails) · P info
-```
-
-INFO and SUGGESTION findings are observational — they never flip PASS to FAIL. Do not fix anything — this skill reports and proposes only. Point the user to `agentsmd-author` to apply fixes.
+Close with a `## Result` block holding one line: `PASS`, `PASS (N suggestions)`, or `FAIL (N fails · M suggestions)`, each optionally followed by ` · P info`. Omit the suggestion count when there are none, and omit `· P info` when there are none. INFO and SUGGESTION findings are observational — they never flip PASS to FAIL. Do not fix anything — this skill reports and proposes only. Point the user to `agentsmd-author` to apply fixes.

plugins/core/skills/agentsmd-author/README.md

@@ -1,27 +0,0 @@
-# agentsmd-author
-
-Create or update a target repo's AGENTS.md file(s) by exploring the repo for real conventions.
-
-## What it does
-
-Explores a target repo (package manager scripts, Makefile/task runner, CI config, linter config, existing docs) and writes or updates `AGENTS.md` with only verified commands and conventions — never invented ones. Supports nested monorepo placement, following the agents.md standard's nearest-file-wins precedence. Closes every run by invoking `agentsmd-audit` inline, and hands off to `provider-adapter-author` when an existing provider-specific file (CLAUDE.md, etc.) now duplicates content AGENTS.md owns.
-
-## Before you start
-
-The `agentsmd-audit` skill must be available (co-installed in the `core` plugin) — this skill invokes it as a mandatory closeout step.
-
-## Usage
-
-```
-/agentsmd-author
-```
-
-Provide the target repo root (defaults to the current directory) and, if relevant, which subdirectory should get a nested AGENTS.md.
-
-## Files
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Skill instructions for agents |
-| `references/content-guide.md` | Section-by-section AGENTS.md content guidance, a worked example, and monorepo/nested-file precedence rules |
-| `references/sources.md` | Provenance record — sources that informed this skill and which files each contributed to |

plugins/core/skills/agentsmd-author/SKILL.md

@@ -1,20 +1,10 @@
 ---
 name: agentsmd-author
 description: >
-  Use when the user wants to create or update a repo's AGENTS.md file
-  ("write an AGENTS.md for this repo", "add setup/test instructions for
-  agents", "update AGENTS.md", "give this package its own AGENTS.md") — even
-  if they don't name the file explicitly, e.g. "document this for AI coding
-  tools" or "make sure agents know how to run tests here". Writes/updates
-  AGENTS.md by exploring the target repo for real build, test, lint, and
-  style conventions — never invents commands. Supports nested monorepo
-  placement (a subdirectory can get its own AGENTS.md following
-  nearest-file-wins precedence). Closes every run by invoking agentsmd-audit
-  inline, and calls provider-adapter-author when an existing provider file
-  (CLAUDE.md, etc.) now duplicates what AGENTS.md owns. Do not use to review
-  an existing AGENTS.md without changing it — use agentsmd-audit instead. Do
-  not use to convert CLAUDE.md/.cursor/rules into a thin adapter — use
-  provider-adapter-author instead.
+  Use when the user wants a repo's AGENTS.md written or updated, root or
+  nested, including "document this for AI coding tools". Writes only verified
+  conventions. Not review-only -> `agentsmd-audit`. Not converting CLAUDE.md ->
+  `provider-adapter-author`.
 allowed-tools: Bash Read Write Edit
 metadata:
   category: docs
@@ -22,16 +12,13 @@ metadata:
     - agents-md-official
     - context7-websites-agents-md
     - context7-agentsmd-agents-md
-  version: "0.1.1"
+  version: "0.1.2"
 ---
 
 ## Gotchas
 
 - Never invent a command. Every line under a setup/test/build section must come from something you actually found in the repo (`package.json` scripts, a `Makefile` target, a CI workflow step, a README). If you can't verify a command, don't include it.
-- AGENTS.md has no required schema — don't force every common-sections-checklist heading into every repo. Include only sections that reflect something real about this repo; a thin, accurate file beats a padded, generic one.
-- Nested placement is for genuinely different conventions, not convenience. Only create a subdirectory AGENTS.md when that subtree has its own build tool, stack, or conventions distinct from the root — otherwise you're duplicating content the root already covers, which the nearest-file-wins rule doesn't merge back together.
-- This skill never touches CLAUDE.md, `.cursor/rules/*.mdc`, `copilot-instructions.md`, or similar provider files directly — that's `provider-adapter-author`'s job. Detect and hand off; don't reconcile it yourself.
-- This skill never audits on its own judgment — the closing `agentsmd-audit` invocation is mandatory, not optional, even when the change looks trivial.
+- Never write to a provider file yourself, in any circumstance: `CLAUDE.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md` and their equivalents are `provider-adapter-author`'s to own. That holds even when the user asks for one in the same breath as AGENTS.md, and even when the file is merely stale or missing a pointer rather than duplicating anything. Detect it and hand off.
 
 ## Step 1 — Explore the target repo
 
@@ -40,17 +27,17 @@ Before writing anything, gather real facts: package manager and scripts (`packag
 ## Step 2 — Decide placement
 
 - No `AGENTS.md` at the repo root yet → create one there first, covering whole-repo conventions.
-- A subdirectory has materially different build/test tooling or conventions than the root → create or update a nested `AGENTS.md` there, scoped to what's different. Don't repeat root-level content — the nearest-file-wins rule means the nested file is read alone, not merged with the root.
+- A subdirectory has materially different build/test tooling or conventions than the root → create or update a nested `AGENTS.md` there, scoped to what's different. Convenience is not a reason to create one — without a distinct stack you are duplicating content the root already covers. **Don't repeat root-level content** in a nested file: the nearest-file-wins rule means it is read alone, never merged back with the root.
 - Otherwise → update the existing file(s) in place.
 
 ## Step 3 — Write or update
 
-Use only sections that reflect something real about the repo — never fill in every common-sections-checklist heading just because it exists. Read `references/content-guide.md` for section-by-section guidance, a worked example, and what separates useful content from generic padding, before writing.
+AGENTS.md has no required schema. Use only sections that reflect something real about the repo — never fill in every common-sections-checklist heading just because it exists, because a thin accurate file beats a padded generic one. Read `references/content-guide.md` for section-by-section guidance, a worked example, and what separates useful content from generic padding, before writing.
 
 ## Step 4 — Check for an existing provider file
 
-Look for `CLAUDE.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, or similar in the target repo. If one exists and now duplicates content the AGENTS.md you just wrote/updated already owns, invoke the `provider-adapter-author` skill on it to reconcile — don't rewrite it yourself.
+Look for `CLAUDE.md`, `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, or similar in the target repo. If one exists, invoke the `provider-adapter-author` skill on it to reconcile — whether it duplicates content the AGENTS.md you just wrote/updated now owns, or is merely stale or missing a pointer to it. Never edit it yourself in either case.
 
 ## Step 5 — Audit and report
 
-Invoke the `agentsmd-audit` skill directly on the AGENTS.md file(s) you just wrote or updated. Resolve any FAIL findings before considering the work done — re-invoke this skill's own writing steps to fix them, then re-run the audit, same as any other close-the-loop check. Report what was created/changed, whether a provider file was reconciled, and the audit's final result.
+Invoke the `agentsmd-audit` skill on the target repo root — its validators take a `<repo-root>` and walk the tree for every AGENTS.md themselves; there is no per-file entry point. This closeout is mandatory, not optional, even when the change looks trivial — never sign the work off on your own judgment. Resolve any FAIL findings before considering the work done — re-invoke this skill's own writing steps to fix them, then re-run the audit, same as any other close-the-loop check. Report what was created/changed, whether a provider file was reconciled, and the audit's final result.

plugins/core/skills/provider-adapter-author/README.md

@@ -1,35 +0,0 @@
-# provider-adapter-author
-
-Convert a target repo's provider-specific instruction file (CLAUDE.md, .cursor/rules, copilot-instructions.md, etc.) into a thin adapter over AGENTS.md.
-
-## What it does
-
-Detects a provider-specific AI instruction file in a target repo, diffs it against the repo's `AGENTS.md`, and rewrites it down to a minimal reference — an `@AGENTS.md`-style import for providers that support one, or a text pointer for those that don't — plus only genuinely provider-specific additions. Self-validates its own output with a bundled deterministic script (no LLM judgment, no separate audit skill) before finishing.
-
-## Before you start
-
-The target repo must already have an `AGENTS.md`. If it doesn't, run `agentsmd-author` first — this skill never creates or edits `AGENTS.md` itself.
-
-## Usage
-
-```
-/provider-adapter-author
-```
-
-Provide the path to the provider-specific file to convert (and the target repo root, if not inferable). Can be invoked directly, or composed into by `agentsmd-author` when it detects an existing provider file with content overlapping AGENTS.md.
-
-## Files
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Skill instructions for agents |
-| `references/sources.md` | Provenance record — the in-repo ADR precedent this skill's design is modeled on |
-| `scripts/validate-adapter.sh` | Self-check gate: reference to AGENTS.md present, no excessive duplication, adapter stays thin |
-| `scripts/README.md` | Directory documentation for `scripts/` |
-| `tests/README.md` | (source-only) Bats test dependency and run instructions |
-| `tests/validate-adapter.bats` | (source-only) Bats test suite for `scripts/validate-adapter.sh` |
-
-Rows marked **(source-only)** exist in the authoring source (`.apm/skills/provider-adapter-author/`)
-but are not present in an installed plugin: `scripts/sync-plugin-content.sh` strips
-`<category>/<name>/tests` when it generates the flat mirror, because these are dev-time fixtures no
-plugin host needs to discover (ADR-0017). Run them from a repo checkout, not from an install.

plugins/core/skills/provider-adapter-author/SKILL.md

@@ -1,43 +1,41 @@
 ---
 name: provider-adapter-author
 description: >
-  Use when the user wants to convert a provider-specific AI instruction file
-  (CLAUDE.md, .cursor/rules/*.mdc, copilot-instructions.md, etc.) into a
-  thin adapter that defers to a repo's AGENTS.md — e.g. "reduce duplication
-  between CLAUDE.md and AGENTS.md", "make CLAUDE.md just import AGENTS.md"
-  — even if the pattern isn't named explicitly. Also invoke when
-  agentsmd-author detects an existing provider file overlapping with
-  AGENTS.md it just wrote. Detects redundant content in a provider file
-  relative to AGENTS.md and rewrites it down to a minimal reference (an
-  `@AGENTS.md`-style import where supported, or a text pointer otherwise)
-  plus genuinely provider-specific additions. Self-validates via a bundled
-  deterministic script before finishing. Do not use to write or audit
-  AGENTS.md itself — use agentsmd-author or agentsmd-audit.
+  Use when a provider file (CLAUDE.md, .cursor rules, copilot-instructions)
+  duplicating the repo's AGENTS.md should be cut to a thin adapter — "make
+  CLAUDE.md just import AGENTS.md".
+  Not writing the AGENTS file -> `agentsmd-author`.
+  Not auditing the AGENTS file -> `agentsmd-audit`.
 allowed-tools: Bash Read Edit Write
 metadata:
   category: docs
   source_keys:
     - adr-0002-0003-two-tier-claude-md
-  version: "0.1.0"
+  version: "0.1.1"
 ---
 
 ## Gotchas
 
-- Not every provider supports cross-file imports. Claude Code does — a `CLAUDE.md` can consist of nothing but one or more `@path` lines (e.g. `@AGENTS.md`), with no other content required. Cursor's `.cursor/rules/*.mdc` and GitHub Copilot's `copilot-instructions.md` have no native import mechanism as of current tooling — for those, "thin" means a short text pointer to AGENTS.md plus only what that tool actually needs, not a literal import line. Pass `--no-import-syntax` to `scripts/validate-adapter.sh` for these providers.
-- This skill never creates or edits `AGENTS.md` itself. If the target repo has no `AGENTS.md` yet, stop and point the user to `agentsmd-author` first — there's nothing to adapt to.
-- Only strip content from the provider file that's genuinely redundant with AGENTS.md. Provider-specific material (IDE settings, tool-only syntax, model-specific instructions) stays — the goal is thin, not empty.
-- Works standalone or composed-into by `agentsmd-author` — behave identically either way; don't assume a caller skill exists.
+- Assume a provider has no cross-file import mechanism until you have confirmed it has one. Claude Code is the exception, not the rule: a `CLAUDE.md` may consist of nothing but `@path` lines, while the same `@AGENTS.md` line in a Cursor rule or a Copilot instructions file is inert text no tool resolves. Pass `--no-import-syntax` to `scripts/validate-adapter.sh` for those providers.
+
+- Works standalone or composed-into by `agentsmd-author` — behave identically either way; do not assume a caller skill exists. Detect the provider file, confirm `AGENTS.md`, and run the closeout validator yourself in both cases (`references/provider-matrix.md`).
 
 ## Step 1 — Detect
 
-Look for known provider instruction files in the target repo: `CLAUDE.md` (repo root, and any deployed copies), `.cursor/rules/*.mdc`, `.github/copilot-instructions.md`, and similar tool-specific files. Confirm `AGENTS.md` exists at the repo root — if not, stop and tell the user to run `agentsmd-author` first.
+Find the provider instruction file to convert. Before searching, read `references/provider-matrix.md` — skip it only when the target is already a known root `CLAUDE.md`, which is the common case.
+
+Then confirm `AGENTS.md` exists at the repo root. If it does not, stop and tell the user to run `agentsmd-author` first — there is nothing to adapt to.
 
 ## Step 2 — Diff and rewrite
 
 Read the provider file and `AGENTS.md` side by side. Separate the provider file's content into two buckets: lines that restate what `AGENTS.md` already owns (universal rules, conventions, project overview) versus lines that are genuinely provider-specific (tool syntax, IDE behavior, model-specific instructions). Rewrite the provider file:
 
-- **Providers with import syntax** (Claude Code): replace the redundant bucket with an `@AGENTS.md` (or correct relative path) import line, keep the provider-specific bucket below it.
-- **Providers without import syntax** (Cursor, Copilot, etc.): replace the redundant bucket with a short pointer sentence mentioning `AGENTS.md`, keep the provider-specific bucket.
+- **Providers with import syntax** (Claude Code): replace the redundant bucket with an `@AGENTS.md` (or correct relative path) import on a line of its own, keep the provider-specific bucket below it. An import folded into a sentence is not the thin-adapter shape and `scripts/validate-adapter.sh` will not credit it — nor one inside a code fence, an indented block, or an HTML comment, nor one whose path does not resolve to a real, non-empty file on disk.
+- **Providers without import syntax** (Cursor, Copilot, etc.): replace the redundant bucket with a short sentence pointing at `AGENTS.md` ("See AGENTS.md at the repo root for ..."), keep the provider-specific bucket. A bare or negated mention is not a pointer and will not be credited.
+
+The provider file is the only file this skill ever writes. Never create or edit `AGENTS.md` — not in this step, not in any step, whatever the payoff looks like.
+
+Strip only what is genuinely redundant. Provider-specific material stays even when it is short — the goal is thin, not empty.
 
 ## Step 3 — Self-validate
 
@@ -47,7 +45,7 @@ Run the bundled check before finishing — this is the skill's own closeout gate
 bash scripts/validate-adapter.sh [--no-import-syntax] [--max-lines N] <adapter-file> <agents-md-file>
 ```
 
-Fix any `FAIL` and re-run until it exits `0`.
+Fix any `FAIL` by editing the provider file, and re-run until it exits `0`. Exits `2` and `3` are not `FAIL`s and nothing was graded under either, so neither is a reason to touch the adapter: `2` means the invocation or the input is wrong (a bad, missing, or extra argument, an unknown option, or a file that is not UTF-8), and `3` means a named file exists but could not be read.
 
 ## Step 4 — Report
 

plugins/core/skills/provider-adapter-author/references/provider-matrix.md

@@ -0,0 +1,32 @@
+---
+source_keys:
+  - adr-0002-0003-two-tier-claude-md
+---
+
+# Known provider instruction files
+
+Which files to look for when detecting a provider-specific instruction file, whether each provider
+resolves a cross-file import, and what a thin adapter therefore looks like for it.
+
+| Provider | File(s) | Import syntax | Thin adapter shape | Validator flag |
+|---|---|---|---|---|
+| Claude Code | `CLAUDE.md` at the repo root, plus any deployed copies | Yes — `@path` lines, e.g. `@AGENTS.md` | One or more `@` import lines; no other content is required | none |
+| Cursor | `.cursor/rules/*.mdc` | No | A short sentence pointing at `AGENTS.md`, plus the rule's own frontmatter and provider-specific body | `--no-import-syntax` |
+| GitHub Copilot | `.github/copilot-instructions.md` | No | A short sentence pointing at `AGENTS.md`, plus Copilot-only instructions | `--no-import-syntax` |
+| Anything else | tool-specific instruction file at whatever path the tool documents | Assume no | Text pointer, as above | `--no-import-syntax` |
+
+A provider not listed here is not evidence it has an import mechanism. Confirm against that tool's
+own documentation before emitting an `@`-style line; an unresolved import reads as literal text and
+silently drops every rule the adapter was supposed to defer to.
+
+Detection is a search, not a lookup: a repo may hold more than one of these, and each one converts
+independently against the same `AGENTS.md`.
+
+## Standalone and composed runs behave identically
+
+This skill is reached two ways: invoked directly by a user, and composed into by `agentsmd-author`
+once it has written or updated the repo's `AGENTS.md`. Behave identically either way — do not
+assume a caller skill exists. Detect the provider file yourself, confirm `AGENTS.md` yourself, and
+run the closeout validator yourself, rather than treating any step as already done by the caller or
+as something the caller will do afterwards. No handshake exists to rely on, and no state is
+passed in beyond the file paths.