You’ve got a working OpenClaw skill. It does its job. But every session it starts from scratch, and you’re tired of re-explaining things it should already know.

This guide walks through adding MemoClaw to a skill that already exists. No rewrite, no new architecture. Just a few targeted additions that give your skill persistent memory.

What we’re working with

I’ll use a real example: a code review skill that reads PRs and leaves comments. Before the retrofit, it treated every PR as if it had never seen the codebase before. After, it remembers past reviews, coding conventions it’s learned, and recurring issues it’s flagged.

The same pattern applies to any skill. Swap “code review” for whatever yours does.

The five-line pattern

At its core, adding memory to a skill comes down to five operations. You don’t need all of them in every skill, but here’s the complete set:

# 1. Recall relevant context at the start
memoclaw recall "relevant query here" --namespace my-skill --top-k 5

# 2. Store new learnings when they happen
memoclaw store --text "what you learned" --namespace my-skill --importance 0.7

# 3. Store corrections with high importance
memoclaw store --text "correction: X not Y" --namespace my-skill --importance 0.95

# 4. Tag for filtering
memoclaw store --text "detail" --namespace my-skill --tags "category,subcategory"

# 5. Recall with tag filter when you need specifics
memoclaw recall "query" --namespace my-skill --tags "category" --top-k 3

That’s the toolkit. Now let’s apply it.

Step 1: identify what’s worth remembering

Before adding any code, ask: what does this skill forget that it shouldn’t?

For the code review skill, the answer was:

• Coding conventions: the team uses snake_case, prefers early returns, avoids ternaries for complex conditions
• Past feedback: “I already flagged this pattern in PR #34, and the team decided to keep it”
• Codebase patterns: “This repo uses a repository pattern for data access, not direct ORM calls”
• False positives: “Don’t flag single-letter variables in list comprehensions, the team is fine with them”

Your skill will have its own version of this list. Write it down before you start coding. It keeps you from over-storing everything.

Step 2: add recall at the start

Open your skill’s SKILL.md (or wherever the agent instructions live). Add a recall step before the skill does its main work.

Before:

## Instructions

When asked to review a PR:
1. Read the diff
2. Check for common issues (naming, error handling, complexity)
3. Post comments on specific lines

After:

## Instructions

When asked to review a PR:
1. Recall relevant context:
   - `memoclaw recall "coding conventions and review preferences" --namespace code-review --top-k 5`
   - `memoclaw recall "past feedback on similar patterns" --namespace code-review --top-k 3`
2. Read the diff
3. Check for common issues, informed by recalled conventions
4. Post comments on specific lines

Two recall calls at the start. That’s $0.01 and maybe 200 tokens of context. Compare that to a MEMORY.md file that keeps growing and eating your context window.

The beauty of semantic search: the query “coding conventions and review preferences” will find relevant memories even if they were stored with completely different wording. You don’t need exact keyword matches.

Step 3: add store after meaningful interactions

This is where most people over-engineer it. You don’t need to store everything. Store when:

• The user corrects the skill (“actually, we use tabs not spaces”)
• The skill learns something about the codebase (“this repo uses dependency injection”)
• A decision is made (“team decided to allow any in API boundary types”)

Add store instructions after the review step:

5. After the review, store any new learnings:
   - If the user corrected your feedback:
     `memoclaw store --text "Correction: [what you learned]" --namespace code-review --importance 0.9 --tags "correction"`
   - If you discovered a codebase pattern:
     `memoclaw store --text "Pattern: [what you found]" --namespace code-review --importance 0.6 --tags "codebase,pattern"`

Notice the importance scores. Corrections get 0.9 because the skill should never repeat a mistake. Patterns get 0.6 because they’re useful but not critical.

Step 4: handle the “I already told you this” problem

The worst thing a memory-enabled skill can do is ask something it was already told. To prevent this, make the recall step part of the skill’s identity, not just an optional optimization.

Add this to your skill’s instructions:

## Memory protocol

Before asking the user any question, first recall from MemoClaw to check
if the answer is already stored. If you find it, use it without asking.

If the user says "I already told you this" or corrects repeated behavior:
- Store the correction with importance 0.95
- Apologize once, then move on

This is the difference between a skill that technically has memory and one that feels like it remembers.

Step 5: pick a namespace and stick with it

Give your skill its own namespace. Use the skill name:

--namespace code-review

If your skill handles multiple projects, consider project-scoped namespaces:

--namespace code-review-myapp
--namespace code-review-client-acme

Don’t overthink it. One namespace per skill is fine for most cases. Split later if recall gets noisy.

The before and after

Here’s the full SKILL.md diff for the code review skill:

 ## Instructions
 
 When asked to review a PR:
+1. Recall relevant context:
+   - `memoclaw recall "coding conventions and style preferences for this repo" --namespace code-review --top-k 5`
+   - `memoclaw recall "past review corrections and false positives" --namespace code-review --tags "correction" --top-k 3`
-1. Read the diff
-2. Check for common issues (naming, error handling, complexity)
-3. Post comments on specific lines
+2. Read the diff
+3. Check for common issues, applying recalled conventions
+4. Post comments on specific lines
+5. Store new learnings:
+   - Corrections from the user → importance 0.9, tag "correction"
+   - New codebase patterns → importance 0.6, tag "pattern"
+   - Team decisions → importance 0.8, tag "decision"
+
+## Memory protocol
+
+Before asking the user a question, recall from MemoClaw first.
+Use the `code-review` namespace for all operations.
+If the user corrects repeated behavior, store with importance 0.95.

That’s the whole change. The rest of the skill stays the same.

Cost of adding memory

For a typical code review session:

• 2 recall calls at start: $0.01
• 1-2 store calls for learnings: $0.005-$0.01

About $0.02 per review session. If you’re on the free tier (100 calls per wallet), that’s roughly 40 review sessions before you need to set up payments.

Compare that to the cost of re-explaining your team’s conventions every single time. The first correction the skill remembers pays for a month of API calls in saved frustration.

Common mistakes when retrofitting

Storing too much. Not every line of conversation needs to be a memory. If you’re storing more than 2-3 memories per session, you’re probably over-indexing. Recall quality drops when there’s too much noise.

Storing raw conversations. “User said: can you check PR #42? Agent said: sure, I’ll look at it.” That’s a transcript, not a memory. Store the takeaway: “PR #42: team prefers explicit error types over generic Error class.”

Forgetting importance scores. Everything at default importance means nothing gets prioritized. Use the full range. A coding convention is more important than a one-time observation.

Skipping the recall step. Storing without recalling is a write-only database. If your skill stores memories but never reads them back, you’ve added cost without benefit. Recall first, always.

Try it on your own skill

Pick a skill you use often. Ask yourself: what does it keep forgetting? That’s your starting point.

Add a recall at the start, a store for corrections, and a namespace. Run it for a week. You’ll notice the difference the second time it remembers something you only told it once.

That’s the whole retrofit. No SDK, no database, no infrastructure. Just a few MemoClaw calls woven into the instructions you already have.