Documentation

AKM is a portable capability library for AI agents: one library for every agent. This hub is organized by what you're trying to do, not by directory — start here, then follow links out to the guides, reference, and architecture pages as you need more depth. Each subdirectory also has its own README indexing everything inside it.

Full per-directory indexes: Guides, Reference, Agents, Architecture, Migration.

Start

• Getting Started -- Install akm, connect a source, and pull a curated shortlist in five to seven minutes
• Concepts -- Capabilities, bundles, adapters, asset types, and refs -- the mental model in one page
• Agent Install Guide -- Step-by-step automated (non-interactive) install for agents
• akm help agents (short guide by default; akm help agents --full for the complete guide) -- The CLI reference agents load to use akm; always the embedded corpus at src/assets/hints/cli-hints-{full,short}.md

Use

One library for every agent: connect what you already have, load only what the task needs, and capture what you learn along the way.

• Use AKM With Any Agent -- Wire akm into Claude Code, OpenCode, Cursor, and other coding assistants with a three-line system prompt block
• Discover and Load -- Search, curate a shortlist, and load exactly the ref a task needs
• Bundles -- Connect local dirs, git repos, npm packages, and websites; browse the registry
• Capture Knowledge -- akm remember, akm import, and how captured material becomes available to every agent
• Wikis -- Multi-wiki knowledge bases (Karpathy-style)
• Environment & Secrets -- akm env and akm secret: exact operations, file modes, and the security guarantee
• Run Workflows -- Start or continue a run, check on it, resume it, or abandon it
• Scheduling -- Run akm tasks through the OS scheduler (cron / launchd / schtasks) safely
• Migrate to 0.9.2 -- Convert task-v2 sources safely and understand workflow resume compatibility
• Improve the Library -- Feedback, history, and proposals -- how evidence turns into reviewable changes
• Recipes: Turn a Website into a Searchable Bundle, Headless Install

Build and operate

Package complete capabilities and turn knowledge into repeatable work.

• Bundle Author's Guide -- Build a bundle, make it discoverable, and share it so others can install it with akm bundle add
• Author's Guide: Writing Workflows -- Write and test a workflow definition, from a minimal example to gates and outputs
• Claude Code workflows vs. akm workflows -- Short decision guide for choosing between a session-native workflow and an akm workflow (full technical comparison)
• Bundling akm -- Ship akm inside your own product: the pin/migrate/health boot contract, plan JSON shapes, and exit codes for bundlers

Maintainers

Working on akm itself, not just using it.

• Maintainer Docs -- Start here: local development, measuring improvement, and the curate contract
• Local Development -- Dogfooding akm while editing its own source
• Curate Workmap -- The current akm curate contract and the highest-value next fixes

Look up details

• CLI -- All akm commands and flags
• Configuration -- Engines, strategies, bundles, and settings
• Supported Formats -- Every bundle format akm recognizes, its detection marker, and current read/write support
• Tasks -- Task-v3 files, targets, triggers, and fail-closed migration
• Asset Types -- The capability taxonomy, directory conventions, and per-type examples
• Refs -- The ref grammar akm search emits and akm show consumes
• Memory -- The memory asset type: capture, belief states, and derived memories
• Workflow Schema -- Authoritative frontmatter/body syntax for a workflow asset
• Workflows (overview) -- Short map across the workflow schema, engine, and how-to guides
• Registry -- Registries, search, hosting, and managing sources
• Website Sources -- The pluggable fetcher API for URL-based knowledge reads
• Data & Telemetry -- Exactly what akm reads and writes on your machine (no remote telemetry)
• Architecture -- How akm's bundles, cache, index, and registries fit together
• Core Principles -- Design principles and constraints
• Adapters -- How akm picks an adapter, indexes, validates, and writes into a bundle
• The Workflow Engine -- How a frozen plan is stored, dispatched, and resumed without replaying completed units
• The Improvement Loop -- How a feedback signal becomes a ranking change, and how evidence becomes a proposal
• Runtime Boundary Design -- Isolating bun:sqlite/Bun.* from the core
• Architecture Decision History -- ADR-style record of the major architecture rulings
• Specs -- Normative specifications (bundle/adapter model, ref grammar, bundle conventions)
• Internals -- Current-truth subsystem references (storage, search, indexing, improve, health)
• Testing -- Testing workflow and pre-release checklist
• Migration -- Upgrade guides and per-release migration notes
• Roadmap -- High-level focus for the releases from here through 1.0

Execution boundary

AKM retrieves every supported capability type. It directly orchestrates defined execution surfaces such as workflows, agent dispatch, tasks, and guarded subprocess injection. It does not blindly execute arbitrary indexed content merely because that content appears in search results. See Core Principles for the full boundary, and The Improvement Loop for how that boundary applies to akm's own self-generated changes.

Posts

Source articles for the dev.to publishing pipeline (historical record). See docs/posts/README.md.

Official Ecosystem Repositories

• itlackey/akm-stash -- the official onboarding bundle with ready-made assets you can install with akm bundle add
• itlackey/akm-registry -- the official registry index that powers built-in discovery
• itlackey/akm-plugins -- optional integrations for tools like OpenCode
• itlackey/akm-bench -- the standalone benchmark harness for measuring agent performance with akm
• itlackey/akm-eval -- the eval framework and tools for akm asset quality

New docs, in five lines: keep one current-truth doc per subsystem, don't fork a second one. Planning, review, and analysis material lives in the untracked .plans/ directory, never under docs/ -- promote conclusions into the current-truth doc or drop them. Normative specs live in docs/architecture/specs/. Cite code by symbol and memories by search-terms -- not line numbers or exact refs, both rot. Nothing in docs/ may reference .plans/.