| name | memorize |
| description | Persist memory across sessions. |
| user-invocable | true |
| allowed-tools | ["Read","Write","Edit","Bash"] |
Memorize
Persist a single fact or preference so it survives across sessions, machines,
and agents. remember / /remember and always / /always are synonyms
for this skill — same behavior; the wording the user happens to use doesn't
change anything.
Unlike ums (which reviews the whole session and may also update skill
definitions), this stores exactly what the user says — no scanning, no skill
updates. Memory files — and ~/.claude/CLAUDE.md — are symlinked into the
ai-config repo, so memorize commits and pushes the one change; otherwise
the note is lost when the session ends (ephemeral cloud containers are
reclaimed) and never syncs elsewhere.
When this fires
- "memorize …", "remember that …", "/remember …", "note that …",
"add to memories: …"
- A standing directive phrased as a preference: "always …", "never …",
"I prefer …", "from now on …"
First: is it actually a memory?
If the request is an automated every-time action ("after each commit run
X", "whenever I edit Y do Z"), memory can't execute it — that needs a hook
in settings.json / settings.local.json (use the update-config skill).
Say so and route it there; don't store a note that will never fire.
Unsure whether a request is really a memory versus a skill, subagent, hook, or
gha capability? config-ai (ca/cai) is the broader router across all of
those forms — this skill is what it hands off to once memory is the answer.
Procedure
-
Parse the fact/preference from the user's message.
-
Choose scope by relevance:
- Project-specific, a repo we own — a fact, convention, or gotcha tied
to ONE specific repo we own ("renders with renv via
R_LIBS_USER") →
commit it to that project's own repo via a PR (its CLAUDE.md,
.github/copilot-instructions.md, or whatever agent-doc infrastructure
it already has), so the whole team and every @claude session there
can see it. (NOT memories/repo/ inside ai-config; that directory is
removed.) If the repo has no agent-doc infrastructure yet, write to its
local Claude project memory instead —
~/.claude/projects/<project-path>/memory/<file>.md — as short-lived
staging only, not a durable destination, and tell the user a PR
adding agent-doc infrastructure to that repo (plus migrating the staged
memory there) is still needed. The project path is the repo's
directory path with / replaced by - — e.g.
/Users/you/Documents/GitHub/rme → -Users-you-Documents-GitHub-rme.
Update MEMORY.md in that directory as an index entry when you used
this local-staging fallback — not when the fact was committed directly
to the owned repo's own agent docs, which needs no local copy.
- Project-specific, an external repo we don't own — never open a
direct PR autonomously. Route it through
upstream-issues: check
the repo's contribution policy first (some ban autonomous AI PRs/issues
outright), then draft and get explicit user approval before posting
anything. Until approved, stage the fact in that repo's local Claude
project memory as short-lived, not-yet-durable staging, and update
MEMORY.md there as an index entry too.
- General standing rule — an always-apply working preference across ALL
repos ("always link PRs in tables", "use Pacific time") →
~/.claude/CLAUDE.md (it's loaded every session)
- General reference fact — a cross-project fact that only matters when
relevant ("gh opens a pager — pipe to cat") → a topical file in
/memories/, or tools.md for what fits none of them.
Read memories/MEMORY.md for the current set and what each one covers;
it is the registry, so naming the files here too would only go stale.
When you add a file here (not just a bullet to an existing one),
register it in as an index entry.
Don't
- Don't run a full session review or touch skill files (that's
ums).
- Don't commit unrelated changes — stage only the file you wrote.
- Don't push conversation-only (
/memories/session/) notes to the shared repo.
- Don't store secrets, tokens, or passwords.
- Don't over-elaborate — one bullet per fact.