Skills arrive through a funnel: evidence recorded, candidates read back, a decision taken, then generation — with the draft-and-publish route as the manual path to the same canonical state. Mutation is deliberately awkward where it should be. Purging facts and rolling back a scope refuse to run without an explicit confirmation, creating a skill touches no native target unless sync is asked for, and cleanup and repair stay inside targets the server itself manages rather than anything it finds. The recommendation tool accepts a dry-run flag for symmetry and is read-only either way, which is worth knowing before you build a plan around it.
A vendor-agnostic persistence layer for AI agents, held locally. It stores facts at project and global scope, turns repeated patterns into formal Agent Skills, and pushes approved rules and skills into the instruction files the tools you use already read — AGENTS.md, CLAUDE.md, .cursor/rules and their kin.
- A fact store with scope and visibility: facts persisted with tags, listed and filtered by scope and status, purged by ID or by whole scope behind a confirmation, and assembled into a Markdown context block sized to a character budget for injection into a system prompt (remember_fact, list_facts, purge_fact, context).
- Undo that is in place before you need it: snapshots listed per scope, the latest one restored behind a confirmation, and an audit trail of what changed (list_snapshots, rollback_scope, list_audit_events).
- Skills that start from evidence rather than a blank page — a recurring opportunity tracked with its evidence, candidates read back read-only, a decision recorded, then the physical skill generated once approved (track_latent_skill, recommend_skills, propose_skill, generate_skill, promote_skill_recommendation).
- A hand-authoring path beside it: an editable draft, validation against a draft, a canonical skill or a local path without touching files, and publication to canonical only once it passes (create_skill_draft, validate_skill, publish_skill, create_skill).
- Control over skills once they exist: listed and inspected for their metadata and triggers, edited, renamed while blocking unmanaged destination conflicts, activated or deactivated without deleting the SKILL.md, and shared into repository content (list_skills, get_skill_detail, update_canonical_skill, update_skill, rename_skill, activate_skill, deactivate_skill, share_skill).
- Adoption of skills already on disk, either imported into canonical storage or adopted in place without creating a duplicate slug (import_skill, adopt_skill).
- Sync that stays inside what it manages: canonical skills pushed to native targets with a drift decision, cleanup and repair limited to managed and orphan targets under a dry run, and approved rules pushed into the instruction files of registered hosts (sync_skills, cleanup_skill, repair_skills, sync_instructions).
- Project layout and health you can read before acting: the layout created, reported without mutation, or migrated from legacy content; and initialisation state, fact counts, active rules, registered skills, approximate size and host validations, alongside read-only environment diagnostics (initialize_project, inspect_project_layout, migrate_project_layout, status, doctor, host_setup, host_check).
Python, and nothing else — no account, no key, and the store stays on your machine. It installs from PyPI and ships both a CLI and an MCP entry point from the same package, so the same operations are available either way. Pushing rules or skills into an editor or agent runtime additionally needs that host registered through host_setup under a host ID, with its own character and line budgets. Skills follow the agentskills.io structure, so a skill created here is a directory with a SKILL.md and its helper scripts rather than a proprietary record.
One command — uv tool install universal-memory