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

1. Gather the relevant session findings
2. Classify each item:
   • Durable project fact
   • Temporary working note
   • Operator preference or instruction
   • Duplicate / stale / conflicting information
3. Propose the best destination for each item
4. Write or update only the appropriate memory surface
5. 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