Step 1 of 4
Design the memory file structure
Structure is what keeps file memory useful at write 50.
Design the project memory format. Create MEMORY.md with sections: ## Project Facts (architecture, key paths, stack choices), ## Preferences (user style and tool preferences, one per line), ## Working Recipes (commands and approaches that work, with context), ## Known Issues & Failed Approaches (what breaks and why), ## Decisions Log (dated one-liners: decision + reason). Define per-section caps (e.g. 30 lines each) and entry format rules (imperative one-liners, no paragraphs, date-stamped where useful). Write the format spec at the top of the file as an HTML comment so both humans and the agent see the rules.
Expected after this step
A MEMORY.md template with sections, caps, and embedded format rules.
Should not happen
- ✕Building embedding infrastructure for what a 200-line markdown file handles
- ✕The agent appending duplicates because it never reads before writing
- ✕A memory file that decays into an unstructured dump nobody trusts
- ✕Writes scattered through code instead of one validated tool path
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Building embedding infrastructure for what a 200-line markdown file handles
- !The agent appending duplicates because it never reads before writing
- !A memory file that decays into an unstructured dump nobody trusts
- !Writes scattered through code instead of one validated tool path
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
Sections blur together in practice. Sharpen the definitions with an example entry under each header and a one-line 'belongs here if...' rule.