Stop Repeating Yourself: How to Make Claude Code Actually Remember

Claude Code has a full set of tools for keeping context between sessions. Most people never touch them because they look intimidating or “too developer-y.” They’re not. And once you start using even one or two, you’ll wonder how you worked without them.

As a personal note – I choose not to use the memory feature in Claude as I enjoy having a less biased canvas to work from at the start of each session. I use ChatGPT with memory for more memory-based discussions – usually on a more health and personal area than the use case I have for Claude and Claude code.

If at any point, I want to include memory from one LLM to another – they have easy ways to transfer memory from one to the other, so I don’t feel that I’m missing out. Idea for another article and another day.

This article covers more structured and targeted way of controlling memory, instructions and context between sessions.

We’ll go from simplest to most powerful. Start wherever feels comfortable.

Updated October 2026: added mods, a newer kind of plugin that changes Claude Code itself, and corrected how you add quick memories and set up hooks.

Layer 1: Give It a Memory (CLAUDE.md)

This is the single highest-value change you can make. If you do nothing else from this article, do this.

CLAUDE.md is a file that lives in your project. Claude reads it at the start of every session. Think of it like leaving sticky notes for a coworker who forgets everything overnight — your stack, your conventions, the commands that actually work, the mistakes you don’t want repeated.

Side note: Most LLMs have the concept or a core file that controls project context, in this case with Claude it is CLAUDE.md but I’ve seen others like AGENTS.md or soul.md, while the names may vary by model -the core concept remains the same.

A basic one might look like this:

# My Workout App

## Stack
React Native + Expo, Firebase Firestore, TypeScript

## Build & Run
npm start — launches Expo dev server
npm test — runs Jest tests

## Important Patterns
- All database calls go through /services/firebase.ts
- Navigation uses React Navigation v6
- Never use inline styles — everything goes in /styles/

## Mistakes Claude Has Made Before
- Don't modify App.tsx directly for navigation changes
- The Firestore security rules live in firestore.rules, not in the app code
- Always run TypeScript checks before calling something done

That’s it. No special syntax, no configuration. Just a markdown file named CLAUDE.md in your project root.

Every time Claude makes a mistake, end with: “Update CLAUDE.md so you don’t make that mistake again.” Claude is surprisingly good at writing rules for itself. Over time, this file becomes a living document that measurably reduces errors.

Where it goes:

• CLAUDE.md in your project root — applies to that project
• ~/.claude/CLAUDE.md — applies to everything, everywhere

If you work on CLAUDE.md file for an extended period of time, review it from time to time and run a clean-up on the file. By default, I’ve noticed Claude will capture too many details like session logs, other factors that could be stored in more tailored files. Instead of keeping sessions history in Claude.md for example, point it to sessionlog.md where that can be kept separately and only read when needed.

Note: I am a novice with file management and there are best practices and standards that are also evolving over time – while the concepts I’m reviewing are valid and important, do not take my suggestions as the end of the learning path. Keep going, ask your LLM how to structure your project folders for best practices as of [TODAYS DATE].

Pro tip: You don’t have to open the file to add a rule. Tell Claude something like “Add this to CLAUDE.md: always use TypeScript strict mode” and it writes the rule in for you. If you say “Remember that…” instead, Claude saves it to its auto memory.

To view/audit Claude Code’s memory:

• /memory — Run this during any session to open the memory file selector. It shows all your memory files (CLAUDE.md, auto memory, local config) and lets you open any of them in your system editor. Claude Fast
• ctrl+o — When you see “Recalled X memories” or “Saved X memories” during a session, both messages include a ctrl+o to expand prompt so you can inspect exactly what was recalled or written. Claude Fast
• Browse the files directly — Each project gets its own memory directory at ~/.claude/projects/<project>/memory/. The directory contains a MEMORY.md entrypoint and optional topic files Claude like debugging.md or api-conventions.md. They’re plain markdown — you can read, edit, or delete anything in there.

Layer 2: Stop Re-Typing Your Best Prompts (Slash Commands & Skills)

You know that prompt you keep writing? The one where you ask Claude to review your code a certain way, or generate a component following your patterns, or run through a checklist before you push?

Stop rewriting it. Save it as a skill.

Skills are just markdown files that become slash commands. Create a folder, drop in a file, and you’ve got a reusable command you can call anytime.

Here’s a real example — a /review command:

mkdir -p .claude/skills/review

Then create .claude/skills/review/SKILL.md:

markdown

---
name: review
description: Reviews code for bugs, edge cases, and missed requirements
---

Review the most recent changes for:

1. Logic errors and edge cases
2. Missing error handling
3. Breaking changes to existing functionality
4. TypeScript type issues

Be direct. If something looks fine, say so briefly and move on.
Don't comment on style or naming unless it causes actual confusion.

Now when you type /review in Claude Code, it runs that exact prompt. Every time. No rewriting, no forgetting the parts that matter.

Some other skills worth building early:

• /plan — “Before writing any code, outline what you’ll change and why. Wait for my approval before proceeding.”
• /test — “Write tests for the most recent changes. Focus on edge cases, not happy paths.”
• /cleanup — “Scan for TODOs, dead code, and unused imports. Fix them one at a time.”

Think of these like recipes. You write them once, and they get better every time you refine the instructions. They’re also committed to git, so they evolve with your project — and if you work with anyone else, they can use them too.

Why this matters more than it sounds: Without skills, your prompting quality is inconsistent. Sometimes you remember to ask Claude to check edge cases. Sometimes you forget. Sometimes you’re thorough. Sometimes you’re rushing and you skip the important parts. Skills standardize your best prompting, so even your lazy Tuesday afternoon sessions run the same quality checks as your focused Saturday morning ones.

Layer 3: Make Things Happen Automatically (Hooks)

Slash commands are things you run on purpose. Hooks are things that happen on their own at specific moments — before Claude edits a file, after it finishes writing, when a session starts.

This is where things start feeling less like chatting and more like building an actual development environment.

A few examples that are genuinely useful:

Auto-format code after every edit: When Claude writes messy formatting (and it will), a hook can run Prettier or Black automatically so you never have to think about it.

Run type checks before accepting changes: Instead of discovering TypeScript errors three steps later, catch them the moment Claude finishes writing.

Set the date at session start: Claude sometimes thinks it’s 2024. A hook that runs a quick date script at the start of every session fixes this permanently.

To set one up, describe the hook you want to Claude, for example “After every file edit, run the TypeScript check”, and it writes the configuration into your settings file for you. Then type /hooks to open a read-only list of your hooks and confirm the new one is there. You only need to touch the JSON yourself if you want to.

Here’s a concrete example. I was working on my workout app and kept running into the same issue: Claude would edit a TypeScript file, I’d accept the changes, and then five minutes later I’d discover a type error that broke something else. Every time. The fix was a simple hook — after any file edit, run npx tsc --noEmit to check types. Now the errors surface immediately instead of hiding until I’m three changes deep.

The honest truth about hooks: most beginners won’t need them right away. They shine when you’ve been using Claude Code regularly enough that certain manual steps start feeling tedious. You’ll know when you’re ready because you’ll catch yourself thinking “I do this every single time — why isn’t this automatic?”

That thought is your signal.

Layer 4: Grab What Others Have Already Built (Plugins)

You don’t have to build everything yourself.

Claude Code has a growing plugin ecosystem — over 2,000 skills and hundreds of community-built plugins available through the marketplace. Some are brilliant. Many are mediocre. A handful are genuinely useful for beginners.

To browse what’s available, type /plugins in Claude Code and select “Discover.” You can install plugins with a single command and toggle them on or off as needed.

Worth looking at early on:

• Code review plugins that spawn multiple reviewers checking security, testing, and code quality separately
• Project management skills for organizing tasks and tracking progress
• Git workflow skills that standardize how you commit, branch, and push

A few places to explore beyond the built-in marketplace:

• The official Anthropic docs have first-party examples
• GitHub search for “claude skill” surfaces hundreds of project-specific setups
• Community directories like claudemarketplace.com curate the better options

The key thing to understand: plugins are just bundles of the same building blocks we covered above — skills, hooks, and slash commands, packaged together so you can install them in one step instead of building from scratch.

Don’t install everything at once. Pick one that solves a problem you’re actually having. And keep an eye on your /context — that command shows you how much of your context window is being used. If you’ve installed five plugins and wonder why Claude feels slower or less focused, that’s probably why.

Mods: plugins that change Claude Code itself

One newer kind of plugin adds a building block of its own: the mod. A mod is made of small JavaScript or TypeScript handlers that run when something happens, such as you submitting a prompt or Claude calling a tool. It can watch that moment, change it or take it over. That lets a mod do things the other layers can’t: draw a panel beside the conversation or a band above the prompt, hold a tool call while it asks you something, or add a /command that runs straight away.

You don’t need to write the code. Describe the mod you want in a Claude Code session and Claude builds it with its built-in plugin-authoring skill. Mods install like any other plugin, from a marketplace, and work in the terminal from Claude Code v2.1.287, in the desktop app’s Code tab from v2.1.286 (check with /status), and in the VS Code extension.

Two examples from YouTube creator Ben AI fit this article well:

• Reflect watches your prompts for a hard rule, something like “never use em dashes,” and asks whether to save it to memory or to CLAUDE.md. It catches the rules you state once in passing and would otherwise have to repeat next session.
• Handoff does the same for a whole session. At about 250,000 tokens it writes a detailed handoff prompt and gives you a button to start a fresh chat with it, so the new session starts where the old one stopped.

Treat a mod like any code you install. Anthropic’s own docs put it plainly: “A mod is code that runs with your permissions.” Mods aren’t sandboxed. One can read your files and environment variables, including API keys, see every prompt and tool call, approve a tool call before you’re asked, and spend your usage by calling a model. Before you install one, get its files and run claude plugin validate on its folder in your terminal (for example claude plugin validate ./some-mod). It lists the events the mod handles and what it calls, without running it. To switch a mod off, disable it in /plugin under Installed, or start Claude Code with --safe-mode to run one session without any.

The Honest Downside

None of this is free. Here’s what you should know:

Your usage goes up. CLAUDE.md, skill descriptions, and plugin configurations all eat context window space. Every skill you enable adds to what Claude processes each session. If you’re on a Pro plan watching your message count, this matters. Keep 3-5 active plugins maximum and disable what you’re not using.

Complexity creep is real. It’s tempting to build elaborate systems of hooks and skills before you need them. Don’t. Every layer you add is a layer you maintain. Start with CLAUDE.md, add one or two skills when you notice repetition, and let the rest come naturally.

Debugging gets harder. When Claude does something unexpected, you now have more places to check — was it the CLAUDE.md? A skill? A hook? A plugin? A mod? Keep your setup simple enough that you can trace problems back to their source.

The ecosystem is still young. Quality varies wildly across community plugins. The official Anthropic marketplace is curated, but third-party directories range from excellent to abandoned. Test before you trust.

If You Only Do Two Things

If all of this feels like a lot, start here:

1. Create a CLAUDE.md with your project basics and update it every time Claude makes a mistake.
2. Save one frequently-used prompt as a skill — whatever you type most often.

That alone changes the dynamic from “chatting with AI” to “building on a system that gets smarter.”

Everything else can wait until you feel the pull.

Quick Reference

The gap isn’t access to AI. It’s whether you’re treating it like a conversation or a system.

Most people are still chatting.

You don’t have to be.