This page explains how the Memory Layer skill system fits together in this repository.
It covers two different things:
- how the agent runtime discovers and selects skills
- how Memory Layer bootstraps and ships the repo-local skill files
- Mental Model
- Short Description vs
SKILL.md - When A Skill Is Selected
- When
SKILL.mdIs Read - What
memoryDoes And Does Not Do - Canonical Skill vs Template vs Example
- Bootstrap And Packaging
- Related Docs
There are three layers:
- the agent runtime decides whether a skill matches a turn
- the selected skill defines the workflow the agent should follow
- Memory Layer commands and the shared Go helper do the actual work
The important split is:
- the agent runtime selects and reads skills
- the skill tells the agent what to do
memorydoes not decide whether the agent should use a skill
The current repo-local Memory Layer bundle uses a Go-based helper under .agents/skills/memory-layer/scripts/, so go must be available on PATH for those helper commands to run.
Skill selection does not start by reading the full SKILL.md.
Instead, the runtime first works from a lightweight skill catalog entry:
- skill name
- short description
- path to the skill entrypoint
That short description is what lets the runtime decide that a task “looks like” it should use the skill.
Only after that selection step does the runtime open the full SKILL.md and follow the detailed workflow.
At runtime, a skill is selected when either:
- the user explicitly names it
- or the request clearly matches the skill description
For the memory-layer skill, those matches are things like:
- initializing or refreshing repo-local Memory Layer setup for a project
- project-specific questions about this repo
- asking what changed or what is known already
- storing durable project knowledge
- explaining code, a module, a file, an architecture path, or the whole codebase
- resuming work after an interruption
- transitioning from planning into approved execution
SKILL.md is read when the skill has been selected for the current turn.
That means:
- it is not read on every
memorycommand - it is not necessarily read on every chat turn
- it is read on turns where the runtime has decided the skill applies
In practice, changes to the live repo-local SKILL.md are picked up the next time the runtime selects and reads that skill.
memory provides the commands and bootstrap logic, but it does not make skill-selection decisions.
memory does:
- initialize a repo-local memory skill bundle during bootstrap
- copy the packaged or repo-local
skill-templateinto.agents/skills/ - compare the shared skill-bundle version and refresh repo-local skills with
memory upgrade - provide the command surface the skill scripts call
memory does not:
- parse
SKILL.mdon every CLI invocation - decide that an agent should use the skill for a turn
There are three important memory-skill copies in this repository:
- canonical live skill bundle
.agents/skills/- the umbrella skill is
.agents/skills/memory-layer/ - the focused skills are:
.agents/skills/memory-project-init/.agents/skills/memory-github-init/.agents/skills/memory-query-resume/.agents/skills/memory-review-proposals/.agents/skills/memory-plan-execution/.agents/skills/memory-direct-task-start/.agents/skills/memory-remember/
- this bundle is what the agent uses in this repository
- packaged template
- installed as
skill-template - used by
memory init/memory wizardto copy the bundled skills into a repo
- installed as
- developer example skill
docs/developer/examples/agent-example/skills/memory-layer/- useful as a reference, but not the canonical current live skill
When these drift, the live repo-local bundle should be treated as authoritative.
During repo bootstrap, memory copies the skill template into:
.agents/skills/
Each Memory-owned skill has a canonical version in its SKILL.md frontmatter. All bundled Memory skills use the same version as the Memory package. memory doctor compares the project-local skill bundle version with the installed template and reports drift through workflow.project_skills.
Package upgrades update the installed template, not every project checkout. To update an existing repo-local bundle, run:
memory upgrade --dry-run
memory upgradememory upgrade backs up replaced skill directories under the user-local project runtime skill-backups/ directory before copying from the template. It avoids replacing newer project-local skills unless --force is used.
The relevant logic lives in crates/mem-cli/src/main.rs:
discover_skill_template_dir()sync_memory_skill_bundle()project_skill_inventory()upgrade_project_skills()
The template is discovered from installed locations such as:
/usr/share/memory-layer/skill-template~/.local/share/memory-layer/skill-templateor$XDG_DATA_HOME/memory-layer/skill-templatefor local Linux installs/usr/local/share/memory-layer/skill-templatefor the macOS.pkg$(brew --prefix)/share/memory-layer/skill-templatefor Homebrew- or, during source/dev use, the repo-local
.agents/skills/
This is why the same skill can exist in three forms:
- live repo-local bundle
- installed template copy
- documentation/example copy