recall-from-notion

Recall user memories from the Notion Memory Store. Trigger PROACTIVELY at the beginning of conversations where knowing the user's background, preferences, pa...

Read the user's memories from the Memory Store Notion Database and use them as context for the current conversation.

Database Discovery

This skill uses a zero-config convention: the database is always named "Memory Store".

Step 1: Locate the database

POST /v1/search
{
  "query": "Memory Store"
}

From the results, find the item with object: "data_source" whose title is "Memory Store". Extract both:

• data_source_id -- for querying (POST /v1/data_sources/{id}/query)

• database_id -- for reference

• If found -> use data_source_id for all subsequent queries.

• If not found -> silently skip recall. Do NOT prompt the user to create anything.

Platform Adaptation

This skill describes operations using generic Notion REST API format. Each platform's AI should translate to its available tools using the fixed mappings below. Do NOT guess -- follow these mappings exactly.

Claude Code / Claude.ai (Notion MCP Tools)

Operation	SKILL.md Describes	Use MCP Tool	Key Parameters
Discover database	POST /v1/search	notion-search	query: "Memory Store", content_search_mode: "workspace_search"
Get data_source_id	--	notion-fetch	Fetch the database, extract from <data-source url="collection://..."> tag
Structured query	POST /v1/data_sources/{id}/query	Not available	Skip Path 1, use Path 2 only
Semantic search in DB	POST /v1/search + data_source_url	notion-search	data_source_url: "collection://<data_source_id>"
Fetch page details	GET /v1/pages/{id}	notion-fetch	id: "<page_id>"

Critical notes:

• Discovery MUST use content_search_mode: "workspace_search" (default ai_search mode may not return databases)
• Structured database query (Path 1) is not available in MCP. Dual-path recall degrades to semantic search only. This is acceptable for <500 memories.
• Do NOT parallel-call multiple notion-search against the same data_source_url -- MCP will error. Run searches sequentially, or combine into one query.
• Semantic search results lack full properties. Use notion-fetch per result to get Category, Status, Scope, etc.
• Multiple notion-fetch calls can run in parallel within one response to minimize latency.

OpenClaw

OpenClaw accesses Notion through a separately installed "notion" skill (clawhub.ai/steipete/notion). This skill must be installed before using recall-from-notion.

When executing, first read the notion skill's SKILL.md to learn the Notion API access patterns (API key setup, curl commands, endpoints). Then follow this workflow using those patterns.

• All operations described in this skill (search, query, fetch page) map directly to the notion skill's REST API patterns
• All operations including structured query (Path 1) are fully supported

Important: This skill (recall-from-notion) is a workflow skill that depends on Notion connectivity. It does NOT provide Notion access itself -- it relies on the platform's Notion integration (MCP tools on Claude Code/Claude.ai, notion skill on OpenClaw).

When to Trigger

Always trigger when:

• User references past conversations or shared context ("we discussed before", "you know my setup")
• User starts a task where personal context matters (coding, writing, planning, recommendations)
• User asks about their own preferences, decisions, or project details
• User says "recall", "remember", or similar

Consider triggering when:

• A new conversation starts with a domain-specific task (coding, architecture, DevOps, etc.)
• User mentions a project name, tool, or technology that might have stored context
• User asks for recommendations or opinions where past preferences would help

Skip when:

• Pure factual Q&A with no personal dimension ("What is Python's GIL")
• User explicitly says they want a fresh start or generic advice

Recall Strategy

Step 1: Discover Database

See Database Discovery above. If not found, silently skip all remaining steps.

Step 2: Analyze Conversation Topic

From the user's message or conversation context, extract:

1. Keywords: Specific nouns, technologies, tools, project names
   • e.g., "Notion", "Claude Code", "orchestrator", "Python"
2. Semantic query: A natural language summary of the user's intent
   • e.g., "CI configuration preferences", "Python project architecture decisions"
3. Current project (if in Claude Code): Detect from the working directory
   • e.g., "OpenClaw", "skills", "claude_world"

Search strategy guidance:

• Prefer one well-crafted natural language query over multiple keyword-stuffed searches. e.g., "user background preferences and development tools" is better than 3 separate searches.
• For broad queries ("what do you know about me", "my basic info"), a single general query suffices.
• Only add a second search if the first round clearly missed a specific topic dimension.
• On MCP platforms, searches against the same data_source_url MUST be sequential (see Critical notes).

Step 3: Dual-Path Recall

Use two parallel paths to maximize recall coverage, then merge results.

Path 1 -- Structured query (precision, returns full properties):

Query the data source with keyword filters on Title, Content, and Project.

POST /v1/data_sources/{data_source_id}/query
{
  "filter": {
    "or": [
      { "property": "Title", "title": { "contains": "<keyword>" } },
      { "property": "Content", "rich_text": { "contains": "<keyword>" } },
      { "property": "Project", "rich_text": { "contains": "<keyword>" } }
    ]
  },
  "page_size": 50
}

For multiple keywords (e.g., "Notion" and "MCP"):

{
  "filter": {
    "or": [
      { "property": "Title", "title": { "contains": "Notion" } },
      { "property": "Content", "rich_text": { "contains": "Notion" } },
      { "property": "Title", "title": { "contains": "MCP" } },
      { "property": "Content", "rich_text": { "contains": "MCP" } }
    ]
  }
}

MCP platforms (Claude Code / Claude.ai): Path 1 is not available (no structured query tool). Skip directly to Path 2. The recall becomes single-path semantic search.

Path 2 -- Semantic search (coverage, catches what keywords miss):

Search within the Memory Store using the semantic query from Step 2.

POST /v1/search
{
  "query": "<semantic query from Step 2>",
  "data_source_url": "collection://<data_source_id>"
}

This catches memories that are semantically related but don't contain the exact keywords. For example, searching "CI configuration" might find "GitHub Actions workflow preferences" even though it doesn't contain the word "CI".

Why dual-path? Structured query is precise but only matches exact keywords -- it misses semantically related memories. Semantic search understands intent but returns incomplete properties (only id/title/highlight). Combining both gives precision + coverage.

Step 4: Merge and Enrich

1. Merge: Combine results from both paths, deduplicate by page id.
2. Enrich: Structured query results already have full properties. For memories found only by semantic search, fetch their full properties:

   GET /v1/pages/{page_id}
   

   (Only fetch the delta -- skip pages already in structured query results.)

MCP platforms: Since only Path 2 is available, ALL results need enrichment via notion-fetch. If multiple searches were performed, deduplicate by page id first, then fetch only unique results. Multiple notion-fetch calls can run in parallel to minimize latency.

Step 5: Filter

Apply these filters on the merged results:

Scope filter (most important for Claude Code):

• Always include: Scope = Global
• Include: Scope = Project where Project matches current project name
• Exclude: Scope = Project for OTHER projects
• Include: no Scope set (legacy data, treat as Global)

Status filter:

• Contradicted: Always skip
• Archived: Skip unless user explicitly asks

Expiry filter:

• 30d: Source Date + 30 days < today -> skip
• 90d: Source Date + 90 days < today -> skip
• 1y: Source Date + 1 year < today -> skip
• Never: Always include

Step 6: Rank

Priority scoring:

1. Dual-path bonus: Found by both structured query and semantic search -> highest relevance
2. Topic match: Directly relates to user's current question/task
3. Category weight: Preference > Fact > Decision > Pattern > Skill > Context
4. Recency: Newer Source Date > Older

Injection limit: 10-15 memories maximum.

Step 7: Inject as Context

Format recalled memories as a compact context block grouped by Category:

Recalled context from Memory Store:

[Preferences]
- User prefers Ruff for code formatting and linting
- ...

[Facts]
- User is a programmer, primarily uses Python
- Notion workspace connected via MCP
- ...

[Decisions]
- Memory Store uses Notion Database as storage backend
- ...

Rules:

• Group by Category, keep each entry 1-2 lines
• Include key details (IDs, commands, URLs) verbatim
• Only show Categories with entries
• Silently drop irrelevant memories

Handling Edge Cases

No results: Proceed without memories. Don't announce unless user explicitly asked.

Too many (>15): Rank strictly, inject top 10-15. Note more are available.

Stale/wrong memories: Flag contradictions and offer to update.

"How do you know that?": Explain it came from Memory Store, offer to show/edit.

Important Notes

• Silent injection: Don't say "Searching memory store..." unless user explicitly asked.
• User's language: Construct search queries in the user's primary language. Memories are stored in the user's language, so search in the same language for best recall.
• Relevance first: When in doubt, leave it out.
• Scope awareness: In Claude Code, detect current project and filter accordingly.
• Cross-platform: Treat entries from all sources (Claude.ai, Claude Code, OpenClaw) equally.
• Read-only: This skill only reads from the database, never writes.