One Claude Code Tip a Day: Teach Memory the Team Rules

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

A real failure: fixing the same “style issue” three times

The first time Claude Code imports from `@/components/ui/button`, it feels harmless. The test passes, the component renders, and the diff looks clean. Then the reviewer says the team uses relative imports inside packages because the app is a pnpm monorepo and aliases differ between Storybook, Vitest, and the deployment build. You correct Claude. Two days later, in a different session, it makes the same alias choice again.

That is the moment to use `/memory`. Not because every preference deserves to be remembered, but because some rules are expensive when Claude keeps rediscovering them. A good memory turns repeated corrections into durable operating instructions. A bad memory turns one accidental preference into global model superstition.

The command

In Claude Code, run:

`/memory`

Use it to inspect and manage what Claude should remember across sessions. The exact interface can vary, but the workflow principle is stable: save rules that are true beyond the current chat, especially project conventions, verification habits, deployment constraints, and “do not do this again” lessons.

Do not use memory as a dumping ground for today’s task. Use it for tomorrow’s mistakes.

Start with evidence, not preference

Imagine you are working in a payments dashboard. Claude adds a new `RefundBadge` component and the unit test passes locally. The build fails in CI because the package forbids path aliases and requires `date-fns` formatting through a shared wrapper.

Before writing memory, ask Claude to reconstruct the evidence:

`Read the CI failure, the current git diff, and the package README. Do not edit yet. Identify which conventions were violated, which are project-wide, and which are only relevant to this feature.`

Then inspect the answer. If Claude says “use relative imports everywhere,” that may be too broad. Maybe the rule is only true inside `packages/admin-ui`. If it says “always use the shared date wrapper,” verify that the wrapper is documented or consistently used:

`!grep -R "formatDisplayDate" packages/admin-ui src | head -20`

`!git diff --stat`

Only after you have evidence should you store the rule.

A practical memory-writing prompt

I like to make Claude draft the memory before saving it:

`We just found a durable convention. Draft one concise memory entry for this repo. It should include the rule, the scope, and the verification command that proved it. Do not save it until I approve.`

A useful draft might be:

`For this monorepo, inside packages/admin-ui, prefer relative imports over @/ aliases because Storybook and CI resolve aliases differently. Before changing imports, verify with pnpm --filter admin-ui test and pnpm --filter admin-ui build.`

That is much better than:

`Always use relative imports.`

What to save in memory

Save project conventions that repeatedly affect edits: import style, package manager, test command, deployment platform, branch policy, lint exceptions, database migration order, or frontend verification standards. For example:

`This project uses pnpm, not npm. For frontend changes, run pnpm test and pnpm lint before proposing a commit.`

`Railway deploys use the production DATABASE_URL from env. Never suggest localhost database URLs for deployed workers; inspect Railway logs and env names first.`

`For CSS text rendering bugs, verify with a screenshot or browser inspection before changing component logic. Invisible text has previously been caused by background-clip/text color interaction.`

What not to save

Do not save unresolved hypotheses. If the tax bug might be caused by rounding, but you have not confirmed it, keep that in the current session, not memory. Do not save temporary task state like “we are editing RefundBadge today.” Do not save secrets, tokens, private keys, customer data, or anything that should not travel across prompts.

Also avoid turning human frustration into policy. After one bad diff, it is tempting to write “never refactor helper functions.” That is probably not a rule. A better memory might be:

`Before refactoring shared helpers, show a git diff plan and list affected tests; do not combine behavior changes with formatting-only edits.`

Memory should guide Claude toward better process, not punish it for one failure.

Second-pass correction: audit memory when Claude behaves weirdly

Memory can also be the bug. If Claude keeps over-constraining a solution, check what it thinks it should remember:

`/memory`

Then ask:

`Review the active memory entries that influenced your plan. Which entries are relevant, which may be over-applied, and which should be narrowed or removed? Do not edit code.`

This matters in long-lived projects. A rule written during an old migration may become obsolete after the build system changes. If Claude refuses to use path aliases because of a six-month-old memory, the right fix is not another prompt fight. Narrow or remove the memory.

Verification after saving memory

After adding a memory, test it immediately in the current session:

`Restate the project rules you will follow for the next edit. Then propose the smallest change to RefundBadge and the exact commands you will run to verify it.`

You are checking whether the memory creates useful behavior. If Claude repeats the rule with the wrong scope, correct the memory before moving on. If it proposes the right commands and avoids the previous mistake, the memory is doing its job.

Finally, inspect the diff:

`!git diff`

The memory is not a substitute for review. It is a way to make the next review less repetitive.

Rule of thumb

Use `/memory` after the second time you correct the same durable mistake, not after the first inconvenience. Save rules with scope, reason, and verification. Remove or narrow memories when they become stale. The goal is not to make Claude Code “remember everything.” The goal is to make it stop forgetting the few things that keep breaking your real workflow.