memory-recalllisted

# Memory Recall **Source pattern**: the read-before-reasoning, write-after-acting loop described in Redis's long-term memory architecture guide, adapted to the file substrate in [ARCHITECTURE.md](../../ARCHITECTURE.md) — this skill is the "read" half; `memory-capture` and `session-checkpoint` are the "write" half. ## When to reach for this, beyond bootstrap `memory-bootstrap` gives a cheap, general orientation at session start. `memory-recall` is targeted — reach for it whenever the *current* task specifically touches something that might already have a decision, a past attempt, or a relevant fact recorded: - About to propose an architectural approach → check `.memory/decisions/` for anything already decided that this would contradict or build on - Debugging something that feels familiar → check `.memory/episodes/` for a past session that hit something similar - About to state something as a project convention or constraint → check `.memory/semantic/project-facts.md` first, both to avoid restating what's already known and to avoid contradicting it - A task file exists for related work → read `.memory/tasks/<slug>.md` for its current state before assuming it's untouched ## How to search, practically The file substrate is deliberately grep-able — a targeted search across `.memory/decisions/`, `.memory/episodes/`, and `.memory/semantic/` for keywords related to the current task is often sufficient and fast. For genuinely relational questions ("what else depends on the modu