Merge pull request 'docs: cut the every-session context set by 74%, and fix what the cut broke' (#105) from docs/slim-agents-md into main

Reviewed-on: https://git.dev.rkdr.net/Defame1297/holocron/pulls/105
Reviewed-by: Defame1297 <gitea@rkdr.net>

.agents/plugins/marketplace.json

@@ -0,0 +1,95 @@
+{
+  "name": "holocron",
+  "interface": {
+    "displayName": "holocron"
+  },
+  "plugins": [
+    {
+      "name": "kyberforge",
+      "source": {
+        "source": "local",
+        "path": "./plugins/kyberforge"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Developer Tools"
+    },
+    {
+      "name": "bin",
+      "source": {
+        "source": "local",
+        "path": "./plugins/bin"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Utilities"
+    },
+    {
+      "name": "git",
+      "source": {
+        "source": "local",
+        "path": "./plugins/git"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Version Control"
+    },
+    {
+      "name": "gitea",
+      "source": {
+        "source": "local",
+        "path": "./plugins/gitea"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Version Control"
+    },
+    {
+      "name": "core",
+      "source": {
+        "source": "local",
+        "path": "./plugins/core"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
+    },
+    {
+      "name": "mattpocock-skills",
+      "source": {
+        "source": "url",
+        "url": "mattpocock/skills",
+        "ref": "v1.2.3",
+        "sha": "835450ef244ab7335f75d95b83e7d979eae22a6d",
+        "tag_pattern": "v{version}"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Productivity"
+    },
+    {
+      "name": "lint",
+      "source": {
+        "source": "local",
+        "path": "./plugins/lint"
+      },
+      "policy": {
+        "installation": "AVAILABLE",
+        "authentication": "ON_INSTALL"
+      },
+      "category": "Developer Tools"
+    }
+  ]
+}

.claude-plugin/marketplace.json

@@ -1,49 +1,67 @@
 {
-  "description": "AI development skills for Claude Code and GitHub Copilot CLI \u2014 factory, design, implement, review, and cross-cutting workflows.",
   "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",
   "owner": {
+    "name": "Defame1297",
     "email": "defame1297@rkdr.net",
-    "name": "Defame1297"
+    "url": "https://git.dev.rkdr.net/Defame1297/"
   },
   "plugins": [
     {
-      "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
       "name": "kyberforge",
+      "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
+      "version": "1.6.0",
+      "category": "Developer Tools",
       "source": "./plugins/kyberforge"
     },
     {
-      "description": "A place for things to be binned",
       "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",
+      "category": "Utilities",
       "source": "./plugins/bin"
     },
     {
-      "description": "Skills for working with Git \u2014 conventional commits, branch management, pull requests, and feature flow.",
       "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",
+      "category": "Version Control",
       "source": "./plugins/git"
     },
     {
-      "description": "Skills for managing Gitea repositories \u2014 issues, pull requests, milestones, releases, and wikis.",
       "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",
+      "category": "Version Control",
       "source": "./plugins/gitea"
     },
     {
-      "description": "Cross-cutting utility skills for everyday AI-assisted coding \u2014 triage, diagnosis, architecture review, and session navigation.",
       "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",
+      "category": "Productivity",
       "source": "./plugins/core"
     },
     {
-      "description": "Skills for Real Engineers \u2014 planning, TDD, architecture, and debugging workflows from Matt Pocock's .claude directory.",
       "name": "mattpocock-skills",
+      "description": "Skills for Real Engineers — planning, TDD, architecture, and debugging workflows from Matt Pocock's .claude directory.",
+      "version": "1.2.3",
+      "category": "Productivity",
       "source": {
+        "source": "github",
         "repo": "mattpocock/skills",
-        "source": "github"
+        "ref": "v1.2.3",
+        "sha": "835450ef244ab7335f75d95b83e7d979eae22a6d",
+        "tag_pattern": "v{version}"
       }
     },
     {
-      "description": "Skills and agents for configuring and running linters.",
       "name": "lint",
+      "description": "Skills and agents for configuring and running linters.",
+      "version": "1.1.6",
+      "category": "Developer Tools",
       "source": "./plugins/lint"
     }
-  ],
-  "version": "0.3.1"
+  ]
 }

.claude/settings.json

@@ -1,12 +1,16 @@
 {
-  "enabledPlugins": {
-    "bin@holocron": true,
-    "core@holocron": true,
-    "git@holocron": true,
-    "gitea@holocron": true,
-    "kyberforge@holocron": true
-  },
   "hooks": {
-    "PreToolUse": []
+    "SessionStart": [
+      {
+        "matcher": "startup",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PROJECT_DIR}/.claude/hooks/kyberforge/.apm/hooks/check-apm-current.sh\"",
+            "timeout": 380
+          }
+        ]
+      }
+    ]
   }
 }

.github/plugin/marketplace.json

@@ -1,49 +1,67 @@
 {
-  "description": "AI development skills for Claude Code and GitHub Copilot CLI \u2014 factory, design, implement, review, and cross-cutting workflows.",
   "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",
   "owner": {
+    "name": "Defame1297",
     "email": "defame1297@rkdr.net",
-    "name": "Defame1297"
+    "url": "https://git.dev.rkdr.net/Defame1297/"
   },
   "plugins": [
     {
-      "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
       "name": "kyberforge",
+      "description": "Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace.",
+      "version": "1.6.0",
+      "category": "Developer Tools",
       "source": "./plugins/kyberforge"
     },
     {
-      "description": "A place for things to be binned",
       "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",
+      "category": "Utilities",
       "source": "./plugins/bin"
     },
     {
-      "description": "Skills for working with Git \u2014 conventional commits, branch management, pull requests, and feature flow.",
       "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",
+      "category": "Version Control",
       "source": "./plugins/git"
     },
     {
-      "description": "Skills for managing Gitea repositories \u2014 issues, pull requests, milestones, releases, and wikis.",
       "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",
+      "category": "Version Control",
       "source": "./plugins/gitea"
     },
     {
-      "description": "Cross-cutting utility skills for everyday AI-assisted coding \u2014 triage, diagnosis, architecture review, and session navigation.",
       "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",
+      "category": "Productivity",
       "source": "./plugins/core"
     },
     {
-      "description": "Skills for Real Engineers \u2014 planning, TDD, architecture, and debugging workflows from Matt Pocock's .claude directory.",
       "name": "mattpocock-skills",
+      "description": "Skills for Real Engineers — planning, TDD, architecture, and debugging workflows from Matt Pocock's .claude directory.",
+      "version": "1.2.3",
+      "category": "Productivity",
       "source": {
+        "source": "github",
         "repo": "mattpocock/skills",
-        "source": "github"
+        "ref": "v1.2.3",
+        "sha": "835450ef244ab7335f75d95b83e7d979eae22a6d",
+        "tag_pattern": "v{version}"
       }
     },
     {
-      "description": "Skills and agents for configuring and running linters.",
       "name": "lint",
+      "description": "Skills and agents for configuring and running linters.",
+      "version": "1.1.6",
+      "category": "Developer Tools",
       "source": "./plugins/lint"
     }
-  ],
-  "version": "0.3.1"
+  ]
 }

.gitignore

@@ -24,3 +24,31 @@ node_modules/
 
 # Claude Code local settings (machine-specific)
 .claude/settings.local.json
+
+# APM dependencies
+apm_modules/
+
+# APM install output — deployed copies of released plugin content, regenerated
+# by `apm install`. The authoring source is plugins/<name>/.apm/; committing a
+# deployed copy would add a third mirror of the same skills to drift against.
+.claude/skills/
+.claude/agents/
+
+# APM hook deployment output — `apm install` copies each package's referenced
+# hook scripts here and tracks its own settings.json entries in the sidecar.
+# Regenerated on every install; the authoring source is
+# plugins/<name>/.apm/hooks/ (ADR-0019).
+.claude/hooks/
+.claude/apm-hooks.json
+
+# `apm pack` bundle output. The pre-push gate runs pack with --dry-run, so this
+# only appears after a bare `apm pack` during a release; it is not repo content.
+build/
+
+# `apm pack`'s manifest for the *root* package. Emitted beside the marketplace
+# manifest by a bare `apm pack`, and never tracked on any branch — the repo's
+# own paths hide it, since sync-plugin-content.sh redirects `apm pack -o` to a
+# scratch tree and the apm-pack-check-clean pre-push hook runs --dry-run. Scoped
+# to the file, not the directory: the sibling .claude-plugin/marketplace.json is
+# compiled output that IS committed and must stay tracked.
+/.claude-plugin/plugin.json

.mcp.json

@@ -0,0 +1,12 @@
+{
+  "mcpServers": {
+    "obsidian": {
+      "args": [
+        "@bitbonsai/mcpvault@0.15.0",
+        "docs/"
+      ],
+      "command": "npx",
+      "type": "stdio"
+    }
+  }
+}

.pre-commit-config.yaml

@@ -28,6 +28,29 @@ repos:
       - id: pretty-format-json
         stages: ['pre-commit']
         args: [--autofix]
+        # Every generated manifest lives at a KNOWN path, so every alternative is
+        # root-anchored and spells that path out. This was five `(^|/)`
+        # any-depth alternatives plus one `^` root-only one -- a mixture with no
+        # rationale, under which a fixture or vendored tree containing
+        # `.../.claude-plugin/plugin.json` would have been silently excluded from
+        # formatting while an equivalent `.../.agents/plugins/marketplace.json`
+        # would not. All fifteen real files (3 root marketplace manifests, 2 per
+        # plugin x 6 plugins) match; anything else is hand-authored and gets
+        # formatted.
+        #
+        # `.claude/settings.json` is the sixteenth, and it is excluded for a
+        # different reason: apm OWNS that file (ADR-0018, ADR-0019), and
+        # `apm audit --ci` replays the install into a scratch tree and diffs
+        # the result byte-for-byte. `pretty-format-json` sorts object keys
+        # unless `--no-sort-keys` is passed, while apm's hook integrator emits
+        # insertion order (`matcher` before `hooks`, `type` before `command`).
+        # Formatting the file therefore rewrites apm's output into a form apm
+        # would never produce, and the `apm-audit-ci` pre-push hook reports it
+        # as permanent drift on a file with no git diff -- exactly what
+        # happened when the SessionStart hook first landed in 2e395a4.
+        # Re-running `apm install` fixes the file; leaving it in scope here
+        # would re-break it on the very commit that carries the fix.
+        exclude: '^(\.claude-plugin/marketplace\.json|\.agents/plugins/marketplace\.json|\.github/plugin/marketplace\.json|plugins/[^/]+/\.claude-plugin/plugin\.json|plugins/[^/]+/\.github/plugin/plugin\.json|\.claude/settings\.json)$'
       - id: check-yaml
         stages: ['pre-commit']
       - id: trailing-whitespace
@@ -45,8 +68,8 @@ repos:
     hooks:
       - id: run-tests
         name: Run test suite
-        description: Run all test-*.sh files and bats suite
-        entry: bash tests/run-tests.sh
+        description: Run all test-*.sh files and bats suite. --strict because a suite that exits 77 (SKIPPED) at pre-push means a documented dependency is missing on this machine, and pre-commit prints nothing for a passing hook -- without it the gate went green having verified 15 of 17 suites on a vale-less PATH, with the skip list swallowed. Ad-hoc `bash tests/run-tests.sh` still skips gracefully.
+        entry: bash tests/run-tests.sh --strict
         language: system
         stages: [pre-push]
         pass_filenames: false
@@ -61,6 +84,114 @@ repos:
         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)
+        entry: bash scripts/sync-plugin-content.sh --check --all
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
+
+      - id: check-marketplace-mirror-sync
+        name: Check marketplace mirror sync
+        description: Verify .github/plugin/marketplace.json (Copilot CLI's legacy manifest path) is byte-identical to .claude-plugin/marketplace.json -- apm has no output profile for this path, so it must be kept in sync explicitly (see issue #90)
+        entry: bash scripts/sync-marketplace-mirror.sh --check
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
+
+      - id: check-executables-allow-sync
+        name: Check executables allow key sync
+        description: Verify root apm.yml's executables.allow key names kyberforge's actual version -- apm matches that key by exact "<package>#<version>" lookup, so a version bump on one side alone silently stops deploying kyberforge's hooks/ and bin/ and lets the apm install go stale (see ADR-0019)
+        entry: bash scripts/check-executables-allow-sync.sh
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
+
+      - 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)
+        entry: apm marketplace check
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
+
+      - id: apm-audit-ci
+        name: apm audit --ci
+        description: Run apm's producer-side CI gate over the root manifest AND each of the six plugin packages. Verifies exactly two things per manifest -- apm.yml parses as a valid APM manifest (manifest-parse), and, if it declares dependencies, apm.lock.yaml exists and is consistent (lockfile-exists). It does NOT enforce an org policy and does NOT scan for hidden Unicode; see the comment below for why. Reference:plugins/kyberforge/.apm/skills/apm-workflow/references/audit.md
+        entry: bash -c 'for d in . plugins/*/; do (cd "$d" && apm audit --ci) || { echo "apm audit --ci failed in $d" >&2; exit 1; }; done'
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
+        # The description above deliberately claims less than this hook's old one
+        # did ("lockfile/policy/hidden-content integrity"), because two of those
+        # three were never happening:
+        #
+        # * POLICY. `apm audit --ci` discovers an org policy from the git remote,
+        #   and apm's discovery only understands github.com and Azure DevOps.
+        #   This repo's remote is a self-hosted Gitea, so discovery resolves
+        #   nothing and the run prints `No org policy found at unknown;
+        #   enforcement skipped`. apm's own message suggests
+        #   `policy.fetch_failure_default=block` in apm.yml "to fail closed" --
+        #   that was tried on a scratch copy and REJECTED: it does not make the
+        #   check meaningful, it makes it permanently red. `apm audit --ci` then
+        #   exits 1 with `No org policy found at unknown
+        #   (policy.fetch_failure_default=block)` on every push, because there is
+        #   no org policy to find and no supported way for this remote to serve
+        #   one. A gate that can never go green is not a gate. Revisit if this
+        #   repo ever gains a policy source apm can actually reach.
+        # * HIDDEN CONTENT. The hidden-Unicode scan is plain `apm audit`, not
+        #   `apm audit --ci` (the two are different modes, and --ci refuses to
+        #   combine with --file/--strip/--dry-run/PACKAGE). Plain `apm audit`
+        #   here reports `No apm.lock.yaml found -- nothing to scan` and exits 0,
+        #   so adding it would buy a second vacuous check, not coverage.
+        #
+        # What IS left is worth keeping, and is now run against seven manifests
+        # instead of one. lockfile-exists is conditional -- it is vacuous while
+        # every apm.yml declares `dependencies: {apm: [], mcp: []}`, and it arms
+        # itself the moment one does not (verified: adding a git dependency to
+        # plugins/lint/apm.yml fails with `apm.yml declares dependencies but
+        # apm.lock.yaml is absent`). manifest-parse is unconditional and fires on
+        # any malformed manifest (verified: a dependency entry missing its
+        # git/path/registry field fails with `Cannot parse apm.yml`). Running the
+        # six plugin packages is what makes either reachable for them at all --
+        # the root-only invocation audits the marketplace manifest and nothing
+        # else. Costs ~0.5s per package, needs no network (checked under
+        # `unshare -rn`), so this does NOT join apm-marketplace-check and
+        # apm-pack-check-clean on the offline SKIP= list.
+
+      - id: check-apm-agents-valid
+        name: Validate real APM agent files
+        description: Run agent-audit's validate.sh over every plugins/*/.apm/agents/*.agent.md file in this repo -- the artifacts it governs, not fixtures
+        entry: bash scripts/check-apm-agents-valid.sh
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
+        # validate.sh was previously exercised only by check-scope-walkup-sync,
+        # and only against synthetic mktemp fixtures -- it had never run against
+        # the four agent files it governs. That is how ADR-0016 could be amended
+        # to bless a `disallowedTools` frontmatter field while validate.sh's
+        # allowlist still rejected it: the spec and its enforcer disagreed and
+        # every gate stayed green. The expected file set is derived from
+        # `git ls-files` (the pattern tests/run-bats.sh established) rather than
+        # a hardcoded count, and discovering zero files is an error, not a pass.
+        # Needs no network.
+
+      - id: apm-pack-check-clean
+        name: apm pack --check-clean
+        description: Release gate -- verify .claude-plugin/marketplace.json still matches what apm.yml + .apm/ would currently generate, and that per-package versions agree with the per_package versioning strategy. Closes issue #90's deferred item 3 (a check-clean-equivalent gate) using apm's own flag instead of custom drift logic.
+        entry: apm pack --check-versions --check-clean --dry-run
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
+
       - id: check-vale-style-sync
         name: Check Vale style copies are in sync
         description: Diff skill-audit's Vale copy against agent-audit's canonical copy
@@ -69,6 +200,25 @@ repos:
         stages: [pre-push]
         pass_filenames: false
         always_run: true
+        # verbose so the DOWNGRADED run is audible. This hook can pass while
+        # having verified strictly less than its name claims:
+        # CHECK_VALE_STYLE_SYNC_ALLOW_MISSING_VALE=1 skips all six glob probes
+        # and says so on a `passed (text-level only, vale unavailable)` line.
+        # pre-commit prints nothing at all for a passing hook, so without this
+        # the opt-out reinstated exactly the silent vacuous pass the script was
+        # written to kill, one level up -- the run showed a bare `Passed` and
+        # the documented instruction to read that summary line was impossible to
+        # follow in the one situation the opt-out exists for. The script's clean
+        # output is a single line, so this costs one line per push.
+
+      - id: check-scope-walkup-sync
+        name: Check scope walk-up implementations agree
+        description: Behaviorally cross-check validate.sh, validate-provenance.sh, new-agent.sh, and new-skill.sh's independent $HOME/.git/apm.yml walk-up ports against each other
+        entry: bash scripts/check-scope-walkup-sync.sh
+        language: system
+        stages: [pre-push]
+        pass_filenames: false
+        always_run: true
 
       - id: check-release-needed
         name: Check a release tag covers .pre-commit-hooks.yaml's paths
@@ -103,7 +253,7 @@ repos:
         description: Ensure SKILL.md files have required frontmatter fields
         entry: bash
         language: system
-        files: 'SKILL\.md$'
+        files: '^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$'
         args:
           - -c
           - |
@@ -118,29 +268,38 @@ repos:
 
       - id: skill-size-check
         stages: ['pre-commit']
-        name: SKILL.md size ceiling
-        description: Enforce agentskills.io's 500-line/5,000-token SKILL.md size ceiling
+        name: SKILL.md size and context-budget ceilings
+        description: Enforce agentskills.io's 500-line/2,770-whole-file-word spec ceilings AND ADR-0020's context budget -- description 250 chars SUGGESTION / 400 FAIL, body-only 600 words SUGGESTION / 900 FAIL, and every boundary-clause routing target resolving to a real skill or agent under plugins/*/.apm/
         entry: scripts/skill-size-check.sh
         language: script
-        files: '^plugins/[^/]+/skills/[^/]+/SKILL\.md$'
+        files: '^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$'
         pass_filenames: true
+        verbose: true
+        # verbose so the SUGGESTION tier is audible. ADR-0020 depends on it:
+        # "A ceiling does not produce an average ... The halving depends
+        # entirely on the 250-character SUGGESTION tier being visible and
+        # respected." pre-commit prints nothing at all for a passing hook, and
+        # a SUGGESTION deliberately does not fail, so without verbose every
+        # suggestion would be swallowed -- the exact invisibility ADR-0013
+        # records for Vale warnings. Costs nothing on a clean file: the script
+        # prints only findings.
 
       - id: vale-audit-prefilter-skill
         stages: ['pre-commit']
         name: Vale audit prefilter (SKILL.md)
         description: Run Vale against SKILL.md files as a deterministic prefilter for skill-audit, via skill-audit's own bundled copy
-        entry: plugins/kyberforge/skills/skill-audit/scripts/vale-wrap.sh
+        entry: plugins/kyberforge/.apm/skills/skill-audit/scripts/vale-wrap.sh
         language: script
-        files: '^plugins/[^/]+/skills/[^/]+/SKILL\.md$'
+        files: '^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$'
         pass_filenames: true
 
       - id: vale-audit-prefilter-agent
         stages: ['pre-commit']
         name: Vale audit prefilter (agent files)
         description: Run Vale against agent markdown files as a deterministic prefilter for agent-audit, via agent-audit's own bundled copy
-        entry: plugins/kyberforge/skills/agent-audit/scripts/vale-wrap.sh
+        entry: plugins/kyberforge/.apm/skills/agent-audit/scripts/vale-wrap.sh
         language: script
-        files: '^plugins/[^/]+/agents/[^/]+\.md$'
+        files: '^plugins/[^/]+/\.apm/agents/[^/]+\.agent\.md$'
         pass_filenames: true
 
   - repo: meta

.pre-commit-hooks.yaml

@@ -1,20 +1,23 @@
 -   id: kyberforge-vale-audit-skill
     name: Kyberforge Vale prose audit (SKILL.md)
     description: Deterministic prose-pattern prefilter for kyberforge's skill-audit, via its own bundled Vale config/styles
-    entry: plugins/kyberforge/skills/skill-audit/scripts/vale-wrap.sh
+    entry: plugins/kyberforge/.apm/skills/skill-audit/scripts/vale-wrap.sh
     language: script
     files: '(^|/)SKILL\.md$'
 
 -   id: kyberforge-vale-audit-agent
     name: Kyberforge Vale prose audit (agent files)
     description: Deterministic prose-pattern prefilter for kyberforge's agent-audit, via its own bundled Vale config/styles
-    entry: plugins/kyberforge/skills/agent-audit/scripts/vale-wrap.sh
+    entry: plugins/kyberforge/.apm/skills/agent-audit/scripts/vale-wrap.sh
     language: script
     files: '(^|/)agents/[^/]+\.md$|\.agent\.md$'
 
 -   id: kyberforge-skill-size-check
-    name: SKILL.md size ceiling
-    description: Enforce agentskills.io's 500-line/5,000-token SKILL.md size ceiling
+    name: SKILL.md size and context-budget ceilings
+    description: Enforce agentskills.io's 500-line/2,770-whole-file-word spec ceilings plus ADR-0020's context budget (description 250 chars SUGGESTION / 400 FAIL, body-only 600 words SUGGESTION / 900 FAIL, resolvable boundary-clause routing targets)
     entry: scripts/skill-size-check.sh
     language: script
     files: '(^|/)SKILL\.md$'
+    # verbose so the SUGGESTION tier reaches a human -- pre-commit prints
+    # nothing for a passing hook, and a SUGGESTION deliberately does not fail.
+    verbose: true

AGENTS.md

@@ -1,39 +1,59 @@
 # Working in this repo
 
-This repo is the global AI development configuration repository — the authoritative source for agent definitions, skills, workflows, and prompts across all projects. Built as a homelab tool intended to scale to professional environments.
+The global AI development configuration repository — the authoritative source for agent definitions, skills, workflows, and prompts across all projects.
+
+This file carries only what applies to **every** session. Setup, prerequisites, and test commands are in `README.md`; the reasoning behind each enforcement gate is in `docs/spec/gates.md`.
 
 ## Structure
 
-- `plugins/` — installable plugin units; each is self-contained (skills, agents, hooks, MCP servers, bundled assets); install separately via `claude plugin install <name>@holocron`
-- `providers/claude-code/` — Claude Code adapter (deployed to `~/.claude/` via `install.sh`)
+- `plugins/` — six installable plugin units, each an apm package (`apm.yml` + `.apm/`). Root `apm.yml` declares all six as `dependencies.apm`; `apm install` deploys them into `.claude/skills/` and `.claude/agents/`, both gitignored install output.
+- `providers/claude-code/` — Claude Code adapter, deployed to `~/.claude/` via `scripts/install.sh`.
+
+## Edit `.apm/`, never the flat mirror
+
+`plugins/<name>/.apm/` is the only hand-edited source for plugin content. The flat `plugins/<name>/{skills,agents,commands,instructions,extensions}/` directories, the merged `plugins/<name>/hooks/hooks.json`, and both `plugin.json` manifests are generated — nothing marks them as generated, so check the path before you edit. An edit to the mirror is discarded by the next sync and reported as drift by the `check-plugin-content-sync` pre-push hook.
+
+Not everything in a plugin root is generated. `README.md`, `docs/`, `bin/`, `sources.md`, `.mcp.json` and per-plugin extras are hand-authored there with no `.apm/` source — edit those in place. The rule is per-path, not per-directory. But a file placed *inside* a mirrored directory is deleted on the next sync (`sync_dir` runs `rm -rf` before every copy), so plugin-root documentation goes in `docs/`, never in `hooks/` or `skills/`.
+
+Full model: `docs/spec/architecture.md`.
 
 ## Prefer plugin skills over raw shell
 
-This repo dogfoods its own plugins. Before shelling out to git, gitea, or lint tooling directly, check whether an installed skill already owns the operation — it usually does:
+This repo dogfoods its own plugins. Before shelling out, check whether a skill already owns the operation — it usually does:
 
-- Commits, branches, history, worktrees, remotes → `git:git-commits`, `git:git-branches`, `git:git-history`, `git:git-worktrees`, `git:git-remotes`
-- Pre-commit hook install/config/troubleshooting → `git:pc-run` / `git:pc-author`
-- Issues, PRs, labels, milestones → `gitea:gitea-issues`, `gitea:gitea-prs`, `gitea:gitea-labels-milestones`; also `gitea:gitea-branches`, `gitea:gitea-files`, `gitea:gitea-releases`, or `gitea:gitea-workflow` when the domain is ambiguous
-- Vale prose linting → `lint:vale-config` / `lint:vale-run`
-- This repo's own AGENTS.md → `core:agentsmd-author` / `core:agentsmd-audit`
+- Commits, branches, history, worktrees, remotes → `git-commits`, `git-branches`, `git-history`, `git-worktrees`, `git-remotes`
+- Pre-commit hook install/config/troubleshooting → `pc-run` / `pc-author`
+- Issues, PRs, labels, milestones → `gitea-issues`, `gitea-prs`, `gitea-labels-milestones`; also `gitea-branches`, `gitea-files`, `gitea-releases`, or `gitea-workflow` when the domain is ambiguous
+- Vale prose linting → `vale-config` / `vale-run`
+- This repo's own AGENTS.md → `agentsmd-author` / `agentsmd-audit`
+
+Use the bare, **unnamespaced** names. That is what `apm install` deploys and the only form this repo's own install produces — a project skill has no plugin to prefix (ADR-0018). Whether the `<plugin>:` form (`gitea:gitea-prs`) also resolves depends on native plugin installs at user scope, outside this repo; write the bare name either way.
 
 Fall back to raw shell only when no skill covers it.
 
-## Setup and testing
+## Session rules
 
-- Install git hooks via `git:pc-run`, wiring all three stages — this repo's `.pre-commit-config.yaml` has no `default_install_hook_types`, so a plain install silently skips `commit-msg` (Conventional Commits) and `pre-push` (tests, manifest check).
-- Install the `vale` binary — required by the `vale-audit-prefilter-skill`/`-agent` pre-commit hooks, which run on every commit touching a `SKILL.md` or agent `.md` file. Without it the hooks fail with a bare "command not found" and no install pointer. `brew install vale` (macOS), `snap install vale` (Linux), `choco install vale` (Windows), or see https://vale.sh/docs/vale-cli/installation/. No `vale sync` needed — the `Kyberforge` styles are committed under `plugins/kyberforge/skills/{skill-audit,agent-audit}/assets/vale/styles/`, not downloaded packages (see ADR-0014).
-- Run `bash tests/run-tests.sh` before considering any change done — it runs every `test-*.sh` script in the repo plus the bats suite (`--bats-only` for just bats). First run auto-initializes the bats submodules; no manual `git submodule update` needed.
-- Pushing re-runs the full suite plus `scripts/check-manifests.sh` via the pre-push hook — same commands, so run them locally first.
-- Author commits with `git:git-commits` — it validates Conventional Commits (enforced at `commit-msg`) for you.
+- **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
 
-Read CONTEXT.md at the start of every session in this repo.
+Read `CONTEXT.md` at the start of every session — it is this repo's domain glossary, and the terms it defines are used unglossed everywhere else. It is not exhaustive: terms it does not carry are defined at their point of use, mostly in `docs/spec/`.
 
 Read these on demand:
 
-- `docs/spec/architecture.md` — current directory structure, install pipeline, provider model
+- `README.md` — prerequisites, install, and test commands
+- `docs/VISION.md` — the phased roadmap and where this is going; read when a decision turns on product direction
+- `LESSONS.md` — patterns that went wrong once; read before repeating a class of change that has burned the repo before
+- `docs/spec/gates.md` — what each pre-commit and pre-push hook enforces and why; read when a gate fails or before changing hook config
+- `docs/spec/architecture.md` — directory structure, install pipeline, provider model
 - `docs/adr/` — architectural decisions; read before answering design questions or proposing structural changes
 - `docs/ai-constitution.md` — full governance evidence base; read when a governance decision needs justification
 - `docs/research/ai-coding-factory/ai-coding-factory-principles.md` — factory design rationale; read when implementing, auditing, or reviewing skills or factory structure

CONTEXT.md

@@ -1,80 +1,226 @@
 ---
 name: AI Development Repo
-description: Domain language and decisions for the global AI development config repository
+description: The domain language of the global AI development config repository
 ---
 
-# Context
+# AI Development Repo
 
-## Principles
+The bounded context of this repo is **how agent instructions are authored, packaged, distributed, and
+kept small**. Terms here name concepts specific to that problem. Mechanics live elsewhere:
+`docs/spec/architecture.md` for structure, `docs/spec/gates.md` for enforcement, `docs/adr/` for
+decisions.
 
-### CLAUDE.md index model
-`AGENTS.md` is the source of always-on universal rules (provider-agnostic). `providers/claude-code/CLAUDE.md` is a thin adapter: it imports `~/.agents/AGENTS.md` via `@~/.agents/AGENTS.md` and appends Claude Code-specific additions (`@import` for governance.md, content index). Deployed to `~/.claude/CLAUDE.md` via `install.sh`. Context size is kept minimal — only what is needed every session is loaded upfront; detailed content is pulled on demand. See ADR-0003.
+## Language
 
-### Instruction file format
-`core/instructions/<topic>.md` files are plain markdown — no frontmatter, no schema. The agent decides when to read each file based on task context and the content index label in `providers/claude-code/CLAUDE.md`. Frontmatter is deferred until there is evidence that agents are loading the wrong files in practice.
+### Context cost
 
-### Repo/gitea as source of truth
-All project state, decisions, context, and working conventions live in this repo or Gitea. External memory systems should not be used for this project — they create a split-brain risk where cached state diverges from the repo. At the start of every session, read `CLAUDE.md`, `CONTEXT.md`, and `docs/VISION.md`. Everything needed to orient is here.
+**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.
+_Avoid_: context cost, token overhead
 
-Before answering any design or architecture question, check for existing decisions: `docs/adr/` (hard architectural decisions).
+**Skill context contract**:
+The ADR-0020 authoring rules that hold the preload tax and body size down — a description carries a
+trigger clause, at most one capability clause, and a boundary clause, and nothing else. Thresholds
+and the target-resolution walk: `docs/spec/gates.md`.
+_Avoid_: skill budget, size limit
 
-## Glossary
+**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
+self-contained `references/` file. Exemplar: `apm-workflow`.
+_Avoid_: router body, thin body
 
-### Management Application
-A separate product (separate repo) for browsing, editing, and configuring AI development configs through a proper product UI. Git is the persistence layer, invisible to the user. The app is repo-agnostic — it works with any git repo that follows these conventions. This repo is the canonical default content (the official starter). See `docs/VISION.md` for the phased roadmap.
+**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`.
+_Avoid_: manual skill, disabled skill
 
-### Skills
-Reusable slash commands for AI coding tools, defined as `SKILL.md` files following the [Agent Skills open standard](https://agentskills.io). Deployed via plugin — `plugins/<plugin-name>/skills/<skill-name>/SKILL.md`, available after the plugin is installed (`claude plugin install <name>@<marketplace>`). Skills are self-contained — they cannot reference files outside the plugin directory after install-time caching.
+**Delegation discipline**:
+The agent-side counterpart to the dispatch body. A plugin-scope agent is a single `.agent.md` file
+with no sibling `references/` directory, so it cannot disclose to itself — it can only delegate to
+skills. Its characteristic defect is therefore restatement, not length.
+_Avoid_: agent hygiene
 
-### Plugin
-The deployable unit in the plugin marketplace. A plugin bundles one or more skills, agents, hooks, prompts, MCP servers, and optionally a `bin/` directory into a single installable directory. Each plugin has two manifests: `.claude-plugin/plugin.json` (Claude Code) and `plugin.json` at the plugin root (Copilot CLI). Plugins are copied to a cache on install — they cannot reference files outside their own directory. In this repo, plugins live under `plugins/<name>/`. Install a plugin with `claude plugin install <name>@<marketplace>`.
+### Distribution
 
-### Plugin marketplace
-A Git repository with a `marketplace.json` manifest listing installable plugins. No backend, registry, or SaaS required — the Git repo is the marketplace. This repo is the `holocron` marketplace. The manifest lives at `.claude-plugin/marketplace.json` (read by both Claude Code and Copilot CLI) and is mirrored to `.github/plugin/marketplace.json`.
+**Skill**:
+A reusable slash command defined as a `SKILL.md` file following the
+[Agent Skills open standard](https://agentskills.io), authored at
+`plugins/<plugin>/.apm/skills/<skill>/SKILL.md`.
+_Avoid_: command, prompt, macro
 
-### HITL (human-in-the-loop)
-Agent pauses before a consequential action; human approves before execution. Required for irreversible or high-stakes actions (architecture changes, production deployments, security configuration). The agent drafts the change plan and waits — it does not proceed autonomously. Contrast with HOTL.
+**Plugin**:
+The deployable unit — one or more skills, agents, hooks, commands, and MCP servers bundled into a
+single installable directory under `plugins/<name>/`, compiled from that plugin's `.apm/` source.
+_Avoid_: package, bundle, module
 
-### HOTL (human-on-the-loop)
-Agent acts; human monitors and can intervene after the fact. Acceptable for low-stakes, bounded, reversible actions where the cost of pausing for approval exceeds the blast radius of an error. The distinction between HITL and HOTL must be explicit and documented — defaulting to HOTL for convenience is not acceptable.
+**apm package**:
+The unit apm builds and installs — `plugins/<name>/apm.yml` plus the hand-authored
+`plugins/<name>/.apm/` tree it compiles from (ADR-0015).
+_Avoid_: plugin directory, source tree
 
-### Sycophancy
-The failure mode where RLHF-trained models prioritise approval over accuracy. Treated as a first-class reliability risk: models change correct answers to wrong ones under user pressure in a majority of observed cases, then persist in the wrong answer. Designing against sycophancy is an explicit obligation, not a quality-of-life concern. Countermeasures: explicit pushback resistance instructions, prompting for dissent, cross-validating against independent sources. Never interpret AI agreement as AI accuracy.
+**Content mirror**:
+The generated flat `skills/`, `agents/`, `commands/`, `instructions/`, `extensions/` directories and
+merged `hooks/hooks.json` at a plugin root — also called the flat mirror — compiled from that
+plugin's `.apm/` tree so hosts that convention-scan those paths discover the content (ADR-0017).
+_Avoid_: generated copy, duplicate tree
 
-### AGENTS.md
-The provider-agnostic always-on instruction entry point. Two files:
-- **Repo-level `AGENTS.md`** — instructions for agents working inside this repo (structure, key rules); imported by repo `CLAUDE.md` via `@AGENTS.md`.
-- **Global `core/AGENTS.md`** — Communication and Behavior rules that apply across all projects; deployed to `~/.agents/AGENTS.md`; imported by `~/.claude/CLAUDE.md` via `@~/.agents/AGENTS.md`.
+**Output profile**:
+An `apm pack` target format for a generated *marketplace* manifest; apm has `claude`
+(`.claude-plugin/marketplace.json`) and `codex` (the differently-shaped
+`.agents/plugins/marketplace.json`), and none for `.github/plugin/marketplace.json` (Copilot CLI's
+legacy path), which a sync script mirrors instead. Mechanics: `docs/spec/architecture.md`.
+_Avoid_: build target, export format
 
-Contains always-on rules in plain markdown with no provider-specific syntax (no `@import`). Provider-specific files (`CLAUDE.md`) are thin adapters that import the relevant `AGENTS.md` and add only Claude Code-specific syntax. This pattern means a single source of truth can serve multiple providers without duplication. See ADR-0003.
+**Plugin marketplace**:
+A Git repository carrying a `marketplace.json` manifest that lists installable plugins. There is no
+backend, registry, or SaaS — the Git repo is the marketplace.
+_Avoid_: registry, store, catalogue
 
-### Skill composition
-A skill calling another skill by name to delegate a sub-task. The calling skill focuses on the orchestration decision ("when to do X"); the called skill owns the mechanics ("how to do X"). Established compositions: `grill-me` calls `write-adr` when a decision crystallises; `implement-feature` calls `tdd` as its implementation methodology; `forge` calls `grill-with-docs` to refine intent, classifies the target artifact type (skill / agent / plugin / marketplace entry), then routes to the matching `*-author` skill — which owns its own create/improve logic and, where applicable, its own inline audit closeout (`skill-author` runs `/skill-audit`, `agent-author` runs `kyberforge:agent-audit`, both in the same context as the authoring work). Reserve `forge` for genuinely undecided "which artifact type is this" questions — an already-fully-specified corrective edit (exact file, line, and fix already known) should call the target author skill directly instead (`skill-author`, `plugin-author`, `agentsmd-author`, etc.); routing a known fix through `forge`'s grill-and-classify layer adds unnecessary indirection and, in practice, has been observed to lose track of hard constraints handed down the chain (e.g. "don't commit yet," "edit in this worktree") because each hop re-derives instructions from a shorter brief. `forge` additionally runs its own independent recheck after a skill/agent route finishes: a clean-context subagent (not forked, no inherited context) re-runs the same audit skill against the finished artifact, as a distinct verification layer from the author skill's inline audit — the two can share blind spots since the inline audit runs in the same context as the work it checks. If the clean audit surfaces any unresolved finding, `forge` loops — re-invoke the author skill to resolve it, re-run the clean audit — until the clean audit comes back with nothing unresolved; only then is the route done. `plugin-author` and `marketplace-author` have no audit counterpart and get no recheck; their terminal check is `claude plugin validate`.
+**holocron**:
+This repository, in its role as a plugin marketplace and as the remote the six plugin dependencies
+resolve against.
+_Avoid_: the marketplace, upstream
 
-### Provider-agnostic issue tracker
-Skills and workflows reference "linked issue" generically rather than a specific provider. Gitea is the canonical issue tracker for this repo (see ADR-0017). "Issue" is the cross-provider term (GitHub, GitLab, Gitea all use it).
+**apm-consumed install**:
+How this repo installs its own plugins as of 2026-08-14 — six `dependencies.apm` entries in the root
+`apm.yml` deployed by `apm install`, rather than `claude plugin install <name>@holocron`. Its
+consequences: ADR-0018.
+_Avoid_: apm install, dependency install
 
-### Provenance chain
-The three-stage traceability record linking a skill back to its research inputs: (1) `/research` produces topic docs and a `sources.md` in `plugins/<plugin>/docs/research/docs/<topic>/`; (2) `/skill-author` reads those docs and records which sources informed which skill files in `references/sources.md` (including a `Research doc:` back-pointer to the upstream research file) and `source_keys` frontmatter on `SKILL.md` and `references/*.md`; (3) `skill-audit` validates the chain is complete and internally consistent via `validate-provenance.sh`. A skill with research input but no `references/sources.md`, or with `source_keys` that don't match `references/sources.md` slugs, has a broken provenance chain.
+**Provenance chain**:
+The three-stage traceability record linking a skill back to its research inputs: `/research` produces
+topic docs and a `sources.md`; the author skill records which sources informed which files in
+`references/sources.md` and `source_keys` frontmatter; `skill-audit` validates the chain is complete
+and internally consistent.
+_Avoid_: sources, citations, attribution
 
-### Bidirectional reference principle
-Files that reference other files should declare those references explicitly. The referencing file carries the forward reference (e.g. content index in `CLAUDE.md`, `references:` in frontmatter). The referenced file carries a `when:` field describing when it is loaded. Both sides should agree — divergence signals staleness. The reverse map ("what files reference this file?") is derived by a reference scanner script, not maintained manually. This principle applies to instruction files, skills, and workflow documents.
+### Governance
 
-### agentsmd-author / agentsmd-audit
-A skill pair in the `core` plugin for writing, updating, and reviewing a repo's `AGENTS.md` file(s) — the generic open-standard file (see the `AGENTS.md` entry above), including this repo's own. `agentsmd-author` creates/updates AGENTS.md content, supports nested monorepo placement (per the standard's nearest-file-wins precedence), and closes out by invoking `agentsmd-audit` inline. `agentsmd-audit` runs a single combined pass checking three mandatory baselines: secrets/credentials (governance.md hard prohibition — AGENTS.md is committed content), structural completeness (common-sections checklist from the agents.md spec), and accuracy/drift (do referenced commands and paths actually resolve against the repo). `agentsmd-audit` never inspects provider adapter files (see `provider-adapter-author`) — its scope is AGENTS.md content only. Chosen over folding this into `kyberforge` because kyberforge's scope is meta-tooling for the holocron marketplace itself, not generic target-repo documentation; `core` is the intended home for cross-cutting, repo-agnostic utility skills.
+**HITL** (human-in-the-loop):
+The agent pauses before a consequential action and a human approves before execution. Required for
+irreversible or high-stakes actions — architecture changes, production deployments, security
+configuration.
+_Avoid_: manual approval, gated action
 
-### provider-adapter-author
-A companion skill (`core` plugin) that detects a target repo's provider-specific instruction file (`CLAUDE.md`, `.cursor/rules/*.mdc`, `copilot-instructions.md`, etc.) and, where it duplicates content AGENTS.md should own, converts it into a thin adapter that imports AGENTS.md — mirroring this repo's own ADR-0002/ADR-0003 two-tier adapter pattern. Self-validates via its own bundled deterministic script (`scripts/validate-adapter.sh`: checks for an import reference, no duplicated headings, size threshold) rather than a separate paired audit skill — the check is mechanical, so a script suffices per governance.md's "prefer deterministic code for repeatable tasks." `agentsmd-author` calls this skill via skill composition when it detects an existing provider file with overlapping content.
+**HOTL** (human-on-the-loop):
+The agent acts and a human monitors, able to intervene after the fact. Acceptable only for
+low-stakes, bounded, reversible actions where the cost of pausing exceeds the blast radius of an
+error.
+_Avoid_: autonomous, unsupervised
 
-### lint plugin
-A standalone, repo-agnostic plugin (`plugins/lint/`) for configuring and running linters — not scoped to kyberforge's own meta-tooling. First linter is Vale (prose style linting), split into two skills per the git/gitea per-concern pattern: `vale-config` (setup — `.vale.ini`, `StylesPath`, styles) and `vale-run` (invoke Vale, interpret/report findings). A `lint-runner` agent composes these for isolated-context lint sweeps; it is report-only (no `Edit` tool) — it flags findings, it does not rewrite prose. Vale's research docs (`docs/research/docs/vale/`) moved from `plugins/kyberforge/` to `plugins/lint/` to keep the provenance chain same-plugin.
+**Sycophancy**:
+The failure mode where an RLHF-trained model prioritises approval over accuracy — changing a correct
+answer to a wrong one under user pressure, then persisting in the wrong answer. Treated here as a
+first-class reliability risk, not a quality-of-life concern.
+_Avoid_: agreeableness, people-pleasing
 
-### Vale audit prefilter (skill-audit / agent-audit)
-Wiring Vale as a deterministic prefilter for `skill-audit`/`agent-audit`'s Description dimension (ADR motivation: issue #84) is repo-specific, not part of the generic `lint` plugin, so it doesn't live in `plugins/lint/` — but per ADR-0014 it also doesn't live at the repo root anymore. Two copies live inside `plugins/kyberforge/`, one per skill, since a plugin's cache-install only copies each skill's own files (no cross-skill sharing): `plugins/kyberforge/skills/agent-audit/assets/vale/` is canonical (`.vale.ini` plus a custom `Kyberforge` style covering description-opener banning ("This skill/agent..."), vague-capability wording ("helps with", "utilize", ...), and generic "see references/ for details" padding — and a `KyberforgeCopilot` style scoped only to `.agent.md` files for the Copilot-only "Use proactively has no effect" check), and `plugins/kyberforge/skills/skill-audit/assets/vale/` is a smaller duplicate (`Kyberforge` only, scoped to `SKILL.md`) kept in sync by `scripts/check-vale-style-sync.sh` (pre-push). A root-level `.pre-commit-hooks.yaml` exposes both copies (plus `skill-size-check`) so any external repo can enforce the same rules via `repo: <this-repo-url>, rev: <tag>` in its own `.pre-commit-config.yaml` — pre-commit clones the pinned rev into its own cache, independent of whether Claude Code or the `kyberforge` plugin is installed at all, and the same mechanism covers CI (`pre-commit run --all-files`). This repo's own `vale-audit-prefilter-skill`/`-agent` pre-commit hooks consume the identical plugin-bundled copies via `repo: local` (not a third root copy, and not a pinned self-reference — a pinned self-reference would lint working-tree edits against the last tagged release rather than the change being made). Every rule is `level: error` and every alert is a FAIL — no ignorable tier, same as shellcheck, the test suite, and conventional-pre-commit. Graded severities do not work here: Vale's exit code keys on `error` alerts alone, so `warning`/`suggestion` rules exit 0 and pre-commit swallows the output of a passing hook, leaving them invisible and blocking nothing. `MinAlertLevel` and `--minAlertLevel` are correspondingly absent from `.vale.ini` and the hook, being no-ops under this model. Vale covers the pattern-matchable sub-checks named in issue #84 (imperative opener, vague filler, `Use proactively`, generic reference-pointer padding) plus, per ADR-0013, one body-wide prose-pattern check ("There is/are" sentence openers) — everything else about body discipline (defaults-vs-menus, why-rationale, non-pattern-matchable judgment calls), near-miss exclusion strength, and control calibration stays LLM judgment.
+### Documents
 
-Both skills' Step 1, and the `vale-audit-prefilter-skill`/`-agent` pre-commit hooks, call each copy's own `scripts/vale-wrap.sh` rather than `vale` directly — a workaround for a confirmed Vale 3.15.2 limitation (see `vale-config`'s Gotchas): `text.frontmatter.description` silently stops matching on most — not all — multi-line descriptions. Verified by reproduction, not assumed: `>` folded scalars, plain (unquoted) continuation lines, and single- or double-quoted multi-line scalars all yield 0 alerts and exit 0 on a deliberately-bad fixture, while a `|` literal block spanning the same 2+ lines lints normally (alerts fire, exit 1). The wrapper flattens those three broken forms to one physical line in a scratch copy (padding with blank lines so every other line number is unchanged) before handing off to real `vale`; `|` literal blocks and single-line descriptions pass through untouched, already linting correctly. The plain and quoted forms previously passed silently — unflattened and unmatched — so a bad description in either sailed through the prefilter. Handed no `--config` at all, the wrapper falls back to its own sibling `assets/vale/.vale.ini`, located from `${BASH_SOURCE[0]}` rather than from the cwd — which is why both manifests' `entry:` is now the bare script path with no argument after it. 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: a `--config` in `.pre-commit-hooks.yaml` pointed at a path no consumer has and hard-failed every external run with `E100 [--config] Runtime error`. `.pre-commit-config.yaml` drops the argument too, deliberately keeping the two entries identical — the local `repo: local` hook resolved its `--config` correctly only because the consuming repo *was* this repo, and that divergence is why three review rounds exercised a path no external consumer takes and missed the defect. An explicit `--config` still wins, in all three argv forms (`--config X`, `--config=/abs`, `--config=rel`), and a relative one still resolves against the caller's cwd, matching bare `vale`, not the repo root. Both audit skills' Step 1 now passes no `--config` either: it resolves the script relative to the skill's own directory so the call works from an installed plugin cache, but a relative `--config` alongside it would still resolve against the cwd, yielding `E100 Runtime error ... does not exist` and exit 2 — which both skills' fallback misreads as "vale unavailable" and silently downgrades to full LLM judgment. `tests/test-vale-wrap.sh` regression-tests this against skill-audit's copy specifically (its fixtures are all `SKILL.md`-shaped, and only skill-audit's `.vale.ini` has that glob section). Each `.vale.ini`'s section globs are path-agnostic (`[**/SKILL.md]` for skill-audit's copy; `[**/agents/*.md]`/`[**/*.agent.md]` for agent-audit's) and do no scoping on their own: Vale's `*` crosses `/`. Scoping comes from each pre-commit hook's own `files:` regex and from the audit skills passing one explicit file per invocation. The two manifests scope differently on purpose: this repo's `.pre-commit-config.yaml` pins its own layout — `^plugins/[^/]+/skills/[^/]+/SKILL\.md$` for `-skill`, `^plugins/[^/]+/agents/[^/]+\.md$` for `-agent` — while the shipped `.pre-commit-hooks.yaml` stays layout-agnostic for external consumers whose skills live anywhere, using `(^|/)SKILL\.md$` and `(^|/)agents/[^/]+\.md$|\.agent\.md$`. Both manifests split the prefilter into two hooks precisely because one combined hook pointed at only one copy would silently 0-file-skip the other file type. A `SKILL.md` outside `plugins/` (e.g. project-scope `.claude/skills/foo/SKILL.md`) still matches `[**/SKILL.md]` and gets linted normally — the globs constrain filename shape, not location. Vale reports 0 files only when the path it is handed matches no glob section at all: a differently-named file, or a directory argument holding nothing that matches. That run prints `✔ 0 errors ... in 0 files.` and exits 0, indistinguishable from a clean pass, so both audits treat a 0-file Vale run as NOT RUN and fall back to full LLM judgment.
+**AGENTS.md**:
+The provider-agnostic always-on instruction file, in plain markdown with no provider-specific syntax
+(ADR-0003). Two exist: repo-level, and the global `core/AGENTS.md` deployed to `~/.agents/AGENTS.md`.
+_Avoid_: instructions file, system prompt
 
-This scope expands per ADR-0013: one cherry-picked low-noise `write-good`/`alex` rule landed in `styles/Kyberforge`, `Kyberforge.SentenceOpenerThereIs` (22 held-out hits, both in-corpus hits clean rewrites, zero suppressions). A second, `Kyberforge.VagueQualifier`, was cherry-picked and then deleted: 2 hits across the 41 skill/agent files, one marginal and one an unfixable false positive (`caveman/SKILL.md` quotes `of course` as an example of filler — a mention, not a use) that forced the repo's only Vale suppression comments. Also new is a sibling pre-commit hook, `skill-size-check` (`scripts/skill-size-check.sh`), enforcing agentskills.io's `SKILL.md` ceiling as two blocking gates: `MAX_LINES=500` and `MAX_WORDS=2770` (a word-count proxy for the 5,000-token limit, calibrated to the densest prose measured in this repo — 1.81 tokens per word — so even a worst-case `SKILL.md` at the ceiling stays under 5,000 tokens). Both are inclusive, and `skill-audit/scripts/validate.sh` checks the same pair on the same terms, so a `SKILL.md` can no longer pass its own audit yet be blocked by the commit hook. Scoped to `^plugins/[^/]+/skills/[^/]+/SKILL\.md$` only, same as `vale-audit-prefilter-skill`, so it never lints `docs/research/examples/` reference skills. It's also exposed in the root-level `.pre-commit-hooks.yaml` as `kyberforge-skill-size-check` — it has no external asset dependency, so it needed no relocation, only exposure to external consumers. File scope (`SKILL.md` + agent files) and enforcement model (rules land directly in `styles/Kyberforge`, blocking immediately, no trial tier) stay unchanged; governance.md/CONTROLS.md were evaluated and excluded as rule sources (nothing prose-pattern-matchable to mine). House convention: banned phrasing that must be mentioned rather than used goes in backticks or a fenced code block — Vale skips code spans and fences, so no suppression is needed; inline `<!-- vale Rule = NO -->` (HTML-comment form; the MDX `{/* */}` form does not work in plain Markdown) is the fallback only where backticking is impossible.
+**Thin adapter**:
+A provider-specific instruction file (`CLAUDE.md`, `.cursor/rules/*.mdc`, `copilot-instructions.md`)
+that imports its `AGENTS.md` and adds only that provider's syntax, carrying no original always-on
+content of its own (ADR-0002, ADR-0003).
+_Avoid_: wrapper, shim, provider file
 
-### LESSONS.md
-Long-loop feedback log for patterns observed across sessions. Three or more entries on the same pattern graduate to the relevant standing file (e.g. a coding convention, a governance rule). Updated by the session-handoff skill or directly by the human. Lives at the repo root.
+**LESSONS.md**:
+The long-loop feedback log for patterns observed across sessions, at the repo root.
+_Avoid_: changelog, retro, postmortem
+
+**Management Application**:
+A separate product in a separate repo for browsing, editing, and configuring AI development configs
+through a product UI, with Git as an invisible persistence layer. Repo-agnostic; this repo is its
+canonical default content. Roadmap: `docs/VISION.md`.
+_Avoid_: the UI, the dashboard, the app
+
+### Quality
+
+**Skill composition**:
+A skill calling another skill by name to delegate a sub-task — the caller owns the orchestration
+decision ("when to do X"), the callee owns the mechanics ("how to do X").
+_Avoid_: chaining, nesting, sub-skill
+
+**Vale audit prefilter**:
+The deterministic Vale pass that runs ahead of `skill-audit`/`agent-audit`'s Description dimension,
+so LLM judgment is spent only on what a pattern cannot catch. Mechanics: `docs/spec/gates.md`.
+_Avoid_: linting, style check
+
+**Authoring root**:
+The directory a gate resolves against — the nearest ancestor of the file being checked holding
+`plugins/*/.apm/skills` or `plugins/*/.apm/agents`, falling back to the nearest ancestor holding
+`.git`. The walk: `docs/spec/gates.md`.
+_Avoid_: repo root, project root
+
+**Near-miss**:
+A query that shares keywords with this skill but needs a different one — and, by extension, the
+sibling that would wrongly answer it; boundary clauses exist to exclude genuine near-misses rather
+than to enumerate siblings. Detail: `skill-audit/references/description-quality.md`.
+_Avoid_: overlap, similar skill
+
+**Vacuous green**:
+A check that reports success because it measured nothing — zero files scanned, an unparsed value read
+as empty, a conditional branch that never armed.
+_Avoid_: false pass, clean run
+
+**Issue**:
+The cross-provider term for a tracked unit of work. Gitea is this repo's canonical tracker
+(ADR-0007), but skills say "linked issue" generically rather than naming a provider.
+_Avoid_: ticket, card, task
+
+## Relationships
+
+- A **Plugin** bundles one or more **Skills** and agents; a **Plugin marketplace** lists **Plugins**;
+  **holocron** is this repo wearing that hat.
+- Every model-invocable **Skill** pays the **Preload tax**. A **Hand-invoked skill** does not — which
+  is the first question to settle when authoring one.
+- The **Skill context contract** bounds both the **Preload tax** (description) and the body.
+  A **Dispatch body** is how a skill stays inside it; **Delegation discipline** is how an agent does.
+- **AGENTS.md** is the source of always-on rules; a **Thin adapter** imports it and originates
+  nothing.
+- **Skill composition** is the caller/callee split. `forge` routes a genuinely *undecided* artifact
+  type to the matching author skill — an already-specified fix (file, line, and change known) calls
+  that author skill directly, because each routing hop re-derives instructions from a shorter brief
+  and has been observed to drop hard constraints handed down the chain.
+- **HITL** and **HOTL** are exclusive per action class, and the choice must be explicit and
+  documented. **Sycophancy** is why HOTL is not the safe default.
+- A **Skill** built on research carries a **Provenance chain**; `skill-audit` fails it when broken.
+- **LESSONS.md** feeds the standing files: three or more entries on one pattern graduate the pattern
+  into the relevant standing document.
+
+## Example dialogue
+
+> **Dev:** "This one only fires when someone types the slash command. Does its description still need
+> trigger words?"
+> **Maintainer:** "No — that's a **hand-invoked skill**. The host withholds it from the model-visible
+> listing, so it pays no **preload tax** at all and the description is human-facing text."
+> **Dev:** "Then the body can be as long as it needs to be?"
+> **Maintainer:** "Different budget. The **skill context contract** gates the body whether or not the
+> skill is model-invoked — the description competes with every other skill's description, the body
+> competes with the caller's live conversation. Four mutually exclusive flows means a **dispatch
+> body**: table in `SKILL.md`, one `references/` file per flow."
+> **Dev:** "And if I split it into an agent instead?"
+> **Maintainer:** "Then you're in **delegation discipline** territory. An agent has no `references/`
+> to disclose to, so the failure mode flips — it stops being length and starts being restatement of
+> a procedure some skill already owns."
+
+## Flagged ambiguities
+
+- "skill" was used for both the authored `SKILL.md` under `plugins/<name>/.apm/skills/` and the
+  deployed copy under `.claude/skills/` — resolved: the authoring source is the **Skill**; the
+  deployed copy is gitignored `apm install` output and is never edited.
+- Skills can answer to two names, bare (`gitea-prs`) and namespaced (`gitea:gitea-prs`), depending on
+  whether a native install exists at user scope alongside the apm one (ADR-0018) — resolved: write
+  the bare name, which is the only form `apm install` produces.
+- "context" means both the model's live token window (the **Preload tax** sense) and the bounded
+  domain this file describes — resolved: unqualified "context" in this repo means the token window.
+- "audit" was used for both an author skill's inline closeout and `forge`'s independent
+  clean-context recheck — resolved: these are two distinct layers, kept separate precisely because
+  an audit running in the same context as the work it checks shares that work's blind spots.

LESSONS.md

@@ -1,8 +1,8 @@
 # Lessons
 
-Patterns observed during development of this repo. Three or more entries on the same pattern → promote to CONTEXT.md (or the relevant instruction file) as a standing rule.
+Patterns observed during development of this repo. Three or more entries on the same pattern → promote to `docs/spec/architecture.md` (or the relevant instruction file) as a standing rule.
 
-**Graduation rule:** When three or more entries cover the same pattern, the human reviews and promotes it to the appropriate standing location: `CONTEXT.md` for domain-level principles, `core/instructions/coding.md` for coding conventions, `core/instructions/git.md` for git conventions, or `core/instructions/testing.md` for testing conventions. The graduated entries are marked `[graduated → target file]` rather than deleted (audit trail).
+**Graduation rule:** When three or more entries cover the same pattern, the human reviews and promotes it to the appropriate standing location: `docs/spec/architecture.md` for structural and domain-level principles — `CONTEXT.md` is not a destination, its `## Principles` section was deleted and what was there now sits under that file's "AGENTS.md pattern" and "Reference conventions" headings — `core/instructions/coding.md` for coding conventions, `core/instructions/testing.md` for testing conventions, or `core/instructions/subagent-orchestration.md` for delegation conventions. Those four are the whole set — `core/instructions/` holds `coding.md`, `governance.md`, `subagent-orchestration.md` and `testing.md`, and nothing else. Git conventions have no standing file of their own: promote them to `core/instructions/coding.md`, or create a new instruction file deliberately rather than assuming one exists. The graduated entries are marked `[graduated → target file]` rather than deleted (audit trail).
 
 **Who writes here:** The session-handoff skill (Chunk 3) prompts LESSONS.md extraction before closing a session. The human may also write directly.
 
@@ -26,6 +26,8 @@ Issue files frequently referenced "the workflow defined in `docs/notes/skill-imp
 
 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.
@@ -124,7 +126,7 @@ Two forks independently fixed `references/sources.md` with different approaches
 
 ## 2026-06-28 — Implementation agents must invoke /skill-author, not write skill files directly
 
-When briefing an agent to implement a new skill, the instinct is to tell it to write the SKILL.md and supporting files directly. This bypasses Step 5 of the skill-author process (provenance), which requires reading all research `sources.md` files and recording every `extracted` slug in META.md. The `validate-provenance.sh` script catches the gap — but only after the commit, requiring a fix round. This pattern recurred twice in one session (plugin-author and marketplace-author initial implementation, then again in the first round of fix agents). Fix: briefs for implementation agents must explicitly say "invoke `/skill-author` (read and follow `plugins/kyberforge/skills/skill-author/SKILL.md`)" — not "write the skill files." Invoking the skill is the only reliable way to ensure all process gates, including provenance, run.
+When briefing an agent to implement a new skill, the instinct is to tell it to write the SKILL.md and supporting files directly. This bypasses Step 5 of the skill-author process (provenance), which requires reading all research `sources.md` files and recording every `extracted` slug in 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.
 
 ## 2026-07-05 — Repo root is a bare checkout; work happens in worktrees only
 
@@ -165,3 +167,97 @@ Dropping the `--config` argument from `.pre-commit-hooks.yaml` was the right fix
 ## 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.
+
+## 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.
+
+## 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`.
+
+## 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.
+
+## 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.
+
+## 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.
+
+## 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.

README.md

@@ -0,0 +1,131 @@
+# holocron
+
+The global AI development configuration repository — the authoritative source for agent definitions, skills, workflows, and prompts across all projects. Built as a homelab tool intended to scale to professional environments.
+
+Content ships as six installable plugins, each an apm (Agent Package Manager) package. This repo consumes its own plugins through apm, so the working copy runs the same released content every other consumer gets.
+
+## Repo layout
+
+| Path | What it holds |
+| --- | --- |
+| `plugins/` | Six apm packages — `bin`, `core`, `git`, `gitea`, `kyberforge`, `lint` — each carrying skills, and where relevant agents, hooks, MCP servers, and bundled assets |
+| `providers/claude-code/` | Claude Code adapter, deployed to `~/.claude/` via `scripts/install.sh` |
+| `core/` | Provider-agnostic always-on content — `core/AGENTS.md` and `core/instructions/` |
+| `docs/` | Specs (`docs/spec/`), architectural decisions (`docs/adr/`), governance, research, and notes |
+| `scripts/` | Install, sync, and check scripts used by the git hooks |
+| `tests/` | `run-tests.sh`, `run-bats.sh`, the `test-*.sh` suites, and the bats submodules |
+
+The six plugins:
+
+- **kyberforge** — skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace
+- **git** — conventional commits, branches, history, submodules, worktrees, remotes, pre-commit hook authoring and running (`pc-author` / `pc-run`), and an interactive router (`git-workflow`)
+- **gitea** — issues, pull requests, labels, milestones, releases, branches, files, and an interactive router (`gitea-workflow`)
+- **core** — authoring and auditing a repo's `AGENTS.md` and the provider adapter files that defer to it
+- **lint** — configuring and running linters
+- **bin** — cross-cutting workflow skills not yet split into a focused plugin: research, documentation, TDD, prototyping, triage, diagnosis, architecture review, requirement grilling, compressed output (`caveman`), and re-orienting mid-task (`zoom-out`)
+
+## Prerequisites
+
+Install all of these before setting up. Each one is a hard dependency of a git hook or a script — several fail with an unhelpful "command not found" if missing.
+
+| 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 |
+| `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 |
+
+Two notes worth reading before you skip one:
+
+- **PyYAML is a hard requirement, not an optional accelerator.** The hand-rolled fallback frontmatter reader was removed deliberately: a reader that mis-parses an unfamiliar scalar shape reports a clean pass on a file it never measured.
+- **No `vale sync` is needed.** The `Kyberforge` styles are committed under `plugins/kyberforge/.apm/skills/{skill-audit,agent-audit}/assets/vale/styles/`, not downloaded packages (ADR-0014).
+
+## Setup
+
+Run these in order, from the repo root.
+
+```bash
+# 1. Deploy this repo's own skills and agents
+apm install
+
+# 2. Install the git hooks — all three stages
+pre-commit install -t pre-commit -t commit-msg -t pre-push
+```
+
+**`apm install`** deploys the six plugins into `.claude/skills/` and `.claude/agents/`. Both are gitignored install output, *not* authoring source — `plugins/<name>/.apm/` remains the only place to edit. It needs the network, materializes `apm_modules/` (which stays gitignored), and also configures the `obsidian` MCP server into the repo's `.mcp.json`.
+
+**Git hooks** must be wired for **all three stages**. This repo's `.pre-commit-config.yaml` has no `default_install_hook_types`, so a plain `pre-commit install` silently skips `commit-msg` (Conventional Commits) and `pre-push` (the full gate) — the `-t` flags above are not optional. The `pc-run` skill handles this and the troubleshooting around it, if you would rather not remember the flags.
+
+## Keeping the install current
+
+The six dependencies in root `apm.yml` are unpinned against the default branch, so deployed skills go stale whenever anyone merges. kyberforge ships a `SessionStart` hook that runs `apm outdated` at startup (~0.7s) and, when something is behind, runs `apm update --yes` and asks the host to re-scan skills (~10.4s).
+
+That rewrites `apm.lock.yaml` — an unexplained modification to it after opening a session is expected, not a bug. Commit or discard it deliberately.
+
+Note the difference between the two commands:
+
+- `apm install` deploys from `apm.lock.yaml`. It does **not** pick up remote changes.
+- `apm update` re-resolves refs. This is the command that pulls in a merged `.apm/` edit.
+
+## Running tests
+
+```bash
+bash tests/run-tests.sh              # every test-*.sh script plus the bats suite
+bash tests/run-tests.sh --bats-only  # just bats
+```
+
+The first run auto-initializes the bats submodules; no manual `git submodule update` needed.
+
+A suite that exits 77 because a dependency is missing is reported as SKIPPED and does **not** fail an ad-hoc run. It *does* fail under `--strict` (equivalently `RUN_TESTS_STRICT=1`), which is how the pre-push hook invokes it — at pre-push, a skip means one of the prerequisites above is absent on this machine, and the gate would otherwise report success having run fewer suites than it appears to. The strict failure names each skipped suite and what to install.
+
+## Before pushing
+
+Run the pre-push gate locally in one command:
+
+```bash
+pre-commit run --hook-stage pre-push --all-files
+```
+
+One caveat: `check-release-needed` is a silent no-op under this invocation. It exits 0 unless
+`PRE_COMMIT_REMOTE_BRANCH` is `refs/heads/main`, and pre-commit exports that only from the real
+pre-push git hook during an actual `git push` — so the hook reports `Passed` having checked nothing.
+Every other pre-push hook does run.
+
+See [`docs/spec/gates.md`](docs/spec/gates.md) for what each hook enforces and why.
+
+**Offline?** Exactly two pre-push hooks need the network, because root `apm.yml`'s marketplace contains one remote package entry that must be resolved with `git ls-remote`:
+
+```bash
+SKIP=apm-marketplace-check,apm-pack-check-clean git push
+```
+
+Skip **only** those two. The remaining pre-push hooks are real local checks and pass offline; adding one of them to `SKIP` disarms it silently.
+
+## Editing plugin content
+
+`plugins/<name>/.apm/` is the only hand-edited source for plugin content — skills, agents, commands, instructions, extensions, and hooks. The flat `plugins/<name>/{skills,agents,commands,instructions,extensions}/` directories, the merged `hooks/hooks.json`, and every `plugin.json` / `marketplace.json` manifest are generated. Nothing labels a generated file as generated, so check the path before you edit; an edit to the mirror is discarded by the next sync and 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` — lives at the plugin **root** and is untouched. Never place such a file inside a mirrored directory: the sync removes the destination before every copy, so it is deleted with no drift report.
+
+Full detail in [`docs/spec/architecture.md`](docs/spec/architecture.md).
+
+## For external consumers
+
+Install a plugin natively from the marketplace manifests:
+
+```bash
+claude plugin install <name>@holocron
+```
+
+Or consume the packages through apm, the way this repo does — declare them as `dependencies.apm` git+path entries against the holocron remote and run `apm install`.
+
+## Where to go next
+
+- [`AGENTS.md`](AGENTS.md) — the rules for AI agents working in this repo
+- [`CONTEXT.md`](CONTEXT.md) — domain language; read at the start of every session here
+- [`docs/spec/architecture.md`](docs/spec/architecture.md) — directory structure, install pipeline, provider model
+- [`docs/spec/gates.md`](docs/spec/gates.md) — the enforcement gates in depth
+- [`docs/adr/`](docs/adr/) — architectural decisions; read before proposing structural changes
+- [`docs/VISION.md`](docs/VISION.md) — where this is going
+- [`LESSONS.md`](LESSONS.md) — things that went wrong once and should not again

apm.yml

@@ -0,0 +1,119 @@
+name: holocron
+version: 0.4.5
+description: AI development skills for Claude Code and GitHub Copilot CLI — factory, design, implement, review, and cross-cutting workflows.
+license: MIT
+
+# Consumer side: this repo installs its own published plugins from the holocron
+# remote, so the working copy runs the same released content every other
+# consumer gets. Addressed as git+path objects rather than <name>@holocron
+# marketplace aliases — an alias needs a `apm marketplace add` registration in
+# ~/.apm/marketplaces.json (user scope, outside this repo), the object form
+# needs nothing beyond this manifest.
+# Unpinned (default branch) on purpose: parity with the Claude Code plugin
+# install this replaced, which ran autoUpdate against main. Add `ref: <tag>`
+# per entry to pin.
+targets:
+  - claude
+dependencies:
+  apm:
+    - git: git@git.dev.rkdr.net:Defame1297/holocron.git
+      path: plugins/bin
+    - git: git@git.dev.rkdr.net:Defame1297/holocron.git
+      path: plugins/core
+    - git: git@git.dev.rkdr.net:Defame1297/holocron.git
+      path: plugins/git
+    - git: git@git.dev.rkdr.net:Defame1297/holocron.git
+      path: plugins/gitea
+    - git: git@git.dev.rkdr.net:Defame1297/holocron.git
+      path: plugins/kyberforge
+    - git: git@git.dev.rkdr.net:Defame1297/holocron.git
+      path: plugins/lint
+  mcp: []
+
+# Turns apm's executable-trust gate ON. Without this block the gate is disabled
+# and every hook, bin and MCP primitive a dependency ships deploys silently —
+# verified: `apm approve --list` reports "Executable-trust gate disabled -- all
+# executables deploy" until an `executables:` block exists.
+#
+# kyberforge ships the SessionStart hook that keeps this install level with the
+# remote (ADR-0019). The key is version-pinned by apm's own design, so a
+# kyberforge version bump makes this entry stop matching and the hook stops
+# deploying until the version here is bumped too. If skills silently go stale
+# after a kyberforge release, check this first.
+executables:
+  allow:
+    kyberforge#1.6.0:
+      hooks: true
+      bin: true
+
+marketplace:
+  # apm's Claude marketplace mapper only emits description:/version: into the
+  # compiled marketplace.json when set explicitly here (an override) — the
+  # 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
+  owner:
+    name: Defame1297
+    email: defame1297@rkdr.net
+    url: https://git.dev.rkdr.net/Defame1297/
+
+  # Default tag pattern used to resolve version ranges for each package.
+  build:
+    tagPattern: "v{version}"
+
+  # Output targets (map form). Each output writes to its profile default
+  # path; add 'path:' under a key to override.
+  # 'codex' requires every package below to declare 'category:' (satisfied).
+  outputs:
+    claude: {}
+    codex: {}
+
+  # CI tip: build one or all formats with a machine-readable manifest:
+  #   apm pack --marketplace=claude,codex --json | jq -r '.marketplace.outputs[].path'
+
+  versioning:
+    strategy: per_package
+
+  packages:
+    - 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
+      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
+      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
+      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
+      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
+      category: Productivity
+
+    - name: mattpocock-skills
+      description: Skills for Real Engineers — planning, TDD, architecture, and debugging workflows from Matt Pocock's .claude directory.
+      source: mattpocock/skills
+      version: "1.2.3"
+      category: Productivity
+
+    - name: lint
+      description: Skills and agents for configuring and running linters.
+      source: ./plugins/lint
+      version: 1.1.6
+      category: Developer Tools

docs/adr/0001-skills-in-agents-dir.md

@@ -1,5 +1,16 @@
 # Skills are distributed via plugins, not monolithic repo deployment
 
+**Superseded by:** ADR-0015 (Microsoft APM replaces the hand-authored plugin/marketplace model
+as this repo's authoring source of truth) and, for plugin-scope agent files specifically,
+ADR-0016 (plugin-scope `.apm/agents/*.agent.md` drops provider-specific fields). Since issue
+#90's conversion executed, plugin content is authored under `plugins/<name>/apm.yml` +
+`.apm/{skills,agents,hooks}/` — not the flat `skills/`/`agents/` layout this ADR describes —
+and `.claude-plugin/plugin.json`/`.github/plugin/plugin.json` are compiled output of `apm pack`,
+not hand-authored. This ADR's content is kept below as the historical record of the
+pre-APM decision; it is no longer the current model.
+
+---
+
 Skills (slash commands) are authored and distributed as part of **plugins** — each plugin contains its own `skills/` directory alongside agents and other artifacts. Plugins are installed via `claude plugin install <name>@holocron` rather than deployed from the repo's local tree. This decision decouples skill authoring cadence from core provider deployments and allows independent versioning per plugin.
 
 ## Context

docs/adr/0005-agent-author-dual-provider-scaffold.md

@@ -44,3 +44,8 @@ separate single-provider skill, adding complexity with no benefit.
 file now lives at `<plugin-root>/sources.md`, outside the `agents/` directory, because
 `claude plugin validate --strict` auto-discovers every `.md` under `agents/` as an agent
 requiring frontmatter. See ADR-0010 for the empirical finding and rationale.
+
+**Update (ADR-0016):** the plugin-scope clause above is superseded. Plugin scope is no longer
+detected via `plugin.json`, and no longer produces a Claude+Copilot file pair — a directory
+containing `apm.yml` now gets a single vendor-neutral `.apm/agents/<name>.agent.md` file with
+no provider-specific fields. Project scope and user scope are unaffected. See ADR-0016.

docs/adr/0006-plugin-version-parity.md

@@ -1,5 +1,18 @@
 # version field is present in both plugin manifests
 
+**Moot as of ADR-0015.** This ADR addressed drift risk between two independently
+*hand-maintained* manifests. Since issue #90's conversion executed, `.claude-plugin/plugin.json`
+and `.github/plugin/plugin.json` are both **compiled output** of `apm pack`, generated in the
+same pass from a single `apm.yml` per plugin — there is no longer a second hand-authored file
+that could drift out of parity. The invariant this ADR required (`version` present and
+identical in both manifests) still holds in the compiled output, but structurally, not because
+a skill enforces it: both files are derived from the same `apm.yml` `version:` field, so
+divergence is no longer possible by construction. `plugin-author`, the skill that enforced this
+invariant, is deleted per ADR-0015 rather than adapted. Kept below as the historical record of
+the pre-APM decision.
+
+---
+
 Each plugin has two manifests: `plugin.json` (Copilot CLI) and `.claude-plugin/plugin.json` (Claude Code). Both tools support a `version` field. Prior to this decision, only the CC manifest carried `version`; the Copilot manifest omitted it.
 
 We now require `version` in both manifests, always identical. A reader of `plugin.json` alone should be able to determine the plugin version without consulting the CC manifest. The `plugin-author` skill enforces this invariant on every create, update, and release operation.

docs/adr/0007-gitea-canonical-issue-tracker.md

@@ -2,6 +2,8 @@
 
 **Supersedes:** ADR-0011 (provider-agnostic issue tracker with file-based default — archived during refactoring)
 
+> **Note on the ADR-0011 number.** Every "ADR-0011" on this page means the *archived* provider-agnostic issue tracker ADR, which no longer exists in `docs/adr/` — it was removed when it was superseded, and the number 0011 was later reused for an unrelated decision, `docs/adr/0011-gitea-skill-deep-modules.md` (the gitea skill's split into deep modules). That file is not the ADR referenced below. The number is not renumbered here: these ADRs are a published record and renumbering would break every citation that already points at either one. The archived text is recoverable from git history.
+
 ADR-0011 established a provider-agnostic model with `docs/issues/NNNN-<slug>.md` as the file-based default, switching to Gitea MCP at runtime when available. The interim model was justified because Gitea would not be configured until after Chunk 3, and the repo needed to work before then.
 
 Gitea is now configured and in active use. The condition in ADR-0011 has been met. This ADR supersedes it.
@@ -16,4 +18,4 @@ Three alternatives were rejected. Keeping the file-based fallback adds code comp
 
 The file-based model also had a structural weakness: issues in `docs/issues/` were invisible from the Gitea UI, making it impossible to track work, assign milestones, or filter by label without opening the repo locally. Gitea provides all of that natively.
 
-The "Provider-agnostic issue tracker" glossary entry in CONTEXT.md is updated in the same workstream to remove the file-based phase framing. The `providers/gitea/` adapter path described in ADR-0011 was never implemented — Gitea integration runs entirely via MCP, not a provider adapter.
+The "Provider-agnostic issue tracker" glossary entry in CONTEXT.md is updated in the same workstream to remove the file-based phase framing. (Amended 2026-08-17: the CONTEXT.md trim renamed that entry to **Issue**; it still records Gitea as this repo's canonical tracker and still tells skills to say "linked issue" generically.) The `providers/gitea/` adapter path described in ADR-0011 was never implemented — Gitea integration runs entirely via MCP, not a provider adapter.

docs/adr/0008-agent-audit-single-file-invocation.md

@@ -14,3 +14,9 @@
 - Scope detection walks up from the input file: first directory containing `plugin.json` → plugin scope; first directory containing `.git` without `plugin.json` → project scope; path under `~` with neither → user scope.
 - At user scope the derivation crosses filesystem locations (`~/.claude/agents/` ↔ `~/.copilot/agents/`); the script must handle the home directory case explicitly.
 - The invocation signature is the public contract. Changing it is a breaking change to any caller — treat it as such.
+
+**Update (ADR-0016):** the plugin-scope clause above is superseded. Plugin scope is no longer
+detected via `plugin.json`, and there is no counterpart to derive — a directory containing
+`apm.yml` produces a single `.apm/agents/<name>.agent.md` file, and `agent-audit` validates it
+directly with no pair-consistency check. Project scope and user scope keep the pair-derivation
+mechanism described above unchanged. See ADR-0016.

docs/adr/0010-agent-sources-relocated-outside-agents-dir.md

@@ -5,6 +5,21 @@ claim that "both files share a single `agents/sources.md` for provenance." The r
 ADR-0005 (dual-provider generation, scope detection, single-root script interface) is
 unaffected and remains in force.
 
+**Path update per ADR-0016:** at plugin scope, agent files no longer live at
+`<plugin-root>/agents/<name>.md`. The authoring source is now
+`<plugin-root>/.apm/agents/<name>.agent.md` — a single vendor-neutral file (no dual Claude/
+Copilot pair) compiled to both targets via `apm pack`. See ADR-0016 for why (the field-dropping
+rationale, `tools:` incompatibility, the compiled-output mechanics) — not restated here. This
+ADR's own conclusion is unaffected by that move: the provenance file still belongs at
+`<plugin-root>/sources.md`, outside any directory `claude plugin validate --strict`
+auto-scans, and `.apm/agents/` is, if anything, further removed from plugin-root than the old
+flat `agents/` directory was, so the reasoning below still holds. References below to
+`<plugin-root>/agents/` describe the pre-APM layout in effect when this decision was made.
+**Scope boundary (per ADR-0016):** this path change is plugin scope only. Project scope
+(`.claude/agents/` + `.github/agents/`) and user scope (`~/.claude/agents/` +
+`~/.copilot/agents/`) are unaffected — they are not APM packages and keep the dual-file
+Claude+Copilot pair model this ADR originally described.
+
 `claude plugin validate --strict` auto-discovers every `.md` file directly under a plugin's
 `agents/` directory and treats it as an agent definition requiring YAML frontmatter (`name`,
 `description`, etc.). A flat provenance file at `agents/sources.md` — no frontmatter, by

docs/adr/0013-vale-harness-scope-and-rule-sources.md

@@ -9,6 +9,12 @@ deferred PR #85 review item to broaden that coverage, retroactively captures #84
 (since it was never recorded as a decision in its own right), and layers the expansion on top
 without reversing or weakening the original four rules.
 
+**2026-08-17 amendment.** The CONTEXT.md section named above no longer holds that documentation.
+CONTEXT.md was cut back to a glossary and the prefilter's mechanics — the two-copy style layout,
+`vale-wrap.sh`, the `--config` argv defect, the rule inventory, and the 0-files-means-NOT-RUN
+fallback — moved to `docs/spec/gates.md`. Read that file, not CONTEXT.md, for the harness itself;
+this ADR still owns the scope decision.
+
 **File scope stays the same.** `SKILL.md` plus agent files (`**/agents/*.md`,
 `**/*.agent.md`) only — matching the existing prefilter's globs. Skill-level
 `README.md` files and `plugin.json` manifests are not added: README.md files are navigational, not

docs/adr/0014-vale-prefilter-ships-from-the-plugin.md

@@ -18,9 +18,9 @@ full LLM judgment every time outside this repo — the exact gap ADR-0013 named
 the plugin itself, following the no-cross-skill-path rule already established in
 `skill-author/references/deployment-modes.md` (a plugin's cache-install only copies each skill's
 own files; there is no plugin-level shared directory). `agent-audit` needs both `Kyberforge` and
-`KyberforgeCopilot` (it lints `.agent.md` files), so `plugins/kyberforge/skills/agent-audit/assets/vale/`
+`KyberforgeCopilot` (it lints `.agent.md` files), so `plugins/kyberforge/.apm/skills/agent-audit/assets/vale/`
 is the canonical, superset copy. `skill-audit` needs a second, smaller copy
-(`plugins/kyberforge/skills/skill-audit/assets/vale/`, `Kyberforge` only) since it cannot
+(`plugins/kyberforge/.apm/skills/skill-audit/assets/vale/`, `Kyberforge` only) since it cannot
 reference agent-audit's copy across the skill boundary. Both skills' Step 1 now resolve
 `scripts/vale-wrap.sh`/`assets/vale/.vale.ini` relative to their own directory, the same way
 `scripts/validate.sh <skill-dir>` already does — no new resolution mechanism, just applying the
@@ -38,7 +38,7 @@ and gets all three, fully decoupled from Claude Code. CI is the identical `pre-c
 **This repo's own dev-time gate** consumes the same plugin-bundled copies instead of a third
 root-level copy — per explicit instruction, this repo should be set up like any other consumer
 would be, not dogfood a special root-only path. The existing `repo: local` hook is retargeted
-(not removed): `entry:` now points at `plugins/kyberforge/skills/{skill-audit,agent-audit}/scripts/vale-wrap.sh`.
+(not removed): `entry:` now points at `plugins/kyberforge/.apm/skills/{skill-audit,agent-audit}/scripts/vale-wrap.sh`.
 `repo: local` is kept rather than switching to a pinned self-reference
 (`repo: <own-url>, rev: <tag>`) — a pinned self-reference would lint working-tree edits against
 the *last tagged release*, not the change actually being made, which is wrong for the repo that
@@ -58,15 +58,20 @@ single hook at agent-audit's copy silently scanned 0 SKILL.md files.)
 **The hook `entry:` is the wrapper alone; the wrapper self-locates its config.** pre-commit
 prefixes only `entry[0]` with the hook-repo clone path (`cmd = (prefix.path(cmd[0]), *cmd[1:])`);
 every later argument is handed to the process untouched and so resolves against the *consuming*
-repo's root. A `--config plugins/kyberforge/skills/…/assets/vale/.vale.ini` in
+repo's root. A `--config plugins/kyberforge/.apm/skills/…/assets/vale/.vale.ini` in
 `.pre-commit-hooks.yaml` therefore named a path no consumer has, and every external run died with
 `E100 [--config] Runtime error`. The external-consumer contract this ADR exists to establish
 cannot be expressed as a `--config` argument at all — the config path has to be derived inside
 the process, from the script's own location. `vale-wrap.sh` accordingly defaults to its sibling
 `assets/vale/.vale.ini`, resolved from `${BASH_SOURCE[0]}`, whenever no `--config` is supplied;
 an explicit `--config` from any other caller still wins and still resolves against the caller's
-cwd, so both audit skills' Step 1 (`--config assets/vale/.vale.ini`) is unaffected. Both
-manifests now carry the identical argument-free `entry:`. Keeping them identical is part of the
+cwd. Both audit skills' Step 1 passes no `--config` either, for the same reason and one more: a
+relative `--config assets/vale/.vale.ini` resolves against the cwd, not against the skill
+directory the wrapper path was resolved from, so it yields `E100 Runtime error … does not exist`
+and exit 2 — which both skills' fallback misreads as "vale unavailable" and silently downgrades
+to full LLM judgment, the exact failure the self-location exists to prevent. Both `SKILL.md` Step
+1 sections say so explicitly ("Pass no `--config`"), and both manifests now carry the identical
+argument-free `entry:`. Keeping them identical is part of the
 decision: the local `repo: local` hook resolved its `--config` correctly only because the
 consuming repo *was* this repo, and that one difference is why three review rounds exercised a
 code path no external consumer ever takes.
@@ -105,8 +110,8 @@ doesn't wonder if it was overlooked.
 ## Consequences
 
 - Root `.vale.ini`, `styles/`, `scripts/vale-wrap.sh` are deleted. Two copies remain:
-  `plugins/kyberforge/skills/agent-audit/assets/vale/` (canonical, superset) and
-  `plugins/kyberforge/skills/skill-audit/assets/vale/` (subset, `Kyberforge` only).
+  `plugins/kyberforge/.apm/skills/agent-audit/assets/vale/` (canonical, superset) and
+  `plugins/kyberforge/.apm/skills/skill-audit/assets/vale/` (subset, `Kyberforge` only).
 - `plugins/kyberforge`'s `plugin.json` and `.claude-plugin/plugin.json` both patch-bump for every
   shipped content change (per ADR-0006's version-parity invariant): `1.2.5` for the relocation
   itself, `1.2.6` for the self-locating `vale-wrap.sh` that followed.

docs/adr/0015-apm-replaces-plugin-marketplace-authoring.md

@@ -0,0 +1,180 @@
+# Microsoft APM replaces the hand-authored plugin/marketplace model as this repo's authoring source of truth
+
+**Status: executed (2026-08-12, issue #90).** All six plugins now carry `apm.yml` + `.apm/` as
+their authoring source; `.claude-plugin/marketplace.json` and every plugin's `plugin.json` are
+`apm pack`-compiled output. **Supersedes ADR-0001** ("Skills are distributed via plugins... each
+plugin contains its own `skills/` directory") — in effect.
+
+This repo replaces its hand-maintained Claude Code plugin/marketplace authoring model
+(`.claude-plugin/marketplace.json` + per-plugin `plugin.json`) with Microsoft APM (`apm.yml` +
+`.apm/`) as the authoring source of truth — an outright replacement of the authoring layer, not an
+additive overlay. This ADR records the decision from a `grill-with-docs` session on issue #88.
+
+## Context
+
+Every plugin under `plugins/<name>/` currently ships two hand-maintained manifests
+(`.claude-plugin/plugin.json` for Claude Code, root `plugin.json` for Copilot CLI) plus a
+hand-maintained root `.claude-plugin/marketplace.json` listing all plugins. Adding a provider means
+hand-authoring a third manifest shape; keeping the two existing ones in parity is itself a tracked
+concern (ADR-0006).
+
+Research on Microsoft APM (`plugins/kyberforge/docs/research/docs/microsoft-apm/`) found that its
+documented "monorepo-hybrid" repo shape maps directly onto this repo's existing `plugins/<name>/`
+layout: each plugin becomes its own `apm.yml` + `.apm/{skills,agents,hooks,prompts,instructions}/`
+package, listed from a root `apm.yml`'s `marketplace:` block. `apm compile`/`apm pack` generate
+per-target output — including a `.claude-plugin/marketplace.json` — from that vendor-neutral
+`.apm/` tree, so provider manifests become compiled artifacts instead of hand-authored files, and
+new providers (Copilot, Gemini, Codex — all supported by `apm runtime setup`) no longer require a
+new hand-maintained manifest format.
+
+## Decision
+
+- **The `plugins/<name>/` monorepo-hybrid directory layout survives.** `.claude-plugin/marketplace.json`
+  and per-provider `plugin.json` files become **compiled output** via `apm compile`/`apm pack`,
+  generated from `apm.yml` + `.apm/` per plugin, extensible to other `apm runtime`-supported
+  providers without hand-maintaining a separate manifest per provider.
+- **This supersedes ADR-0001** ("Skills are distributed via plugins... each plugin
+  contains its own `skills/` directory"). Executed in issue #90: skills and agents physically moved
+  to `plugins/<name>/.apm/skills/` and `plugins/<name>/.apm/agents/*.agent.md`.
+- New operational tooling — `apm-install` (skill), `apm-workflow` (skill), `apm-orchestrate`
+  (agent) — lands in `kyberforge`, tracked in issue #88
+  (https://git.dev.rkdr.net/Defame1297/holocron/issues/88).
+- Adapting `skill-author`/`agent-author`'s routing to author `.apm/`-native content (retargeting to
+  `.apm/skills/`, `.apm/agents/` paths — the content these two skills author is still meaningful
+  post-conversion) is deferred to issue #89
+  (https://git.dev.rkdr.net/Defame1297/holocron/issues/89). `forge` is out of scope for #89 — it
+  stays untouched by this whole conversion effort and keeps routing to whatever the live author
+  skills are at the time.
+- **`plugin-author`/`marketplace-author` are not adapted — they are superseded and deleted.**
+  Unlike `skill-author`/`agent-author`, nothing in these two skills carries forward as authoring
+  routing: `apm compile`/`apm pack` will generate `.claude-plugin/marketplace.json` and
+  per-provider `plugin.json` directly from `apm.yml` + `.apm/`, so `apm-install`/`apm-workflow`/
+  `apm-orchestrate` (issue #88, already landed on this branch) fully replace what these two skills
+  did. `plugin-author`/`marketplace-author` were deleted in issue #90's execution.
+- Translating the existing plugins into `apm.yml` + `.apm/` and running the real conversion was
+  executed under issue #90 (https://git.dev.rkdr.net/Defame1297/holocron/issues/90), which tracks
+  that work through to merge.
+- `CONTEXT.md`'s "Plugin"/"Plugin marketplace" glossary entries were rewritten in issue #90 to
+  describe the compiled-output model directly, rather than carrying a forward-pointer to this ADR.
+  Superseded 2026-08-17: CONTEXT.md was cut back to one-line definitions, and the compiled-output
+  model is now described in `docs/spec/architecture.md`. The same trim deleted the "lint plugin"
+  entry cited under Considered options below; that pointer now reads `docs/spec/architecture.md`'s
+  plugin scope table, which carries the repo-agnostic-versus-marketplace-specific argument.
+
+## Considered options
+
+**Additive/compile-layer only, no `apm.yml` (rejected).** Keep `plugin.json`/`marketplace.json`
+hand-authored and bolt APM on top as an optional extra. Rejected: doesn't achieve the multi-provider
+compile-reuse goal APM's package model provides, and leaves the existing dual-manifest hand
+maintenance in place unchanged.
+
+**New standalone `plugins/apm/` plugin (rejected).** `plugins/lint/` was split out of `kyberforge`
+specifically because Vale tooling is generic and repo-agnostic, not holocron-marketplace-specific
+(see `docs/spec/architecture.md`'s plugin scope table) — the same argument applies to a generic `apm` CLI
+wrapper. The shipped `apm-install`/`apm-workflow` skills are, in fact, generic, repo-agnostic APM
+CLI documentation with no holocron-specific content, so a standalone `plugins/apm/` would have
+been a defensible split on artifact content alone. Rejected anyway, in favor of `kyberforge`,
+because holocron is currently the only repo that needs this tooling — standing up a separate
+plugin for a single consumer isn't worth it yet. Accepted as an explicit tradeoff (same pattern
+as ADR-0011's `gitea-workflow` naming tradeoff) — worth revisiting if this tooling is ever reused
+outside holocron's own conversion.
+
+## Content migration out of `plugin-author`/`marketplace-author`
+
+A content audit of `plugin-author`/`marketplace-author` (same `grill-with-docs` session as this
+correction) sorted what they document into three buckets:
+
+- **Claude Code platform constraints — carried forward.** Facts that stay true regardless of
+  authoring model (reserved plugin-name prefixes; the `agents/`-directory stray-`.md`-file
+  validator gotcha, ADR-0010; `claude plugin validate` as a required terminal check) have been
+  added into `apm-workflow`'s reference docs, since compiled output still has to satisfy these
+  constraints post-conversion.
+- **Dual-manifest artifacts — obsolete, not carried forward.** Conventions that existed only
+  because of hand-authored dual manifests (ADR-0006's version-parity/patch-bump rule, the
+  CC-vs-Copilot field-placement split, dual-file mirroring) are obsolete under `apm.yml`'s
+  single-manifest model and were deliberately dropped.
+- **Holocron policy choice — resolved in #90.** `marketplace-author`'s catalog-version convention
+  (minor bump for package add/remove, patch bump for field-only updates) isn't an APM mechanic —
+  `apm` doesn't enforce it, and has no native version-bump automation at all — so rather than
+  building a new script, the convention is now documented as guidance inside `apm-workflow`'s
+  reference docs (`references/marketplace.md` for the root catalog version rule,
+  `references/configure.md` for the per-package version-bump-on-content-edit rule), applied
+  manually by whoever edits `apm.yml`.
+
+## Consequences
+
+- ADR-0001 is superseded (issue #90).
+- ADR-0006 (plugin-version-parity) is moot (issue #90): `plugin.json`/`marketplace.json` are now
+  compiled output of a single `apm.yml`, so there's no second hand-authored file left to keep in
+  parity, and `plugin-author` — the skill that enforced ADR-0006 — was deleted rather than adapted
+  (see "Content migration" above).
+- ADR-0010 (agent sources relocated outside agents dir) was updated (issue #90) for agents now
+  living at `plugins/<name>/.apm/agents/*.agent.md` — the directory path changed; the pre-existing
+  `.agent.md` extension convention (ADR-0005/ADR-0010) and project/user scope are unaffected, per
+  ADR-0016.
+- ADR-0014 (Vale prefilter ships from the plugin) had its hardcoded `plugins/<name>/skills/...`
+  paths (the Vale prefilter is skill-scoped only; ADR-0014 never referenced a
+  `plugins/<name>/agents/...` path) updated for the `.apm/` nesting as part of issue #90's
+  execution.
+- `kyberforge` gained three new artifacts (issue #88) before any conversion of existing content
+  happened, then lost two (`plugin-author`/`marketplace-author`, deleted once issue #90 verified
+  parity) — net version bump 1.3.1 → 1.4.0. The root marketplace catalog bumped 0.3.1 → 0.3.2 to
+  match.
+- ADR-0016 (a narrower decision discovered while designing issue #89) turned out to gate how
+  issue #90 had to re-author plugin-scope agents: `.apm/agents/*.agent.md` compiles verbatim to
+  both Claude and Copilot, so those files carry only the fields in the `apm-agent-allowlist` section
+  of `plugins/kyberforge/.apm/skills/agent-audit/references/field-inventory.md` (as amended
+  2026-08-14: `name`/`description`/`model`/`source_keys`/`disallowedTools`) — existing dual-file
+  `<name>.md`+`<name>.agent.md` pairs could not be raw-moved, only re-authored.
+- Two follow-up issues tracked the remaining work: #89 (`skill-author`/`agent-author` routing
+  adaptation — closed, merged in #93) and #90 (the actual repo conversion, which also deleted
+  `plugin-author`/`marketplace-author` — tracked through to merge; treat #90's own state as the
+  authority on whether it has landed, not this line).
+- **`displayName` is gone from all six compiled `plugin.json` files — accepted, not overlooked.**
+  `apm.yml` has no key that compiles to it: `synthesize_plugin_json_from_apm_yml`
+  (`apm_cli/deps/plugin_parser.py`) emits only `name`, `version`, `description`, `author`,
+  `license`, `homepage`, `repository` and `keywords`, and nothing in `plugin_manifest.py` adds
+  `displayName` afterwards. So every `plugins/<name>/.claude-plugin/plugin.json` now carries
+  `author`/`description`/`homepage`/`keywords`/`license`/`name`/`repository`/`version` (plus
+  `mcpServers` for `bin`) and no `displayName`. The field is optional —
+  `plugins/kyberforge/docs/research/docs/claude-code-plugins/api-reference.md:14` lists
+  `displayName` as `Required: No`, "Human-readable name shown in plugin manager" — which is why
+  `claude plugin validate --strict` still passes on all six. The visible cost is that the plugin
+  manager falls back to the bare `name` as each plugin's label. Accepted as the price of `apm.yml`
+  being the single authoring source: re-injecting `displayName` post-compile would mean a second
+  `reinject_*` workaround of the kind ADR-0017's amendment reserves for fields apm strips on a
+  factually wrong premise, and apm's premise here is simply that the key does not exist in its
+  schema.
+- **`owner.email` was dropped by mistake and has been restored (2026-08-14).** An earlier revision
+  of this ADR listed `owner.email` alongside `displayName` as a field `apm.yml` "has no key that
+  compiles to." That was wrong. `apm_cli/marketplace/yml_schema.py:186` defines
+  `_AUTHOR_OBJECT_KEYS = frozenset({"name", "email", "url"})`, and an `email:` under root
+  `apm.yml`'s `marketplace.owner` block was empirically confirmed to compile straight through into
+  `.claude-plugin/marketplace.json`'s `owner`. The key is declared in root `apm.yml` again and the
+  compiled `owner` block is `{name, email, url}`. Only `displayName` is a genuine schema gap; this
+  one was a documentation error that removed working configuration.
+- **`mattpocock-skills` is pinned to an exact version, and the pin is advanced by hand.**
+  Pre-conversion the entry was `{"repo": "mattpocock/skills", "source": "github"}` — an unpinned
+  reference that tracked the upstream default branch, so consumers got whatever was on it at
+  install time. The conversion first replaced that with `version: "^1.2.0"`, which was still not a
+  pin: a caret range has nothing to freeze it, because there is no lockfile for
+  `marketplace.packages[]`. `apm pack` re-resolved the range against upstream on **every** run, so
+  an upstream `v1.2.4` would immediately invalidate the committed `ref`/`sha` and fail
+  `apm-pack-check-clean` with exit 4 — blocking every push in the repo, triggered by a third party
+  at an unrelated moment, with no local change to explain it. Root `apm.yml` therefore declares an
+  exact `version: "1.2.3"`, which `apm pack` freezes into `.claude-plugin/marketplace.json` as
+  `ref: v1.2.3` + an explicit `sha`. Two consequences, both intended: the committed ref/sha is
+  genuinely reproducible and cannot move under the repo, and picking up a new upstream release is a
+  deliberate act — a human edits the `version:` string in root `apm.yml` and re-runs `apm pack`.
+  apm has no version-bump automation (established under "Versioning" in issue #90's plan), so an
+  ageing pin is the accepted cost of a push gate that only fires on this repo's own changes.
+  Note the pin does not make the entry offline-resolvable: an exact version still requires a
+  `git ls-remote`, which is why two pre-push hooks need the network (see `AGENTS.md`).
+- **Caveat on "Status: executed" above:** issue #90's own execution comment flagged, before merge,
+  that Claude Code's ability to actually load content out of `.apm/` was unverified — that caveat
+  turned out to be a real defect, not a formality: the native installer has zero awareness of
+  `.apm/` and reported `Skills (0) Agents (0) Hooks (0)` on every plugin installed from this
+  marketplace. The manifest-compilation deliverable this ADR describes was genuinely complete;
+  runtime discoverability was not. Fixed in ADR-0017 (a second, compiled flat-directory content
+  mirror at each plugin root, generated by `scripts/sync-plugin-content.sh`) — see that ADR for
+  the root cause and the fix.

docs/adr/0016-apm-agent-primitive-drops-provider-specific-fields.md

@@ -0,0 +1,174 @@
+# Plugin-scope agent-author omits `tools:` and all Claude-only fields from `.apm/agents/*.agent.md`
+
+This ADR is a narrower, downstream consequence discovered while designing issue #89's
+implementation under ADR-0015's broader direction (Microsoft APM replaces hand-authored
+plugin/marketplace authoring). It does not restate ADR-0015's rationale — see that ADR for
+the parent decision.
+
+## Context
+
+APM's agent primitive (`.apm/agents/<name>.agent.md`) has no per-target integrator in
+`apm compile` — confirmed via APM's own Python source (`integration/targets.py` and related
+files, cited in `plugins/kyberforge/docs/research/docs/microsoft-apm/agent-primitive-schema.md`).
+Compilation does a naive verbatim copy of the whole frontmatter and body to both the Claude
+Code and Copilot CLI targets. This is unlike:
+
+- The **skill** primitive, which is also a straight copy (confirmed in the same research doc)
+  but has no field semantics to conflict — `SKILL.md`'s content is target-agnostic already.
+- The **prompt**, **instructions**, and **hooks** primitives, which each get real per-target
+  reconstruction through a dedicated integrator (field allowlisting, key renaming, dropped-field
+  warnings).
+
+Because the agent primitive ships the same frontmatter unchanged to both harnesses, two
+concrete incompatibilities surface:
+
+1. **`tools:`** — Claude Code expects tool names drawn from its own vocabulary, as a
+   comma-separated string or a YAML list (`agent-definition.md:37`); Copilot CLI expects a list
+   drawn from a different alias vocabulary (`execute`/`read`/`edit`/`search`/`agent`/`web`). The
+   incompatibility is the vocabulary, not the punctuation: a value correct for one harness names
+   tools the other does not have.
+2. **Claude-only knobs with no Copilot equivalent** — `isolation`, `maxTurns`, `effort`,
+   `memory`, `permissionMode`. Writing any of these means Copilot's copy carries frontmatter
+   keys it doesn't recognize at all. Whether Copilot's agent loader ignores unknown keys or
+   errors on them is unconfirmed by research. *(Still unconfirmed as of the 2026-08-14 amendment
+   below, which admits `disallowedTools` as an explicitly accepted risk rather than by resolving
+   this question.)*
+
+## Decision
+
+At **plugin scope only** (destination package has an `apm.yml` at its root — an APM producer
+package compiled via `apm compile`), `.apm/agents/<name>.agent.md` carries only `name`,
+`description`, `model`, and the prose body. No `tools:` field, no Claude-only fields, at all.
+
+*(Narrowed by the 2026-08-14 amendment below: `disallowedTools` is admitted as a fifth allowed
+field. `tools:` and every other Claude-only knob remain excluded on the reasoning given here.)*
+
+Absent `tools:` means inherit-all-tools on both harnesses — the one value that is never wrong
+on either target, unlike a present, harness-specific value that is guaranteed wrong on at least
+one of them.
+
+`agent-audit`, at plugin scope, is intended to flag — as a **SUGGESTION**, not a FAIL, since
+this is an upstream schema limitation rather than an authoring mistake — any agent whose
+description or body implies a need for tool restriction or a Claude-only behavior the
+frontmatter can no longer express. This would give visibility into the gap without pretending
+the schema can do something it can't. **Not yet implemented**: `check_apm_agent_file()` in
+`validate.sh` currently validates only the field allowlist, `name`, `description`, and
+body-emptiness/length — it has no heuristic for this case. Tracked as follow-up work.
+
+### Scope boundary
+
+This decision applies to **plugin-scope `agent-author` only**. Project scope (`.claude/agents/`
++ `.github/agents/`) and user scope (`~/.claude/agents/` + `~/.copilot/agents/`) are not APM
+packages — neither goes through `apm compile` — so both keep today's dual-file Claude+Copilot
+pair model exactly as ADR-0005 and ADR-0008 already describe. Those two ADRs remain fully
+authoritative for project and user scope; only their plugin-scope clauses are affected by this
+ADR (see the update notes appended to each).
+
+## Considered options
+
+**Pick one harness's vocabulary and accept breakage on the other (rejected).** E.g. always
+write Claude's space-separated `tools:` string. Rejected because it ships a value that is
+silently wrong (or possibly a hard error) on Copilot, and which harness "wins" would be an
+arbitrary, undocumented asymmetry.
+
+**Same as above, but `agent-audit` flags the cross-harness breakage as a tracked finding
+(rejected).** Rejected for the same core reason — it still ships a wrong value to a real
+harness. Tracking the breakage doesn't prevent it, and the chosen decision already gets
+equivalent visibility (a SUGGESTION finding) without ever shipping the wrong value in the first
+place.
+
+## Amendment (2026-08-14): the write fence comes back as a denylist
+
+The decision above generalised from `tools:` to "no tool restriction at all". That over-reached.
+The unportability argument is specific to the **allowlist**: Claude Code reads `tools:` as a
+delimited string of its own tool names, Copilot CLI reads it as a list drawn from its
+alias vocabulary (`execute`/`read`/`edit`/`search`/`agent`/`web`), so one value is wrong on one
+harness. That reasoning stands, and `tools:` stays out of every plugin-scope agent.
+
+A **denylist** has no such conflict. The evidence for that splits three ways, and this amendment
+states which part is which rather than asserting the whole as settled.
+
+**Confirmed — Claude Code honours it for plugin subagents.**
+`plugins/kyberforge/docs/research/docs/claude-code-plugins/agent-definition.md:39` documents
+`disallowedTools` as a "Denylist applied before `tools`… Takes precedence over `tools`", and — the
+part that matters here — it is **not** in that document's plugin-subagent ignore list. Line 99
+names exactly three fields plugin agents silently ignore: `hooks`, `mcpServers`, `permissionMode`.
+`disallowedTools` is absent from that list. Claude Code is also the harness where the fence is
+actually wanted, so the field earns its place on this evidence alone.
+
+**Inferred — the field is very likely inert on Copilot CLI, but by analogy, not by documentation.**
+`plugins/kyberforge/docs/research/docs/github-copilot-plugins/troubleshooting.md:50` and `:53`
+record Copilot *silently ignoring* two agent frontmatter fields it does not process (`mcp-servers`
+and `metadata` outside the cloud runtime) rather than erroring on them. That is a documented
+tolerance for *known-but-unprocessed* keys, which is adjacent to, not identical to, tolerance for
+an *unknown* key. No stronger evidence exists: a sweep of the vendored Copilot corpus
+(`agent-definition.md`, `api-reference.md`, `troubleshooting.md`, `configuration.md`) documents
+unknown-key handling nowhere.
+
+**Unverified — Copilot's loader behaviour on an unrecognised key.** Context item 2 above says this
+is unconfirmed by research and that remains true; nothing found since changes it. An earlier
+revision of this amendment claimed "an unrecognised frontmatter key is inert" as settled fact and
+attributed it to apm's verbatim-copy behaviour. That attribution was a non-sequitur — verbatim copy
+describes what *apm* does at compile time and says nothing about what *Copilot* does at load time —
+and the claim contradicted this ADR's own Context section.
+
+**So this is an accepted risk, stated as one.** Blast radius if the inference is wrong and Copilot
+errors on the key: the three affected plugin-scope agents fail to load under Copilot CLI. It is
+loud, not silent; it is confined to three agents in three plugins; no other primitive and no Claude
+Code path is affected; and the remedy is a one-line frontmatter deletion. What the denylist shape
+*does* rule out categorically — independent of loader behaviour — is the failure mode that motivated
+dropping `tools:` in the first place: a denied name the other harness does not recognise denies
+nothing, so a mis-shaped value can never grant or misroute a capability. The risk is a load failure,
+never a silent over-grant. That asymmetry is why the same verbatim copy that makes `tools:`
+unshippable makes `disallowedTools` worth shipping.
+
+So the read-only orchestrator agents regain their write fence: `gitea-orchestrate`,
+`apm-orchestrate` and `lint-runner` each carry `disallowedTools: Edit, Write, NotebookEdit` plus
+explicit prose in the body stating the agent does not edit files. `git-orchestrate` is deliberately
+excluded — it legitimately declared `edit` before the conversion and still needs to write.
+
+**Residual — the fence is partial, and the prose is doing more of the work than the field is.**
+`disallowedTools: Edit, Write, NotebookEdit` denies exactly those three tools. It does not deny
+`Bash`, and at plugin scope these agents carry no `tools:` and therefore inherit it, so
+`bash -c 'echo … > f'` remains unfenced by frontmatter. Only the body prose covers that path. This
+is not a regression introduced here — the pre-conversion `tools:` allowlists also granted `Bash`,
+so the shell route was open then too — but the ADR should not credit the mechanism with more than
+it delivers. Closing it would need a `disallowedTools` entry for `Bash`, which these agents cannot
+take because they legitimately shell out.
+
+Net position: the allowlist stays dropped for the reason originally given, and the denylist is
+admitted as the portable-by-construction half of what was lost. It restores a real, Claude-Code-
+confirmed write fence against the tool-call path, not a complete write sandbox. The consequence
+below is narrowed accordingly.
+
+Enforcement follows the decision: `agent-audit`'s plugin-scope validator reads its allowlist as
+data from the `apm-agent-allowlist` section of
+`plugins/kyberforge/.apm/skills/agent-audit/references/field-inventory.md`, and that line now reads
+`name description model source_keys disallowedTools`. `disallowedTools` also stays in that file's
+`claude-code-only-fields` list, which is not a contradiction — that list governs whether a field
+may cross the CC/Copilot boundary in a real project/user-scope *pair*, a different question from
+whether a field is safe under verbatim copy in a single vendor-neutral file.
+
+## Consequences
+
+- Every plugin-scope APM agent loses per-agent tool *allowlisting* and any Claude-only capability
+  (isolation, maxTurns, effort, memory, permissionMode) until APM ships a real per-target
+  integrator for the agent primitive. This is a known, accepted regression, not an oversight.
+  Tool **denial** is not part of that loss — see the 2026-08-14 amendment above.
+- **ADR-0005 is partially superseded** — its plugin-scope clause ("directory containing
+  `plugin.json` is plugin scope → both files land in `<root>/agents/`") no longer applies.
+  Plugin scope is now "directory containing `apm.yml` → single vendor-neutral file lands in
+  `<root>/.apm/agents/`." Project and user scope, and the rest of ADR-0005, are unaffected.
+- **ADR-0008 is partially superseded** — its counterpart-derivation/pair-validation mechanism
+  no longer applies at plugin scope; `agent-audit` takes the single file directly there. Project
+  and user scope, where a real pair still exists, are unaffected.
+- **ADR-0009 is not superseded.** The mechanism it established — `agent-audit` reading field
+  lists from `references/field-inventory.md` rather than hardcoding them, with a `source_keys`
+  provenance chain — survives and is reused. Only the *content shape* changes for plugin scope:
+  `field-inventory.md` shifts from two side-by-side CC-only/Copilot-only blocklists to one
+  vendor-neutral allowlist for plugin-scope agents, while continuing to serve its original
+  two-blocklist role for project/user-scope validation. That file's `apm-agent-allowlist` section
+  is the authoritative list and is read as data by `validate.sh`; as amended on 2026-08-14 it holds
+  `name`/`description`/`model`/`source_keys`/`disallowedTools` — `source_keys` for provenance
+  tracking, validated separately by `validate-provenance.sh` against `sources.md` rather than being
+  a provider-specific field, and `disallowedTools` per the amendment above.

docs/adr/0017-plugin-content-mirror-bridges-apm-to-host-discovery.md

@@ -0,0 +1,348 @@
+# Plugin roots gain a compiled flat-directory mirror of `.apm/` content so Claude Code can discover it
+
+This ADR is a follow-on correction to ADR-0015 (Microsoft APM replaces hand-authored
+plugin/marketplace authoring), discovered during issue #90's post-execution review. It does not
+restate ADR-0015's rationale for adopting `.apm/` as the authoring source of truth — see that ADR
+for the parent decision. It resolves the one question ADR-0015's own execution flagged as open but
+did not block on: whether Claude Code's installer can actually load content out of `.apm/`. It
+could not.
+
+**Status: executed (2026-08-13, issue #90).** `scripts/sync-plugin-content.sh` has been run
+against all 6 plugins; flat `agents/`, `skills/`, `commands/` (etc., wherever `.apm/` populates
+them), and a merged hooks file now exist at each plugin root as tracked, generated files. The
+merged hooks file lands at `hooks/hooks.json`, not at the plugin root itself — see the second
+amendment below, which corrects the path this ADR originally recorded.
+
+## Context
+
+ADR-0015's execution comment on issue #90 (2026-08-12) flagged, before merge: "it's currently
+unverified whether Claude Code can actually discover any skill/agent content in these plugins...
+This needs to be checked... before treating this conversion as functionally complete, not just
+manifest-complete." That caveat did not block ADR-0015 from shipping "Status: executed" — the
+manifest-compilation deliverable (`.claude-plugin/marketplace.json`/`plugin.json` generated from
+`apm.yml` + `.apm/`) was genuinely complete, and every automated gate (`apm audit --ci`,
+`claude plugin validate --strict` ×6, `apm marketplace check`) passed clean — so the ADR merged
+with the caveat noted but unresolved.
+
+The caveat turned out to be a real defect, not a formality. `claude plugin install` against all
+three plugins tested (`git@holocron`, `gitea@holocron`, `kyberforge@holocron`) reported
+`Skills (0) Agents (0) Hooks (0)`. Root cause, confirmed two independent ways:
+
+1. **Claude Code's installer scans flat convention directories only.** `strings` on the installed
+   `claude` binary finds zero references to `.apm/` or `apm.yml` anywhere. The installed plugin
+   cache (`~/.claude/plugins/cache/holocron/kyberforge/1.3.1/`) mirrors the pre-conversion flat
+   `skills/`/`agents/`/`hooks/` layout verbatim — that is what the installer actually copies and
+   reads. `plugins/kyberforge/docs/research/docs/claude-code-plugins/configuration.md`'s own
+   "Plugin Directory Layout" table documents the same flat convention (`skills/<name>/SKILL.md`,
+   `agents/`, `hooks/hooks.json`, all "at the plugin root, not inside `.claude-plugin/`") — this
+   was accurate before ADR-0015 and never stopped being accurate; ADR-0015 moved plugin content
+   without adding a bridge to it.
+2. **apm's own manifest compiler has no `.apm/` → host-path bridge, by design.**
+   `apm_cli/core/plugin_manifest.py`'s `build_plugin_manifest` docstring states directly:
+   "Convention directories (`agents/`, `skills/`, `commands/`) are auto-discovered by the host, so
+   they are never listed explicitly in the manifest." apm's Claude/Copilot compiler assumes plugin
+   content already lives in those flat root-level directories; it has no model of `.apm/` nesting
+   being host-visible at all, so it never emits anything that would point a host at `.apm/`.
+
+Separately, `apm_cli/bundle/plugin_exporter.py`'s `export_plugin_bundle` (the engine behind
+`apm pack --format plugin`) *does* implement the correct mapping — `.apm/agents` → `agents/`,
+`.apm/skills` → `skills/` (subdirs preserved), `.apm/prompts` + `.apm/commands` → `commands/`
+(`*.prompt.md` renamed to `*.md`), `.apm/instructions` → `instructions/`, `.apm/extensions` →
+`extensions/`, and `.apm/hooks/*.json` merged into one `hooks.json`. But it was only ever wired to
+produce a distributable bundle under `build/<name>-<version>/` — a path nothing in root
+`apm.yml`'s per-package `marketplace.packages[].source:` fields (e.g. `./plugins/bin`) or
+`marketplace.json`'s equivalent points at. The correct mapping existed in apm's own codebase the
+whole time; it was simply never connected to the path this repo's marketplace actually installs
+plugins from.
+
+## Decision
+
+Each plugin root gains a second, generated content category, produced by
+`scripts/sync-plugin-content.sh` (wraps `apm pack --format plugin`, copies the resulting bundle's
+`agents/`, `skills/`, `commands/`, `instructions/`, `extensions/`, and merged hooks file back to
+the plugin root — the hooks file to `hooks/hooks.json`, per the second amendment below) — same
+governance status as `.claude-plugin/plugin.json`/`marketplace.json`:
+**compiled output of `.apm/`, never hand-edited.**
+
+- `.apm/` remains the sole hand-edited authoring source, unchanged from ADR-0015.
+- The flat mirror is what Claude Code's (and Copilot's) installer actually convention-scans at
+  install time — it exists purely to satisfy the host's discovery contract, a contract apm's own
+  manifest compiler deliberately does not bridge.
+- `plugin.json`/`apm.lock.yaml`/`.mcp.json` from the bundle are excluded from the copy:
+  `plugin.json` is already correctly generated by a separate, already-verified apm code path
+  (`build_plugin_manifest`, run in the same `apm pack` invocation); `.mcp.json` is hand-authored
+  at the plugin root per ADR-0015 and is not an `.apm/` primitive.
+- Dev-fixture `tests/` directories are excluded too — they are dev-time fixtures no plugin host
+  ever needs to discover, and several reference their own repo root through a hardcoded relative
+  walk-up sized for `.apm/`-nested depth, so a copy one directory level shallower breaks the
+  duplicate and double-runs the original under repo-wide bats discovery. The exclusion is
+  **depth-scoped to `<category>/<name>/tests`**, deliberately: a skill may legitimately ship a
+  directory literally named `tests` as a template asset it scaffolds *from*
+  (`skills/skill-author/assets/templates/tests`, at depth 4). A depth-agnostic `-name tests`
+  matched that too and stripped it, making the mirrored `new-skill.sh` die mid-run on
+  `sed: can't read .../tests/README.md` — the scaffolder seds its way through the template tree
+  file by file. Scaffolding assets survive; fixtures do not.
+- Drift is enforced by a pre-push gate (`scripts/sync-plugin-content.sh --check --all`, wired into
+  `.pre-commit-config.yaml` as hook id `check-plugin-content-sync` by a parallel workstream on
+  issue #90) — the same enforcement model `check-manifests.sh` already applies to the other
+  compiled-output category. `--check` alone is not the gate: the script requires either `--all` or
+  an explicit list of plugin directories, and run bare it prints usage and exits 1. `--all` derives
+  its work list from `marketplace.json`, a generated file, so it asserts its own coverage against
+  that list: it fails if it verified fewer plugins than the marketplace declares, not merely if it
+  verified none. A listed plugin whose `.apm/` has gone missing is skipped by the per-plugin sync
+  and would otherwise let the gate report success over a shrinking work list.
+- Verified two ways before landing: `claude plugin validate --strict` passes on all 6 real
+  (non-scratch) plugin directories, and a live behavioral test
+  (`claude --plugin-dir plugins/kyberforge -p "list your skills and agents"`) against the real
+  committed directory confirms `kyberforge:*` skills and the `kyberforge:apm-orchestrate` agent
+  are now actually discovered — they were not, before this fix.
+- The stale root-level `plugins/<name>/plugin.json` files (a near-duplicate of
+  `.claude-plugin/plugin.json` that nothing read or wrote, flagged separately in issue #90's
+  review) were deleted across all 6 plugins as part of the same cleanup.
+
+## Considered options
+
+**Patch `plugin.json`'s content-pointer fields to point directly at `.apm/` paths (rejected).**
+Claude Code's manifest schema documents these as legitimate override fields that accept custom
+paths — `plugins/kyberforge/docs/research/docs/claude-code-plugins/configuration.md` shows a real
+example (`"skills": "./custom/skills/"`, `"agents": ["./custom/agents/reviewer.md"]`), so the host
+side of this would work. Rejected because apm never emits such a pointer and would have to be
+worked around on every run to make it do so.
+
+Be precise about the mechanism, because an earlier revision of this ADR overstated it. apm 0.28.0's
+`build_plugin_manifest` (`apm_cli/core/plugin_manifest.py`) does carry a strip loop, but its field
+list is `("agents", "skills", "commands", "instructions")` — `hooks` is **not** in it, and
+`instructions` **is**, which this ADR previously did not mention. More to the point, that loop can
+never fire: the manifest it operates on comes from `synthesize_plugin_json_from_apm_yml`
+(`apm_cli/deps/plugin_parser.py`), which only ever emits `name`, `version`, `description`,
+`author`, `license`, `homepage`, `repository` and `keywords`. The pointer fields are absent from
+apm's output because `apm.yml` has no schema for them, not because apm actively removes them — the
+`pop` loop is defensive dead code against a manifest shape apm does not produce.
+
+The rejection is unaffected by that correction, only its framing. Honoring this option would still
+mean post-processing apm's compiled output on every `apm pack` run to add fields apm's schema has
+no way to express, rather than reusing `plugin_exporter.py`'s bundle-export mapping, which already
+does the right thing and only needed its output redirected to a path the installer reads. What it
+is *not* is a fight against a load-bearing apm code path — the honest statement is that apm has no
+input for these fields, and inventing one downstream is a workaround this ADR did not need.
+
+**Point `marketplace.json`'s `source:` at `apm pack`'s `build/<name>-<version>/` output directly
+(rejected).** Would reuse the bundle exporter's correct mapping without adding a new script.
+Rejected: `build/` is a version-suffixed, regenerate-on-every-pack directory — pointing the
+marketplace at it would mean either committing a moving-target build artifact to version control
+(defeating the point of it being generated) or requiring every consumer's marketplace to run
+`apm pack` before install, a build step Claude Code's installer has no hook for — it clones/fetches
+source and scans directories; it does not execute a package manager's build command first.
+Copying the relevant subset back to the stable `plugins/<name>/` path — where `marketplace.json`
+already points — needed no change to the marketplace source model at all.
+
+## Amendment (2026-08-13, revised 2026-08-14): Copilot's `plugin.json` gets an `mcpServers` *path*
+
+PR #95's review (a follow-on to this same issue #90 workstream) found a second field apm's
+compiler drops for the Copilot ecosystem: `build_plugin_manifest` runs
+`manifest.pop("mcpServers", None)` on every Copilot-ecosystem `plugin.json`, its docstring stating
+the field is "not part of the Copilot plugin manifest schema." That claim is contradicted by this
+repo's own researched documentation —
+`plugins/kyberforge/docs/research/docs/github-copilot-plugins/configuration.md:49` documents
+`mcpServers` as a valid, optional `plugin.json` field, typed **"string or object — MCP server
+config path or inline definitions."**
+
+This is not the same situation "Considered options" above rejected. There, apm emits no pointer
+because its schema has no input for one and the host auto-discovers the directories anyway, so
+nothing is missing. Here a field Copilot actually reads is actively removed on a premise that is
+wrong against documented Copilot behavior, and there is no auto-discovery mechanism that makes it
+redundant. Shipping the manifest as apm produces it would ship a manifest known to be incomplete.
+
+`scripts/sync-plugin-content.sh`'s `reinject_mcp_servers()`, called from `sync_one()`, therefore
+sets `mcpServers` on `.github/plugin/plugin.json` after `apm pack` runs — to the **string
+`".mcp.json"`**, the path form of the documented type, not the resolved server objects. Only when
+the plugin's `.mcp.json` declares at least one server, matching apm's own Claude-ecosystem builder,
+which omits the field entirely rather than emitting `mcpServers: {}`.
+
+**The payload is a path because an inlined object is a credential-leak path.** The original
+implementation copied `.mcp.json`'s resolved `mcpServers` object into the manifest with `jq`. That
+route bypasses apm's own `_sanitize_mcp_servers()` (`apm_cli/core/plugin_manifest.py`), which
+strips credential keys and redacts secret values out of `.mcp.json` precisely because — in its own
+words — "copying them verbatim into a committed `plugin.json` would exfiltrate them into the
+distributed artefact." Today's `.mcp.json` files here carry no `env` block, so nothing leaked; the
+first one that did would have written a live token into a tracked, published manifest, with the
+sanitizer sitting one code path away and never invoked. A path reference cannot carry a secret at
+all: the manifest names a file, and resolution happens in the host at load time. This also matches
+apm's documented posture for MCP secrets — `microsoft-apm/configuration.md:96-98` requires `${VAR}`
+indirection so secrets are "never committed to the manifest."
+
+**Both modes re-inject**, not just real syncs: real mode writes into the plugin root directly,
+`--check` into its throwaway copy first, so the manifest diff compares against the same content a
+real sync would actually produce (see the script's own header). A check-mode re-injection is what
+keeps `--check` from reporting permanent phantom drift on every plugin that ships an `.mcp.json`.
+
+This remains scoped to one field found to be incorrectly dropped. It does not reopen the
+content-pointer option rejected above: those fields stay absent because apm has no schema input for
+them and the host needs no pointer, which is a different situation from a documented field being
+actively removed.
+
+Consequence: if a future apm release corrects the Copilot `mcpServers` omission, `reinject_mcp_servers()`
+and its call site become dead code and should be deleted — nothing else in this ADR depends on the
+reinjection existing beyond working around this specific upstream gap.
+
+Line numbers are deliberately omitted above. An earlier revision of this amendment cited
+`reinject_mcp_servers()` at line 190 and its call site at line 269; both had already moved by the
+next review round of the same PR, and moved again with the edits recorded in the amendment below.
+A function name is stable enough to grep for; a line number in an ADR is stale by the next commit.
+
+## Amendment (2026-08-14): the merged hooks file lands at `hooks/hooks.json`, not the plugin root
+
+As originally executed, `sync-plugin-content.sh` wrote the merged hooks file to
+`plugins/<name>/hooks.json`. That path is scanned by nothing. Claude Code convention-scans
+`hooks/hooks.json`, and the "Plugin Directory Layout" table this ADR's own root-cause analysis
+quotes above says so:
+`plugins/kyberforge/docs/research/docs/claude-code-plugins/configuration.md:100` is the row naming
+`hooks/hooks.json`, six lines below the table's preamble at `:94` — "All content directories must
+be at the plugin root, not inside `.claude-plugin/`". The two are not the same line; an earlier
+revision of this amendment said they were. The implementation read the preamble's "at the plugin
+root" and dropped the file there, without reading the row that names the path. So this ADR shipped
+with the contract quoted correctly in its diagnosis and violated in its output — the flat mirror
+bridged skills and agents into discovery and left hooks exactly as undiscoverable as before the
+fix.
+
+The merged file therefore moves to `plugins/<name>/hooks/hooks.json`. A root-level `hooks.json`
+left over from a prior sync is stale output: a real sync deletes it, `--check` reports it as
+drift. The real sync produced exactly these working-tree changes — `plugins/kyberforge/hooks.json`
+and `plugins/lint/hooks.json` deleted, `plugins/kyberforge/hooks/hooks.json` and
+`plugins/lint/hooks/hooks.json` created. Only those two plugins have an `.apm/hooks/` tree, so
+only those two grow a mirrored hooks file at all.
+
+This does **not** reopen the "patch `plugin.json` pointer fields" option rejected above. The move
+needs no `hooks` pointer in `plugin.json`: `hooks/hooks.json` *is* the convention path, so the
+host finds it by auto-discovery, exactly as it finds `skills/` and `agents/`. The rejection stands
+for the reason it was made, once stated accurately — apm emits no pointer field for any of these,
+because `apm.yml` has no key that produces one, and none is needed when content sits at the
+convention path. (`hooks` was never in `build_plugin_manifest`'s strip list at all; see the
+corrected mechanism note under "Considered options".) Writing to the convention path is what makes
+the no-pointer premise true here rather than something to work around.
+
+Read "the host finds it by auto-discovery" above as **Claude Code**, not both hosts. Copilot has no
+default for `hooks` and so discovers none — a real gap, examined and deliberately left open in the
+next amendment.
+
+## Amendment (2026-08-14): no `hooks` pointer is re-injected for Copilot — the gap stays documented
+
+PR #95's review found a third field, and it looks like the `mcpServers` amendment's exact twin:
+`plugins/kyberforge/docs/research/docs/github-copilot-plugins/configuration.md:47` types `hooks` as
+a `plugin.json` field, **"string or object"**, with **no default** — so Copilot has no convention
+path to scan — and `jq 'has("hooks")'` returns `false` for all six `plugins/*/.github/plugin/plugin.json`.
+Copilot therefore resolves **zero hooks from every plugin in this repo**. The facts are not in
+dispute; the remedy is.
+
+State the mechanism correctly first, because it differs from `mcpServers` and the amendment above
+depends on that distinction. `mcpServers` is *actively removed* — `build_plugin_manifest` runs
+`manifest.pop("mcpServers", None)` on every Copilot manifest. `hooks` was **never in that strip
+list** (its field list is `("agents", "skills", "commands", "instructions")`, and the loop is dead
+code besides — see "Considered options"). This is an absence apm never fills, not a removal to
+reverse.
+
+**Decision: do not re-inject. Document the gap.** The `mcpServers` exception was granted on three
+conditions, and `hooks` meets only two of them:
+
+1. *A documented host schema field.* Met — `hooks` is in Copilot's own field table.
+2. *apm has no input that produces it.* Met — `apm.yml` has no key for it.
+3. *The payload is correct for the host regardless of content.* **Not met**, and this is the whole
+   difference. `.mcp.json` is one host-agnostic format that both ecosystems read, so the string
+   `".mcp.json"` is a true statement about the file no matter what is in it. Hooks have no such
+   shared format: Claude Code reads
+   `{"hooks": {"PreToolUse": [{"matcher": ..., "hooks": [...]}]}}` while Copilot requires
+   `{"version": 1, "hooks": {"sessionStart": [{"type": "command", "bash": ..., "powershell": ...}]}}`
+   — a mandatory `version`, lowercase and differently-named lifecycle events, and per-shell script
+   keys. apm's exporter merges `.apm/hooks/*.json` into **exactly one** `hooks.json` with no
+   per-target shaping (`_collect_hooks_from_apm`, `apm_cli/bundle/plugin_exporter.py`), and that one
+   file also sits at Claude Code's convention path, where Claude Code will read it whatever it
+   contains. So there is exactly one file and two incompatible readers of it.
+
+A `hooks` pointer would therefore assert that a Claude-shaped file is Copilot-shaped. That trades an
+*incomplete* manifest for a *wrong* one, which is the opposite of the `mcpServers` amendment's
+reasoning ("shipping the manifest as apm produces it would ship a manifest known to be incomplete").
+
+The "it changes nothing today, so it is zero-risk and correct-by-construction for the first real
+hook" argument does not survive the same check, in both halves. It is not inert today: both
+`hooks/hooks.json` files are `{"hooks": {}}`, which lacks the `version: 1` Copilot's schema
+requires, so a pointer would name a file invalid against the schema it is being pointed at from —
+a change from "declares no hooks" to "declares hooks, at an invalid file". And it is not
+correct-by-construction later: whoever writes the first real hook writes it in one of the two
+shapes, and the pointer is wrong in the Claude-shaped case (the case that actually happens, since
+Claude Code auto-discovers the same file and is what these hooks are authored against) while the
+Copilot-shaped case breaks Claude Code instead. No content makes both readers correct.
+
+What would change this decision is upstream, not local: apm emitting a per-target hooks file (at
+which point a pointer names a file genuinely shaped for its reader), or the two hook schemas
+converging. Until then the honest artifact is a documented gap, recorded for authors in
+`plugins/kyberforge/docs/hooks.md` and pinned by a test asserting the Copilot manifest carries no
+`hooks` key — so that adding one is a deliberate act that has to confront the schema mismatch,
+rather than a plausible-looking one-liner nobody re-derives.
+
+This does not weaken the `mcpServers` amendment. That exception was narrow on purpose, and this is
+what its third condition was for.
+
+## Amendment (2026-08-14): symlinks under `.apm/` are dropped, and are now reported
+
+apm's bundle exporter filters symlinks out of the bundle entirely — `f.is_file() and not
+f.is_symlink()` in `_collect_flat` and `_collect_recursive`, and the same test in
+`_collect_hooks_from_apm` (`apm_cli/bundle/plugin_exporter.py`). It emits no warning. A symlink
+placed under a plugin's `.apm/` therefore never reaches the mirror, and until now nothing said so.
+
+This was **silent content loss, not drift**, and that distinction is why no existing gate caught it.
+Every other check in `sync-plugin-content.sh` compares the live mirror against a freshly synced
+copy — and both sides are built from that same bundle. The symlink is absent from both, they agree,
+and `--check` exits 0. There is no mismatch to detect, only an absence with nothing left to
+mismatch against. Reproduced on a fixture: `ln -s real.md link.md` under `.apm/skills/hello/`
+produced a mirror with no `link.md` and a `--check` at exit 0.
+
+`check_apm_symlinks()` therefore reads the `.apm/` **source** tree directly — the only place the
+loss is visible — and reports each symlink in both modes, failing the run. It is reported rather
+than resolved: dereferencing and copying the target would make a real sync emit content the bundle
+does not contain, which is precisely the "reimplement apm's mapping outside apm" this ADR rejects.
+Telling the author is the in-contract half.
+
+The scan covers only the `.apm/` directories apm's exporter actually reads
+(`agents`, `skills`, `prompts`, `commands`, `instructions`, `extensions`, `hooks`), and carves out
+`<category>/<name>/tests` to match the mirror's own exclusion — that subtree is not mirrored whether
+or not it holds a symlink, so nothing is lost there. The carve-out is depth-scoped for the same
+reason the `tests/` exclusion is: a symlink under `assets/templates/tests` sits in content the
+mirror does carry, and is reported.
+
+## Consequences
+
+- Git now tracks real, visible duplication: `.apm/skills/<name>/SKILL.md` and
+  `skills/<name>/SKILL.md` both exist and must match, likewise `.apm/agents/*.agent.md` vs.
+  `agents/*.agent.md`, and `.apm/hooks/*.json` vs. the merged `hooks/hooks.json` (see the
+  2026-08-14 amendment above for that path). This is an accepted
+  tradeoff of bridging a gap apm itself doesn't close, not a bug — `.apm/` stays the single
+  hand-edited source, and the drift gate (`check-plugin-content-sync`) is what keeps the mirror
+  honest rather than trusting authors to remember to regenerate it by hand.
+- `scripts/check-manifests.sh`'s existing blind spot (flagged in the same issue #90 review round:
+  it validated `plugin.json` fields that ADR-0015 already stopped populating, so a plugin shipping
+  zero content could pass it silently) is fixed as part of the same workstream: those field checks
+  are removed (nothing to check — the fields are correctly absent by design), and the
+  content-presence question they were standing in for is now answered by
+  `check-plugin-content-sync`, not re-implemented inside `check-manifests.sh`.
+- ADR-0015's "Status: executed" now carries a pointer to this ADR (see that ADR's Consequences)
+  rather than being rewritten — the manifest-compilation half of its execution was correct and
+  stands; this ADR fixes the second, previously-unverified half.
+- `CONTEXT.md`'s "Plugin" and "Plugin marketplace" glossary entries are updated to describe the
+  flat mirror as a second compiled-output category, alongside the existing
+  `.claude-plugin/plugin.json`/`marketplace.json` description. Superseded 2026-08-17: CONTEXT.md was
+  cut back to one-line definitions and no longer describes either compiled-output category;
+  `docs/spec/architecture.md` is where the mirror is documented.
+- A future apm release that ships a native `.apm/`-aware plugin.json compiler (closing this gap
+  upstream) would let `sync-plugin-content.sh` and its drift gate be deleted outright — nothing in
+  this ADR's decision depends on the flat mirror existing beyond satisfying the current installer's
+  convention-scan contract.
+- **Reproduction note (2026-08-13):** the live behavioral test cited in "Decision" above
+  (`claude --plugin-dir plugins/kyberforge -p "list your skills and agents"`) is only a clean
+  kyberforge-only signal when run from a working directory outside this repo. Run literally as
+  written, from this repo's root, this repo's own project-level `.claude/settings.json` sets
+  `enabledPlugins` to true for all 6 holocron plugins (kyberforge, git, gitea, core, lint, bin), so
+  Claude Code loads all 6 plugins' skills/agents, not just kyberforge's — conflating kyberforge's
+  discoverability with the other 5 plugins' already-enabled content. To isolate the signal, run
+  from a neutral cwd outside `/root/ai-development` with an absolute `--plugin-dir` path, e.g.
+  `cd /some/neutral/dir && claude --plugin-dir /root/ai-development/plugins/kyberforge -p "list your skills and agents"`.
+- Reference: issue #90 (https://git.dev.rkdr.net/Defame1297/holocron/issues/90).

docs/adr/0018-repo-consumes-its-own-plugins-through-apm.md

@@ -0,0 +1,149 @@
+# This repo installs its own plugins through apm, not Claude Code's native plugin install
+
+ADR-0015 moved plugin **authoring** to apm; ADR-0017 added the flat content mirror that keeps the
+authored `.apm/` tree discoverable by hosts that install natively. Both are about producing the
+marketplace. This ADR is about consuming it: how the plugins get onto the machine this repo is
+worked on.
+
+**Status: executed (2026-08-14).** All six packages are installed into `/root/ai-development` by
+`apm install`; the six native project-scope installs (`claude plugin uninstall <name>@holocron
+--scope project`) are gone and `.claude/settings.json`'s `enabledPlugins` block is empty.
+
+## Context
+
+Until now the repo consumed its own output the same way any user would: `claude plugin install
+<name>@holocron`, six plugins enabled per-project in `.claude/settings.json`, the `holocron`
+marketplace registered in `~/.claude/plugins/known_marketplaces.json` with `autoUpdate: true`.
+That worked. It also meant the repo's dogfooding stopped one layer short of the tooling it
+publishes: `kyberforge` ships `apm-workflow` and `apm-install` skills describing an install path
+the repo itself did not take.
+
+apm supports both scopes. `apm install --global` deploys to `~/.claude/`; plain `apm install`
+deploys to the project. Global was rejected deliberately — the switch should be provable in one
+repo before it changes how every other project on the machine resolves its skills.
+
+## Decision
+
+Root `apm.yml` declares all six packages under `dependencies.apm`, each as a `git:`/`path:` object
+against the holocron remote:
+
+```yaml
+dependencies:
+  apm:
+    - git: git@git.dev.rkdr.net:Defame1297/holocron.git
+      path: plugins/core
+```
+
+`apm install` deploys them to `.claude/skills/<name>/` and `.claude/agents/<name>.md`.
+
+Three sub-decisions inside that:
+
+- **Object form over the `<name>@holocron` marketplace alias.** The alias is shorter and apm
+  resolves it correctly (verified end-to-end against this remote), but it first requires
+  `apm marketplace add`, which writes to `~/.apm/marketplaces.json` — user scope, outside the
+  repo, and absent on a fresh clone. The object form needs nothing beyond the committed manifest.
+- **Remote source over local path.** apm accepts `path: /root/ai-development/plugins/<name>` as a
+  local dependency, which would make the working tree live instantly. Rejected: it erases the
+  distinction between editing a skill and shipping one, which is the entire point of having a
+  marketplace. The remote form keeps the repo running the same released content every other
+  consumer gets.
+- **Unpinned against the default branch.** Parity with the `autoUpdate: true` the native install
+  had. apm warns on every install (`6 dependencies unpinned`); accepted knowingly. Pinning is a
+  per-entry `ref:` away once the repo tags releases per package — today `git tag` lists one tag
+  total, so there is nothing meaningful to pin to.
+
+## Consequences
+
+**Skills gain an unnamespaced name.** apm deploys plain project skills, so `git:git-commits` also
+answers to `git-commits` and `kyberforge:skill-audit` to `skill-audit`. This is not configurable —
+a project skill has no plugin to prefix. `AGENTS.md` and `CONTEXT.md` are updated to name the bare
+form, which is what apm deploys and the only form a repo consuming holocron through apm gets.
+
+**Correction (2026-08-14): the namespaced form did not stop resolving.** *Superseded by the
+2026-08-17 correction below: the machine state this cites is no longer present. Both are kept
+because the pair is the finding — read neither as current.* An earlier revision of
+this consequence said every `<plugin>:<skill>` reference "was stale the moment the switch landed",
+and `AGENTS.md`/`CONTEXT.md` were written to match. That contradicts the "User scope is untouched,
+deliberately" consequence below, and the contradiction resolves against it: `~/.claude.json` still
+enables `core`, `git`, `gitea`, `kyberforge` and `lint` at user scope, so both names are live at
+once and a working `gitea:gitea-prs` is the user-scope copy answering. That doubling is the same
+"present twice under two names" outcome the "Keeping both install paths" alternative was rejected
+for — reached by leaving user scope alone rather than by adopting it, which is why it is a
+consequence to record rather than a decision to revisit. Prefer the bare name regardless: it
+survives those user-scope installs eventually being converted, and the namespaced form still
+resolves for anyone installing holocron natively, so skill bodies written for both audiences
+should name the bare skill.
+
+**Correction (2026-08-17): the evidence under the correction above is gone, and the claim goes with
+it — not to its opposite.** Observed on this machine: `~/.claude/plugins/installed_plugins.json` is
+`{"version": 2, "plugins": {}}`; there is no `enabledPlugins` key anywhere in `~/.claude.json`
+(`grep -c enabledPlugins` returns 0); `~/.apm/marketplaces.json` is `{"marketplaces": []}`. The
+`holocron` entry in `~/.claude/plugins/known_marketplaces.json` survives, but a registered
+marketplace is not an installed plugin. So the user-scope installs the 2026-08-14 correction cited
+are not there, and neither is the state the *original* consequence described before it. The claim
+about the namespaced form has now been written twice off two different observations of the same
+machine, and this ADR has already reversed itself once on it. That is the finding: the fact is
+machine state, not a property of this decision, and it changes without any commit. No instruction
+file — `AGENTS.md`, `CONTEXT.md`, or a skill body — should assert either way whether
+`<plugin>:<skill>` resolves. The rule that survives every observation is the one that was always the
+actionable half: write the bare name, because it is the only form `apm install` produces.
+
+**apm owns `.claude/settings.json`.** (ADR-0019 supersedes the "exactly `{"hooks": {}}`" claim
+below — once a package ships a hook, apm merges it into that file and the merged entry is apm's own
+output. The rule that nothing repo-authored goes in the file is unchanged.) `apm audit --ci` replays the install into a scratch tree and
+diffs it against the worktree. apm's hook integrator writes that file, so the replay expects
+exactly what apm would have written — `{"hooks": {}}` — and any repo-owned key in it is permanent
+drift that fails the `apm-audit-ci` pre-push hook. Verified both directions: with the pre-existing
+`enabledPlugins` block present, `1 of 10 check(s) failed`; reduced to `{"hooks": {}}`,
+`All 10 check(s) passed`. Nothing was lost in that reduction — `enabledPlugins` was empty after the
+native uninstall and the only `hooks` entry was an empty `PreToolUse: []` — but it does mean the
+file is no longer available for repo-owned settings. Machine-specific settings go in the gitignored
+`.claude/settings.local.json`, which apm does not deploy; shared enforcement belongs in
+`.pre-commit-config.yaml`, where this repo already keeps it.
+
+**`apm_modules/` breaks naive tree walks.** apm materializes a full copy of every dependency there
+— including this repo's own plugins, `.bats` files and all. The dependency copies resolve their
+bats helpers relative to their own root, not this repo's, so `tests/run-tests.sh` went from 167
+tests passing to `334 tests, 167 failures` on the first install. Both discovery walks
+(`tests/run-bats.sh`, `tests/run-tests.sh`) now exclude `apm_modules/`, on the find side and on the
+`git ls-files` side that derives the expected set. Any future script that walks the repo tree needs
+the same exclusion.
+
+**Install output is gitignored; the lockfile is not.** `.claude/skills/`, `.claude/agents/`, and
+`apm_modules/` are regenerated by `apm install`. Committing the deployed skills would add a third
+mirror of content ADR-0017 already governs two copies of. `apm.lock.yaml` is committed — it is what
+makes the install reproducible, and `apm audit --ci` checks it.
+
+**MCP survived the switch; hooks were never at risk.** apm read `plugins/bin/.mcp.json` as a
+self-defined direct-dependency MCP server and configured `obsidian` into the repo's `.mcp.json`
+unprompted. The `gitea` and `context7` servers were never plugin-provided — they live in
+`~/.claude.json` and are untouched. Every plugin's `.apm/hooks/hooks.json` is `{"hooks": {}}`, so
+apm's "contributed no entries to claude settings; skipped" warning on `kyberforge` and `lint` is
+accurate and harmless.
+
+**A `.apm/` edit now needs a round trip.** The dependency resolves from the remote, so an edit is
+invisible to the running session until it is pushed and the install is refreshed. Under the native
+install with `autoUpdate` the shape was the same; it was more noticeable here at first because the
+refresh is a manual step where marketplace auto-update was not — ADR-0019 automates it at
+`SessionStart`.
+
+**Correction (2026-08-14): the refresh command is `apm update`, not `apm install`.** An earlier
+revision of this paragraph named `apm install`, which is wrong: `apm install` deploys from the
+pinned `resolved_commit` in `apm.lock.yaml` and does not re-resolve refs (`apm install --force`
+documents this explicitly — "does NOT refresh refs; use 'apm update' for that"). Running it after a
+merge redeploys the same content and reports success.
+
+**User scope is untouched, deliberately.** This decision changed project scope only; whatever is
+natively installed at user scope was left alone, and converting it is a separate decision with a
+blast radius beyond this repo. The specific inventory this paragraph used to name
+(`bin@holocron`, `gitea@holocron`, a stale `hello-world@holocron`) is machine state and is stale —
+see the 2026-08-17 correction above. The decision recorded here is unaffected by what that state is.
+
+## Alternatives considered
+
+- **`apm install --global`.** Verified working in an isolated `HOME`: user-scope deploys land in
+  `~/.claude/skills/` and `~/.claude/agents/`, and it is the only scope where a plugin's `bin/`
+  executables deploy (moot here — every `bin/` in this repo is empty but for a README). Deferred,
+  not rejected: it changes skill resolution for every project on the machine at once.
+- **Keeping both install paths.** Rejected: the same skill would be present twice under two names,
+  and `.claude/settings.json` cannot hold `enabledPlugins` without failing `apm audit --ci`.

docs/adr/0019-session-start-hook-keeps-the-apm-install-current.md

@@ -0,0 +1,167 @@
+# A SessionStart hook keeps the apm install current, replacing a git hook that never ran
+
+ADR-0018 switched this repo to consuming its own plugins through `apm install`, with the six
+packages declared as unpinned git refs against the holocron remote's default branch. That decision
+left a hole it named but did not fill: the deployed content goes stale the moment anyone merges,
+and nothing detects it.
+
+**Status: accepted (2026-08-14).**
+
+## Context
+
+The pre-existing answer was `scripts/git-hooks/post-push`, which pulled the marketplace clone and
+ran `claude plugin update kyberforge`. Issue #78 filed it as a bug — the hook updated `kyberforge`
+but not `gitea`, so gitea skills stayed pinned at a pre-refactor version after #67 merged.
+
+The issue's premise was wrong in a way nobody had noticed for six weeks. **Git has no client-side
+`post-push` hook.** `githooks(5)` does not list one, and git 2.39.5 does not invoke one.
+`scripts/install.sh` copies every file in `scripts/git-hooks/` into `.git/hooks/`, so
+`.git/hooks/post-push` existed on disk and looked installed. It had never fired. The hook did not
+skip `gitea`; it skipped everything. Both tests that appeared to cover it — `test-post-push.sh` and
+`test-git-hooks-install.sh` — asserted only that the script behaved correctly when invoked directly
+and that install.sh copied the file. Neither asserted that git ever runs it.
+
+That also makes the original framing wrong. Refreshing on push assumes the person who pushes is the
+person who goes stale, which is backwards: your install goes stale when *someone else* merges, and a
+push of your own is neither necessary nor sufficient for it to have happened.
+
+## Decision
+
+A `SessionStart` hook, shipped in `plugins/kyberforge/.apm/hooks/`, checks whether the install is
+behind and refreshes it in place.
+
+`SessionStart` is the correct trigger because the thing that goes stale is the skill content a
+*session* loads, and that is the moment the staleness does damage. It also enables two things a git
+hook structurally cannot do: `additionalContext` puts the notice into the agent's context rather
+than terminal scrollback nobody reads, and `reloadSkills: true` makes the host re-scan the skill
+directories after the hook returns, so a refresh lands in the running session without a restart.
+
+apm's own lifecycle events (`pre-/post-install`, `pre-/post-update`, `pre-/post-uninstall`) were
+rejected: they fire around apm operations already chosen, so they can announce a refresh but never
+detect that one is needed.
+
+Three sub-decisions:
+
+- **Refresh automatically rather than report.** The hook runs `apm update --yes` and asks for a skill
+  reload. The rejected alternative was to report and let a human run it. Auto-refresh costs a
+  rewritten `apm.lock.yaml` — a committed file — appearing as an unexplained modification in the
+  working tree, on any branch, at any time. The emitted notice says so explicitly for that reason.
+- **`plugins/kyberforge/.apm/hooks/`, not `.claude/settings.json`.** ADR-0018 established that apm
+  owns `.claude/settings.json` and that any repo-authored key in it is permanent `apm audit --ci`
+  drift. A hook shipped in a package is written into that file by apm itself, so it is apm's output
+  and does not drift. `.claude/settings.local.json` also works but is gitignored and machine-local,
+  which fails the requirement that this travel with the repo.
+- **`startup` matcher only.** `resume`, `clear`, `compact` and `fork` would re-run the check on every
+  compaction, and a compaction is not an event after which the remote can have moved.
+
+The executable-trust gate is switched on at the same time. Root `apm.yml` gains an `executables:`
+block allowing kyberforge's hooks and bin.
+
+## Consequences
+
+**The gate is off until something turns it on, and this repo had it off.** `apm approve --list`
+reports `Executable-trust gate disabled -- all executables deploy` until an `executables:` block
+exists in `apm.yml`. Any hook, bin, or MCP primitive a dependency shipped would have deployed with
+no prompt and no record. The block added here closes that for this repo; every other apm project on
+this machine still has it open.
+
+**The allow key is version-pinned, and that is a live failure mode.** apm writes
+`kyberforge#1.5.0`, not `kyberforge` — and the release that ships this hook proved the point
+immediately, since bumping kyberforge to 1.5.0 required editing the key in the same commit. A
+kyberforge version bump makes the entry stop matching, the
+gate blocks the hook, and the install silently stops refreshing — the exact failure this ADR exists
+to end, reintroduced through the mechanism meant to secure it.
+
+Matching is an exact dictionary lookup on the composed `name#version` string
+(`apm_cli/security/executables.py`, `is_package_approved`), so there is no wildcard or
+version-less key that would sidestep this — the key has to be edited on every bump, and the
+question is only what catches a missed edit. A comment in the `executables:` block is not enough:
+this repo gates generated-content drift, marketplace mirror drift and vale style drift
+deterministically, and a silent-staleness failure is strictly worse than any of them. So
+`scripts/check-executables-allow-sync.sh` runs at pre-push, parsing `version:` out of
+`plugins/kyberforge/apm.yml` and asserting root `apm.yml` carries the matching
+`kyberforge#<version>` key. The comment stays as the human-facing pointer; the hook is what
+actually holds. It parses with PyYAML where importable and falls back to a two-shape scan
+otherwise, so a missing pip package cannot become the thing that blocks every push.
+
+**Trust is keyed on the version, not on the content.** `kyberforge#1.5.0` approves whatever
+`check-apm-current.sh` contains at the moment it is fetched, not the bytes that were reviewed when
+the key was written. Because the dependency is unpinned against the default branch and the hook
+runs `apm update --yes` unattended, an edit to that script landing on `main` deploys and executes
+on every contributor's machine at their next session start, with no second approval prompt and no
+diff shown. The trust gate constrains *which package* may ship an executable; it does not constrain
+what that executable does between version bumps. That is an accepted property of this design rather
+than an oversight — the remote is self-hosted, push access to `main` is already sufficient to
+change any skill body an agent will follow — but it is the reason the gate should not be read as a
+supply-chain control. Pinning each dependency to a `ref:` is what would make it one, and ADR-0018
+defers that until per-package release tags exist.
+
+**A referenced hook script must be addressed at its `.apm/` path.** apm resolves
+`${CLAUDE_PLUGIN_ROOT}/...` against the installed package root, and `apm pack` keeps only `*.json`
+from `.apm/hooks/` when it builds the flat mirror. So `${CLAUDE_PLUGIN_ROOT}/hooks/check-apm-current.sh`
+resolves to the mirror, where the script does not exist — verified, apm reports
+`Hook script not found` and deploys a hook pointing at nothing. The working reference is
+`${CLAUDE_PLUGIN_ROOT}/.apm/hooks/check-apm-current.sh`. The script cannot simply be placed in
+`plugins/kyberforge/hooks/` either: that directory is `rm -rf`'d by every content sync (ADR-0017).
+A test pins the reference.
+
+**Session startup gets slower when the install is stale.** Measured: ~0.7 s for the `apm outdated`
+check when everything is current, ~10.4 s when six packages are behind and the refresh runs. The
+hook declares `timeout: 380` to cover a cold multi-package fetch. That number is not free-standing:
+the script imposes its own `timeout 60` on `apm outdated` and `timeout 300` on `apm update`, so the
+host-side timeout has to exceed their sum or the host kills the hook mid-update and leaves
+`.claude/skills/` half-deployed with no notice emitted. An earlier revision declared `320`, which
+was below the 360 s the script can legitimately take. A test asserts the invariant rather than the
+literal — it parses every `timeout N` out of the script, sums them, and requires the `hooks.json`
+value to be larger — so changing either side without the other fails the suite.
+
+**Reading a human-readable CLI for a control decision cost a silent failure, again.** `apm outdated`
+has no `--json` or other machine-readable flag (confirmed against 0.28.0), so the hook must match
+its prose. The first attempt matched `outdated dependencies found` — plural only. apm emits
+`1 outdated dependency found` in the singular when exactly one package is behind
+(`apm_cli/commands/outdated.py`), so a single stale package was invisible: the hook exited 0
+silently and no refresh ran. With six packages merging independently, one-behind is the ordinary
+case rather than an edge, which means the mechanism failed most often in exactly the situation it
+exists for. The match is now `outdated dependenc(y|ies) found`.
+
+The deeper lesson is the one `post-push` already taught and this repeated: every assertion about the
+hook mocked `apm`, so the suite was green while the hook could not detect the common case. Mocks
+verify the code against its author's belief about the interface, never the interface. The suite now
+carries one probe that stages a genuinely outdated dependency against a local git remote — offline,
+via `url.<path>.insteadOf`, so the twelve-hooks-pass-under-`unshare -rn` property survives — runs
+the real `apm outdated`, and replays its genuine output through the real hook. Reverting the grep
+to plural-only fails it.
+
+**The hook cannot install itself.** Dependencies resolve from the remote, so the hook does not
+deploy until this change is merged and `apm update` has run once against the new default branch.
+Until then the repo has the mechanism in source and not in effect.
+
+**`.claude/settings.json` stops being `{"hooks": {}}`.** apm merges the hook into it and tracks
+ownership in a `.claude/apm-hooks.json` sidecar, with the script copied to
+`.claude/hooks/<pkg>/`. The sidecar and the script directory are gitignored install output; the
+settings file remains committed, now with apm-generated content in it. ADR-0018's statement that the
+committed content is exactly `{"hooks": {}}` is superseded on that point only — the rule it was
+protecting, that nothing repo-authored goes in that file, is unchanged.
+
+**Native consumers are protected by a guard, not by the gate.** A host installing holocron through
+`claude plugin install` auto-discovers `hooks/hooks.json` and does not consult apm's trust gate at
+all. The script therefore exits silently when there is no `apm.lock.yaml` in the working directory,
+which is what makes it inert in a repo that does not consume packages through apm. Copilot CLI sees
+no hook at all, for the reasons already documented in `plugins/kyberforge/docs/hooks.md`.
+
+**`scripts/git-hooks/` is now empty.** `post-push` and `test-post-push.sh` are deleted.
+`install.sh`'s copy block is generic and is kept; `test-git-hooks-install.sh` now synthesizes its
+own fixture hook instead of depending on a real one existing, so the mechanism stays tested and can
+be used again if a hook git actually invokes is ever wanted.
+
+## Alternatives considered
+
+- **A `post-merge` git hook.** Real, unlike `post-push`, and verified to fire on both a
+  fast-forward `git pull` and a `git pull --rebase`. Rejected as the primary mechanism because a
+  pull is the wrong signal, and because it cannot reload skills in a running session. It remains
+  the only option for a project that consumes apm packages without a Claude-family host.
+- **Reporting instead of refreshing.** See the sub-decision above.
+- **A seventh plugin holding only this hook**, to avoid shipping it to external kyberforge
+  consumers. Rejected as disproportionate: the `apm.lock.yaml` guard already makes the hook inert
+  for anyone not consuming through apm, and a package exists to be maintained, versioned, and
+  registered in the marketplace.

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

@@ -0,0 +1,419 @@
+# Skills and agents are authored against a context budget, not a spec ceiling
+
+Every installed skill's `name` and `description` sits in every agent's context from the first token
+of every session, whether or not the skill is ever invoked. Across this repo's 39 skills that is
+23,427 characters — roughly 5,900 tokens — and the authoring rules that produced it optimised for
+triggering reliability with no counter-pressure on size. This ADR sets the budget, the shape, and the
+gates that hold them.
+
+**Status: accepted (2026-08-14).**
+
+## Context
+
+Every `file:line` citation in this ADR is against the base commit the decision was taken on,
+`f9b919d7e3bd5e6b51fbdf88b32ace0438b313e0`, not against current `HEAD`. The change that carries this
+ADR rewrites several of the cited files, so a citation resolved against the worktree will land on
+unrelated text. Use `git show f9b919d:<path>` to follow one.
+
+Measured before any change, at that commit. Method, so the figures are reproducible: sum
+`len(name) + len(description)` over the frontmatter of every `plugins/*/.apm/skills/*/SKILL.md`,
+folding `>` block scalars to the value the host actually loads (most descriptions here are folded
+scalars, so counting raw lines measures indentation instead); tokens at the standard
+~4-characters-per-token approximation `scripts/skill-size-check.sh` uses. Word counts are
+whitespace-separated tokens, and are stated as **body-only** or **whole-file** every time, never bare.
+
+| | |
+|---|---|
+| 39 skill `name` + `description` | 23,427 chars, ~5,900 tokens, **preloaded every session** |
+| 4 agent `name` + `description` | 1,325 chars, ~330 tokens, preloaded every session |
+| skill bodies (body-only words) | median 684, mean 815, p90 1,349 |
+| skill files (whole-file words) | median 816, mean 927, p90 1,526 |
+| `MAX_WORDS` gate (`skill-audit/scripts/validate.sh:147`) | **2,770** whole-file — a density proxy, not a percentile |
+
+That last row is worth stating plainly, because it is the first thing this ADR is about. 2,770 is not
+derived from the corpus distribution at all: per the derivation comment in
+`scripts/skill-size-check.sh`, it is 2,770 words at the densest observed 7.22 chars/word ≈ 20,000
+chars ≈ the agentskills.io ~5,000-token ceiling. Neither percentile reaches it — 2× the body-only p90
+is 2,698 and 2× the whole-file p90 is 3,052 — and reading it as "2× p90" would pair a whole-file gate
+against a body-only distribution, which is exactly the conflation this ADR exists to stop.
+
+Three findings drove this, none of which is "the descriptions drifted".
+
+**The rules mandate the bloat.** `skill-author/SKILL.md:104` requires indirect triggers ("even if the
+user doesn't mention X explicitly") and `skill-audit/references/description-quality.md:21` requires
+authors to "err toward being pushy". Both are enforced. The one rule that would delete the waste —
+`skill-author/SKILL.md:102`, "not the skill's internal mechanics" — is judgment-only and is absent
+from the FAIL conditions at `description-quality.md:45-50`. The enforced rules inflate; the deflating
+rule does not bite. The result is measurable: `gitea-files` spends 147 chars listing six verbs, then
+301 chars re-quoting the same six as user phrasings, in the same order. `apm-workflow` does the same
+with six capability clusters. Across the twelve longest descriptions, 30.7% is capability
+enumeration and 11.6% is composition or implementation detail that cannot affect a routing decision.
+
+**Capability enumeration in a description is a correctness hazard, not only a token cost.**
+`plugins/kyberforge/docs/research/examples/skill-write/writing-skills/SKILL.md:154-158` reports a
+measured failure: "when
+a description summarizes the skill's workflow, an agent may follow the description instead of reading
+the full skill content. A description saying 'code review between tasks' caused an agent to do ONE
+review, even though the skill's flowchart clearly showed TWO reviews." `git-commits` is exactly that
+shape — 74% of its description is capability enumeration, including a rules table (`header max 100
+chars, lowercase subject, no trailing periods, 11 standard types`) an agent can act on without ever
+loading the body.
+
+**The upstream sources cannot settle this.** The four skill-writing references under
+`plugins/kyberforge/docs/research/examples/skill-write/` disagree on what a description contains —
+when-only (`writing-skills/SKILL.md:99`), what-and-when (`skill-creator/SKILL.md:67`,
+`writing-skills/anthropic-best-practices.md:187`), triggers-only
+(`writing-great-skills/SKILL.md:28`), and what-plus-when-plus-negative
+(`write-skill/SKILL-TEMPLATE.md:5-6`). Those four paths are relative to that directory.
+`writing-skills` and the Anthropic document it bundles contradict each other inside one skill
+directory. They also disagree on whether
+500 lines is binding, on the inline-versus-bundle threshold, and on the TOC threshold (>100 lines vs
+>300 lines). "Grounded in the research" is therefore not available as a tiebreaker; a house choice is
+required and this is it.
+
+A fourth observation shaped the body half. The best progressive-disclosure ratio in the repo belongs
+to `apm-workflow` — a 421-word body dispatching to 3,006 words of references — and the worst two
+belong to the skills that define the house standard: `skill-author` (2,623-word body / 1,247 words of
+references) and `agent-author` (2,582 / 1,664). Measured the other way, whole-file, those two are
+2,760 and 2,758 words — ten and twelve words under the 2,770 gate their own plugin enforces. A
+ceiling that nothing approaches is not a constraint; a ceiling that two files have grown into is a
+target. The two numbers for one file are the point: 2,623 and 2,760 describe the same `skill-author`,
+and only one of them is what either gate measures.
+
+## Decision
+
+### Descriptions
+
+A description carries three things and nothing else: a **trigger clause**, at most one **capability
+clause**, and a **boundary clause**. Capability enumeration, output-format detail, composition notes
+("composes X rather than duplicating Y"), and implementation detail move to the body or to
+`README.md`.
+
+- **250 characters SUGGESTION, 400 FAIL.** The agentskills.io 1,024-character limit remains as an
+  unchanged spec backstop. The SUGGESTION tier is what moves the average; the FAIL tier only stops
+  outliers.
+- **A missing, valueless or `null` `description:` is a hard FAIL** in all three validators. That
+  reads as a trivial precondition and is not: a `description:` line with no value followed by
+  `model: sonnet` let a line regex capture the *next* key, which looked non-empty, so the "missing or
+  empty" branch never fired and every gate below it then early-returned on the genuinely empty folded
+  value — exit 0, zero output, on a blocking pre-push gate. Presence is decided on the YAML-folded
+  value and nowhere else. The field this contract is entirely about is the one field a gate must
+  never fail to notice is absent.
+- **Boundary clauses compress** to `Not <thing> → <skill-name>.` and must name a target that
+  resolves to a real skill or agent. Resolution walks up **from the file being checked** to an
+  *authoring root* — the nearest ancestor holding `plugins/*/.apm/skills` or `plugins/*/.apm/agents`,
+  falling back to the nearest ancestor holding `.git`. Two passes rather than one interleaved walk,
+  so a nested `.git` (a submodule, a sub-package worktree) cannot beat a real monorepo root further
+  up. When an authoring root is found the universe is every skill and agent under
+  `<root>/plugins/*/`, plus the target's own apm package and the packages that package declares in
+  its own `apm.yml` `dependencies.apm`. Sibling plugins resolve against each other, which is what a
+  monorepo means. Deployed `.claude/`/`.agents/` trees are consulted **only** when the walk found no
+  plugin monorepo root — whether it landed on a bare `.git` ancestor or on nothing at all. That is
+  the consumer case, where there is no monorepo to read. The condition is which of the two passes
+  matched, never a name-count delta: a single-plugin monorepo re-collects its own package and adds
+  no new name, so a delta test reads zero there and would pull the deployed trees back in. What the
+  resolver must never do is
+  derive the universe from its own location: a `${BASH_SOURCE}`-relative repo root leaked this repo's
+  39-skill universe into every consumer repo running the hook through pre-commit, so a consumer skill
+  routing to `skill-audit` resolved against a plugin it had never installed. Checked
+  deterministically. A description carrying **no** boundary clause at all is a SUGGESTION, for skills
+  and agents alike: most descriptions want one, some genuinely have no near-miss sibling to exclude,
+  and that judgment is not a script's to make.
+- **The verdict must not depend on whether `apm install` has been run.** Deployed trees are
+  gitignored install output, present only on a machine that has run it. Four cross-plugin targets
+  here (`gitea-branches` → `git-branches`, `gitea-branches` → `git-history`, `gitea-issues` →
+  `git-branches`, `gitea-workflow` → `git-workflow`) once resolved through `.claude/skills/` alone,
+  so the same commit measured 2 dangling targets on a developer machine and 6 on a fresh clone. A
+  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.
+- **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
+  vendor-neutral `.apm/` description routing to one is a portability defect and the hard FAIL is a
+  true positive, not a false one. An allowlist of known built-ins was **rejected**: it answers a
+  different question ("does this exist on *some* host?"), it cannot answer that portably from a
+  single source file, and it goes stale the next time a host ships a command — reintroducing the
+  same-commit-two-verdicts failure the bullet above exists to close. An author who needs to mention
+  one writes it un-slashed (``the `compact` built-in``), which is not route notation and makes no
+  routing claim.
+- **Blocking is scoped to a sentence, which makes sentence boundaries load-bearing.** A prose-form
+  target earns a hard error only when its own sentence names another target that *resolves*; route
+  notation (`/name`, `→ name`) is exempt and always blocks. So the splitter is part of the contract,
+  not a detail of it. `e.g. "…"` is not a sentence end, and a sentence opening with a code span or a
+  lowercase skill name is a start; getting either wrong moves targets between the two tiers in
+  opposite directions — a stranded corroborator silently demotes a real finding to SUGGESTION, and a
+  missed boundary lets one sentence vouch for a target it never stood beside, producing a hard FAIL
+  with no escape hatch.
+- **The blanket pushiness rules are deleted.** `skill-author/SKILL.md:104` and
+  `description-quality.md:21` are replaced by a conditional: add an indirect trigger only where the
+  user's natural phrasing genuinely omits the domain word — true for the `gitea-*` family, false for
+  `git-commits`. Stating the same trigger twice in two registers is a FAIL.
+
+### Bodies
+
+The body carries the **decision procedure only**: ordered steps, decision branches, gates, and which
+reference to load when. Lookup tables, spec restatements, output schemas, templates, and rationale
+prose move to `references/` behind an explicit "read X when Y" trigger.
+
+- **600 words SUGGESTION, 900 FAIL, counted body-only** — everything after the closing `---` of the
+  frontmatter. The 2,770-word / 500-line spec backstop is unchanged, keeps its existing meaning
+  (conformance, not quality), and keeps counting the **whole file including frontmatter**. These are
+  two different gates measuring two different things, and conflating them is what produced the
+  current state.
+- **Dispatch is mandatory at two or more mutually exclusive flows.** The body carries the dispatch
+  table and the gates that apply to every branch; each flow lives in its own self-contained
+  `references/` file. This is `apm-workflow/SKILL.md:33-41` promoted from accident to rule. "Two
+  mutually exclusive flows" is not decidable from file text, so this rule is auditor judgment — see
+  Enforcement below for what that means and does not mean.
+- **Every `references/<file>.md` a body names must exist.** A dispatch table pointing at a file that
+  was never written is a silently dead branch. Checked deterministically.
+- **Gotchas are constrained.** A Gotcha must state a fact that contradicts a reasonable default —
+  something the agent gets wrong by acting sensibly. More than five entries is a SUGGESTION, as is a
+  Gotchas section exceeding 25% of the body; both are countable and both are checked
+  deterministically. A Gotcha that paraphrases a step in the body below it is a FAIL, but a FAIL an
+  auditor issues, not a script — semantic equivalence is not pattern-matchable.
+
+### Agents
+
+Agents take the same description gates — they are preloaded identically — and **no body word gate**.
+A skill body is loaded into the caller's context, competing with the live conversation; an agent body
+becomes the system prompt of a fresh context. The rationale for the 900-word FAIL does not transfer.
+
+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
+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.
+
+A plugin-scope agent is a single file with no sibling `references/` directory, so it cannot disclose
+to itself — it can only delegate to skills. `agent-audit` therefore gains a **delegation check**: an
+agent body that restates a procedure owned by a skill it can invoke is a FAIL, with the fix being
+"invoke `<skill>` instead". Length falls out of delegation rather than being gated directly.
+
+### Invocation as a design axis
+
+`skill-author` asks whether a skill is model-invoked or hand-invoked before writing a description. A
+hand-invoked skill sets `disable-model-invocation: true` and carries one plain human-facing sentence
+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`.
+
+### Merging siblings
+
+Two skills that share substantial content, name each other as near-misses, and differ only in the
+type of input they take should be **one skill with a dispatch table**. This catches `skill-audit` +
+`agent-audit` and is scoped to them; the author pair is explicitly excluded, because
+`skill-author` and `agent-author` emit genuinely different artifacts (a skill directory versus a
+one-or-two-file agent pair, per ADR-0005 and ADR-0016) and their overlap is in the improve flow
+rather than the core job.
+
+**DEFERRED — not implemented in the change that carries this ADR. Tracked as issue #101.** Both
+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
+and dated instead of discovered later.
+
+### Enforcement and rollout
+
+Gates land where the existing gates already live — no new layer. The table below is exhaustive about
+which tier each rule is in, because the failure this ADR is most exposed to is a rule filed under
+"Enforcement" that no validator implements:
+
+| 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` |
+| 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 |
+| 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 |
+| description opener, composition notes in a description | skills, agents | prose pattern | `plugins/kyberforge/.apm/skills/*/assets/vale/styles/Kyberforge/` |
+| a Gotcha paraphrasing a body step | skills | **auditor judgment** | `references/body-discipline.md` |
+| dispatch at two or more mutually exclusive flows | skills | **auditor judgment** | `references/body-discipline.md` |
+| delegation: an agent body restating a skill's procedure | agents | **auditor judgment** | `agent-audit` |
+| capability enumeration, restatement, trigger quality | skills, agents | **auditor judgment** | `references/description-quality.md` |
+
+The rows in bold are stated as FAILs in the Decision above and are FAILs an *auditor* issues. None of
+them is countable: "does this Gotcha paraphrase step 4", "are these two flows mutually exclusive" and
+"does this agent body restate what `git-commits` already owns" are semantic questions, and a script
+that guessed at them would be a worse gate than no gate, because it would be believed. They are not
+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.
+
+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`,
+`prototype` and `tdd` are all real skill names *and* ordinary English, so it must be written
+`` `forge` `` or `/forge` to be seen at all. Grammar then decides whether a recognised target may
+raise an error: one followed by an ordinary lowercase noun is a compound **modifier**, not a route
+("use pre-commit hooks instead of ad-hoc scripts", "invoke the pull-request template"), so it is
+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
+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
+merely contain the word, so `## Gotcha handling` and `## Why gotchas matter` are prose sections and
+are skipped; fenced code blocks are masked out of heading detection and entry counting, so a fenced
+example list is not mistaken for the section; and a `references/` pointer named on a line
+that also says the file is gone ("removed", "deprecated", "no longer") is read as a historical
+mention rather than a dead dispatch entry. Note the 25% fraction is deliberately *not* fence-masked
+on either side — fenced lines are real body words, and the fraction is measured against the whole
+body.
+
+**The deterministic tier blocks immediately, with no baseline file.**
+
+Three pre-existing contradictions are fixed in the same change, because they are the contract:
+
+- `skill-audit/SKILL.md:58` asks whether the description opens with an action verb ("Audits…",
+  "Reviews…"), while `:56` defers the same question to `Kyberforge.DescriptionOpener` and
+  `skill-author/SKILL.md:101` requires an imperative "Use when…" opener. The criterion is
+  unsatisfiable against the house's own skills, both of which open with "Use when".
+- `DescriptionOpener.yml` is anchored to `^This (skill|agent)\b`, which misses a plain `This …`
+  opener; it is widened here to `^This\b`. The anchor itself stays. Composition prose that sits
+  *mid*-description — `gitea-workflow`'s "This is the human-facing entry point…" at character 377,
+  `gitea-labels-milestones`'s "This is a cross-cutting shared skill…" at character 300 — was never in
+  the opener rule's scope and correctly is not: under `scope: text.frontmatter.description` the `^`
+  anchors to the start of the whole folded value, and un-anchoring to reach mid-description text was
+  measured at 5 hits and 5 false positives and rejected (`LESSONS.md`, 2026-08-14). The real gap is
+  that no rule covered that text at all, which a new token-list rule, `Kyberforge.CompositionNote`,
+  closes: 10 alerts across four `gitea-*` skills, 0 false positives.
+- `description-quality.md:45-50` has no FAIL condition for internal-mechanics content, which is why
+  `skill-author/SKILL.md:102` never bit.
+
+## Consequences
+
+**Editing any non-compliant skill now requires retrofitting it first.** At decision time, 30 of 39
+descriptions exceeded 400 characters and 13 of 39 bodies exceeded 900 words — the latter counted
+body-only, which is what the new gate measures; the pre-existing 2,770-word gate counts the whole
+file including frontmatter, and the two must not be conflated. The change that carries this ADR also
+retrofits kyberforge's own four author/audit skills, so the figures on landing are **26 and 9**.
+With the gate hot and no baseline, a one-line
+fix to `gitea-prs` cannot be committed until that skill meets the contract. This is deliberate — it
+guarantees convergence and avoids a half-state — but it means the retrofit is lazy and *mandatory*
+rather than deferred. Issue #99 tracks it and should be prioritised accordingly, and the risk it
+carries is the ordinary one for hot gates: a gate expensive enough to be inconvenient gets bypassed
+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.
+
+**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
+the 250-character SUGGESTION instead lands at 9,750, a 58% cut. The halving depends entirely on the
+250-character SUGGESTION tier being visible and respected. That tier works here in a way it does not
+elsewhere in this repo: `skill-audit` already reports `PASS (N suggestions)` as a first-class
+outcome. This is explicitly **not** the failure ADR-0013 records — Vale warnings are invisible
+because vale's exit code keys on `error` alone, but these gates live in `validate.sh` and
+`skill-audit`, where a SUGGESTION reaches the report. Realistic landing is somewhere in that 33-58%
+band, not a guaranteed 50%.
+
+**A word gate cannot detect the defect it is standing in for.** `git-commits` carries twelve Gotchas
+of which four restate steps in its own Workflow (`:32` ≡ step 9, `:33` ≡ step 9, `:36` ≡ step 2,
+`:31` ≡ the description). Its body is 1,102 words and its whole file 1,217, so it does fail the
+900-word body FAIL — but for its length, not for the restatement. The four duplicated Gotchas are 114
+words between them; delete every one and the file still fails, while a skill 250 words shorter with
+the identical defect passes clean. The two properties are uncorrelated, which is why the counts are a
+backstop to the dispatch rule and the Gotchas constraint — both of which are auditor judgment for the
+semantic half, per the Enforcement table — and not a substitute for them. Reading the word gate as
+the mechanism is the specific mistake this paragraph exists to prevent.
+
+**Some skills legitimately need more description budget than others.** A tiered limit keyed to
+sibling density was considered and rejected as too clever; the flat 250/400 pair means the `gitea-*`
+and `git-*` families — where every sibling shares a keyword and boundary clauses do real routing work
+— 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.
+
+- `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
+  kyberforge's own skills.
+- `agent-author` said "Do not use for read-only review — examine agent files manually", routing away
+  from `agent-audit`, the correct sibling. **Fixed here**, same way. Note this one was never
+  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.**
+- `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`.
+
+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.
+
+**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
+root-cause grouping rule in four copies, and the wholesale clone of the "Improving an existing X"
+flow all remain. Cache isolation makes them structurally unavoidable
+(`skill-audit/SKILL.md:95` forbids cross-skill references; `LESSONS.md:107` records why), so the
+options are a sync gate or continued drift. This is an input to issue #101, which carries both halves
+of the kyberforge duplication problem — the deferred audit-pair merge and this — not a solved
+problem.
+
+**Provenance frontmatter is explicitly out of scope.** `LESSONS.md:63` asserts that non-routing
+frontmatter (`source_keys`, `category`, `version`) is loaded at agent startup, which would make the
+7,352 characters of it across the corpus a third again on top of the description tax. Measured
+against a live session on this Claude Code version, it is not: the model-visible skill listing
+contains only `name` and `description`. That is host-observed rather than spec-guaranteed and says
+nothing about Copilot CLI, but it is sufficient to establish that cutting `source_keys` would break
+the ADR-0009 provenance machinery for no runtime gain. The metadata was added deliberately and stays.
+
+## Alternatives considered
+
+Upstream citations below are relative to
+`plugins/kyberforge/docs/research/examples/skill-write/`, as in Context above.
+
+- **Keep pushiness, raise the budget to ~500 chars.** Undertriggering is the worse failure mode — a
+  skill that never fires is worth nothing regardless of cost — and `skill-creator/SKILL.md:67`
+  explicitly recommends being "pushy" against an observed undertriggering tendency. Rejected because
+  that claim is an unmeasured assertion about an older model, and because the correctness hazard in
+  `writing-skills/SKILL.md:154-158` cuts the other way: a fat description is not merely expensive, it is a
+  shortcut agents take instead of reading the body. Would have landed a 35% cut.
+- **A trigger-eval loop to set lengths empirically.** `skill-creator/SKILL.md:337-404` specifies 20
+  queries per skill, 8-10 positive and 8-10 near-miss, with a 60/40 train/test split selecting on
+  test score. This is the rigorous answer and the repo has deliberately never built it. Rejected
+  because it blocks the context cut behind a substantial new subsystem.
+- **A repo-level aggregate preload budget** (≤12,000 chars across all skills, checked at pre-push).
+  The only option that measures the actual goal rather than a proxy. Rejected because it makes one
+  skill's edit fail on account of another skill's growth, and because it is meaningless for an
+  external consumer installing a subset of the plugins.
+- **500-word body FAIL, matching `writing-skills/SKILL.md:217-221`.** Best-grounded in upstream and
+  would align this repo with the tightest source. Rejected because it fails 28 of 39 skills body-only
+  (35 of 39 measured whole-file), and a blunt gate gets satisfied by deleting content rather than
+  relocating it.
+- **A shrinking baseline file** recording each non-compliant skill's current numbers, failing only on
+  growth. Would have made the retrofit a visible burn-down instead of a wall. Rejected in favour of
+  hot gates.
+- **A sync gate over the duplicated spans** instead of a merge rule — generalising
+  `scripts/check-vale-style-sync.sh` to cover shared prose so duplication persists but drift cannot.
+  Rejected for the audit pair in favour of merging, which removes the duplication rather than
+  policing it, and removes a mutually-excluding near-miss pair from the router at the same time. It
+  remains the only available answer for the author pair.
+- **Merging `skill-author` + `agent-author` as well**, taking kyberforge from seven skills to five.
+  Largest cut available. Rejected because it reopens ADR-0005, ADR-0008 and ADR-0016 together, and a
+  merged author skill would carry both the skill-directory scaffold and the dual-provider agent
+  scaffold behind one dispatch.
+- **Demoting Gotchas** to the end of the body or into `references/gotchas.md`, removing its
+  position-based exemption from the dispatch rule. Maximum saving on the largest body construct
+  (6,830 words, 21% of all body text). Rejected because a gotcha read after the mistake is worthless.

docs/adr/0021-plugin-descriptions-state-a-domain-boundary.md

@@ -0,0 +1,227 @@
+# A plugin's published description states its domain boundary and never enumerates its skills
+
+Three of this repo's six plugins publish a `description` that lists the skills they ship. That style
+has now failed three times in four days, the third time inside the correction for the second. It is
+enforced by nothing, it obliges a marketplace release on every skill addition, and it was never
+applied to the other three plugins. This ADR retires it: a published description says what the
+plugin is *for*, and the inventory lives where an inventory can be read off the tree.
+
+**Status: accepted (2026-08-17).**
+
+## Context
+
+A plugin's published description is one string authored twice — in `plugins/<name>/apm.yml` and in
+the matching `marketplace.packages[]` entry of the root `apm.yml` — and compiled into four generated
+files per plugin edit: the plugin's `.claude-plugin/plugin.json` and `.github/plugin/plugin.json`,
+plus the repo-wide `.claude-plugin/marketplace.json` and its `.github/plugin/marketplace.json`
+mirror. (`.agents/plugins/marketplace.json`, apm's codex profile, carries no per-package
+`description` or `version` at all and is unaffected.) It is the only text a consumer sees in a marketplace listing before
+installing. It is **not** a SKILL.md `description`: it is never preloaded into an agent's context and
+routes nothing at runtime. ADR-0020 governs that other artifact; this one governs this one. The
+overlap is a finding, not a scope: ADR-0020 established that capability enumeration in a description
+is "a correctness hazard, not only a token cost". The hazard at this layer is different — staleness
+in published metadata rather than an agent shortcutting the body — but the enumeration is the same
+construct and it fails the same way.
+
+Measured at `de84d1b`, the branch tip before this change. Each figure is reproducible from the tree:
+skill counts are `ls plugins/<name>/.apm/skills/ | wc -l`, description text is
+`plugins/<name>/apm.yml`.
+
+| Plugin | Style | Skills | Items enumerated | Skills named | Unnamed |
+|---|---|---|---|---|---|
+| `bin` | enumeration | 11 | 8 | 9 | `caveman`, `zoom-out` |
+| `git` | enumeration | 9 | 8 | 8 | `git-workflow` |
+| `gitea` | enumeration | 7 | 7 | 6 | `gitea-workflow` |
+| `core` | boundary | 3 | — | — | — |
+| `kyberforge` | boundary | 7 | — | — | — |
+| `lint` | boundary | 2 | — | — | — |
+
+Three failures, in order.
+
+**`bb9158d` (2026-08-14) — `core`'s description described `bin`.** The text it deleted read
+"Cross-cutting utility skills for everyday AI-assisted coding — triage, diagnosis, architecture
+review, and session navigation." All four items are real skills and not one of them is `core`'s:
+they are `bin`'s `triage`, `diagnose`, `improve-codebase-architecture` and `zoom-out`. `core` ships
+`agentsmd-author`, `agentsmd-audit` and `provider-adapter-author`, and the published description
+named none of them.
+
+This is the failure the whole style was later adopted against, and it is worth being exact about
+what it was, because the record has been read the other way twice since. It was **wrong content**,
+not an incomplete list. The description was a syntactically perfect, complete, four-item enumeration
+of a real skill set; it just belonged to a different plugin. Enumerating harder could not have caught
+it, and a gate that asked "does every enumerated item exist as a skill?" would have passed it — all
+four did exist. `bb9158d`'s own fix went the other direction: it replaced the enumeration with a
+domain boundary, and `core` has needed no correction since. The precedent set by that commit was
+therefore *boundary*, and the two commits below cite it while doing the opposite.
+
+**`65bac15` (2026-08-17) — `git` advertised `gitea`'s domain, `gitea` advertised a skill that does
+not exist.** `git` read "conventional commits, branch management, pull requests, and feature flow";
+pull requests reach the forge over HTTP and are `gitea`'s, which is the exact boundary
+`docs/spec/architecture.md` draws between the two plugins. `gitea` read "issues, pull requests,
+milestones, releases, and wikis"; `grep -ri wiki plugins/gitea/.apm/` returns nothing and no wiki
+skill has ever existed. Both were repaired by re-enumerating.
+
+**`de84d1b` (2026-08-17) — the re-enumeration was itself incomplete.** `bin`'s "A place for things to
+be binned" was replaced with an eight-item list over eleven skills; `caveman` and `zoom-out` are
+absent. `zoom-out` is the same skill `bb9158d` had called "session navigation" three days earlier
+while deleting it from the wrong plugin's description — named when it was in the wrong place,
+unnamed once it was in the right one. And the miss is not confined to `bin`: `git-workflow` is
+unnamed in `git`'s corrected description, though `65bac15`'s own commit message states it was added
+("omitting pc-author/pc-run, git-submodules and git-workflow"), and `gitea-workflow` is unnamed in
+`gitea`'s. Across the three plugins, 23 of 27 skills are named at the third attempt.
+
+**Nothing checks any of this.** `scripts/check-manifests.sh` does not contain the string
+`description`. The three ADR-0020 validators (`scripts/skill-size-check.sh` and skill-audit's and
+agent-audit's `validate.sh`) gate on SKILL.md and agent frontmatter; they do open `apm.yml`, but only
+to read `dependencies.apm` when resolving the boundary-target universe — none of them reads the
+`description:` key, and their hook globs match `SKILL.md` and `*.agent.md` only. `apm audit --ci`,
+`apm pack --check-clean` and `scripts/sync-plugin-content.sh --check --all` all compare compiled
+output against `apm.yml`, so their entire job is to propagate whatever the description says into
+those four files byte-for-byte and confirm they match. The `wiki` claim passed every one of the fourteen pre-push hooks, every day it
+was published.
+
+**And the obligation is unbounded.** Under enumeration, adding one skill to `bin`, `git` or `gitea`
+means editing two copies of a prose string on top of the version bumps and regeneration any skill
+addition already owes under this repo's release policy
+(`plugins/kyberforge/.apm/skills/apm-workflow/references/marketplace.md`). The bumps are not the
+marginal cost — the prose edit is, and it is the half nothing checks. A skill *rename* triggers the
+same, for a string no consumer can tell went stale. 27 of the repo's 39 skills sat behind
+a description carrying that obligation; the other 12 did not, and their three plugins have generated
+no defect of this class.
+
+### Scope
+
+This decision covers the six plugins this repo authors. The root marketplace also lists
+`mattpocock-skills`, a third-party package whose description is not this repo's to write; its entry
+is out of scope and is left as published upstream.
+
+## Decision
+
+**A plugin's published `description` states the plugin's domain boundary. It does not enumerate the
+skills the plugin ships, by name or by paraphrase.**
+
+- The boundary answers "what kind of work belongs to this plugin, and where is its edge against its
+  nearest sibling" — the question a consumer deciding whether to install is actually asking. It is
+  stable under skill addition, rename and removal, which is the entire point: an artifact that does
+  not change when the tree changes cannot go stale against it.
+- **The boundary must cover everything the plugin actually ships.** A boundary drawn narrower than
+  the contents is the same defect as an incomplete enumeration, one level up, and it is the specific
+  risk in this change. `git` carries `pc-author` and `pc-run`, which are not git operations at all;
+  "Skills for working with Git" silently drops them, so the boundary names the pre-commit hooks
+  explicitly rather than trusting a reader to file them under Git.
+- The two copies — package `apm.yml` and the root `marketplace.packages[]` entry — stay identical.
+  This is already the rule in practice and both prior corrections state why: the root entry is what
+  reaches the compiled marketplace, so fixing only the package manifest leaves it half-propagated.
+- The three descriptions, rewritten here, with `core`/`kyberforge`/`lint` shown for register:
+
+  | Plugin | Published description | Chars |
+  |---|---|---|
+  | `bin` | 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. | 152 |
+  | `git` | Skills and agents for working with a local Git clone over the git wire protocol, and for authoring and running the pre-commit hooks that guard it. | 146 |
+  | `gitea` | 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. | 134 |
+  | `core` | *(unchanged)* Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it. | 101 |
+  | `kyberforge` | *(unchanged)* Skills and agents for creating, maintaining, and managing a Claude Code / Copilot CLI plugin marketplace. | 105 |
+  | `lint` | *(unchanged)* Skills and agents for configuring and running linters. | 54 |
+
+- **No gate is added.** This is a deliberate omission and the reasoning is below, not an item left
+  for later.
+
+### Why no gate
+
+The check enumeration would need — "every skill directory appears in the description" — was writable
+in principle and was never written, including by the two commits that corrected an enumeration by
+enumerating again and had every reason to. It is also only half a check: it
+catches a skill missing from the list, and it cannot catch `wiki`, because "this noun does not name
+any skill" requires a vocabulary of permissible non-skill nouns that no one is going to maintain.
+Under a boundary there is no correspondence left to check, which is the property being bought.
+
+What survives un-gated is `bb9158d`'s actual failure: a boundary that is simply wrong about its
+plugin. That was never machine-checkable in either style — the text was a well-formed description of
+a real plugin — and it is caught by the same review that has to happen when a published,
+consumer-facing string is edited at all. A gate that would catch it needs a declared per-plugin
+skill-to-boundary mapping for the description to be checked against, which is a second artifact
+requiring exactly the per-skill maintenance this ADR exists to delete, relocated one file over.
+
+Two cheap partial gates were considered and rejected in the same breath. Forbidding a comma-separated
+run of three or more noun phrases is a prose heuristic that fires on `lint`'s perfectly good
+"configuring and running linters" class of sentence. Forbidding any string matching a skill directory
+name under `plugins/<name>/.apm/skills/` bans legitimate boundary vocabulary — `git-branches` exists,
+and a `git` boundary has every right to say "branches". Both would be believed, and both would be
+wrong, which ADR-0020 already records as worse than no gate.
+
+## Considered options
+
+**Keep enumeration and gate it.** The only option that makes the current style safe. Rejected on the
+three grounds above: the check is one-directional, it cannot see an invented capability, and it makes
+a marketplace release the consequence of adding a directory. It also hard-couples published consumer
+copy to internal directory names, so a skill rename becomes a version bump on the plugin and on the
+marketplace.
+
+**Enumerate consistently across all six plugins**, on the grounds that the real defect is the split
+style. Rejected: it takes an obligation that has produced three failures on three plugins and applies
+it to six. The measured outcome of the most recent attempt to enumerate carefully, with the defect
+fresh and two prior commits as precedent, is four skills unnamed.
+
+**Cap the description length**, mirroring ADR-0020's 250/400-character tiers, on the theory that a
+short description has no room to enumerate. Rejected because length does not measure correspondence:
+`gitea`'s failing description was 96 characters and asserted a skill that has never existed, while
+`bin`'s 176-character enumeration is under the same cap. All six descriptions here, before and after,
+sit inside ADR-0020's tiers; the tier would have been silent through all three failures.
+
+**Delete the description to a bare name.** Rejected: apm's Claude marketplace mapper emits
+`description` into `marketplace.json`, and it is the only prose a consumer sees before installing.
+
+**Point the description at the plugin's `README.md`.** Rejected: a marketplace listing renders a
+string, not a link — and the README's own plugin list carries the same enumeration with the same
+staleness, so this relocates the defect rather than fixing it.
+
+## Consequences
+
+**Three descriptions are rewritten and the compiled output regenerated.** Eight generated files
+change: `plugins/{bin,git,gitea}/.claude-plugin/plugin.json`,
+`plugins/{bin,git,gitea}/.github/plugin/plugin.json`, `.claude-plugin/marketplace.json` and its
+byte-identical `.github/plugin/marketplace.json` mirror. `.agents/plugins/marketplace.json` (the
+codex profile) is unchanged and correctly so — it carries no per-package `description` or `version`
+field at all, only `name`, `source`, `policy` and `category`.
+
+**Version bumps, all PATCH under the `per_package` strategy:** `bin` 1.1.4 → 1.1.5, `git` 1.3.4 →
+1.3.5, `gitea` 1.3.5 → 1.3.6, `marketplace.version` 0.4.4 → 0.4.5.
+
+**The root `apm.yml` top-level `version:` is restored to lockstep with `marketplace.version`,
+0.4.2 → 0.4.5.** These two fields have moved together in every commit that has ever touched root
+`apm.yml` — 0.3.2, 0.3.3, 0.3.4, 0.4.0, 0.4.1, 0.4.2 in both — until `65bac15` and
+`de84d1b` on this branch bumped `marketplace.version` to 0.4.3 and then 0.4.4 while leaving the
+top-level field at 0.4.2. Lockstep is not folklore: it is stated at
+`plugins/kyberforge/.apm/skills/apm-workflow/references/marketplace.md`. This is a defect, not a
+style: `apm.yml`'s comment inside the marketplace block records that the top-level `version:` is not inherited into the compiled output
+"despite being used elsewhere (e.g. by `apm audit`)", so the field is live and was silently two
+releases behind what the marketplace published. Closed here rather than tracked, because the
+correction is one line and the drift is three days old.
+
+**`docs/spec/architecture.md`'s plugin table is unchanged and stays a routing table.** It answers
+"where does a new skill go" for someone working *inside* this repo; the published description answers
+"should I install this" for someone outside it. The two now read similarly, and that is not
+duplication to collapse — they have different readers and different lifecycles, and the table already
+says so in its own preamble ("These are routing boundaries, not inventories"). One caveat for whoever
+next edits that page: its closing sentence sends a reader to the published description "for what a
+consumer actually gets", which was true against an enumeration and is now a pointer to a second
+boundary statement. Neither artifact carries an inventory after this change, so that sentence was
+rewritten in the same branch to point at `plugins/<name>/.apm/skills/` and `README.md` instead.
+
+**`README.md`'s plugin bullet list becomes the only place an inventory lives, and it still
+enumerates.** That is deliberate, but it makes the list load-bearing in a way it was not before, so
+its `bin`, `git` and `gitea` bullets were completed in the same branch to name every skill those
+plugins ship. This ADR does not otherwise extend to it: a README is a hand-read document where a
+list of what you get is the useful thing, it is not compiled into four files, and a stale line in it
+costs a reader a moment rather than misrepresenting a published package. The tradeoff that makes
+enumeration wrong in a marketplace manifest is precisely the one that makes it fine there.
+
+**Nothing in the ADR-0020 gate set changes.** Its character and word tiers, its Vale rules and its
+three validators all read `SKILL.md` and `*.agent.md` frontmatter; none of them opens an `apm.yml`.
+The two contracts are adjacent and independent, and a future author retrofitting a skill under
+issue #99 is not touched by this ADR.
+
+**The failure mode this leaves open is a wrong boundary, and it is un-gated by design.** If a fourth
+failure of this class occurs it will be a description that describes the wrong plugin — `bb9158d`'s
+shape, the one enumeration never addressed. That is the trigger to revisit, and the thing to build
+then is a declared skill-to-boundary mapping, not a return to enumeration.

docs/spec/architecture.md

@@ -19,32 +19,64 @@ project repo (local overrides)
 - **Executables** (`DEPLOY_EXECUTABLES`): `providers/claude-code/statusline-command.sh` → `~/.claude/statusline-command.sh` (with `+x`)
 - **Directories** (`DEPLOY_DIRS`): `core/` → `~/.claude/core/` (destination fully replaced on each deploy)
 
-Skills are **not** deployed by `install.sh`. They are distributed as plugins and installed separately via `claude plugin install <name>@holocron`.
+Skills are **not** deployed by `install.sh`. They are distributed as plugins and installed separately — in this repo by `apm install` against the `dependencies.apm` entries in the root `apm.yml`, which lands them in `.claude/skills/` and `.claude/agents/` (ADR-0018); elsewhere by `claude plugin install <name>@holocron`.
 
-`~/.claude/CLAUDE.md` is a thin adapter, not a content source. It imports `~/.agents/AGENTS.md` (always-on rules) and `governance.md` (always-on governance), then lists the content index. All always-on content lives in `AGENTS.md` files so other providers can import the same source without duplication.
+`~/.claude/CLAUDE.md` is a thin adapter, not a content source. It imports `~/.agents/AGENTS.md` (always-on rules) and `governance.md` (always-on governance) and carries nothing else — the content index of on-demand instruction files sits in `core/AGENTS.md`, deployed to `~/.agents/AGENTS.md` and imported by it. All always-on content lives in `AGENTS.md` files so other providers can import the same source without duplication.
 
 ## Plugin model
 
-Skills, agents, MCP servers, and hooks are distributed as self-contained plugin units under `plugins/`. Each plugin has a `plugin.json` manifest and is installed independently via `claude plugin install`.
+Skills, agents, MCP servers, and hooks are distributed as self-contained plugin units under `plugins/`, installed independently — via `apm install` here, or `claude plugin install <name>@holocron` for a host consuming the marketplace natively (ADR-0018). Self-contained is a hard constraint, not a description: a plugin is copied to a cache on install, so nothing inside it may reference a file outside its own directory. That is why the Vale styles are duplicated across two skills rather than shared (ADR-0014), and why ADR-0020's constants are copied into three validators rather than sourced from one. Each plugin is an **apm package**: `plugins/<name>/apm.yml` plus a hand-authored `plugins/<name>/.apm/{skills,agents,hooks,commands,instructions,extensions}/` tree (ADR-0015). There is no hand-maintained `plugin.json` — every manifest and every host-visible content directory is compiled from that source.
+
+Which plugin a new skill belongs in follows from what each one is scoped to. The boundary that matters most in practice is `core` vs `kyberforge`: `core` is the home for cross-cutting, repo-agnostic utility skills that a consumer would want against *their* repo, while `kyberforge` is meta-tooling for the holocron marketplace itself. A skill that authors a target repo's `AGENTS.md` is `core`; a skill that audits a `SKILL.md` against this marketplace's contract is `kyberforge`.
+
+The second boundary worth stating is `git` vs `gitea`, because both own things called branches and both touch pull requests: `git` is whatever works over the git wire protocol against a local clone, `gitea` is whatever goes through the forge's HTTP API. That is why `git-branches` and `gitea-branches` both exist and are not duplicates.
+
+These are routing boundaries, not inventories — they answer "where does a new skill go", so they deliberately do not enumerate what each plugin ships today. The plugin's published `description` in its `apm.yml` states the same boundary for a consumer deciding whether to install (ADR-0021); neither carries an inventory. For what a plugin ships today, read `plugins/<name>/.apm/skills/` or the plugin list in `README.md`.
+
+| Plugin | Scope |
+|---|---|
+| `core` | Authoring and auditing a repo's `AGENTS.md` and the provider adapter files that defer to it |
+| `git` | Git operations and git hook tooling — anything driven over the git wire protocol against a local clone, plus the pre-commit hooks that guard it |
+| `gitea` | Anything reached through the Gitea HTTP API rather than the git wire protocol — the forge's own objects |
+| `kyberforge` | Creating and maintaining a Claude Code / Copilot CLI plugin marketplace — this repo's own meta-tooling |
+| `lint` | Configuring and running linters against a target repo; repo-agnostic, first linter is Vale |
+| `bin` | Unsorted skills that have not earned a home yet |
+
+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.
+
+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/`.
 
 ## Governance layer
 
 `core/instructions/governance.md` is the always-on governance instruction file. Unlike the on-demand instruction files in the content index, governance.md is loaded into every Claude session via `@import` in `providers/claude-code/CLAUDE.md`. This is a technical guarantee, not a behavioural instruction — `@import` causes Claude Code to expand and load the file at launch, before any interaction begins.
 
+Those on-demand files are plain markdown — no frontmatter, no schema. The agent decides when to read each one from task context and the content index label alone. Frontmatter is deferred until there is evidence that agents are loading the wrong files in practice; it is a deliberate deferral, not an oversight to close.
+
 The governance layer has two phases:
 - **Phase 1** (complete): instruction and documentation layer — `governance.md` loaded via `@import`; `docs/ai-constitution.md` and `docs/wiki/HUMANS.md` as human-facing reference; `CONTEXT.md` extended with governance domain language.
 - **Phase 2** (planned): deterministic enforcement layer — pre-commit hooks, CI gates, secret scanning, licence scanning. Specified in `docs/research/governance_principles/CONTROLS.md`.
 
 ## AGENTS.md pattern
 
-This repo uses two `AGENTS.md` files as the provider-agnostic source of always-on rules (ADR-0012):
+This repo uses two `AGENTS.md` files as the provider-agnostic source of always-on rules (ADR-0003):
 
 - **Repo-level `AGENTS.md`** — instructions for agents working inside this repo (structure, key rules). Imported by repo `CLAUDE.md` via `@AGENTS.md`.
 - **Global `core/AGENTS.md`** — Communication and Behavior rules that apply across all projects. Deployed to `~/.agents/AGENTS.md`; imported by `~/.claude/CLAUDE.md` via `@~/.agents/AGENTS.md`.
 
 Both `CLAUDE.md` files are thin adapters: they import from their respective `AGENTS.md` and add only Claude Code-specific syntax (`@import`, content index paths). They carry no original always-on content.
 
-This repo also has a `CLAUDE.md` at its root — the Claude Code entry point for working in this repo. It imports `AGENTS.md` and `CONTEXT.md`, nothing more. This is distinct from `providers/claude-code/CLAUDE.md`, which is the global config deployed to `~/.claude/`.
+This repo also has a `CLAUDE.md` at its root — the Claude Code entry point for working in this repo. It imports `AGENTS.md` and nothing else; there is no `@CONTEXT.md` import. It is not import-only either: below the import sits a fenced `<!-- rtk-instructions v2 -->` … `<!-- /rtk-instructions -->` block carrying the RTK command-prefix convention, which is tool-specific content with no `AGENTS.md` source. This is distinct from `providers/claude-code/CLAUDE.md`, which is the global config deployed to `~/.claude/`.
+
+`CONTEXT.md` is therefore **not** always-loaded. `AGENTS.md` instructs agents to read it at session start, which is a behavioural instruction, not an `@import` guarantee — `LESSONS.md`'s 2026-05-17 entry proposed adding the import and it was never applied. Treat that entry as open work rather than a record of a landed change.
+
+## Reference conventions
+
+The stated convention is that files referencing other files declare those references explicitly: the referencing file carries the forward reference (the content index in `core/AGENTS.md`, `references:` in frontmatter), the referenced file carries a `when:` field describing when it is loaded, and divergence between the two signals staleness. It is aspirational, not a description of the repo today — no file under `core/instructions/` carries frontmatter at all, `when:` appears in exactly one of the 39 `SKILL.md` sources under `plugins/*/.apm/skills/`, and the reference scanner script meant to derive the reverse map ("what files reference this file?") does not exist; `docs/notes/skill-implementation-workflow.md` still lists it as unbuilt work. Treat it as intent for instruction files, skills, and workflow documents, not as a rule the repo enforces.
 
 ## Provider model
 
@@ -52,4 +84,4 @@ This repo also has a `CLAUDE.md` at its root — the Claude Code entry point for
 
 ## Architectural decisions
 
-Key hard-to-reverse decisions are recorded as ADRs in `docs/adr/`. See the index there for rationale on choices like the pull distribution model, copy-not-symlink coupling, and the two-tier CLAUDE.md structure.
+Key hard-to-reverse decisions are recorded as ADRs in `docs/adr/`. There is no index file — the directory holds numbered ADRs whose filenames state their decision, so `ls docs/adr/` is the index. Read a superseding ADR before the one it supersedes: ADR-0015 (apm as the authoring source of truth) supersedes ADR-0001 and moots ADR-0006, ADR-0017 corrects ADR-0015's host-discovery gap, and ADR-0019 supersedes one claim in ADR-0018 (that `.claude/settings.json`'s committed content is exactly `{"hooks": {}}`) while keeping the rule behind it. Entry points for the structure described on this page: ADR-0002 (two-tier CLAUDE.md), ADR-0003 (AGENTS.md as the provider-agnostic entry point), ADR-0015 and ADR-0017 (the two compilers behind the plugin roots).

docs/spec/gates.md

@@ -0,0 +1,689 @@
+# Enforcement gates
+
+Reference for this repo's pre-commit and pre-push hooks: what each one guards, what its numbers
+mean, and which shapes were tried and rejected. Read it when a gate fails, before changing anything
+in `.pre-commit-config.yaml`, or before "fixing" something that looks like an inconsistency — several
+of the oddities documented here are load-bearing and have already been re-litigated once.
+
+`AGENTS.md` carries only the operative rules an agent needs in the moment. The reasoning lives here.
+
+---
+
+## Running the gates
+
+| Command | Scope |
+|---|---|
+| `pre-commit run --all-files` | the commit-stage hooks |
+| `pre-commit run --hook-stage pre-push --all-files` | the push gate, one command — with one caveat below |
+| `pre-commit run skill-size-check --all-files` | just the ADR-0020 size/context gates |
+
+Install hooks via `pc-run`, wiring **all three stages**. This repo's `.pre-commit-config.yaml` has no
+`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,
+`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
+is the count of hooks this repo authors itself.
+
+**The caveat: one of those 14 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
+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.
+
+**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**
+
+| Hook | Guards |
+|---|---|
+| `check-plugin-content-sync` | each plugin's flat `skills/agents/commands/hooks` mirror matches `.apm/` (issue #90) |
+| `check-marketplace-mirror-sync` | `.github/plugin/marketplace.json` is byte-identical to `.claude-plugin/marketplace.json` — no apm output profile targets that path |
+| `check-vale-style-sync` | skill-audit's Vale copy matches agent-audit's canonical copy, plus six glob-coverage probes (see [Vale](#vale)) |
+| `check-scope-walkup-sync` | `validate.sh`, `validate-provenance.sh`, `new-agent.sh` and `new-skill.sh`'s four independent `$HOME`/`.git`/`apm.yml` walk-up ports still agree behaviorally |
+| `check-executables-allow-sync` | root `apm.yml`'s `executables.allow` key names kyberforge's actual version (see [apm gates](#apm-gates)) |
+
+`check-executables-allow-sync` is the odd one in this group: it guards a *silent failure* rather than
+drift in generated text.
+
+**Artifact validators**
+
+| Hook | Guards |
+|---|---|
+| `check-apm-agents-valid` | runs agent-audit's `validate.sh` over every real `plugins/*/.apm/agents/*.agent.md` (see [Agent files](#agent-files-take-the-description-gates-not-the-body-gate)) |
+
+**apm's own gates**
+
+| Hook | Guards |
+|---|---|
+| `apm-marketplace-check` | every `marketplace.packages[]` entry resolves, including network reachability of remote refs |
+| `apm-audit-ci` | `apm audit --ci` once per manifest — root plus each of the six plugin packages |
+| `apm-pack-check-clean` | `apm pack --check-versions --check-clean --dry-run` — the compiled marketplace still matches what `apm.yml` + `.apm/` would generate, and per-package versions agree with the `per_package` strategy |
+
+**Host validators** (both need the `claude` CLI on PATH)
+
+| Hook | Guards |
+|---|---|
+| `validate-plugins` | `claude plugin validate --strict` on every plugin directory |
+| `validate-marketplace` | `claude plugin validate --strict` on the root marketplace manifest |
+
+**Release**
+
+| Hook | Guards |
+|---|---|
+| `check-release-needed` | on a real `git push` to `main` only — fails if files exposed via `.pre-commit-hooks.yaml` changed since the last tag. A no-op everywhere else, including under `pre-commit run --hook-stage pre-push` (see [the caveat above](#running-the-gates)) |
+
+Four of these shell out to `apm`: `apm-marketplace-check`, `apm-audit-ci`, `apm-pack-check-clean`,
+and `check-plugin-content-sync` (via `scripts/sync-plugin-content.sh`, which wraps `apm pack`). The
+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`).
+
+## 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)).
+
+### Two independent gate families, neither replaced the other
+
+**Family 1 — agentskills.io spec backstop** (unchanged, conformance not quality):
+
+| Constant | Value | Measured over |
+|---|---|---|
+| `MAX_LINES` | 500 | whole file, **frontmatter included** |
+| `MAX_WORDS` | 2,770 | whole file, **frontmatter included** |
+
+**Family 2 — ADR-0020 context budget** (measured differently, on purpose):
+
+| Check | SUGGESTION | FAIL | Measured over |
+|---|---|---|---|
+| `description` characters | 250 | 400 | the YAML-**folded** value |
+| body words | 600 | 900 | **body only** — everything after the frontmatter's closing `---` |
+
+Plus two hard FAILs with no suggestion tier:
+
+- **A missing, valueless or `null` `description:`.** Not a skip. The description is the one field
+  preloaded into every session, so a gate that declines to measure it reports green. (This is not
+  hypothetical: `description:` with no value followed by `model: sonnet` let a line regex capture the
+  *next* key, which looked non-empty, so the "missing or empty" branch never fired and every gate
+  below early-returned on the genuinely empty folded value — exit 0, zero output, on a blocking gate.)
+- **Every `references/<file>.md` a body names must exist** on disk. A dispatch table pointing at a
+  file that was never written is a silently dead branch, and nothing else in the gate/audit/vale
+  stack notices it.
+
+A file can sit well inside one family and fail the other. 2,770 whole-file words is a conformance
+backstop; 900 body-only words is a quality gate. Conflating them is what produced the current state.
+
+### An unresolved routing target is not automatically a FAIL
+
+A boundary-clause target that resolves to no skill or agent has **three** possible verdicts, not one
+(`unresolved_targets()` in `scripts/skill-size-check.sh`):
+
+| 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 |
+| **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
+tool, a file format or an English compound as a route: "pre-commit hooks" is prose about a tool and
+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.
+
+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
+gets promoted.
+
+### Target resolution walk
+
+Resolution walks up **from the file being checked** — never from the script's own location. Deriving
+it from `${BASH_SOURCE}` leaked holocron's 39-skill universe into every consumer repo running the
+hook through pre-commit, so a consumer skill routing to `skill-audit` resolved against a plugin it
+had never installed.
+
+The walk finds an **authoring root**: the nearest ancestor holding `plugins/*/.apm/skills` or
+`plugins/*/.apm/agents`, falling back to the nearest ancestor holding `.git`. **Two passes, not one
+interleaved walk**, so a nested `.git` (a submodule, a sub-package worktree) cannot beat a real
+monorepo root further up.
+
+The universe is then:
+
+1. every skill and agent under `<root>/plugins/*/` — sibling plugins resolve, which is what a
+   monorepo means;
+2. the checked file's own apm package;
+3. the packages that package declares in **its own** `apm.yml` `dependencies.apm`.
+
+The **root** manifest's `dependencies:` block is not read, and no plugin here declares a cross-plugin
+apm dependency — none needs to.
+
+Deployed `.claude/` / `.agents/` trees are consulted **only** when the walk found no plugin monorepo
+root, whether it landed on a bare `.git` ancestor or on nothing at all. That is the consumer case.
+
+**The gate keys on which of the two passes matched, never on whether the root contributed a new
+name.** A name-count delta looks equivalent and is not: `_collect_authoring_root()` re-collects the
+checked file's own plugin, whose names the earlier steps already added, so a single-plugin monorepo
+shows a delta of zero and would wrongly reach for the deployed trees — including the user's global
+`~/.claude/skills`, making the verdict depend on what happens to be installed.
+
+Why it matters: those trees are gitignored `apm install` output, present only on a machine that has
+run it. Four cross-plugin targets here (`gitea-branches` → `git-branches`, `gitea-branches` →
+`git-history`, `gitea-issues` → `git-branches`, `gitea-workflow` → `git-workflow`) once resolved
+through `.claude/skills/` alone, so **the same commit measured 2 dangling targets on a developer
+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**.
+
+### SUGGESTION-only checks
+
+Three more, deterministic to measure but judgment to act on:
+
+- a description with **no boundary clause at all**;
+- a `## Gotchas` section with **more than five entries**;
+- a `## Gotchas` section over **25% of the body**.
+
+### `verbose: true` is load-bearing
+
+The hook is declared `verbose: true` so the SUGGESTION tier is audible. pre-commit prints nothing at
+all for a passing hook, and a SUGGESTION deliberately does not fail — without verbose every
+suggestion is swallowed, which is exactly the invisibility ADR-0013 records for Vale warnings.
+ADR-0020's preload arithmetic depends on it: writing to the 400-char FAIL delivers roughly half the
+cut that writing to the 250-char SUGGESTION does, so the intended saving depends entirely on that
+tier being visible. The numbers, and the measurement method behind them, are not restated here —
+they live in ADR-0020's Consequences section, under "A ceiling does not produce an average", whose
+figures are pinned to the base commit the decision was taken on (`f9b919d`). Quoting them here would
+just create a second copy to go stale. It costs nothing on a clean file — the script prints only
+findings.
+
+### Duplicated constants
+
+`skill-audit`'s `validate.sh` holds a second copy of the four ADR-0020 constants
+(`DESC_SUGGEST_CHARS` / `DESC_MAX_CHARS` / `BODY_SUGGEST_WORDS` / `BODY_MAX_WORDS`), and
+`agent-audit`'s `validate.sh` holds a third copy of the two description constants. They are copied
+rather than imported because a cache-installed plugin's scripts cannot read files outside their own
+plugin directory. `tests/test-skill-size-check.sh` asserts the copies agree, so drift fails CI rather
+than silently letting an audit bless a skill the commit hook then rejects. The shared boundary
+resolver block is embedded verbatim in all three scripts between `BEGIN`/`END ADR-0020 SHARED
+BOUNDARY RESOLVER` markers and must stay byte-identical.
+
+### `python3` and PyYAML are hard requirements
+
+Both, and neither is a best-effort accelerator.
+
+`python3` because the script measures the **folded** `description` value. Most descriptions here are
+`>`-block scalars, so a regex over the raw lines measures indentation and newlines instead of the
+value. Missing it fails the hook with an install pointer rather than skipping the ADR-0020 checks,
+which would be a vacuous green. In practice it is already present — pre-commit is itself a Python
+application.
+
+**PyYAML** because the hand-rolled fallback frontmatter reader has been **removed deliberately**. It
+disagreed with a real parser across the FAIL boundary — one corpus description measured 270
+characters parsed and 412 unparsed — and a quoted `"description"` key or an explicit
+`description: null` returned empty from it, silently skipping the description *and* routing checks. A
+reader that mis-parses an unfamiliar scalar shape reports a clean pass on a file it never measured,
+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.
+
+## Agent files take the description gates, not the body gate
+
+`check-apm-agents-valid` runs agent-audit's `validate.sh` over every real
+`plugins/*/.apm/agents/*.agent.md`. It derives its expected file set from `git ls-files` — the pattern
+`tests/run-bats.sh` established — so an agent file deleted from the worktree but still tracked fails
+the run, and **discovering zero agent files is an error, not a pass**. An untracked *new* agent file
+is still validated: the derivation is one-directional on purpose, so uncommitted work is not blocked
+but also cannot bypass the gate.
+
+The hook exists because `validate.sh` was previously exercised only by `check-scope-walkup-sync`,
+against synthetic `mktemp` fixtures — it had never run against the agent files it governs. That is
+how ADR-0016 could be amended to bless a `disallowedTools` frontmatter field while `validate.sh`'s
+allowlist still rejected it: spec and enforcer disagreed and every gate stayed green.
+
+Agents take the ADR-0020 **description** gates (agent-audit's `validate.sh` holds its own copy of
+those two constants) and, deliberately, **no body word gate**. A skill body is loaded into the
+caller's context and competes with the live conversation; an agent body becomes the system prompt of
+a *fresh* context. The rationale for the 900-word FAIL does not transfer. A bats test pins that
+absence in agent-audit's validator — adding a body gate there contradicts the ADR rather than fixing
+an inconsistency.
+
+**Be precise about the scope of that guarantee: it holds for the *validator*, not for the shared
+script.** `scripts/skill-size-check.sh` applies its body gate to whatever path it is handed, and
+
+```
+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`
+— 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.
+
+## Current retrofit status
+
+**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.
+
+| 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` |
+
+`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.
+
+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**.
+
+Check where a skill stands before starting, and check **both** gates:
+
+```
+pre-commit run skill-size-check --all-files   # size/context only
+pre-commit run --all-files                    # size AND Vale
+```
+
+Scoping a retrofit off `skill-size-check` output alone leaves you blocked at the second gate.
+
+## Vale
+
+Install the `vale` binary — `brew install vale` (macOS), `snap install vale` (Linux),
+`choco install vale` (Windows), or see <https://vale.sh/docs/vale-cli/installation/>. No `vale sync`
+is needed: the `Kyberforge` styles are **committed** under
+`plugins/kyberforge/.apm/skills/{skill-audit,agent-audit}/assets/vale/styles/`, not downloaded
+packages (ADR-0014).
+
+### Two copies, one canonical
+
+Wiring Vale as a deterministic prefilter for `skill-audit`/`agent-audit`'s Description dimension
+(motivation: issue #84) is repo-specific, not part of the generic `lint` plugin, so it does not live
+in `plugins/lint/` — and per ADR-0014 it no longer lives at the repo root either. It lives **twice**,
+one copy per skill, both under `plugins/kyberforge/.apm/skills/`:
+
+| Copy | Styles | `.vale.ini` sections |
+|---|---|---|
+| `agent-audit/assets/vale/` — **canonical** | `Kyberforge`, `KyberforgeCopilot` | `[**/agents/*.md]`, `[**/*.agent.md]` |
+| `skill-audit/assets/vale/` — smaller duplicate | `Kyberforge` | `[**/SKILL.md]` |
+
+Duplicated rather than shared because a plugin's cache-install copies only each skill's own files —
+there is no cross-skill sharing to point at. `check-vale-style-sync` at pre-push is what keeps them
+from drifting; `KyberforgeCopilot` is the one deliberate inequality, being scoped only to `.agent.md`
+files for the Copilot-only "`Use proactively` has no effect" check.
+
+### What Vale owns, and what stays LLM judgment
+
+Eleven rule files across the two copies, six distinct rules:
+
+| Rule | Vale scope | Bans | From |
+|---|---|---|---|
+| `Kyberforge.DescriptionOpener` | `text.frontmatter.description` | non-imperative openers ("This skill/agent…") | issue #84 |
+| `Kyberforge.VagueWording` | `text.frontmatter.description` | vague capability wording ("helps with", "utilize", …) | issue #84 |
+| `Kyberforge.PaddingPhrase` | `text` | generic "see `references/` for details" padding | issue #84 |
+| `KyberforgeCopilot.ProactivePhrase` | `text.frontmatter.description` | `Use proactively` (no effect in Copilot) | issue #84 |
+| `Kyberforge.SentenceOpenerThereIs` | `sentence` | "There is/are" sentence openers | ADR-0013 |
+| `Kyberforge.CompositionNote` | `text.frontmatter.description` | architecture and composition prose in a description | ADR-0020 |
+
+Vale covers the **pattern-matchable** sub-checks named in issue #84 plus, per ADR-0013, one
+cherry-picked body-wide prose-pattern rule. Everything else stays LLM judgment: defaults-vs-menus,
+why-rationale, the non-pattern-matchable body-discipline calls, near-miss exclusion strength, and
+control calibration. New rules land directly in `styles/Kyberforge` and block immediately — there is
+no trial tier.
+
+The cherry-pick record, so it is not re-litigated:
+
+- `Kyberforge.SentenceOpenerThereIs` **landed** — 22 held-out hits, both in-corpus hits clean
+  rewrites, zero suppressions needed.
+- `Kyberforge.VagueQualifier` was cherry-picked and then **deleted**. 2 hits across the corpus as it
+  stood on 2026-08-08 (before the `.apm/` restructure): one marginal, and one unfixable false
+  positive — `caveman/SKILL.md` quotes `of course` as an example of filler, a mention rather than a
+  use — which forced the repo's only Vale suppression comments.
+- `governance.md` and `CONTROLS.md` were evaluated as rule sources and **excluded**: nothing
+  prose-pattern-matchable to mine.
+
+### Why every rule is `level: error`
+
+Every alert is a FAIL, with no ignorable tier — same all-or-nothing model as shellcheck, the test
+suite, and conventional-pre-commit. Graded severities do not work here: **Vale's exit code keys on
+`error` alerts alone**, so a `warning` or `suggestion` rule exits 0, and pre-commit swallows a
+passing hook's output. Such a rule would be invisible and would block nothing.
+
+`MinAlertLevel` and `--minAlertLevel` are correspondingly **absent** from both `.vale.ini` files and
+from the hook definitions. Under this model they are no-ops; adding one is not a missing knob.
+
+The `verbose: true` escape hatch that makes `skill-size-check`'s SUGGESTION tier audible has no
+analogue here — Vale has no tier to make audible.
+
+### External consumers: the root `.pre-commit-hooks.yaml`
+
+The root `.pre-commit-hooks.yaml` exposes both Vale copies (`kyberforge-vale-audit-skill`,
+`kyberforge-vale-audit-agent`) plus `kyberforge-skill-size-check`, so any external repo can enforce
+the same rules with `repo: <this-repo-url>, rev: <tag>` in its own `.pre-commit-config.yaml`.
+pre-commit clones the pinned rev into its own cache, independent of whether Claude Code or the
+`kyberforge` plugin is installed at all; the same mechanism covers CI via `pre-commit run
+--all-files`. `skill-size-check` has no external asset dependency, so it needed no relocation under
+ADR-0014 — only exposure.
+
+This repo's own `vale-audit-prefilter-skill` / `-agent` hooks consume the **identical**
+plugin-bundled copies via `repo: local`. Deliberately not a third root copy, and deliberately **not a
+pinned self-reference** — a pinned self-reference would lint working-tree edits against the last
+tagged release rather than against the change being made.
+
+### Pre-commit
+
+Two prefilter hooks, with `.apm/`-scoped `files:` patterns:
+
+| Hook | Pattern |
+|---|---|
+| `vale-audit-prefilter-skill` | `^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$` |
+| `vale-audit-prefilter-agent` | `^plugins/[^/]+/\.apm/agents/[^/]+\.agent\.md$` |
+
+Only the **authoring source** triggers them. A `SKILL.md` in the generated flat mirror matches
+neither pattern, so prose findings surface only when you edit the file you are supposed to be
+editing. Without the binary the hooks fail with a bare "command not found" and no install pointer.
+
+**Two hooks, not one combined hook.** Both manifests split the prefilter in two precisely because a
+single hook can point at only one copy, and that copy would silently 0-file-skip the other file
+shape (see [A 0-file Vale run is NOT RUN](#a-0-file-vale-run-is-not-run)).
+
+### The `.vale.ini` globs do no scoping
+
+Each `.vale.ini`'s section globs are **path-agnostic** — `[**/SKILL.md]` for skill-audit's copy,
+`[**/agents/*.md]` and `[**/*.agent.md]` for agent-audit's — and constrain filename *shape*, not
+location: Vale's `*` crosses `/`. A `SKILL.md` outside `plugins/` (a project-scope
+`.claude/skills/foo/SKILL.md`, say) still matches `[**/SKILL.md]` and gets linted normally.
+
+All scoping therefore comes from the pre-commit hook's own `files:` regex and from the audit skills
+passing one explicit file per invocation. The two manifests scope **differently on purpose**:
+
+| Manifest | `-skill` | `-agent` |
+|---|---|---|
+| `.pre-commit-config.yaml` (pins this repo's layout) | `^plugins/[^/]+/\.apm/skills/[^/]+/SKILL\.md$` | `^plugins/[^/]+/\.apm/agents/[^/]+\.agent\.md$` |
+| `.pre-commit-hooks.yaml` (layout-agnostic for consumers) | `(^\|/)SKILL\.md$` | `(^\|/)agents/[^/]+\.md$\|\.agent\.md$` |
+
+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.
+
+### `vale-wrap.sh`, never bare `vale`
+
+Both audit skills' Step 1 and both pre-commit hooks call **each copy's own**
+`scripts/vale-wrap.sh`, not `vale`. It works around a confirmed **Vale 3.15.2** limitation:
+`text.frontmatter.description` silently stops matching on most — not all — multi-line descriptions.
+
+Verified by reproduction on a deliberately-bad fixture, not assumed:
+
+| Description scalar spanning 2+ lines | Vale's behaviour |
+|---|---|
+| `>` folded block | 0 alerts, exit 0 — **broken** |
+| plain (unquoted) continuation lines | 0 alerts, exit 0 — **broken** |
+| single- or double-quoted, wrapped | 0 alerts, exit 0 — **broken** |
+| `\|` literal block | alerts fire, exit 1 — lints normally |
+
+The wrapper flattens the three broken forms to a single-line scalar in a scratch copy — or, for the
+rare value no inline scalar can spell verbatim, a `|-` block with one content line — padding with
+blank lines so **every other line number is unchanged**. `|` literal blocks and single-line
+descriptions pass through untouched. Most descriptions in this repo are `>` blocks, so before the
+wrapper a bad description in any of the three broken forms sailed straight through the prefilter.
+
+### The `--config` argv defect
+
+Handed **no `--config` at all**, the wrapper falls back to its own sibling `assets/vale/.vale.ini`,
+located from `${BASH_SOURCE[0]}` rather than from the cwd. That is why both manifests' `entry:` is
+now the bare script path with **no argument after it**.
+
+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. A `--config` in
+`.pre-commit-hooks.yaml` therefore pointed at a path no consumer has and hard-failed every external
+run with `E100 [--config] Runtime error`.
+
+`.pre-commit-config.yaml` drops the argument too, deliberately keeping the two entries identical.
+The local `repo: local` hook resolved its `--config` correctly only because the consuming repo *was*
+this repo — and that divergence is why three review rounds exercised a path no external consumer
+takes and missed the defect. **Do not reintroduce a `--config` to either manifest to make the local
+run "explicit".**
+
+An explicit `--config` from any other caller still wins, in all three argv forms (`--config X`,
+`--config=/abs`, `--config=rel`), and a relative one resolves against the caller's cwd — matching
+bare `vale`, not the repo root.
+
+Both audit skills' Step 1 passes no `--config` either. Step 1 resolves the script relative to the
+skill's own directory so the call works from an installed plugin cache; a relative `--config`
+alongside it would resolve against the cwd instead, yielding `E100 Runtime error … does not exist`
+and exit 2 — which both skills' fallback misreads as "vale unavailable" and silently downgrades to
+full LLM judgment.
+
+`tests/test-vale-wrap.sh` regression-tests this against **skill-audit's** copy specifically: its
+fixtures are all `SKILL.md`-shaped, and only skill-audit's `.vale.ini` carries that glob section.
+
+### A 0-file Vale run is NOT RUN
+
+Vale reports 0 files only when the path it is handed matches **no glob section at all** — a
+differently-named file, or a directory argument holding nothing that matches. That run prints
+
+```
+✔ 0 errors ... in 0 files.
+```
+
+and exits 0, indistinguishable from a clean pass. Both audits therefore treat a 0-file Vale run as
+**NOT RUN** and fall back to full LLM judgment rather than reporting the Description dimension
+clean.
+
+### Pre-push
+
+`vale` is a **pre-push** dependency too, not only pre-commit. `check-vale-style-sync` runs **six
+glob-coverage probes** by invoking `vale --config` — one representative path per file shape the
+prefilter is supposed to cover. They are the only assertions in the script that catch a `.vale.ini`
+glob typo (`[**/SKILL.md]` → `[**/SKILLS.md]`), the failure mode where every text-level check stays
+clean while vale lints zero files. As a warning this self-disabled on exactly that mutation and
+exited 0, and since pre-commit swallows a passing hook's output the stderr line was never seen — the
+hook reported `Passed`. Missing `vale` is therefore a hard failure here.
+
+The opt-out is `CHECK_VALE_STYLE_SYNC_ALLOW_MISSING_VALE=1`, and **it is not `SKIP=`**: the hook
+still runs and still asserts everything verifiable from file text, but the six probes do not, and its
+summary says so explicitly —
+
+```
+Vale style sync check passed (text-level only, vale unavailable): … 0 glob probe(s) verified.
+```
+
+Use it only on a machine that genuinely cannot install `vale`, and read that line as "the glob axis
+was not checked", not as a pass. The hook is `verbose: true` for exactly that reason — its clean
+output is a single line, so it costs one line per push.
+
+### Mentioning banned phrasing without tripping the rule
+
+House convention: banned phrasing that must be **mentioned** rather than used goes in backticks or a
+fenced code block. Vale skips code spans and fences, so no suppression is needed — which is why this
+document quotes `Use proactively` and "There is/are" the way it does.
+
+Inline `<!-- vale Rule = NO -->` is the fallback **only** where backticking is impossible. Use the
+HTML-comment form; the MDX `{/* */}` form does not work in plain Markdown. The one time a rule forced
+suppression comments, the rule was deleted instead (see the `VagueQualifier` entry above).
+
+## Tests
+
+```
+bash tests/run-tests.sh              # every test-*.sh plus the bats suite
+bash tests/run-tests.sh --bats-only  # just bats
+```
+
+First run auto-initializes the bats submodules; no manual `git submodule update` needed.
+
+**Exit 77 = SKIPPED.** A suite that skips because a dependency is missing does **not** fail an ad-hoc
+run. The pre-push hook invokes the same script as `--strict` (`RUN_TESTS_STRICT=1` is equivalent),
+where a skip **does** fail the push: at pre-push a skip means one of the documented dependencies is
+absent on this machine, so the gate would otherwise report success having run fewer suites than it
+appears to. Without `--strict` the gate once went green having verified 15 of 17 suites on a
+vale-less PATH, with the skip list swallowed. Without vale, three suites skip —
+`test-check-vale-style-sync.sh`, `test-vale-hooks-consumer.sh`, `test-vale-wrap.sh` — and the strict
+failure names each one and what to install.
+
+`tests/run-bats.sh` derives the set of `.bats` files it expects from `git ls-files`, so a `.bats`
+file deleted from the worktree but still tracked in the index fails the run rather than silently
+shrinking the suite. Remove one with `git rm` (or stage the deletion) when intentional; an untracked
+new `.bats` file is picked up and needs no ceremony.
+
+Both discovery walks (`tests/run-bats.sh` and `tests/run-tests.sh`) exclude `apm_modules/`:
+`apm install` materializes a full copy of every plugin there, and running a dependency's copy of a
+`.bats` file breaks its relative path to the bats helpers — **167 spurious failures** before the
+exclusion landed.
+
+## apm gates
+
+### `apm-audit-ci`
+
+Runs `apm audit --ci` **once per manifest** — the root one and each of the six plugin packages —
+because the root-only invocation audits the marketplace manifest and **nothing else**, and
+`apm-pack-check-clean` does not parse plugin `dependencies:` blocks either. Verified: a malformed
+dependency entry passes `apm pack --check-versions --check-clean --dry-run` and fails
+`apm audit --ci` in that package's directory. Costs ~0.5s per package.
+
+It verifies **exactly two things** per manifest and claims no more:
+
+- **manifest-parse** — each `apm.yml` parses as a valid APM manifest. Unconditional; verified to fire
+  on a dependency entry missing its `git`/`path`/`registry` field (`Cannot parse apm.yml`).
+- **lockfile-exists** — any package declaring dependencies has a consistent `apm.lock.yaml`.
+  Conditional, and vacuous while every plugin `apm.yml` declares `dependencies: {apm: [], mcp: []}`;
+  it arms itself the moment one does not (verified by adding a git dependency to
+  `plugins/lint/apm.yml`).
+
+It does **not** enforce an org policy. apm discovers one from the git remote and only understands
+github.com and Azure DevOps, so against this repo's self-hosted Gitea remote it prints:
+
+```
+No org policy found at unknown; enforcement skipped
+```
+
+**Do not "fix" that with `policy.fetch_failure_default: block` in `apm.yml`.** apm's own message
+suggests it; it was tried on a scratch copy and **rejected**. With no reachable policy source it does
+not make the check meaningful, it makes it permanently red — `apm audit --ci` exits 1 with
+`No org policy found at unknown (policy.fetch_failure_default=block)` on every push, forever. A gate
+that can never go green is not a gate. Revisit only if this repo gains a policy source apm can reach.
+
+It also does not scan for hidden Unicode: that scan is plain `apm audit`, a different mode (`--ci`
+refuses to combine with `--file`/`--strip`/`--dry-run`/`PACKAGE`), and plain `apm audit` here reports
+`No apm.lock.yaml found -- nothing to scan` and exits 0. Adding it would buy a second vacuous check.
+
+### `check-executables-allow-sync`
+
+apm gates a package's `hooks/` and `bin/` on an **exact `<package>#<version>` dictionary lookup** in
+root `apm.yml`'s `executables.allow` (`apm_cli/security/executables.py`, `is_package_approved`).
+There is no wildcard and no version-less form.
+
+So bumping `plugins/kyberforge/apm.yml`'s `version:` without bumping the key **errors nowhere**: the
+entry simply stops matching, the gate blocks the hook, kyberforge's `SessionStart` hook stops
+deploying, and the apm install goes quietly stale — the exact failure ADR-0019 exists to end,
+reintroduced through the mechanism meant to secure it. ADR-0019 records this as a live failure mode;
+the release that shipped the hook hit it immediately.
+
+`scripts/check-executables-allow-sync.sh` parses `version:` out of `plugins/kyberforge/apm.yml` and
+asserts root `apm.yml` carries the matching `kyberforge#<version>` key. A comment in the
+`executables:` block stays as the human-facing pointer; the hook is what actually holds. It parses
+with PyYAML where importable and falls back to a two-shape scan otherwise, so a missing pip package
+cannot become the thing that blocks every push.
+
+## `.claude/settings.json`
+
+**apm owns this file. Nothing repo-authored goes in it.**
+
+`apm audit --ci` replays the install into a scratch tree and diffs the result byte-for-byte, so
+anything apm would not have written there — an `enabledPlugins` block, a real `hooks` entry — is
+permanent drift that fails `apm-audit-ci`. A hook you want in this repo is authored in
+`plugins/<name>/.apm/hooks/` and deployed by apm, never hand-written here.
+
+Its committed content is whatever apm last wrote, which today is the merged `SessionStart` entry for
+kyberforge's `check-apm-current.sh`. That is apm's own output and it belongs in the commit (ADR-0019;
+ADR-0018's statement that the committed content is exactly `{"hooks": {}}` is superseded on that
+point only). Machine-specific settings go in the gitignored `.claude/settings.local.json`, which apm
+does not deploy and the replay does not compare; shared enforcement belongs in
+`.pre-commit-config.yaml`.
+
+### Why it is excluded from `pretty-format-json`
+
+It is the **sixth and last alternation** in that hook's `exclude:` pattern, and the only one there
+for a reason other than "generated manifest". Mind which number you are quoting: **six alternations,
+expanding to sixteen real files** — 3 root marketplace manifests, 2 per plugin × 6 plugins, plus this
+one.
+
+`pretty-format-json --autofix` sorts object keys unless `--no-sort-keys` is passed, while apm's hook
+integrator emits insertion order (`matcher` before `hooks`, `type` before `command`). Leaving the
+file in that hook's scope therefore rewrites apm's output into a form apm would never produce on the
+way into **every** commit, and `apm-audit-ci` then reports permanent drift on a file with an empty
+`git diff` — exactly what happened when the `SessionStart` hook first landed in `2e395a4`. Re-running
+`apm install` fixes the file; leaving it in scope would re-break it on the very commit carrying the
+fix.
+
+**Load-bearing. Do not tidy it out of that list** (see `LESSONS.md`, 2026-08-14).
+
+## Pushing without a network
+
+Exactly **two** pre-push hooks need the network, for one shared reason: root `apm.yml`'s
+`marketplace.packages[]` contains exactly one remote entry — `mattpocock-skills`,
+`source: mattpocock/skills` — and resolving it needs a `git ls-remote`.
+
+| Hook | Offline failure |
+|---|---|
+| `apm-marketplace-check` (`always_run`, resolves every entry) | `No cached refs (offline)` |
+| `apm-pack-check-clean` (re-resolves the same entry) | `Error: Git network timeout during ls-remote` |
+
+Pinning the entry to an exact version does **not** remove the call — an exact pin still ls-remotes.
+`--offline` rescues neither.
+
+To push without a network, skip both using pre-commit's own mechanism:
+
+```
+SKIP=apm-marketplace-check,apm-pack-check-clean git push
+```
+
+**Skip those two alone.** Verified under `unshare -rn`: the other twelve pre-push hooks pass offline
+because they are real local checks. (`check-executables-allow-sync` landed after that run, but reads
+two local manifests and makes no network call.) Adding any other hook to `SKIP` disarms it silently.
+
+`apm-audit-ci` calls `apm` too but stays local: its org-policy discovery resolves nothing on this
+remote *before* any network call, so it does not join the pair above.
+
+---
+
+## See also
+
+- `docs/adr/0020-skill-description-and-body-context-contract.md` — the context contract, its
+  enforcement table (deterministic vs. auditor judgment), and every rejected alternative
+- `docs/adr/0019-session-start-hook-keeps-the-apm-install-current.md` — the `SessionStart` hook, the
+  executable-trust gate, and the version-pinned allow key
+- `docs/adr/0017-plugin-content-mirror-bridges-apm-to-host-discovery.md`,
+  `docs/adr/0015-apm-replaces-plugin-marketplace-authoring.md`,
+  `docs/adr/0014-vale-prefilter-ships-from-the-plugin.md` — plugin content sync, apm-generated
+  manifests, committed Vale styles
+- `docs/spec/architecture.md` — directory structure, install pipeline, what is generated and what is
+  hand-authored
+- `.pre-commit-config.yaml` — the hooks themselves, with inline rationale comments

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

@@ -0,0 +1,49 @@
+---
+name: caveman
+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.
+---
+
+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".
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Abbreviate common terms (DB/auth/config/req/res/fn/impl). Strip conjunctions. Use arrows for causality (X -> Y). One word when one word enough.
+
+Technical terms stay exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+### Examples
+
+**"Why React component re-render?"**
+
+> Inline obj prop -> new ref -> re-render. `useMemo`.
+
+**"Explain database connection pooling."**
+
+> Pool = reuse DB conn. Skip handshake -> fast under load.
+
+## Auto-Clarity Exception
+
+Drop caveman temporarily for: security warnings, irreversible action confirmations, multi-step sequences where fragment order risks misread, user asks to clarify or repeats question. Resume caveman after clear part done.
+
+Example -- destructive op:
+
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+>
+> ```sql
+> DROP TABLE users;
+> ```
+>
+> Caveman resume. Verify backup exist first.

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

@@ -0,0 +1,117 @@
+---
+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.
+---
+
+# 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.
+
+## Phase 1 — Build a feedback loop
+
+**This is the skill.** Everything else is mechanical. If you have a fast, deterministic, agent-runnable pass/fail signal for the bug, you will find the cause — bisection, hypothesis-testing, and instrumentation all just consume that signal. If you don't have one, no amount of staring at code will save you.
+
+Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give up.**
+
+### 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 `scripts/hitl-loop.template.sh` so the loop is still structured. Captured output feeds back to you.
+
+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.
+
+## Phase 2 — Reproduce
+
+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).
+- [ ] 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.
+
+## Phase 3 — Hypothesise
+
+Generate **3–5 ranked hypotheses** before testing any of them. Single-hypothesis generation anchors on the first plausible idea.
+
+Each hypothesis must be **falsifiable**: state the prediction it makes.
+
+> Format: "If <X> is the cause, then <changing Y> will make the bug disappear / <changing Z> will make it worse."
+
+If you cannot state the prediction, the hypothesis is a vibe — discard or sharpen it.
+
+**Show the ranked list to the user before testing.** They often have domain knowledge that re-ranks instantly ("we just deployed a change to #3"), or know hypotheses they've already ruled out. Cheap checkpoint, big time saver. Don't block on it — proceed with your ranking if the user is AFK.
+
+## Phase 4 — Instrument
+
+Each probe must map to a specific prediction from Phase 3. **Change one variable at a time.**
+
+Tool preference:
+
+1. **Debugger / REPL inspection** if the env supports it. One breakpoint beats ten logs.
+2. **Targeted logs** at the boundaries that distinguish hypotheses.
+3. Never "log everything and grep".
+
+**Tag every debug log** with a unique prefix, e.g. `[DEBUG-a4f2]`. Cleanup at the end becomes a single grep. Untagged logs survive; tagged logs die.
+
+**Perf branch.** For performance regressions, logs are usually wrong. Instead: establish a baseline measurement (timing harness, `performance.now()`, profiler, query plan), then bisect. Measure first, fix second.
+
+## Phase 5 — Fix + regression test
+
+Write the regression test **before the fix** — but only if there is a **correct seam** for it.
+
+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. The codebase architecture is preventing the bug from being locked down. Flag this for the next phase.
+
+If a correct seam exists:
+
+1. Turn the minimised repro into a failing test at that seam.
+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.
+
+## Phase 6 — Cleanup + post-mortem
+
+Required before declaring done:
+
+- [ ] Original repro no longer reproduces (re-run the Phase 1 loop)
+- [ ] Regression test passes (or absence of seam is documented)
+- [ ] All `[DEBUG-...]` instrumentation removed (`grep` the prefix)
+- [ ] Throwaway prototypes deleted (or moved to a clearly-marked debug location)
+- [ ] The hypothesis that turned out correct is stated in the commit / PR message — so the next debugger learns
+
+**Then ask: what would have prevented this bug?** If the answer involves architectural change (no good test seam, tangled callers, hidden coupling) hand off to the `/improve-codebase-architecture` skill with the specifics. Make the recommendation **after** the fix is in, not before — you have more information now than when you started.

plugins/bin/.apm/skills/diagnose/scripts/hitl-loop.template.sh

@@ -0,0 +1,41 @@
+#!/usr/bin/env bash
+# Human-in-the-loop reproduction loop.
+# Copy this file, edit the steps below, and run it.
+# The agent runs the script; the user follows prompts in their terminal.
+#
+# Usage:
+#   bash hitl-loop.template.sh
+#
+# Two helpers:
+#   step "<instruction>"          → show instruction, wait for Enter
+#   capture VAR "<question>"      → show question, read response into VAR
+#
+# At the end, captured values are printed as KEY=VALUE for the agent to parse.
+
+set -euo pipefail
+
+step() {
+  printf '\n>>> %s\n' "$1"
+  read -r -p "    [Enter when done] " _
+}
+
+capture() {
+  local var="$1" question="$2" answer
+  printf '\n>>> %s\n' "$question"
+  read -r -p "    > " answer
+  printf -v "$var" '%s' "$answer"
+}
+
+# --- edit below ---------------------------------------------------------
+
+step "Open the app at http://localhost:3000 and sign in."
+
+capture ERRORED "Click the 'Export' button. Did it throw an error? (y/n)"
+
+capture ERROR_MSG "Paste the error message (or 'none'):"
+
+# --- edit above ---------------------------------------------------------
+
+printf '\n--- Captured ---\n'
+printf 'ERRORED=%s\n' "$ERRORED"
+printf 'ERROR_MSG=%s\n' "$ERROR_MSG"

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

@@ -0,0 +1,10 @@
+---
+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".
+---
+
+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.
+
+Ask the questions one at a time.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.

plugins/bin/.apm/skills/grill-with-docs/ADR-FORMAT.md

@@ -0,0 +1,47 @@
+# ADR Format
+
+ADRs live in `docs/adr/` and use sequential numbering: `0001-slug.md`, `0002-slug.md`, etc.
+
+Create the `docs/adr/` directory lazily — only when the first ADR is needed.
+
+## Template
+
+```md
+# {Short title of the decision}
+
+{1-3 sentences: what's the context, what did we decide, and why.}
+```
+
+That's it. An ADR can be a single paragraph. The value is in recording *that* a decision was made and *why* — not in filling out sections.
+
+## Optional sections
+
+Only include these when they add genuine value. Most ADRs won't need them.
+
+- **Status** frontmatter (`proposed | accepted | deprecated | superseded by ADR-NNNN`) — useful when decisions are revisited
+- **Considered Options** — only when the rejected alternatives are worth remembering
+- **Consequences** — only when non-obvious downstream effects need to be called out
+
+## Numbering
+
+Scan `docs/adr/` for the highest existing number and increment by one.
+
+## When to offer an ADR
+
+All three of these must be true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+2. **Surprising without context** — a future reader will look at the code and wonder "why on earth 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 a decision is easy to reverse, skip it — you'll just reverse it. If it's not surprising, nobody will wonder why. If there was no real alternative, there's nothing to record beyond "we did the obvious thing."
+
+### What qualifies
+
+- **Architectural shape.** "We're using a monorepo." "The write model is event-sourced, the read model is projected into Postgres."
+- **Integration patterns between contexts.** "Ordering and Billing communicate via domain events, not synchronous HTTP."
+- **Technology choices that carry lock-in.** Database, message bus, auth provider, deployment target. Not every library — just the ones that would take a quarter to swap out.
+- **Boundary and scope decisions.** "Customer data is owned by the Customer context; other contexts reference it by ID only." The explicit no-s are as valuable as the yes-s.
+- **Deliberate deviations from the obvious path.** "We're using manual SQL instead of an ORM because X." Anything where a reasonable reader would assume the opposite. These stop the next engineer from "fixing" something that was deliberate.
+- **Constraints not visible in the code.** "We can't use AWS because of compliance requirements." "Response times must be under 200ms because of the partner API contract."
+- **Rejected alternatives when the rejection is non-obvious.** If you considered GraphQL and picked REST for subtle reasons, record it — otherwise someone will suggest GraphQL again in six months.

plugins/bin/.apm/skills/grill-with-docs/CONTEXT-FORMAT.md

@@ -0,0 +1,77 @@
+# CONTEXT.md Format
+
+## Structure
+
+```md
+# {Context Name}
+
+{One or two sentence description of what this context is and why it exists.}
+
+## Language
+
+**Order**:
+{A concise description of the term}
+_Avoid_: Purchase, transaction
+
+**Invoice**:
+A request for payment sent to a customer after delivery.
+_Avoid_: Bill, payment request
+
+**Customer**:
+A person or organization that places orders.
+_Avoid_: Client, buyer, account
+
+## Relationships
+
+- An **Order** produces one or more **Invoices**
+- An **Invoice** belongs to exactly one **Customer**
+
+## Example dialogue
+
+> **Dev:** "When a **Customer** places an **Order**, do we create the **Invoice** immediately?"
+> **Domain expert:** "No — an **Invoice** is only generated once a **Fulfillment** is confirmed."
+
+## Flagged ambiguities
+
+- "account" was used to mean both **Customer** and **User** — resolved: these are distinct concepts.
+```
+
+## Rules
+
+- **Be opinionated.** When multiple words exist for the same concept, pick the best one and list the others as aliases to avoid.
+- **Flag conflicts explicitly.** If a term is used ambiguously, call it out in "Flagged ambiguities" with a clear resolution.
+- **Keep definitions tight.** One sentence max. Define what it IS, not what it does.
+- **Show relationships.** Use bold term names and express cardinality where obvious.
+- **Only include terms specific to this project's context.** General programming concepts (timeouts, error types, utility patterns) don't belong even if the project uses them extensively. Before adding a term, ask: is this a concept unique to this context, or a general programming concept? Only the former belongs.
+- **Group terms under subheadings** when natural clusters emerge. If all terms belong to a single cohesive area, a flat list is fine.
+- **Write an example dialogue.** A conversation between a dev and a domain expert that demonstrates how the terms interact naturally and clarifies boundaries between related concepts.
+
+## Single vs multi-context repos
+
+**Single context (most repos):** One `CONTEXT.md` at the repo root.
+
+**Multiple contexts:** A `CONTEXT-MAP.md` at the repo root lists the contexts, where they live, and how they relate to each other:
+
+```md
+# Context Map
+
+## Contexts
+
+- [Ordering](./src/ordering/CONTEXT.md) — receives and tracks customer orders
+- [Billing](./src/billing/CONTEXT.md) — generates invoices and processes payments
+- [Fulfillment](./src/fulfillment/CONTEXT.md) — manages warehouse picking and shipping
+
+## Relationships
+
+- **Ordering → Fulfillment**: Ordering emits `OrderPlaced` events; Fulfillment consumes them to start picking
+- **Fulfillment → Billing**: Fulfillment emits `ShipmentDispatched` events; Billing consumes them to generate invoices
+- **Ordering ↔ Billing**: Shared types for `CustomerId` and `Money`
+```
+
+The skill infers which structure applies:
+
+- If `CONTEXT-MAP.md` exists, read it to find contexts
+- If only a root `CONTEXT.md` exists, single context
+- If neither exists, create a root `CONTEXT.md` lazily when the first term is resolved
+
+When multiple contexts exist, infer which one the current topic relates to. If unclear, ask.

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

@@ -0,0 +1,88 @@
+---
+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.
+---
+
+<what-to-do>
+
+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.
+
+Ask the questions one at a time, waiting for feedback on each question before continuing.
+
+If a question can be answered by exploring the codebase, explore the codebase instead.
+
+</what-to-do>
+
+<supporting-info>
+
+## Domain awareness
+
+During codebase exploration, also look for existing documentation:
+
+### File structure
+
+Most repos have a single context:
+
+```
+/
+├── CONTEXT.md
+├── docs/
+│   └── adr/
+│       ├── 0001-event-sourced-orders.md
+│       └── 0002-postgres-for-write-model.md
+└── src/
+```
+
+If a `CONTEXT-MAP.md` exists at the root, the repo has multiple contexts. The map points to where each one lives:
+
+```
+/
+├── CONTEXT-MAP.md
+├── docs/
+│   └── adr/                          ← system-wide decisions
+├── src/
+│   ├── ordering/
+│   │   ├── CONTEXT.md
+│   │   └── docs/adr/                 ← context-specific decisions
+│   └── billing/
+│       ├── CONTEXT.md
+│       └── docs/adr/
+```
+
+Create files lazily — only when you have something to write. If no `CONTEXT.md` exists, create one when the first term is resolved. If no `docs/adr/` exists, create it when the first ADR is needed.
+
+## During the session
+
+### Challenge against the glossary
+
+When the user uses a term that conflicts with the existing language in `CONTEXT.md`, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y — which is it?"
+
+### Sharpen fuzzy language
+
+When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account' — do you mean the Customer or the User? Those are different things."
+
+### Discuss concrete scenarios
+
+When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
+
+### Cross-reference with code
+
+When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible — which is right?"
+
+### 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).
+
+Don't couple `CONTEXT.md` to implementation details. Only include terms that are meaningful to domain experts.
+
+### Offer ADRs sparingly
+
+Only offer to create an ADR when all three are true:
+
+1. **Hard to reverse** — the cost of changing your mind later is meaningful
+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).
+
+</supporting-info>

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

@@ -0,0 +1,37 @@
+# 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**.
+
+## Dependency categories
+
+When assessing a candidate for deepening, classify its dependencies. The category determines how the deepened module is tested across its seam.
+
+### 1. In-process
+
+Pure computation, in-memory state, no I/O. Always deepenable — merge the modules and test through the new interface directly. No adapter needed.
+
+### 2. Local-substitutable
+
+Dependencies that have local test stand-ins (PGLite for Postgres, in-memory filesystem). Deepenable if the stand-in exists. The deepened module is tested with the stand-in running in the test suite. The seam is internal; no port at the module's external interface.
+
+### 3. Remote but owned (Ports & Adapters)
+
+Your own services across a network boundary (microservices, internal APIs). Define a **port** (interface) at the seam. The deep module owns the logic; the transport is injected as an **adapter**. Tests use an in-memory adapter. Production uses an HTTP/gRPC/queue adapter.
+
+Recommendation shape: *"Define a port at the seam, implement an HTTP adapter for production and an in-memory adapter for testing, so the logic sits in one deep module even though it's deployed across a network."*
+
+### 4. True external (Mock)
+
+Third-party services (Stripe, Twilio, etc.) you don't control. The deepened module takes the external dependency as an injected port; tests provide a mock adapter.
+
+## Seam discipline
+
+- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a port unless at least two adapters are justified (typically production + test). A single-adapter seam is just indirection.
+- **Internal seams vs external seams.** A deep module can have internal seams (private to its implementation, used by its own tests) as well as the external seam at its interface. Don't expose internal seams through the interface just because tests use them.
+
+## Testing strategy: replace, don't layer
+
+- Old unit tests on shallow modules become waste once tests at the deepened module's interface exist — delete them.
+- Write new tests at the deepened module's interface. The **interface is the test surface**.
+- Tests assert on observable outcomes through the interface, not internal state.
+- Tests should survive internal refactors — they describe behaviour, not implementation. If a test has to change when the implementation changes, it's testing past the interface.

plugins/bin/.apm/skills/improve-codebase-architecture/INTERFACE-DESIGN.md

@@ -0,0 +1,44 @@
+# Interface Design
+
+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**.
+
+## Process
+
+### 1. Frame the problem space
+
+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))
+- 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.
+
+### 2. Spawn sub-agents
+
+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:
+
+- 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.
+
+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))
+5. Trade-offs — where leverage is high, where it's thin
+
+### 3. Present and compare
+
+Present designs sequentially so the user can absorb each one, then compare them in prose. Contrast by **depth** (leverage at the interface), **locality** (where change concentrates), and **seam placement**.
+
+After comparing, give your own recommendation: which design you think is strongest and why. If elements from different designs would combine well, propose a hybrid. Be opinionated — the user wants a strong read, not a menu.

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

@@ -0,0 +1,53 @@
+# Language
+
+Shared vocabulary for every suggestion this skill makes. Use these terms exactly — don't substitute "component," "service," "API," or "boundary." Consistent language is the whole point.
+
+## Terms
+
+**Module**
+Anything with an interface and an implementation. Deliberately scale-agnostic — applies equally to a function, class, package, or tier-spanning slice.
+_Avoid_: unit, component, service.
+
+**Interface**
+Everything a caller must know to use the module correctly. Includes the type signature, but also invariants, ordering constraints, error modes, required configuration, and performance characteristics.
+_Avoid_: API, signature (too narrow — those refer only to the type-level surface).
+
+**Implementation**
+What's inside a module — its body of code. Distinct from **Adapter**: a thing can be a small adapter with a large implementation (a Postgres repo) or a large adapter with a small implementation (an in-memory fake). Reach for "adapter" when the seam is the topic; "implementation" otherwise.
+
+**Depth**
+Leverage at the interface — the amount of behaviour a caller (or test) can exercise per unit of interface they have to learn. A module is **deep** when a large amount of behaviour sits behind a small interface. A module is **shallow** when the interface is nearly as complex as the implementation.
+
+**Seam** _(from Michael Feathers)_
+A place where you can alter behaviour without editing in that place. The *location* at which a module's interface lives. Choosing where to put the seam is its own design decision, distinct from what goes behind it.
+_Avoid_: boundary (overloaded with DDD's bounded context).
+
+**Adapter**
+A concrete thing that satisfies an interface at a seam. Describes *role* (what slot it fills), not substance (what's inside).
+
+**Leverage**
+What callers get from depth. More capability per unit of interface they have to learn. One implementation pays back across N call sites and M tests.
+
+**Locality**
+What maintainers get from depth. Change, bugs, knowledge, and verification concentrate at one place rather than spreading across callers. Fix once, fixed everywhere.
+
+## Principles
+
+- **Depth is a property of the interface, not the implementation.** A deep module can be internally composed of small, mockable, swappable parts — they just aren't part of the interface. A module can have **internal seams** (private to its implementation, used by its own tests) as well as the **external seam** at its interface.
+- **The deletion test.** Imagine deleting the module. If complexity vanishes, the module wasn't hiding anything (it was a pass-through). If complexity reappears across N callers, the module was earning its keep.
+- **The interface is the test surface.** Callers and tests cross the same seam. If you want to test *past* the interface, the module is probably the wrong shape.
+- **One adapter means a hypothetical seam. Two adapters means a real one.** Don't introduce a seam unless something actually varies across it.
+
+## Relationships
+
+- A **Module** has exactly one **Interface** (the surface it presents to callers and tests).
+- **Depth** is a property of a **Module**, measured against its **Interface**.
+- A **Seam** is where a **Module**'s **Interface** lives.
+- An **Adapter** sits at a **Seam** and satisfies the **Interface**.
+- **Depth** produces **Leverage** for callers and **Locality** for maintainers.
+
+## Rejected framings
+
+- **Depth as ratio of implementation-lines to interface-lines** (Ousterhout): rewards padding the implementation. We use depth-as-leverage instead.
+- **"Interface" as the TypeScript `interface` keyword or a class's public methods**: too narrow — interface here includes every fact a caller must know.
+- **"Boundary"**: overloaded with DDD's bounded context. Say **seam** or **interface**.

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

@@ -0,0 +1,71 @@
+---
+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.
+---
+
+# Improve Codebase Architecture
+
+Surface architectural friction and propose **deepening opportunities** — refactors that turn shallow modules into deep ones. The aim is testability and AI-navigability.
+
+## 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).
+
+- **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.
+- **Implementation** — the code inside.
+- **Depth** — leverage at the interface: a lot of behaviour behind a small interface. **Deep** = high leverage. **Shallow** = interface nearly as complex as the implementation.
+- **Seam** — where an interface lives; a place behaviour can be altered without editing in place. (Use this, not "boundary.")
+- **Adapter** — a concrete thing satisfying an interface at a seam.
+- **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):
+
+- **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.**
+
+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.
+
+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:
+
+- Where does understanding one concept require bouncing between many small modules?
+- Where are modules **shallow** — interface nearly as complex as the implementation?
+- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called (no **locality**)?
+- Where do tightly-coupled modules leak across their seams?
+- Which parts of the codebase are untested, or hard to test through their current interface?
+
+Apply the **deletion test** to anything you suspect is shallow: would deleting it concentrate complexity, or just move it? A "yes, concentrates" is the signal you want.
+
+### 2. Present candidates
+
+Present a numbered list of deepening opportunities. For each candidate:
+
+- **Files** — which files/modules are involved
+- **Problem** — why the current architecture is causing friction
+- **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."
+
+**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.
+
+Do NOT propose interfaces yet. Ask the user: "Which of these would you like to explore?"
+
+### 3. Grilling loop
+
+Once the user picks a candidate, drop into a grilling conversation. Walk the design tree with them — constraints, dependencies, the shape of the deepened module, what sits behind the seam, what tests survive.
+
+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.
+- **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).

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

@@ -0,0 +1,79 @@
+# Logic Prototype
+
+A tiny interactive terminal app that lets the user drive a state model by hand. Use this when the question is about **business logic, state transitions, or data shape** — the kind of thing that looks reasonable on paper but only feels wrong once you push it through real cases.
+
+## When this is the right shape
+
+- "I'm not sure if this state machine handles the edge case where X then Y."
+- "Does this data model actually let me represent the case where..."
+- "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).
+
+## Process
+
+### 1. State the question
+
+Before writing code, write down what state model and what question you're prototyping. One paragraph, in the prototype's README or a comment at the top of the file. A logic prototype that answers the wrong question is pure waste — make the question explicit so it can be checked later, whether the user is watching now or returning to it AFK.
+
+### 2. Pick the language
+
+Use whatever the host project uses. If the project has no obvious runtime (e.g. a docs repo), ask.
+
+Match the project's existing conventions for tooling — don't add a new package manager or runtime just for the prototype.
+
+### 3. Isolate the logic in a portable module
+
+Put the actual logic — the bit that's answering the question — behind a small, pure interface that could be lifted out and dropped into the real codebase later. The TUI around it is throwaway; the logic module shouldn't be.
+
+The right shape depends on the question:
+
+- **A pure reducer** — `(state, action) => state`. Good when actions are discrete events and state is a single value.
+- **A state machine** — explicit states and transitions. Good when "which actions are even legal right now" is part of the question.
+- **A small set of pure functions** over a plain data type. Good when there's no implicit current state — just transformations.
+- **A class or module with a clear method surface** when the logic genuinely owns ongoing internal state.
+
+Pick whichever shape best fits the question being asked, *not* whichever is easiest to wire to a TUI. Keep it pure: no I/O, no terminal code, no `console.log` for control flow. The TUI imports it and calls into it; nothing flows the other direction.
+
+This is what makes the prototype useful past its own lifetime. When the question's been answered, the validated reducer / machine / function set can be lifted into the real module — the TUI shell gets deleted.
+
+### 4. Build the smallest TUI that exposes the state
+
+Build it as a **lightweight TUI** — on every tick, clear the screen (`console.clear()` / `print("\033[2J\033[H")` / equivalent) and re-render the whole frame. The user should always see one stable view, not an ever-growing scrollback.
+
+Each frame has two parts, in this order:
+
+1. **Current state**, pretty-printed and diff-friendly (one field per line, or formatted JSON). Use **bold** for field names or section headers and **dim** for less important context (timestamps, IDs, derived values). Native ANSI escape codes are fine — `\x1b[1m` bold, `\x1b[2m` dim, `\x1b[0m` reset. No need to pull in a styling library unless one is already in the project.
+2. **Keyboard shortcuts**, listed at the bottom: `[a] add user  [d] delete user  [t] tick clock  [q] quit`. Bold the key, dim the description, or vice-versa — whatever reads cleanly.
+
+Behaviour:
+
+1. **Initialise state** — a single in-memory object/struct. Render the first frame on start.
+2. **Read one keystroke (or one line)** at a time, dispatch to a handler that mutates state.
+3. **Re-render** the full frame after every action — don't append, replace.
+4. **Loop until quit.**
+
+The whole frame should fit on one screen.
+
+### 5. Make it runnable in one command
+
+Add a script to the project's existing task runner (`package.json` scripts, `Makefile`, `justfile`, `pyproject.toml`). The user should run `pnpm run <prototype-name>` or equivalent — never need to remember a path.
+
+If the host project has no task runner, just put the command at the top of the prototype's README.
+
+### 6. Hand it over
+
+Give the user the run command. They'll drive it themselves; the interesting moments are when they say "wait, that shouldn't be possible" or "huh, I assumed X would be different" — those are the bugs in the _idea_, which is the whole point. If they want new actions added, add them. Prototypes evolve.
+
+### 7. Capture the answer
+
+When the prototype has done its job, the answer to the question is the only thing worth keeping. If the user is around, ask what it taught them. If not, leave a `NOTES.md` next to the prototype so the answer can be filled in (or filled in by you, if you've watched the session) before the prototype gets deleted.
+
+## Anti-patterns
+
+- **Don't add tests.** A prototype that needs tests is no longer a prototype.
+- **Don't wire it to the real database.** Use an in-memory store unless the question is specifically about persistence.
+- **Don't generalise.** No "what if we wanted to support X later." The prototype answers one question.
+- **Don't blur the logic and the TUI together.** If the reducer / state machine references `console.log`, prompts, or terminal escape codes, it's no longer portable. Keep the TUI as a thin shell over a pure module.
+- **Don't ship the TUI shell into production.** The shell is optimised for being driven by hand from a terminal. The logic module behind it is the bit worth keeping.

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

@@ -0,0 +1,30 @@
+---
+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".
+---
+
+# Prototype
+
+A prototype is **throwaway code that answers a question**. The question decides the shape.
+
+## 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:
+
+- **"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.
+
+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.
+
+## Rules that apply to both
+
+1. **Throwaway from day one, and clearly marked as such.** Locate the prototype code close to where it will actually be used (next to the module or page it's prototyping for) so context is obvious — but name it so a casual reader can see it's a prototype, not production. For throwaway UI routes, obey whatever routing convention the project already uses; don't invent a new top-level structure.
+2. **One command to run.** Whatever the project's existing task runner supports — `pnpm <name>`, `python <path>`, `bun <path>`, etc. The user must be able to start it without thinking.
+3. **No persistence by default.** State lives in memory. Persistence is the thing the prototype is *checking*, not something it should depend on. If the question explicitly involves a database, hit a scratch DB or a local file with a clear "PROTOTYPE — wipe me" name.
+4. **Skip the polish.** No tests, no error handling beyond what makes the prototype *runnable*, no abstractions. The point is to learn something fast and then delete it.
+5. **Surface the state.** After every action (logic) or on every variant switch (UI), print or render the full relevant state so the user can see what changed.
+6. **Delete or absorb when done.** When the prototype has answered its question, either delete it or fold the validated decision into the real code — don't leave it rotting in the repo.
+
+## When done
+
+The *answer* is the only thing worth keeping from a prototype. Capture it somewhere durable (commit message, ADR, issue, or a `NOTES.md` next to the prototype) along with the question it was answering. If the user is around, that capture is a quick conversation; if not, leave the placeholder so they (or you, on the next pass) can fill in the verdict before deleting the prototype.

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

@@ -0,0 +1,112 @@
+# UI Prototype
+
+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).
+
+## When this is the right shape
+
+- "What should this page look like?"
+- "I want to see a few options for this dashboard before committing."
+- "Try a different layout for the settings screen."
+- Any time the user would otherwise spend a day picking between three vague mockups in their head.
+
+## Two sub-shapes — strongly prefer sub-shape A
+
+A UI prototype is much easier to judge when it's **butting up against the rest of the app** — real header, real sidebar, real data, real density. A throwaway route on its own is a vacuum: every variant looks fine in isolation. Default to sub-shape A whenever there's a plausible existing page to host the variants. Only reach for sub-shape B if the prototype genuinely has no nearby home.
+
+### Sub-shape A — adjustment to an existing page (preferred)
+
+The route already exists. Variants are rendered **on the same route**, gated by a `?variant=` URL search param. The existing data fetching, params, and auth all stay — only the rendering swaps. This is the default; pick it unless there's a specific reason not to.
+
+If the prototype is for something that doesn't yet have a page but *would naturally live inside one* (a new section of the dashboard, a new card on the settings screen, a new step in an existing flow) — that's still sub-shape A. Mount the variants inside the host page.
+
+### Sub-shape B — a new page (last resort)
+
+Only use this when the thing being prototyped genuinely has no existing page to live inside — e.g. an entirely new top-level surface, or a flow that can't be embedded anywhere sensible.
+
+Create a **throwaway route** following whatever routing convention the project already uses — don't invent a new top-level structure. Name it so it's obviously a prototype (e.g. include the word `prototype` in the path or filename). Same `?variant=` pattern.
+
+Before committing to sub-shape B, sanity-check: is there really no existing page this could be embedded in? An empty route hides design problems that a populated one would expose.
+
+In both sub-shapes the floating bottom bar is identical.
+
+## Process
+
+### 1. State the question and pick N
+
+Default to **3 variants**. More than 5 stops being radically different and starts being noise — cap there.
+
+Write down the plan in one line, in the prototype's location or a top-of-file comment:
+
+> "Three variants of the settings page, switchable via `?variant=`, on the existing `/settings` route."
+
+This works whether the user is here to push back or not.
+
+### 2. Generate radically different variants
+
+Draft each variant. Hold each one to:
+
+- The page's purpose and the data it has access to.
+- The project's component library / styling system (TailwindCSS, shadcn, MUI, plain CSS, whatever).
+- A clear exported component name, e.g. `VariantA`, `VariantB`, `VariantC`.
+
+Variants must be **structurally different** — different layout, different information hierarchy, different primary affordance, not just different colours. Three slightly-tweaked card grids isn't a UI prototype, it's wallpaper. If two drafts come out too similar, redo one with explicit "do not use a card grid" guidance.
+
+### 3. Wire them together
+
+Create a single switcher component on the route:
+
+```tsx
+// pseudo-code — adapt to the project's framework
+const variant = searchParams.get('variant') ?? 'A';
+return (
+  <>
+    {variant === 'A' && <VariantA {...data} />}
+    {variant === 'B' && <VariantB {...data} />}
+    {variant === 'C' && <VariantC {...data} />}
+    <PrototypeSwitcher variants={['A','B','C']} current={variant} />
+  </>
+);
+```
+
+For sub-shape A (existing page): keep all the existing data fetching above the switcher; only the rendered subtree changes per variant.
+
+For sub-shape B (new page): the throwaway route under `/prototype/<name>` mounts the same switcher.
+
+### 4. Build the floating switcher
+
+A small fixed-position bar at the bottom-centre of the screen with three pieces:
+
+- **Left arrow** — cycles to the previous variant (wraps around).
+- **Variant label** — shows the current variant key and, if the variant exports a name, that name too. e.g. `B — Sidebar layout`.
+- **Right arrow** — cycles forward (wraps around).
+
+Behaviour:
+
+- Clicking an arrow updates the URL search param (use the framework's router — `router.replace` on Next, `navigate` on React Router, etc) so the variant is shareable and reload-stable.
+- Keyboard: `←` and `→` arrow keys also cycle. Don't intercept arrow keys when an `<input>`, `<textarea>`, or `[contenteditable]` is focused.
+- Visually distinct from the page (e.g. high-contrast pill, subtle shadow) so it's obviously not part of the design being evaluated.
+- Hidden in production builds — gate on `process.env.NODE_ENV !== 'production'` or an equivalent check, so a stray prototype merge can't ship the bar to users.
+
+Put the switcher in a single shared component so both sub-shapes can reuse it. Locate it wherever shared UI lives in the project.
+
+### 5. Hand it over
+
+Surface the URL (and the `?variant=` keys). The user will flip through whenever they get to it. The interesting feedback is usually **"I want the header from B with the sidebar from C"** — that's the actual design they want.
+
+### 6. Capture the answer and clean up
+
+Once a variant has won, write down which one and why (commit message, ADR, issue, or a `NOTES.md` next to the prototype if running AFK and the user hasn't responded yet). Then:
+
+- **Sub-shape A** — delete the losing variants and the switcher; fold the winner into the existing page.
+- **Sub-shape B** — promote the winning variant to a real route, delete the throwaway route and the switcher.
+
+Don't leave variant components or the switcher lying around. They rot fast and confuse the next reader.
+
+## Anti-patterns
+
+- **Variants that differ only in colour or copy.** That's a tweak, not a prototype. Real variants disagree about structure.
+- **Sharing too much code between variants.** A shared `<Header>` is fine; a shared `<Layout>` defeats the point. Each variant should be free to throw out the layout.
+- **Wiring variants to real mutations.** Read-only prototypes are fine. If a variant needs to mutate, point it at a stub — the question is "what should this look like", not "does the backend work".
+- **Promoting the prototype directly to production.** The variant code was written under prototype constraints (no tests, minimal error handling). Rewrite it properly when you fold it in.

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

@@ -0,0 +1,15 @@
+```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

@@ -0,0 +1,97 @@
+---
+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).
+metadata:
+  category: research
+allowed-tools:
+  - WebSearch
+  - WebFetch
+  - Read
+  - Write
+  - mcp__context7__resolve-library-id
+  - mcp__context7__query-docs
+model: sonnet
+---
+
+<requirements>
+
+## Required inputs
+
+- **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
+
+## Constraints
+
+- 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
+
+</requirements>
+
+<steps>
+
+## Process
+
+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.
+
+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.
+
+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.
+
+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.
+
+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.
+
+6. **Consolidate.** Merge all subagent summaries (Context7 and web) by topic area. Identify which default topics have sufficient content and which custom topics emerged.
+
+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.
+
+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`.
+
+## Output format
+
+- `<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
+
+</steps>
+
+<checks>
+
+## Failure handling
+
+- 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
+
+## 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>

plugins/bin/.apm/skills/research/references/file-format.md

@@ -0,0 +1,39 @@
+# Reference file format
+
+Every topic file follows this structure.
+
+## Frontmatter
+
+```yaml
+---
+topic: <topic-slug>          # matches the filename without .md (e.g. "api-reference")
+source_keys:                 # kebab-case slugs of sources that contributed; must match sources.md entries
+  - <slug>
+  - <slug>
+---
+```
+
+## Body
+
+Plain prose organized into markdown sections (`##`, `###`). Extract the content most relevant to skill authoring or implementation — not a verbatim copy of the source. Focus on:
+- Decisions that affect how to call the API or tool
+- Options, flags, or parameters with non-obvious behavior
+- Constraints, rate limits, or gotchas
+- Canonical patterns the skill should follow
+
+No inline URLs in the body — all source traceability lives in `sources.md` via `source_keys`.
+
+## sources.md format
+
+```markdown
+# Sources
+
+## <slug>
+
+- **URL:** <full URL>
+- **Description:** <one-line summary of what this source covers>
+- **Contributing files:** <comma-separated list of topic files this source contributed to>
+- **Status:** `extracted` | `no content extracted`
+```
+
+Use one `##` section per source. Slugs are kebab-case derived from the domain or page title (e.g. `stripe-api-docs`, `openai-python-sdk-readme`). For Context7 sources, use the slug `context7-<library-slug>` (e.g. `context7-vercel-next-js`) and set **URL** to `context7:<library-id>` (e.g. `context7:/vercel/next.js`).

plugins/bin/.apm/skills/research/references/topics.md

@@ -0,0 +1,17 @@
+# Default topic list
+
+Create one file per topic when relevant content is found. Skip topics with no content. Add custom topics when content warrants it.
+
+| File | Covers |
+|---|---|
+| `overview.md` | What it is, key concepts, mental model, architecture summary |
+| `installation.md` | Setup, dependencies, prerequisites, version requirements |
+| `configuration.md` | Config files, options, environment variables, defaults |
+| `cli-reference.md` | Commands, subcommands, flags, exit codes |
+| `api-reference.md` | Endpoints, SDK methods, types, request/response shapes |
+| `examples.md` | Common usage patterns, recipes, quickstart walkthroughs |
+| `troubleshooting.md` | Known issues, error codes, gotchas, workarounds |
+
+## Custom topics
+
+Create additional topic files when content doesn't fit the defaults. Examples: `webhooks.md`, `rate-limits.md`, `authentication.md`, `migrations.md`, `security.md`. Use kebab-case filenames.

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

@@ -0,0 +1,109 @@
+---
+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.
+---
+
+# Test-Driven Development
+
+## Philosophy
+
+**Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't.
+
+**Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure.
+
+**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.
+
+## Anti-Pattern: Horizontal Slices
+
+**DO NOT write all tests first, then all implementation.** This is "horizontal slicing" - treating RED as "write all tests" and GREEN as "write all code."
+
+This produces **crap tests**:
+
+- Tests written in bulk test _imagined_ behavior, not _actual_ behavior
+- You end up testing the _shape_ of things (data structures, function signatures) rather than user-facing behavior
+- Tests become insensitive to real changes - they pass when behavior breaks, fail when behavior is fine
+- You outrun your headlights, committing to test structure before understanding the implementation
+
+**Correct approach**: Vertical slices via tracer bullets. One test → one implementation → repeat. Each test responds to what you learned from the previous cycle. Because you just wrote the code, you know exactly what behavior matters and how to verify it.
+
+```
+WRONG (horizontal):
+  RED:   test1, test2, test3, test4, test5
+  GREEN: impl1, impl2, impl3, impl4, impl5
+
+RIGHT (vertical):
+  RED→GREEN: test1→impl1
+  RED→GREEN: test2→impl2
+  RED→GREEN: test3→impl3
+  ...
+```
+
+## Workflow
+
+### 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.
+
+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)
+- [ ] List the behaviors to test (not implementation steps)
+- [ ] Get user approval on the plan
+
+Ask: "What should the public interface look like? Which behaviors are most important to test?"
+
+**You can't test everything.** Confirm with the user exactly which behaviors matter most. Focus testing effort on critical paths and complex logic, not every possible edge case.
+
+### 2. Tracer Bullet
+
+Write ONE test that confirms ONE thing about the system:
+
+```
+RED:   Write test for first behavior → test fails
+GREEN: Write minimal code to pass → test passes
+```
+
+This is your tracer bullet - proves the path works end-to-end.
+
+### 3. Incremental Loop
+
+For each remaining behavior:
+
+```
+RED:   Write next test → fails
+GREEN: Minimal code to pass → passes
+```
+
+Rules:
+
+- One test at a time
+- Only enough code to pass current test
+- Don't anticipate future tests
+- Keep tests focused on observable behavior
+
+### 4. Refactor
+
+After all tests pass, look for [refactor candidates](refactoring.md):
+
+- [ ] Extract duplication
+- [ ] Deepen modules (move complexity behind simple interfaces)
+- [ ] Apply SOLID principles where natural
+- [ ] Consider what new code reveals about existing code
+- [ ] Run tests after each refactor step
+
+**Never refactor while RED.** Get to GREEN first.
+
+## Checklist Per Cycle
+
+```
+[ ] Test describes behavior, not implementation
+[ ] Test uses public interface only
+[ ] Test would survive internal refactor
+[ ] Code is minimal for this test
+[ ] No speculative features added
+```

plugins/bin/.apm/skills/tdd/deep-modules.md

@@ -0,0 +1,33 @@
+# Deep Modules
+
+From "A Philosophy of Software Design":
+
+**Deep module** = small interface + lots of implementation
+
+```
+┌─────────────────────┐
+│   Small Interface   │  ← Few methods, simple params
+├─────────────────────┤
+│                     │
+│                     │
+│  Deep Implementation│  ← Complex logic hidden
+│                     │
+│                     │
+└─────────────────────┘
+```
+
+**Shallow module** = large interface + little implementation (avoid)
+
+```
+┌─────────────────────────────────┐
+│       Large Interface           │  ← Many methods, complex params
+├─────────────────────────────────┤
+│  Thin Implementation            │  ← Just passes through
+└─────────────────────────────────┘
+```
+
+When designing interfaces, ask:
+
+- Can I reduce the number of methods?
+- Can I simplify the parameters?
+- Can I hide more complexity inside?

plugins/bin/.apm/skills/tdd/interface-design.md

@@ -0,0 +1,31 @@
+# Interface Design for Testability
+
+Good interfaces make testing natural:
+
+1. **Accept dependencies, don't create them**
+
+   ```typescript
+   // Testable
+   function processOrder(order, paymentGateway) {}
+
+   // Hard to test
+   function processOrder(order) {
+     const gateway = new StripeGateway();
+   }
+   ```
+
+2. **Return results, don't produce side effects**
+
+   ```typescript
+   // Testable
+   function calculateDiscount(cart): Discount {}
+
+   // Hard to test
+   function applyDiscount(cart): void {
+     cart.total -= discount;
+   }
+   ```
+
+3. **Small surface area**
+   - Fewer methods = fewer tests needed
+   - Fewer params = simpler test setup

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

@@ -0,0 +1,59 @@
+# When to Mock
+
+Mock at **system boundaries** only:
+
+- External APIs (payment, email, etc.)
+- Databases (sometimes - prefer test DB)
+- Time/randomness
+- File system (sometimes)
+
+Don't mock:
+
+- Your own classes/modules
+- Internal collaborators
+- Anything you control
+
+## Designing for Mockability
+
+At system boundaries, design interfaces that are easy to mock:
+
+**1. Use dependency injection**
+
+Pass external dependencies in rather than creating them internally:
+
+```typescript
+// Easy to mock
+function processPayment(order, paymentClient) {
+  return paymentClient.charge(order.total);
+}
+
+// Hard to mock
+function processPayment(order) {
+  const client = new StripeClient(process.env.STRIPE_KEY);
+  return client.charge(order.total);
+}
+```
+
+**2. Prefer SDK-style interfaces over generic fetchers**
+
+Create specific functions for each external operation instead of one generic function with conditional logic:
+
+```typescript
+// GOOD: Each function is independently mockable
+const api = {
+  getUser: (id) => fetch(`/users/${id}`),
+  getOrders: (userId) => fetch(`/users/${userId}/orders`),
+  createOrder: (data) => fetch('/orders', { method: 'POST', body: data }),
+};
+
+// BAD: Mocking requires conditional logic inside the mock
+const api = {
+  fetch: (endpoint, options) => fetch(endpoint, options),
+};
+```
+
+The SDK approach means:
+- Each mock returns one specific shape
+- No conditional logic in test setup
+- Easier to see which endpoints a test exercises
+- Type safety per endpoint

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

@@ -0,0 +1,10 @@
+# Refactor Candidates
+
+After TDD cycle, look for:
+
+- **Duplication** → Extract function/class
+- **Long methods** → Break into private helpers (keep tests on public interface)
+- **Shallow modules** → Combine or deepen
+- **Feature envy** → Move logic to where data lives
+- **Primitive obsession** → Introduce value objects
+- **Existing code** the new code reveals as problematic

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

@@ -0,0 +1,61 @@
+# Good and Bad Tests
+
+## Good Tests
+
+**Integration-style**: Test through real interfaces, not mocks of internal parts.
+
+```typescript
+// GOOD: Tests observable behavior
+test("user can checkout with valid cart", async () => {
+  const cart = createCart();
+  cart.add(product);
+  const result = await checkout(cart, paymentMethod);
+  expect(result.status).toBe("confirmed");
+});
+```
+
+Characteristics:
+
+- Tests behavior users/callers care about
+- Uses public API only
+- Survives internal refactors
+- Describes WHAT, not HOW
+- One logical assertion per test
+
+## Bad Tests
+
+**Implementation-detail tests**: Coupled to internal structure.
+
+```typescript
+// BAD: Tests implementation details
+test("checkout calls paymentService.process", async () => {
+  const mockPayment = jest.mock(paymentService);
+  await checkout(cart, payment);
+  expect(mockPayment.process).toHaveBeenCalledWith(cart.total);
+});
+```
+
+Red flags:
+
+- Mocking internal collaborators
+- Testing private methods
+- Asserting on call counts/order
+- Test breaks when refactoring without behavior change
+- Test name describes HOW not WHAT
+- Verifying through external means instead of interface
+
+```typescript
+// BAD: Bypasses interface to verify
+test("createUser saves to database", async () => {
+  await createUser({ name: "Alice" });
+  const row = await db.query("SELECT * FROM users WHERE name = ?", ["Alice"]);
+  expect(row).toBeDefined();
+});
+
+// GOOD: Verifies through interface
+test("createUser makes user retrievable", async () => {
+  const user = await createUser({ name: "Alice" });
+  const retrieved = await getUser(user.id);
+  expect(retrieved.name).toBe("Alice");
+});
+```

plugins/bin/.apm/skills/triage/AGENT-BRIEF.md

@@ -0,0 +1,168 @@
+# 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.
+
+## Principles
+
+### Durability over precision
+
+The issue may sit in `ready-for-agent` for days or weeks. The codebase will change in the meantime. Write the brief so it stays useful even as files are renamed, moved, or refactored.
+
+- **Do** describe interfaces, types, and behavioral contracts
+- **Do** name specific types, function signatures, or config shapes that the agent should look for or modify
+- **Don't** reference file paths — they go stale
+- **Don't** reference line numbers
+- **Don't** assume the current implementation structure will remain the same
+
+### Behavioral, not procedural
+
+Describe **what** the system should do, not **how** to implement it. The agent will explore the codebase fresh and make its own implementation decisions.
+
+- **Good:** "The `SkillConfig` type should accept an optional `schedule` field of type `CronExpression`"
+- **Bad:** "Open src/types/skill.ts and add a schedule field on line 42"
+- **Good:** "When a user runs `/triage` with no arguments, they should see a summary of issues needing attention"
+- **Bad:** "Add a switch statement in the main handler function"
+
+### Complete acceptance criteria
+
+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"
+- **Bad:** "Triage should work correctly"
+
+### Explicit scope boundaries
+
+State what is out of scope. This prevents the agent from gold-plating or making assumptions about adjacent features.
+
+## Template
+
+```markdown
+## Agent Brief
+
+**Category:** bug / enhancement
+**Summary:** one-line description of what needs to happen
+
+**Current behavior:**
+Describe what happens now. For bugs, this is the broken behavior.
+For enhancements, this is the status quo the feature builds on.
+
+**Desired behavior:**
+Describe what should happen after the agent's work is complete.
+Be specific about edge cases and error conditions.
+
+**Key interfaces:**
+- `TypeName` — what needs to change and why
+- `functionName()` return type — what it currently returns vs what it should return
+- Config shape — any new configuration options needed
+
+**Acceptance criteria:**
+- [ ] Specific, testable criterion 1
+- [ ] Specific, testable criterion 2
+- [ ] Specific, testable criterion 3
+
+**Out of scope:**
+- Thing that should NOT be changed or addressed in this issue
+- Adjacent feature that might seem related but is separate
+```
+
+## Examples
+
+### Good agent brief (bug)
+
+```markdown
+## Agent Brief
+
+**Category:** bug
+**Summary:** Skill description truncation drops mid-word, producing broken output
+
+**Current behavior:**
+When a skill description exceeds 1024 characters, it is truncated at exactly
+1024 characters regardless of word boundaries. This produces descriptions
+that end mid-word (e.g. "Use when the user wants to confi").
+
+**Desired behavior:**
+Truncation should break at the last word boundary before 1024 characters
+and append "..." to indicate truncation.
+
+**Key interfaces:**
+- The `SkillMetadata` type's `description` field — no type change needed,
+  but the validation/processing logic that populates it needs to respect
+  word boundaries
+- Any function that reads SKILL.md frontmatter and extracts the description
+
+**Acceptance criteria:**
+- [ ] Descriptions under 1024 chars are unchanged
+- [ ] Descriptions over 1024 chars are truncated at the last word boundary
+      before 1024 chars
+- [ ] Truncated descriptions end with "..."
+- [ ] The total length including "..." does not exceed 1024 chars
+
+**Out of scope:**
+- Changing the 1024 char limit itself
+- Multi-line description support
+```
+
+### Good agent brief (enhancement)
+
+```markdown
+## Agent Brief
+
+**Category:** enhancement
+**Summary:** Add `.out-of-scope/` directory support for tracking rejected feature requests
+
+**Current behavior:**
+When a feature request is rejected, the issue is closed with a `wontfix` label
+and a comment. There is no persistent record of the decision or reasoning.
+Future similar requests require the maintainer to recall or search for the
+prior discussion.
+
+**Desired behavior:**
+Rejected feature requests should be documented in `.out-of-scope/<concept>.md`
+files that capture the decision, reasoning, and links to all issues that
+requested the feature. When triaging new issues, these files should be
+checked for matches.
+
+**Key interfaces:**
+- Markdown file format in `.out-of-scope/` — each file should have a
+  `# Concept Name` heading, a `**Decision:**` line, a `**Reason:**` line,
+  and a `**Prior requests:**` list with issue links
+- The triage workflow should read all `.out-of-scope/*.md` files early
+  and match incoming issues against them by concept similarity
+
+**Acceptance criteria:**
+- [ ] Closing a feature as wontfix creates/updates a file in `.out-of-scope/`
+- [ ] The file includes the decision, reasoning, and link to the closed issue
+- [ ] If a matching `.out-of-scope/` file already exists, the new issue is
+      appended to its "Prior requests" list rather than creating a duplicate
+- [ ] During triage, existing `.out-of-scope/` files are checked and surfaced
+      when a new issue matches a prior rejection
+
+**Out of scope:**
+- Automated matching (human confirms the match)
+- Reopening previously rejected features
+- Bug reports (only enhancement rejections go to `.out-of-scope/`)
+```
+
+### Bad agent brief
+
+```markdown
+## Agent Brief
+
+**Summary:** Fix the triage bug
+
+**What to do:**
+The triage thing is broken. Look at the main file and fix it.
+The function around line 150 has the issue.
+
+**Files to change:**
+- src/triage/handler.ts (line 150)
+- src/types.ts (line 42)
+```
+
+This is bad because:
+- No category
+- Vague description ("the triage thing is broken")
+- References file paths and line numbers that will go stale
+- No acceptance criteria
+- No scope boundaries
+- No description of current vs desired behavior

plugins/bin/.apm/skills/triage/OUT-OF-SCOPE.md

@@ -0,0 +1,101 @@
+# Out-of-Scope Knowledge Base
+
+The `.out-of-scope/` directory in a repo stores persistent records of rejected feature requests. It serves two purposes:
+
+1. **Institutional memory** — why a feature was rejected, so the reasoning isn't lost when the issue is closed
+2. **Deduplication** — when a new issue comes in that matches a prior rejection, the skill can surface the previous decision instead of re-litigating it
+
+## Directory structure
+
+```
+.out-of-scope/
+├── dark-mode.md
+├── plugin-system.md
+└── graphql-api.md
+```
+
+One file per **concept**, not per issue. Multiple issues requesting the same thing are grouped under one file.
+
+## File format
+
+The file should be written in a relaxed, readable style — more like a short design document than a database entry. Use paragraphs, code samples, and examples to make the reasoning clear and useful to someone encountering it for the first time.
+
+```markdown
+# Dark Mode
+
+This project does not support dark mode or user-facing theming.
+
+## Why this is out of scope
+
+The rendering pipeline assumes a single color palette defined in
+`ThemeConfig`. Supporting multiple themes would require:
+
+- A theme context provider wrapping the entire component tree
+- Per-component theme-aware style resolution
+- A persistence layer for user theme preferences
+
+This is a significant architectural change that doesn't align with the
+project's focus on content authoring. Theming is a concern for downstream
+consumers who embed or redistribute the output.
+
+```ts
+// The current ThemeConfig interface is not designed for runtime switching:
+interface ThemeConfig {
+  colors: ColorPalette; // single palette, resolved at build time
+  fonts: FontStack;
+}
+```
+
+## Prior requests
+
+- #42 — "Add dark mode support"
+- #87 — "Night theme for accessibility"
+- #134 — "Dark theme option"
+```
+
+### Naming the file
+
+Use a short, descriptive kebab-case name for the concept: `dark-mode.md`, `plugin-system.md`, `graphql-api.md`. The name should be recognizable enough that someone browsing the directory understands what was rejected without opening the file.
+
+### Writing the reason
+
+The reason should be substantive — not "we don't want this" but why. Good reasons reference:
+
+- Project scope or philosophy ("This project focuses on X; theming is a downstream concern")
+- Technical constraints ("Supporting this would require Y, which conflicts with our Z architecture")
+- Strategic decisions ("We chose to use A instead of B because...")
+
+The reason should be durable. Avoid referencing temporary circumstances ("we're too busy right now") — those aren't real rejections, they're deferrals.
+
+## When to check `.out-of-scope/`
+
+During triage (Step 1: Gather context), read all files in `.out-of-scope/`. When evaluating a new issue:
+
+- Check if the request matches an existing out-of-scope concept
+- Matching is by concept similarity, not keyword — "night theme" matches `dark-mode.md`
+- If there's a match, surface it to the maintainer: "This is similar to `.out-of-scope/dark-mode.md` — we rejected this before because [reason]. Do you still feel the same way?"
+
+The maintainer may:
+
+- **Confirm** — the new issue gets added to the existing file's "Prior requests" list, then closed
+- **Reconsider** — the out-of-scope file gets deleted or updated, and the issue proceeds through normal triage
+- **Disagree** — the issues are related but distinct, proceed with normal triage
+
+## When to write to `.out-of-scope/`
+
+Only when an **enhancement** (not a bug) is rejected as `wontfix`. The flow:
+
+1. Maintainer decides a feature request is out of scope
+2. Check if a matching `.out-of-scope/` file already exists
+3. If yes: append the new issue to the "Prior requests" list
+4. If no: create a new file with the concept name, decision, reason, and first prior request
+5. Post a comment on the issue explaining the decision and mentioning the `.out-of-scope/` file
+6. Close the issue with the `wontfix` label
+
+## Updating or removing out-of-scope files
+
+If the maintainer changes their mind about a previously rejected concept:
+
+- Delete the `.out-of-scope/` file
+- The skill does not need to reopen old issues — they're historical records
+- The new issue that triggered the reconsideration proceeds through normal triage

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

@@ -0,0 +1,103 @@
+---
+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.
+---
+
+# Triage
+
+Move issues on the project issue tracker through a small state machine of triage roles.
+
+Every comment or issue posted to the issue tracker during triage **must** start with this disclaimer:
+
+```
+> *This was generated by AI during triage.*
+```
+
+## 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
+
+## Roles
+
+Two **category** roles:
+
+- `bug` — something is broken
+- `enhancement` — new feature or improvement
+
+Five **state** roles:
+
+- `needs-triage` — maintainer needs to evaluate
+- `needs-info` — waiting on reporter for more information
+- `ready-for-agent` — fully specified, ready for an AFK agent
+- `ready-for-human` — needs human implementation
+- `wontfix` — will not be actioned
+
+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.
+
+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.
+
+## Invocation
+
+The maintainer invokes `/triage` and describes what they want in natural language. Interpret the request and act. Examples:
+
+- "Show me anything that needs my attention"
+- "Let's look at #42"
+- "Move #42 to ready-for-agent"
+- "What's ready for agents to pick up?"
+
+## Show what needs attention
+
+Query the issue tracker and present three buckets, oldest first:
+
+1. **Unlabeled** — never triaged.
+2. **`needs-triage`** — evaluation in progress.
+3. **`needs-info` with reporter activity since the last triage notes** — needs re-evaluation.
+
+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.
+
+2. **Recommend.** Tell the maintainer your category and state recommendation with reasoning, plus a brief codebase summary relevant to the issue. Wait for direction.
+
+3. **Reproduce (bugs only).** Before any grilling, attempt reproduction: read the reporter's steps, trace the relevant code, run tests or commands. Report what happened — successful repro with code path, failed repro, or insufficient detail (a strong `needs-info` signal). A confirmed repro makes a much stronger agent brief.
+
+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-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)).
+   - `needs-triage` — apply the role. Optional comment if there's partial progress.
+
+## Quick state override
+
+If the maintainer says "move #42 to ready-for-agent", trust them and apply the role directly. Confirm what you're about to do (role changes, comment, close), then act. Skip grilling. If moving to `ready-for-agent` without a grilling session, ask whether they want to write an agent brief.
+
+## Needs-info template
+
+```markdown
+## Triage Notes
+
+**What we've established so far:**
+
+- point 1
+- point 2
+
+**What we still need from you (@reporter):**
+
+- question 1
+- question 2
+```
+
+Capture everything resolved during grilling under "established so far" so the work isn't lost. Questions must be specific and actionable, not "please provide more info".
+
+## Resuming a previous session
+
+If prior triage notes exist on the issue, read them, check whether the reporter has answered any outstanding questions, and present an updated picture before continuing. Don't re-ask resolved questions.

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

@@ -0,0 +1,103 @@
+---
+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"
+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:
+  category: implement
+source:
+  - repo: anthropics/skills
+    commit: f458cee31a7577a47ba0c9a101976fa599385174
+    files:
+      - skills/doc-coauthoring/SKILL.md  # Reader Testing stage, surgical-edit constraint, gap-check step
+    updated: 2026-05-17
+  - repo: mattpocock/skills
+    commit: e74f0061bb67222181640effa98c675bdb2fdaa7
+    files:
+      - skills/productivity/write-a-skill/SKILL.md  # trigger pattern, review checklist items
+    updated: 2026-05-17
+  - repo: bmad-code-org/BMAD-METHOD
+    commit: 71136bc6af77cbf507d3768494311d5b6ca95cc5
+    files:
+      - src/core-skills/bmad-advanced-elicitation/SKILL.md  # confirmation gate before applying changes
+    updated: 2026-05-17
+---
+
+## Role
+
+You are a technical writer that produces documentation by reading code and spec — you derive every claim from a source file or explicit user input and never invent behaviour.
+
+## When to use / When not to use
+
+**Use when:**
+- User wants to document a module, class, function, feature, CLI flag, API endpoint, config file, or README section
+- 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 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
+
+## Required inputs
+
+- Specific file(s) or module(s) to document, or enough description to propose candidates
+- Target audience: developer / user / contributor / internal
+- Documentation type: reference, guide, README section, inline comment, changelog entry
+
+## Constraints
+
+- Every claim must be traceable to a source file line, spec section, or explicit user statement — never invent behaviour
+- User must approve specific files before the skill reads them; skill may propose candidates but waits for approval
+- Stage skipping is allowed only with an explicit user request and a one-sentence logged reason
+- Show the full revised section before each confirmation gate — never gate on output the user has not seen
+- Never reprint the whole document; all edits are surgical
+- Produce a one-line delta summary after each refinement round
+- Reader Testing sub-agent receives only the finished doc and the question list — no source files
+- Write summary and overview sections last, after all detail sections are stable
+
+## Process
+
+1. **Identify scope.** User names specific files or sections. If not provided, propose candidates based on the description — wait for explicit approval before reading.
+
+2. **Read and extract.** Read approved files. Extract: public API surface, described behaviour, visible constraints, non-obvious invariants. Note what the code does NOT explain (caller intent, error handling rationale, non-obvious side effects).
+
+3. **Gap check.** Present extracted behaviour to the user. Ask them to fill only the gaps — what the code does not explain. Log any explicitly deferred gaps. If the user requests to skip this step, log the reason and proceed.
+
+4. **Draft section by section.** For each section: state the proposed content and its source (code line / spec section / user input). Show; confirm before moving to the next section.
+
+5. **Confirmation gate.** Before finalising any section, show the full revised section. Wait for explicit confirmation or correction — never apply changes the user has not seen.
+
+6. **Delta summary.** After each round of revisions: "Round N: changed [sections], added [X], removed [Y]."
+
+7. **Reader Testing.** Predict 5–10 questions a target reader would ask. Spawn a scoped sub-agent that receives only the finished doc and the questions — no source files. Report its answers. If any answers fail, loop back to step 4.
+
+8. **Finalise.** Write summary and overview sections last. Prompt the user to review the complete document before committing.
+
+## Output format
+
+- Markdown artifact with section headers; produced one section at a time — never as a single large dump
+- Delta summary after each refinement round: "Round N: [what changed]"
+- Reader Testing report: numbered question list with sub-agent answers
+- Final doc at the user-specified or conventionally appropriate path
+
+## Failure handling
+
+- Files not named and description too vague to propose candidates → ask for specific names before reading
+- 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`
+
+## Self-check
+
+- [ ] All claims traceable to a source file or explicit user input
+- [ ] No invented behaviour — unverifiable claims removed
+- [ ] User approved specific files before reading
+- [ ] Any stage skips logged with reason
+- [ ] Full revised section shown before each confirmation gate
+- [ ] Delta summary produced after each refinement round
+- [ ] Reader Testing completed with scoped sub-agent (doc + questions only)
+- [ ] Summary/overview written last
+- [ ] User prompted to review before committing

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

@@ -0,0 +1,7 @@
+---
+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
+---
+
+I don't know this area of code well. Go up a layer of abstraction. Give me a map of all the relevant modules and callers, using the project's domain glossary vocabulary.

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

@@ -1,12 +1,30 @@
 {
+  "name": "bin",
+  "version": "1.1.5",
+  "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",
+    "email": "defame1297@rkdr.net",
     "url": "https://git.dev.rkdr.net/Defame1297/"
   },
-  "description": "A place for things to be binned",
-  "displayName": "bin",
-  "keywords": [],
   "license": "MIT",
-  "name": "bin",
-  "version": "1.1.1"
+  "homepage": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/bin",
+  "repository": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/bin",
+  "keywords": [
+    "utility",
+    "diagnostics",
+    "prototyping",
+    "tdd",
+    "research"
+  ],
+  "mcpServers": {
+    "obsidian": {
+      "args": [
+        "@bitbonsai/mcpvault@0.15.0",
+        "docs/"
+      ],
+      "command": "npx",
+      "type": "stdio"
+    }
+  }
 }

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

@@ -0,0 +1,21 @@
+{
+  "name": "bin",
+  "version": "1.1.5",
+  "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",
+    "email": "defame1297@rkdr.net",
+    "url": "https://git.dev.rkdr.net/Defame1297/"
+  },
+  "license": "MIT",
+  "homepage": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/bin",
+  "repository": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/bin",
+  "keywords": [
+    "utility",
+    "diagnostics",
+    "prototyping",
+    "tdd",
+    "research"
+  ],
+  "mcpServers": ".mcp.json"
+}

plugins/bin/.mcp.json

@@ -2,7 +2,7 @@
   "mcpServers": {
     "obsidian": {
       "args": [
-        "@bitbonsai/mcpvault@latest",
+        "@bitbonsai/mcpvault@0.15.0",
         "docs/"
       ],
       "command": "npx",

plugins/bin/README.md

@@ -30,10 +30,14 @@ copilot plugin install ./plugins/bin
 
 ## Contents
 
-| Component   | Path                                                 | Description                                                   |
-| -------------| ------------------------------------------------------| ---------------------------------------------------------------|
-| Skills      | `skills/`                                            | Slash commands available after install                        |
-| Agents      | `agents/`                                            | Role-based agents (`.md` for Claude, `.agent.md` for Copilot) |
+| Component | Path | Description |
+|---|---|---|
+| Skills | `.apm/skills/` → `skills/` | Slash commands available after install |
+| MCP servers | `.mcp.json` | The `obsidian` server (`npx @bitbonsai/mcpvault@0.15.0 docs/`), hand-authored at the plugin root |
+
+`.apm/` is the authoring source; `skills/` is the generated mirror plugin hosts scan (ADR-0017). This plugin ships no agents. It is the only plugin here with a non-empty `.mcp.json`, which is why its compiled manifests are the only ones carrying an `mcpServers` block.
+
+The two compiled manifests get that block by different routes. `.claude-plugin/plugin.json` gets it from apm itself: `build_plugin_manifest`'s Claude branch calls `collect_mcp_servers`, which reads `.mcp.json`, sanitizes it, and inlines the resulting server objects. `.github/plugin/plugin.json` gets nothing from apm — the Copilot branch drops the field — so `scripts/sync-plugin-content.sh`'s `reinject_mcp_servers()` puts it back, as the **string `".mcp.json"`** rather than the resolved objects. Copilot's manifest schema types the field as "string or object — MCP server config path or inline definitions", and a path reference cannot carry a credential into a committed manifest. See ADR-0017's `mcpServers` amendment.
 
 ## Author
 

plugins/bin/apm.yml

@@ -0,0 +1,35 @@
+name: bin
+version: 1.1.5
+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
+  email: defame1297@rkdr.net
+  url: https://git.dev.rkdr.net/Defame1297/
+license: MIT
+homepage: https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/bin
+repository: https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/bin
+keywords:
+  - utility
+  - diagnostics
+  - prototyping
+  - tdd
+  - research
+
+# Constrains what .apm/ may contain: instructions, skill, hybrid, or prompts
+type: skill
+
+# Which agent platforms to deploy to.
+# Resolution order: --target flag > this field > auto-detect from filesystem.
+# Accepted values: agent-skills, antigravity, claude, codex, copilot, cursor, gemini, grok-build, kiro, opencode, windsurf
+targets:
+  - claude
+  - copilot
+  - codex
+
+dependencies:
+  apm: []
+  mcp: []
+includes: auto
+devDependencies:
+  apm: []
+scripts: {}

plugins/bin/plugin.json

@@ -1,15 +0,0 @@
-{
-  "author": {
-    "email": "defame1297@rkdr.net",
-    "name": "Defame1297"
-  },
-  "description": "A place for things to be binned",
-  "keywords": [],
-  "license": "MIT",
-  "mcpServers": ".mcp.json",
-  "name": "bin",
-  "skills": [
-    "skills/"
-  ],
-  "version": "1.1.1"
-}

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

@@ -0,0 +1,35 @@
+# 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

@@ -0,0 +1,68 @@
+---
+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.
+allowed-tools: Bash Read
+metadata:
+  category: docs
+  source_keys:
+    - agents-md-official
+    - context7-websites-agents-md
+    - context7-agentsmd-agents-md
+    - governance-secrets-hard-prohibition
+  version: "0.1.1"
+---
+
+## 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.
+- 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
+
+```bash
+bash scripts/validate-secrets.sh <repo-root>
+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.
+
+## Step 2 — Report
+
+Open with a coverage line:
+
+```text
+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.

plugins/core/.apm/skills/agentsmd-audit/references/sources.md

@@ -0,0 +1,33 @@
+# Sources
+
+## agents-md-official
+
+- **URL:** https://agents.md/
+- **Description:** Official agents.md website — format spec, common-sections checklist, precedence rules (nearest-file-wins, no merge across files), monorepo nesting patterns
+- **Research doc:** plugins/core/docs/research/docs/agentsmd/sources.md
+- **Contributing files:** SKILL.md
+- **Status:** `extracted`
+
+## context7-websites-agents-md
+
+- **URL:** context7:/websites/agents_md
+- **Description:** Context7 index of the official agents.md website — overview, governance, cross-tool compatibility, configuration examples
+- **Research doc:** plugins/core/docs/research/docs/agentsmd/sources.md
+- **Contributing files:** SKILL.md
+- **Status:** `extracted`
+
+## context7-agentsmd-agents-md
+
+- **URL:** context7:/agentsmd/agents.md
+- **Description:** Context7 index of the agentsmd/agents.md repository — format spec, nested monorepo patterns, file structure examples
+- **Research doc:** plugins/core/docs/research/docs/agentsmd/sources.md
+- **Contributing files:** SKILL.md
+- **Status:** `extracted`
+
+## governance-secrets-hard-prohibition
+
+- **URL:** (org convention — not a plugin research corpus entry)
+- **Description:** Hard prohibition on placing secrets, API keys, tokens, or credentials in code, config, prompts, or any output. Grounds the secrets/credentials check in `scripts/validate-secrets.sh` and Step 1 of SKILL.md — AGENTS.md is committed content, so an embedded real secret is a hard-prohibition violation, not a style nit.
+- **Research doc:** core/instructions/governance.md (org convention file, not a plugin research corpus entry; content is inlined here since plugins must be self-contained and this file may not exist wherever the plugin is installed)
+- **Contributing files:** SKILL.md
+- **Status:** `extracted`

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

@@ -0,0 +1,11 @@
+# scripts/
+
+Deterministic validators this skill shells out to instead of relying on LLM judgment for mechanical checks.
+
+| File | Purpose |
+|------|---------|
+| `validate-secrets.sh` | Scans every AGENTS.md file (root + nested) for embedded secrets, API keys, tokens, and connection strings |
+| `validate-structure.sh` | Checks for empty/placeholder content, the common-sections checklist, and nested-vs-root duplication |
+| `validate-drift.sh` | Resolves referenced npm/make commands and file paths against the actual repo state |
+
+All three take a single `<repo-root>` argument, print `FAIL`/`INFO`/`SUGGESTION` findings to stdout, and exit non-zero only on FAIL.

plugins/core/.apm/skills/agentsmd-audit/scripts/validate-drift.sh

@@ -0,0 +1,137 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+usage() {
+  cat <<EOF
+Usage: validate-drift.sh <repo-root>
+
+Check every AGENTS.md file in a repo (root and nested) for drift: package
+manager scripts and file paths referenced in the text that no longer exist
+in the repo. Catches the failure mode that matters most in practice — an
+agent running a documented command that was renamed or deleted.
+
+Arguments:
+  repo-root  Path to the repository root to scan.
+
+Exit codes:
+  0  No FAIL findings (INFO may still be printed, e.g. no package.json found)
+  1  One or more FAIL findings
+EOF
+}
+
+if [[ "${1:-}" == "--help" || "${1:-}" == "-h" ]]; then
+  usage
+  exit 0
+fi
+
+if [[ $# -lt 1 ]]; then
+  echo "Error: repo-root is required." >&2
+  echo "" >&2
+  usage >&2
+  exit 1
+fi
+
+python3 -u - "$1" <<'PYTHON'
+import sys
+import os
+import re
+import json
+
+repo_root = os.path.abspath(sys.argv[1])
+if not os.path.isdir(repo_root):
+    print(f"Error: '{repo_root}' is not a directory.", file=sys.stderr)
+    sys.exit(1)
+
+EXCLUDE_DIRS = {".git", "node_modules", "vendor", ".venv", "venv", "dist", "build"}
+
+def find_agents_md(root):
+    results = []
+    for dirpath, dirnames, filenames in os.walk(root):
+        dirnames[:] = [d for d in dirnames if d not in EXCLUDE_DIRS and not d.startswith(".")]
+        for fname in filenames:
+            if fname == "AGENTS.md":
+                results.append(os.path.join(dirpath, fname))
+    return sorted(results)
+
+def load_package_scripts(root):
+    pkg_path = os.path.join(root, "package.json")
+    if not os.path.isfile(pkg_path):
+        return None
+    try:
+        with open(pkg_path, encoding="utf-8") as f:
+            data = json.load(f)
+    except (json.JSONDecodeError, OSError):
+        return None
+    return set(data.get("scripts", {}).keys())
+
+def load_make_targets(root):
+    make_path = os.path.join(root, "Makefile")
+    if not os.path.isfile(make_path):
+        return None
+    with open(make_path, encoding="utf-8", errors="replace") as f:
+        content = f.read()
+    return set(re.findall(r'(?m)^([a-zA-Z0-9_-]+)\s*:(?!=)', content))
+
+NPM_RUN_RE = re.compile(r'\b(?:npm|pnpm|yarn)\s+run\s+([a-zA-Z0-9:_-]+)')
+MAKE_RE = re.compile(r'\bmake\s+([a-zA-Z0-9_-]+)')
+
+# Backticked relative file paths, e.g. `scripts/bootstrap.sh`, `src/index.ts`.
+# Requires a path separator and file extension to avoid matching bare commands/words.
+PATH_RE = re.compile(r'`([A-Za-z0-9_.\-]+(?:/[A-Za-z0-9_.\-]+)+\.[A-Za-z0-9]+)`')
+
+has_fail = False
+
+package_scripts = load_package_scripts(repo_root)
+make_targets = load_make_targets(repo_root)
+
+for fpath in find_agents_md(repo_root):
+    rel = os.path.relpath(fpath, repo_root)
+    with open(fpath, encoding="utf-8", errors="replace") as f:
+        content = f.read()
+
+    for m in NPM_RUN_RE.finditer(content):
+        script_name = m.group(1)
+        if package_scripts is None:
+            print(f"INFO  Cannot verify referenced script '{script_name}' — {rel}")
+            print(f"      Note: AGENTS.md references an npm/pnpm/yarn script, but no package.json was found at the repo root to check it against.")
+            print()
+        elif script_name not in package_scripts:
+            has_fail = True
+            print(f"FAIL  Referenced script '{script_name}' not found in package.json — {rel}")
+            print(f"      Why: AGENTS.md tells agents to run '{script_name}', but package.json has no matching \"scripts\" entry — the command will fail.")
+            print(f"      Fix: Update AGENTS.md to reference an existing script, or add '{script_name}' to package.json's scripts.")
+            print()
+
+    for m in MAKE_RE.finditer(content):
+        target_name = m.group(1)
+        if make_targets is None:
+            print(f"INFO  Cannot verify referenced make target '{target_name}' — {rel}")
+            print(f"      Note: AGENTS.md references a make target, but no Makefile was found at the repo root to check it against.")
+            print()
+        elif target_name not in make_targets:
+            has_fail = True
+            print(f"FAIL  Referenced make target '{target_name}' not found in Makefile — {rel}")
+            print(f"      Why: AGENTS.md tells agents to run 'make {target_name}', but the Makefile has no matching target — the command will fail.")
+            print(f"      Fix: Update AGENTS.md to reference an existing target, or add '{target_name}' to the Makefile.")
+            print()
+
+    file_dir = os.path.dirname(fpath)
+    for m in PATH_RE.finditer(content):
+        candidate = m.group(1)
+        resolved = (
+            os.path.isfile(os.path.join(repo_root, candidate))
+            or os.path.isfile(os.path.join(file_dir, candidate))
+            or os.path.isdir(os.path.join(repo_root, candidate))
+            or os.path.isdir(os.path.join(file_dir, candidate))
+        )
+        if not resolved:
+            has_fail = True
+            print(f"FAIL  Referenced path '{candidate}' does not exist — {rel}")
+            print(f"      Why: AGENTS.md points agents to '{candidate}', but it isn't present in the repo (checked relative to repo root and to the AGENTS.md's own directory).")
+            print(f"      Fix: Update AGENTS.md to reference the correct path, or restore/create '{candidate}'.")
+            print()
+
+if has_fail:
+    sys.exit(1)
+sys.exit(0)
+PYTHON

plugins/core/.apm/skills/agentsmd-audit/scripts/validate-secrets.sh

@@ -0,0 +1,120 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+usage() {
+  cat <<EOF
+Usage: validate-secrets.sh <repo-root>
+
+Scan every AGENTS.md file in a repo (root and nested) for embedded secrets,
+API keys, tokens, or connection strings. AGENTS.md is committed content —
+real credentials in it are a hard-prohibition violation, not a style nit.
+Placeholders (<your-key>, \$ENV_VAR, YOUR_TOKEN_HERE, example.com, etc.) are
+not flagged.
+
+Arguments:
+  repo-root  Path to the repository root to scan.
+
+Exit codes:
+  0  No findings
+  1  One or more FAIL findings
+EOF
+}
+
+if [[ "${1:-}" == "--help" || "${1:-}" == "-h" ]]; then
+  usage
+  exit 0
+fi
+
+if [[ $# -lt 1 ]]; then
+  echo "Error: repo-root is required." >&2
+  echo "" >&2
+  usage >&2
+  exit 1
+fi
+
+python3 -u - "$1" <<'PYTHON'
+import sys
+import os
+import re
+
+repo_root = os.path.abspath(sys.argv[1])
+if not os.path.isdir(repo_root):
+    print(f"Error: '{repo_root}' is not a directory.", file=sys.stderr)
+    sys.exit(1)
+
+EXCLUDE_DIRS = {".git", "node_modules", "vendor", ".venv", "venv", "dist", "build"}
+
+def find_agents_md(root):
+    results = []
+    for dirpath, dirnames, filenames in os.walk(root):
+        dirnames[:] = [d for d in dirnames if d not in EXCLUDE_DIRS and not d.startswith(".")]
+        for fname in filenames:
+            if fname == "AGENTS.md":
+                results.append(os.path.join(dirpath, fname))
+    return sorted(results)
+
+PLACEHOLDER_RE = re.compile(
+    r'(?i)(your[_-]|my[_-]|example|xxx+|placeholder|changeme|<[^>]+>|\$\{|\$[A-Z_][A-Z0-9_]*|\.\.\.|redacted)'
+)
+
+PATTERNS = [
+    ("AWS access key ID", re.compile(r'AKIA[0-9A-Z]{16}')),
+    ("Private key block", re.compile(r'-----BEGIN [A-Z ]*PRIVATE KEY-----')),
+    ("GitHub token", re.compile(r'gh[pousr]_[A-Za-z0-9]{36,}')),
+    ("Slack token", re.compile(r'xox[baprs]-[A-Za-z0-9-]{10,}')),
+    ("GitLab token", re.compile(r'glpat-[A-Za-z0-9_-]{20,}')),
+    ("Generic API-style secret token", re.compile(r'\bsk-[A-Za-z0-9]{20,}\b')),
+    (
+        "Credential-bearing connection string",
+        re.compile(r'[a-zA-Z][a-zA-Z0-9+.-]*://[^:@/\s]+:[^@/\s]+@[^\s\'"]+'),
+    ),
+    (
+        "Assigned secret/password/token literal",
+        re.compile(
+            r'(?i)\b(api[_-]?key|secret|token|password|passwd|pwd|access[_-]?key)\b'
+            r'\s*[:=]\s*[\'"]?([A-Za-z0-9+/_.\-]{12,})[\'"]?'
+        ),
+    ),
+]
+
+findings = []
+
+def emit_fail(desc, fpath, lineno, why, fix):
+    findings.append((desc, fpath, lineno, why, fix))
+
+for fpath in find_agents_md(repo_root):
+    rel = os.path.relpath(fpath, repo_root)
+    with open(fpath, encoding="utf-8", errors="replace") as f:
+        lines = f.readlines()
+    for i, line in enumerate(lines, start=1):
+        for label, pattern in PATTERNS:
+            m = pattern.search(line)
+            if not m:
+                continue
+            # Scope the placeholder allowlist to the matched secret-candidate
+            # substring only. Checking the whole line would let an unrelated
+            # placeholder-looking token elsewhere on the line (e.g. in a
+            # trailing comment) suppress detection of a real credential.
+            value = m.group(0)
+            if PLACEHOLDER_RE.search(value):
+                continue
+            emit_fail(
+                f"Possible {label}",
+                f"{rel}:{i}",
+                i,
+                "AGENTS.md is committed content; this line matches a real-looking credential pattern rather than a placeholder.",
+                "Remove the embedded credential and replace it with an environment variable reference or placeholder (e.g. $API_KEY, <your-token>).",
+            )
+            break
+
+if not findings:
+    sys.exit(0)
+
+for desc, fpath, _lineno, why, fix in findings:
+    print(f"FAIL  {desc} — {fpath}")
+    print(f"      Why: {why}")
+    print(f"      Fix: {fix}")
+    print()
+
+sys.exit(1)
+PYTHON

plugins/core/.apm/skills/agentsmd-audit/scripts/validate-structure.sh

@@ -0,0 +1,118 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+usage() {
+  cat <<EOF
+Usage: validate-structure.sh <repo-root>
+
+Check every AGENTS.md file in a repo (root and nested) for structural
+completeness against the agents.md spec's common-sections checklist
+(setup/build, code style, testing, security, commit/PR conventions).
+Missing individual sections are informational (not every repo needs every
+section) — only an empty or entirely unfilled file is a hard failure.
+
+Arguments:
+  repo-root  Path to the repository root to scan.
+
+Exit codes:
+  0  No FAIL findings (INFO/SUGGESTION may still be printed)
+  1  One or more FAIL findings
+EOF
+}
+
+if [[ "${1:-}" == "--help" || "${1:-}" == "-h" ]]; then
+  usage
+  exit 0
+fi
+
+if [[ $# -lt 1 ]]; then
+  echo "Error: repo-root is required." >&2
+  echo "" >&2
+  usage >&2
+  exit 1
+fi
+
+python3 -u - "$1" <<'PYTHON'
+import sys
+import os
+import re
+
+PLACEHOLDER_RE = re.compile(r'(?i)FILL IN:|TODO:\s*write|lorem ipsum')
+
+COMMON_SECTIONS = [
+    ("setup/build commands", re.compile(r'(?im)^#{1,3}\s*(setup|install|build|getting started)')),
+    ("code style", re.compile(r'(?im)^#{1,3}\s*(code style|style guide|conventions)')),
+    ("testing instructions", re.compile(r'(?im)^#{1,3}\s*(test|testing)')),
+    ("security considerations", re.compile(r'(?im)^#{1,3}\s*security')),
+    ("commit/PR conventions", re.compile(r'(?im)^#{1,3}\s*(commit|pr|pull request)')),
+]
+
+repo_root = os.path.abspath(sys.argv[1])
+if not os.path.isdir(repo_root):
+    print(f"Error: '{repo_root}' is not a directory.", file=sys.stderr)
+    sys.exit(1)
+
+EXCLUDE_DIRS = {".git", "node_modules", "vendor", ".venv", "venv", "dist", "build"}
+
+def find_agents_md(root):
+    results = []
+    for dirpath, dirnames, filenames in os.walk(root):
+        dirnames[:] = [d for d in dirnames if d not in EXCLUDE_DIRS and not d.startswith(".")]
+        for fname in filenames:
+            if fname == "AGENTS.md":
+                results.append(os.path.join(dirpath, fname))
+    return sorted(results)
+
+has_fail = False
+file_contents = {}  # rel path -> content, for the duplication pass below
+
+for fpath in find_agents_md(repo_root):
+    rel = os.path.relpath(fpath, repo_root)
+    with open(fpath, encoding="utf-8", errors="replace") as f:
+        content = f.read()
+    file_contents[rel] = content
+
+    if not content.strip():
+        has_fail = True
+        print(f"FAIL  AGENTS.md is empty — {rel}")
+        print("      Why: An empty file provides no instructions and gives agents nothing to act on.")
+        print("      Fix: Add at least a project overview and setup/test commands, per the agents.md common-sections checklist.")
+        print()
+        continue
+
+    if PLACEHOLDER_RE.search(content):
+        has_fail = True
+        print(f"FAIL  Unfilled placeholder content — {rel}")
+        print("      Why: A 'FILL IN:' or template stub left in place means the file has no repo-specific instructions yet.")
+        print("      Fix: Replace the placeholder with real, repo-specific content.")
+        print()
+        continue
+
+    for label, pattern in COMMON_SECTIONS:
+        if not pattern.search(content):
+            print(f"INFO  No {label} section — {rel}")
+            print(f"      Note: The agents.md common-sections checklist includes {label}; not every repo needs every section, but confirm this omission is deliberate.")
+            print()
+
+# --- Nested-vs-root duplication check ---
+root_content = file_contents.get("AGENTS.md")
+if root_content:
+    root_lines = {ln.strip() for ln in root_content.splitlines() if ln.strip()}
+    for rel, content in file_contents.items():
+        if rel == "AGENTS.md":
+            continue
+        nested_lines = [ln.strip() for ln in content.splitlines() if ln.strip()]
+        if not nested_lines:
+            continue
+        overlap = sum(1 for ln in nested_lines if ln in root_lines)
+        ratio = overlap / len(nested_lines)
+        if ratio >= 0.7:
+            print(f"SUGGESTION  Nested AGENTS.md largely duplicates the root file — {rel}")
+            print(f"      Why: {ratio:.0%} of this file's content lines already appear in the root AGENTS.md; per the spec's nearest-file-wins precedence, nested files don't inherit from the root, but they also shouldn't just restate it.")
+            print(f"      Fix: Trim {rel} down to only what's specific to this package/directory.")
+            print()
+
+if has_fail:
+    sys.exit(1)
+sys.exit(0)
+PYTHON

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

@@ -18,7 +18,7 @@ git clone https://github.com/bats-core/bats-assert tests/test_helper/bats-assert
 Run all tests for this skill (from the repo root):
 
 ```bash
-bats plugins/core/skills/agentsmd-audit/tests/
+bats plugins/core/.apm/skills/agentsmd-audit/tests/
 ```
 
 ## Files

plugins/core/.apm/skills/agentsmd-audit/tests/validate-drift.bats

@@ -1,7 +1,7 @@
 #!/usr/bin/env bats
 
 setup() {
-    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../" && pwd)"
+    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../../" && pwd)"
     load "$REPO_ROOT/tests/test_helper/bats-support/load"
     load "$REPO_ROOT/tests/test_helper/bats-assert/load"
 

plugins/core/.apm/skills/agentsmd-audit/tests/validate-secrets.bats

@@ -1,7 +1,7 @@
 #!/usr/bin/env bats
 
 setup() {
-    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../" && pwd)"
+    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../../" && pwd)"
     load "$REPO_ROOT/tests/test_helper/bats-support/load"
     load "$REPO_ROOT/tests/test_helper/bats-assert/load"
 
@@ -52,6 +52,19 @@ EOF
     assert_output --partial "connection string"
 }
 
+@test "still catches a real secret when a placeholder token sits elsewhere on the same line" {
+    cat > "$TMPDIR/AGENTS.md" <<'EOF'
+# AGENTS.md
+
+## Setup
+- AWS_ACCESS_KEY_ID=AKIAABCDEFGHIJKLMNOP # see your-token-here for an example, gitleaks:allow (synthetic fixture — this test verifies the placeholder allowlist is scoped to the matched value, not the whole line)
+EOF
+    run bash "$SCRIPT" "$TMPDIR"
+    assert_failure
+    assert_output --partial "AWS access key ID"
+    assert_output --partial "AGENTS.md:4"
+}
+
 @test "detects secrets in a nested AGENTS.md, not just root" {
     mkdir -p "$TMPDIR/packages/api"
     cat > "$TMPDIR/AGENTS.md" <<'EOF'

plugins/core/.apm/skills/agentsmd-audit/tests/validate-structure.bats

@@ -1,7 +1,7 @@
 #!/usr/bin/env bats
 
 setup() {
-    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../" && pwd)"
+    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../../" && pwd)"
     load "$REPO_ROOT/tests/test_helper/bats-support/load"
     load "$REPO_ROOT/tests/test_helper/bats-assert/load"
 

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

@@ -0,0 +1,27 @@
+# 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

@@ -0,0 +1,56 @@
+---
+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.
+allowed-tools: Bash Read Write Edit
+metadata:
+  category: docs
+  source_keys:
+    - agents-md-official
+    - context7-websites-agents-md
+    - context7-agentsmd-agents-md
+  version: "0.1.1"
+---
+
+## 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.
+
+## Step 1 — Explore the target repo
+
+Before writing anything, gather real facts: package manager and scripts (`package.json`, `pyproject.toml`, `Cargo.toml`, etc.), a `Makefile` or task runner, CI config (`.github/workflows/`, etc.) for the commands it actually runs, linter/formatter config files, and any existing docs (`README.md`, existing `AGENTS.md`) describing conventions. Note whether any subdirectory looks like its own package with a different stack.
+
+## 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.
+- 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.
+
+## 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.
+
+## 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.

plugins/core/.apm/skills/agentsmd-author/references/content-guide.md

@@ -0,0 +1,118 @@
+---
+source_keys:
+  - agents-md-official
+  - context7-websites-agents-md
+  - context7-agentsmd-agents-md
+---
+
+# What good AGENTS.md content looks like
+
+AGENTS.md has no required schema — there's no field to fill in, only sections that either
+earn their place or don't. Agents treat this file as a set of live directives, not
+documentation: they will actually run the commands it lists and fix failures before
+finishing a task. That means a wrong or stale line is worse than a missing one. Verify
+every command against something real in the repo before writing it down.
+
+## Section-by-section guidance
+
+**Setup / build commands** — the install and dev-server commands, exactly as they appear
+in `package.json` scripts, a `Makefile`, or a `Cargo.toml`/`pyproject.toml` equivalent. One
+line per command, each with a one-clause note on what it does if the name alone isn't
+obvious. Skip this section if there's genuinely nothing beyond "clone and run" — don't pad
+it with a restated `git clone`.
+
+**Code style** — only conventions that aren't already enforced by a linter/formatter config
+the agent will pick up on its own (a `.eslintrc`, `rustfmt.toml`, etc. speaks for itself).
+Write down the conventions that live only in people's heads: naming patterns, module
+boundaries, patterns to avoid, anything a linter can't catch. If the repo has no
+undocumented conventions beyond what tooling enforces, skip this section.
+
+**Testing instructions** — the exact command(s) to run the suite, where to find
+per-package or per-workflow test configuration (e.g. `.github/workflows/`), and any
+non-obvious requirement (a service that must be running, an env var that must be set).
+State plainly that the agent should run tests before considering a change done and fix
+failures — don't leave this implicit.
+
+**Security considerations** — only repo-specific hazards: a data-handling boundary, a
+credential pattern to never hardcode, a destructive command that needs a confirmation
+step. Do not restate general security advice ("don't commit secrets") that any agent
+already assumes — that's padding, not a directive.
+
+**Commit / PR conventions** — the title/format convention if one exists (e.g. a
+Conventional Commits type prefix, a ticket-number requirement), and any check that must
+pass before a PR is opened (lint, test, type-check). Point at the real command, not
+"make sure it passes."
+
+**Dev environment tips** — the handful of things that save real time and are easy to miss:
+how to jump to a specific package in a monorepo without `ls`-ing around, how to register a
+new package so the toolchain sees it, where to look up a canonical name/id. This section
+is for genuine friction points observed in this repo, not generic advice.
+
+## What separates useful content from padding
+
+A useful section names a real file, command, or path that exists in this repo right now.
+A padded section could be pasted into any repo unchanged and still "make sense" — that's
+the tell. If a sentence would read the same in a different codebase, it doesn't belong.
+Prefer four accurate lines over twelve generic ones.
+
+## Worked example (minimal project)
+
+```markdown
+# AGENTS.md
+
+## Setup commands
+- Install deps: `pnpm install`
+- Start dev server: `pnpm dev`
+- Run tests: `pnpm test`
+
+## Code style
+- TypeScript strict mode
+- Single quotes, no semicolons
+- Use functional patterns where possible
+
+## Dev environment tips
+- Use `pnpm dlx turbo run where <project_name>` to jump to a package instead of scanning with `ls`.
+- Run `pnpm install --filter <project_name>` to add the package to your workspace so Vite, ESLint, and TypeScript can see it.
+- Check the `name` field inside each package's `package.json` to confirm the right name.
+
+## Testing instructions
+- Find the CI plan in the `.github/workflows` folder.
+- Run `pnpm turbo run test --filter <project_name>` to run every check defined for that package.
+- From the package root you can just call `pnpm test`. The commit should pass all tests before you merge.
+- Fix any test or type errors until the whole suite is green.
+- Add or update tests for the code you change, even if nobody asked.
+
+## PR instructions
+- Title format: [<project_name>] <Title>
+- Always run `pnpm lint` and `pnpm test` before committing.
+```
+
+Every line above names a real command or path — that's the standard to hold this repo's
+version to, not the specific tooling shown (a Python/Cargo/Go repo's AGENTS.md should look
+nothing like this one in its specifics, only in how concrete each line is).
+
+## Monorepo / nested placement
+
+```
+my-monorepo/
+├── AGENTS.md              # Root-level: applies to the whole repo
+├── packages/
+│   ├── api/
+│   │   └── AGENTS.md      # API-specific instructions; overrides root for this package
+│   ├── web/
+│   │   └── AGENTS.md      # Web app-specific instructions
+│   └── shared/
+│       └── AGENTS.md      # Shared library instructions
+```
+
+Precedence rule: the file nearest the edited path wins. Nested files are **not** merged
+with the root file — an agent editing inside `packages/api/` reads only
+`packages/api/AGENTS.md`, never the root file in addition. Consequences:
+
+- A nested file must stand alone. Don't write "also see the root file" — write what the
+  agent needs, full stop.
+- Don't duplicate root content in a nested file "just in case." If a nested file repeats
+  root-level setup instructions verbatim, that's a sign it shouldn't exist as a separate
+  file at all — the subtree isn't actually different enough to warrant one.
+- Only create a nested file when the subtree has a genuinely different stack, build tool,
+  or convention than the root (see `SKILL.md` Step 2 for the placement decision itself).

plugins/core/.apm/skills/agentsmd-author/references/sources.md

@@ -0,0 +1,25 @@
+# Sources
+
+## agents-md-official
+
+- **URL:** https://agents.md/
+- **Description:** Official agents.md website — format spec, common-sections checklist, precedence rules (nearest-file-wins, no merge across files), monorepo nesting patterns
+- **Research doc:** plugins/core/docs/research/docs/agentsmd/sources.md
+- **Contributing files:** SKILL.md, references/content-guide.md
+- **Status:** `extracted`
+
+## context7-websites-agents-md
+
+- **URL:** context7:/websites/agents_md
+- **Description:** Context7 index of the official agents.md website — overview, governance, cross-tool compatibility, configuration examples
+- **Research doc:** plugins/core/docs/research/docs/agentsmd/sources.md
+- **Contributing files:** SKILL.md, references/content-guide.md
+- **Status:** `extracted`
+
+## context7-agentsmd-agents-md
+
+- **URL:** context7:/agentsmd/agents.md
+- **Description:** Context7 index of the agentsmd/agents.md repository — format spec, nested monorepo patterns, file structure examples
+- **Research doc:** plugins/core/docs/research/docs/agentsmd/sources.md
+- **Contributing files:** SKILL.md, references/content-guide.md
+- **Status:** `extracted`

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

@@ -0,0 +1,35 @@
+# 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

@@ -0,0 +1,54 @@
+---
+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.
+allowed-tools: Bash Read Edit Write
+metadata:
+  category: docs
+  source_keys:
+    - adr-0002-0003-two-tier-claude-md
+  version: "0.1.0"
+---
+
+## 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.
+
+## 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.
+
+## 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.
+
+## Step 3 — Self-validate
+
+Run the bundled check before finishing — this is the skill's own closeout gate; there is no separate paired audit skill for this concern:
+
+```bash
+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`.
+
+## Step 4 — Report
+
+State which file was converted, what was removed versus kept, and the validator's final result.

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

@@ -0,0 +1,9 @@
+# Sources
+
+## adr-0002-0003-two-tier-claude-md
+
+- **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
+- **Status:** `extracted`

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

@@ -0,0 +1,9 @@
+# scripts/
+
+Deterministic self-check this skill shells out to instead of relying on LLM judgment for a mechanical check.
+
+| 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 |
+
+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.

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

@@ -0,0 +1,141 @@
+#!/usr/bin/env bash
+set -euo pipefail
+
+usage() {
+  cat <<EOF
+Usage: validate-adapter.sh [--no-import-syntax] [--max-lines N] <adapter-file> <agents-md-file>
+
+Self-check gate for provider-adapter-author. Checks that a rewritten
+provider-specific instruction file (CLAUDE.md, .cursor/rules/*.mdc,
+copilot-instructions.md, etc.) is actually a thin adapter over AGENTS.md,
+not a duplicate copy of it.
+
+Arguments:
+  adapter-file     Path to the provider-specific file to check.
+  agents-md-file   Path to the AGENTS.md file it should defer to.
+
+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.
+  --max-lines N        Max non-blank lines allowed in the adapter file before
+                       it's considered no longer "thin". Default: 60.
+  --help, -h           Show this help and exit 0.
+
+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)
+EOF
+}
+
+NO_IMPORT_SYNTAX=0
+MAX_LINES=60
+ARGS=()
+
+while [[ $# -gt 0 ]]; do
+  case "$1" in
+    --help|-h)
+      usage
+      exit 0
+      ;;
+    --no-import-syntax)
+      NO_IMPORT_SYNTAX=1
+      shift
+      ;;
+    --max-lines)
+      MAX_LINES="${2:-}"
+      shift 2
+      ;;
+    *)
+      ARGS+=("$1")
+      shift
+      ;;
+  esac
+done
+
+if [[ ${#ARGS[@]} -lt 2 ]]; then
+  echo "Error: adapter-file and agents-md-file are required." >&2
+  echo "" >&2
+  usage >&2
+  exit 1
+fi
+
+python3 -u - "${ARGS[0]}" "${ARGS[1]}" "$NO_IMPORT_SYNTAX" "$MAX_LINES" <<'PYTHON'
+import sys
+import os
+import re
+
+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)
+
+if not os.path.isfile(adapter_path):
+    print(f"Error: '{adapter_path}' is not a file.", file=sys.stderr)
+    sys.exit(1)
+if not os.path.isfile(agents_md_path):
+    print(f"Error: '{agents_md_path}' is not a file.", file=sys.stderr)
+    sys.exit(1)
+
+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()
+
+has_fail = False
+
+if not adapter_content.strip():
+    print(f"FAIL  Adapter file is empty — {adapter_path}")
+    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)
+
+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)]
+
+if no_import_syntax:
+    has_reference = "AGENTS.md" in adapter_content
+else:
+    has_reference = bool(import_lines) or "AGENTS.md" in adapter_content
+
+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.\"")
+    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()
+
+# --- Duplication check ---
+non_import_lines = [ln for ln in lines if not IMPORT_RE.match(ln)]
+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()}
+
+if adapter_lines:
+    overlap = sum(1 for ln in adapter_lines if ln in agents_lines)
+    ratio = overlap / len(adapter_lines)
+    if ratio > 0.3:
+        has_fail = True
+        print(f"FAIL  Adapter duplicates AGENTS.md content — {adapter_path}")
+        print(f"      Why: {ratio:.0%} of the adapter's non-import lines already appear verbatim in AGENTS.md. A thin adapter should import shared content, not restate it.")
+        print("      Fix: Remove the duplicated lines and rely on the AGENTS.md import (or pointer) instead.")
+        print()
+
+# --- Size check ---
+non_blank_count = len([ln for ln in lines if ln.strip()])
+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()
+
+if has_fail:
+    sys.exit(1)
+sys.exit(0)
+PYTHON

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

@@ -18,7 +18,7 @@ git clone https://github.com/bats-core/bats-assert tests/test_helper/bats-assert
 Run all tests for this skill (from the repo root):
 
 ```bash
-bats plugins/core/skills/provider-adapter-author/tests/
+bats plugins/core/.apm/skills/provider-adapter-author/tests/
 ```
 
 ## Files

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

@@ -1,7 +1,7 @@
 #!/usr/bin/env bats
 
 setup() {
-    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../" && pwd)"
+    REPO_ROOT="$(cd "$BATS_TEST_DIRNAME/../../../../../../" && pwd)"
     load "$REPO_ROOT/tests/test_helper/bats-support/load"
     load "$REPO_ROOT/tests/test_helper/bats-assert/load"
 

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

@@ -1,18 +1,20 @@
 {
+  "name": "core",
+  "version": "1.1.1",
+  "description": "Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.",
   "author": {
     "name": "Defame1297",
+    "email": "defame1297@rkdr.net",
     "url": "https://git.dev.rkdr.net/Defame1297/"
   },
-  "description": "Cross-cutting utility skills for everyday AI-assisted coding \u2014 triage, diagnosis, architecture review, and session navigation.",
-  "displayName": "Core",
-  "keywords": [
-    "cross-cutting",
-    "triage",
-    "diagnose",
-    "architecture",
-    "debug"
-  ],
   "license": "MIT",
-  "name": "core",
-  "version": "1.1.0"
+  "homepage": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/core",
+  "repository": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/core",
+  "keywords": [
+    "agents-md",
+    "documentation",
+    "audit",
+    "provider-adapter",
+    "governance"
+  ]
 }

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

@@ -0,0 +1,20 @@
+{
+  "name": "core",
+  "version": "1.1.1",
+  "description": "Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.",
+  "author": {
+    "name": "Defame1297",
+    "email": "defame1297@rkdr.net",
+    "url": "https://git.dev.rkdr.net/Defame1297/"
+  },
+  "license": "MIT",
+  "homepage": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/core",
+  "repository": "https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/core",
+  "keywords": [
+    "agents-md",
+    "documentation",
+    "audit",
+    "provider-adapter",
+    "governance"
+  ]
+}

plugins/core/README.md

@@ -1,6 +1,6 @@
 # core
 
-Cross-cutting utility skills for everyday AI-assisted coding — triage, diagnosis, architecture review, and session navigation.
+Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.
 
 ## Install
 
@@ -32,7 +32,9 @@ copilot plugin install ./plugins/core
 
 | Component | Path | Description |
 |---|---|---|
-| Skills | `skills/` | Slash commands available after install |
+| Skills | `.apm/skills/` → `skills/` | Slash commands available after install |
+
+`.apm/` is the authoring source; `skills/` is the generated mirror plugin hosts scan (ADR-0017).
 
 ## Skills
 

plugins/core/apm.yml

@@ -0,0 +1,35 @@
+name: core
+version: 1.1.1
+description: Skills for authoring and auditing a repo's AGENTS.md and the provider adapter files that defer to it.
+author:
+  name: Defame1297
+  email: defame1297@rkdr.net
+  url: https://git.dev.rkdr.net/Defame1297/
+license: MIT
+homepage: https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/core
+repository: https://git.dev.rkdr.net/Defame1297/holocron/src/branch/main/plugins/core
+keywords:
+  - agents-md
+  - documentation
+  - audit
+  - provider-adapter
+  - governance
+
+# Constrains what .apm/ may contain: instructions, skill, hybrid, or prompts
+type: skill
+
+targets:
+  - claude
+  - copilot
+  - codex
+
+# "auto" publishes the authoritative local source layout, or list explicit
+# repo paths to define the complete publication set.
+includes: auto
+
+dependencies:
+  apm: []
+  mcp: []
+devDependencies:
+  apm: []
+scripts: {}

plugins/core/hooks.json

@@ -1,3 +0,0 @@
-{
-  "hooks": {}
-}

plugins/core/plugin.json

@@ -1,22 +0,0 @@
-{
-  "author": {
-    "email": "defame1297@rkdr.net",
-    "name": "Defame1297"
-  },
-  "description": "Cross-cutting utility skills for everyday AI-assisted coding \u2014 triage, diagnosis, architecture review, and session navigation.",
-  "hooks": "hooks.json",
-  "keywords": [
-    "cross-cutting",
-    "triage",
-    "diagnose",
-    "architecture",
-    "debug"
-  ],
-  "license": "MIT",
-  "mcpServers": ".mcp.json",
-  "name": "core",
-  "skills": [
-    "skills/"
-  ],
-  "version": "1.1.0"
-}

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

@@ -24,7 +24,12 @@ Provide the path to the repo root to audit when invoking.
 | `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` | Bats test dependency and run instructions |
-| `tests/validate-secrets.bats` | Bats test suite for `scripts/validate-secrets.sh` |
-| `tests/validate-structure.bats` | Bats test suite for `scripts/validate-structure.sh` |
-| `tests/validate-drift.bats` | Bats test suite for `scripts/validate-drift.sh` |
+| `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/scripts/validate-secrets.sh

@@ -87,14 +87,14 @@ for fpath in find_agents_md(repo_root):
     with open(fpath, encoding="utf-8", errors="replace") as f:
         lines = f.readlines()
     for i, line in enumerate(lines, start=1):
-        if PLACEHOLDER_RE.search(line):
-            continue
         for label, pattern in PATTERNS:
             m = pattern.search(line)
             if not m:
                 continue
-            # Re-check placeholder allowlist against just the matched value, in case
-            # the placeholder marker sits outside the regex's own match span.
+            # Scope the placeholder allowlist to the matched secret-candidate
+            # substring only. Checking the whole line would let an unrelated
+            # placeholder-looking token elsewhere on the line (e.g. in a
+            # trailing comment) suppress detection of a real credential.
             value = m.group(0)
             if PLACEHOLDER_RE.search(value):
                 continue

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

@@ -26,5 +26,10 @@ Provide the path to the provider-specific file to convert (and the target repo r
 | `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` | Bats test dependency and run instructions |
-| `tests/validate-adapter.bats` | Bats test suite for `scripts/validate-adapter.sh` |
+| `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/git/.apm/agents/git-orchestrate.agent.md

@@ -3,8 +3,6 @@ name: git-orchestrate
 
 description: Orchestrates git workflow operations for other agents. Invoke when a caller needs a multi-step or destructive git operation (rebase, force-push, branch deletion) coordinated across domain skills with safety gates, session context, and structured results.
 
-tools: Bash, Read, Edit
-
 source_keys:
   - context7-git-htmldocs
   - git-scm-docs
@@ -12,7 +10,6 @@ source_keys:
   - git-scm-submodule-docs
   - git-scm-remote-docs
   - conventional-commits-spec
-
 ---
 
 You are the orchestrator for the git plugin—a composable workflow dispatcher designed for other agents to invoke multi-step git operations reliably. Your one job is routing and safety-gating: you do not execute git logic yourself, you delegate to domain skills and enforce confirmation on destructive operations.

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

@@ -0,0 +1,22 @@
+# git-branches
+
+Manage the full lifecycle of git branches — create, switch, delete, rename, and track feature/hotfix/release branches under GitHub Flow or Gitflow.
+
+## What it does
+
+This skill handles branch operations within the git workflow suite. It creates branches following GitHub Flow or Gitflow conventions (configurable), switches and tracks branches, handles safe deletion with unmerged-work checks, and retrieves branch intent metadata for use by other skills (e.g., commit message context). It returns structured results suitable for agent composition.
+
+## Usage
+
+```
+/git-branches
+```
+
+Describe your branch task: create a feature/hotfix/release branch, switch, delete, rename, or track. The skill will determine the branching pattern (GitHub Flow or Gitflow) from config or repo state and handle safety checks for destructive operations.
+
+## Files
+
+| File | Purpose |
+|------|---------|
+| `SKILL.md` | Skill instructions for agents |
+| `references/sources.md` | Research sources backing the branching/gitflow guidance |

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

@@ -0,0 +1,112 @@
+---
+name: git-branches
+
+description: >
+  Use when managing the full lifecycle of git branches: create feature/hotfix/release branches
+  (gitflow, GitHub Flow, or custom patterns from config), switch, delete, rename, and track branches,
+  or retrieve branch intent metadata. Handles branch protection safety checks and returns structured
+  results for agent composition. Use even if the user doesn't explicitly mention branch names — they
+  may be asking about "fixing something" or "shipping a feature", which implicitly requires branch
+  management. Do not use when the user needs only commit operations (use git-commits) or history
+  inspection (use git-history).
+
+metadata:
+  category: git
+  source_keys:
+    - context7-git-htmldocs
+    - nvie-gitflow-post
+    - atlassian-gitflow-tutorial
+    - gitflow-cheatsheet
+---
+
+## Gotchas
+
+- **Branches are cheap; deletion is cheap but risky.** Deleting one requires checking if commits on it are reachable elsewhere; always confirm before deleting, as it may lose unmerged work.
+- **Uncommitted changes can block branch switches.** `git switch` aborts if local modifications conflict with the target branch. Offer to stash changes before switching when this happens, don't force a checkout.
+- **Tracking relationships matter for coordination.** Agents pushing on behalf of users should always set tracking (`-u origin <branch>`) so later pushes/pulls know the target. Without it, commands fail or target the wrong remote branch.
+- **Gitflow vs. GitHub Flow are not compatible.** Gitflow requires `develop` and `release/*` branches with `--no-ff` merges; GitHub Flow uses only `main` and feature branches with fast-forward. Read the repo's config or ask the orchestrator which pattern to use — don't guess.
+- **Naming collisions with tags.** A branch and tag can have the same name. Prefer `git switch` over `git checkout` for branch operations — verify which ref you're targeting with `git branch --list <name>` / `git tag --list <name>` if the name could be ambiguous, and disambiguate explicitly with `refs/heads/<name>` (branch) or `refs/tags/<name>` (tag) where a command accepts either.
+- **Never force-push `main` or `master`.** This is a hard refusal, not a confirmation gate — it applies even if the caller passes `confirm: true`. Deleting or renaming `main`/`master` in a way that would require a force-push to reconcile the remote (e.g. force-deleting and recreating it, or renaming it out from under in-flight work) must be rejected outright; explain why and suggest a non-destructive alternative (e.g. a new branch) instead of proceeding.
+
+## Branch Patterns
+
+Default to **GitHub Flow** (simpler, modern, CI/CD-friendly). Fall back to **Gitflow** only if the repo's config specifies it or the branch structure shows it in use (presence of `develop` or release branches).
+
+**GitHub Flow:**
+- Base: `main`
+- Feature branches: `feature/<feature-name>` or `fix/<bug-name>`
+- Merge: fast-forward when possible (preserves linear history)
+- Delete after merge
+
+**Gitflow:**
+- Base: `main` (production) + `develop` (integration)
+- Feature branches: `feature/<feature-name>` (from `develop`)
+- Release branches: `release/X.Y.Z` (from `develop`, merged to `main` + `develop`)
+- Hotfix branches: `hotfix/X.Y.Z` (from `main`, merged to `main` + `develop`)
+- Merge: always use `--no-ff` to preserve branch structure
+
+## Workflow
+
+- [ ] **Determine pattern:** Check git plugin config (`.claude/plugins/git/config.json`, if present — see `config.example.json` in the plugin root for the expected shape) for `branching_pattern` (default: `github-flow`). If not set, inspect repo for `develop` branch or `release/*` branches; if present, assume Gitflow.
+- [ ] **Create branch:** Use `git switch -c <branch> <base>`. Base defaults to config's `base_branch` (usually `main` or `develop`). Include intent metadata in branch name or return as structured result (e.g., `{ "branch": "feature/x", "intent": "implement feature X" }`).
+- [ ] **Track remote:** If pushing, always use `git push -u origin <branch>` to establish tracking.
+- [ ] **Safety checks before destructive ops:** Before delete/force-push/rebase with history loss, check: (1) Is this branch tracking a remote? Warn if yes. (2) Are there unpushed commits? Warn if yes. (3) Does the orchestrator call include `confirm: true`? Fail if not. For humans, prompt interactively.
+- [ ] **Return structured results:** Always return branch operations as JSON or structured text: `{ "action": "create", "branch": "feature/x", "base": "main", "tracking": "origin/feature/x", "intent": "implement feature X" }`. Agents need to parse this for subsequent operations.
+- [ ] **Retrieve intent (`get-intent`):** Git has no native field for free-text branch metadata — this skill doesn't persist it. On `create`, the `intent` value is only ever returned in the structured result; the caller (orchestrator or agent) is responsible for storing it if it needs to be looked up later. On `get-intent`, either parse it back out of the branch name convention (`feature/<intent-slug>`) or return `{ "intent": null }` if the caller never persisted the original create-time value — don't fabricate an intent.
+
+### Command mapping for each action
+
+- **delete:** `git branch -d <branch>` refuses if the branch has unmerged commits — prefer this by default. `git branch -D <branch>` forces deletion and discards unmerged work; only use it after the safety checks above pass and `confirm: true` is set. For a remote branch: `git push origin --delete <branch>`.
+- **rename:** `git branch -m <old> <new>`.
+- **list:** `git branch` (local only), `git branch -a` (all local + remote-tracking), `git branch -r` (remote-tracking only), `git branch --merged`/`--no-merged` (filter by merge status into current branch).
+- **get-intent:** No git command — see Workflow step "Retrieve intent" for how this is resolved.
+- **track (existing branch):** `git branch --set-upstream-to=origin/<branch>` sets tracking without a push; `git branch -vv` shows tracking state for all local branches.
+- **switch (existing branch):** `git switch <branch>` — switches to an existing local branch (aborts on conflicting local changes, see Gotchas). `git switch -` switches back to the previously checked-out branch.
+
+## Merging
+
+Scope: fast-forward/merge-commit mechanics and conflict resolution only. Rebase, cherry-pick, and revert belong to `git-history`.
+
+- **Fast-forward:** `git merge <branch>` — advances the pointer with no merge commit if the target hasn't diverged.
+- **True merge:** `git merge --no-ff <branch>` — forces a merge commit even when fast-forward is possible; required by Gitflow on all supporting-branch merges.
+- **Squash merge:** `git merge --squash <branch>` stages the combined diff without committing; follow with a manual `git commit`.
+- **Octopus merge:** `git merge branch-a branch-b branch-c` merges more than two branches at once; fails outright on any conflict, so use sequential two-way merges if conflicts are expected.
+
+**Conflict resolution:** when Git can't auto-merge, it inserts conflict markers and stops. Run `git status` to find conflicted files, edit them to resolve the markers, then `git add <file>` and `git merge --continue`. `git merge --abort` reverts to the pre-merge state. `git mergetool` opens the configured merge tool; `git diff --diff-filter=U` shows only conflicted files.
+
+## Comparing Branches
+
+- `git log main..feature` — commits in `feature` not in `main`.
+- `git log feature..main` — commits in `main` not in `feature` (reverse direction).
+- `git log --left-right main...feature` — both diverging sets (symmetric diff).
+- `git diff main...feature` — diff from the common ancestor to `feature`'s tip.
+- `git merge-base main feature` — print the common ancestor commit.
+
+## Integration with Orchestrator
+
+When invoked by `git-orchestrate`, accept requests in the form:
+```json
+{
+  "action": "create|switch|delete|rename|track|list|get-intent",
+  "branch": "<branch-name>",
+  "base": "<base-branch (optional, defaults to config)>",
+  "intent": "<human-readable intent (optional)>",
+  "confirm": "<true for destructive ops, omit for read ops>"
+}
+```
+
+Return results as:
+```json
+{
+  "success": true,
+  "action": "create|switch|...",
+  "branch": "<name>",
+  "message": "descriptive message",
+  "intent": "<intent if tracked>",
+  "tracking": "origin/<branch (if set)>",
+  "error": "<error message if success=false>",
+  "suggestion": "<recovery suggestion if applicable>"
+}
+```
+
+If error is due to uncommitted changes, include `{ "suggestion": "stash changes and retry" }` so the orchestrator can offer automatic recovery.