@memorilabs/openclaw-memori 0.0.8 → 0.0.10
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +118 -91
- package/dist/cli/commands.d.ts +2 -0
- package/dist/cli/commands.js +143 -0
- package/dist/cli/config-file.d.ts +8 -0
- package/dist/cli/config-file.js +64 -0
- package/dist/handlers/augmentation.js +12 -5
- package/dist/index.js +10 -3
- package/dist/sanitizer.d.ts +1 -0
- package/dist/sanitizer.js +10 -2
- package/dist/tools/index.d.ts +3 -0
- package/dist/tools/index.js +12 -0
- package/dist/tools/memori-feedback.d.ts +25 -0
- package/dist/tools/memori-feedback.js +40 -0
- package/dist/tools/memori-quota.d.ts +17 -0
- package/dist/tools/memori-quota.js +55 -0
- package/dist/tools/memori-recall-summary.d.ts +39 -0
- package/dist/tools/memori-recall-summary.js +58 -0
- package/dist/tools/memori-recall.d.ts +61 -0
- package/dist/tools/memori-recall.js +99 -0
- package/dist/tools/memori-signup.d.ts +25 -0
- package/dist/tools/memori-signup.js +72 -0
- package/dist/tools/types.d.ts +8 -0
- package/dist/tools/types.js +1 -0
- package/dist/types.d.ts +4 -8
- package/dist/utils/context.d.ts +4 -2
- package/dist/utils/context.js +4 -2
- package/dist/utils/index.d.ts +2 -1
- package/dist/utils/index.js +2 -1
- package/dist/utils/memori-client.d.ts +11 -0
- package/dist/utils/memori-client.js +20 -2
- package/dist/utils/skills-loader.d.ts +6 -0
- package/dist/utils/skills-loader.js +14 -0
- package/dist/version.d.ts +1 -1
- package/dist/version.js +1 -1
- package/openclaw.plugin.json +15 -2
- package/package.json +3 -2
- package/skills/clawhub/SKILL.md +313 -0
- package/skills/memori/SKILL.md +284 -0
- package/dist/handlers/recall.d.ts +0 -5
- package/dist/handlers/recall.js +0 -34
package/openclaw.plugin.json
CHANGED
|
@@ -1,10 +1,13 @@
|
|
|
1
1
|
{
|
|
2
2
|
"id": "openclaw-memori",
|
|
3
3
|
"name": "Memori System",
|
|
4
|
-
"version": "0.0.
|
|
4
|
+
"version": "0.0.10",
|
|
5
5
|
"description": "Hosted memory backend",
|
|
6
6
|
"kind": "memory",
|
|
7
7
|
"main": "dist/index.js",
|
|
8
|
+
"contracts": {
|
|
9
|
+
"tools": ["memori_recall", "memori_recall_summary", "memori_feedback"]
|
|
10
|
+
},
|
|
8
11
|
"uiHints": {
|
|
9
12
|
"apiKey": {
|
|
10
13
|
"label": "Memori API Key",
|
|
@@ -16,6 +19,11 @@
|
|
|
16
19
|
"label": "Entity ID",
|
|
17
20
|
"placeholder": "e.g., your-app-user-id",
|
|
18
21
|
"help": "Required. The unique identifier to attribute these memories to."
|
|
22
|
+
},
|
|
23
|
+
"projectId": {
|
|
24
|
+
"label": "Project ID",
|
|
25
|
+
"placeholder": "e.g., my-project",
|
|
26
|
+
"help": "Required. Scopes all memories to this project."
|
|
19
27
|
}
|
|
20
28
|
},
|
|
21
29
|
"configSchema": {
|
|
@@ -29,7 +37,12 @@
|
|
|
29
37
|
"entityId": {
|
|
30
38
|
"type": "string",
|
|
31
39
|
"title": "Entity ID",
|
|
32
|
-
"description": "Required.
|
|
40
|
+
"description": "Required. The unique identifier to attribute these memories to."
|
|
41
|
+
},
|
|
42
|
+
"projectId": {
|
|
43
|
+
"type": "string",
|
|
44
|
+
"title": "Project ID",
|
|
45
|
+
"description": "Required. Scopes all memories to this project."
|
|
33
46
|
}
|
|
34
47
|
},
|
|
35
48
|
"required": []
|
package/package.json
CHANGED
|
@@ -1,12 +1,13 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@memorilabs/openclaw-memori",
|
|
3
|
-
"version": "0.0.
|
|
3
|
+
"version": "0.0.10",
|
|
4
4
|
"description": "Official MemoriLabs.ai long-term memory plugin for OpenClaw",
|
|
5
5
|
"type": "module",
|
|
6
6
|
"main": "./dist/index.js",
|
|
7
7
|
"types": "./dist/index.d.ts",
|
|
8
8
|
"files": [
|
|
9
9
|
"dist",
|
|
10
|
+
"skills",
|
|
10
11
|
"openclaw.plugin.json"
|
|
11
12
|
],
|
|
12
13
|
"scripts": {
|
|
@@ -66,6 +67,6 @@
|
|
|
66
67
|
"@hono/node-server": "^1.19.10"
|
|
67
68
|
},
|
|
68
69
|
"dependencies": {
|
|
69
|
-
"@memorilabs/memori": "
|
|
70
|
+
"@memorilabs/memori": "0.1.12-beta"
|
|
70
71
|
}
|
|
71
72
|
}
|
|
@@ -0,0 +1,313 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memori
|
|
3
|
+
id: '@memorilabs/openclaw-memori'
|
|
4
|
+
description: Long-term memory for OpenClaw agents using the Memori SDK. Automatically captures conversations and execution trace, and equips the agent with explicit tools to recall context, manage its account, and monitor usage across sessions.
|
|
5
|
+
license: MIT
|
|
6
|
+
compatibility:
|
|
7
|
+
- openclaw
|
|
8
|
+
metadata:
|
|
9
|
+
openclaw:
|
|
10
|
+
requires:
|
|
11
|
+
env:
|
|
12
|
+
- MEMORI_API_KEY
|
|
13
|
+
- ENTITY_ID
|
|
14
|
+
- PROJECT_ID
|
|
15
|
+
bins:
|
|
16
|
+
- memori
|
|
17
|
+
primaryEnv: MEMORI_API_KEY
|
|
18
|
+
externalServices:
|
|
19
|
+
- https://api.memorilabs.ai
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
# Memori skills file
|
|
23
|
+
|
|
24
|
+
You 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.
|
|
25
|
+
|
|
26
|
+
Memori 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.
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Core instruction
|
|
31
|
+
|
|
32
|
+
At the start of a session, you should check the `SKILL.md` file
|
|
33
|
+
|
|
34
|
+
Use it to understand:
|
|
35
|
+
|
|
36
|
+
- Available capabilities
|
|
37
|
+
- Tooling and integrations
|
|
38
|
+
- Expected behaviors and constraints
|
|
39
|
+
|
|
40
|
+
Treat `SKILL.md` as a source of truth for what you can do before taking action.
|
|
41
|
+
|
|
42
|
+
---
|
|
43
|
+
|
|
44
|
+
## When to use Memori
|
|
45
|
+
|
|
46
|
+
Use Memori when:
|
|
47
|
+
|
|
48
|
+
- The task depends on prior context
|
|
49
|
+
- The user refers to previous sessions or decisions
|
|
50
|
+
- You need known constraints, preferences, or patterns
|
|
51
|
+
- You are starting a session and need current state
|
|
52
|
+
- You want to understand what has already been done
|
|
53
|
+
|
|
54
|
+
---
|
|
55
|
+
|
|
56
|
+
## When not to use Memori
|
|
57
|
+
|
|
58
|
+
Do not use Memori when:
|
|
59
|
+
|
|
60
|
+
- The task is fully self-contained
|
|
61
|
+
- The answer depends only on the current prompt
|
|
62
|
+
- No historical context is required
|
|
63
|
+
- The query is simple or one-off
|
|
64
|
+
|
|
65
|
+
Avoid unnecessary recall.
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
## Recall behavior
|
|
70
|
+
|
|
71
|
+
Recall is **agent-controlled and intentional**.
|
|
72
|
+
|
|
73
|
+
Prefer targeted recall over broad queries.
|
|
74
|
+
|
|
75
|
+
### Supported parameters (recall only)
|
|
76
|
+
|
|
77
|
+
- `entityId` → user, agent, or system context
|
|
78
|
+
- `projectId` → project or workspace context
|
|
79
|
+
- `sessionId` → specific session
|
|
80
|
+
- `dateStart` / `dateEnd` → time-bounded recall
|
|
81
|
+
- `source` → type of memory
|
|
82
|
+
- `signal` → how the memory was derived
|
|
83
|
+
|
|
84
|
+
> Note: If a `sessionId` is provided, a `projectId` must also be provided.
|
|
85
|
+
> All timestamps are stored in **UTC**.
|
|
86
|
+
|
|
87
|
+
### Memory filters
|
|
88
|
+
|
|
89
|
+
- `source`:
|
|
90
|
+
- constraint
|
|
91
|
+
- decision
|
|
92
|
+
- execution
|
|
93
|
+
- fact
|
|
94
|
+
- insight
|
|
95
|
+
- instruction
|
|
96
|
+
- status
|
|
97
|
+
- strategy
|
|
98
|
+
- task
|
|
99
|
+
|
|
100
|
+
- `signal`:
|
|
101
|
+
- commit
|
|
102
|
+
- discovery
|
|
103
|
+
- failure
|
|
104
|
+
- inference
|
|
105
|
+
- pattern
|
|
106
|
+
- result
|
|
107
|
+
- update
|
|
108
|
+
- verification
|
|
109
|
+
|
|
110
|
+
Use `source` and `signal` to prioritize high-signal memory when possible.
|
|
111
|
+
|
|
112
|
+
### Default behavior (recall)
|
|
113
|
+
|
|
114
|
+
- No date range → **all-time memory**
|
|
115
|
+
- Use time bounds when narrowing results is necessary
|
|
116
|
+
|
|
117
|
+
### Best practices
|
|
118
|
+
|
|
119
|
+
- Start narrow (entity + project)
|
|
120
|
+
- Add time bounds only when needed
|
|
121
|
+
- Use `source` and `signal` to refine results
|
|
122
|
+
- Expand scope only if needed
|
|
123
|
+
- Do not recall on every turn
|
|
124
|
+
|
|
125
|
+
---
|
|
126
|
+
|
|
127
|
+
## Summary behavior
|
|
128
|
+
|
|
129
|
+
Summaries are used for **state awareness**, not precise retrieval.
|
|
130
|
+
|
|
131
|
+
Use:
|
|
132
|
+
|
|
133
|
+
- `memori_recall_summary`
|
|
134
|
+
|
|
135
|
+
### Supported parameters (summaries)
|
|
136
|
+
|
|
137
|
+
- `projectId`
|
|
138
|
+
- `sessionId`
|
|
139
|
+
- `dateStart`
|
|
140
|
+
- `dateEnd`
|
|
141
|
+
|
|
142
|
+
> Summaries do **not** support `source` or `signal`.
|
|
143
|
+
|
|
144
|
+
### Default behavior (summaries)
|
|
145
|
+
|
|
146
|
+
- No date range → **last 24 hours**
|
|
147
|
+
|
|
148
|
+
---
|
|
149
|
+
|
|
150
|
+
## Daily brief behavior
|
|
151
|
+
|
|
152
|
+
At the start of a meaningful session, retrieve a structured summary.
|
|
153
|
+
|
|
154
|
+
Use the daily brief to understand:
|
|
155
|
+
|
|
156
|
+
- Current state
|
|
157
|
+
- Prior decisions
|
|
158
|
+
- Constraints
|
|
159
|
+
- Open work
|
|
160
|
+
|
|
161
|
+
### Expected daily brief structure
|
|
162
|
+
|
|
163
|
+
- Today at a glance
|
|
164
|
+
- Top 3 next actions
|
|
165
|
+
- Top 3 risks
|
|
166
|
+
- Verify before acting
|
|
167
|
+
- Recent decisions
|
|
168
|
+
- Mission stack
|
|
169
|
+
- Hard constraints
|
|
170
|
+
- Current status
|
|
171
|
+
- Open loops
|
|
172
|
+
- Known failures and anti-patterns
|
|
173
|
+
- Staleness warnings
|
|
174
|
+
|
|
175
|
+
Treat this as the working state of the system.
|
|
176
|
+
|
|
177
|
+
---
|
|
178
|
+
|
|
179
|
+
## Typical workflow
|
|
180
|
+
|
|
181
|
+
1. Start of session → retrieve summary
|
|
182
|
+
2. During task → use targeted recall
|
|
183
|
+
3. When memory is missing or incorrect → send feedback
|
|
184
|
+
4. When limits are reached → degrade gracefully
|
|
185
|
+
|
|
186
|
+
---
|
|
187
|
+
|
|
188
|
+
## Safety and correctness
|
|
189
|
+
|
|
190
|
+
- Do not invent memory
|
|
191
|
+
- Do not assume memory is correct if it conflicts with the user
|
|
192
|
+
- Verify before acting when needed
|
|
193
|
+
- Treat recent instructions as higher priority than recalled memory
|
|
194
|
+
|
|
195
|
+
---
|
|
196
|
+
|
|
197
|
+
## Memori system guidance
|
|
198
|
+
|
|
199
|
+
This section defines how you should interact with Memori beyond basic recall.
|
|
200
|
+
|
|
201
|
+
---
|
|
202
|
+
|
|
203
|
+
### 1. Feedback (`memori_feedback`)
|
|
204
|
+
|
|
205
|
+
You are equipped with the `memori_feedback` tool to improve memory quality over time.
|
|
206
|
+
|
|
207
|
+
You may send feedback at any time, and should do so at the end of a session when appropriate.
|
|
208
|
+
|
|
209
|
+
Feedback should be sent when:
|
|
210
|
+
|
|
211
|
+
- Recall results are irrelevant or missing key context
|
|
212
|
+
- Important decisions or constraints were not captured
|
|
213
|
+
- Memory quality degrades across sessions
|
|
214
|
+
- Something works particularly well and should be reinforced
|
|
215
|
+
|
|
216
|
+
Examples:
|
|
217
|
+
|
|
218
|
+
- "Send feedback that recall missed a pricing constraint."
|
|
219
|
+
- "Tell Memori the daily brief was accurate."
|
|
220
|
+
- "Submit a bug report: you didn't remember my preferred language."
|
|
221
|
+
|
|
222
|
+
#### Purpose
|
|
223
|
+
|
|
224
|
+
Feedback improves:
|
|
225
|
+
|
|
226
|
+
- Memory extraction quality
|
|
227
|
+
- Recall relevance
|
|
228
|
+
- Summary accuracy
|
|
229
|
+
|
|
230
|
+
---
|
|
231
|
+
|
|
232
|
+
### 2. Updates
|
|
233
|
+
|
|
234
|
+
Memori evolves over time (new features, improved recall, better summaries).
|
|
235
|
+
|
|
236
|
+
When updates are exposed:
|
|
237
|
+
|
|
238
|
+
- Check for updates via system message or tool
|
|
239
|
+
- Adapt behavior to use new capabilities
|
|
240
|
+
|
|
241
|
+
When an update is detected:
|
|
242
|
+
|
|
243
|
+
- Prefer newer recall patterns when available
|
|
244
|
+
- Use improved summaries or classification outputs
|
|
245
|
+
- Continue operating normally if no changes are required
|
|
246
|
+
|
|
247
|
+
---
|
|
248
|
+
|
|
249
|
+
### 3. Account Creation and Onboarding (`memori_signup`)
|
|
250
|
+
|
|
251
|
+
You are equipped with the `memori_signup` tool to securely create an account and provision an API key for the user via the Memori CLI.
|
|
252
|
+
|
|
253
|
+
Use this tool when:
|
|
254
|
+
|
|
255
|
+
- The user explicitly asks to sign up, create an account, or get an API key for Memori.
|
|
256
|
+
- You encounter an error indicating a missing `MEMORI_API_KEY` and the user provides their email address to get one.
|
|
257
|
+
|
|
258
|
+
#### Behavior:
|
|
259
|
+
|
|
260
|
+
- **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.
|
|
261
|
+
- **Execution:** Once they provide an email, run `memori_signup` with that email.
|
|
262
|
+
- **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).
|
|
263
|
+
- **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.
|
|
264
|
+
|
|
265
|
+
---
|
|
266
|
+
|
|
267
|
+
### 4. Quota Awareness and Upgrades (`memori_quota`)
|
|
268
|
+
|
|
269
|
+
You are equipped with the `memori_quota` tool to check the user's current memory usage and limits via the Memori CLI.
|
|
270
|
+
|
|
271
|
+
Use this tool when:
|
|
272
|
+
|
|
273
|
+
- The user explicitly asks about their quota, usage, storage, or how many memories they have left.
|
|
274
|
+
- You encounter errors suggesting memory limits have been reached and want to confirm before degrading behavior.
|
|
275
|
+
|
|
276
|
+
#### Behavior:
|
|
277
|
+
|
|
278
|
+
- **No Parameters Required:** Simply invoke `memori_quota` — it requires no arguments.
|
|
279
|
+
- **Execution:** The tool runs the underlying CLI and returns the user's current usage and quota.
|
|
280
|
+
- **Follow-up:** Relay the result clearly to the user. If they are near or at their limit, explain the impact and suggest an upgrade.
|
|
281
|
+
- **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.
|
|
282
|
+
|
|
283
|
+
#### When limits are reached or nearing:
|
|
284
|
+
|
|
285
|
+
#### a. Degrade gracefully
|
|
286
|
+
|
|
287
|
+
- Reduce recall scope (shorter time ranges)
|
|
288
|
+
- Prioritize high-signal memory (decisions, constraints, key facts)
|
|
289
|
+
- Avoid unnecessary or repeated recall calls
|
|
290
|
+
|
|
291
|
+
#### b. Inform the human/operator
|
|
292
|
+
|
|
293
|
+
Clearly communicate when limits impact performance.
|
|
294
|
+
|
|
295
|
+
Example:
|
|
296
|
+
|
|
297
|
+
> "Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality."
|
|
298
|
+
|
|
299
|
+
#### c. Suggest upgrades appropriately
|
|
300
|
+
|
|
301
|
+
- Only prompt when performance is affected
|
|
302
|
+
- Avoid repetitive or disruptive messaging
|
|
303
|
+
- Keep messaging neutral and helpful
|
|
304
|
+
|
|
305
|
+
---
|
|
306
|
+
|
|
307
|
+
## Learn More
|
|
308
|
+
|
|
309
|
+
- **npm Package**: https://www.npmjs.com/package/@memorilabs/openclaw-memori
|
|
310
|
+
- **GitHub**: https://github.com/MemoriLabs/Memori
|
|
311
|
+
- **Documentation**: https://memorilabs.ai/docs/memori-cloud/openclaw/overview/
|
|
312
|
+
- **API Dashboard**: https://app.memorilabs.ai/
|
|
313
|
+
- **Support**: [GitHub Issues](https://github.com/MemoriLabs/Memori/issues)
|
|
@@ -0,0 +1,284 @@
|
|
|
1
|
+
# Memori skills file
|
|
2
|
+
|
|
3
|
+
You 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.
|
|
4
|
+
|
|
5
|
+
Memori 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.
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Core instruction
|
|
10
|
+
|
|
11
|
+
At the start of a session, you should check the `SKILL.md` file
|
|
12
|
+
|
|
13
|
+
Use it to understand:
|
|
14
|
+
|
|
15
|
+
- Available capabilities
|
|
16
|
+
- Tooling and integrations
|
|
17
|
+
- Expected behaviors and constraints
|
|
18
|
+
|
|
19
|
+
Treat `SKILL.md` as a source of truth for what you can do before taking action.
|
|
20
|
+
|
|
21
|
+
---
|
|
22
|
+
|
|
23
|
+
## When to use Memori
|
|
24
|
+
|
|
25
|
+
Use Memori when:
|
|
26
|
+
|
|
27
|
+
- The task depends on prior context
|
|
28
|
+
- The user refers to previous sessions or decisions
|
|
29
|
+
- You need known constraints, preferences, or patterns
|
|
30
|
+
- You are starting a session and need current state
|
|
31
|
+
- You want to understand what has already been done
|
|
32
|
+
|
|
33
|
+
---
|
|
34
|
+
|
|
35
|
+
## When not to use Memori
|
|
36
|
+
|
|
37
|
+
Do not use Memori when:
|
|
38
|
+
|
|
39
|
+
- The task is fully self-contained
|
|
40
|
+
- The answer depends only on the current prompt
|
|
41
|
+
- No historical context is required
|
|
42
|
+
- The query is simple or one-off
|
|
43
|
+
|
|
44
|
+
Avoid unnecessary recall.
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Recall behavior
|
|
49
|
+
|
|
50
|
+
Recall is **agent-controlled and intentional**.
|
|
51
|
+
|
|
52
|
+
Prefer targeted recall over broad queries.
|
|
53
|
+
|
|
54
|
+
### Supported parameters (recall only)
|
|
55
|
+
|
|
56
|
+
- `entityId` → user, agent, or system context
|
|
57
|
+
- `projectId` → project or workspace context
|
|
58
|
+
- `sessionId` → specific session
|
|
59
|
+
- `dateStart` / `dateEnd` → time-bounded recall
|
|
60
|
+
- `source` → type of memory
|
|
61
|
+
- `signal` → how the memory was derived
|
|
62
|
+
|
|
63
|
+
> Note: If a `sessionId` is provided, a `projectId` must also be provided.
|
|
64
|
+
> All timestamps are stored in **UTC**.
|
|
65
|
+
|
|
66
|
+
### Memory filters
|
|
67
|
+
|
|
68
|
+
- `source`:
|
|
69
|
+
- constraint
|
|
70
|
+
- decision
|
|
71
|
+
- execution
|
|
72
|
+
- fact
|
|
73
|
+
- insight
|
|
74
|
+
- instruction
|
|
75
|
+
- status
|
|
76
|
+
- strategy
|
|
77
|
+
- task
|
|
78
|
+
|
|
79
|
+
- `signal`:
|
|
80
|
+
- commit
|
|
81
|
+
- discovery
|
|
82
|
+
- failure
|
|
83
|
+
- inference
|
|
84
|
+
- pattern
|
|
85
|
+
- result
|
|
86
|
+
- update
|
|
87
|
+
- verification
|
|
88
|
+
|
|
89
|
+
Use `source` and `signal` to prioritize high-signal memory when possible.
|
|
90
|
+
|
|
91
|
+
### Default behavior (recall)
|
|
92
|
+
|
|
93
|
+
- No date range → **all-time memory**
|
|
94
|
+
- Use time bounds when narrowing results is necessary
|
|
95
|
+
|
|
96
|
+
### Best practices
|
|
97
|
+
|
|
98
|
+
- Start narrow (entity + project)
|
|
99
|
+
- Add time bounds only when needed
|
|
100
|
+
- Use `source` and `signal` to refine results
|
|
101
|
+
- Expand scope only if needed
|
|
102
|
+
- Do not recall on every turn
|
|
103
|
+
|
|
104
|
+
---
|
|
105
|
+
|
|
106
|
+
## Summary behavior
|
|
107
|
+
|
|
108
|
+
Summaries are used for **state awareness**, not precise retrieval.
|
|
109
|
+
|
|
110
|
+
Use:
|
|
111
|
+
|
|
112
|
+
- `memori_recall_summary`
|
|
113
|
+
|
|
114
|
+
### Supported parameters (summaries)
|
|
115
|
+
|
|
116
|
+
- `projectId`
|
|
117
|
+
- `sessionId`
|
|
118
|
+
- `dateStart`
|
|
119
|
+
- `dateEnd`
|
|
120
|
+
|
|
121
|
+
> Summaries do **not** support `source` or `signal`.
|
|
122
|
+
|
|
123
|
+
### Default behavior (summaries)
|
|
124
|
+
|
|
125
|
+
- No date range → **last 24 hours**
|
|
126
|
+
|
|
127
|
+
---
|
|
128
|
+
|
|
129
|
+
## Daily brief behavior
|
|
130
|
+
|
|
131
|
+
At the start of a meaningful session, retrieve a structured summary.
|
|
132
|
+
|
|
133
|
+
Use the daily brief to understand:
|
|
134
|
+
|
|
135
|
+
- Current state
|
|
136
|
+
- Prior decisions
|
|
137
|
+
- Constraints
|
|
138
|
+
- Open work
|
|
139
|
+
|
|
140
|
+
### Expected daily brief structure
|
|
141
|
+
|
|
142
|
+
- Today at a glance
|
|
143
|
+
- Top 3 next actions
|
|
144
|
+
- Top 3 risks
|
|
145
|
+
- Verify before acting
|
|
146
|
+
- Recent decisions
|
|
147
|
+
- Mission stack
|
|
148
|
+
- Hard constraints
|
|
149
|
+
- Current status
|
|
150
|
+
- Open loops
|
|
151
|
+
- Known failures and anti-patterns
|
|
152
|
+
- Staleness warnings
|
|
153
|
+
|
|
154
|
+
Treat this as the working state of the system.
|
|
155
|
+
|
|
156
|
+
---
|
|
157
|
+
|
|
158
|
+
## Typical workflow
|
|
159
|
+
|
|
160
|
+
1. Start of session → retrieve summary
|
|
161
|
+
2. During task → use targeted recall
|
|
162
|
+
3. When memory is missing or incorrect → send feedback
|
|
163
|
+
4. When limits are reached → degrade gracefully
|
|
164
|
+
|
|
165
|
+
---
|
|
166
|
+
|
|
167
|
+
## Safety and correctness
|
|
168
|
+
|
|
169
|
+
- Do not invent memory
|
|
170
|
+
- Do not assume memory is correct if it conflicts with the user
|
|
171
|
+
- Verify before acting when needed
|
|
172
|
+
- Treat recent instructions as higher priority than recalled memory
|
|
173
|
+
|
|
174
|
+
---
|
|
175
|
+
|
|
176
|
+
## Memori system guidance
|
|
177
|
+
|
|
178
|
+
This section defines how you should interact with Memori beyond basic recall.
|
|
179
|
+
|
|
180
|
+
---
|
|
181
|
+
|
|
182
|
+
### 1. Feedback (`memori_feedback`)
|
|
183
|
+
|
|
184
|
+
You are equipped with the `memori_feedback` tool to improve memory quality over time.
|
|
185
|
+
|
|
186
|
+
You may send feedback at any time, and should do so at the end of a session when appropriate.
|
|
187
|
+
|
|
188
|
+
Feedback should be sent when:
|
|
189
|
+
|
|
190
|
+
- Recall results are irrelevant or missing key context
|
|
191
|
+
- Important decisions or constraints were not captured
|
|
192
|
+
- Memory quality degrades across sessions
|
|
193
|
+
- Something works particularly well and should be reinforced
|
|
194
|
+
|
|
195
|
+
Examples:
|
|
196
|
+
|
|
197
|
+
- "Send feedback that recall missed a pricing constraint."
|
|
198
|
+
- "Tell Memori the daily brief was accurate."
|
|
199
|
+
- "Submit a bug report: you didn't remember my preferred language."
|
|
200
|
+
|
|
201
|
+
#### Purpose
|
|
202
|
+
|
|
203
|
+
Feedback improves:
|
|
204
|
+
|
|
205
|
+
- Memory extraction quality
|
|
206
|
+
- Recall relevance
|
|
207
|
+
- Summary accuracy
|
|
208
|
+
|
|
209
|
+
---
|
|
210
|
+
|
|
211
|
+
### 2. Updates
|
|
212
|
+
|
|
213
|
+
Memori evolves over time (new features, improved recall, better summaries).
|
|
214
|
+
|
|
215
|
+
When updates are exposed:
|
|
216
|
+
|
|
217
|
+
- Check for updates via system message or tool
|
|
218
|
+
- Adapt behavior to use new capabilities
|
|
219
|
+
|
|
220
|
+
When an update is detected:
|
|
221
|
+
|
|
222
|
+
- Prefer newer recall patterns when available
|
|
223
|
+
- Use improved summaries or classification outputs
|
|
224
|
+
- Continue operating normally if no changes are required
|
|
225
|
+
|
|
226
|
+
---
|
|
227
|
+
|
|
228
|
+
### 3. Account Creation and Onboarding (`memori_signup`)
|
|
229
|
+
|
|
230
|
+
You are equipped with the `memori_signup` tool to securely create an account and provision an API key for the user via the Memori CLI.
|
|
231
|
+
|
|
232
|
+
Use this tool when:
|
|
233
|
+
|
|
234
|
+
- The user explicitly asks to sign up, create an account, or get an API key for Memori.
|
|
235
|
+
- You encounter an error indicating a missing `MEMORI_API_KEY` and the user provides their email address to get one.
|
|
236
|
+
|
|
237
|
+
#### Behavior:
|
|
238
|
+
|
|
239
|
+
- **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.
|
|
240
|
+
- **Execution:** Once they provide an email, run `memori_signup` with that email.
|
|
241
|
+
- **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).
|
|
242
|
+
- **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.
|
|
243
|
+
|
|
244
|
+
---
|
|
245
|
+
|
|
246
|
+
### 4. Quota Awareness and Upgrades (`memori_quota`)
|
|
247
|
+
|
|
248
|
+
You are equipped with the `memori_quota` tool to check the user's current memory usage and limits via the Memori CLI.
|
|
249
|
+
|
|
250
|
+
Use this tool when:
|
|
251
|
+
|
|
252
|
+
- The user explicitly asks about their quota, usage, storage, or how many memories they have left.
|
|
253
|
+
- You encounter errors suggesting memory limits have been reached and want to confirm before degrading behavior.
|
|
254
|
+
|
|
255
|
+
#### Behavior:
|
|
256
|
+
|
|
257
|
+
- **No Parameters Required:** Simply invoke `memori_quota` — it requires no arguments.
|
|
258
|
+
- **Execution:** The tool runs the underlying CLI and returns the user's current usage and quota.
|
|
259
|
+
- **Follow-up:** Relay the result clearly to the user. If they are near or at their limit, explain the impact and suggest an upgrade.
|
|
260
|
+
- **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.
|
|
261
|
+
|
|
262
|
+
#### When limits are reached or nearing:
|
|
263
|
+
|
|
264
|
+
#### a. Degrade gracefully
|
|
265
|
+
|
|
266
|
+
- Reduce recall scope (shorter time ranges)
|
|
267
|
+
- Prioritize high-signal memory (decisions, constraints, key facts)
|
|
268
|
+
- Avoid unnecessary or repeated recall calls
|
|
269
|
+
|
|
270
|
+
#### b. Inform the human/operator
|
|
271
|
+
|
|
272
|
+
Clearly communicate when limits impact performance.
|
|
273
|
+
|
|
274
|
+
Example:
|
|
275
|
+
|
|
276
|
+
> "Memory limits have been reached. I can continue with limited recall, or you can upgrade to restore full functionality."
|
|
277
|
+
|
|
278
|
+
#### c. Suggest upgrades appropriately
|
|
279
|
+
|
|
280
|
+
- Only prompt when performance is affected
|
|
281
|
+
- Avoid repetitive or disruptive messaging
|
|
282
|
+
- Keep messaging neutral and helpful
|
|
283
|
+
|
|
284
|
+
---
|
|
@@ -1,5 +0,0 @@
|
|
|
1
|
-
import { OpenClawEvent, OpenClawContext, MemoriPluginConfig } from '../types.js';
|
|
2
|
-
import { MemoriLogger } from '../utils/index.js';
|
|
3
|
-
export declare function handleRecall(event: OpenClawEvent, ctx: OpenClawContext, config: MemoriPluginConfig, logger: MemoriLogger): Promise<{
|
|
4
|
-
prependContext: string;
|
|
5
|
-
} | undefined>;
|
package/dist/handlers/recall.js
DELETED
|
@@ -1,34 +0,0 @@
|
|
|
1
|
-
import { cleanText, isSystemMessage } from '../sanitizer.js';
|
|
2
|
-
import { RECALL_CONFIG } from '../constants.js';
|
|
3
|
-
import { extractContext, initializeMemoriClient } from '../utils/index.js';
|
|
4
|
-
export async function handleRecall(event, ctx, config, logger) {
|
|
5
|
-
logger.section('RECALL HOOK START');
|
|
6
|
-
try {
|
|
7
|
-
const context = extractContext(event, ctx, config.entityId);
|
|
8
|
-
const promptText = cleanText(event.prompt);
|
|
9
|
-
if (!promptText ||
|
|
10
|
-
promptText.length < RECALL_CONFIG.MIN_PROMPT_LENGTH ||
|
|
11
|
-
isSystemMessage(promptText)) {
|
|
12
|
-
logger.info('Prompt too short or is a system message. Aborting recall.');
|
|
13
|
-
return undefined;
|
|
14
|
-
}
|
|
15
|
-
const memoriClient = initializeMemoriClient(config.apiKey, context);
|
|
16
|
-
logger.info('Executing SDK Recall...');
|
|
17
|
-
const recallText = await memoriClient.recall(promptText);
|
|
18
|
-
const hookReturn = recallText ? { prependContext: recallText } : undefined;
|
|
19
|
-
if (hookReturn) {
|
|
20
|
-
logger.info('Successfully injected memory context.');
|
|
21
|
-
}
|
|
22
|
-
else {
|
|
23
|
-
logger.info('No relevant memories found.');
|
|
24
|
-
}
|
|
25
|
-
return hookReturn;
|
|
26
|
-
}
|
|
27
|
-
catch (err) {
|
|
28
|
-
logger.error(`Recall failed: ${err instanceof Error ? err.message : String(err)}`);
|
|
29
|
-
return undefined;
|
|
30
|
-
}
|
|
31
|
-
finally {
|
|
32
|
-
logger.endSection('RECALL HOOK END');
|
|
33
|
-
}
|
|
34
|
-
}
|