| name | remember |
| description | Review auto-memory entries and propose promotions to OPENSPACE.md, OPENSPACE.local.md, or retained auto-memory topics; detect duplicates, stale facts, conflicts, and ambiguous entries before making changes. |
Memory Review
Goal
Review the user's memory landscape and produce a clear report of proposed changes, grouped by action type. Do not apply changes until the user approves them.
Steps
1. Gather all memory layers
Read OPENSPACE.md and OPENSPACE.local.md from the project root if they exist. Review auto-memory from the memory section and MEMORY.md; use memory_read for topic files when needed. Note team memory only as unavailable unless this deployment explicitly has a team memory backend.
Success criteria: you have the contents of all available memory layers and can compare them.
2. Classify each auto-memory entry
For each substantive auto-memory entry, determine the best destination:
| Destination | What belongs there | Examples |
|---|
OPENSPACE.md | Project conventions and instructions for OpenSpace that all contributors should follow | use uv not raw pip; API routes use kebab-case; test command is pytest; prefer functional style |
OPENSPACE.local.md | Personal instructions specific to this user or machine, not applicable to other contributors | concise responses; explain tradeoffs; do not auto-commit; run tests before committing |
| Auto-memory topic | Durable cross-session user, feedback, project, or reference memory that does not belong in static project instructions | user role, durable feedback, external reference pointers, uncertain but useful context |
| Stay put | Working notes, temporary context, or entries that do not clearly fit elsewhere | session-specific observations, uncertain patterns |
Important distinctions:
OPENSPACE.md and OPENSPACE.local.md contain instructions for the agent, not arbitrary external-tool preferences.- Workflow practices such as PR conventions, merge strategy, and branch naming can be personal or team-wide; ask the user when unclear.
- When unsure, ask rather than guess.
Success criteria: each entry has a proposed destination or is flagged as ambiguous.
3. Identify cleanup opportunities
Scan across all layers for:
- Duplicates: auto-memory entries already captured in
OPENSPACE.md or OPENSPACE.local.md.
- Outdated entries: static instructions contradicted by newer auto-memory.
- Conflicts: contradictions between any two layers; propose a resolution and note which evidence is newer.
- Overloaded index lines:
MEMORY.md entries that contain content that belongs in a topic file.
Success criteria: all cross-layer issues are identified.
4. Present the report
Output a structured report grouped by action type:
- Promotions: entries to move, with destination and rationale.
- Cleanup: duplicates, outdated entries, conflicts, and index cleanup.
- Ambiguous: entries where you need the user's input on destination.
- No action needed: brief note on entries that should stay put.
If auto-memory is empty, say so and offer to review OPENSPACE.md for cleanup.
Rules
- Present all proposals before making changes.
- Do not modify files without explicit user approval.
- Do not create new files unless the approved target does not exist yet.
- Ask about ambiguous entries; do not guess.
