{"owner":"MemoriLabs","repo":"Memori","hasSkills":true,"totalSkillsCount":5,"totalTokensCount":9836,"categories":["anthropic-skill","plugin-manifest"],"hasMcp":true,"mcpConfig":{"mcpServers":{"Memori":{"command":"npx","args":["-y","@modelcontextprotocol/server-Memori"]}}},"found":["integrations/openclaw/skills/memori/SKILL.md","integrations/openclaw/openclaw.plugin.json","integrations/openclaw/skills/clawhub/SKILL.md","integrations/claude-code/SKILL.md","docs/memori-cloud/mcp/skills/memori-mcp/SKILL.md"],"skills":{"integrations/openclaw/skills/memori/SKILL.md":"# Memori skills file\n\nYou have access to Memori, agent-native memory infrastructure: an LLM-agnostic layer that structures memory from not just natural language, but also from agent trace that comes from execution.\n\nMemori automatically captures and structures memory from conversation and execution trace — including the agent's actions, tool results, decisions, and outcomes — and allows you to retrieve it on demand. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so the next time it completes a task, it is more accurate and efficient.\n\n---\n\n## Quick reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue task without interruption.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n---\n\n## Core instruction\n\nAt the start of a session, you should check the `SKILL.md` file\n\nUse it to understand:\n\n- Available capabilities\n- Tooling and integrations\n- Expected behaviors and constraints\n\nTreat `SKILL.md` as a source of truth for what you can do before taking action.\n\n---\n\n## When to use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a session and need current state\n- You want to understand what has already been done\n\n---\n\n## When not to use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n\nAvoid unnecessary recall.\n\n---\n\n## Recall behavior\n\nRecall is **agent-controlled and intentional**.\n\nPrefer targeted recall over broad queries.\n\n### Supported parameters (recall only)\n\n- `entityId` → user, agent, or system context\n- `projectId` → project or workspace context\n- `sessionId` → specific session\n- `dateStart` / `dateEnd` → time-bounded recall\n- `source` → type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal` → how the memory was derived (must be paired with `source` from the allowed combinations below)\n\n> Note: If a `sessionId` is provided, a `projectId` must also be provided.\n> All timestamps are stored in **UTC**.\n\n### Allowed source + signal combinations\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\n### Default behavior (recall)\n\n- No date range → **all-time memory**\n- Use time bounds when narrowing results is necessary\n\n### Best practices\n\n- Start narrow (entity + project)\n- Add time bounds only when needed\n- Use an allowed `(source, signal)` pair to refine results (never set them independently)\n- Expand scope only if needed\n- Do not recall on every turn\n\n---\n\n## Summary behavior\n\nSummaries are used for **state awareness**, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\n### Supported parameters (summaries)\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\n> Summaries do **not** support `source` or `signal`.\n\n### Default behavior (summaries)\n\n- No date range → **last 24 hours**\n\n---\n\n## Daily brief behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\n### Expected daily brief structure\n\n- Today at a glance\n- Top 3 next actions\n- Top 3 risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat this as the working state of the system.\n\n---\n\n## Typical workflow\n\n1. Start of session → retrieve summary\n2. During task → use targeted recall\n3. When memory is missing or incorrect → send feedback\n4. When limits are reached → degrade gracefully\n\n---\n\n## Post-compaction brief behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\n### Use:\n\nmemori_compaction\n\nSupported parameters (post-compaction briefs)\n\nprojectId (required)\nsessionId (optional)\n\nPost-compaction briefs do not support source or signal.\n\n### Default behavior (post-compaction briefs)\n\nRetrieve the most recent relevant post-compaction brief for the project or session.\n\nExpected post-compaction brief structure\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n\n### How to use a post-compaction brief\n\nTreat the post-compaction brief as the agent's resume state.\n\nUse it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\n### Important behavior\n\nThe post-compaction brief should guide continuation, not override explicit user instructions.\n\nBefore acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n---\n\n## Safety and correctness\n\n- Do not invent memory\n- Do not assume memory is correct if it conflicts with the user\n- Verify before acting when needed\n- Treat recent instructions as higher priority than recalled memory\n\n---\n\n## Memori system guidance\n\nThis section defines how you should interact with Memori beyond basic recall.\n\n---\n\n### 1. Feedback (`memori_feedback`)\n\nYou are equipped with the `memori_feedback` tool to improve memory quality over time.\n\nYou may send feedback at any time, and should do so at the end of a session when appropriate.\n\nFeedback should be sent when:\n\n- Recall results are irrelevant or missing key context\n- Important decisions or constraints were not captured\n- Memory quality degrades across sessions\n- Something works particularly well and should be reinforced\n\nExamples:\n\n- \"Send feedback that recall missed a pricing constraint.\"\n- \"Tell Memori the daily brief was accurate.\"\n- \"Submit a bug report: you didn't remember my preferred language.\"\n\n#### Purpose\n\nFeedback improves:\n\n- Memory extraction quality\n- Recall relevance\n- Summary accuracy\n\n---\n\n### 2. Updates\n\nMemori evolves over time (new features, improved recall, better summaries).\n\nWhen updates are exposed:\n\n- Check for updates via system message or tool\n- Adapt behavior to use new capabilities\n\nWhen an update is detected:\n\n- Prefer newer recall patterns when available\n- Use improved summaries or classification outputs\n- Continue operating normally if no changes are required\n\n---\n\n### 3. Account Creation and Onboarding (`memori_signup`)\n\nYou are equipped with the `memori_signup` tool to securely create an account and provision an API key for the user via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing `MEMORI_API_KEY` and the user provides their email address to get one.\n\n#### Behavior:\n\n- **Email Required:** If the user asks to sign up but **does not** provide an email address, you MUST ask them for their email first. Do not attempt to guess or hallucinate an email.\n- **Execution:** Once they provide an email, run `memori_signup` with that email.\n- **Follow-up:** The tool will trigger the underlying CLI and return a success or error message. Relay that message to the user, remind them to check their inbox for the API key, and instruct them to add it to their configuration (`~/.openclaw/openclaw.json` or `.env` file).\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n---\n\n### 4. Quota Awareness and Upgrades (`memori_quota`)\n\nYou are equipped with the `memori_quota` tool to check the user's current memory usage and limits via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or how many memories they have left.\n- You encounter errors suggesting memory limits have been reached and want to confirm before degrading behavior.\n\n#### Behavior:\n\n- **No Parameters Required:** Simply invoke `memori_quota` — it requires no arguments.\n- **Execution:** The tool runs the underlying CLI and returns the user's current usage and quota.\n- **Follow-up:** Relay the result clearly to the user. If they are near or at their limit, explain the impact and suggest an upgrade.\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n#### When limits are reached or nearing:\n\n#### a. Degrade gracefully\n\n- Reduce recall scope (shorter time ranges)\n- Prioritize high-signal memory (decisions, constraints, key facts)\n- Avoid unnecessary or repeated recall calls\n\n#### b. Inform the human/operator\n\nClearly communicate when limits impact performance.\n\nExample:\n\n> \"Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\"\n\n#### c. Suggest upgrades appropriately\n\n- Only prompt when performance is affected\n- Avoid repetitive or disruptive messaging\n- Keep messaging neutral and helpful\n\n---\n","integrations/openclaw/openclaw.plugin.json":"{\n  \"id\": \"openclaw-memori\",\n  \"name\": \"Memori System\",\n  \"version\": \"0.0.13\",\n  \"description\": \"Hosted memory backend\",\n  \"kind\": \"memory\",\n  \"main\": \"dist/index.js\",\n  \"contracts\": {\n    \"tools\": [\n      \"memori_recall\",\n      \"memori_recall_summary\",\n      \"memori_compaction\",\n      \"memori_feedback\",\n      \"memori_signup\",\n      \"memori_quota\"\n    ]\n  },\n  \"uiHints\": {\n    \"apiKey\": {\n      \"label\": \"Memori API Key\",\n      \"sensitive\": true,\n      \"placeholder\": \"Enter your Memori API key...\",\n      \"help\": \"API key from memorilabs.ai (or use MEMORI_API_KEY env var)\"\n    },\n    \"entityId\": {\n      \"label\": \"Entity ID\",\n      \"placeholder\": \"e.g., your-app-user-id\",\n      \"help\": \"Required. The unique identifier to attribute these memories to.\"\n    },\n    \"projectId\": {\n      \"label\": \"Project ID\",\n      \"placeholder\": \"e.g., my-project\",\n      \"help\": \"Required. Scopes all memories to this project.\"\n    }\n  },\n  \"configSchema\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"apiKey\": {\n        \"type\": \"string\",\n        \"title\": \"API Key\",\n        \"description\": \"Memori API Key\"\n      },\n      \"entityId\": {\n        \"type\": \"string\",\n        \"title\": \"Entity ID\",\n        \"description\": \"Required. The unique identifier to attribute these memories to.\"\n      },\n      \"projectId\": {\n        \"type\": \"string\",\n        \"title\": \"Project ID\",\n        \"description\": \"Required. Scopes all memories to this project.\"\n      }\n    },\n    \"required\": []\n  }\n}\n","integrations/openclaw/skills/clawhub/SKILL.md":"---\nname: memori\nid: '@memorilabs/openclaw-memori'\ndescription: Agent-native memory for OpenClaw that structures memory from agent trace, execution history, decisions, tool calls, and conversations into durable long-term memory primitives.\nlicense: Apache-2.0\nhomepage: https://github.com/MemoriLabs/Memori\nrepository: https://github.com/MemoriLabs/Memori.git\ncompatibility:\n  - openclaw\nmetadata:\n  openclaw:\n    requires:\n      env:\n        - MEMORI_API_KEY\n        - ENTITY_ID\n        - PROJECT_ID\n      bins:\n        - memori\n    primaryEnv: MEMORI_API_KEY\n    externalServices:\n      - https://api.memorilabs.ai\n---\n\n# Memori - Structured Long-term Memory for OpenClaw\n\nGive your OpenClaw agents persistent, structured memory derived from agent execution, tool usage, workflow history, and conversations. Memori integrates seamlessly in the background via lifecycle hooks and provides agents with the tools to retrieve context when it is relevant.\n\n## Core Workflow\n\nMemori operates on two parallel tracks through standard OpenClaw lifecycle hooks:\n\n### 1. Advanced Augmentation (automatic)\n\nAfter each interaction, Memori converts raw session data into structured, reusable memories asynchronously.\n\n- Transforms raw agent sessions into structured memory units\n- Captures the agent's actions, reasoning, tool usage, responses, corrections, and failures\n- Organizes into classes to enable efficient retrieval\n- Generates embeddings for semantic retrieval\n- Updates structured memory and the knowledge graph\n\nThis is how structured memory is continuously built and updated over time. It runs after the agent responds and does not impact latency.\n\n### 2. Agent-Controlled-Intelligent Recall\n\nRecall is explicit and initiated by the agent.\n\nMemori separates memory creation from memory recall:\n\n- Creation is automatic (advanced augmentation)\n- Recall is intentional (agent-controlled)\n\nAgents decide:\n\n- When to recall\n- What scope to recall from\n- How much history to include\n\nTo maintain an efficient context window, Memori equips the agent with specific tools to retrieve history when required for the conversation:\n\n1. **`memori_recall`**: Searches the structured memory graph for specific facts, constraints, and prior decisions.\n2. **`memori_recall_summary`**: Retrieves structured daily briefs and rolling summaries of prior sessions.\n3. **`memori_compaction`**: Retrieves structured post-compaction brief to continue task without interruption.\n4. **`memori_feedback`**: Reports on memory quality to improve extraction accuracy.\n\n## Installation\n\n```bash\nopenclaw plugins install @memorilabs/openclaw-memori\n```\n\n## Configuration\n\nAdd to your `~/.openclaw/openclaw.json` or use the `openclaw memori init` CLI command to set up your workspace:\n\n```bash\nopenclaw memori init \\\n  --api-key \"YOUR_MEMORI_API_KEY\" \\\n  --entity-id \"your-entity-id\" \\\n  --project-id \"your-project-id\"\n```\n\nAlternatively, configure it directly via JSON:\n\n```json\n{\n  \"plugins\": {\n    \"entries\": {\n      \"openclaw-memori\": {\n        \"enabled\": true,\n        \"config\": {\n          \"apiKey\": \"${MEMORI_API_KEY}\",\n          \"entityId\": \"openclaw-user\",\n          \"projectId\": \"default-project\"\n        }\n      }\n    }\n  }\n}\n```\n\n### Configuration Options\n\n- **apiKey** (required): Memori API key — acquire with `memori signup`\n- **entityId** (required): Unique identifier for this user's memories\n- **projectId** (required): Scopes all memories to a specific project or workspace\n\n## Agentic Tool Guidelines\n\nWhen this plugin is active, the agent is equipped with tools to manage long-term context. The agent should use its discretion to call these tools when helpful:\n\n- **Contextual Recall**: The agent can run a `memori_recall` search to retrieve relevant details if context is missing regarding user preferences.\n- **Summaries**: The agent can utilize the `memori_recall_summary` tool to construct a brief if a user requests a recap.\n- **Account Creation**: If a user explicitly asks to create an account, the agent can use the `memori_signup` tool to initiate the process by asking for an email address. Keys are never returned in the chat. The system securely emails the credentials to the user, who must then manually configure them to activate the plugin.\n- **Quota Monitoring**: The agent can use the `memori_quota` tool to check the user's current memory usage and storage limits to communicate quota status or gracefully degrade behavior if limits are reached.\n- **Date Defaults**: If the agent chooses to search memory, providing specific start/end dates is recommended to keep context windows efficient. Omitting dates will search all available history.\n\n## Verification\n\nCheck that the plugin is working and securely connected:\n\n```bash\n# Verify plugin is securely connected to the API\nopenclaw memori status --check\n\n# Check for Memori logs in gateway output\nopenclaw gateway logs --filter \"[Memori]\"\n```\n\n## Quota Management\n\nCheck your current API quota:\n\n```bash\nmemori quota\n```\n\n**Example output:**\n\n```\n __  __                           _\n|  \\/  | ___ _ __ ___   ___  _ __(_)\n| |\\/| |/ _ \\ '_ ` _ \\ / _ \\| '__| |\n| |  | |  __/ | | | | | (_) | |  | |\n|_|  |_|\\___|_| |_| |_|\\___/|_|  |_|\n                  perfectam memoriam\n                       memorilabs.ai\n\n+ Maximum # of Memories: 100\n+ Current # of Memories: 0\n\n+ You are not currently over quota.\n```\n\nUse this to monitor usage and upgrade if needed.\n\n## Performance\n\n- **Automatic deduplication** prevents memory bloat\n- **Agent-controlled retrieval** ensures token usage remains targeted, compact, and actionable\n- **Semantic ranking** ensures relevant memories surface first\n\n## Privacy, Consent & Data Handling\n\n**Explicit Opt-In Required:** Memori requires the user to explicitly configure an API key (`MEMORI_API_KEY`) and an `entityId`. **No data is captured or transmitted unless these credentials are actively provided by the user.**\n\n- ✅ Conversations are securely transmitted to the Memori backend (`https://api.memorilabs.ai`) only when the plugin is fully configured by the user.\n- ✅ Data is encrypted in transit and at rest.\n- ✅ Users control their data scope via their specific `projectId` and `entityId`.\n- ✅ The backend automatically filters sensitive data (API keys, passwords, secrets) prior to storage.\n\nFor details: [Memori Privacy Policy](https://memorilabs.ai/privacy)\n\n## Memory Persistence\n\nMemories persist safely across:\n\n- Session restarts\n- Gateway restarts\n- System reboots\n- OpenClaw upgrades\n\nAll storage is handled by the Memori backend and is scoped safely alongside your local `MEMORY.md` file without overwriting it.\n\n## Troubleshooting\n\n**Plugin not loading:**\n\n- Verify `enabled: true` in openclaw.json\n- Check API key: `echo $MEMORI_API_KEY`\n- Restart gateway: `openclaw gateway restart`\n\n**No memories captured:**\n\n- Check gateway logs for `[Memori]` errors\n- Verify API endpoint reachable\n- Test API key: `memori quota`\n\n**Memories not recalled:**\n\n- Did the agent utilize the retrieval tool? Check your gateway logs for `memori_recall` tool execution. If it didn't use the tool, you can prompt it to search its memory.\n- Ensure `entityId` and `projectId` are consistent across sessions.\n- Verify memories exist: `memori quota` shows count > 0.\n\n**Quota exceeded:**\n\n- Run `memori quota` to check usage\n- Upgrade at [memorilabs.ai](https://app.memorilabs.ai/)\n- Or clear old memories via dashboard\n\n## Learn More\n\n- **npm Package**: https://www.npmjs.com/package/@memorilabs/openclaw-memori\n- **GitHub**: https://github.com/MemoriLabs/Memori\n- **Documentation**: https://memorilabs.ai/docs/memori-cloud/openclaw/overview/\n- **API Dashboard**: https://app.memorilabs.ai/\n- **Support**: [GitHub Issues](https://github.com/MemoriLabs/Memori/issues)\n\n## Notes\n\nThis skill informs the agent about the Memori plugin. The plugin must be installed separately via npm. Once installed, memory capture happens in the background, and the agent is empowered to explicitly query its memories when needed.\n","integrations/claude-code/SKILL.md":"---\nname: memori\ndescription: >\n  Ambient Memori long-term memory for Claude Code via local Bash. MUST TRIGGER\n  on essentially every non-trivial user turn: run recall before drafting any\n  substantive response, whether or not the user mentioned memory, a prior\n  session, or past work. The default is to check memory first; do not wait to\n  be asked. Always fire before external lookups (WebSearch/WebFetch) and\n  before answering any question about preferences, prior decisions,\n  constraints, project history, status, past work, or any non-trivial\n  coding/research task. Skip only for trivial acknowledgements/closings,\n  purely self-contained turns where prior context cannot possibly help, or\n  when the user explicitly opts out. Use Advanced Augmentation after drafting\n  the final response for every non-trivial turn, as the last memory step. Use\n  recall.summary only for broad session summaries/orientation, compaction\n  after context loss, feedback for memory quality, quota for limits, and\n  signup only when explicitly requested.\nargument-hint: '<command> [--flags ...]'\nallowed-tools: Bash\n---\n\n# Memori Claude Code Skill\n\nThin CLI wrapper around Memori Cloud for Claude Code subprocesses. Memori is an\nambient memory enhancement, not an explicit destination tool. Do not wait for\nthe user to ask to \"use Memori\" before applying the memory lifecycle below.\nClaude Code's primary job remains answering the user, editing code, debugging,\nreviewing, and completing the requested work.\n\nRun commands from the Claude Code integration root:\n\n```bash\nbun .claude/skills/memori/index.ts <command> [--flags ...]\n```\n\nFlags accept `--flag value` or `--flag=value`.\n\n## Setup\n\nConfigure credentials in `.claude/settings.local.json` (per-project, not\nchecked into source control). Claude Code injects everything under `env`\ninto every Bash subprocess, including this skill:\n\n```json\n{\n  \"env\": {\n    \"MEMORI_API_KEY\": \"your_memori_api_key\",\n    \"MEMORI_ENTITY_ID\": \"stable_identifier_for_this_user\"\n  }\n}\n```\n\nRequired:\n\n- `MEMORI_API_KEY` — Memori Cloud API key.\n- `MEMORI_ENTITY_ID` — any stable string that namespaces memory for this\n  user/agent. If it is missing on the first command, pick a sensible default\n  yourself (the machine hostname, or a generated UUID), write it to `.claude/settings.local.json` so it persists,\n  and continue. If no sensible default can be inferred, ask the user.\n\nAuto-resolved (no setup required, override with flags or env if needed):\n\n- `MEMORI_PROJECT_ID` — defaults to `basename($CLAUDE_PROJECT_DIR)`, the\n  Claude Code workspace folder name. Override per call with `--projectId`,\n  or pin it by adding `MEMORI_PROJECT_ID` to the `env` block.\n- `MEMORI_SESSION_ID` — defaults to `$CLAUDE_CODE_SESSION_ID` for writes\n  (`advanced-augmentation`) and for `compaction` (which by definition\n  restores the current session). **Reads (`recall`, `recall.summary`) do\n  not auto-apply session_id** — it is a narrowing filter on the agent\n  recall API, so the default keeps retrieval project-scoped across new\n  Claude Code sessions and `/clear`. Pass `--sessionId` explicitly when\n  you want a single-session recall.\n\nOptional:\n\n- `MEMORI_PROCESS_ID` — process attribution for `advanced-augmentation`.\n\nA colocated `.env` file next to `index.ts` is loaded as a fallback when\n`settings.local.json` is not used.\n\n## Commands\n\n```bash\nbun .claude/skills/memori/index.ts recall [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO] [--source SOURCE --signal SIGNAL]\nbun .claude/skills/memori/index.ts recall.summary [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO]\nbun .claude/skills/memori/index.ts advanced-augmentation --userMessage \"$USER_MESSAGE\" --assistantMessage \"$ASSISTANT_MESSAGE\" [--sessionId ID] [--projectId ID] [--model MODEL] [--summary \"$SUMMARY\"] [--trace \"$TRACE_JSON\"] [--processId ID]\nbun .claude/skills/memori/index.ts compaction [--projectId ID] [--sessionId ID] [--numMessages 5]\nbun .claude/skills/memori/index.ts feedback --content \"feedback text\"\nbun .claude/skills/memori/index.ts quota\nbun .claude/skills/memori/index.ts signup --email \"user@example.com\"\n```\n\n## Procedure\n\n1. Run `recall` before drafting any substantive response. This is the default\n   for every non-trivial user turn — including general coding tasks,\n   debugging, code review, and research — not just memory-question turns. Do\n   not wait for the user to mention a previous session, past work, or memory;\n   the default is to check memory first.\n2. Always run `recall` before any external information lookup (WebSearch,\n   WebFetch, or any other tool that fetches facts from outside the repo). The\n   user may have prior context on the topic stored in Memori, and memory must\n   be consulted before going external. This is mandatory.\n3. Use `recall.summary` only for broad summary cases: session orientation,\n   daily briefs, broad status, or reorientation after a long gap. Do not use\n   it for specific user queries.\n4. Use `compaction` only after context compaction or lost working context.\n5. Answer or complete the user's actual request. Memory should improve\n   context, not replace the answer.\n6. After drafting the final response for a non-trivial turn, run\n   `advanced-augmentation` with that final response. This is mandatory\n   ambient bookkeeping and must be the last memory step of the turn.\n7. Use `feedback`, `quota`, and `signup` only when the user request or a\n   Memori error makes them relevant.\n\nSkip the memory lifecycle only for trivial acknowledgements/closings, purely\nself-contained turns where prior context cannot help, or when the user\nexplicitly asks not to remember/store the turn.\n\n## Recall\n\n`recall` is targeted retrieval. The endpoint does not support `query`; never\npass `--query`. Use filters, especially source/signal.\n\nFor prompts like \"what did we discuss last session about X?\", run `recall`\nbefore answering even though the topic text cannot be passed as `--query`. Use\nthe closest source/signal category and then answer from the returned memories.\n\nSource and signal must be provided together:\n\n| Use case | Flags |\n|---|---|\n| Fact or preference | `--source fact --signal verification` |\n| Prior decision | `--source decision --signal commit` |\n| Constraint or requirement | `--source constraint --signal discovery` |\n| Standing instruction | `--source instruction --signal discovery` |\n| Status or progress | `--source status --signal update` |\n| Completed task/result | `--source task --signal result` |\n| Failure or error | `--source execution --signal failure` |\n| Strategy or pattern | `--source strategy --signal pattern` |\n| Inferred lesson | `--source insight --signal inference` |\n\n## Advanced Augmentation\n\nRun after drafting the final assistant response for every non-trivial turn:\n\n```bash\nbun .claude/skills/memori/index.ts advanced-augmentation \\\n  --userMessage \"$USER_MESSAGE\" \\\n  --assistantMessage \"$ASSISTANT_MESSAGE\" \\\n  --trace \"$TRACE_JSON\"\n```\n\n`--sessionId` defaults to `$CLAUDE_CODE_SESSION_ID`; pass it explicitly only\nwhen correlating with a session other than the current Claude Code one.\n\nTrace is JSON shaped like `{ \"tools\": [...] }`. If omitted, the CLI sends\n`{ \"tools\": [] }`. Each tool entry must include:\n\n- `name`: string tool/function name\n- `args`: object of arguments passed to the tool\n- `result`: summarized tool result; the key must be present\n\nValid trace example:\n\n```json\n{\n  \"tools\": [\n    {\n      \"name\": \"ReadFile\",\n      \"args\": { \"path\": \"src/app.ts\" },\n      \"result\": \"Read app entrypoint\"\n    }\n  ]\n}\n```\n\nDo not include secrets, credentials, or large raw logs in trace fields.\n\n## Output And Errors\n\nOn success, commands print JSON to stdout and exit 0. On failure, errors print\nto stderr and exit 1. If memory fails, briefly report the memory issue when\nrelevant and continue with the user's actual request using current context.\n","docs/memori-cloud/mcp/skills/memori-mcp/SKILL.md":"---\nname: memori-mcp-usage\ndescription: Use when an MCP-connected agent should use Memori tools for targeted recall, summaries, post-compaction briefs, durable memory augmentation, quota checks, signup, feedback, preferences, prior context, or cross-session continuity.\nversion: 0.5.0\nauthor: Memori Labs\nlicense: MIT\nmetadata:\n  tags: [Memori, MCP, Memory, Recall, Summary, Compaction, Advanced Augmentation]\n  homepage: https://memorilabs.ai/\n---\n\n# Memori skills file\n\n## Overview\n\nMemori is agent-native memory infrastructure: an LLM-agnostic layer that structures memory from natural language and from agent execution trace.\n\nMemori automatically captures and structures memory from conversation and execution trace, including the agent's actions, tool results, decisions, and outcomes. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so future work is more accurate and efficient.\n\n## Core Instruction\n\nWhen Memori MCP tools are available, treat this skill as the source of truth for how to use Memori through MCP.\n\nUse it to understand:\n\n- Available Memori capabilities\n- Tooling and integrations\n- Expected behavior and constraints\n- Safety and privacy implications\n\nMCP server configuration supplies authenticated user or tenant context through request headers. Do not invent entity, process, project, or session identifiers.\n\nCurrent user instructions, verified local context, and tool results outrank recalled memory.\n\n## Quick Reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue work after context compaction.\n- `memori_advanced_augmentation`: store durable memory from a completed user/assistant turn.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n## When to Use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a meaningful session and need current state\n- You want to understand what has already been done\n\n## When Not to Use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n- The message is trivial, administrative, or closing (for example \"thanks\", \"ok\", \"goodbye\")\n\nAvoid unnecessary recall.\n\n## Recall Behavior\n\nRecall is agent-controlled and intentional. Prefer targeted recall over broad queries.\n\nUse:\n\n- `memori_recall`\n\nSupported parameters:\n\n- `query`: natural language search query\n- `projectId`: project or workspace context, when the tool schema exposes it\n- `sessionId`: specific session, only with `projectId`\n- `dateStart` / `dateEnd`: UTC time-bounded recall\n- `source`: type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal`: how the memory was derived (must be paired with `source` from the allowed combinations below)\n\nIf a `sessionId` is provided, a `projectId` must also be provided. All timestamps are stored in UTC.\n\nPass optional scope fields only when the tool schema exposes them and the active client or workspace provides reliable values.\n\nAllowed source + signal combinations:\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\nDefault behavior:\n\n- No date range means all-time memory.\n\nBest practices:\n\n- Best query: use the latest user message verbatim.\n- Good query: use a short rephrased intent when the message is long or noisy.\n- Avoid generic queries like \"preferences\", \"memory\", or \"context\".\n- Start narrow with project or workspace scope, then expand only if needed.\n- Prefer one recall call per turn.\n- Do not recall on every turn.\n\n## Summary Behavior\n\nSummaries are used for state awareness, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\nSupported parameters:\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\nSummaries do not support `source` or `signal`.\n\nDefault behavior:\n\n- No date range means Memori's summary default, currently the recent working window.\n\n## Daily Brief Behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\nUseful daily brief shape:\n\n- Today at a glance\n- Top next actions\n- Top risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat summaries as working state, not unquestionable truth. If the answer depends on one specific decision, preference, or prior outcome, use `memori_recall` or verify against current sources.\n\n## Post-Compaction Brief Behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\nUse:\n\n- `memori_compaction`\n\nSupported parameters:\n\n- `projectId`: project or workspace context; required when the tool schema requires it\n- `sessionId`: specific session, only with `projectId`\n- `numMessages`: number of recent conversation messages to include\n\nPost-compaction briefs do not support `source` or `signal`.\n\nDefault behavior:\n\n- Retrieve the most recent relevant post-compaction brief for the project or session.\n- Include a small tail of recent conversation messages unless more context is explicitly needed.\n\nExpected post-compaction brief structure:\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n- Messages\n\nTreat the post-compaction brief as the agent's resume state. Use it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\nThe post-compaction brief should guide continuation, not override explicit user instructions. Before acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n## Advanced Augmentation\n\nThrough MCP, durable memory is stored explicitly with `memori_advanced_augmentation` after you draft a response.\n\nUse `memori_advanced_augmentation` only when the turn reveals durable information that would still be useful weeks from now in another conversation.\n\nSupported parameters:\n\n- `user_message`: the user's message for this turn\n- `assistant_response`: the final assistant response for this turn\n- `projectId`: project or workspace scope, when available\n- `sessionId`: session scope, when available\n- `summary`: concise durable summary, when the tool schema supports it\n- `trace`: relevant execution trace, when the tool schema supports it and it is safe to store\n\nGood candidates:\n\n- Explicit preferences: \"always\", \"from now on\", \"default to\", \"I prefer\"\n- Stable profile facts the user wants remembered: role, timezone, location, usual environment, accessibility needs\n- Long-lived project context: tooling, architecture decisions, naming conventions, ownership, deployment constraints\n- Durable workflow norms: review standards, release process, test strategy, formatting conventions\n\n### Do Not Augment\n\nNever store:\n\n- Secrets, API keys, tokens, passwords, credentials, or sensitive personal data\n- Large logs, stack traces, raw tool output, or one-time error dumps\n- Temporary values, codes, links, live prices, schedules, or expiring facts\n- Role-play, hypotheticals, fictional statements, or examples\n- Routine session progress such as tests passed, commands run, files edited, or commit messages\n- Routine task activity such as refactors, imports, renames, or formatting\n- Conversation-scoped choices that are not lasting preferences\n\nIf the user says not to remember, store, save, log, or keep this turn, respect that. You may still recall if needed, but do not augment.\n\nRule of thumb: if the information describes what happened in this session rather than a fact or preference that should shape future sessions, do not augment.\n\n## Procedure\n\n1. If the message is trivial or the user opts out of storage, skip augmentation (and usually recall).\n2. After context compaction: retrieve resume state with `memori_compaction`.\n3. Start of a meaningful session: retrieve a summary with `memori_recall_summary`.\n4. During the task: use targeted `memori_recall` when prior context would materially improve the answer.\n5. Answer using useful recalled context, but verify anything stale, surprising, or high stakes.\n6. After drafting the final response: call `memori_advanced_augmentation` only for durable facts, preferences, or project context.\n7. When memory is missing or incorrect: send `memori_feedback`.\n8. When limits are reached: check `memori_quota` if needed and degrade gracefully.\n\n## Common Pitfalls\n\n- Do not use broad recall when the user needs one specific fact, decision, or prior outcome.\n- Do not treat summaries as authoritative when exact details matter; use targeted recall or verify against current sources.\n- Do not use compaction for targeted memory search or routine turns.\n- Do not call signup, quota, or feedback tools unless the user's request or a Memori error makes them relevant.\n- Do not provide a `sessionId` without also providing a `projectId`.\n- Do not invent entity, process, project, or session identifiers; MCP headers supply attribution context.\n- Do not hide privacy tradeoffs: augmentation may store completed-turn context and safe trace fields when the client provides them.\n- Do not let memory override current user instructions, repository rules, or verified facts from the active workspace.\n\n## Safety and Correctness\n\n- Do not invent memory.\n- Do not assume memory is correct if it conflicts with the user.\n- Verify before acting when needed.\n- Treat current user instructions as higher priority than recalled memory.\n- If a signup, quota, or memory tool fails because the MCP server is unavailable, misconfigured, unauthorized, or missing credentials, explain the setup gap plainly and do not invent memory results.\n\n## Feedback\n\nUse:\n\n- `memori_feedback`\n\nSend feedback when:\n\n- Recall results are irrelevant or missing key context.\n- Important decisions or constraints were not captured.\n- A summary omits important current state.\n- Memory quality degrades across sessions.\n- Something works particularly well and should be reinforced.\n\nKeep feedback concise and specific. Do not send feedback for ordinary task completion.\n\nFeedback improves memory extraction quality, recall relevance, and summary accuracy.\n\n## Account Creation and Onboarding\n\nUse:\n\n- `memori_signup`\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing Memori API key and the user provides their email address.\n\nBehavior:\n\n- If the user asks to sign up but does not provide an email address, ask for their email first.\n- Once they provide an email, run `memori_signup` with that email.\n- Relay the tool result, remind them to check their inbox for the API key, and tell them to configure the Memori MCP server with `X-Memori-API-Key` and `X-Memori-Entity-Id` in their client MCP config.\n- Do not guess or hallucinate an email address.\n\n## Quota Awareness and Upgrades\n\nUse:\n\n- `memori_quota`\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or remaining memory capacity.\n- Errors suggest memory limits have been reached and you want to confirm before degrading behavior.\n\nBehavior:\n\n- Invoke `memori_quota` with no arguments when the tool schema allows it.\n- Relay the result clearly.\n- If limits are near or reached, explain the impact and suggest an upgrade only when performance is affected.\n\nWhen limits are reached or near:\n\n- Reduce recall scope.\n- Prioritize high-signal memory, especially decisions, constraints, key facts, and execution results.\n- Avoid unnecessary or repeated recall calls.\n- Tell the user when limits affect memory behavior.\n\nExample:\n\n> Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\n\n## Updates\n\nMemori may expose improved recall patterns, summaries, classification, or tool behavior over time.\n\nWhen an update is exposed through the system, tool metadata, or user-provided docs:\n\n- Prefer the newer recall or summary behavior when available.\n- Keep this skill's safety, privacy, and intentional-use rules in force.\n- Continue normally if no behavior change is required.\n\n## Verification\n\nConfirm the skill is working in a fresh MCP client session:\n\n1. Verify the Memori MCP server is connected and lists `memori_recall`, `memori_recall_summary`, `memori_compaction`, and `memori_advanced_augmentation`.\n2. Tell the agent a durable preference such as \"I always use tabs over spaces.\"\n3. After augmentation completes, start a later session and ask it to write code.\n\nExpected behavior:\n\n- The agent should use Memori MCP tools rather than answer from generic memory knowledge.\n- The answer should distinguish precise recall from broad state summaries.\n- The answer should mention targeted use, avoiding unnecessary recall, and treating current user instructions as higher priority than memory.\n- If Memori credentials or the MCP server are unavailable, the agent should explain the setup gap without inventing recall results.\n"},"files":{"integrations/openclaw/skills/memori/SKILL.md":"# Memori skills file\n\nYou have access to Memori, agent-native memory infrastructure: an LLM-agnostic layer that structures memory from not just natural language, but also from agent trace that comes from execution.\n\nMemori automatically captures and structures memory from conversation and execution trace — including the agent's actions, tool results, decisions, and outcomes — and allows you to retrieve it on demand. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so the next time it completes a task, it is more accurate and efficient.\n\n---\n\n## Quick reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue task without interruption.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n---\n\n## Core instruction\n\nAt the start of a session, you should check the `SKILL.md` file\n\nUse it to understand:\n\n- Available capabilities\n- Tooling and integrations\n- Expected behaviors and constraints\n\nTreat `SKILL.md` as a source of truth for what you can do before taking action.\n\n---\n\n## When to use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a session and need current state\n- You want to understand what has already been done\n\n---\n\n## When not to use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n\nAvoid unnecessary recall.\n\n---\n\n## Recall behavior\n\nRecall is **agent-controlled and intentional**.\n\nPrefer targeted recall over broad queries.\n\n### Supported parameters (recall only)\n\n- `entityId` → user, agent, or system context\n- `projectId` → project or workspace context\n- `sessionId` → specific session\n- `dateStart` / `dateEnd` → time-bounded recall\n- `source` → type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal` → how the memory was derived (must be paired with `source` from the allowed combinations below)\n\n> Note: If a `sessionId` is provided, a `projectId` must also be provided.\n> All timestamps are stored in **UTC**.\n\n### Allowed source + signal combinations\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\n### Default behavior (recall)\n\n- No date range → **all-time memory**\n- Use time bounds when narrowing results is necessary\n\n### Best practices\n\n- Start narrow (entity + project)\n- Add time bounds only when needed\n- Use an allowed `(source, signal)` pair to refine results (never set them independently)\n- Expand scope only if needed\n- Do not recall on every turn\n\n---\n\n## Summary behavior\n\nSummaries are used for **state awareness**, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\n### Supported parameters (summaries)\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\n> Summaries do **not** support `source` or `signal`.\n\n### Default behavior (summaries)\n\n- No date range → **last 24 hours**\n\n---\n\n## Daily brief behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\n### Expected daily brief structure\n\n- Today at a glance\n- Top 3 next actions\n- Top 3 risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat this as the working state of the system.\n\n---\n\n## Typical workflow\n\n1. Start of session → retrieve summary\n2. During task → use targeted recall\n3. When memory is missing or incorrect → send feedback\n4. When limits are reached → degrade gracefully\n\n---\n\n## Post-compaction brief behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\n### Use:\n\nmemori_compaction\n\nSupported parameters (post-compaction briefs)\n\nprojectId (required)\nsessionId (optional)\n\nPost-compaction briefs do not support source or signal.\n\n### Default behavior (post-compaction briefs)\n\nRetrieve the most recent relevant post-compaction brief for the project or session.\n\nExpected post-compaction brief structure\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n\n### How to use a post-compaction brief\n\nTreat the post-compaction brief as the agent's resume state.\n\nUse it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\n### Important behavior\n\nThe post-compaction brief should guide continuation, not override explicit user instructions.\n\nBefore acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n---\n\n## Safety and correctness\n\n- Do not invent memory\n- Do not assume memory is correct if it conflicts with the user\n- Verify before acting when needed\n- Treat recent instructions as higher priority than recalled memory\n\n---\n\n## Memori system guidance\n\nThis section defines how you should interact with Memori beyond basic recall.\n\n---\n\n### 1. Feedback (`memori_feedback`)\n\nYou are equipped with the `memori_feedback` tool to improve memory quality over time.\n\nYou may send feedback at any time, and should do so at the end of a session when appropriate.\n\nFeedback should be sent when:\n\n- Recall results are irrelevant or missing key context\n- Important decisions or constraints were not captured\n- Memory quality degrades across sessions\n- Something works particularly well and should be reinforced\n\nExamples:\n\n- \"Send feedback that recall missed a pricing constraint.\"\n- \"Tell Memori the daily brief was accurate.\"\n- \"Submit a bug report: you didn't remember my preferred language.\"\n\n#### Purpose\n\nFeedback improves:\n\n- Memory extraction quality\n- Recall relevance\n- Summary accuracy\n\n---\n\n### 2. Updates\n\nMemori evolves over time (new features, improved recall, better summaries).\n\nWhen updates are exposed:\n\n- Check for updates via system message or tool\n- Adapt behavior to use new capabilities\n\nWhen an update is detected:\n\n- Prefer newer recall patterns when available\n- Use improved summaries or classification outputs\n- Continue operating normally if no changes are required\n\n---\n\n### 3. Account Creation and Onboarding (`memori_signup`)\n\nYou are equipped with the `memori_signup` tool to securely create an account and provision an API key for the user via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing `MEMORI_API_KEY` and the user provides their email address to get one.\n\n#### Behavior:\n\n- **Email Required:** If the user asks to sign up but **does not** provide an email address, you MUST ask them for their email first. Do not attempt to guess or hallucinate an email.\n- **Execution:** Once they provide an email, run `memori_signup` with that email.\n- **Follow-up:** The tool will trigger the underlying CLI and return a success or error message. Relay that message to the user, remind them to check their inbox for the API key, and instruct them to add it to their configuration (`~/.openclaw/openclaw.json` or `.env` file).\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n---\n\n### 4. Quota Awareness and Upgrades (`memori_quota`)\n\nYou are equipped with the `memori_quota` tool to check the user's current memory usage and limits via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or how many memories they have left.\n- You encounter errors suggesting memory limits have been reached and want to confirm before degrading behavior.\n\n#### Behavior:\n\n- **No Parameters Required:** Simply invoke `memori_quota` — it requires no arguments.\n- **Execution:** The tool runs the underlying CLI and returns the user's current usage and quota.\n- **Follow-up:** Relay the result clearly to the user. If they are near or at their limit, explain the impact and suggest an upgrade.\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n#### When limits are reached or nearing:\n\n#### a. Degrade gracefully\n\n- Reduce recall scope (shorter time ranges)\n- Prioritize high-signal memory (decisions, constraints, key facts)\n- Avoid unnecessary or repeated recall calls\n\n#### b. Inform the human/operator\n\nClearly communicate when limits impact performance.\n\nExample:\n\n> \"Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\"\n\n#### c. Suggest upgrades appropriately\n\n- Only prompt when performance is affected\n- Avoid repetitive or disruptive messaging\n- Keep messaging neutral and helpful\n\n---\n","integrations/openclaw/openclaw.plugin.json":"{\n  \"id\": \"openclaw-memori\",\n  \"name\": \"Memori System\",\n  \"version\": \"0.0.13\",\n  \"description\": \"Hosted memory backend\",\n  \"kind\": \"memory\",\n  \"main\": \"dist/index.js\",\n  \"contracts\": {\n    \"tools\": [\n      \"memori_recall\",\n      \"memori_recall_summary\",\n      \"memori_compaction\",\n      \"memori_feedback\",\n      \"memori_signup\",\n      \"memori_quota\"\n    ]\n  },\n  \"uiHints\": {\n    \"apiKey\": {\n      \"label\": \"Memori API Key\",\n      \"sensitive\": true,\n      \"placeholder\": \"Enter your Memori API key...\",\n      \"help\": \"API key from memorilabs.ai (or use MEMORI_API_KEY env var)\"\n    },\n    \"entityId\": {\n      \"label\": \"Entity ID\",\n      \"placeholder\": \"e.g., your-app-user-id\",\n      \"help\": \"Required. The unique identifier to attribute these memories to.\"\n    },\n    \"projectId\": {\n      \"label\": \"Project ID\",\n      \"placeholder\": \"e.g., my-project\",\n      \"help\": \"Required. Scopes all memories to this project.\"\n    }\n  },\n  \"configSchema\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"apiKey\": {\n        \"type\": \"string\",\n        \"title\": \"API Key\",\n        \"description\": \"Memori API Key\"\n      },\n      \"entityId\": {\n        \"type\": \"string\",\n        \"title\": \"Entity ID\",\n        \"description\": \"Required. The unique identifier to attribute these memories to.\"\n      },\n      \"projectId\": {\n        \"type\": \"string\",\n        \"title\": \"Project ID\",\n        \"description\": \"Required. Scopes all memories to this project.\"\n      }\n    },\n    \"required\": []\n  }\n}\n","integrations/openclaw/skills/clawhub/SKILL.md":"---\nname: memori\nid: '@memorilabs/openclaw-memori'\ndescription: Agent-native memory for OpenClaw that structures memory from agent trace, execution history, decisions, tool calls, and conversations into durable long-term memory primitives.\nlicense: Apache-2.0\nhomepage: https://github.com/MemoriLabs/Memori\nrepository: https://github.com/MemoriLabs/Memori.git\ncompatibility:\n  - openclaw\nmetadata:\n  openclaw:\n    requires:\n      env:\n        - MEMORI_API_KEY\n        - ENTITY_ID\n        - PROJECT_ID\n      bins:\n        - memori\n    primaryEnv: MEMORI_API_KEY\n    externalServices:\n      - https://api.memorilabs.ai\n---\n\n# Memori - Structured Long-term Memory for OpenClaw\n\nGive your OpenClaw agents persistent, structured memory derived from agent execution, tool usage, workflow history, and conversations. Memori integrates seamlessly in the background via lifecycle hooks and provides agents with the tools to retrieve context when it is relevant.\n\n## Core Workflow\n\nMemori operates on two parallel tracks through standard OpenClaw lifecycle hooks:\n\n### 1. Advanced Augmentation (automatic)\n\nAfter each interaction, Memori converts raw session data into structured, reusable memories asynchronously.\n\n- Transforms raw agent sessions into structured memory units\n- Captures the agent's actions, reasoning, tool usage, responses, corrections, and failures\n- Organizes into classes to enable efficient retrieval\n- Generates embeddings for semantic retrieval\n- Updates structured memory and the knowledge graph\n\nThis is how structured memory is continuously built and updated over time. It runs after the agent responds and does not impact latency.\n\n### 2. Agent-Controlled-Intelligent Recall\n\nRecall is explicit and initiated by the agent.\n\nMemori separates memory creation from memory recall:\n\n- Creation is automatic (advanced augmentation)\n- Recall is intentional (agent-controlled)\n\nAgents decide:\n\n- When to recall\n- What scope to recall from\n- How much history to include\n\nTo maintain an efficient context window, Memori equips the agent with specific tools to retrieve history when required for the conversation:\n\n1. **`memori_recall`**: Searches the structured memory graph for specific facts, constraints, and prior decisions.\n2. **`memori_recall_summary`**: Retrieves structured daily briefs and rolling summaries of prior sessions.\n3. **`memori_compaction`**: Retrieves structured post-compaction brief to continue task without interruption.\n4. **`memori_feedback`**: Reports on memory quality to improve extraction accuracy.\n\n## Installation\n\n```bash\nopenclaw plugins install @memorilabs/openclaw-memori\n```\n\n## Configuration\n\nAdd to your `~/.openclaw/openclaw.json` or use the `openclaw memori init` CLI command to set up your workspace:\n\n```bash\nopenclaw memori init \\\n  --api-key \"YOUR_MEMORI_API_KEY\" \\\n  --entity-id \"your-entity-id\" \\\n  --project-id \"your-project-id\"\n```\n\nAlternatively, configure it directly via JSON:\n\n```json\n{\n  \"plugins\": {\n    \"entries\": {\n      \"openclaw-memori\": {\n        \"enabled\": true,\n        \"config\": {\n          \"apiKey\": \"${MEMORI_API_KEY}\",\n          \"entityId\": \"openclaw-user\",\n          \"projectId\": \"default-project\"\n        }\n      }\n    }\n  }\n}\n```\n\n### Configuration Options\n\n- **apiKey** (required): Memori API key — acquire with `memori signup`\n- **entityId** (required): Unique identifier for this user's memories\n- **projectId** (required): Scopes all memories to a specific project or workspace\n\n## Agentic Tool Guidelines\n\nWhen this plugin is active, the agent is equipped with tools to manage long-term context. The agent should use its discretion to call these tools when helpful:\n\n- **Contextual Recall**: The agent can run a `memori_recall` search to retrieve relevant details if context is missing regarding user preferences.\n- **Summaries**: The agent can utilize the `memori_recall_summary` tool to construct a brief if a user requests a recap.\n- **Account Creation**: If a user explicitly asks to create an account, the agent can use the `memori_signup` tool to initiate the process by asking for an email address. Keys are never returned in the chat. The system securely emails the credentials to the user, who must then manually configure them to activate the plugin.\n- **Quota Monitoring**: The agent can use the `memori_quota` tool to check the user's current memory usage and storage limits to communicate quota status or gracefully degrade behavior if limits are reached.\n- **Date Defaults**: If the agent chooses to search memory, providing specific start/end dates is recommended to keep context windows efficient. Omitting dates will search all available history.\n\n## Verification\n\nCheck that the plugin is working and securely connected:\n\n```bash\n# Verify plugin is securely connected to the API\nopenclaw memori status --check\n\n# Check for Memori logs in gateway output\nopenclaw gateway logs --filter \"[Memori]\"\n```\n\n## Quota Management\n\nCheck your current API quota:\n\n```bash\nmemori quota\n```\n\n**Example output:**\n\n```\n __  __                           _\n|  \\/  | ___ _ __ ___   ___  _ __(_)\n| |\\/| |/ _ \\ '_ ` _ \\ / _ \\| '__| |\n| |  | |  __/ | | | | | (_) | |  | |\n|_|  |_|\\___|_| |_| |_|\\___/|_|  |_|\n                  perfectam memoriam\n                       memorilabs.ai\n\n+ Maximum # of Memories: 100\n+ Current # of Memories: 0\n\n+ You are not currently over quota.\n```\n\nUse this to monitor usage and upgrade if needed.\n\n## Performance\n\n- **Automatic deduplication** prevents memory bloat\n- **Agent-controlled retrieval** ensures token usage remains targeted, compact, and actionable\n- **Semantic ranking** ensures relevant memories surface first\n\n## Privacy, Consent & Data Handling\n\n**Explicit Opt-In Required:** Memori requires the user to explicitly configure an API key (`MEMORI_API_KEY`) and an `entityId`. **No data is captured or transmitted unless these credentials are actively provided by the user.**\n\n- ✅ Conversations are securely transmitted to the Memori backend (`https://api.memorilabs.ai`) only when the plugin is fully configured by the user.\n- ✅ Data is encrypted in transit and at rest.\n- ✅ Users control their data scope via their specific `projectId` and `entityId`.\n- ✅ The backend automatically filters sensitive data (API keys, passwords, secrets) prior to storage.\n\nFor details: [Memori Privacy Policy](https://memorilabs.ai/privacy)\n\n## Memory Persistence\n\nMemories persist safely across:\n\n- Session restarts\n- Gateway restarts\n- System reboots\n- OpenClaw upgrades\n\nAll storage is handled by the Memori backend and is scoped safely alongside your local `MEMORY.md` file without overwriting it.\n\n## Troubleshooting\n\n**Plugin not loading:**\n\n- Verify `enabled: true` in openclaw.json\n- Check API key: `echo $MEMORI_API_KEY`\n- Restart gateway: `openclaw gateway restart`\n\n**No memories captured:**\n\n- Check gateway logs for `[Memori]` errors\n- Verify API endpoint reachable\n- Test API key: `memori quota`\n\n**Memories not recalled:**\n\n- Did the agent utilize the retrieval tool? Check your gateway logs for `memori_recall` tool execution. If it didn't use the tool, you can prompt it to search its memory.\n- Ensure `entityId` and `projectId` are consistent across sessions.\n- Verify memories exist: `memori quota` shows count > 0.\n\n**Quota exceeded:**\n\n- Run `memori quota` to check usage\n- Upgrade at [memorilabs.ai](https://app.memorilabs.ai/)\n- Or clear old memories via dashboard\n\n## Learn More\n\n- **npm Package**: https://www.npmjs.com/package/@memorilabs/openclaw-memori\n- **GitHub**: https://github.com/MemoriLabs/Memori\n- **Documentation**: https://memorilabs.ai/docs/memori-cloud/openclaw/overview/\n- **API Dashboard**: https://app.memorilabs.ai/\n- **Support**: [GitHub Issues](https://github.com/MemoriLabs/Memori/issues)\n\n## Notes\n\nThis skill informs the agent about the Memori plugin. The plugin must be installed separately via npm. Once installed, memory capture happens in the background, and the agent is empowered to explicitly query its memories when needed.\n","integrations/claude-code/SKILL.md":"---\nname: memori\ndescription: >\n  Ambient Memori long-term memory for Claude Code via local Bash. MUST TRIGGER\n  on essentially every non-trivial user turn: run recall before drafting any\n  substantive response, whether or not the user mentioned memory, a prior\n  session, or past work. The default is to check memory first; do not wait to\n  be asked. Always fire before external lookups (WebSearch/WebFetch) and\n  before answering any question about preferences, prior decisions,\n  constraints, project history, status, past work, or any non-trivial\n  coding/research task. Skip only for trivial acknowledgements/closings,\n  purely self-contained turns where prior context cannot possibly help, or\n  when the user explicitly opts out. Use Advanced Augmentation after drafting\n  the final response for every non-trivial turn, as the last memory step. Use\n  recall.summary only for broad session summaries/orientation, compaction\n  after context loss, feedback for memory quality, quota for limits, and\n  signup only when explicitly requested.\nargument-hint: '<command> [--flags ...]'\nallowed-tools: Bash\n---\n\n# Memori Claude Code Skill\n\nThin CLI wrapper around Memori Cloud for Claude Code subprocesses. Memori is an\nambient memory enhancement, not an explicit destination tool. Do not wait for\nthe user to ask to \"use Memori\" before applying the memory lifecycle below.\nClaude Code's primary job remains answering the user, editing code, debugging,\nreviewing, and completing the requested work.\n\nRun commands from the Claude Code integration root:\n\n```bash\nbun .claude/skills/memori/index.ts <command> [--flags ...]\n```\n\nFlags accept `--flag value` or `--flag=value`.\n\n## Setup\n\nConfigure credentials in `.claude/settings.local.json` (per-project, not\nchecked into source control). Claude Code injects everything under `env`\ninto every Bash subprocess, including this skill:\n\n```json\n{\n  \"env\": {\n    \"MEMORI_API_KEY\": \"your_memori_api_key\",\n    \"MEMORI_ENTITY_ID\": \"stable_identifier_for_this_user\"\n  }\n}\n```\n\nRequired:\n\n- `MEMORI_API_KEY` — Memori Cloud API key.\n- `MEMORI_ENTITY_ID` — any stable string that namespaces memory for this\n  user/agent. If it is missing on the first command, pick a sensible default\n  yourself (the machine hostname, or a generated UUID), write it to `.claude/settings.local.json` so it persists,\n  and continue. If no sensible default can be inferred, ask the user.\n\nAuto-resolved (no setup required, override with flags or env if needed):\n\n- `MEMORI_PROJECT_ID` — defaults to `basename($CLAUDE_PROJECT_DIR)`, the\n  Claude Code workspace folder name. Override per call with `--projectId`,\n  or pin it by adding `MEMORI_PROJECT_ID` to the `env` block.\n- `MEMORI_SESSION_ID` — defaults to `$CLAUDE_CODE_SESSION_ID` for writes\n  (`advanced-augmentation`) and for `compaction` (which by definition\n  restores the current session). **Reads (`recall`, `recall.summary`) do\n  not auto-apply session_id** — it is a narrowing filter on the agent\n  recall API, so the default keeps retrieval project-scoped across new\n  Claude Code sessions and `/clear`. Pass `--sessionId` explicitly when\n  you want a single-session recall.\n\nOptional:\n\n- `MEMORI_PROCESS_ID` — process attribution for `advanced-augmentation`.\n\nA colocated `.env` file next to `index.ts` is loaded as a fallback when\n`settings.local.json` is not used.\n\n## Commands\n\n```bash\nbun .claude/skills/memori/index.ts recall [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO] [--source SOURCE --signal SIGNAL]\nbun .claude/skills/memori/index.ts recall.summary [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO]\nbun .claude/skills/memori/index.ts advanced-augmentation --userMessage \"$USER_MESSAGE\" --assistantMessage \"$ASSISTANT_MESSAGE\" [--sessionId ID] [--projectId ID] [--model MODEL] [--summary \"$SUMMARY\"] [--trace \"$TRACE_JSON\"] [--processId ID]\nbun .claude/skills/memori/index.ts compaction [--projectId ID] [--sessionId ID] [--numMessages 5]\nbun .claude/skills/memori/index.ts feedback --content \"feedback text\"\nbun .claude/skills/memori/index.ts quota\nbun .claude/skills/memori/index.ts signup --email \"user@example.com\"\n```\n\n## Procedure\n\n1. Run `recall` before drafting any substantive response. This is the default\n   for every non-trivial user turn — including general coding tasks,\n   debugging, code review, and research — not just memory-question turns. Do\n   not wait for the user to mention a previous session, past work, or memory;\n   the default is to check memory first.\n2. Always run `recall` before any external information lookup (WebSearch,\n   WebFetch, or any other tool that fetches facts from outside the repo). The\n   user may have prior context on the topic stored in Memori, and memory must\n   be consulted before going external. This is mandatory.\n3. Use `recall.summary` only for broad summary cases: session orientation,\n   daily briefs, broad status, or reorientation after a long gap. Do not use\n   it for specific user queries.\n4. Use `compaction` only after context compaction or lost working context.\n5. Answer or complete the user's actual request. Memory should improve\n   context, not replace the answer.\n6. After drafting the final response for a non-trivial turn, run\n   `advanced-augmentation` with that final response. This is mandatory\n   ambient bookkeeping and must be the last memory step of the turn.\n7. Use `feedback`, `quota`, and `signup` only when the user request or a\n   Memori error makes them relevant.\n\nSkip the memory lifecycle only for trivial acknowledgements/closings, purely\nself-contained turns where prior context cannot help, or when the user\nexplicitly asks not to remember/store the turn.\n\n## Recall\n\n`recall` is targeted retrieval. The endpoint does not support `query`; never\npass `--query`. Use filters, especially source/signal.\n\nFor prompts like \"what did we discuss last session about X?\", run `recall`\nbefore answering even though the topic text cannot be passed as `--query`. Use\nthe closest source/signal category and then answer from the returned memories.\n\nSource and signal must be provided together:\n\n| Use case | Flags |\n|---|---|\n| Fact or preference | `--source fact --signal verification` |\n| Prior decision | `--source decision --signal commit` |\n| Constraint or requirement | `--source constraint --signal discovery` |\n| Standing instruction | `--source instruction --signal discovery` |\n| Status or progress | `--source status --signal update` |\n| Completed task/result | `--source task --signal result` |\n| Failure or error | `--source execution --signal failure` |\n| Strategy or pattern | `--source strategy --signal pattern` |\n| Inferred lesson | `--source insight --signal inference` |\n\n## Advanced Augmentation\n\nRun after drafting the final assistant response for every non-trivial turn:\n\n```bash\nbun .claude/skills/memori/index.ts advanced-augmentation \\\n  --userMessage \"$USER_MESSAGE\" \\\n  --assistantMessage \"$ASSISTANT_MESSAGE\" \\\n  --trace \"$TRACE_JSON\"\n```\n\n`--sessionId` defaults to `$CLAUDE_CODE_SESSION_ID`; pass it explicitly only\nwhen correlating with a session other than the current Claude Code one.\n\nTrace is JSON shaped like `{ \"tools\": [...] }`. If omitted, the CLI sends\n`{ \"tools\": [] }`. Each tool entry must include:\n\n- `name`: string tool/function name\n- `args`: object of arguments passed to the tool\n- `result`: summarized tool result; the key must be present\n\nValid trace example:\n\n```json\n{\n  \"tools\": [\n    {\n      \"name\": \"ReadFile\",\n      \"args\": { \"path\": \"src/app.ts\" },\n      \"result\": \"Read app entrypoint\"\n    }\n  ]\n}\n```\n\nDo not include secrets, credentials, or large raw logs in trace fields.\n\n## Output And Errors\n\nOn success, commands print JSON to stdout and exit 0. On failure, errors print\nto stderr and exit 1. If memory fails, briefly report the memory issue when\nrelevant and continue with the user's actual request using current context.\n","docs/memori-cloud/mcp/skills/memori-mcp/SKILL.md":"---\nname: memori-mcp-usage\ndescription: Use when an MCP-connected agent should use Memori tools for targeted recall, summaries, post-compaction briefs, durable memory augmentation, quota checks, signup, feedback, preferences, prior context, or cross-session continuity.\nversion: 0.5.0\nauthor: Memori Labs\nlicense: MIT\nmetadata:\n  tags: [Memori, MCP, Memory, Recall, Summary, Compaction, Advanced Augmentation]\n  homepage: https://memorilabs.ai/\n---\n\n# Memori skills file\n\n## Overview\n\nMemori is agent-native memory infrastructure: an LLM-agnostic layer that structures memory from natural language and from agent execution trace.\n\nMemori automatically captures and structures memory from conversation and execution trace, including the agent's actions, tool results, decisions, and outcomes. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so future work is more accurate and efficient.\n\n## Core Instruction\n\nWhen Memori MCP tools are available, treat this skill as the source of truth for how to use Memori through MCP.\n\nUse it to understand:\n\n- Available Memori capabilities\n- Tooling and integrations\n- Expected behavior and constraints\n- Safety and privacy implications\n\nMCP server configuration supplies authenticated user or tenant context through request headers. Do not invent entity, process, project, or session identifiers.\n\nCurrent user instructions, verified local context, and tool results outrank recalled memory.\n\n## Quick Reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue work after context compaction.\n- `memori_advanced_augmentation`: store durable memory from a completed user/assistant turn.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n## When to Use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a meaningful session and need current state\n- You want to understand what has already been done\n\n## When Not to Use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n- The message is trivial, administrative, or closing (for example \"thanks\", \"ok\", \"goodbye\")\n\nAvoid unnecessary recall.\n\n## Recall Behavior\n\nRecall is agent-controlled and intentional. Prefer targeted recall over broad queries.\n\nUse:\n\n- `memori_recall`\n\nSupported parameters:\n\n- `query`: natural language search query\n- `projectId`: project or workspace context, when the tool schema exposes it\n- `sessionId`: specific session, only with `projectId`\n- `dateStart` / `dateEnd`: UTC time-bounded recall\n- `source`: type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal`: how the memory was derived (must be paired with `source` from the allowed combinations below)\n\nIf a `sessionId` is provided, a `projectId` must also be provided. All timestamps are stored in UTC.\n\nPass optional scope fields only when the tool schema exposes them and the active client or workspace provides reliable values.\n\nAllowed source + signal combinations:\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\nDefault behavior:\n\n- No date range means all-time memory.\n\nBest practices:\n\n- Best query: use the latest user message verbatim.\n- Good query: use a short rephrased intent when the message is long or noisy.\n- Avoid generic queries like \"preferences\", \"memory\", or \"context\".\n- Start narrow with project or workspace scope, then expand only if needed.\n- Prefer one recall call per turn.\n- Do not recall on every turn.\n\n## Summary Behavior\n\nSummaries are used for state awareness, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\nSupported parameters:\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\nSummaries do not support `source` or `signal`.\n\nDefault behavior:\n\n- No date range means Memori's summary default, currently the recent working window.\n\n## Daily Brief Behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\nUseful daily brief shape:\n\n- Today at a glance\n- Top next actions\n- Top risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat summaries as working state, not unquestionable truth. If the answer depends on one specific decision, preference, or prior outcome, use `memori_recall` or verify against current sources.\n\n## Post-Compaction Brief Behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\nUse:\n\n- `memori_compaction`\n\nSupported parameters:\n\n- `projectId`: project or workspace context; required when the tool schema requires it\n- `sessionId`: specific session, only with `projectId`\n- `numMessages`: number of recent conversation messages to include\n\nPost-compaction briefs do not support `source` or `signal`.\n\nDefault behavior:\n\n- Retrieve the most recent relevant post-compaction brief for the project or session.\n- Include a small tail of recent conversation messages unless more context is explicitly needed.\n\nExpected post-compaction brief structure:\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n- Messages\n\nTreat the post-compaction brief as the agent's resume state. Use it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\nThe post-compaction brief should guide continuation, not override explicit user instructions. Before acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n## Advanced Augmentation\n\nThrough MCP, durable memory is stored explicitly with `memori_advanced_augmentation` after you draft a response.\n\nUse `memori_advanced_augmentation` only when the turn reveals durable information that would still be useful weeks from now in another conversation.\n\nSupported parameters:\n\n- `user_message`: the user's message for this turn\n- `assistant_response`: the final assistant response for this turn\n- `projectId`: project or workspace scope, when available\n- `sessionId`: session scope, when available\n- `summary`: concise durable summary, when the tool schema supports it\n- `trace`: relevant execution trace, when the tool schema supports it and it is safe to store\n\nGood candidates:\n\n- Explicit preferences: \"always\", \"from now on\", \"default to\", \"I prefer\"\n- Stable profile facts the user wants remembered: role, timezone, location, usual environment, accessibility needs\n- Long-lived project context: tooling, architecture decisions, naming conventions, ownership, deployment constraints\n- Durable workflow norms: review standards, release process, test strategy, formatting conventions\n\n### Do Not Augment\n\nNever store:\n\n- Secrets, API keys, tokens, passwords, credentials, or sensitive personal data\n- Large logs, stack traces, raw tool output, or one-time error dumps\n- Temporary values, codes, links, live prices, schedules, or expiring facts\n- Role-play, hypotheticals, fictional statements, or examples\n- Routine session progress such as tests passed, commands run, files edited, or commit messages\n- Routine task activity such as refactors, imports, renames, or formatting\n- Conversation-scoped choices that are not lasting preferences\n\nIf the user says not to remember, store, save, log, or keep this turn, respect that. You may still recall if needed, but do not augment.\n\nRule of thumb: if the information describes what happened in this session rather than a fact or preference that should shape future sessions, do not augment.\n\n## Procedure\n\n1. If the message is trivial or the user opts out of storage, skip augmentation (and usually recall).\n2. After context compaction: retrieve resume state with `memori_compaction`.\n3. Start of a meaningful session: retrieve a summary with `memori_recall_summary`.\n4. During the task: use targeted `memori_recall` when prior context would materially improve the answer.\n5. Answer using useful recalled context, but verify anything stale, surprising, or high stakes.\n6. After drafting the final response: call `memori_advanced_augmentation` only for durable facts, preferences, or project context.\n7. When memory is missing or incorrect: send `memori_feedback`.\n8. When limits are reached: check `memori_quota` if needed and degrade gracefully.\n\n## Common Pitfalls\n\n- Do not use broad recall when the user needs one specific fact, decision, or prior outcome.\n- Do not treat summaries as authoritative when exact details matter; use targeted recall or verify against current sources.\n- Do not use compaction for targeted memory search or routine turns.\n- Do not call signup, quota, or feedback tools unless the user's request or a Memori error makes them relevant.\n- Do not provide a `sessionId` without also providing a `projectId`.\n- Do not invent entity, process, project, or session identifiers; MCP headers supply attribution context.\n- Do not hide privacy tradeoffs: augmentation may store completed-turn context and safe trace fields when the client provides them.\n- Do not let memory override current user instructions, repository rules, or verified facts from the active workspace.\n\n## Safety and Correctness\n\n- Do not invent memory.\n- Do not assume memory is correct if it conflicts with the user.\n- Verify before acting when needed.\n- Treat current user instructions as higher priority than recalled memory.\n- If a signup, quota, or memory tool fails because the MCP server is unavailable, misconfigured, unauthorized, or missing credentials, explain the setup gap plainly and do not invent memory results.\n\n## Feedback\n\nUse:\n\n- `memori_feedback`\n\nSend feedback when:\n\n- Recall results are irrelevant or missing key context.\n- Important decisions or constraints were not captured.\n- A summary omits important current state.\n- Memory quality degrades across sessions.\n- Something works particularly well and should be reinforced.\n\nKeep feedback concise and specific. Do not send feedback for ordinary task completion.\n\nFeedback improves memory extraction quality, recall relevance, and summary accuracy.\n\n## Account Creation and Onboarding\n\nUse:\n\n- `memori_signup`\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing Memori API key and the user provides their email address.\n\nBehavior:\n\n- If the user asks to sign up but does not provide an email address, ask for their email first.\n- Once they provide an email, run `memori_signup` with that email.\n- Relay the tool result, remind them to check their inbox for the API key, and tell them to configure the Memori MCP server with `X-Memori-API-Key` and `X-Memori-Entity-Id` in their client MCP config.\n- Do not guess or hallucinate an email address.\n\n## Quota Awareness and Upgrades\n\nUse:\n\n- `memori_quota`\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or remaining memory capacity.\n- Errors suggest memory limits have been reached and you want to confirm before degrading behavior.\n\nBehavior:\n\n- Invoke `memori_quota` with no arguments when the tool schema allows it.\n- Relay the result clearly.\n- If limits are near or reached, explain the impact and suggest an upgrade only when performance is affected.\n\nWhen limits are reached or near:\n\n- Reduce recall scope.\n- Prioritize high-signal memory, especially decisions, constraints, key facts, and execution results.\n- Avoid unnecessary or repeated recall calls.\n- Tell the user when limits affect memory behavior.\n\nExample:\n\n> Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\n\n## Updates\n\nMemori may expose improved recall patterns, summaries, classification, or tool behavior over time.\n\nWhen an update is exposed through the system, tool metadata, or user-provided docs:\n\n- Prefer the newer recall or summary behavior when available.\n- Keep this skill's safety, privacy, and intentional-use rules in force.\n- Continue normally if no behavior change is required.\n\n## Verification\n\nConfirm the skill is working in a fresh MCP client session:\n\n1. Verify the Memori MCP server is connected and lists `memori_recall`, `memori_recall_summary`, `memori_compaction`, and `memori_advanced_augmentation`.\n2. Tell the agent a durable preference such as \"I always use tabs over spaces.\"\n3. After augmentation completes, start a later session and ask it to write code.\n\nExpected behavior:\n\n- The agent should use Memori MCP tools rather than answer from generic memory knowledge.\n- The answer should distinguish precise recall from broad state summaries.\n- The answer should mention targeted use, avoiding unnecessary recall, and treating current user instructions as higher priority than memory.\n- If Memori credentials or the MCP server are unavailable, the agent should explain the setup gap without inventing recall results.\n"},"items":[{"name":"SKILL.md","path":"docs/memori-cloud/mcp/skills/memori-mcp/SKILL.md","rawUrl":"https://raw.githubusercontent.com/MemoriLabs/Memori/HEAD/docs/memori-cloud/mcp/skills/memori-mcp/SKILL.md","title":"memori-mcp-usage","category":"anthropic-skill","format":"markdown","content":"---\nname: memori-mcp-usage\ndescription: Use when an MCP-connected agent should use Memori tools for targeted recall, summaries, post-compaction briefs, durable memory augmentation, quota checks, signup, feedback, preferences, prior context, or cross-session continuity.\nversion: 0.5.0\nauthor: Memori Labs\nlicense: MIT\nmetadata:\n  tags: [Memori, MCP, Memory, Recall, Summary, Compaction, Advanced Augmentation]\n  homepage: https://memorilabs.ai/\n---\n\n# Memori skills file\n\n## Overview\n\nMemori is agent-native memory infrastructure: an LLM-agnostic layer that structures memory from natural language and from agent execution trace.\n\nMemori automatically captures and structures memory from conversation and execution trace, including the agent's actions, tool results, decisions, and outcomes. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so future work is more accurate and efficient.\n\n## Core Instruction\n\nWhen Memori MCP tools are available, treat this skill as the source of truth for how to use Memori through MCP.\n\nUse it to understand:\n\n- Available Memori capabilities\n- Tooling and integrations\n- Expected behavior and constraints\n- Safety and privacy implications\n\nMCP server configuration supplies authenticated user or tenant context through request headers. Do not invent entity, process, project, or session identifiers.\n\nCurrent user instructions, verified local context, and tool results outrank recalled memory.\n\n## Quick Reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue work after context compaction.\n- `memori_advanced_augmentation`: store durable memory from a completed user/assistant turn.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n## When to Use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a meaningful session and need current state\n- You want to understand what has already been done\n\n## When Not to Use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n- The message is trivial, administrative, or closing (for example \"thanks\", \"ok\", \"goodbye\")\n\nAvoid unnecessary recall.\n\n## Recall Behavior\n\nRecall is agent-controlled and intentional. Prefer targeted recall over broad queries.\n\nUse:\n\n- `memori_recall`\n\nSupported parameters:\n\n- `query`: natural language search query\n- `projectId`: project or workspace context, when the tool schema exposes it\n- `sessionId`: specific session, only with `projectId`\n- `dateStart` / `dateEnd`: UTC time-bounded recall\n- `source`: type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal`: how the memory was derived (must be paired with `source` from the allowed combinations below)\n\nIf a `sessionId` is provided, a `projectId` must also be provided. All timestamps are stored in UTC.\n\nPass optional scope fields only when the tool schema exposes them and the active client or workspace provides reliable values.\n\nAllowed source + signal combinations:\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\nDefault behavior:\n\n- No date range means all-time memory.\n\nBest practices:\n\n- Best query: use the latest user message verbatim.\n- Good query: use a short rephrased intent when the message is long or noisy.\n- Avoid generic queries like \"preferences\", \"memory\", or \"context\".\n- Start narrow with project or workspace scope, then expand only if needed.\n- Prefer one recall call per turn.\n- Do not recall on every turn.\n\n## Summary Behavior\n\nSummaries are used for state awareness, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\nSupported parameters:\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\nSummaries do not support `source` or `signal`.\n\nDefault behavior:\n\n- No date range means Memori's summary default, currently the recent working window.\n\n## Daily Brief Behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\nUseful daily brief shape:\n\n- Today at a glance\n- Top next actions\n- Top risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat summaries as working state, not unquestionable truth. If the answer depends on one specific decision, preference, or prior outcome, use `memori_recall` or verify against current sources.\n\n## Post-Compaction Brief Behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\nUse:\n\n- `memori_compaction`\n\nSupported parameters:\n\n- `projectId`: project or workspace context; required when the tool schema requires it\n- `sessionId`: specific session, only with `projectId`\n- `numMessages`: number of recent conversation messages to include\n\nPost-compaction briefs do not support `source` or `signal`.\n\nDefault behavior:\n\n- Retrieve the most recent relevant post-compaction brief for the project or session.\n- Include a small tail of recent conversation messages unless more context is explicitly needed.\n\nExpected post-compaction brief structure:\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n- Messages\n\nTreat the post-compaction brief as the agent's resume state. Use it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\nThe post-compaction brief should guide continuation, not override explicit user instructions. Before acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n## Advanced Augmentation\n\nThrough MCP, durable memory is stored explicitly with `memori_advanced_augmentation` after you draft a response.\n\nUse `memori_advanced_augmentation` only when the turn reveals durable information that would still be useful weeks from now in another conversation.\n\nSupported parameters:\n\n- `user_message`: the user's message for this turn\n- `assistant_response`: the final assistant response for this turn\n- `projectId`: project or workspace scope, when available\n- `sessionId`: session scope, when available\n- `summary`: concise durable summary, when the tool schema supports it\n- `trace`: relevant execution trace, when the tool schema supports it and it is safe to store\n\nGood candidates:\n\n- Explicit preferences: \"always\", \"from now on\", \"default to\", \"I prefer\"\n- Stable profile facts the user wants remembered: role, timezone, location, usual environment, accessibility needs\n- Long-lived project context: tooling, architecture decisions, naming conventions, ownership, deployment constraints\n- Durable workflow norms: review standards, release process, test strategy, formatting conventions\n\n### Do Not Augment\n\nNever store:\n\n- Secrets, API keys, tokens, passwords, credentials, or sensitive personal data\n- Large logs, stack traces, raw tool output, or one-time error dumps\n- Temporary values, codes, links, live prices, schedules, or expiring facts\n- Role-play, hypotheticals, fictional statements, or examples\n- Routine session progress such as tests passed, commands run, files edited, or commit messages\n- Routine task activity such as refactors, imports, renames, or formatting\n- Conversation-scoped choices that are not lasting preferences\n\nIf the user says not to remember, store, save, log, or keep this turn, respect that. You may still recall if needed, but do not augment.\n\nRule of thumb: if the information describes what happened in this session rather than a fact or preference that should shape future sessions, do not augment.\n\n## Procedure\n\n1. If the message is trivial or the user opts out of storage, skip augmentation (and usually recall).\n2. After context compaction: retrieve resume state with `memori_compaction`.\n3. Start of a meaningful session: retrieve a summary with `memori_recall_summary`.\n4. During the task: use targeted `memori_recall` when prior context would materially improve the answer.\n5. Answer using useful recalled context, but verify anything stale, surprising, or high stakes.\n6. After drafting the final response: call `memori_advanced_augmentation` only for durable facts, preferences, or project context.\n7. When memory is missing or incorrect: send `memori_feedback`.\n8. When limits are reached: check `memori_quota` if needed and degrade gracefully.\n\n## Common Pitfalls\n\n- Do not use broad recall when the user needs one specific fact, decision, or prior outcome.\n- Do not treat summaries as authoritative when exact details matter; use targeted recall or verify against current sources.\n- Do not use compaction for targeted memory search or routine turns.\n- Do not call signup, quota, or feedback tools unless the user's request or a Memori error makes them relevant.\n- Do not provide a `sessionId` without also providing a `projectId`.\n- Do not invent entity, process, project, or session identifiers; MCP headers supply attribution context.\n- Do not hide privacy tradeoffs: augmentation may store completed-turn context and safe trace fields when the client provides them.\n- Do not let memory override current user instructions, repository rules, or verified facts from the active workspace.\n\n## Safety and Correctness\n\n- Do not invent memory.\n- Do not assume memory is correct if it conflicts with the user.\n- Verify before acting when needed.\n- Treat current user instructions as higher priority than recalled memory.\n- If a signup, quota, or memory tool fails because the MCP server is unavailable, misconfigured, unauthorized, or missing credentials, explain the setup gap plainly and do not invent memory results.\n\n## Feedback\n\nUse:\n\n- `memori_feedback`\n\nSend feedback when:\n\n- Recall results are irrelevant or missing key context.\n- Important decisions or constraints were not captured.\n- A summary omits important current state.\n- Memory quality degrades across sessions.\n- Something works particularly well and should be reinforced.\n\nKeep feedback concise and specific. Do not send feedback for ordinary task completion.\n\nFeedback improves memory extraction quality, recall relevance, and summary accuracy.\n\n## Account Creation and Onboarding\n\nUse:\n\n- `memori_signup`\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing Memori API key and the user provides their email address.\n\nBehavior:\n\n- If the user asks to sign up but does not provide an email address, ask for their email first.\n- Once they provide an email, run `memori_signup` with that email.\n- Relay the tool result, remind them to check their inbox for the API key, and tell them to configure the Memori MCP server with `X-Memori-API-Key` and `X-Memori-Entity-Id` in their client MCP config.\n- Do not guess or hallucinate an email address.\n\n## Quota Awareness and Upgrades\n\nUse:\n\n- `memori_quota`\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or remaining memory capacity.\n- Errors suggest memory limits have been reached and you want to confirm before degrading behavior.\n\nBehavior:\n\n- Invoke `memori_quota` with no arguments when the tool schema allows it.\n- Relay the result clearly.\n- If limits are near or reached, explain the impact and suggest an upgrade only when performance is affected.\n\nWhen limits are reached or near:\n\n- Reduce recall scope.\n- Prioritize high-signal memory, especially decisions, constraints, key facts, and execution results.\n- Avoid unnecessary or repeated recall calls.\n- Tell the user when limits affect memory behavior.\n\nExample:\n\n> Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\n\n## Updates\n\nMemori may expose improved recall patterns, summaries, classification, or tool behavior over time.\n\nWhen an update is exposed through the system, tool metadata, or user-provided docs:\n\n- Prefer the newer recall or summary behavior when available.\n- Keep this skill's safety, privacy, and intentional-use rules in force.\n- Continue normally if no behavior change is required.\n\n## Verification\n\nConfirm the skill is working in a fresh MCP client session:\n\n1. Verify the Memori MCP server is connected and lists `memori_recall`, `memori_recall_summary`, `memori_compaction`, and `memori_advanced_augmentation`.\n2. Tell the agent a durable preference such as \"I always use tabs over spaces.\"\n3. After augmentation completes, start a later session and ask it to write code.\n\nExpected behavior:\n\n- The agent should use Memori MCP tools rather than answer from generic memory knowledge.\n- The answer should distinguish precise recall from broad state summaries.\n- The answer should mention targeted use, avoiding unnecessary recall, and treating current user instructions as higher priority than memory.\n- If Memori credentials or the MCP server are unavailable, the agent should explain the setup gap without inventing recall results.\n","frontmatter":{"name":"memori-mcp-usage","description":"Use when an MCP-connected agent should use Memori tools for targeted recall, summaries, post-compaction briefs, durable memory augmentation, quota checks, signup, feedback, preferences, prior context, or cross-session continuity.","version":"0.5.0","author":"Memori Labs","license":"MIT","metadata":{"tags":["Memori","MCP","Memory","Recall","Summary","Compaction","Advanced Augmentation"],"homepage":"https://memorilabs.ai/"}},"isInternal":false,"tokens":3223,"sizeBytes":15382},{"name":"SKILL.md","path":"integrations/claude-code/SKILL.md","rawUrl":"https://raw.githubusercontent.com/MemoriLabs/Memori/HEAD/integrations/claude-code/SKILL.md","title":"memori","category":"anthropic-skill","format":"markdown","content":"---\nname: memori\ndescription: >\n  Ambient Memori long-term memory for Claude Code via local Bash. MUST TRIGGER\n  on essentially every non-trivial user turn: run recall before drafting any\n  substantive response, whether or not the user mentioned memory, a prior\n  session, or past work. The default is to check memory first; do not wait to\n  be asked. Always fire before external lookups (WebSearch/WebFetch) and\n  before answering any question about preferences, prior decisions,\n  constraints, project history, status, past work, or any non-trivial\n  coding/research task. Skip only for trivial acknowledgements/closings,\n  purely self-contained turns where prior context cannot possibly help, or\n  when the user explicitly opts out. Use Advanced Augmentation after drafting\n  the final response for every non-trivial turn, as the last memory step. Use\n  recall.summary only for broad session summaries/orientation, compaction\n  after context loss, feedback for memory quality, quota for limits, and\n  signup only when explicitly requested.\nargument-hint: '<command> [--flags ...]'\nallowed-tools: Bash\n---\n\n# Memori Claude Code Skill\n\nThin CLI wrapper around Memori Cloud for Claude Code subprocesses. Memori is an\nambient memory enhancement, not an explicit destination tool. Do not wait for\nthe user to ask to \"use Memori\" before applying the memory lifecycle below.\nClaude Code's primary job remains answering the user, editing code, debugging,\nreviewing, and completing the requested work.\n\nRun commands from the Claude Code integration root:\n\n```bash\nbun .claude/skills/memori/index.ts <command> [--flags ...]\n```\n\nFlags accept `--flag value` or `--flag=value`.\n\n## Setup\n\nConfigure credentials in `.claude/settings.local.json` (per-project, not\nchecked into source control). Claude Code injects everything under `env`\ninto every Bash subprocess, including this skill:\n\n```json\n{\n  \"env\": {\n    \"MEMORI_API_KEY\": \"your_memori_api_key\",\n    \"MEMORI_ENTITY_ID\": \"stable_identifier_for_this_user\"\n  }\n}\n```\n\nRequired:\n\n- `MEMORI_API_KEY` — Memori Cloud API key.\n- `MEMORI_ENTITY_ID` — any stable string that namespaces memory for this\n  user/agent. If it is missing on the first command, pick a sensible default\n  yourself (the machine hostname, or a generated UUID), write it to `.claude/settings.local.json` so it persists,\n  and continue. If no sensible default can be inferred, ask the user.\n\nAuto-resolved (no setup required, override with flags or env if needed):\n\n- `MEMORI_PROJECT_ID` — defaults to `basename($CLAUDE_PROJECT_DIR)`, the\n  Claude Code workspace folder name. Override per call with `--projectId`,\n  or pin it by adding `MEMORI_PROJECT_ID` to the `env` block.\n- `MEMORI_SESSION_ID` — defaults to `$CLAUDE_CODE_SESSION_ID` for writes\n  (`advanced-augmentation`) and for `compaction` (which by definition\n  restores the current session). **Reads (`recall`, `recall.summary`) do\n  not auto-apply session_id** — it is a narrowing filter on the agent\n  recall API, so the default keeps retrieval project-scoped across new\n  Claude Code sessions and `/clear`. Pass `--sessionId` explicitly when\n  you want a single-session recall.\n\nOptional:\n\n- `MEMORI_PROCESS_ID` — process attribution for `advanced-augmentation`.\n\nA colocated `.env` file next to `index.ts` is loaded as a fallback when\n`settings.local.json` is not used.\n\n## Commands\n\n```bash\nbun .claude/skills/memori/index.ts recall [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO] [--source SOURCE --signal SIGNAL]\nbun .claude/skills/memori/index.ts recall.summary [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO]\nbun .claude/skills/memori/index.ts advanced-augmentation --userMessage \"$USER_MESSAGE\" --assistantMessage \"$ASSISTANT_MESSAGE\" [--sessionId ID] [--projectId ID] [--model MODEL] [--summary \"$SUMMARY\"] [--trace \"$TRACE_JSON\"] [--processId ID]\nbun .claude/skills/memori/index.ts compaction [--projectId ID] [--sessionId ID] [--numMessages 5]\nbun .claude/skills/memori/index.ts feedback --content \"feedback text\"\nbun .claude/skills/memori/index.ts quota\nbun .claude/skills/memori/index.ts signup --email \"user@example.com\"\n```\n\n## Procedure\n\n1. Run `recall` before drafting any substantive response. This is the default\n   for every non-trivial user turn — including general coding tasks,\n   debugging, code review, and research — not just memory-question turns. Do\n   not wait for the user to mention a previous session, past work, or memory;\n   the default is to check memory first.\n2. Always run `recall` before any external information lookup (WebSearch,\n   WebFetch, or any other tool that fetches facts from outside the repo). The\n   user may have prior context on the topic stored in Memori, and memory must\n   be consulted before going external. This is mandatory.\n3. Use `recall.summary` only for broad summary cases: session orientation,\n   daily briefs, broad status, or reorientation after a long gap. Do not use\n   it for specific user queries.\n4. Use `compaction` only after context compaction or lost working context.\n5. Answer or complete the user's actual request. Memory should improve\n   context, not replace the answer.\n6. After drafting the final response for a non-trivial turn, run\n   `advanced-augmentation` with that final response. This is mandatory\n   ambient bookkeeping and must be the last memory step of the turn.\n7. Use `feedback`, `quota`, and `signup` only when the user request or a\n   Memori error makes them relevant.\n\nSkip the memory lifecycle only for trivial acknowledgements/closings, purely\nself-contained turns where prior context cannot help, or when the user\nexplicitly asks not to remember/store the turn.\n\n## Recall\n\n`recall` is targeted retrieval. The endpoint does not support `query`; never\npass `--query`. Use filters, especially source/signal.\n\nFor prompts like \"what did we discuss last session about X?\", run `recall`\nbefore answering even though the topic text cannot be passed as `--query`. Use\nthe closest source/signal category and then answer from the returned memories.\n\nSource and signal must be provided together:\n\n| Use case | Flags |\n|---|---|\n| Fact or preference | `--source fact --signal verification` |\n| Prior decision | `--source decision --signal commit` |\n| Constraint or requirement | `--source constraint --signal discovery` |\n| Standing instruction | `--source instruction --signal discovery` |\n| Status or progress | `--source status --signal update` |\n| Completed task/result | `--source task --signal result` |\n| Failure or error | `--source execution --signal failure` |\n| Strategy or pattern | `--source strategy --signal pattern` |\n| Inferred lesson | `--source insight --signal inference` |\n\n## Advanced Augmentation\n\nRun after drafting the final assistant response for every non-trivial turn:\n\n```bash\nbun .claude/skills/memori/index.ts advanced-augmentation \\\n  --userMessage \"$USER_MESSAGE\" \\\n  --assistantMessage \"$ASSISTANT_MESSAGE\" \\\n  --trace \"$TRACE_JSON\"\n```\n\n`--sessionId` defaults to `$CLAUDE_CODE_SESSION_ID`; pass it explicitly only\nwhen correlating with a session other than the current Claude Code one.\n\nTrace is JSON shaped like `{ \"tools\": [...] }`. If omitted, the CLI sends\n`{ \"tools\": [] }`. Each tool entry must include:\n\n- `name`: string tool/function name\n- `args`: object of arguments passed to the tool\n- `result`: summarized tool result; the key must be present\n\nValid trace example:\n\n```json\n{\n  \"tools\": [\n    {\n      \"name\": \"ReadFile\",\n      \"args\": { \"path\": \"src/app.ts\" },\n      \"result\": \"Read app entrypoint\"\n    }\n  ]\n}\n```\n\nDo not include secrets, credentials, or large raw logs in trace fields.\n\n## Output And Errors\n\nOn success, commands print JSON to stdout and exit 0. On failure, errors print\nto stderr and exit 1. If memory fails, briefly report the memory issue when\nrelevant and continue with the user's actual request using current context.\n","frontmatter":{"name":"memori","description":"Ambient Memori long-term memory for Claude Code via local Bash. MUST TRIGGER on essentially every non-trivial user turn: run recall before drafting any substantive response, whether or not the user mentioned memory, a prior session, or past work. The default is to check memory first; do not wait to be asked. Always fire before external lookups (WebSearch/WebFetch) and before answering any question about preferences, prior decisions, constraints, project history, status, past work, or any non-trivial coding/research task. Skip only for trivial acknowledgements/closings, purely self-contained turns where prior context cannot possibly help, or when the user explicitly opts out. Use Advanced Augmentation after drafting the final response for every non-trivial turn, as the last memory step. Use recall.summary only for broad session summaries/orientation, compaction after context loss, feedback for memory quality, quota for limits, and signup only when explicitly requested.\n","argument-hint":"<command> [--flags ...]","allowed-tools":"Bash","allowedTools":["Bash"]},"allowedTools":["Bash"],"isInternal":false,"tokens":1868,"sizeBytes":7908},{"name":"SKILL.md","path":"integrations/openclaw/skills/clawhub/SKILL.md","rawUrl":"https://raw.githubusercontent.com/MemoriLabs/Memori/HEAD/integrations/openclaw/skills/clawhub/SKILL.md","title":"memori","category":"anthropic-skill","format":"markdown","content":"---\nname: memori\nid: '@memorilabs/openclaw-memori'\ndescription: Agent-native memory for OpenClaw that structures memory from agent trace, execution history, decisions, tool calls, and conversations into durable long-term memory primitives.\nlicense: Apache-2.0\nhomepage: https://github.com/MemoriLabs/Memori\nrepository: https://github.com/MemoriLabs/Memori.git\ncompatibility:\n  - openclaw\nmetadata:\n  openclaw:\n    requires:\n      env:\n        - MEMORI_API_KEY\n        - ENTITY_ID\n        - PROJECT_ID\n      bins:\n        - memori\n    primaryEnv: MEMORI_API_KEY\n    externalServices:\n      - https://api.memorilabs.ai\n---\n\n# Memori - Structured Long-term Memory for OpenClaw\n\nGive your OpenClaw agents persistent, structured memory derived from agent execution, tool usage, workflow history, and conversations. Memori integrates seamlessly in the background via lifecycle hooks and provides agents with the tools to retrieve context when it is relevant.\n\n## Core Workflow\n\nMemori operates on two parallel tracks through standard OpenClaw lifecycle hooks:\n\n### 1. Advanced Augmentation (automatic)\n\nAfter each interaction, Memori converts raw session data into structured, reusable memories asynchronously.\n\n- Transforms raw agent sessions into structured memory units\n- Captures the agent's actions, reasoning, tool usage, responses, corrections, and failures\n- Organizes into classes to enable efficient retrieval\n- Generates embeddings for semantic retrieval\n- Updates structured memory and the knowledge graph\n\nThis is how structured memory is continuously built and updated over time. It runs after the agent responds and does not impact latency.\n\n### 2. Agent-Controlled-Intelligent Recall\n\nRecall is explicit and initiated by the agent.\n\nMemori separates memory creation from memory recall:\n\n- Creation is automatic (advanced augmentation)\n- Recall is intentional (agent-controlled)\n\nAgents decide:\n\n- When to recall\n- What scope to recall from\n- How much history to include\n\nTo maintain an efficient context window, Memori equips the agent with specific tools to retrieve history when required for the conversation:\n\n1. **`memori_recall`**: Searches the structured memory graph for specific facts, constraints, and prior decisions.\n2. **`memori_recall_summary`**: Retrieves structured daily briefs and rolling summaries of prior sessions.\n3. **`memori_compaction`**: Retrieves structured post-compaction brief to continue task without interruption.\n4. **`memori_feedback`**: Reports on memory quality to improve extraction accuracy.\n\n## Installation\n\n```bash\nopenclaw plugins install @memorilabs/openclaw-memori\n```\n\n## Configuration\n\nAdd to your `~/.openclaw/openclaw.json` or use the `openclaw memori init` CLI command to set up your workspace:\n\n```bash\nopenclaw memori init \\\n  --api-key \"YOUR_MEMORI_API_KEY\" \\\n  --entity-id \"your-entity-id\" \\\n  --project-id \"your-project-id\"\n```\n\nAlternatively, configure it directly via JSON:\n\n```json\n{\n  \"plugins\": {\n    \"entries\": {\n      \"openclaw-memori\": {\n        \"enabled\": true,\n        \"config\": {\n          \"apiKey\": \"${MEMORI_API_KEY}\",\n          \"entityId\": \"openclaw-user\",\n          \"projectId\": \"default-project\"\n        }\n      }\n    }\n  }\n}\n```\n\n### Configuration Options\n\n- **apiKey** (required): Memori API key — acquire with `memori signup`\n- **entityId** (required): Unique identifier for this user's memories\n- **projectId** (required): Scopes all memories to a specific project or workspace\n\n## Agentic Tool Guidelines\n\nWhen this plugin is active, the agent is equipped with tools to manage long-term context. The agent should use its discretion to call these tools when helpful:\n\n- **Contextual Recall**: The agent can run a `memori_recall` search to retrieve relevant details if context is missing regarding user preferences.\n- **Summaries**: The agent can utilize the `memori_recall_summary` tool to construct a brief if a user requests a recap.\n- **Account Creation**: If a user explicitly asks to create an account, the agent can use the `memori_signup` tool to initiate the process by asking for an email address. Keys are never returned in the chat. The system securely emails the credentials to the user, who must then manually configure them to activate the plugin.\n- **Quota Monitoring**: The agent can use the `memori_quota` tool to check the user's current memory usage and storage limits to communicate quota status or gracefully degrade behavior if limits are reached.\n- **Date Defaults**: If the agent chooses to search memory, providing specific start/end dates is recommended to keep context windows efficient. Omitting dates will search all available history.\n\n## Verification\n\nCheck that the plugin is working and securely connected:\n\n```bash\n# Verify plugin is securely connected to the API\nopenclaw memori status --check\n\n# Check for Memori logs in gateway output\nopenclaw gateway logs --filter \"[Memori]\"\n```\n\n## Quota Management\n\nCheck your current API quota:\n\n```bash\nmemori quota\n```\n\n**Example output:**\n\n```\n __  __                           _\n|  \\/  | ___ _ __ ___   ___  _ __(_)\n| |\\/| |/ _ \\ '_ ` _ \\ / _ \\| '__| |\n| |  | |  __/ | | | | | (_) | |  | |\n|_|  |_|\\___|_| |_| |_|\\___/|_|  |_|\n                  perfectam memoriam\n                       memorilabs.ai\n\n+ Maximum # of Memories: 100\n+ Current # of Memories: 0\n\n+ You are not currently over quota.\n```\n\nUse this to monitor usage and upgrade if needed.\n\n## Performance\n\n- **Automatic deduplication** prevents memory bloat\n- **Agent-controlled retrieval** ensures token usage remains targeted, compact, and actionable\n- **Semantic ranking** ensures relevant memories surface first\n\n## Privacy, Consent & Data Handling\n\n**Explicit Opt-In Required:** Memori requires the user to explicitly configure an API key (`MEMORI_API_KEY`) and an `entityId`. **No data is captured or transmitted unless these credentials are actively provided by the user.**\n\n- ✅ Conversations are securely transmitted to the Memori backend (`https://api.memorilabs.ai`) only when the plugin is fully configured by the user.\n- ✅ Data is encrypted in transit and at rest.\n- ✅ Users control their data scope via their specific `projectId` and `entityId`.\n- ✅ The backend automatically filters sensitive data (API keys, passwords, secrets) prior to storage.\n\nFor details: [Memori Privacy Policy](https://memorilabs.ai/privacy)\n\n## Memory Persistence\n\nMemories persist safely across:\n\n- Session restarts\n- Gateway restarts\n- System reboots\n- OpenClaw upgrades\n\nAll storage is handled by the Memori backend and is scoped safely alongside your local `MEMORY.md` file without overwriting it.\n\n## Troubleshooting\n\n**Plugin not loading:**\n\n- Verify `enabled: true` in openclaw.json\n- Check API key: `echo $MEMORI_API_KEY`\n- Restart gateway: `openclaw gateway restart`\n\n**No memories captured:**\n\n- Check gateway logs for `[Memori]` errors\n- Verify API endpoint reachable\n- Test API key: `memori quota`\n\n**Memories not recalled:**\n\n- Did the agent utilize the retrieval tool? Check your gateway logs for `memori_recall` tool execution. If it didn't use the tool, you can prompt it to search its memory.\n- Ensure `entityId` and `projectId` are consistent across sessions.\n- Verify memories exist: `memori quota` shows count > 0.\n\n**Quota exceeded:**\n\n- Run `memori quota` to check usage\n- Upgrade at [memorilabs.ai](https://app.memorilabs.ai/)\n- Or clear old memories via dashboard\n\n## Learn More\n\n- **npm Package**: https://www.npmjs.com/package/@memorilabs/openclaw-memori\n- **GitHub**: https://github.com/MemoriLabs/Memori\n- **Documentation**: https://memorilabs.ai/docs/memori-cloud/openclaw/overview/\n- **API Dashboard**: https://app.memorilabs.ai/\n- **Support**: [GitHub Issues](https://github.com/MemoriLabs/Memori/issues)\n\n## Notes\n\nThis skill informs the agent about the Memori plugin. The plugin must be installed separately via npm. Once installed, memory capture happens in the background, and the agent is empowered to explicitly query its memories when needed.\n","frontmatter":{"name":"memori","id":"@memorilabs/openclaw-memori","description":"Agent-native memory for OpenClaw that structures memory from agent trace, execution history, decisions, tool calls, and conversations into durable long-term memory primitives.","license":"Apache-2.0","homepage":"https://github.com/MemoriLabs/Memori","repository":"https://github.com/MemoriLabs/Memori.git","compatibility":["openclaw"],"metadata":{"openclaw":{"requires":{"env":["MEMORI_API_KEY","ENTITY_ID","PROJECT_ID"],"bins":["memori"]},"primaryEnv":"MEMORI_API_KEY","externalServices":["https://api.memorilabs.ai"]}}},"isInternal":false,"tokens":1845,"sizeBytes":8002},{"name":"SKILL.md","path":"integrations/openclaw/skills/memori/SKILL.md","rawUrl":"https://raw.githubusercontent.com/MemoriLabs/Memori/HEAD/integrations/openclaw/skills/memori/SKILL.md","title":"memori","category":"anthropic-skill","format":"markdown","content":"# Memori skills file\n\nYou have access to Memori, agent-native memory infrastructure: an LLM-agnostic layer that structures memory from not just natural language, but also from agent trace that comes from execution.\n\nMemori automatically captures and structures memory from conversation and execution trace — including the agent's actions, tool results, decisions, and outcomes — and allows you to retrieve it on demand. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so the next time it completes a task, it is more accurate and efficient.\n\n---\n\n## Quick reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue task without interruption.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n---\n\n## Core instruction\n\nAt the start of a session, you should check the `SKILL.md` file\n\nUse it to understand:\n\n- Available capabilities\n- Tooling and integrations\n- Expected behaviors and constraints\n\nTreat `SKILL.md` as a source of truth for what you can do before taking action.\n\n---\n\n## When to use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a session and need current state\n- You want to understand what has already been done\n\n---\n\n## When not to use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n\nAvoid unnecessary recall.\n\n---\n\n## Recall behavior\n\nRecall is **agent-controlled and intentional**.\n\nPrefer targeted recall over broad queries.\n\n### Supported parameters (recall only)\n\n- `entityId` → user, agent, or system context\n- `projectId` → project or workspace context\n- `sessionId` → specific session\n- `dateStart` / `dateEnd` → time-bounded recall\n- `source` → type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal` → how the memory was derived (must be paired with `source` from the allowed combinations below)\n\n> Note: If a `sessionId` is provided, a `projectId` must also be provided.\n> All timestamps are stored in **UTC**.\n\n### Allowed source + signal combinations\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\n### Default behavior (recall)\n\n- No date range → **all-time memory**\n- Use time bounds when narrowing results is necessary\n\n### Best practices\n\n- Start narrow (entity + project)\n- Add time bounds only when needed\n- Use an allowed `(source, signal)` pair to refine results (never set them independently)\n- Expand scope only if needed\n- Do not recall on every turn\n\n---\n\n## Summary behavior\n\nSummaries are used for **state awareness**, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\n### Supported parameters (summaries)\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\n> Summaries do **not** support `source` or `signal`.\n\n### Default behavior (summaries)\n\n- No date range → **last 24 hours**\n\n---\n\n## Daily brief behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\n### Expected daily brief structure\n\n- Today at a glance\n- Top 3 next actions\n- Top 3 risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat this as the working state of the system.\n\n---\n\n## Typical workflow\n\n1. Start of session → retrieve summary\n2. During task → use targeted recall\n3. When memory is missing or incorrect → send feedback\n4. When limits are reached → degrade gracefully\n\n---\n\n## Post-compaction brief behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\n### Use:\n\nmemori_compaction\n\nSupported parameters (post-compaction briefs)\n\nprojectId (required)\nsessionId (optional)\n\nPost-compaction briefs do not support source or signal.\n\n### Default behavior (post-compaction briefs)\n\nRetrieve the most recent relevant post-compaction brief for the project or session.\n\nExpected post-compaction brief structure\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n\n### How to use a post-compaction brief\n\nTreat the post-compaction brief as the agent's resume state.\n\nUse it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\n### Important behavior\n\nThe post-compaction brief should guide continuation, not override explicit user instructions.\n\nBefore acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n---\n\n## Safety and correctness\n\n- Do not invent memory\n- Do not assume memory is correct if it conflicts with the user\n- Verify before acting when needed\n- Treat recent instructions as higher priority than recalled memory\n\n---\n\n## Memori system guidance\n\nThis section defines how you should interact with Memori beyond basic recall.\n\n---\n\n### 1. Feedback (`memori_feedback`)\n\nYou are equipped with the `memori_feedback` tool to improve memory quality over time.\n\nYou may send feedback at any time, and should do so at the end of a session when appropriate.\n\nFeedback should be sent when:\n\n- Recall results are irrelevant or missing key context\n- Important decisions or constraints were not captured\n- Memory quality degrades across sessions\n- Something works particularly well and should be reinforced\n\nExamples:\n\n- \"Send feedback that recall missed a pricing constraint.\"\n- \"Tell Memori the daily brief was accurate.\"\n- \"Submit a bug report: you didn't remember my preferred language.\"\n\n#### Purpose\n\nFeedback improves:\n\n- Memory extraction quality\n- Recall relevance\n- Summary accuracy\n\n---\n\n### 2. Updates\n\nMemori evolves over time (new features, improved recall, better summaries).\n\nWhen updates are exposed:\n\n- Check for updates via system message or tool\n- Adapt behavior to use new capabilities\n\nWhen an update is detected:\n\n- Prefer newer recall patterns when available\n- Use improved summaries or classification outputs\n- Continue operating normally if no changes are required\n\n---\n\n### 3. Account Creation and Onboarding (`memori_signup`)\n\nYou are equipped with the `memori_signup` tool to securely create an account and provision an API key for the user via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing `MEMORI_API_KEY` and the user provides their email address to get one.\n\n#### Behavior:\n\n- **Email Required:** If the user asks to sign up but **does not** provide an email address, you MUST ask them for their email first. Do not attempt to guess or hallucinate an email.\n- **Execution:** Once they provide an email, run `memori_signup` with that email.\n- **Follow-up:** The tool will trigger the underlying CLI and return a success or error message. Relay that message to the user, remind them to check their inbox for the API key, and instruct them to add it to their configuration (`~/.openclaw/openclaw.json` or `.env` file).\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n---\n\n### 4. Quota Awareness and Upgrades (`memori_quota`)\n\nYou are equipped with the `memori_quota` tool to check the user's current memory usage and limits via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or how many memories they have left.\n- You encounter errors suggesting memory limits have been reached and want to confirm before degrading behavior.\n\n#### Behavior:\n\n- **No Parameters Required:** Simply invoke `memori_quota` — it requires no arguments.\n- **Execution:** The tool runs the underlying CLI and returns the user's current usage and quota.\n- **Follow-up:** Relay the result clearly to the user. If they are near or at their limit, explain the impact and suggest an upgrade.\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n#### When limits are reached or nearing:\n\n#### a. Degrade gracefully\n\n- Reduce recall scope (shorter time ranges)\n- Prioritize high-signal memory (decisions, constraints, key facts)\n- Avoid unnecessary or repeated recall calls\n\n#### b. Inform the human/operator\n\nClearly communicate when limits impact performance.\n\nExample:\n\n> \"Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\"\n\n#### c. Suggest upgrades appropriately\n\n- Only prompt when performance is affected\n- Avoid repetitive or disruptive messaging\n- Keep messaging neutral and helpful\n\n---\n","isInternal":false,"tokens":2500,"sizeBytes":11537},{"name":"openclaw.plugin.json","path":"integrations/openclaw/openclaw.plugin.json","rawUrl":"https://raw.githubusercontent.com/MemoriLabs/Memori/HEAD/integrations/openclaw/openclaw.plugin.json","title":"Memori System","category":"plugin-manifest","format":"json","content":"{\n  \"id\": \"openclaw-memori\",\n  \"name\": \"Memori System\",\n  \"version\": \"0.0.13\",\n  \"description\": \"Hosted memory backend\",\n  \"kind\": \"memory\",\n  \"main\": \"dist/index.js\",\n  \"contracts\": {\n    \"tools\": [\n      \"memori_recall\",\n      \"memori_recall_summary\",\n      \"memori_compaction\",\n      \"memori_feedback\",\n      \"memori_signup\",\n      \"memori_quota\"\n    ]\n  },\n  \"uiHints\": {\n    \"apiKey\": {\n      \"label\": \"Memori API Key\",\n      \"sensitive\": true,\n      \"placeholder\": \"Enter your Memori API key...\",\n      \"help\": \"API key from memorilabs.ai (or use MEMORI_API_KEY env var)\"\n    },\n    \"entityId\": {\n      \"label\": \"Entity ID\",\n      \"placeholder\": \"e.g., your-app-user-id\",\n      \"help\": \"Required. The unique identifier to attribute these memories to.\"\n    },\n    \"projectId\": {\n      \"label\": \"Project ID\",\n      \"placeholder\": \"e.g., my-project\",\n      \"help\": \"Required. Scopes all memories to this project.\"\n    }\n  },\n  \"configSchema\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"apiKey\": {\n        \"type\": \"string\",\n        \"title\": \"API Key\",\n        \"description\": \"Memori API Key\"\n      },\n      \"entityId\": {\n        \"type\": \"string\",\n        \"title\": \"Entity ID\",\n        \"description\": \"Required. The unique identifier to attribute these memories to.\"\n      },\n      \"projectId\": {\n        \"type\": \"string\",\n        \"title\": \"Project ID\",\n        \"description\": \"Required. Scopes all memories to this project.\"\n      }\n    },\n    \"required\": []\n  }\n}\n","frontmatter":{"id":"openclaw-memori","name":"Memori System","version":"0.0.13","description":"Hosted memory backend","kind":"memory","main":"dist/index.js","contracts":{"tools":["memori_recall","memori_recall_summary","memori_compaction","memori_feedback","memori_signup","memori_quota"]},"uiHints":{"apiKey":{"label":"Memori API Key","sensitive":true,"placeholder":"Enter your Memori API key...","help":"API key from memorilabs.ai (or use MEMORI_API_KEY env var)"},"entityId":{"label":"Entity ID","placeholder":"e.g., your-app-user-id","help":"Required. The unique identifier to attribute these memories to."},"projectId":{"label":"Project ID","placeholder":"e.g., my-project","help":"Required. Scopes all memories to this project."}},"configSchema":{"type":"object","properties":{"apiKey":{"type":"string","title":"API Key","description":"Memori API Key"},"entityId":{"type":"string","title":"Entity ID","description":"Required. The unique identifier to attribute these memories to."},"projectId":{"type":"string","title":"Project ID","description":"Required. Scopes all memories to this project."}},"required":[]}},"isInternal":false,"tokens":400,"sizeBytes":1475}],"systemPromptSnippet":"<yakaai_skills repo=\"MemoriLabs/Memori\">\n<!-- File: docs/memori-cloud/mcp/skills/memori-mcp/SKILL.md (Tokens: ~3223 | Category: anthropic-skill) -->\n---\nname: memori-mcp-usage\ndescription: Use when an MCP-connected agent should use Memori tools for targeted recall, summaries, post-compaction briefs, durable memory augmentation, quota checks, signup, feedback, preferences, prior context, or cross-session continuity.\nversion: 0.5.0\nauthor: Memori Labs\nlicense: MIT\nmetadata:\n  tags: [Memori, MCP, Memory, Recall, Summary, Compaction, Advanced Augmentation]\n  homepage: https://memorilabs.ai/\n---\n\n# Memori skills file\n\n## Overview\n\nMemori is agent-native memory infrastructure: an LLM-agnostic layer that structures memory from natural language and from agent execution trace.\n\nMemori automatically captures and structures memory from conversation and execution trace, including the agent's actions, tool results, decisions, and outcomes. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so future work is more accurate and efficient.\n\n## Core Instruction\n\nWhen Memori MCP tools are available, treat this skill as the source of truth for how to use Memori through MCP.\n\nUse it to understand:\n\n- Available Memori capabilities\n- Tooling and integrations\n- Expected behavior and constraints\n- Safety and privacy implications\n\nMCP server configuration supplies authenticated user or tenant context through request headers. Do not invent entity, process, project, or session identifiers.\n\nCurrent user instructions, verified local context, and tool results outrank recalled memory.\n\n## Quick Reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue work after context compaction.\n- `memori_advanced_augmentation`: store durable memory from a completed user/assistant turn.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n## When to Use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a meaningful session and need current state\n- You want to understand what has already been done\n\n## When Not to Use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n- The message is trivial, administrative, or closing (for example \"thanks\", \"ok\", \"goodbye\")\n\nAvoid unnecessary recall.\n\n## Recall Behavior\n\nRecall is agent-controlled and intentional. Prefer targeted recall over broad queries.\n\nUse:\n\n- `memori_recall`\n\nSupported parameters:\n\n- `query`: natural language search query\n- `projectId`: project or workspace context, when the tool schema exposes it\n- `sessionId`: specific session, only with `projectId`\n- `dateStart` / `dateEnd`: UTC time-bounded recall\n- `source`: type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal`: how the memory was derived (must be paired with `source` from the allowed combinations below)\n\nIf a `sessionId` is provided, a `projectId` must also be provided. All timestamps are stored in UTC.\n\nPass optional scope fields only when the tool schema exposes them and the active client or workspace provides reliable values.\n\nAllowed source + signal combinations:\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\nDefault behavior:\n\n- No date range means all-time memory.\n\nBest practices:\n\n- Best query: use the latest user message verbatim.\n- Good query: use a short rephrased intent when the message is long or noisy.\n- Avoid generic queries like \"preferences\", \"memory\", or \"context\".\n- Start narrow with project or workspace scope, then expand only if needed.\n- Prefer one recall call per turn.\n- Do not recall on every turn.\n\n## Summary Behavior\n\nSummaries are used for state awareness, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\nSupported parameters:\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\nSummaries do not support `source` or `signal`.\n\nDefault behavior:\n\n- No date range means Memori's summary default, currently the recent working window.\n\n## Daily Brief Behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\nUseful daily brief shape:\n\n- Today at a glance\n- Top next actions\n- Top risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat summaries as working state, not unquestionable truth. If the answer depends on one specific decision, preference, or prior outcome, use `memori_recall` or verify against current sources.\n\n## Post-Compaction Brief Behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\nUse:\n\n- `memori_compaction`\n\nSupported parameters:\n\n- `projectId`: project or workspace context; required when the tool schema requires it\n- `sessionId`: specific session, only with `projectId`\n- `numMessages`: number of recent conversation messages to include\n\nPost-compaction briefs do not support `source` or `signal`.\n\nDefault behavior:\n\n- Retrieve the most recent relevant post-compaction brief for the project or session.\n- Include a small tail of recent conversation messages unless more context is explicitly needed.\n\nExpected post-compaction brief structure:\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n- Messages\n\nTreat the post-compaction brief as the agent's resume state. Use it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\nThe post-compaction brief should guide continuation, not override explicit user instructions. Before acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n## Advanced Augmentation\n\nThrough MCP, durable memory is stored explicitly with `memori_advanced_augmentation` after you draft a response.\n\nUse `memori_advanced_augmentation` only when the turn reveals durable information that would still be useful weeks from now in another conversation.\n\nSupported parameters:\n\n- `user_message`: the user's message for this turn\n- `assistant_response`: the final assistant response for this turn\n- `projectId`: project or workspace scope, when available\n- `sessionId`: session scope, when available\n- `summary`: concise durable summary, when the tool schema supports it\n- `trace`: relevant execution trace, when the tool schema supports it and it is safe to store\n\nGood candidates:\n\n- Explicit preferences: \"always\", \"from now on\", \"default to\", \"I prefer\"\n- Stable profile facts the user wants remembered: role, timezone, location, usual environment, accessibility needs\n- Long-lived project context: tooling, architecture decisions, naming conventions, ownership, deployment constraints\n- Durable workflow norms: review standards, release process, test strategy, formatting conventions\n\n### Do Not Augment\n\nNever store:\n\n- Secrets, API keys, tokens, passwords, credentials, or sensitive personal data\n- Large logs, stack traces, raw tool output, or one-time error dumps\n- Temporary values, codes, links, live prices, schedules, or expiring facts\n- Role-play, hypotheticals, fictional statements, or examples\n- Routine session progress such as tests passed, commands run, files edited, or commit messages\n- Routine task activity such as refactors, imports, renames, or formatting\n- Conversation-scoped choices that are not lasting preferences\n\nIf the user says not to remember, store, save, log, or keep this turn, respect that. You may still recall if needed, but do not augment.\n\nRule of thumb: if the information describes what happened in this session rather than a fact or preference that should shape future sessions, do not augment.\n\n## Procedure\n\n1. If the message is trivial or the user opts out of storage, skip augmentation (and usually recall).\n2. After context compaction: retrieve resume state with `memori_compaction`.\n3. Start of a meaningful session: retrieve a summary with `memori_recall_summary`.\n4. During the task: use targeted `memori_recall` when prior context would materially improve the answer.\n5. Answer using useful recalled context, but verify anything stale, surprising, or high stakes.\n6. After drafting the final response: call `memori_advanced_augmentation` only for durable facts, preferences, or project context.\n7. When memory is missing or incorrect: send `memori_feedback`.\n8. When limits are reached: check `memori_quota` if needed and degrade gracefully.\n\n## Common Pitfalls\n\n- Do not use broad recall when the user needs one specific fact, decision, or prior outcome.\n- Do not treat summaries as authoritative when exact details matter; use targeted recall or verify against current sources.\n- Do not use compaction for targeted memory search or routine turns.\n- Do not call signup, quota, or feedback tools unless the user's request or a Memori error makes them relevant.\n- Do not provide a `sessionId` without also providing a `projectId`.\n- Do not invent entity, process, project, or session identifiers; MCP headers supply attribution context.\n- Do not hide privacy tradeoffs: augmentation may store completed-turn context and safe trace fields when the client provides them.\n- Do not let memory override current user instructions, repository rules, or verified facts from the active workspace.\n\n## Safety and Correctness\n\n- Do not invent memory.\n- Do not assume memory is correct if it conflicts with the user.\n- Verify before acting when needed.\n- Treat current user instructions as higher priority than recalled memory.\n- If a signup, quota, or memory tool fails because the MCP server is unavailable, misconfigured, unauthorized, or missing credentials, explain the setup gap plainly and do not invent memory results.\n\n## Feedback\n\nUse:\n\n- `memori_feedback`\n\nSend feedback when:\n\n- Recall results are irrelevant or missing key context.\n- Important decisions or constraints were not captured.\n- A summary omits important current state.\n- Memory quality degrades across sessions.\n- Something works particularly well and should be reinforced.\n\nKeep feedback concise and specific. Do not send feedback for ordinary task completion.\n\nFeedback improves memory extraction quality, recall relevance, and summary accuracy.\n\n## Account Creation and Onboarding\n\nUse:\n\n- `memori_signup`\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing Memori API key and the user provides their email address.\n\nBehavior:\n\n- If the user asks to sign up but does not provide an email address, ask for their email first.\n- Once they provide an email, run `memori_signup` with that email.\n- Relay the tool result, remind them to check their inbox for the API key, and tell them to configure the Memori MCP server with `X-Memori-API-Key` and `X-Memori-Entity-Id` in their client MCP config.\n- Do not guess or hallucinate an email address.\n\n## Quota Awareness and Upgrades\n\nUse:\n\n- `memori_quota`\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or remaining memory capacity.\n- Errors suggest memory limits have been reached and you want to confirm before degrading behavior.\n\nBehavior:\n\n- Invoke `memori_quota` with no arguments when the tool schema allows it.\n- Relay the result clearly.\n- If limits are near or reached, explain the impact and suggest an upgrade only when performance is affected.\n\nWhen limits are reached or near:\n\n- Reduce recall scope.\n- Prioritize high-signal memory, especially decisions, constraints, key facts, and execution results.\n- Avoid unnecessary or repeated recall calls.\n- Tell the user when limits affect memory behavior.\n\nExample:\n\n> Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\n\n## Updates\n\nMemori may expose improved recall patterns, summaries, classification, or tool behavior over time.\n\nWhen an update is exposed through the system, tool metadata, or user-provided docs:\n\n- Prefer the newer recall or summary behavior when available.\n- Keep this skill's safety, privacy, and intentional-use rules in force.\n- Continue normally if no behavior change is required.\n\n## Verification\n\nConfirm the skill is working in a fresh MCP client session:\n\n1. Verify the Memori MCP server is connected and lists `memori_recall`, `memori_recall_summary`, `memori_compaction`, and `memori_advanced_augmentation`.\n2. Tell the agent a durable preference such as \"I always use tabs over spaces.\"\n3. After augmentation completes, start a later session and ask it to write code.\n\nExpected behavior:\n\n- The agent should use Memori MCP tools rather than answer from generic memory knowledge.\n- The answer should distinguish precise recall from broad state summaries.\n- The answer should mention targeted use, avoiding unnecessary recall, and treating current user instructions as higher priority than memory.\n- If Memori credentials or the MCP server are unavailable, the agent should explain the setup gap without inventing recall results.\n\n<!-- File: integrations/claude-code/SKILL.md (Tokens: ~1868 | Category: anthropic-skill) -->\n---\nname: memori\ndescription: >\n  Ambient Memori long-term memory for Claude Code via local Bash. MUST TRIGGER\n  on essentially every non-trivial user turn: run recall before drafting any\n  substantive response, whether or not the user mentioned memory, a prior\n  session, or past work. The default is to check memory first; do not wait to\n  be asked. Always fire before external lookups (WebSearch/WebFetch) and\n  before answering any question about preferences, prior decisions,\n  constraints, project history, status, past work, or any non-trivial\n  coding/research task. Skip only for trivial acknowledgements/closings,\n  purely self-contained turns where prior context cannot possibly help, or\n  when the user explicitly opts out. Use Advanced Augmentation after drafting\n  the final response for every non-trivial turn, as the last memory step. Use\n  recall.summary only for broad session summaries/orientation, compaction\n  after context loss, feedback for memory quality, quota for limits, and\n  signup only when explicitly requested.\nargument-hint: '<command> [--flags ...]'\nallowed-tools: Bash\n---\n\n# Memori Claude Code Skill\n\nThin CLI wrapper around Memori Cloud for Claude Code subprocesses. Memori is an\nambient memory enhancement, not an explicit destination tool. Do not wait for\nthe user to ask to \"use Memori\" before applying the memory lifecycle below.\nClaude Code's primary job remains answering the user, editing code, debugging,\nreviewing, and completing the requested work.\n\nRun commands from the Claude Code integration root:\n\n```bash\nbun .claude/skills/memori/index.ts <command> [--flags ...]\n```\n\nFlags accept `--flag value` or `--flag=value`.\n\n## Setup\n\nConfigure credentials in `.claude/settings.local.json` (per-project, not\nchecked into source control). Claude Code injects everything under `env`\ninto every Bash subprocess, including this skill:\n\n```json\n{\n  \"env\": {\n    \"MEMORI_API_KEY\": \"your_memori_api_key\",\n    \"MEMORI_ENTITY_ID\": \"stable_identifier_for_this_user\"\n  }\n}\n```\n\nRequired:\n\n- `MEMORI_API_KEY` — Memori Cloud API key.\n- `MEMORI_ENTITY_ID` — any stable string that namespaces memory for this\n  user/agent. If it is missing on the first command, pick a sensible default\n  yourself (the machine hostname, or a generated UUID), write it to `.claude/settings.local.json` so it persists,\n  and continue. If no sensible default can be inferred, ask the user.\n\nAuto-resolved (no setup required, override with flags or env if needed):\n\n- `MEMORI_PROJECT_ID` — defaults to `basename($CLAUDE_PROJECT_DIR)`, the\n  Claude Code workspace folder name. Override per call with `--projectId`,\n  or pin it by adding `MEMORI_PROJECT_ID` to the `env` block.\n- `MEMORI_SESSION_ID` — defaults to `$CLAUDE_CODE_SESSION_ID` for writes\n  (`advanced-augmentation`) and for `compaction` (which by definition\n  restores the current session). **Reads (`recall`, `recall.summary`) do\n  not auto-apply session_id** — it is a narrowing filter on the agent\n  recall API, so the default keeps retrieval project-scoped across new\n  Claude Code sessions and `/clear`. Pass `--sessionId` explicitly when\n  you want a single-session recall.\n\nOptional:\n\n- `MEMORI_PROCESS_ID` — process attribution for `advanced-augmentation`.\n\nA colocated `.env` file next to `index.ts` is loaded as a fallback when\n`settings.local.json` is not used.\n\n## Commands\n\n```bash\nbun .claude/skills/memori/index.ts recall [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO] [--source SOURCE --signal SIGNAL]\nbun .claude/skills/memori/index.ts recall.summary [--projectId ID] [--sessionId ID] [--dateStart ISO] [--dateEnd ISO]\nbun .claude/skills/memori/index.ts advanced-augmentation --userMessage \"$USER_MESSAGE\" --assistantMessage \"$ASSISTANT_MESSAGE\" [--sessionId ID] [--projectId ID] [--model MODEL] [--summary \"$SUMMARY\"] [--trace \"$TRACE_JSON\"] [--processId ID]\nbun .claude/skills/memori/index.ts compaction [--projectId ID] [--sessionId ID] [--numMessages 5]\nbun .claude/skills/memori/index.ts feedback --content \"feedback text\"\nbun .claude/skills/memori/index.ts quota\nbun .claude/skills/memori/index.ts signup --email \"user@example.com\"\n```\n\n## Procedure\n\n1. Run `recall` before drafting any substantive response. This is the default\n   for every non-trivial user turn — including general coding tasks,\n   debugging, code review, and research — not just memory-question turns. Do\n   not wait for the user to mention a previous session, past work, or memory;\n   the default is to check memory first.\n2. Always run `recall` before any external information lookup (WebSearch,\n   WebFetch, or any other tool that fetches facts from outside the repo). The\n   user may have prior context on the topic stored in Memori, and memory must\n   be consulted before going external. This is mandatory.\n3. Use `recall.summary` only for broad summary cases: session orientation,\n   daily briefs, broad status, or reorientation after a long gap. Do not use\n   it for specific user queries.\n4. Use `compaction` only after context compaction or lost working context.\n5. Answer or complete the user's actual request. Memory should improve\n   context, not replace the answer.\n6. After drafting the final response for a non-trivial turn, run\n   `advanced-augmentation` with that final response. This is mandatory\n   ambient bookkeeping and must be the last memory step of the turn.\n7. Use `feedback`, `quota`, and `signup` only when the user request or a\n   Memori error makes them relevant.\n\nSkip the memory lifecycle only for trivial acknowledgements/closings, purely\nself-contained turns where prior context cannot help, or when the user\nexplicitly asks not to remember/store the turn.\n\n## Recall\n\n`recall` is targeted retrieval. The endpoint does not support `query`; never\npass `--query`. Use filters, especially source/signal.\n\nFor prompts like \"what did we discuss last session about X?\", run `recall`\nbefore answering even though the topic text cannot be passed as `--query`. Use\nthe closest source/signal category and then answer from the returned memories.\n\nSource and signal must be provided together:\n\n| Use case | Flags |\n|---|---|\n| Fact or preference | `--source fact --signal verification` |\n| Prior decision | `--source decision --signal commit` |\n| Constraint or requirement | `--source constraint --signal discovery` |\n| Standing instruction | `--source instruction --signal discovery` |\n| Status or progress | `--source status --signal update` |\n| Completed task/result | `--source task --signal result` |\n| Failure or error | `--source execution --signal failure` |\n| Strategy or pattern | `--source strategy --signal pattern` |\n| Inferred lesson | `--source insight --signal inference` |\n\n## Advanced Augmentation\n\nRun after drafting the final assistant response for every non-trivial turn:\n\n```bash\nbun .claude/skills/memori/index.ts advanced-augmentation \\\n  --userMessage \"$USER_MESSAGE\" \\\n  --assistantMessage \"$ASSISTANT_MESSAGE\" \\\n  --trace \"$TRACE_JSON\"\n```\n\n`--sessionId` defaults to `$CLAUDE_CODE_SESSION_ID`; pass it explicitly only\nwhen correlating with a session other than the current Claude Code one.\n\nTrace is JSON shaped like `{ \"tools\": [...] }`. If omitted, the CLI sends\n`{ \"tools\": [] }`. Each tool entry must include:\n\n- `name`: string tool/function name\n- `args`: object of arguments passed to the tool\n- `result`: summarized tool result; the key must be present\n\nValid trace example:\n\n```json\n{\n  \"tools\": [\n    {\n      \"name\": \"ReadFile\",\n      \"args\": { \"path\": \"src/app.ts\" },\n      \"result\": \"Read app entrypoint\"\n    }\n  ]\n}\n```\n\nDo not include secrets, credentials, or large raw logs in trace fields.\n\n## Output And Errors\n\nOn success, commands print JSON to stdout and exit 0. On failure, errors print\nto stderr and exit 1. If memory fails, briefly report the memory issue when\nrelevant and continue with the user's actual request using current context.\n\n<!-- File: integrations/openclaw/skills/clawhub/SKILL.md (Tokens: ~1845 | Category: anthropic-skill) -->\n---\nname: memori\nid: '@memorilabs/openclaw-memori'\ndescription: Agent-native memory for OpenClaw that structures memory from agent trace, execution history, decisions, tool calls, and conversations into durable long-term memory primitives.\nlicense: Apache-2.0\nhomepage: https://github.com/MemoriLabs/Memori\nrepository: https://github.com/MemoriLabs/Memori.git\ncompatibility:\n  - openclaw\nmetadata:\n  openclaw:\n    requires:\n      env:\n        - MEMORI_API_KEY\n        - ENTITY_ID\n        - PROJECT_ID\n      bins:\n        - memori\n    primaryEnv: MEMORI_API_KEY\n    externalServices:\n      - https://api.memorilabs.ai\n---\n\n# Memori - Structured Long-term Memory for OpenClaw\n\nGive your OpenClaw agents persistent, structured memory derived from agent execution, tool usage, workflow history, and conversations. Memori integrates seamlessly in the background via lifecycle hooks and provides agents with the tools to retrieve context when it is relevant.\n\n## Core Workflow\n\nMemori operates on two parallel tracks through standard OpenClaw lifecycle hooks:\n\n### 1. Advanced Augmentation (automatic)\n\nAfter each interaction, Memori converts raw session data into structured, reusable memories asynchronously.\n\n- Transforms raw agent sessions into structured memory units\n- Captures the agent's actions, reasoning, tool usage, responses, corrections, and failures\n- Organizes into classes to enable efficient retrieval\n- Generates embeddings for semantic retrieval\n- Updates structured memory and the knowledge graph\n\nThis is how structured memory is continuously built and updated over time. It runs after the agent responds and does not impact latency.\n\n### 2. Agent-Controlled-Intelligent Recall\n\nRecall is explicit and initiated by the agent.\n\nMemori separates memory creation from memory recall:\n\n- Creation is automatic (advanced augmentation)\n- Recall is intentional (agent-controlled)\n\nAgents decide:\n\n- When to recall\n- What scope to recall from\n- How much history to include\n\nTo maintain an efficient context window, Memori equips the agent with specific tools to retrieve history when required for the conversation:\n\n1. **`memori_recall`**: Searches the structured memory graph for specific facts, constraints, and prior decisions.\n2. **`memori_recall_summary`**: Retrieves structured daily briefs and rolling summaries of prior sessions.\n3. **`memori_compaction`**: Retrieves structured post-compaction brief to continue task without interruption.\n4. **`memori_feedback`**: Reports on memory quality to improve extraction accuracy.\n\n## Installation\n\n```bash\nopenclaw plugins install @memorilabs/openclaw-memori\n```\n\n## Configuration\n\nAdd to your `~/.openclaw/openclaw.json` or use the `openclaw memori init` CLI command to set up your workspace:\n\n```bash\nopenclaw memori init \\\n  --api-key \"YOUR_MEMORI_API_KEY\" \\\n  --entity-id \"your-entity-id\" \\\n  --project-id \"your-project-id\"\n```\n\nAlternatively, configure it directly via JSON:\n\n```json\n{\n  \"plugins\": {\n    \"entries\": {\n      \"openclaw-memori\": {\n        \"enabled\": true,\n        \"config\": {\n          \"apiKey\": \"${MEMORI_API_KEY}\",\n          \"entityId\": \"openclaw-user\",\n          \"projectId\": \"default-project\"\n        }\n      }\n    }\n  }\n}\n```\n\n### Configuration Options\n\n- **apiKey** (required): Memori API key — acquire with `memori signup`\n- **entityId** (required): Unique identifier for this user's memories\n- **projectId** (required): Scopes all memories to a specific project or workspace\n\n## Agentic Tool Guidelines\n\nWhen this plugin is active, the agent is equipped with tools to manage long-term context. The agent should use its discretion to call these tools when helpful:\n\n- **Contextual Recall**: The agent can run a `memori_recall` search to retrieve relevant details if context is missing regarding user preferences.\n- **Summaries**: The agent can utilize the `memori_recall_summary` tool to construct a brief if a user requests a recap.\n- **Account Creation**: If a user explicitly asks to create an account, the agent can use the `memori_signup` tool to initiate the process by asking for an email address. Keys are never returned in the chat. The system securely emails the credentials to the user, who must then manually configure them to activate the plugin.\n- **Quota Monitoring**: The agent can use the `memori_quota` tool to check the user's current memory usage and storage limits to communicate quota status or gracefully degrade behavior if limits are reached.\n- **Date Defaults**: If the agent chooses to search memory, providing specific start/end dates is recommended to keep context windows efficient. Omitting dates will search all available history.\n\n## Verification\n\nCheck that the plugin is working and securely connected:\n\n```bash\n# Verify plugin is securely connected to the API\nopenclaw memori status --check\n\n# Check for Memori logs in gateway output\nopenclaw gateway logs --filter \"[Memori]\"\n```\n\n## Quota Management\n\nCheck your current API quota:\n\n```bash\nmemori quota\n```\n\n**Example output:**\n\n```\n __  __                           _\n|  \\/  | ___ _ __ ___   ___  _ __(_)\n| |\\/| |/ _ \\ '_ ` _ \\ / _ \\| '__| |\n| |  | |  __/ | | | | | (_) | |  | |\n|_|  |_|\\___|_| |_| |_|\\___/|_|  |_|\n                  perfectam memoriam\n                       memorilabs.ai\n\n+ Maximum # of Memories: 100\n+ Current # of Memories: 0\n\n+ You are not currently over quota.\n```\n\nUse this to monitor usage and upgrade if needed.\n\n## Performance\n\n- **Automatic deduplication** prevents memory bloat\n- **Agent-controlled retrieval** ensures token usage remains targeted, compact, and actionable\n- **Semantic ranking** ensures relevant memories surface first\n\n## Privacy, Consent & Data Handling\n\n**Explicit Opt-In Required:** Memori requires the user to explicitly configure an API key (`MEMORI_API_KEY`) and an `entityId`. **No data is captured or transmitted unless these credentials are actively provided by the user.**\n\n- ✅ Conversations are securely transmitted to the Memori backend (`https://api.memorilabs.ai`) only when the plugin is fully configured by the user.\n- ✅ Data is encrypted in transit and at rest.\n- ✅ Users control their data scope via their specific `projectId` and `entityId`.\n- ✅ The backend automatically filters sensitive data (API keys, passwords, secrets) prior to storage.\n\nFor details: [Memori Privacy Policy](https://memorilabs.ai/privacy)\n\n## Memory Persistence\n\nMemories persist safely across:\n\n- Session restarts\n- Gateway restarts\n- System reboots\n- OpenClaw upgrades\n\nAll storage is handled by the Memori backend and is scoped safely alongside your local `MEMORY.md` file without overwriting it.\n\n## Troubleshooting\n\n**Plugin not loading:**\n\n- Verify `enabled: true` in openclaw.json\n- Check API key: `echo $MEMORI_API_KEY`\n- Restart gateway: `openclaw gateway restart`\n\n**No memories captured:**\n\n- Check gateway logs for `[Memori]` errors\n- Verify API endpoint reachable\n- Test API key: `memori quota`\n\n**Memories not recalled:**\n\n- Did the agent utilize the retrieval tool? Check your gateway logs for `memori_recall` tool execution. If it didn't use the tool, you can prompt it to search its memory.\n- Ensure `entityId` and `projectId` are consistent across sessions.\n- Verify memories exist: `memori quota` shows count > 0.\n\n**Quota exceeded:**\n\n- Run `memori quota` to check usage\n- Upgrade at [memorilabs.ai](https://app.memorilabs.ai/)\n- Or clear old memories via dashboard\n\n## Learn More\n\n- **npm Package**: https://www.npmjs.com/package/@memorilabs/openclaw-memori\n- **GitHub**: https://github.com/MemoriLabs/Memori\n- **Documentation**: https://memorilabs.ai/docs/memori-cloud/openclaw/overview/\n- **API Dashboard**: https://app.memorilabs.ai/\n- **Support**: [GitHub Issues](https://github.com/MemoriLabs/Memori/issues)\n\n## Notes\n\nThis skill informs the agent about the Memori plugin. The plugin must be installed separately via npm. Once installed, memory capture happens in the background, and the agent is empowered to explicitly query its memories when needed.\n\n<!-- File: integrations/openclaw/skills/memori/SKILL.md (Tokens: ~2500 | Category: anthropic-skill) -->\n# Memori skills file\n\nYou have access to Memori, agent-native memory infrastructure: an LLM-agnostic layer that structures memory from not just natural language, but also from agent trace that comes from execution.\n\nMemori automatically captures and structures memory from conversation and execution trace — including the agent's actions, tool results, decisions, and outcomes — and allows you to retrieve it on demand. Use it to maintain continuity across sessions, preserve decisions and constraints, and help the agent understand what it actually did so the next time it completes a task, it is more accurate and efficient.\n\n---\n\n## Quick reference\n\n- `memori_recall`: retrieve precise memories by query, project, session, time range, or an allowed source/signal pair.\n- `memori_recall_summary`: retrieve a state summary for session starts, daily briefs, or broad status checks.\n- `memori_compaction`: retrieve a structured post-compaction brief to continue task without interruption.\n- `memori_feedback`: report irrelevant, missing, stale, or especially useful memory behavior.\n- `memori_signup`: create a Memori account or request an API key when the user explicitly asks.\n- `memori_quota`: check usage, quota, storage, or memory capacity when the user asks or limits appear to be reached.\n\n---\n\n## Core instruction\n\nAt the start of a session, you should check the `SKILL.md` file\n\nUse it to understand:\n\n- Available capabilities\n- Tooling and integrations\n- Expected behaviors and constraints\n\nTreat `SKILL.md` as a source of truth for what you can do before taking action.\n\n---\n\n## When to use Memori\n\nUse Memori when:\n\n- The task depends on prior context\n- The user refers to previous sessions or decisions\n- You need known constraints, preferences, or patterns\n- You are starting a session and need current state\n- You want to understand what has already been done\n\n---\n\n## When not to use Memori\n\nDo not use Memori when:\n\n- The task is fully self-contained\n- The answer depends only on the current prompt\n- No historical context is required\n- The query is simple or one-off\n\nAvoid unnecessary recall.\n\n---\n\n## Recall behavior\n\nRecall is **agent-controlled and intentional**.\n\nPrefer targeted recall over broad queries.\n\n### Supported parameters (recall only)\n\n- `entityId` → user, agent, or system context\n- `projectId` → project or workspace context\n- `sessionId` → specific session\n- `dateStart` / `dateEnd` → time-bounded recall\n- `source` → type of memory (must be paired with `signal` from the allowed combinations below)\n- `signal` → how the memory was derived (must be paired with `source` from the allowed combinations below)\n\n> Note: If a `sessionId` is provided, a `projectId` must also be provided.\n> All timestamps are stored in **UTC**.\n\n### Allowed source + signal combinations\n\n`source` and `signal` are not independent. They must be set together (or both omitted). Only the following `(source, signal)` pairs are valid:\n\n- `source=constraint`, `signal=discovery`\n- `source=decision`, `signal=commit`\n- `source=fact`, `signal=verification`\n- `source=execution`, `signal=failure`\n- `source=instruction`, `signal=discovery`\n- `source=insight`, `signal=inference`\n- `source=status`, `signal=update`\n- `source=strategy`, `signal=pattern`\n- `source=task`, `signal=result`\n\nAny combination of `source` and `signal` not in this list is invalid and must not be sent to `memori_recall`.\n\nUse one of the allowed `(source, signal)` pairs to prioritize high-signal memory when possible; never set `source` or `signal` independently.\n\n### Default behavior (recall)\n\n- No date range → **all-time memory**\n- Use time bounds when narrowing results is necessary\n\n### Best practices\n\n- Start narrow (entity + project)\n- Add time bounds only when needed\n- Use an allowed `(source, signal)` pair to refine results (never set them independently)\n- Expand scope only if needed\n- Do not recall on every turn\n\n---\n\n## Summary behavior\n\nSummaries are used for **state awareness**, not precise retrieval.\n\nUse:\n\n- `memori_recall_summary`\n\n### Supported parameters (summaries)\n\n- `projectId`\n- `sessionId`\n- `dateStart`\n- `dateEnd`\n\n> Summaries do **not** support `source` or `signal`.\n\n### Default behavior (summaries)\n\n- No date range → **last 24 hours**\n\n---\n\n## Daily brief behavior\n\nAt the start of a meaningful session, retrieve a structured summary.\n\nUse the daily brief to understand:\n\n- Current state\n- Prior decisions\n- Constraints\n- Open work\n\n### Expected daily brief structure\n\n- Today at a glance\n- Top 3 next actions\n- Top 3 risks\n- Verify before acting\n- Recent decisions\n- Mission stack\n- Hard constraints\n- Current status\n- Open loops\n- Known failures and anti-patterns\n- Staleness warnings\n\nTreat this as the working state of the system.\n\n---\n\n## Typical workflow\n\n1. Start of session → retrieve summary\n2. During task → use targeted recall\n3. When memory is missing or incorrect → send feedback\n4. When limits are reached → degrade gracefully\n\n---\n\n## Post-compaction brief behavior\n\nPost-compaction briefs are used to restore working state after context compaction.\n\nUse them when:\n\n- The agent resumes after compaction\n- A long-running workflow has lost conversational detail\n- The agent needs to continue operational work without replaying the full prior session\n- The agent needs durable state, standing instructions, environment details, open loops, or the next expected action\n\nPost-compaction briefs are not a replacement for precise memory retrieval.\n\n### Use:\n\nmemori_compaction\n\nSupported parameters (post-compaction briefs)\n\nprojectId (required)\nsessionId (optional)\n\nPost-compaction briefs do not support source or signal.\n\n### Default behavior (post-compaction briefs)\n\nRetrieve the most recent relevant post-compaction brief for the project or session.\n\nExpected post-compaction brief structure\n\n- Meta\n- Environment\n- Standing orders\n- State\n- Active tasks\n- Open loops\n- Pending results\n- Timeline\n- Workspace changes\n- Continuation\n- Last action\n- Next expected action\n\n### How to use a post-compaction brief\n\nTreat the post-compaction brief as the agent's resume state.\n\nUse it to understand:\n\n- What environment the agent was operating in\n- Which standing orders must continue to be followed\n- Which tasks are active\n- Which issues remain unresolved\n- What happened across the prior session window\n- What files, workspace state, or external systems may have changed\n- What the agent did last\n- What the agent should do next\n\n### Important behavior\n\nThe post-compaction brief should guide continuation, not override explicit user instructions.\n\nBefore acting on operational details, verify any state that may have changed since compaction.\n\nPay special attention to:\n\n- Standing orders\n- Hard constraints\n- Alerting rules\n- Expected response formats\n- Open loops\n- Staleness warnings\n- Next expected action\n\nIf the post-compaction brief contains a required output format, follow it exactly unless the user gives a newer instruction.\n\n---\n\n## Safety and correctness\n\n- Do not invent memory\n- Do not assume memory is correct if it conflicts with the user\n- Verify before acting when needed\n- Treat recent instructions as higher priority than recalled memory\n\n---\n\n## Memori system guidance\n\nThis section defines how you should interact with Memori beyond basic recall.\n\n---\n\n### 1. Feedback (`memori_feedback`)\n\nYou are equipped with the `memori_feedback` tool to improve memory quality over time.\n\nYou may send feedback at any time, and should do so at the end of a session when appropriate.\n\nFeedback should be sent when:\n\n- Recall results are irrelevant or missing key context\n- Important decisions or constraints were not captured\n- Memory quality degrades across sessions\n- Something works particularly well and should be reinforced\n\nExamples:\n\n- \"Send feedback that recall missed a pricing constraint.\"\n- \"Tell Memori the daily brief was accurate.\"\n- \"Submit a bug report: you didn't remember my preferred language.\"\n\n#### Purpose\n\nFeedback improves:\n\n- Memory extraction quality\n- Recall relevance\n- Summary accuracy\n\n---\n\n### 2. Updates\n\nMemori evolves over time (new features, improved recall, better summaries).\n\nWhen updates are exposed:\n\n- Check for updates via system message or tool\n- Adapt behavior to use new capabilities\n\nWhen an update is detected:\n\n- Prefer newer recall patterns when available\n- Use improved summaries or classification outputs\n- Continue operating normally if no changes are required\n\n---\n\n### 3. Account Creation and Onboarding (`memori_signup`)\n\nYou are equipped with the `memori_signup` tool to securely create an account and provision an API key for the user via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks to sign up, create an account, or get an API key for Memori.\n- You encounter an error indicating a missing `MEMORI_API_KEY` and the user provides their email address to get one.\n\n#### Behavior:\n\n- **Email Required:** If the user asks to sign up but **does not** provide an email address, you MUST ask them for their email first. Do not attempt to guess or hallucinate an email.\n- **Execution:** Once they provide an email, run `memori_signup` with that email.\n- **Follow-up:** The tool will trigger the underlying CLI and return a success or error message. Relay that message to the user, remind them to check their inbox for the API key, and instruct them to add it to their configuration (`~/.openclaw/openclaw.json` or `.env` file).\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n---\n\n### 4. Quota Awareness and Upgrades (`memori_quota`)\n\nYou are equipped with the `memori_quota` tool to check the user's current memory usage and limits via the Memori CLI.\n\nUse this tool when:\n\n- The user explicitly asks about their quota, usage, storage, or how many memories they have left.\n- You encounter errors suggesting memory limits have been reached and want to confirm before degrading behavior.\n\n#### Behavior:\n\n- **No Parameters Required:** Simply invoke `memori_quota` — it requires no arguments.\n- **Execution:** The tool runs the underlying CLI and returns the user's current usage and quota.\n- **Follow-up:** Relay the result clearly to the user. If they are near or at their limit, explain the impact and suggest an upgrade.\n- **Troubleshooting Errors:** If the tool fails with a `Permission denied`, `EACCES`, or `command not found` error, do not ask the user for permission to troubleshoot. Instead, immediately tell them that their CLI installation is broken or missing, and explicitly instruct them to run `npm install -g @memorilabs/memori` in their terminal to fix it.\n\n#### When limits are reached or nearing:\n\n#### a. Degrade gracefully\n\n- Reduce recall scope (shorter time ranges)\n- Prioritize high-signal memory (decisions, constraints, key facts)\n- Avoid unnecessary or repeated recall calls\n\n#### b. Inform the human/operator\n\nClearly communicate when limits impact performance.\n\nExample:\n\n> \"Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality.\"\n\n#### c. Suggest upgrades appropriately\n\n- Only prompt when performance is affected\n- Avoid repetitive or disruptive messaging\n- Keep messaging neutral and helpful\n\n---\n\n<!-- File: integrations/openclaw/openclaw.plugin.json (Tokens: ~400 | Category: plugin-manifest) -->\n{\n  \"id\": \"openclaw-memori\",\n  \"name\": \"Memori System\",\n  \"version\": \"0.0.13\",\n  \"description\": \"Hosted memory backend\",\n  \"kind\": \"memory\",\n  \"main\": \"dist/index.js\",\n  \"contracts\": {\n    \"tools\": [\n      \"memori_recall\",\n      \"memori_recall_summary\",\n      \"memori_compaction\",\n      \"memori_feedback\",\n      \"memori_signup\",\n      \"memori_quota\"\n    ]\n  },\n  \"uiHints\": {\n    \"apiKey\": {\n      \"label\": \"Memori API Key\",\n      \"sensitive\": true,\n      \"placeholder\": \"Enter your Memori API key...\",\n      \"help\": \"API key from memorilabs.ai (or use MEMORI_API_KEY env var)\"\n    },\n    \"entityId\": {\n      \"label\": \"Entity ID\",\n      \"placeholder\": \"e.g., your-app-user-id\",\n      \"help\": \"Required. The unique identifier to attribute these memories to.\"\n    },\n    \"projectId\": {\n      \"label\": \"Project ID\",\n      \"placeholder\": \"e.g., my-project\",\n      \"help\": \"Required. Scopes all memories to this project.\"\n    }\n  },\n  \"configSchema\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"apiKey\": {\n        \"type\": \"string\",\n        \"title\": \"API Key\",\n        \"description\": \"Memori API Key\"\n      },\n      \"entityId\": {\n        \"type\": \"string\",\n        \"title\": \"Entity ID\",\n        \"description\": \"Required. The unique identifier to attribute these memories to.\"\n      },\n      \"projectId\": {\n        \"type\": \"string\",\n        \"title\": \"Project ID\",\n        \"description\": \"Required. Scopes all memories to this project.\"\n      }\n    },\n    \"required\": []\n  }\n}\n</yakaai_skills>"}