The short answer
Use Claude Code memory for notes the tool learns while you work. Use CLAUDE.md for rules your team has chosen. Put the feature plan in a brief, then keep the changing work on a task board.
These places solve different problems. When they are mixed into one long instruction file, a coding session gets a pile of old decisions and misses the one decision that matters today.
What Claude Code memory and CLAUDE.md do
Claude Code has memory features and CLAUDE.md instruction files. The official Claude Code memory guide explains that both are used to carry context between conversations.
A CLAUDE.md file is written and maintained by people. It is a good home for rules that should remain true, such as the product goal, the test command, coding rules and a hard design limit. Memory can hold useful notes the tool records during work. Check the official guide when you need to change how Claude Code itself stores or loads memory.
- Put a team rule in CLAUDE.md when you want every session to follow it.
- Treat automatic memory as a helpful note, not as the only record of a product decision.
- Do not put a changing task list in either place. It goes stale too quickly.
A running example: add appointment booking to a small app
Imagine a small app that lets a customer book a time with a consultant. The product rule is that a customer can only book an open time. That is a durable rule, so it belongs in the project plan and can be linked from CLAUDE.md.
The first booking feature still needs its own brief. The brief says what the booking screen shows, what happens when no times are open and how the person knows the booking saved. The task board then records the changing work, such as building the availability query, the form and the confirmation message.
This separation gives a new coding session the right amount of context. It can read the stable rule, open the booking brief and work on one task without guessing the rest of the app.
Put each kind of context in the right place
Use the place that matches how long the information stays true and who needs to review it.
| Place | Put this there | Do not put this there |
|---|---|---|
| Claude Code memory | Useful notes the tool records during work | The only copy of a team rule or product decision |
| CLAUDE.md | Stable product rules, commands and project constraints | A daily list of tasks or a full feature specification |
| Feature brief | User outcome, behaviour, boundaries and checks for one feature | Rules that apply to every part of the project |
| Task board | The next small change, its state and what must be checked | The full history of why the product exists |
Make a handoff that a new session can follow
Before a new session starts, point the coding agent to the project instructions, the feature brief and the next task. Ask it to repeat the important constraint before it changes code.
For the booking example, the handoff can say: read the project rules, read the booking brief and implement the confirmation message task. The task should name the acceptance checks: show the booked time, do not create a second booking after a double click and show a useful message when saving fails.
Run the relevant automated tests after the change. Then try the booking flow yourself. A test can prove a rule it covers. Your manual check can catch a confusing message or missing next step.
Keep the plan visible while the work changes
CodeSpring keeps the app map, feature requirements and Kanban tasks together. That gives a coding agent a clear plan to read and gives the person building the app a place to review each task against the original feature decision.
CodeSpring is not a replacement for Claude Code memory. It is the team-owned product plan and task record that should not disappear into a tool's private notes.