akm-opencodeOpenCode plugin for AKM 0.9 with in-process search, show, and curate tools plus feedback and remember.
1
591
101 in 7 days
39.5
Multi-signal model
12 hours ago
2026-08-19
Install and configure
opencode.jsonWrites to this project's opencode.json — applies to this repository only.
opencode.json
{
"$schema": "https://opencode.ai/config.json",
"plugin": ["akm-opencode@0.9.1"]
}Writes to ~/.config/opencode/opencode.json — applies to every project.
~/.config/opencode/opencode.json
{
"$schema": "https://opencode.ai/config.json",
"plugin": ["akm-opencode@0.9.1"]
}If you want to modify the plugin locally, install it into the project and reference the local path.
shell
pnpm add -D akm-opencodeopencode loads npm dependencies through its embedded runtime on startup and caches them locally — no manual global install needed.
Platform plugins for AKM ^0.9.0. Both integrations expose exactly five public AKM surfaces:
| Capability | OpenCode tool | Claude slash command |
|---|---|---|
| Search configured bundles or registries | akm_search |
/akm-search |
| Show a concept | akm_show |
/akm-show |
| Curate concepts for a task | akm_curate |
/akm-curate |
| Record an outcome | akm_feedback |
/akm-feedback |
| Save durable knowledge | akm_remember |
/akm-remember |
AKM references are concept IDs in the form [bundle//]conceptId[#fragment], for example skills/code-review, memories/release-notes, or team-playbook//knowledge/deploy#Rollback. The CLI search and curate commands use --from local, --from registry, --from all, or --from <bundle-name>.
OpenCode
Add the plugin to opencode.json:
{
"plugin": ["akm-opencode"]
}
The plugin also uses OpenCode lifecycle hooks to inject curated context, preserve it through compaction, record usage feedback, and capture useful session memories. See opencode/README.md for details.
Claude Code
Add the marketplace and install the plugin:
/plugin marketplace add itlackey/akm-plugins
/plugin install akm
Or use the Claude CLI:
claude plugin marketplace add itlackey/akm-plugins
claude plugin install akm@akm-plugins
Claude receives the five slash commands, an AKM skill, and lifecycle hooks for scoped curation, feedback, and memory capture. See claude/README.md for details.
Development
Set AKM_LOCAL_BUILD_CLI=/absolute/path/to/akm/dist/cli.js to test either plugin against a local AKM build.
Versioning
The plugins keep MAJOR.MINOR in sync with the AKM CLI line they target, and let PATCH diverge inside that minor. While AKM is on 0.9.x, the plugins release 0.9.0, 0.9.1, 0.9.2, … independently of AKM's own patch number.
The sync point is AKM_VERSION_RANGE in claude/shared/akm-version.ts, which both plugins import. On a 0.x version a caret range is a minor line — ^0.9.0 means >=0.9.0 <0.10.0 — so that one constant already states which AKM line a release targets. Moving the plugins to a new AKM minor is a change to that constant, and the release then follows it.
Patch divergence is deliberate: a plugin-only fix has to be shippable without waiting for an AKM release, which is impossible if the patch component is spent mirroring AKM's.
Versions must be plain semver (MAJOR.MINOR.PATCH, optionally -prerelease). A four-component string such as 0.9.0.20260811.1 is not semver and npm rejects it on publish. For dated snapshot builds use a prerelease of the next patch — 0.9.1-20260811.1, which sorts above 0.9.0 and below 0.9.1 — rather than a prerelease of the current one, which would sort below the version already published. Note that no prerelease satisfies a stable range like ^0.9.0, so snapshots reach users only through an explicit npm dist-tag.
Both rules are enforced, not conventional:
tests/version-policy.test.tspins all four version fields to each other and to theAKM_VERSION_RANGEminor line, and pins the three install-ref copies of the range to the constant..github/workflows/release.ymlvalidates the requested version before it stamps manifests, commits, and pushes a tag — npm would otherwise be the first thing to reject a bad version, long after the tag exists.