akm-cli
Version:
akm (Agent Knowledge Manager) — a portable, local-first capability library for AI agents. Discover, load, share, and improve reusable skills, scripts, workflows, and knowledge across any shell-capable coding agent, including Claude Code, OpenCode, and Cur
169 lines (137 loc) • 8.22 kB
Markdown
# Asset Types
Reference for the capability taxonomy the native `akm` adapter recognizes,
the bundle directory layout, and the metadata every asset carries.
## Contract
- akm's own native format (the `akm` adapter) recognizes **fourteen asset
types**: script, skill, command, agent, knowledge, instruction, env,
secret, workflow, lesson, memory, task, session, and fact.
- Scripts, knowledge, commands, agents, skills, and workflows are classified
by **file extension and content**, not by directory name. A `.sh` file is
a script whether it lives in `scripts/`, `deploy/`, or the bundle root; for
these types the conventional directory names below are an **opt-in
convention that improves indexing confidence**. The remaining types are
**directory-required**: env, secret, memory, lesson, fact, session, task,
and instruction assets are only discovered under their placement
directories (a memory-shaped `.md` outside `memories/` indexes as plain
knowledge).
- `type` is not part of an asset's ref — the placement subdirectory carries
that signal. See [Refs](refs.md).
- Ten additional *bundle formats* beyond akm's own (Claude Code and OpenCode
tool directories, OKF, LLM wikis, and more) are recognized, indexed, and
validated in place by their own adapters — see
[Bundle Types](bundle-types.md) for the full type-by-type table (purpose,
what the agent gets, and example ref) and the other-format read/write
picture.
## Directory layout
There's no required structure, but this skeleton is the opt-in convention:
```text
my-bundle/
scripts/ # Executable scripts (.sh, .ts, .js, .py, .rb, .go, etc.)
skills/ # Skill definitions (directories with SKILL.md)
commands/ # Slash commands (.md with $ARGUMENTS or agent frontmatter)
agents/ # Agent definitions (.md with model/tools frontmatter)
knowledge/ # Reference documents (.md)
instructions/ # Project guidance (.md)
env/ # Environment files (.env) — groups of related config, loaded whole
secrets/ # Secrets — one sensitive value per file (auth tokens, keys, certs)
workflows/ # Peer workflow sources (.md and .yml)
lessons/ # Distilled lessons (.md, see akm improve / proposals)
memories/ # Recalled context fragments (.md, see Memory reference)
facts/ # Durable bundle-level facts (.md)
tasks/ # Task source v4 scheduled or on-demand automation (.yml only)
sessions/ # Machine-placed indexed session summaries (.md)
.meta/ # Optional bundle orientation, not indexed (see "Bundle orientation" below)
```
LLM Wikis are a related but separate concept: a wiki is its own installable
bundle (`akm bundle add github:team/research-wiki`), not a type-subdirectory
inside a regular bundle. See [Wikis](../guides/wikis.md) for how akm
recognizes and indexes them.
## Classification taxonomy
Scripts and knowledge are classified by **what they are**: a `.sh` file is a
script; a plain `.md` file is knowledge. Commands and agents are classified
by **how an LLM should use them**: a `.md` file with `$ARGUMENTS`
placeholders is a command template; one with `tools` in its frontmatter is an
agent definition. Workflow assets may be `.md` or `.yml`: Markdown is
classified by `type: workflow` or placement, while the GitHub-shaped YAML
adapter validates the closed workflow subset. These are peer workflow sources,
not an md-only surface. Skills are a
**packaging convention**: a directory containing a `SKILL.md` file.
See [Classification](../architecture/internals/classification.md) for the
full specificity-based matching system.
## Metadata field reference
Metadata lives with the asset itself, not in a separate sidecar file:
frontmatter for markdown assets, and structured comments for scripts. The
indexer derives metadata from filenames, code comments, frontmatter, and
`package.json`.
See [Filesystem Layout](../architecture/internals/storage-locations.md) for
the full field reference.
### Bundle orientation: the `.meta/` convention
A bundle may carry an optional `.meta/` directory at its root holding
human-authored orientation for the bundle *as a whole* — purpose, key
assets, conventions, maintainer. This is distinct from per-asset metadata,
which still lives with each asset: `.meta/` never describes individual
assets, only the bundle itself.
```text
my-bundle/
.meta/
index.md # shown by `akm show meta` — the default orientation doc
about.md # shown by `akm show meta:about`
conventions.md # shown by `akm show meta:conventions`
```
Because `.meta/` is a dot-directory, the indexer skips it — these docs never
appear in `akm search` and never compete for ranking. They are **direct-read
on demand**:
```sh
akm show meta # working bundle's .meta/index.md
akm show meta:about # working bundle's .meta/about.md
akm show akm//meta # the primary bundle explicitly
```
`akm show <origin>//meta:<name>` resolves `<name>.md` first, then an
extensionless `<name>`. The convention is open-ended: bundle owners add new
docs by dropping files into `.meta/` — no configuration or code changes
required. `akm bundle create` scaffolds a starter `.meta/index.md`.
**Known gap:** an install-ref origin (`akm show github:owner/repo//meta`)
does not currently resolve even for an installed bundle — origin resolution
matches only derived installation ids, not raw install refs. Use `akm//meta`
for the primary bundle, or the bundle key you gave it in `bundles`
(`config.json`), not the original install ref.
## Script execution (ExecHints)
For script assets, akm resolves execution hints in this order:
1. Header comment tags (`@run`, `@setup`, `@cwd`)
2. Auto-detection from extension and nearby dependency files
## Defaults
- Directory placement is advisory for scripts, knowledge, commands, agents,
skills, and workflows; it is required for env, secret, memory, lesson,
fact, session, task, and instruction discovery.
- A memory asset with no source directory pointed at it is written to the
working bundle by `akm remember`.
- `facts/` holds durable bundle-level facts, including the organization,
backlink, and domain convention facts the bundle skeleton ships with (see
[Refs — namespacing](refs.md#namespacing)).
## Security / persistence implications
- `env` and `secret` assets carry protected values: key names are
discoverable, but values are never written to stdout, the index, or
structured output. See `STABILITY.md`'s "Protected env & secret values"
entry for the exact contract and the safe injection path
(`akm env run` / `akm secret run`).
- All asset content is plain files inside the bundle directory — the search
index (`index.db`) is a derived, regenerable cache rebuilt by `akm index`;
it is never the source of truth for asset content.
- `akm lint` only operates on writable sources, and `akm improve` on one of
them: the bundle it writes to (`--bundle`, else `defaultWriteTarget`, else the
working bundle). Read-only registry caches (`git`, `npm`, `website`) are
excluded from improvement and lint passes even when they are indexed.
## Stability
Per `STABILITY.md`: asset `type` is a free-form, open string — `--type`
filtering is exact-match against an open set and deliberately unvalidated
(an unrecognized type returns zero hits, not an error). The `lesson` asset
type's schema (`when_to_use`, `description`) is stable, but its
distillation triggers and ranking are Experimental tuning targets. See
`STABILITY.md` for the full command- and surface-level tier index.
## See also
- [Concepts](../guides/concepts.md) — the four core ideas asset types fit into
- [Refs](refs.md) — how a conceptId is built from an asset's placement
- [Memory](memory.md) — the memory asset type's belief-state and derived-memory model
- [Bundle Types](bundle-types.md) — every bundle format akm recognizes, not just its own
- [Classification](../architecture/internals/classification.md) — the specificity-based matcher
- [Filesystem Layout](../architecture/internals/storage-locations.md) — full metadata field reference