| name | memories-sanitize |
| description | Review recent memories and remove invalid or misleading ones from the semantic memory database |
| allowed-tools | Bash(simba *) |
Memory Sanitization Procedure
Review memories and identify those that are invalid, misleading, or outdated. This applies to any work session - debugging, feature development, refactoring, exploration, etc.
Step 1: List Memories
List all memories:
simba memory list
Or filter by type:
simba memory list --type GOTCHA
Each memory shows: id, type, confidence, and content.
Step 2: Identify Invalid Memories
Review each memory and mark as INVALID if it:
From Any Session Type
- Outdated information - Was true but no longer applies after changes
- Superseded by better approach - A newer, better solution exists
- Too specific/narrow - Only applied to a removed/changed feature
- Incorrect generalization - Specific case wrongly stated as general rule
From Debugging Sessions
- Red herring - An initial hypothesis that turned out to be wrong
- Wrong blame - Points to code that was actually working correctly
- Non-issue - Something suspected as a bug but wasn't
From Feature Development
- Abandoned approach - Design decision that was later reversed
- Prototype artifact - Workaround that was replaced by proper implementation
- Incomplete understanding - Early assumption corrected by later work
Step 3: Delete Invalid Memories
For each invalid memory, delete it:
simba memory delete <MEMORY_ID>
Step 4: Add Corrected Memories (Optional)
If an invalid memory should be replaced with a correct version:
simba memory store --type WORKING_SOLUTION --content "<CORRECT_LEARNING>" --context "<CONTEXT>" --confidence 0.95
Memory Types Reference
| Type | Use For |
|---|
GOTCHA | Counterintuitive behaviors, traps, "watch out for this" |
WORKING_SOLUTION | Commands, code, or approaches that worked |
PATTERN | Recurring architectural decisions or workflows |
DECISION | Explicit design choices with reasoning |
FAILURE | What didn't work and why (useful to avoid repeating) |
PREFERENCE | User's stated preferences |
Examples
Debugging Example
Invalid: "Reference equality vs .Equals() mismatch causes graph disconnection"
Correct: "Coordinate tolerance 1e-6 too small for reprojected coords; use 0.01m for EPSG:3857"
Feature Development Example
Invalid: "Use polling for real-time updates in dashboard"
Correct: "Use WebSocket for real-time updates - polling caused excessive server load"
Refactoring Example
Invalid: "ServiceLocator pattern works well for dependency injection"
Correct: "Constructor injection preferred - ServiceLocator made testing difficult"
Tips
- Wait until work is complete before extracting memories
- During iterative development, early decisions often get revised
- Lower confidence scores for findings that might change
- Be specific in context field about file paths and scenarios
- Periodic sanitization prevents memory database pollution
