alt Hacker News> Claude Code’s "Memory" feature was the tipping point for me
My standing orders are the default MEMORY.md must be a stub directing Claude to another MEMORY.md file in the local folder, project, etc.
All memories remain with their respective projects over syncs, moves, devices, etc. The stub must state all this clearly, and nothing else.
This has worked very well.
If you give the model/memory a name, that name can be persistent and independent over "backend" model swaps.
Replies
I've adopted the same concept as well, although through various mechanics. Basically, you want to capture your insights/documentation in the repo so any future model provider can continue the work.
Majority will only care about getting outcomes asap so they'll skip this step, but it may come to roost when migrating workflows. A good simple test is how easily you can switch workflow to a different model provider/harness without much effort.
Can you explain a bit more technically how you set this up? What is a "stub directory"?
Feel free to give a concrete example if you have time, because this sounds like something I definitely want to try out myself.