Search the user's own past coding sessions across every AI tool they've used (Claude Code, Codex, Cursor, opencode, aider, gemini, and others) and return the best matches as dense text under ~4KB. Call this the moment the user implies work already happened — 'didn't we fix this before?', 'what was that error again', 'we already set this up', 'how did we solve X last time', 'what did we decide about Y' — and always before debugging an error or re-implementing something that might already exist. Query with the most specific token available: an exact error string, function name, file path, or flag (multiple words are ANDed). Do NOT use this for general knowledge or library/API docs — only this user's prior sessions. A result may carry a bracketed marker before its snippets — [this was tried and rejected], [a later decision replaced this], [marked stale — may no longer hold] — with the reason and the date. That is the user's own later judgement on that session: do not repeat a rejected approach, prefer the replacement over what it replaced, and treat stale results as needing confirmation before you act on them. An unmarked result carries no such judgement either way. Follow up with recall_context when one session looks right and you need its full story. Optionally filter by harness. When a result genuinely helps the task at hand — you reuse a fix, skip re-debugging, or confirm a prior decision — tell the user in one digest.Short line what deja-vu recalled and how you used it (e.g. "deja-vu recalled: we hit this JWT skew in March — reusing that fix"). Even a partial hint counts if it changed your approach. Say nothing about recalls that did not help.

Return a full markdown digest (~8KB) of the single best-matching prior session — problem, decisions, outcome — when a bare recall hit is not enough and you need the reasoning behind it. Use after recall, or directly when the user asks 'remind me how we handled X' or 'what was the whole story with Y'. Query terms are matched against transcript text, so use tokens likely to appear verbatim: an error string, function name, or flag. Not for browsing many sessions — use recall for that; this returns one deep digest. When a result genuinely helps the task at hand — you reuse a fix, skip re-debugging, or confirm a prior decision — tell the user in one digest.Short line what deja-vu recalled and how you used it (e.g. "deja-vu recalled: we hit this JWT skew in March — reusing that fix"). Even a partial hint counts if it changed your approach. Say nothing about recalls that did not help.

Before editing, refactoring, or deleting a file, find the prior sessions that discussed it so you know why it is shaped the way it is. Call whenever you are about to change a file, or when the user asks 'why is this like this', 'what was this for', 'is it safe to remove this'. Most specific mentions come first. This is session history across AI tools, not git blame — it explains intent and past decisions, not commit authorship. Give an absolute path, relative path, or bare filename.

Store one durable decision or conclusion so a future session can recall it. Call right after a decision is settled, a tricky bug is resolved, or the user says 'remember this', 'note that for next time', 'don't forget we chose X'. Write a single self-contained fact (e.g. 'We use Postgres advisory locks for the job queue because Redis lost messages under load'). Do NOT store transcripts, routine conversation, or anything already obvious from the code. text is required; project defaults to notes.