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