akm-cli 0.9.30 → 0.10.26101001-alpha

package/docs/posts/intro-part-01.md

@@ -0,0 +1,76 @@
+---
+title: Your AI Agent's Skill List Is Getting Out of Hand
+id: 3327252
+cover_image: 'https://raw.githubusercontent.com/itlackey/akm/main/docs/posts/akm-logo-sized.webp'
+series: akm-skills
+description: A quick introduction to the Agent-i-Stash CLI for managing AI agent extensions
+tags:
+  - ai
+  - agents
+  - cli
+  - skills
+published: true
+date: '2026-03-08T15:58:28Z'
+---
+
+> This is a dated article from AKM's publishing archive. For current product behavior, see the
+> [documentation index](https://github.com/itlackey/akm/blob/main/docs/README.md).
+
+If you've been building with Claude Code or OpenCode for any length of time, you've probably hit the same wall. You start with a handful of skills and commands. They work great. So you add more. Then a few more for that new project. Then a teammate shares theirs and you copy those in too.
+
+Before long you've got dozens of files scattered across directories, no good way to find the one you need, and an agent that's either missing context it should have or drowning in context it doesn't need.
+
+That's the problem [Agent-i-Stash](https://github.com/itlackey/akm) is built to solve.
+
+## The Real Issue Isn't Storage, It's Discovery
+
+Claude Code and OpenCode are great at *using* skills and tools. They're not great at helping you *manage* them. There's no built-in search. No way to share a curated set of skills with your team without copying files around. No versioning. No registry.
+
+So most people end up with one of two bad situations:
+
+**Option A:** You stuff everything into context at startup. Your agent sees every skill, every tool, every command — whether it needs them or not. This sounds fine until you realize that loading irrelevant context doesn't just waste tokens, it actively degrades the quality of your agent's decisions. More isn't better. It's just noise.
+
+**Option B:** You keep your stash small and tightly curated. The agent stays sharp, but you're constantly maintaining it by hand, rediscovering skills you forgot you had, and starting from scratch every time you spin up a new project.
+
+Neither of these scales.
+
+## Progressive Disclosure: Only Load What You Actually Need
+
+The idea behind Agent-i-Stash is straightforward: your agent shouldn't have to know about every skill upfront. It should be able to *search* for what it needs, then load only that.
+
+This is called progressive disclosure — a pattern from UX design that's finding a second life in agent architecture. Instead of front-loading everything, you expose a lightweight index. The agent scans it, decides what's relevant to the current task, and fetches only those resources. Everything else stays out of context.
+
+The difference in practice is significant. An agent working from a bloated context window will drop steps, misfire on tool selection, and hallucinate connections between things that have nothing to do with each other. An agent that fetches only what it needs stays focused.
+
+Agent-i-Stash gives you this through two commands your agent can call: `akm search` to find relevant skills by intent, and `akm show` to load the full content of only the ones it actually needs. Semantic search means you're not matching on exact keywords — the agent can describe what it's trying to do in plain language and get back relevant results.
+
+## Skills Should Be Shareable
+
+The other problem Agent-i-Stash tackles is distribution. Right now, if you build a great skill for managing Docker containers or generating print-ready PDFs, sharing it with someone else means sending files. There's no package lifecycle, no versioning, no clean way to pull updates.
+
+Agent-i-Stash adds a registry layer on top of your stash. You can install a stash from GitHub or npm in one command. Your team can maintain an internal repository of shared skills that everyone pulls from. Community-maintained stashes can be versioned and updated the same way you'd update any other dependency.
+
+This matters because the value of a good skill compounds when it's shared. A skill that took you an afternoon to get right shouldn't have to be reinvented by every person on your team — or by strangers on the internet who ran into the same problem you did.
+
+## It's Not Replacing Anything
+
+Agent-i-Stash isn't trying to replace MCP, or the skill systems built into Claude Code and OpenCode. It sits alongside them as a management and discovery layer. You still define your skills the same way. You still use them the same way. You just also have a way to find them, share them, and keep them organized as the collection grows.
+
+Think of it like the difference between having a folder full of scripts and having a package manager. The scripts are still scripts. You just don't have to remember where you put them.
+
+## Beta Testers and Agents Wanted
+
+The project is young — v0.0.9 as of this writing — but the problem it's solving is real and it's only going to get worse as agent workflows get more capable and more complex. A community-maintained registry of high-quality, searchable, versioned skills is genuinely useful infrastructure.
+
+Give it a look at [github.com/itlackey/akm](https://github.com/itlackey/akm). And if you've built skills worth sharing, this is a good time to think about how to package them so others can benefit.
+
+Feel free to drop links in the comments to skills or stashes you've built that you think others should know about.
+
+---
+
+*__Update (March 2026):__ This post is part of a series that has been updated to reflect akm's current CLI. Later posts in the series now use `akm setup` (formerly `akm init`), `akm add` (formerly `akm stash add`), and `akm list` (formerly `akm stash list`). If you're following along with an older version, `akm upgrade` will get you current.*
+
+
+---
+
+> **Note (2026-04-23):** This post has been updated to align with akm 0.6.0 terminology. Earlier wording referred to a *kit* and the *Kit Maker's Guide*; those terms have been renamed to *stash* and *Stash Maker's Guide* throughout. The pre-rename text is preserved in this repository's git history.

package/docs/posts/intro-part-02.md

@@ -0,0 +1,221 @@
+---
+title: You Already Have Dozens of Agent Skills. You Just Can't Find Them.
+cover_image: 'https://raw.githubusercontent.com/itlackey/akm/main/docs/posts/akm-logo-sized.webp'
+id: 3359719
+series: akm-skills
+description: A quick introduction to managing sources
+tags:
+  - ai
+  - agents
+  - cli
+  - skills
+published: true
+date: '2026-03-16T17:26:29Z'
+---
+
+> This is a dated article from AKM's publishing archive. For current product behavior, see the
+> [documentation index](https://github.com/itlackey/akm/blob/main/docs/README.md).
+
+In the [last post](https://dev.to/itlackey/your-ai-agents-skill-list-is-getting-out-of-hand-32ck), I talked about the problem: your agent's skill collection is growing faster than your ability to manage it. Skills scattered across directories, no search, no sharing, no sanity. I introduced [Agent-i-Stash](https://github.com/itlackey/akm) as the fix — a CLI called `akm` that gives your agent a searchable, indexed stash of assets.
+
+But here's what I glossed over: most of you aren't starting from zero. You've already got skills, commands, agents, and rules spread across multiple platforms. Claude Code has `~/.claude/skills/`. OpenCode has `.opencode/`. Cursor has `.cursor/rules/`. Codex has its `agents.md`. You might be using two or three of these tools in the same week, building up assets in each one, and none of them can see each other.
+
+That's the real unlock with `akm`. It doesn't care where your assets came from. Point it at a directory, and it indexes everything inside. Point it at five directories, and now you've got semantic search across all of them. One command, every platform, every model.
+
+Let me show you how fast this actually works.
+
+## Install
+
+Pick your poison:
+
+```bash
+# Standalone binary (no runtime needed)
+curl -fsSL https://raw.githubusercontent.com/itlackey/akm/main/install.sh | bash
+
+# Or via npm (Node.js >= 22 required)
+npm install -g akm-cli
+```
+
+The npm package requires Node.js >= 22 to bootstrap its command. If a working
+Bun >= 1.0 is also on `PATH`, the launcher prefers Bun for execution; old,
+unusable, or absent Bun installations fall back to Node.js. Standalone binaries
+are runtime-free. You now have the `akm` binary on your `PATH`. When a new
+version drops, `akm upgrade` handles it in place.
+
+## Initialize Your Stash
+
+```bash
+akm setup
+```
+
+This creates `~/akm` with subdirectories for each asset type: `scripts/`, `skills/`, `commands/`, `agents/`, `knowledge/`, and `memories/`. If you want to put it somewhere else, set `AKM_BUNDLE_DIR` before you run setup.
+
+But the real power move isn't putting everything in one folder. It's telling `akm` where your stuff already lives.
+
+## Add Your Existing Platform Directories
+
+Here's what most people's machines actually look like. You've got Claude Code skills in one place, OpenCode assets in another, maybe some Cursor rules in a third. Instead of copying files around or choosing a winner, just add them as sources.
+
+```bash
+akm add ~/.claude/skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add ./my-project/.opencode/skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add ./.cursor/rules  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+One command per directory. Each `akm add` registers the path, and the search index picks it up on the next build. No JSON editing, no manual config files. Your files stay exactly where they are — `akm` just knows about them now.
+
+You can name sources to keep track of what's what:
+
+```bash
+akm add ~/.claude/skills --name "claude-skills"  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add ./team-shared --name "team"  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+And see everything at a glance:
+
+```bash
+akm list  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+That shows your primary stash, all the directories you've added, and any managed sources — in priority order. Need to remove one? `akm remove` takes a path or a name.
+
+For assets that live in a git repo or an npm package, `akm add` handles installation and makes them searchable immediately:
+
+```bash
+# A team repo full of shared skills
+akm add github:your-org/team-agent-toolkit  # doclint:ignore (historical — pre-0.9.0 command spelling)
+
+# An npm stash
+akm add @scope/deploy-skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+
+# A local git directory
+akm add ./path/to/my-opencode-skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+Every `akm add` registers the stash, caches the assets, and triggers an incremental index build.
+
+## Build the Index
+
+```bash
+akm index
+```
+
+First run builds the full index. After that, it runs incrementally — only rescanning directories that changed. If you've configured an embedding endpoint (local Ollama, OpenAI, whatever), you get vector-based semantic search. If not, you still get solid keyword matching out of the box with the built-in local model.
+
+Want the enhanced experience? If you're running Ollama:
+
+```bash
+ollama pull nomic-embed-text
+akm config set embedding '{"endpoint":"http://localhost:11434/v1/embeddings","model":"nomic-embed-text","dimension":384}'
+akm index --full
+```
+
+## Search Across Everything
+
+Now here's where it pays off. Say you're working in Claude Code and you vaguely remember writing a skill for Docker container management a few months ago. Was it in your OpenCode stash? Your Claude Code skills? That shared repo your teammate set up?
+
+Doesn't matter.
+
+```bash
+akm search "docker container management"
+```
+
+That searches across every source you've registered — your primary stash, every directory you added with `akm add`, and all managed sources. Semantic search means you don't need to remember the exact filename. Describe what you're looking for and `akm` finds it.
+
+Results come back with a `ref` you can pass straight to `akm show`:
+
+```bash
+akm show skill:docker-homelab
+```
+
+Your agent gets the full SKILL.md content, ready to use. For scripts, it gets a `run` command it can execute directly. For commands, the full markdown template with placeholders. For knowledge, navigable content with TOC and section views. No manual file hunting.
+
+Want to search the community registries too? `akm` ships with [skills.sh](https://skills.sh) built in:
+
+```bash
+akm search "code review" --from all
+```
+
+Now you're searching your local stash and community registries in one shot. Found something useful? Install it:
+
+```bash
+akm add github:someone/great-stash  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+Or if you just want one asset from a stash without installing the whole thing:
+
+```bash
+akm clone "github:someone/great-stash//skill:code-review" --dest ./.claude
+```
+
+That clones just the skill directly into your project's Claude Code skills directory. The type subdirectory (`skills/`, `scripts/`, etc.) gets appended automatically.
+
+## Tell Your Agent About It
+
+Here's the part that ties it all together. Drop this into your `AGENTS.md`, `CLAUDE.md`, or system prompt:
+
+```markdown
+## Resources & Capabilities
+
+You have access to a searchable library of scripts, skills, commands, agents,
+knowledge, and memories via the `akm` CLI. Use `akm -h` for details.
+```
+
+That's the entire integration. No plugins, no SDKs, no integration code. Any model that can run shell commands can use `akm`. Claude Code, OpenCode, Codex, Cursor — if it has a terminal, it works.
+
+The agent runs `akm search` to find what it needs, `akm show` to load the content, and gets to work. Everything else stays out of context.
+
+## What This Looks Like in Practice
+
+Let's say your setup looks something like this:
+
+- **Claude Code**: `~/.claude/skills/` has skills for PDF generation, CMYK conversion, and print layout QA
+- **OpenCode**: `.opencode/skills/` in a project has custom Azure deployment scripts and a LiteLLM manager
+- **Shared team repo**: A git repo with Docker, CI/CD, and code review assets
+- **Cursor**: `.cursor/rules/` has coding conventions and architecture patterns
+
+After setup:
+
+```bash
+akm setup
+akm add ~/.claude/skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add .opencode/skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add .cursor/rules  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add github:your-org/team-agent-toolkit  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm index
+```
+
+Now when your agent runs `akm search "deploy container to azure"`, it finds your Azure deployment script from the OpenCode directory, the Docker skill from your team repo, and maybe a relevant knowledge doc from Cursor's rules. All in one search. All ranked by relevance.
+
+The agent picks what it needs, loads only that, and gets to work. Progressive disclosure means your agent's context stays clean — no drowning in irrelevant skills, no missing the one it actually needs.
+
+## Why This Matters More Than It Sounds
+
+The fragmentation problem in agent tooling is only getting worse. Every platform is building its own skill format, its own directory conventions, its own discovery mechanism. None of them talk to each other. If you're serious about building agent workflows, you're going to end up with assets in three or four of these systems within the year.
+
+You can either manage that by hand — maintaining parallel copies, forgetting where things are, rebuilding from scratch when you switch tools — or you can index once and search everywhere.
+
+`akm` isn't trying to replace any of these platforms. Your Claude Code skills stay Claude Code skills. Your OpenCode scripts stay OpenCode scripts. `akm` just makes them all findable from one place, regardless of which agent is asking.
+
+## Get Started
+
+```bash
+curl -fsSL https://raw.githubusercontent.com/itlackey/akm/main/install.sh | bash
+akm setup
+akm add ~/.claude/skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm index
+akm search "whatever you need"
+```
+
+Five commands. Every skill you've ever written, searchable in seconds.
+
+The repo is at [github.com/itlackey/akm](https://github.com/itlackey/akm). If you've got agent assets scattered across platforms, give it a shot and let me know what breaks.
+
+---
+
+*__Update (March 2026):__ This post was updated to reflect akm's current CLI. The unified `akm add` command replaces the earlier `akm stash add`, `akm setup` replaces `akm init`, and `akm list` replaces `akm stash list`. Sources (formerly "stash sources") are now managed through a single `akm add` / `akm remove` interface. If you're following along with an older version, `akm upgrade` will get you current.*
+
+
+---
+
+> **Note (2026-04-23):** This post has been updated to align with akm 0.6.0 terminology. Earlier wording referred to a *kit* and the *Kit Maker's Guide*; those terms have been renamed to *stash* and *Stash Maker's Guide* throughout. The pre-rename text is preserved in this repository's git history.

package/docs/posts/intro-part-03.md

@@ -0,0 +1,190 @@
+---
+title: Your Agent's Memory Shouldn't Disappear When the Session Ends
+cover_image: 'https://raw.githubusercontent.com/itlackey/akm/main/docs/posts/akm-logo-sized.webp'
+id: 3359720
+series: akm-memory
+description: A quick introduction to using OpenViking with akm
+tags:
+  - ai
+  - agents
+  - cli
+  - skills
+published: true
+date: '2026-03-17T16:07:09Z'
+---
+
+> This is a dated article from AKM's publishing archive. For current product behavior, see the
+> [documentation index](https://github.com/itlackey/akm/blob/main/docs/README.md).
+
+> **⚠ Deprecation notice (akm v1):** The OpenViking provider described in this post is no longer supported in akm v1. Configurations using `--provider openviking` will fail to load. This post is preserved for historical reference. See the [configuration docs](https://github.com/itlackey/akm/blob/main/docs/reference/configuration.md) for current provider options.
+
+This is part three in a series about managing the growing pile of skills, scripts, and context that AI coding agents depend on. In [part one](https://dev.to/itlackey/your-ai-agents-skill-list-is-getting-out-of-hand-32ck), I talked about why progressive disclosure beats loading everything into context. In [part two](https://dev.to/itlackey/you-already-have-dozens-of-agent-skills-you-just-cant-find-them), I showed how `akm` unifies your existing Claude Code, OpenCode, and Cursor assets into one searchable stash.
+
+Both of those were about files on disk. Local skills, local scripts, local knowledge documents. That covers most people's immediate pain, but it leaves a bigger problem on the table: what happens when the context your agent needs isn't local?
+
+Think about project architecture docs that live in a shared knowledge base. Team decisions captured during previous sessions. Coding standards that evolve over time and shouldn't be copy-pasted into every developer's stash. Agent memories that accumulate across conversations and need to persist somewhere more durable than a markdown file in a git repo.
+
+That's where [OpenViking](https://github.com/volcengine/OpenViking) comes in, and why `akm` now supports it as a first-class provider.
+
+## What Is OpenViking?
+
+OpenViking is an open-source context database built by ByteDance's Volcano Engine team. Instead of treating agent context as flat vectors in a RAG pipeline, it organizes everything — memories, resources, skills — into a hierarchical virtual filesystem with semantic search.
+
+The part that matters: it stores and retrieves agent context (project docs, team decisions, coding standards) via a REST API. When you connect it to `akm`, its content shows up in search results alongside your local assets — same `type:name` refs, same ranking, same `akm show` workflow.
+
+The part that matters for `akm` is the API. OpenViking exposes REST endpoints for search (semantic and text), content read, and file stat. That's exactly what a provider needs: the ability to find things and retrieve them. So we built one.
+
+## Adding OpenViking as a Source
+
+If you already have `akm` installed and an OpenViking server running, the setup is one command:
+
+```bash
+akm add http://localhost:1933 --provider openviking  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+That registers the server as a source. From that point on, `akm search` queries your local stash and the OpenViking server in parallel. Results from both show up in the same `hits[]` array, ranked together.
+
+If your server requires authentication:
+
+```bash
+akm add http://localhost:1933 --provider openviking --options '{"apiKey":"your-api-key"}'  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+Give it a name to keep things tidy:
+
+```bash
+akm add http://localhost:1933 --provider openviking --name "team-context" --options '{"apiKey":"your-api-key"}'  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+Verify it's registered:
+
+```bash
+akm list  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+That's the full setup. No config files to hand-edit, no environment variables to set. The provider handles caching, retries, and graceful degradation — if the server goes down, your local stash still works fine and the provider falls back to cached results for up to an hour.
+
+## Searching Remote and Local Together
+
+Here's what changes in practice. Before OpenViking, an `akm search` hit your local stash — your primary directory, search paths, and managed sources. Now it also hits any OpenViking servers you've registered.
+
+```bash
+akm search "project architecture"
+```
+
+This might return a local skill from your Claude Code directory *and* a knowledge doc from OpenViking. The results are unified: same format, same scoring, same `type:name` refs. Your agent can't tell the difference between a local asset and one from OpenViking — and it shouldn't need to.
+
+```bash
+akm show knowledge:project-context
+```
+
+That fetches the content — from the local index if available, or from the OpenViking server as a fallback. The response comes back in the same format as any other `akm show` — with a `content` field, an `action` field, and type metadata.
+
+By default, OpenViking search uses semantic matching (via `POST /api/v1/search/find`). If you prefer text search for exact matching, configure the provider with:
+
+```bash
+akm add http://localhost:1933 --provider openviking --options '{"apiKey":"your-key","searchType":"text"}'  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+Text search uses OpenViking's grep endpoint, which deduplicates results by URI and ranks them by match frequency.
+
+## Standing Up a Test Server
+
+If you want to try this locally before pointing at a shared server, the akm repo includes a ready-made Docker Compose setup:
+
+```bash
+git clone https://github.com/itlackey/akm.git
+cd akm/tests/fixtures/openviking
+
+# Start the server
+docker compose up -d
+
+# Wait a few seconds, then seed sample content
+./seed.sh
+```
+
+The seed script loads a handful of test documents — project architecture notes, coding standards, an API reference, and a project memory — into the OpenViking server.
+
+Now register it:
+
+```bash
+akm add http://localhost:1933 --provider openviking --name openviking --options '{"apiKey":"akm-test-key"}'  # doclint:ignore (historical — pre-0.9.0 command spelling)
+```
+
+And test:
+
+```bash
+akm search "project architecture"
+akm show knowledge:project-context
+```
+
+You should get back the full markdown content of the project architecture document. Search works across all sources:
+
+```bash
+akm search "coding standards"
+```
+
+And if you have Ollama running locally, you can enable semantic search by updating the `ov.conf` to point the embedding endpoint at your Ollama instance (`http://host.docker.internal:11434/v1`). Without embeddings, text search and direct content access still work fine.
+
+Tear it down when you're done:
+
+```bash
+docker compose down
+```
+
+## Why This Matters for Teams
+
+The OpenViking integration solves a class of problems that local-only management can't.
+
+**Shared context without shared files.** Your team can maintain a single OpenViking instance with project documentation, architectural decisions, and coding standards. Every developer's agent can search and retrieve that context without syncing files, mounting network drives, or maintaining parallel copies. Update a document in OpenViking and every agent sees the change immediately.
+
+**Persistent memory across sessions.** OpenViking's memory system stores recalled context fragments that survive across conversations. When your agent starts a new session, it can search for memories from previous work — `akm search "sprint planning decisions" --type memory` — and get back what it learned last week. That's a fundamentally different capability than loading the same static skills every time.
+
+**Unified search across everything.** This is the compounding effect of the whole series. Part one gave you progressive disclosure for local skills. Part two unified your multi-platform assets into one searchable stash. Now part three adds remote context to the same search surface. One `akm search` query, one result set, one `akm show` command — regardless of whether the asset is a Claude Code skill in `~/.claude/skills/`, a script from an npm stash, or a knowledge document on an OpenViking server across the network.
+
+## The Full Picture
+
+After three posts, here's what a fully-wired setup looks like:
+
+```bash
+# Install
+curl -fsSL https://raw.githubusercontent.com/itlackey/akm/main/install.sh | bash
+akm setup
+
+# Local platform assets
+akm add ~/.claude/skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add .opencode/skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add .cursor/rules  # doclint:ignore (historical — pre-0.9.0 command spelling)
+
+# Community and team stashes
+akm add github:your-org/team-agent-toolkit  # doclint:ignore (historical — pre-0.9.0 command spelling)
+akm add @scope/deploy-skills  # doclint:ignore (historical — pre-0.9.0 command spelling)
+
+# Remote context server
+akm add https://your-viking.internal:1933 --provider openviking --name team-context --options '{"apiKey":"..."}'  # doclint:ignore (historical — pre-0.9.0 command spelling)
+
+# Build the index
+akm index
+```
+
+Now drop the `AGENTS.md` snippet into every project and your agent has access to all of it:
+
+```markdown
+## Resources & Capabilities
+
+You have access to a searchable library of scripts, skills, commands, agents,
+knowledge, and memories via the `akm` CLI. Use `akm -h` for details.
+```
+
+Local skills, remote knowledge, team stashes, community registries, persistent memories. One search, one interface, every agent.
+
+The repo is at [github.com/itlackey/akm](https://github.com/itlackey/akm). OpenViking is at [github.com/volcengine/OpenViking](https://github.com/volcengine/OpenViking). Both are open source, both are moving fast, and the combination is genuinely useful infrastructure for anyone running agents in production.
+
+---
+
+*__Update (March 2026):__ This post was updated to reflect akm's current CLI. `akm add` replaces the earlier `akm stash add` for adding sources (including OpenViking providers), `akm setup` replaces `akm init`, and `akm list` replaces `akm stash list`. Sources (formerly "stash sources") are now managed through a single `akm add` / `akm remove` interface. If you're following along with an older version, `akm upgrade` will get you current.*
+
+
+---
+
+> **Note (2026-04-23):** This post has been updated to align with akm 0.6.0 terminology. Earlier wording referred to a *kit* and the *Kit Maker's Guide*; those terms have been renamed to *stash* and *Stash Maker's Guide* throughout. The pre-rename text is preserved in this repository's git history.