Memory To Notion

Memory to Notion

This skill retrieves the user's past conversation history, analyzes it for valuable and meaningful content, decomposes conversations into atomic memory entries, and writes them as rows into the Memory Store Notion Database.

Database Discovery

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

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 creating pages (POST /v1/pages with parent: {"database_id": "..."})

• If found -> use data_source_id for queries, database_id for page creation.

• If not found -> ask the user: "No 'Memory Store' database found in your Notion workspace. Which page should I create it under? Please provide a Notion page URL or page ID." Then create the database (see Database Creation below).

Schema

Database Creation

When the database does not exist, create it under the user-specified parent page. Use the Notion create-database API with the schema above.

Category Definitions

• Fact: Objective facts -- user's identity, background, tech stack, tools, environment, organization
• Decision: Architecture decisions, technology choices, approach selections
• Preference: User preferences -- coding style, tool configuration, interaction habits
• Context: Background information -- project context, domain knowledge, observations
• Pattern: Behavioral patterns -- workflows, recurring needs
• Skill: Skills and knowledge -- commands, APIs, techniques learned

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)

Critical notes:

• Discovery MUST use content_search_mode: "workspace_search" (default ai_search mode may not return databases)
• Structured query for dedup is not available in MCP. Use semantic search as fallback: notion-search with data_source_url: "collection://<data_source_id>" and keywords from the candidate memory. Then notion-fetch each result to compare full properties.
• Do NOT parallel-call multiple notion-search against the same data_source_url -- MCP will error. When deduping multiple candidate memories, run searches sequentially. Deduplicate results by page id before fetching.
• notion-create-database uses SQL DDL syntax, not JSON. See Database Creation section for the DDL.

OpenClaw

OpenClaw accesses Notion through a separately installed "notion" skill (clawhub.ai/steipete/notion). This skill must be installed before using memory-to-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, create page, update page, create database) map directly to the notion skill's REST API patterns
• All operations including structured query for dedup are fully supported

Important: This skill (memory-to-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).

Workflow

Step 1: Discover Database

Locate the "Memory Store" database. If not found, create it (see above).

Step 2: Gather Conversation Content

Choose a strategy based on the current platform:

Claude.ai (has conversation history API):

• Use recent_chats(n=20) to fetch recent conversations
• Use after/before parameters to filter by time range
• Use conversation_search for keyword-based retrieval
• For comprehensive archival, paginate up to ~5 rounds

Claude Code (current session only):

• Extract valuable information from the current conversation context
• Triggered when the user says "summarize memory" or similar
• Review facts, decisions, preferences produced in this session
• Cannot access past sessions -- only processes current conversation

Step 3: Check Existing Memories (Dedup & Conflict Detection)

Before writing, query the database to check for duplicates and conflicts. For each candidate memory, search Title and Content:

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

MCP platforms (Claude Code / Claude.ai): Structured query is not available. Use notion-search with data_source_url: "collection://<data_source_id>" and keywords from the candidate memory as query. Run dedup searches sequentially (not in parallel). Deduplicate results by page id across searches, then notion-fetch only unique results to compare properties.

The query returns full page properties. Check for:

1. Duplicates: Same fact already stored -> skip
2. Updates: Same topic but info changed -> update existing, mark old as Contradicted if needed
3. Conflicts: New info contradicts existing -> create new as Active, mark old as Contradicted

Step 4: Decompose into Atomic Memories

Each conversation may yield 0-N memory entries. The key principle is one fact per row.

Decomposition rules:

• Each memory should be self-contained and independently meaningful
• Don't store entire conversation summaries -- extract individual facts, decisions, preferences
• Title should be a single declarative sentence (searchable)
• Content provides enough detail to be useful without the original conversation

Examples of good decomposition:

A conversation about "setting up a new Python project" might yield:

"User prefers uv over pip for Python dependency management"  -> Category: Preference
"Project OpenClaw uses FastAPI + PostgreSQL architecture"     -> Category: Decision
"User prefers Ruff for code formatting and linting"           -> Category: Preference
"User is a programmer"                                        -> Category: Fact

What NOT to store:

• Transient Q&A that can be easily re-searched ("What is Python's GIL")
• Pleasantries and small talk
• Failed attempts with no useful outcome
• Information the user explicitly asked to forget

Step 5: Write to Memory Store

Create pages in the database. For each memory entry, set properties:

{
  "Title": "One-line summary",
  "Category": "Fact|Decision|Preference|Context|Pattern|Skill",
  "Content": "Detailed memory content, sufficient for any AI platform to understand and use",
  "Source": "Claude.ai|ClaudeCode|OpenClaw|Manual|Other",
  "Status": "Active",
  "Scope": "Global|Project",
  "Project": "Project name (set when Scope=Project)",
  "Expiry": "Never|30d|90d|1y",
  "date:Source Date:start": "YYYY-MM-DD",
  "date:Source Date:is_datetime": 0
}

Scope guidelines:

• Global: Cross-project universal -- user preferences, general toolchain, personal habits, global decisions
• Project: Project-specific -- project architecture, dedicated config, project-scoped technical decisions
• When uncertain, default to Global
• Project field should match the user's project directory name or repository name (e.g., "OpenClaw")

Expiry guidelines:

• Never: Stable facts and preferences (name, tools, architecture)
• 1y: May become outdated (tool versions, project status)
• 90d: Limited shelf life (current tasks, temporary decisions)
• 30d: Very transient (this week's todos, temporary workarounds)

Step 6: Handle Conflicts

If Step 3 found conflicting memories:

1. Update the old memory's Status to "Contradicted":

   PATCH /v1/pages/{old_page_id}
   { "properties": { "Status": { "select": { "name": "Contradicted" } } } }
   

2. Create the new memory with Status "Active" (default)
3. Optionally note in new Content what it supersedes: "(Updated: previously recorded as XX)"

Step 7: Report Results

After writing, provide the user with a summary:

• Conversations processed
• Memories created / updated / skipped
• List of new entries with Titles and Categories
• Conflicts detected and how resolved

Example:

Memory archival complete

Processed 8 conversations, generated 12 memories:
- New: 10
- Updated: 1 (user location updated from Beijing to Shenzhen)
- Skipped: 3 low-value conversations

New memories:
| Title | Category |
|-------|----------|
| User prefers uv for Python dependency management | Preference |
| Project OpenClaw uses FastAPI architecture | Decision |

Important Notes

• Atomic entries: One fact per row. Never dump a whole conversation summary into one entry.
• Language: Title and Content should be written in the user's primary language (the language they most frequently use in conversations). This ensures memories are searchable and readable in the language the user naturally uses. Do NOT force English -- match the user's language.
• Idempotent: Always check for existing memories before writing. Running twice should not create duplicates.
• Source accuracy: Auto-set Source based on current platform (Claude.ai -> "Claude.ai", Claude Code -> "ClaudeCode", OpenClaw -> "OpenClaw").
• Preserve details: Keep code snippets, commands, config values, URLs verbatim in Content.
• User control: Don't store anything the user wouldn't want to see. When in doubt, ask.
• Cross-platform ready: Write Content so any AI platform can understand and use it.

Example Interaction

User: summarize memory

Claude:

1. Searches for "Memory Store" database, obtains data_source_id and database_id
2. Reviews current session (Claude Code) or recent chats (Claude.ai)
3. Queries database for existing entries to avoid duplicates
4. Decomposes conversations into atomic memories
5. Writes entries to the database
6. Reports: "Processed 5 conversations, generated 8 new memories, updated 1, skipped 2."