One Claude Code Tip a Day: Keep Team Rules in /memory

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

The failure: memory becomes a junk drawer

The tempting way to use Claude Code memory is to save everything that felt useful today. A flaky checkout test failed on staging? Save it. The auth service had a weird timeout? Save it. Claude misunderstood a component boundary? Save that too. After a few weeks, every new session starts with a pile of stale warnings that sound authoritative but may no longer be true.

Today's tip is to treat `/memory` as a place for durable team rules, not as a transcript archive. Good memory makes Claude Code safer before it has read the repo. Bad memory makes it confidently avoid old ghosts. The difference is whether the note would still help a teammate next month after the bug that produced it is gone.

Use /memory for rules that survive the session

In a real project, the best candidates are boring and repeatable: the command that actually runs the focused test suite, the directory that contains generated files Claude should not edit, the rule that migrations must be reviewed separately, or the fact that visual changes require browser verification, not just a passing build.

Start by asking Claude to propose memory entries before saving anything:

Prompt: `Review this session and propose at most three /memory entries. Only include durable project rules that should affect future sessions. Exclude bug-specific theories, temporary file paths, one-off logs, and anything that should live in an issue comment instead. For each entry, explain why it will still be true in 30 days.`

Then inspect the proposal like code. If an entry says `checkout is flaky on staging`, reject it. That is an incident note. If it says `For checkout UI changes, verify with pnpm test:e2e -- checkout and a browser pass through /checkout because unit tests do not cover the payment iframe`, that is closer to a durable workflow rule.

A practical /memory workflow

Use the command deliberately:

Command: `/memory`

When the memory editor or memory flow opens, add rules in short, testable language. I like this shape:

Example memory: `In this repo, do not edit files under src/generated/. Regenerate them with pnpm codegen and review the resulting diff instead.`

Example memory: `For frontend fixes, verify the relevant route in a browser after tests pass; CSS and hydration issues have escaped unit tests before.`

Example memory: `Before changing database migrations, ask for a separate migration plan and rollback note.`

Notice what is missing: no stack trace from Tuesday, no guess about the current root cause, no reminder that one branch had a bad environment variable. Those facts belong in the issue, a runbook, or today's handoff prompt. `/memory` should make the next session start with better guardrails, not yesterday's noise.

Pair memory with an explicit first prompt

Memory is not a substitute for reading the code. In fact, durable memory should make Claude more careful about what it has not inspected. After saving a new rule, start the next relevant session with a prompt that forces Claude to combine memory with fresh evidence:

Prompt: `Use the project memory as constraints, but do not assume it describes the current bug. First read the relevant files, identify which memory entries apply, and list any entries that might be stale or irrelevant before proposing edits.`

This is especially useful on teams. One developer may add a memory rule after fixing a deployment loop; another developer may later use Claude for a small UI copy change. The rule should help Claude choose safer verification, but it should not hijack the task. Asking Claude to name applicable and irrelevant memory entries prevents memory from becoming hidden prompt magic.

Failure modes to watch for

The first failure mode is storing conclusions instead of constraints. `The cache layer is the problem` will age badly. `When changing cache behavior, verify with the stale-navigation Playwright spec and inspect response headers` gives future Claude Code something to prove.

The second failure mode is storing preferences that are really personal habits. If you like verbose explanations, keep that in your own workflow. Project memory should be useful to the repo, not just to one session style. The third failure mode is never pruning. A monthly memory review is worth the five minutes: ask Claude to list entries, mark anything that conflicts with current files or scripts, and propose deletions before adding new rules.

Use a second-pass correction whenever Claude cites memory too aggressively. A good prompt is: `Which part of that answer came from memory rather than current repo inspection? Verify the memory-backed claim before editing.` That one line catches many confident shortcuts.

Rule of thumb

Put rules in `/memory` only when they are durable, project-specific, and verifiable. Save constraints, commands, and review habits; do not save today's theories. If a note would help a careful maintainer avoid a predictable mistake next month, it belongs in memory. If it merely explains why today's session was confusing, put it in the issue or the handoff. Claude Code gets more productive when its long-term context is small, sharp, and regularly challenged by fresh evidence.