remember

Overview of remember skill

What remember does

The remember skill is a focused Knowledge Capture skill for explicitly saving facts, conventions, decisions, and gotchas into Claude auto-memory when they are too important to leave to automatic capture. It is designed for moments like “we finally found the CI issue,” “this project has an undocumented convention,” or “Claude should not forget this team preference.”

Instead of asking the assistant to “keep this in mind” and hoping it persists, remember gives the agent a repeatable workflow: parse the knowledge, check for duplicates, and write a contextual memory entry with a timestamp.

Best-fit users and teams

Use the remember skill if you work with long-running projects where recurring context matters: engineering teams, solo developers with multiple repositories, AI-assisted debugging workflows, or agents that need to improve over time. It is especially useful when important knowledge lives in chat history but not yet in CLAUDE.md, documentation, tests, or code comments.

The skill is not a full knowledge base, note-taking app, or documentation generator. Its job is narrower: preserve compact, actionable memory that should influence future Claude sessions.

Why this is different from a normal prompt

A normal prompt like “remember this” is ambiguous. The remember skill adds operational discipline: it asks what should be remembered, why it matters, and whether the memory is project-specific or global. It also includes a duplicate-check step so the memory file does not become noisy with repeated versions of the same fact.

That makes remember valuable when the cost of forgetting is high: repeated debugging, wrong tool choices, ignored coding conventions, or preference drift.

How to Use remember skill

remember install and source review

Install the skill from the repository with your skill manager, for example:

npx skills add alirezarezvani/claude-skills --skill remember

Then inspect the source at:

engineering-team/self-improving-agent/skills/remember/SKILL.md

This skill is compact and has no separate scripts/, references/, rules/, or resources/ directories in the repository preview, so SKILL.md is the main file to read. Pay attention to the usage examples, duplicate-check command, and memory-entry workflow before relying on it in a production agent setup.

Basic remember usage

Call the skill with /si:remember followed by the exact knowledge you want saved:

/si:remember "This project's CI requires Node 20 LTS — v22 breaks the build"

Good inputs are specific, durable, and actionable. Weak input says:

/si:remember "CI is weird"

Strong input says:

/si:remember "CI fails on Node 22 because the build image expects Node 20 LTS; use Node 20 for local reproduction and GitHub Actions parity"

The stronger version tells future Claude what happened, where it applies, and what action to take.

What to include in the prompt

For best results, include four pieces of information:

• Fact: the thing Claude should retain.
• Context: where it applies, such as a repo, endpoint, test suite, tool, or team.
• Reason: why forgetting it causes bad output.
• Scope: whether it is project-specific or a general preference.

Example:

/si:remember "Project-specific: In this repo, API auth uses a custom JWT library instead of passport. Do not recommend passport middleware unless we are replacing the auth layer."

This gives the skill enough material to create memory that is useful later, not just a vague note.

Practical workflow for Knowledge Capture

Use remember immediately after a discovery, decision, or correction. The best timing is when the information is fresh and before the conversation moves on.

A practical flow:

1. Discover a durable fact during debugging, review, or planning.
2. Convert it into one sentence with context and consequence.
3. Run /si:remember "<fact>".
4. Let the skill check for duplicate memory.
5. If a similar entry exists, update or clarify instead of adding noise.
6. Continue work with the new memory available for future sessions.

This workflow keeps memory useful without turning it into a transcript.

remember skill FAQ

When should I use remember?

Use remember when the knowledge is likely to affect future work and is not already obvious from the codebase or documentation. Good candidates include build requirements, framework constraints, architectural decisions, recurring test issues, undocumented conventions, and stable user or team preferences.

Do not use it for temporary task state such as “I am currently editing file X” unless that fact will matter after the session ends.

Is remember suitable for beginners?

Yes, because the command is simple, but beginners should be careful not to store vague or emotional notes. A memory like “the database is annoying” will not help. A memory like “Local DB tests require Docker Compose service postgres-test to be running before npm test” is useful.

The skill works best when the user can describe the operational lesson clearly.

How does remember compare with CLAUDE.md?

CLAUDE.md is better for stable, shared project instructions that every future agent should read as part of the repo. remember is better for incremental learning, hard-won discoveries, and context that may not be ready for formal documentation.

A good pattern is to use remember first, then promote repeated or team-wide memories into CLAUDE.md, README files, tests, or architecture docs.

When should I not use remember?

Do not use remember for secrets, credentials, private tokens, or sensitive personal information. Do not use it as a replacement for source-controlled documentation when the knowledge should be visible to the whole team. Also avoid saving guesses, unresolved theories, or one-off observations unless you clearly label them as uncertain.

Memory should reduce future mistakes, not preserve speculation.

How to Improve remember skill

Improve remember results with sharper inputs

The biggest quality lever is the input sentence. Before calling remember, rewrite rough discoveries into durable guidance.

Rough:

/si:remember "Jest hangs sometimes"

Better:

/si:remember "Project-specific: Jest integration tests can hang after DB tests unless run with --forceExit; use this flag when reproducing CI test hangs locally."

This version names the tool, condition, workaround, and scope. That makes the saved memory easier for Claude to apply correctly.

Avoid duplicate and stale memory

The upstream workflow includes a duplicate check against the project memory file. Respect that step. Duplicate memories create conflicting guidance, especially when a convention changes over time.

If you find an older entry, prefer revising the memory conceptually: “This replaces the old Node 18 note; the project now standardizes on Node 20 LTS.” Clear supersession is better than accumulating contradictory facts.

Turn repeated memories into documentation

If the same remembered fact affects multiple contributors, promote it out of memory. Add it to CLAUDE.md, README.md, onboarding docs, test setup notes, or architecture decision records. remember is excellent for capture, but source-controlled documentation is better for shared governance.

A useful rule: if Claude has needed the memory more than twice, humans probably need it too.

Common failure modes to watch

The main failure modes are over-saving, under-scoping, and saving conclusions without evidence. Avoid entries that are too broad, such as “always use explicit error handling,” unless that is truly a global preference. Prefer scoped guidance: “In this repo, avoid catch-all error handlers in API routes because errors are logged by middleware.”

Good remember usage creates compact, contextual memory that improves future assistance without making the agent rigid or noisy.