Remember
Promote durable, reusable knowledge into the right memory surface instead of leaving it buried in chat history.
When to Use
- User wants to preserve knowledge discovered during a session
- Organizing scattered findings into structured memory
- Cleaning up duplicate or conflicting stored information
When NOT to Use
- Ephemeral task notes → just keep in conversation
- Already documented in code or docs → reference directly
Memory Surfaces
| Surface |
Use For |
Durability |
| Project memory |
Durable team/project knowledge |
Permanent |
| Session context |
Short-lived working notes |
Session only |
| Docs / Instructions |
Conventions, instructions |
Permanent |
Workflow
- Gather the relevant session findings
- Classify each item:
- Durable project fact
- Temporary working note
- Operator preference or instruction
- Duplicate / stale / conflicting information
- Propose the best destination for each item
- Write or update only the appropriate memory surface
- Call out duplicates or conflicts that should be cleaned up
Rules
- Do not dump everything into one store
- Prefer project memory for durable team knowledge
- Keep entries concise and actionable
- If something is uncertain, mark it as uncertain rather than storing it as fact
Output
- What was stored
- Where it was stored
- Any duplicates/conflicts found
Quality Gate (Before Storing)
Before committing anything to memory, apply this 3-question filter. Skip storage if the answer to any question is "No":
| Question |
Rationale |
| Is it actionable? "Does this tell someone what to DO in a future situation?" |
Observations are not memory entries; decisions are. |
| Is it durable? "Will this still be true in 3 months, or is it tied to a temporary workaround?" |
Ephemeral findings belong in session notes, not project memory. |
| Is it unique? "Does something close already exist in memory that covers this?" |
Duplicate entries create confusion; prefer updating existing entries. |
Examples
| Item |
Actionable? |
Durable? |
Unique? |
Store? |
"Use bcrypt cost=12 for passwords in this project" |
✅ |
✅ |
✅ |
YES |
| "API was slow today because server was rebooting" |
❌ |
❌ |
✅ |
NO — ephemeral |
"Always run npm run build before pushing" |
✅ |
✅ |
Check existing |
YES if not already stored |
| "The login page has a bug in dark mode" |
❌ |
❌ |
✅ |
NO — file a bug, not a memory entry |
"We prefer interface over type for object shapes" |
✅ |
✅ |
Check existing |
YES if not in coding-standards |
When to Update vs Create
- UPDATE an existing entry if the new information refines, corrects, or supersedes it
- CREATE a new entry only if no existing entry covers the topic
- DELETE entries that are provably outdated (check with user first)
See Also
/coding-standards — canonical rules reference (no need to duplicate into memory)
/skill-stocktake — audit memory surfaces for quality