| name | clawdi |
| description | Cross-agent long-term memory + session history for the current user: their preferences, coding habits, named projects / repos / tools, past bugs and architecture decisions, AND their past agent conversations across Claude Code / Codex / OpenClaw / Hermes. Surface this skill BEFORE answering any question about the user themselves, their work, or their history — even when phrased abstractly (e.g. 'what do I usually use for X', 'find the session where I worked on auth'). Also provides connected-service tools (Gmail, GitHub, Notion, Drive, Calendar, etc.) and reads Clawdi share URLs (https://cloud.clawdi.ai/s/...) the user pastes. |
Clawdi Cloud
You have access to Clawdi Cloud tools via the clawdi MCP server. Use them aggressively — memory + session retrieval is the highest-leverage capability you have here.
Memory
Three tools for cross-agent memory:
memory_search — Search long-term memory by natural-language query (any language).memory_add — Save a durable memory for cross-agent recall. Categories: fact (technical facts, API details, config values), preference (user preferences, coding style, workflow choices), pattern (recurring patterns, pitfalls, team conventions), decision (architecture decisions and their reasoning), context (project context, deadlines, ongoing work).memory_extract — Batch-extract durable memories from the CURRENT conversation. Call this when the user says "extract memories", "save what we discussed", "remember this conversation", or equivalent. The tool returns instructions that walk you through a list-then-confirm flow using memory_search and memory_add — follow them exactly, including waiting for the user's approval before writing anything. Never skip the confirmation step, never save more than 5 memories in one invocation, and do not narrate your internal workflow to the user.
When to search — bias toward calling
Default assumption: the user has stored context you don't have. Call memory_search BEFORE answering any question about them, their project, their preferences, or their history. A call that returns empty costs ~100ms; a missed hit makes you look amnesic and forces them to re-teach you every session.
The single most common failure mode is NOT calling memory_search on abstract self-referential questions. If the user's message has any of these shapes, you MUST call it — no judgment, no exceptions:
- Preference / habit questions, even without a specific entity named.
Examples: "what do I usually use for X", "how do I normally do Y", "what's my preferred tool for Z", "what's my coding style". Pass a short paraphrase as the query.
- Callbacks to prior context. "as I mentioned", "like last time", "you know the one", "we discussed before", "what was that X we set up".
- Named entities specific to this user. Their project / repo / service / team / tool name. A person by name.
- Past bugs, decisions, investigations, design choices.
- Start of a new session where they reference anything about themselves or their work.
Do NOT search for:
- Purely textbook programming questions with no user-specific signal ("how does
useEffect work", "what is the time complexity of quicksort").
- Questions the current code already answers directly.
When unsure, search. Empty results cost you nothing. Missing the user's context costs you their trust.
When to save
- After fixing a non-obvious bug (save root cause + fix)
- After making an architecture decision (save reasoning)
- After discovering a useful pattern or workaround
- When the user explicitly says "remember this" / "save this"
- After learning a user preference you'd otherwise have to re-ask ("I prefer rg", "I always use pnpm")
Write memories as standalone sentences with full context — include names, not pronouns. A future session will read this without knowing today's conversation.
Do NOT save trivial facts that are obvious from the code itself, or generic programming knowledge.
Sessions
Two tools for reading and finding past agent conversations stored in Clawdi Cloud:
session_read — Fetch a single session by reference and return its full conversation as Markdown. Accepts a Clawdi share URL (https://cloud.clawdi.ai/s/{uuid}) OR a session UUID for one of the user's own sessions. Handles owned and shared sessions transparently — you don't need to know which one.session_search — Find sessions in the user's history by keyword. Trigram-ranked substring search with typo tolerance. Returns matching sessions with summary, project, timestamps, and session UUIDs you can pass back to session_read.
When to read — call session_read whenever the user references a specific session
MUST call when the user's message includes:
- A Clawdi share URL (e.g.
https://cloud.clawdi.ai/s/11111111-2222-3333-4444-555555555555) — pass the full URL
- A direct reference like "open the session where I did X" or "the one from yesterday about auth" — first call
session_search to find the UUID, then session_read to load it
Do NOT call WebFetch on cloud.clawdi.ai/s/... URLs — session_read is the right tool and avoids the WebFetch permission prompt.
When to search — bias toward calling, similar to memory_search
MUST call session_search when:
- The user asks about prior work: "what did I do about the focus bug", "find the session where I migrated auth", "show me last week's debugging session"
- They reference a past investigation by topic but don't name a specific session
- They want to continue / reuse approach from a prior conversation
Difference from memory_search
memory_search finds stored facts / preferences / decisions the user (or a previous agent run) explicitly extracted. Short rows; high signal.session_search finds full conversations in the corpus. Long rows; useful when the user wants the original context, not just the takeaway.
When the user's request is conceptual ("how do I usually do X"), prefer memory_search. When they want to revisit a specific past conversation ("the session where..."), use session_search. When unsure, try memory_search first (cheaper, faster), fall back to session_search if empty.
Connectors
Connected service tools (Gmail, GitHub, Notion, etc.) are dynamically registered from the user's Clawdi Cloud dashboard. They appear as individual tools like gmail_fetch_emails, github_list_issues, etc.
- These tools are already authenticated — no OAuth needed at runtime
- If a tool call fails with "No connected account", tell the user to connect the service in the Clawdi Cloud dashboard
- File downloads from connectors return signed URLs — download them with
curl or fetch before processing
- Confirm with the user before side-effecting operations (sending email, creating issues, etc.)
