Save a memory — any knowledge worth preserving. USE THIS WHEN: you just solved a tricky bug, found a non-obvious fix, discovered a workaround, learned a user preference, or encountered something that future agents (or your future self) would benefit from knowing. DO NOT save trivial things — only save memories that would save someone real time or prevent a real mistake. The content should be a clear, self-contained piece of knowledge. Optionally set tier: 'working' (auto-expires in 1h, for scratch context), 'short' (auto-expires in 7d, for session learnings), or 'long' (default, no expiry, for lasting knowledge). Optionally set scope='global' to make this memory visible across every project (use for universal lessons, language gotchas, framework patterns, tool quirks); leave unset to default by type (lesson/preference/pattern/convention default to 'global', everything else stays scoped to the current project). When enrichment is enabled, automatically extracts topics, entities, sentiment, classifies intent/domain/emotion, and extracts structured facts.

Record a structured observation extracted from a session. USE THIS WHEN: capturing a multi-faceted event (a debugging session, a decision with trade-offs, a workflow pattern) where you have a short title, a few atomic facts, and a narrative. PREFER THIS over remember(...) for typical auto-extracted observations from session transcripts. Use the simpler remember(content, type=...) only for polished single-fact memories you're confident about. Stored with type='observation' so future retrieval can score polished memories higher than raw observations. Pass scope='global' for universal lessons; default 'project' keeps the observation visible only inside its repo.

Search for relevant memories from past experience. USE THIS WHEN: you're about to solve a problem, debug an error, or make a design decision — especially if you suspect someone has hit this before. Search with a natural-language description of your problem or question. GOOD queries: 'CORS errors with FastAPI', 'Docker build fails on M1', 'rate limiting strategy for API'. BAD queries: 'help', 'error', 'fix this'. Be specific. Supports filtering by tier (working/short/long), type, tags, entity, topic, intent, domain, and emotion. Supports temporal filtering: year, month, day, days_ago, hours_ago, window (today/last_hour/last_day/last_week/last_month/last_year), before, after, date_from, date_to (ISO 8601). When knowledge graph is enabled, set graph_depth (e.g. via LORE_GRAPH_DEPTH) to surface memories connected via entity relationships. Pass scope='all' to also include memories from other projects (rare; default scopes to current project + global pool).

Phase 6D progressive disclosure: return a compact index of relevant memories — id, title, score, signals only. USE THIS WHEN: you want to survey what Lore knows about a topic before drilling in. Cheaper than recall (~50 tokens/result vs ~300). Pair with get_memories(ids=[...]) to fetch full content for the rows worth reading. GOOD queries: 'CORS errors with FastAPI', 'Docker build fails on M1'. Avoid 'help', 'error', 'fix this'. Pass scope='all' to also include memories from other projects (rare; default scopes to current project + global pool).

Phase 6D progressive disclosure: fetch full payloads for one or more memory IDs (typically returned by search()). USE THIS AFTER search() identifies rows worth drilling into. Caps at 10 IDs per call. Returns a JSON-formatted block with full content, tags, meta, and timestamps. Errors (missing or unauthorized IDs) are surfaced in the errors array; the call still succeeds as long as at least one ID resolves.

Phase 6G middle drill-down: return chronologically adjacent events (±limit entries, hard cap ±max_hours) around an anchor memory ID, scoped to the same project. Each entry: id, created_at, type, title, narrative_1l, same_session. USE THIS AFTER search() identifies a promising hit, BEFORE get_memories(), to establish causality without paying for full content. ~60 tokens/entry. PARAMS: anchor_id (required); limit (1-50, default 10); direction ('before'|'after'|'both', default 'both'); max_hours (>0, ≤72, default 2.0).

Delete a memory by its ID. USE THIS WHEN: a memory is outdated, incorrect, or no longer relevant. Pass the memory ID from recall output.

List stored memories, optionally filtered by type, tier, or project. USE THIS WHEN: you want to browse all stored memories, audit what's in the knowledge base, or find memories by type/tier without semantic search. For semantic search, use recall instead.

Return memory statistics: total count, counts by type and tier, oldest and newest memory timestamps. USE THIS WHEN: you want an overview of the knowledge base, check how many memories exist, or see the distribution across types and tiers.

Upvote a memory that was helpful. USE THIS WHEN: you recalled a memory and it actually helped solve your problem. This boosts the memory's ranking in future searches. Pass the memory ID from recall output.

Downvote a memory that was wrong or unhelpful. USE THIS WHEN: you recalled a memory but it was outdated, incorrect, or misleading. This lowers the memory's ranking so others don't waste time on bad advice. Pass the memory ID from recall output.

Share a private memory with the whole team (PRIVATE → SHARED). USE THIS WHEN: a memory you captured is useful to teammates and you want everyone in the org to be able to recall it. By default captures are private to you; this opts a specific one into the shared pool. Pass the memory ID from recall output.

Unshare a memory, making it private to you again (SHARED → PRIVATE). USE THIS WHEN: a memory was shared with the team but should no longer be visible to others. Pass the memory ID from recall output.

Export memories formatted for LLM context injection. USE THIS WHEN: you need to inject relevant memories directly into a prompt or system message. Returns a formatted block of memories optimized for your LLM's preferred format. Supports XML (Claude), ChatML (OpenAI), markdown, and raw text.

Check if stored memories are still fresh against current git state. USE THIS WHEN: you want to verify that code-pattern memories are still relevant before acting on them. Compares memories with file_path metadata against the git commit history to detect staleness.

Sync GitHub repository data (PRs, issues, commits, releases) into Lore as memories. USE THIS WHEN: you want to ingest tribal knowledge from a GitHub repo so it's searchable. Requires the gh CLI to be installed and authenticated.

Classify a piece of text by intent, domain, and emotion. Returns structured classification without storing anything. USE THIS WHEN: you want to understand the nature of a piece of text before storing it, or to analyze conversation patterns.

Enrich memories with LLM-extracted metadata (topics, sentiment, entities, categories). USE THIS WHEN: you want to add structured metadata to existing memories for better filtering. Requires LORE_ENRICHMENT_ENABLED=true and a configured LLM provider (LORE_LLM_PROVIDER + API key). Enrichment runs automatically on remember() when enabled; use this tool to enrich older memories.

Extract structured facts from text without storing them. Returns atomic (subject, predicate, object) triples with confidence scores. USE THIS WHEN: you need to understand what facts are contained in a piece of text, or to preview what facts would be extracted before remembering.

List active (non-invalidated) facts from the knowledge base. USE THIS WHEN: you want to see what structured facts Lore knows about a subject, or to review all known facts.

List recent fact conflicts detected during memory ingestion. Shows what facts were superseded, merged, or flagged as contradictions. USE THIS WHEN: you want to review knowledge changes, audit what facts were updated, or resolve flagged contradictions.

Query the knowledge graph to find entities connected to a given entity. USE THIS WHEN: you want to understand relationships between concepts, find dependencies, or explore how entities are connected. Returns connected entities and relationship types within the specified depth.

List entities in the knowledge graph, optionally filtered by type. USE THIS WHEN: you want to see what entities Lore knows about, find entity names for graph queries, or get an overview of the knowledge graph. Set format='json' for D3-compatible graph visualization output.

Find memories and entities related to a given memory or entity. USE THIS WHEN: you want a quick overview of what's connected to something, without needing the full graph_query options. Simpler interface than graph_query for common lookups.

Ingest content from external sources with source tracking. USE THIS WHEN: you want to import content from Slack, Telegram, Git, or any external source with full provenance tracking (who said it, where, when). Content goes through normalization and deduplication before storage. Supports source-specific formatting cleanup (Slack mrkdwn, Telegram HTML, etc).

Retrieve memories from this month+day across all years. USE THIS WHEN: you want to reflect on what happened on a specific date in past years, find anniversaries, or review historical context. Returns memories grouped by year. Defaults to today's date. Supports date window for fuzzy matching.

Accept raw conversation messages and automatically extract memories. USE THIS WHEN: you want to dump your recent conversation context so Lore can identify and store useful knowledge (facts, decisions, preferences, lessons). Unlike 'remember' which requires you to decide what to save, this tool accepts raw conversation history and uses LLM processing to extract what's worth keeping. Requires enrichment to be enabled (LORE_ENRICHMENT_ENABLED=true).

Trigger memory consolidation. Merges near-duplicate memories and summarizes related memory clusters into concise long-term memories. USE THIS WHEN: memory bloat is high, or you want to compress episodic memories into semantic knowledge. Defaults to dry-run (preview only).

Get a summary of recent memory activity across projects. CALL THIS AT THE START OF EVERY SESSION to maintain continuity with prior work. Returns the last N hours of memories grouped by project, regardless of semantic relevance to your current task. This catches recent decisions, changes, and context that semantic search would miss. Works without LLM (structured listing) — enhanced with LLM (concise summary of key points).

Export all memories and knowledge graph to a JSON file for backup or migration. USE THIS WHEN: you want to create a portable backup before risky operations, migrate data to another machine, or audit stored knowledge. Supports filtering by project, type, tier, and date.

Create a quick snapshot backup of all Lore data. USE THIS BEFORE: running consolidation, bulk imports, upgrades, or any operation that modifies many memories at once. Snapshots are stored at ~/.lore/snapshots/ and can be restored.

List available snapshots for restore. USE THIS WHEN: you want to see what backups are available before restoring or cleaning up old snapshots.

List auto-detected topics — recurring concepts across multiple memories.

Get everything Lore knows about a topic — linked memories, related entities, timeline.

Save a session snapshot to preserve important context before it is lost.

Get pending knowledge graph connections for review. USE THIS WHEN: you want to present discovered connections to the user for approval or rejection. Returns pending relationships grouped by type with entity names and source memory context. The user can then decide which connections to keep (approve) and which to discard (reject). Rejected patterns are remembered so they won't be re-suggested.

Approve or reject a pending knowledge graph connection. USE THIS AFTER: getting a review_digest and the user has decided which connections to keep or discard. Rejected patterns are tracked so the same connection won't be re-suggested.

Get proactive memory suggestions based on current session context. USE THIS WHEN: you want to surface potentially relevant memories without a specific query. Useful at session start or before major decisions. Returns memories ranked by multi-signal relevance.

Mark a memory as superseded by a newer one. USE THIS WHEN: a fact has changed (e.g. 'we used Postgres but switched to SQLite', 'I no longer prefer X'). PREFER THIS over forget — supersede preserves history for audit while ensuring the old memory drops in retrieval score so stale facts don't pollute future recalls. Pass superseded_by=None to explicitly un-supersede.

List memories that were canonical at a given point in time. USE THIS WHEN: you want to know 'what did we know about X as of date Y?' — useful for audit, debugging stale-context issues, or answering historical questions. Filter by entity name and/or type. Excludes memories that were already superseded as of the given timestamp.

Atomic consolidation: create a new memory from N source memories and supersede every source in one operation. USE THIS WHEN: merging near-duplicates or promoting an observation cluster to a lesson. Provenance guarantee: every source_ids entry has its supersession_chain pointing at the returned id before this tool returns — even if the dream subagent crashes mid-loop. PREFER THIS over remember(...) + forget(...) for any merge / promotion path; forget destroys the audit trail.

Show the full lineage for a memory: which source memories were consolidated into it, plus its own supersession chain. USE THIS WHEN: a recall result looks suspicious and you want to drill back to the unconsolidated source claims, or when auditing how a lesson was synthesized. Returns sources (events where memory_id appears as superseded_by) and chain (events for memory_id itself).

Show the supersession audit chain for a memory. USE THIS WHEN: investigating why a memory drops in retrieval score, auditing 'what changed' for a given fact, or tracing the lineage of a piece of knowledge across corrections. Returns the events oldest first.

List the facts (subject–predicate–object relationships) about an entity that were valid at a given point in time. USE THIS WHEN: you need 'what was true about X as of date Y?' for audit/compliance, debugging stale context, or historical questions (e.g. 'what database did ServiceX use on 2026-05-01?'). Excludes facts that had already been superseded as of that timestamp. Optionally filter by predicate.

Supersede a fact (relationship) with a newer one — supersede-NOT-delete. USE THIS WHEN: a fact was corrected (e.g. 'ServiceX uses Postgres' is now 'ServiceX uses MySQL'). Pass the old fact's relationship_id and the newer fact's id as superseded_by. The old fact stops appearing in current fact queries but stays queryable as-of past dates, and the correction is recorded in the audit chain. Get relationship_ids from facts_at_time.

Show the correction trail for a fact (relationship). USE THIS WHEN: auditing 'how did this fact change over time?' or tracing which newer fact replaced an old one and why. Returns the supersession events oldest first.