@clawmem-ai/clawmem 0.1.9 → 0.1.11
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 +37 -189
- package/openclaw.plugin.json +20 -89
- package/package.json +2 -1
- package/skills/clawmem/SKILL.md +78 -0
- package/skills/clawmem/references/collaboration.md +223 -0
- package/skills/clawmem/references/communication.md +82 -0
- package/skills/clawmem/references/manual-ops.md +205 -0
- package/skills/clawmem/references/repair.md +127 -0
- package/skills/clawmem/references/schema.md +63 -0
- package/skills/clawmem/scripts/clawmem_exports.py +54 -0
- package/src/config.test.ts +82 -0
- package/src/config.ts +23 -6
- package/src/github-client.ts +207 -1
- package/src/memory.test.ts +2 -4
- package/src/memory.ts +11 -15
- package/src/service.ts +1249 -56
- package/src/types.ts +9 -2
- package/src/utils.ts +13 -0
|
@@ -0,0 +1,223 @@
|
|
|
1
|
+
# ClawMem Collaboration
|
|
2
|
+
|
|
3
|
+
Use this reference when memory should live in a shared repo instead of one agent's private default repo, or when multiple agents or teammates need to read and write the same memory space. Use it for both `collaboration` and `collabration` requests.
|
|
4
|
+
|
|
5
|
+
## Contents
|
|
6
|
+
|
|
7
|
+
- When to use
|
|
8
|
+
- Default operating style
|
|
9
|
+
- Repo routing and shared spaces
|
|
10
|
+
- Collaboration model
|
|
11
|
+
- Choose the right mechanism
|
|
12
|
+
- Pre-mutation checklist
|
|
13
|
+
- Prompt-to-tool mapping
|
|
14
|
+
- Team memory quality bar
|
|
15
|
+
- Collaboration rule of thumb
|
|
16
|
+
- Manual org-owned shared repo creation
|
|
17
|
+
- Fallback mode
|
|
18
|
+
|
|
19
|
+
## When to use
|
|
20
|
+
|
|
21
|
+
Use this reference when the user asks to:
|
|
22
|
+
|
|
23
|
+
- create or manage an organization
|
|
24
|
+
- invite someone into an organization
|
|
25
|
+
- inspect, accept, or decline an invitation sent to the current user
|
|
26
|
+
- create or manage a team
|
|
27
|
+
- add or remove a repository collaborator
|
|
28
|
+
- grant a team access to a repo
|
|
29
|
+
- inspect outside collaborators
|
|
30
|
+
- create a shared team memory repo or org-owned memory space
|
|
31
|
+
- debug why a user can or cannot access a repo
|
|
32
|
+
|
|
33
|
+
Do not use this workflow for ordinary memory recall or save actions unless the user is specifically asking to change who can access a memory repo.
|
|
34
|
+
|
|
35
|
+
## Default operating style
|
|
36
|
+
|
|
37
|
+
- Prefer the built-in ClawMem collaboration tools first.
|
|
38
|
+
- Inspect current state before mutating anything.
|
|
39
|
+
- Set `confirmed=true` only after the user has approved the exact org, team, repo, invitation, or permission change.
|
|
40
|
+
- Fall back to `gh api` or `curl` only when plugin tools are unavailable, when debugging backend behavior directly, or when you must create an org-owned repo because the plugin does not expose an org-repo creation tool yet.
|
|
41
|
+
- Reuse the main `clawmem` skill's route-resolution helper when raw shell access is required.
|
|
42
|
+
- Think in canonical runtime permissions: `read`, `write`, `admin`.
|
|
43
|
+
- Treat GitHub-compatible aliases such as `pull`, `triage`, `push`, and `maintain` as transport compatibility only.
|
|
44
|
+
|
|
45
|
+
Tool-first rule:
|
|
46
|
+
- Read-only inspection:
|
|
47
|
+
- `collaboration_orgs`
|
|
48
|
+
- `collaboration_teams`
|
|
49
|
+
- `collaboration_team_repos`
|
|
50
|
+
- `collaboration_repo_collaborators`
|
|
51
|
+
- `collaboration_repo_invitations`
|
|
52
|
+
- `collaboration_user_repo_invitations`
|
|
53
|
+
- `collaboration_org_invitations`
|
|
54
|
+
- `collaboration_user_org_invitations`
|
|
55
|
+
- `collaboration_outside_collaborators`
|
|
56
|
+
- `collaboration_repo_access_inspect`
|
|
57
|
+
- Mutations:
|
|
58
|
+
- `collaboration_org_create`
|
|
59
|
+
- `collaboration_team_create`
|
|
60
|
+
- `collaboration_team_membership_set`
|
|
61
|
+
- `collaboration_team_membership_remove`
|
|
62
|
+
- `collaboration_team_repo_set`
|
|
63
|
+
- `collaboration_team_repo_remove`
|
|
64
|
+
- `collaboration_repo_collaborator_set`
|
|
65
|
+
- `collaboration_repo_collaborator_remove`
|
|
66
|
+
- `collaboration_user_repo_invitation_accept`
|
|
67
|
+
- `collaboration_user_repo_invitation_decline`
|
|
68
|
+
- `collaboration_org_invitation_create`
|
|
69
|
+
- `collaboration_user_org_invitation_accept`
|
|
70
|
+
- `collaboration_user_org_invitation_decline`
|
|
71
|
+
|
|
72
|
+
## Repo routing and shared spaces
|
|
73
|
+
|
|
74
|
+
Before explicit memory operations, choose the right repo:
|
|
75
|
+
- Private personal memory: usually the current agent's `defaultRepo`
|
|
76
|
+
- Project memory: the relevant project repo
|
|
77
|
+
- Shared or team knowledge: the shared repo for that team or project
|
|
78
|
+
- Unclear: inspect `memory_repos`, then choose deliberately
|
|
79
|
+
|
|
80
|
+
Do not treat `defaultRepo` as the only space. It is only the fallback.
|
|
81
|
+
|
|
82
|
+
Default tool path:
|
|
83
|
+
- Use `memory_repos` to inspect accessible spaces
|
|
84
|
+
- Use `memory_repo_create` when a new repo should be owned by the current agent identity
|
|
85
|
+
- Create an org-owned repo with raw `gh api` or `curl` when the memory space must be governed by an organization team
|
|
86
|
+
- Pass `repo` explicitly to `memory_recall`, `memory_list`, `memory_get`, `memory_store`, `memory_update`, and `memory_forget` when the target is not the current `defaultRepo`
|
|
87
|
+
|
|
88
|
+
This keeps private memory, project memory, and shared memory separate without forcing extra plugin configuration changes.
|
|
89
|
+
|
|
90
|
+
## Collaboration model
|
|
91
|
+
|
|
92
|
+
Reason with these rules before every collaboration action:
|
|
93
|
+
|
|
94
|
+
- An organization is an explicit governance boundary.
|
|
95
|
+
- Org membership is explicit and separate from team membership.
|
|
96
|
+
- Teams are org-scoped authorization groups, not social groups.
|
|
97
|
+
- Effective repo access is `max(org base permission, direct collaborator grant, team grant)` after owner or admin shortcuts.
|
|
98
|
+
- Runtime permissions are only `none`, `read`, `write`, and `admin`.
|
|
99
|
+
- `memory_repos` only shows repos that are already accessible now; it does not prove there are no pending invitations.
|
|
100
|
+
- A repo collaborator grant may create a pending repository invitation instead of immediate access when the target user is not already a collaborator.
|
|
101
|
+
- Accepting a repository invitation is what turns a pending share into visible repo access for the invitee.
|
|
102
|
+
- Outside collaborators are non-members who still have direct collaborator access to at least one org-owned repo.
|
|
103
|
+
- Accepting an org invitation creates org membership, joins invited teams as `member`, and removes the pending invitation.
|
|
104
|
+
- If a user becomes an org member, any outside-collaborator row for that org should disappear.
|
|
105
|
+
- The system-managed `admins` team is an implementation mechanism, not a user-facing product primitive.
|
|
106
|
+
|
|
107
|
+
## Choose the right mechanism
|
|
108
|
+
|
|
109
|
+
Use this decision map:
|
|
110
|
+
|
|
111
|
+
| Goal | Use |
|
|
112
|
+
|---|---|
|
|
113
|
+
| Give one user access to one repo without org membership | Direct collaborator |
|
|
114
|
+
| Bring one user into the org | Org invitation |
|
|
115
|
+
| Grant a group access to selected repos | Team + team-repo grant |
|
|
116
|
+
| Create a shared team memory space | Org-owned repo + team-repo grant |
|
|
117
|
+
| Create another memory space under the current agent identity | `memory_repo_create` |
|
|
118
|
+
| Inspect non-members who still have repo access | Outside collaborator listing |
|
|
119
|
+
|
|
120
|
+
Hard rules:
|
|
121
|
+
- Never assume team membership creates org membership.
|
|
122
|
+
- Never use team membership as a side-door org bootstrap.
|
|
123
|
+
- Never assume a repo share should become org membership; choose intentionally.
|
|
124
|
+
- If the task is org-scoped, ensure the org already exists or create it explicitly first.
|
|
125
|
+
|
|
126
|
+
## Pre-mutation checklist
|
|
127
|
+
|
|
128
|
+
Before any write action:
|
|
129
|
+
|
|
130
|
+
1. Identify the acting identity, target org, target repo, target user, target team, and desired permission.
|
|
131
|
+
2. Normalize the user's requested permission mentally to `read`, `write`, or `admin` before reasoning.
|
|
132
|
+
3. Inspect current state first when the request is ambiguous.
|
|
133
|
+
4. If the action changes governance, permissions, membership, or invitations, require explicit user intent or confirmation.
|
|
134
|
+
5. Never paste raw tokens into chat or files.
|
|
135
|
+
|
|
136
|
+
Read-only checks can run without confirmation.
|
|
137
|
+
|
|
138
|
+
## Prompt-to-tool mapping
|
|
139
|
+
|
|
140
|
+
Translate user intent like this:
|
|
141
|
+
|
|
142
|
+
- `Create a shared memory repo for team X`
|
|
143
|
+
- inspect or create the org and team first
|
|
144
|
+
- if the repo should be team-governed, create an org-owned repo with raw `gh api` or `curl`; `memory_repo_create` only creates repos under the current agent identity
|
|
145
|
+
- grant the team access with `collaboration_team_repo_set`
|
|
146
|
+
- `Give Alice access to this one memory repo`
|
|
147
|
+
- inspect direct collaborators first with `collaboration_repo_collaborators`
|
|
148
|
+
- then use `collaboration_repo_collaborator_set`
|
|
149
|
+
- if the user was not already a collaborator, expect a pending repo invitation and verify with `collaboration_repo_invitations`
|
|
150
|
+
- `Bring Alice into the org and platform team`
|
|
151
|
+
- inspect teams first with `collaboration_teams`
|
|
152
|
+
- then use `collaboration_org_invitation_create`
|
|
153
|
+
- `Someone shared a memory repo with me; can you see it and accept it?`
|
|
154
|
+
- start with `collaboration_user_repo_invitations`
|
|
155
|
+
- do not treat a `memory_repos` miss as proof that no share exists
|
|
156
|
+
- if the correct pending invite is visible and the user asked to accept it, use `collaboration_user_repo_invitation_accept`
|
|
157
|
+
- `I still cannot see the shared memory repo`
|
|
158
|
+
- inspect `collaboration_user_repo_invitations` first
|
|
159
|
+
- if needed, have the repo owner inspect `collaboration_repo_invitations`
|
|
160
|
+
- `Why can Bob still see this repo?`
|
|
161
|
+
- start with `collaboration_repo_access_inspect`
|
|
162
|
+
- then drill into `collaboration_repo_collaborators`, `collaboration_repo_invitations`, `collaboration_team_repos`, `collaboration_outside_collaborators`, and `collaboration_org_invitations` as needed
|
|
163
|
+
- `Remove Carol from org-shared memory access`
|
|
164
|
+
- identify whether access comes from a direct collaborator grant, a team repo grant, or a pending invitation
|
|
165
|
+
- remove the actual source of access rather than guessing
|
|
166
|
+
|
|
167
|
+
## Team memory quality bar
|
|
168
|
+
|
|
169
|
+
- Private memories can start rough and become cleaner over time
|
|
170
|
+
- Shared memories should be conclusions, not speculation
|
|
171
|
+
- When access is governed by teams or org policy, prefer org-owned repos over one user's private space
|
|
172
|
+
- Use stable `kind:*` and `topic:*` labels so different agents can retrieve the same schema
|
|
173
|
+
- Prefer updating a canonical shared fact in place instead of creating competing duplicates
|
|
174
|
+
|
|
175
|
+
## Collaboration rule of thumb
|
|
176
|
+
|
|
177
|
+
If knowledge should stay personal, keep it in the agent's default repo. If it should shape multiple agents or people, put it in a shared repo and target that repo explicitly on retrieval and save.
|
|
178
|
+
|
|
179
|
+
## Manual org-owned shared repo creation
|
|
180
|
+
|
|
181
|
+
Use the plugin tool path first. If the memory space must be org-governed, create an org-owned repo directly because `memory_repo_create` only creates repos under the current agent identity.
|
|
182
|
+
|
|
183
|
+
### With `gh api`
|
|
184
|
+
|
|
185
|
+
```sh
|
|
186
|
+
GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
|
|
187
|
+
gh api -X POST "/orgs/<org>/repos" \
|
|
188
|
+
-f name='team-memory' \
|
|
189
|
+
-F private=true \
|
|
190
|
+
-F has_issues=true
|
|
191
|
+
```
|
|
192
|
+
|
|
193
|
+
### With `curl`
|
|
194
|
+
|
|
195
|
+
```sh
|
|
196
|
+
curl -sf -X POST "$CLAWMEM_BASE_URL/orgs/<org>/repos" \
|
|
197
|
+
-H "Authorization: token $CLAWMEM_TOKEN" \
|
|
198
|
+
-H "Content-Type: application/json" \
|
|
199
|
+
-d '{"name": "team-memory", "private": true, "has_issues": true}'
|
|
200
|
+
```
|
|
201
|
+
|
|
202
|
+
After the repo exists:
|
|
203
|
+
- grant the team access with `collaboration_team_repo_set`
|
|
204
|
+
- use the main memory tools with explicit `repo` targeting for read and write flows
|
|
205
|
+
- reuse [manual-ops.md](manual-ops.md) only if you need raw memory issue control after the repo already exists
|
|
206
|
+
|
|
207
|
+
## Fallback mode
|
|
208
|
+
|
|
209
|
+
If the collaboration tools are unavailable, use `gh api` against the ClawMem host; fall back to `curl` only when `gh` is unavailable or broken.
|
|
210
|
+
|
|
211
|
+
Command pattern:
|
|
212
|
+
|
|
213
|
+
```sh
|
|
214
|
+
GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
|
|
215
|
+
gh api "/user"
|
|
216
|
+
```
|
|
217
|
+
|
|
218
|
+
If `gh` cannot be used:
|
|
219
|
+
|
|
220
|
+
```sh
|
|
221
|
+
curl -sf -H "Authorization: token $CLAWMEM_TOKEN" \
|
|
222
|
+
"$CLAWMEM_BASE_URL/user"
|
|
223
|
+
```
|
|
@@ -0,0 +1,82 @@
|
|
|
1
|
+
# ClawMem Communication And First-Run Messaging
|
|
2
|
+
|
|
3
|
+
Use this reference when you need user-facing copy after setup succeeds, need a short first-run message, want to generate a memory console link, or want stronger post-save communication after memory operations.
|
|
4
|
+
|
|
5
|
+
## Contents
|
|
6
|
+
|
|
7
|
+
- Keep the user posted
|
|
8
|
+
- Restart notice protocol
|
|
9
|
+
- First-run message
|
|
10
|
+
- Memory visualization console
|
|
11
|
+
|
|
12
|
+
## Keep the user posted
|
|
13
|
+
|
|
14
|
+
Nothing interesting should happen silently. If memory shaped the answer or changed after the turn, tell the user what happened.
|
|
15
|
+
|
|
16
|
+
Preferred retrieval transparency:
|
|
17
|
+
- `Memory hit #<id>: <title>`
|
|
18
|
+
|
|
19
|
+
Use a miss note only when the user would reasonably expect that you checked:
|
|
20
|
+
- `Memory miss: no prior decision found on staging cutover`
|
|
21
|
+
|
|
22
|
+
Preferred confirmation:
|
|
23
|
+
- `Locked memory #<id>: <title>`
|
|
24
|
+
|
|
25
|
+
Friendlier variants are fine as long as they stay truthful and short.
|
|
26
|
+
|
|
27
|
+
Examples:
|
|
28
|
+
- `Memory hit #14: Team demo moved to Wednesday`
|
|
29
|
+
- `Locked memory #10: API rate limiting uses a sliding window policy`
|
|
30
|
+
- `Locked memory #27: Client meeting is Thursday at 2pm`
|
|
31
|
+
|
|
32
|
+
## Restart notice protocol
|
|
33
|
+
|
|
34
|
+
If setup requires an OpenClaw gateway restart and that restart may interrupt outgoing replies, send a short notice before restarting.
|
|
35
|
+
|
|
36
|
+
Suggested notice:
|
|
37
|
+
|
|
38
|
+
> ClawMem is installed and selected as the active memory plugin. Restarting the OpenClaw gateway to load it now.
|
|
39
|
+
> If the connection drops for a moment, say hi again and I will continue from there.
|
|
40
|
+
|
|
41
|
+
## First-run message
|
|
42
|
+
|
|
43
|
+
After restart completes and verification passes, use a short onboarding note. Keep it high-signal and avoid dumping the full skill into chat.
|
|
44
|
+
|
|
45
|
+
Suggested structure:
|
|
46
|
+
- ClawMem is active and now persists durable memories across sessions.
|
|
47
|
+
- The agent will proactively recall relevant preferences, decisions, lessons, and active tasks.
|
|
48
|
+
- The agent will tell the user when it locks a memory.
|
|
49
|
+
- The agent can evolve its schema over time by adding reusable kinds or topics when the current schema is not expressive enough.
|
|
50
|
+
- The user can inspect the memory graph in the console link below.
|
|
51
|
+
|
|
52
|
+
Optional fuller note:
|
|
53
|
+
|
|
54
|
+
> ClawMem is active. I now carry durable memories across sessions instead of starting from zero each time.
|
|
55
|
+
> I will proactively recall relevant preferences, decisions, lessons, workflows, and active tasks when they can help.
|
|
56
|
+
> When I learn something reusable, I can lock it in immediately and evolve the schema deliberately so future retrieval gets better.
|
|
57
|
+
> When I save something important, I will tell you. You can inspect the memory graph in the console link below.
|
|
58
|
+
|
|
59
|
+
## Memory visualization console
|
|
60
|
+
|
|
61
|
+
The ClawMem Console provides an interactive graph view of memory nodes, labels, and links.
|
|
62
|
+
|
|
63
|
+
### Generate a console login URL
|
|
64
|
+
|
|
65
|
+
Construct the URL from the current agent token:
|
|
66
|
+
|
|
67
|
+
```text
|
|
68
|
+
https://console.clawmem.ai/login.html?token={CLAWMEM_TOKEN}
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
Read `CLAWMEM_TOKEN` from the current route, substitute it into the URL, and show the full untruncated URL directly to the authenticated user.
|
|
72
|
+
|
|
73
|
+
### When to show the console link
|
|
74
|
+
|
|
75
|
+
- During onboarding after a successful install
|
|
76
|
+
- When the user asks to view memories, the graph, or a dashboard
|
|
77
|
+
- After significant memory operations, such as bulk saves
|
|
78
|
+
- When a visual overview would clearly help the user
|
|
79
|
+
|
|
80
|
+
### Security
|
|
81
|
+
|
|
82
|
+
The console login URL contains the agent token. Never store it in memory nodes, files, logs, or commits. Only show it directly to the authenticated user.
|
|
@@ -0,0 +1,205 @@
|
|
|
1
|
+
# ClawMem Manual Operations And Troubleshooting
|
|
2
|
+
|
|
3
|
+
Use this reference only when:
|
|
4
|
+
- the user explicitly wants raw GitHub-style repo or issue operations
|
|
5
|
+
- you are debugging backend state or labels
|
|
6
|
+
- the plugin memory tools are unavailable
|
|
7
|
+
|
|
8
|
+
ClawMem runs on a GitHub-compatible backend, so repo, issue, label, invitation, and team operations follow GitHub-shaped APIs. That is why `gh` and `curl` are valid fallback tools here.
|
|
9
|
+
|
|
10
|
+
## Contents
|
|
11
|
+
|
|
12
|
+
- Route resolution
|
|
13
|
+
- Preflight
|
|
14
|
+
- Save a memory manually
|
|
15
|
+
- Search memories manually
|
|
16
|
+
- Mark memory as stale manually
|
|
17
|
+
- Link related memories manually
|
|
18
|
+
- `git push` to ClawMem
|
|
19
|
+
- Known pitfalls
|
|
20
|
+
- Autonomy
|
|
21
|
+
|
|
22
|
+
If the plugin tools are available, prefer:
|
|
23
|
+
- `memory_repos` to inspect available repos
|
|
24
|
+
- `memory_list` to inspect the current active-memory index
|
|
25
|
+
- `memory_get` to verify one exact memory
|
|
26
|
+
- `memory_labels` to inspect current schema
|
|
27
|
+
- `memory_repo_create` to create a new memory repo
|
|
28
|
+
- `memory_store` to save
|
|
29
|
+
- `memory_update` to evolve one canonical memory in place
|
|
30
|
+
- `memory_recall` to search
|
|
31
|
+
- `memory_forget` to retire stale memories
|
|
32
|
+
|
|
33
|
+
## Route resolution
|
|
34
|
+
|
|
35
|
+
ClawMem is routed per agent identity, not through one global repo or token.
|
|
36
|
+
|
|
37
|
+
Resolve the current route with the bundled helper:
|
|
38
|
+
|
|
39
|
+
```sh
|
|
40
|
+
eval "$(python3 scripts/clawmem_exports.py)"
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
That exports:
|
|
44
|
+
- `CLAWMEM_AGENT_ID`
|
|
45
|
+
- `CLAWMEM_BASE_URL`
|
|
46
|
+
- `CLAWMEM_HOST`
|
|
47
|
+
- `CLAWMEM_DEFAULT_REPO`
|
|
48
|
+
- `CLAWMEM_REPO`
|
|
49
|
+
- `CLAWMEM_TOKEN`
|
|
50
|
+
|
|
51
|
+
Rules:
|
|
52
|
+
- Never store tokens in files or chat
|
|
53
|
+
- `CLAWMEM_DEFAULT_REPO` is the fallback memory space for automatic flows
|
|
54
|
+
- `CLAWMEM_REPO` is the repo chosen for the current operation
|
|
55
|
+
- If `CLAWMEM_TOKEN` is empty, this agent identity has not been provisioned yet
|
|
56
|
+
|
|
57
|
+
## Preflight
|
|
58
|
+
|
|
59
|
+
```sh
|
|
60
|
+
eval "$(python3 scripts/clawmem_exports.py)"
|
|
61
|
+
|
|
62
|
+
test -n "$CLAWMEM_REPO" || { echo "ClawMem repo missing for agent $CLAWMEM_AGENT_ID"; exit 1; }
|
|
63
|
+
test -n "$CLAWMEM_TOKEN" || { echo "ClawMem token missing for agent $CLAWMEM_AGENT_ID"; exit 1; }
|
|
64
|
+
case "$CLAWMEM_REPO" in
|
|
65
|
+
*/*) ;;
|
|
66
|
+
*) echo "Invalid CLAWMEM_REPO='$CLAWMEM_REPO' (expected owner/repo)"; exit 1 ;;
|
|
67
|
+
esac
|
|
68
|
+
```
|
|
69
|
+
|
|
70
|
+
For ClawMem, always pass `--repo "$CLAWMEM_REPO"` to `gh` or use `$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/...` with `curl` explicitly.
|
|
71
|
+
|
|
72
|
+
Do not export `GH_HOST` or `GH_ENTERPRISE_TOKEN` globally for unrelated github.com work. Use per-command env prefixes if you need isolation.
|
|
73
|
+
|
|
74
|
+
## Save a memory manually
|
|
75
|
+
|
|
76
|
+
Use the tool path first. If raw issue control is required:
|
|
77
|
+
|
|
78
|
+
### With `gh`
|
|
79
|
+
|
|
80
|
+
```sh
|
|
81
|
+
for lbl in "type:memory" "kind:core-fact" "kind:convention" "kind:lesson" "kind:skill" "kind:task"; do
|
|
82
|
+
GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
|
|
83
|
+
gh label create "$lbl" --repo "$CLAWMEM_REPO" --color "5319e7" 2>/dev/null || true
|
|
84
|
+
done
|
|
85
|
+
|
|
86
|
+
GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
|
|
87
|
+
gh issue create --repo "$CLAWMEM_REPO" \
|
|
88
|
+
--title "Memory: <concise title>" \
|
|
89
|
+
--body "<durable detail in plain language>" \
|
|
90
|
+
--label "type:memory" \
|
|
91
|
+
--label "kind:lesson"
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
### With `curl`
|
|
95
|
+
|
|
96
|
+
```sh
|
|
97
|
+
for lbl in "type:memory" "kind:core-fact" "kind:convention" "kind:lesson" "kind:skill" "kind:task"; do
|
|
98
|
+
curl -sf -X POST -H "Authorization: token $CLAWMEM_TOKEN" \
|
|
99
|
+
-H "Content-Type: application/json" \
|
|
100
|
+
"$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/labels" \
|
|
101
|
+
-d "{\"name\":\"$lbl\",\"color\":\"5319e7\"}" >/dev/null 2>&1 || true
|
|
102
|
+
done
|
|
103
|
+
|
|
104
|
+
curl -sf -X POST -H "Authorization: token $CLAWMEM_TOKEN" \
|
|
105
|
+
-H "Content-Type: application/json" \
|
|
106
|
+
"$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues" \
|
|
107
|
+
-d "{
|
|
108
|
+
\"title\": \"Memory: <concise title>\",
|
|
109
|
+
\"body\": \"<durable detail in plain language>\",
|
|
110
|
+
\"labels\": [\"type:memory\", \"kind:lesson\"]
|
|
111
|
+
}" | jq '{number, title, url: .html_url}'
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
## Search memories manually
|
|
115
|
+
|
|
116
|
+
### With `gh`
|
|
117
|
+
|
|
118
|
+
```sh
|
|
119
|
+
GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
|
|
120
|
+
gh issue list --repo "$CLAWMEM_REPO" \
|
|
121
|
+
--state open \
|
|
122
|
+
--label "type:memory" \
|
|
123
|
+
--search "<keywords>" \
|
|
124
|
+
--limit 100 \
|
|
125
|
+
--json number,title,body,labels,updatedAt
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
### With `curl`
|
|
129
|
+
|
|
130
|
+
```sh
|
|
131
|
+
curl -sf -H "Authorization: token $CLAWMEM_TOKEN" \
|
|
132
|
+
"$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues?state=open&labels=type:memory&per_page=100&type=issues" | \
|
|
133
|
+
jq --arg q "<keywords>" '
|
|
134
|
+
($q | ascii_downcase) as $needle
|
|
135
|
+
| map(select(
|
|
136
|
+
((.title // "") + "\n" + (.body // "")) | ascii_downcase | contains($needle)
|
|
137
|
+
))
|
|
138
|
+
| map({number, title, body, labels: [.labels[]?.name], updatedAt: .updated_at})
|
|
139
|
+
'
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
## Mark memory as stale manually
|
|
143
|
+
|
|
144
|
+
If this is still the same canonical fact or task, prefer `memory_update` instead of retiring the old node.
|
|
145
|
+
|
|
146
|
+
### With `gh`
|
|
147
|
+
|
|
148
|
+
```sh
|
|
149
|
+
GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
|
|
150
|
+
gh issue close <number> --repo "$CLAWMEM_REPO"
|
|
151
|
+
```
|
|
152
|
+
|
|
153
|
+
### With `curl`
|
|
154
|
+
|
|
155
|
+
```sh
|
|
156
|
+
curl -sf -X PATCH -H "Authorization: token $CLAWMEM_TOKEN" \
|
|
157
|
+
-H "Content-Type: application/json" \
|
|
158
|
+
"$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues/<number>" \
|
|
159
|
+
-d '{"state": "closed"}'
|
|
160
|
+
```
|
|
161
|
+
|
|
162
|
+
If a new memory replaces an old one, save the new memory first and mention the old `#ID` in the replacement body so the supersession is explicit.
|
|
163
|
+
|
|
164
|
+
## Link related memories manually
|
|
165
|
+
|
|
166
|
+
When one memory depends on, refines, or supersedes another, mention `#<id>` in the body so the graph keeps an explicit edge.
|
|
167
|
+
|
|
168
|
+
Prefer doing this when you create a curated raw memory, or when you are already rewriting the full issue body intentionally.
|
|
169
|
+
|
|
170
|
+
If you patch an existing plugin-managed memory body by hand, preserve the existing structured body and add the `#<id>` relation into the durable detail instead of overwriting metadata fields blindly.
|
|
171
|
+
|
|
172
|
+
## `git push` to ClawMem
|
|
173
|
+
|
|
174
|
+
`GH_HOST` and `GH_ENTERPRISE_TOKEN` affect `gh`, not `git push`. If you need to push code to a ClawMem git service repo:
|
|
175
|
+
|
|
176
|
+
```sh
|
|
177
|
+
echo "$CLAWMEM_TOKEN" | gh auth login -h "$CLAWMEM_HOST" --with-token
|
|
178
|
+
```
|
|
179
|
+
|
|
180
|
+
After that, `git push` to `https://git.clawmem.ai/...` works normally.
|
|
181
|
+
|
|
182
|
+
## Known pitfalls
|
|
183
|
+
|
|
184
|
+
| Problem | Fix |
|
|
185
|
+
|---|---|
|
|
186
|
+
| Labels do not update reliably via `PATCH` on some backends | Use `PUT /repos/{owner}/{repo}/issues/{n}/labels` when you need exact label replacement |
|
|
187
|
+
| `openclaw config get` returns redacted token values | Read the config file path via `openclaw config file`, then inspect the JSON directly |
|
|
188
|
+
| Conversation mirror returns `404` | The cached conversation issue was deleted; the plugin recreates it on the next session |
|
|
189
|
+
| New session gets `401 Unauthorized` | Re-read the current agent route. If this is first use, trigger one real turn so the plugin can finish provisioning |
|
|
190
|
+
| Agent uses the wrong memory repo | Resolve `config.agents.<agentId>` for the current agent; do not read only top-level legacy repo settings |
|
|
191
|
+
| `gh` is not the official GitHub CLI | Run `gh --version`; if it is the npm `gh` package instead of the official CLI, use `curl` or replace the CLI install |
|
|
192
|
+
|
|
193
|
+
## Autonomy
|
|
194
|
+
|
|
195
|
+
Without confirmation:
|
|
196
|
+
- creating or updating memory nodes
|
|
197
|
+
- adding comments
|
|
198
|
+
- reusing or creating labels
|
|
199
|
+
- closing stale memory nodes
|
|
200
|
+
- creating new memory repos when a new space is clearly needed
|
|
201
|
+
|
|
202
|
+
Requires confirmation:
|
|
203
|
+
- OpenClaw config changes
|
|
204
|
+
- service restarts
|
|
205
|
+
- deletions that go beyond ordinary memory retirement
|
|
@@ -0,0 +1,127 @@
|
|
|
1
|
+
# ClawMem Repair And Verification
|
|
2
|
+
|
|
3
|
+
Use this reference when ClawMem is already installed but is not selected as the active memory plugin, is missing per-agent provisioning, has a broken route, or needs verification after setup.
|
|
4
|
+
|
|
5
|
+
The website bootstrap `SKILL.md` is the primary setup guide. This reference is for post-install repair, diagnostics, and compatibility-file reminders.
|
|
6
|
+
|
|
7
|
+
## Contents
|
|
8
|
+
|
|
9
|
+
- Verify activation and provisioning
|
|
10
|
+
- Verify read access without manual login
|
|
11
|
+
- Verify the plugin tool path
|
|
12
|
+
- Compatibility mode for SOUL.md, AGENTS.md, and TOOLS.md
|
|
13
|
+
- Definition of done
|
|
14
|
+
- If ClawMem is still broken
|
|
15
|
+
|
|
16
|
+
## Step 1: Verify activation and provisioning
|
|
17
|
+
|
|
18
|
+
First verify that ClawMem is the active memory plugin.
|
|
19
|
+
|
|
20
|
+
```sh
|
|
21
|
+
openclaw status
|
|
22
|
+
python3 - <<'PY'
|
|
23
|
+
import json, os, subprocess
|
|
24
|
+
cfg_path = subprocess.check_output(["openclaw", "config", "file"], text=True).strip()
|
|
25
|
+
with open(os.path.expanduser(cfg_path)) as f:
|
|
26
|
+
root = json.load(f)
|
|
27
|
+
slots = (root.get("plugins") or {}).get("slots") or {}
|
|
28
|
+
print(f"plugins.slots.memory = {slots.get('memory', 'MISSING')}")
|
|
29
|
+
PY
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
Expected:
|
|
33
|
+
- OpenClaw status shows ClawMem as the active memory plugin
|
|
34
|
+
- `plugins.slots.memory = clawmem`
|
|
35
|
+
|
|
36
|
+
Then verify the current agent route. Resolve the current route with the bundled helper:
|
|
37
|
+
|
|
38
|
+
```sh
|
|
39
|
+
eval "$(python3 scripts/clawmem_exports.py)"
|
|
40
|
+
printf 'agent=%s\nbase=%s\ndefaultRepo=%s\ntoken=%s\n' \
|
|
41
|
+
"${CLAWMEM_AGENT_ID}" "${CLAWMEM_BASE_URL}" "${CLAWMEM_DEFAULT_REPO}" \
|
|
42
|
+
"$(test -n "${CLAWMEM_TOKEN}" && printf SET || printf MISSING)"
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
If `CLAWMEM_DEFAULT_REPO` or `CLAWMEM_TOKEN` is missing, the current agent has not been provisioned yet. Trigger one real turn with that agent so the plugin can finish provisioning and persist credentials, or restart OpenClaw and retry after the agent is first used.
|
|
46
|
+
|
|
47
|
+
## Step 2: Verify read access without manual login
|
|
48
|
+
|
|
49
|
+
This proves that a fresh session can query ClawMem using the current agent's provisioned route.
|
|
50
|
+
|
|
51
|
+
```sh
|
|
52
|
+
eval "$(python3 scripts/clawmem_exports.py)"
|
|
53
|
+
|
|
54
|
+
test -n "$CLAWMEM_REPO" || { echo "Current agent route has no repo yet"; exit 1; }
|
|
55
|
+
test -n "$CLAWMEM_TOKEN" || { echo "Current agent route has no token yet"; exit 1; }
|
|
56
|
+
|
|
57
|
+
GH_HOST="$CLAWMEM_HOST" GH_ENTERPRISE_TOKEN="$CLAWMEM_TOKEN" \
|
|
58
|
+
gh issue list --repo "$CLAWMEM_REPO" --limit 1 --json number,title
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
If `gh` is unavailable or not the official GitHub CLI, use the fallback probe:
|
|
62
|
+
|
|
63
|
+
```sh
|
|
64
|
+
curl -sf -H "Authorization: token $CLAWMEM_TOKEN" \
|
|
65
|
+
"$CLAWMEM_BASE_URL/repos/$CLAWMEM_REPO/issues?state=open&per_page=1&type=issues" | \
|
|
66
|
+
jq 'map({number,title})'
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
If either command returns JSON, even `[]`, the route is usable.
|
|
70
|
+
|
|
71
|
+
## Step 3: Verify the plugin tool path
|
|
72
|
+
|
|
73
|
+
From a normal ClawMem-enabled session, verify that:
|
|
74
|
+
- `memory_repos` lists accessible repos and marks the default repo
|
|
75
|
+
- `memory_list` returns the active memory index
|
|
76
|
+
- `memory_get` fetches one exact memory by id or issue number
|
|
77
|
+
- `memory_labels` returns the current reusable schema labels
|
|
78
|
+
- `memory_recall` returns either a hit list or a clean miss
|
|
79
|
+
- `memory_store` is available for immediate durable saves
|
|
80
|
+
- `memory_update` updates an existing memory in place
|
|
81
|
+
- `memory_repo_create` creates a new repo when a new memory space is needed
|
|
82
|
+
|
|
83
|
+
Conversation summaries or auto-extracted memories from a just-finished session may appear on the next real request, not necessarily immediately at session close.
|
|
84
|
+
|
|
85
|
+
## Compatibility mode for SOUL.md, AGENTS.md, and TOOLS.md
|
|
86
|
+
|
|
87
|
+
If your OpenClaw environment still relies on file-injected identity or behavior reminders, use these compact compatibility snippets. Do not duplicate the entire skill body into those files.
|
|
88
|
+
|
|
89
|
+
### Optional SOUL.md identity block
|
|
90
|
+
|
|
91
|
+
```markdown
|
|
92
|
+
## Memory System — ClawMem
|
|
93
|
+
I use ClawMem as my memory system.
|
|
94
|
+
When prior context may help, I search ClawMem before answering.
|
|
95
|
+
```
|
|
96
|
+
|
|
97
|
+
### Optional AGENTS.md reminder
|
|
98
|
+
|
|
99
|
+
```markdown
|
|
100
|
+
Before ending every response, ask: "Did I learn anything durable this turn?"
|
|
101
|
+
If yes or unsure, save it to ClawMem now.
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
### Optional TOOLS.md reminder
|
|
105
|
+
|
|
106
|
+
```markdown
|
|
107
|
+
ClawMem is the primary long-term memory system.
|
|
108
|
+
Use the bundled $clawmem skill for retrieval, saving, routing, schema, and troubleshooting.
|
|
109
|
+
```
|
|
110
|
+
|
|
111
|
+
These snippets are compatibility aids, not the primary runtime source of truth.
|
|
112
|
+
|
|
113
|
+
## Definition of done
|
|
114
|
+
|
|
115
|
+
- `openclaw.json` has `plugins.slots.memory = clawmem`
|
|
116
|
+
- The current agent route has a `defaultRepo` or legacy `repo`
|
|
117
|
+
- The current agent route has a `token`
|
|
118
|
+
- Read-only probe works without manual `gh auth login`
|
|
119
|
+
- Plugin memory tools work from a normal session
|
|
120
|
+
- The bundled `$clawmem` skill is available after installation
|
|
121
|
+
|
|
122
|
+
## If ClawMem is still broken
|
|
123
|
+
|
|
124
|
+
- If `plugins.slots.memory` is wrong, set it back to `clawmem`, restart the gateway, and retry.
|
|
125
|
+
- If the route is missing a repo or token, trigger one real turn with that agent and retry provisioning checks.
|
|
126
|
+
- If a new session gets `401 Unauthorized`, re-read the current route instead of assuming the old repo or token is still valid.
|
|
127
|
+
- If your environment still depends on `SOUL.md` or `AGENTS.md`, add the compatibility snippets above rather than pasting large sections of this skill into those files.
|