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:

1. Promotions: entries to move, with destination and rationale.
2. Cleanup: duplicates, outdated entries, conflicts, and index cleanup.
3. Ambiguous: entries where you need the user's input on destination.
4. 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.