Agent Skills vs Procedural Memory: What's the Difference?
A skill and an auto-memory note can hold the same procedure, and an agent can write either one. What differs is whether a reviewer sees it, where it loads from, and whether it leaves the machine.
DosuA skill and an agent's own memory note can hold the same procedure, and an agent can write either one. Anthropic's guidance on developing skills is to ask Claude to capture its successful approaches and common mistakes into a skill, so who typed it first does not separate the two. What separates them is what happens to the procedure next: whether a reviewer sees it, where it loads from, and whether it ever leaves the machine it was written on.
Both terms cover a lot of ground, so this piece compares two concrete things: a reviewed skill committed to your repository, and the auto-memory notes Claude Code keeps per repository. Procedural memory is retained how-to knowledge, and a repository skill can carry it just as well as a memory note can.
What a repository skill is, and when it loads
A skill is a directory holding a SKILL.md file of instructions, plus any scripts or reference files it needs. In Claude Code these are filesystem-based, at ~/.claude/skills/ for your own and .claude/skills/ for a project, which is what makes a project skill reviewable: it is a file in the repository, it arrives through a pull request, and git log says when the procedure last changed.
Loading is staged by default. Skill descriptions sit in context so the agent knows what is available, and the body of SKILL.md loads when the skill is invoked, either by the agent matching your request against the description or by you typing the skill's name. Claude Code documents exceptions to that default worth knowing before you budget context: a skill marked disable-model-invocation: true keeps its description out of context entirely and runs only when you invoke it, and a subagent with preloaded skills gets the full skill content injected at startup. Running a bundled script through bash puts only its output in context, though a file in the skill directory read as reference material enters context like any other file.
The required-fields question depends on which surface you mean. The Agent Skills format as documented for the Claude API requires name and description in the YAML frontmatter. In Claude Code every frontmatter field is optional: name defaults to the directory name, and description falls back to the first non-empty line of the body. A description is still the field worth writing carefully, because it is what the agent matches a request against.
What Claude Code's auto memory keeps, and what loads from it
Auto memory is Claude Code's own store of retained how-to knowledge: notes Claude writes from your corrections and from what it works out, during the session rather than in a tidy pass afterwards. Claude Code's documentation sets it beside instruction files directly. CLAUDE.md holds instructions and rules you write. Auto memory holds learnings and patterns Claude writes.
What loads from it is narrower than the store itself. Each project gets ~/.claude/projects/<project>/memory/, holding a MEMORY.md index plus one file per memory, with the project path derived from the git repository so every worktree in that repo shares one directory. Only the first 200 lines of MEMORY.md, or the first 25KB, load at the start of a conversation. Topic files are not loaded at startup at all. Claude reads them on demand with its ordinary file tools when the index suggests one is relevant. You can browse and edit all of it with /memory, and switch the whole mechanism off for a project with autoMemoryEnabled.
One documented property matters more than the rest for a team: auto memory is machine-local, and the files are not shared across machines or cloud environments. What your agent retained stays with your agent, which is the gap our guide to team memory for coding agents works through.
Review, loading, and sharing
| Reviewed repository skill | Claude Code auto memory | |
|---|---|---|
| Where review happens | The pull request that adds or changes the file | After the fact, by reading what was stored |
| When it loads | Description normally available, body on invocation | MEMORY.md index at startup, topic files on demand |
| How it travels | With the repository, through version control | With the machine, unless you add a shared store |
| How it goes wrong | Keeps teaching the old procedure until someone edits it | Keeps recalling a workaround after the fix landed |
| What it suits | Procedures a reviewer should see and everyone should get | Working knowledge for one agent on one machine |
Which one should hold a given procedure
Claude Code's documentation gives a routing rule for instruction files that transfers cleanly: if an entry is a multi-step procedure, or only matters for one part of the codebase, move it into a skill or a path-scoped rule rather than the file that loads every session. Extend it with the two questions the table above raises. Should a person approve this before other people's agents follow it? Does it need to reach anyone beyond this machine?
Two yeses means a repository skill. A deploy runbook, a release checklist, the way integration tests get their services started: you want a reviewer on changes to them and you want every engineer's agent working from the same copy.
Two noes means leave it in memory. An agent spends two failed runs working out that the staging seed script needs the migration applied first. It is useful now, it may not outlive the sprint, and nothing is gained by routing it through review yet.
A third kind of rule belongs in neither. Claude Code treats both instruction files and auto memory as context rather than enforced configuration, and points at a PreToolUse hook when you need an action blocked regardless of what the agent decides.
Each one fails in its own way
A skill fails by sitting still. The test command changes, the file does not, and every agent that loads the skill follows the old one. That failure is at least legible: the file has a history, and you can compare its last change against the code it describes.
Memory fails by remembering accurately. A workaround retained while a test was broken still reads as true after the fix lands, and nothing in an ordinary session rechecks it. Deciding which notes to retire, and what event should trigger the retirement, is its own job, covered in how to prune stale agent memory.
The third failure is quieter than both. A long procedure pasted into the always-loaded instruction file spends context in every session on steps most tasks never touch, which is the case the routing rule above exists to prevent.
Turning a recurring note into a reviewed skill
When the same note keeps coming back across sessions and across engineers, it has earned a review. Ask the owner to reproduce it, decide whether it holds for the whole repository, and land it as a SKILL.md that goes through review like any other change. Our walkthrough of procedural memory for coding agents covers writing that file so another agent can follow it, including how to describe failure handling.
An agent can draft that file for you, which is the point of asking it to capture what worked. The review is what changes its status, not the typing. Afterwards, clear the memory note that still describes the old workaround, because two stores that disagree are worse than either alone.
Where Dosu fits for teams running several agents
Repository skills solve review and reach for procedures you can commit. They do not solve the part where one engineer's agent retains something useful and nobody else's does, because those notes sit on that machine.
Dosu is knowledge infrastructure for engineering teams and the coding agents they work with. Connect a repository as a Source to ground generated Documents. With Monitor and Library review enabled, Dosu checks published Documents for drift against the pull requests that caused it and proposes updates for review, rather than editing anything silently.
Agent access is separate from that. The Dosu MCP server lets agents retrieve relevant Documents and shared notes through read_knowledge, and record working knowledge through write_knowledge. It works with any MCP-compatible client, including Claude Code, Cursor, and VS Code Copilot, so a note one agent records can be retrieved by a teammate's agent in a different tool. Monitors maintain published Documents, not arbitrary agent notes. A stable procedure you want followed the same way every time still belongs in a reviewed file next to the code.
FAQ
Does Claude Code have procedural memory, or only skills?
Both, and they overlap. A repository skill can carry procedural knowledge that a person or an agent wrote. Auto memory is the store Claude Code maintains itself, per repository under ~/.claude/projects/, where the MEMORY.md index loads at session start and topic files are read on demand. Auto memory is machine-local by design, so treat it as that agent's working memory rather than the team's.
Do Cursor and Codex draw the same line?
Each tool has its own instruction files, skill support, and loading rules, and the mechanics above are Claude Code's documented behavior, checked November 4, 2026. Before assuming a procedure loads or persists the same way elsewhere, check that tool's current documentation. Our comparison of AGENTS.md, CLAUDE.md, and .cursorrules covers which instruction file each one reads today.
Can a skill and a stored memory note contradict each other?
Yes, and the agent has no rule that settles it for you. Claude Code's documentation says contradictory instructions may be resolved arbitrarily, because these files are context rather than enforced configuration. So treat promoting a note as a two-step change: land the skill, then remove or correct the note it replaces.
Check one procedure your agents keep rediscovering
Pick a procedure your team has explained to an agent more than once this month. Run /memory in Claude Code to see what it stored for that repository, and read the note against the current code. If a reviewer should approve it and everyone's agent should get it, move it into a .claude/skills/<name>/SKILL.md and send it through review. If it is working knowledge for one task, leave it in memory and pick a date to recheck it.
Then test whether it can reach anyone else. Create a Library and connect the repository to Dosu, which needs owner or admin rights in your organization, then run npx @dosu/cli setup to point your agent at it. Record the procedure with write_knowledge and confirm the note anchored to the repository and branch you meant, since an unresolved anchor downgrades the write instead of failing it. Then have a teammate with Library access call read_knowledge for that same repository and branch, find the note in the returned index, and fetch it in full by note_id. That round trip is the whole claim, tested.
Sources
Claude Code and Agent Skills behavior above is from Anthropic's Agent Skills documentation, its Claude Code skills and memory pages, and its guidance on developing skills, all checked November 4, 2026. Dosu behavior is from the Dosu product documentation for Sources, Monitors, and the Dosu MCP server.