Why --- ADR-0018 left deployed skills tracking the remote default branch with nothing watching for drift. The mechanism that was supposed to cover this, scripts/git-hooks/post-push, could never have worked: git has no client-side post-push hook. install.sh copied it into .git/hooks/ so it looked installed, and it had never once fired. Issue #78 reported it as skipping the gitea plugin; it was skipping everything. Refreshing on push was also the wrong shape. Your install goes stale when someone else merges, so a push of your own is neither necessary nor sufficient for staleness to have occurred. Implementation notes -------------------- kyberforge ships a SessionStart hook (startup matcher only) that runs `apm outdated`, and when anything is behind runs `apm update --yes` and returns reloadSkills:true so the running session picks up redeployed content. It exits silently with no apm.lock.yaml present, which keeps it inert for hosts that installed this plugin natively rather than through apm. Two findings drove the wiring, both verified rather than assumed: - apm resolves ${CLAUDE_PLUGIN_ROOT} against the installed package root, and `apm pack` keeps only *.json from .apm/hooks/. A .../hooks/<script> reference therefore points into the generated mirror where the script does not exist — apm reports "Hook script not found" and deploys a hook aimed at nothing. The reference must be .apm/-relative, and a test pins it. - apm's executable-trust gate is OFF unless apm.yml carries an `executables:` block; until now every hook, bin and MCP primitive a dependency shipped would have deployed unprompted. Root apm.yml now enables it. The allow key is version-pinned by apm's design, so a kyberforge version bump silently blocks the hook until the key is bumped too — called out in the block and the ADR. Also corrects ADR-0018 and AGENTS.md, which named `apm install` as the refresh command. It is not: `apm install` deploys from apm.lock.yaml's pinned commit and does not re-resolve refs. `apm update` does. Impact ------ Session startup costs ~0.7s when current and ~10.4s when six packages are behind. Auto-refresh rewrites apm.lock.yaml, so an unexplained modification to it after opening a session is expected; the emitted notice says so. .claude/settings.json stops being exactly {"hooks": {}} once the hook lands there — the merged entry is apm's own output, and the rule that nothing repo-authored goes in that file is unchanged. .claude/hooks/ and the .claude/apm-hooks.json sidecar are gitignored install output. The hook cannot install itself: dependencies resolve from the remote, so it takes effect only after this merges and `apm update` runs once against the new default branch. scripts/git-hooks/ is now empty. install.sh's copy block is kept and test-git-hooks-install.sh synthesizes its own fixture, so the mechanism stays tested without requiring a dead hook to exist. ADR: 0019 Refs: #78 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01X7GvKuJfy2WrdBmUttV4DT
7.7 KiB
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:
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>@holocronmarketplace alias. The alias is shorter and apm resolves it correctly (verified end-to-end against this remote), but it first requiresapm 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: truethe native install had. apm warns on every install (6 dependencies unpinned); accepted knowingly. Pinning is a per-entryref:away once the repo tags releases per package — todaygit taglists one tag total, so there is nothing meaningful to pin to.
Consequences
Skills lose their namespace. apm deploys plain project skills, so git:git-commits is now
git-commits and kyberforge:skill-audit is skill-audit. This is not configurable — a project
skill has no plugin to prefix. Every <plugin>:<skill> reference in the repo's own instructions
was stale the moment the switch landed; AGENTS.md and CONTEXT.md are updated. The namespaced
form still resolves for anyone installing holocron natively, so skill bodies written for both
audiences should name the bare skill.
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. bin@holocron, gitea@holocron, and a stale
hello-world@holocron remain natively installed at user scope, and every project other than this
one still resolves its skills that way. Converting them is a separate decision with a blast radius
beyond this repo.
Alternatives considered
apm install --global. Verified working in an isolatedHOME: user-scope deploys land in~/.claude/skills/and~/.claude/agents/, and it is the only scope where a plugin'sbin/executables deploy (moot here — everybin/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.jsoncannot holdenabledPluginswithout failingapm audit --ci.