memroot 0.1.0-alpha.1 → 0.1.0-alpha.4
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 +26 -2
- package/dist/index.js +1929 -470
- package/dist/plugins/claude/.claude-plugin/plugin.json +2 -2
- package/dist/plugins/claude/README.md +8 -4
- package/dist/plugins/claude/hooks/hooks.json +10 -0
- package/dist/plugins/claude/scripts/capture-worker.mjs +19294 -0
- package/dist/plugins/claude/scripts/session-end.mjs +469 -0
- package/dist/plugins/claude/scripts/session-start.mjs +372 -53
- package/dist/plugins/claude/scripts/status.mjs +152 -12
- package/dist/plugins/claude/skills/memroot-memory/SKILL.md +48 -0
- package/dist/plugins/claude/skills/memroot-memory/references/save.md +76 -0
- package/dist/plugins/claude/skills/memroot-status/SKILL.md +19 -0
- package/dist/plugins/codex/.codex-plugin/plugin.json +4 -4
- package/dist/plugins/codex/README.md +13 -9
- package/dist/plugins/codex/hooks/hooks.json +11 -0
- package/dist/plugins/codex/scripts/capture-worker.mjs +19294 -0
- package/dist/plugins/codex/scripts/session-end.mjs +469 -0
- package/dist/plugins/codex/scripts/session-start.mjs +372 -53
- package/dist/plugins/codex/scripts/status.mjs +149 -9
- package/dist/plugins/codex/skills/memroot-memory/SKILL.md +48 -0
- package/dist/plugins/codex/skills/memroot-memory/references/save.md +76 -0
- package/dist/plugins/codex/skills/memroot-status/SKILL.md +20 -0
- package/dist/plugins/grok/.claude-plugin/plugin.json +2 -2
- package/dist/plugins/grok/README.md +10 -4
- package/dist/plugins/grok/hooks/hooks.json +24 -1
- package/dist/plugins/grok/scripts/capture-worker.mjs +19294 -0
- package/dist/plugins/grok/scripts/session-end.mjs +469 -0
- package/dist/plugins/grok/scripts/session-reminder.mjs +275 -0
- package/dist/plugins/grok/scripts/status.mjs +152 -12
- package/dist/plugins/grok/skills/memroot-memory/SKILL.md +48 -0
- package/dist/plugins/grok/skills/memroot-memory/references/save.md +76 -0
- package/dist/plugins/grok/skills/memroot-status/SKILL.md +20 -0
- package/package.json +6 -3
- package/dist/plugins/claude/skills/status/SKILL.md +0 -18
- package/dist/plugins/codex/skills/status/SKILL.md +0 -22
- package/dist/plugins/grok/skills/status/SKILL.md +0 -18
|
@@ -0,0 +1,76 @@
|
|
|
1
|
+
# Building a memory_create request
|
|
2
|
+
|
|
3
|
+
Save one memory per call, a few sentences at most, in your own words. Write the summary so it makes sense to a future reader without this conversation.
|
|
4
|
+
|
|
5
|
+
Use the template below for every kind of memory. Keep `"assertion_type": "descriptive"` with `"predicate": "has_property"` whatever the `memory.kind` is; the server requires that pair to match, and it does not follow the kind. Only `memory.kind`, `memory.title`, `memory.summary`, the assertion `statement`, the literal `value` and `qualifier`, the evidence `summary`, the date, and the two ids change. Other predicates (`requires`, `prefers`, `avoids`, `located_in`, ...) have entity role rules that are easy to get wrong, and some clients show only "Invalid or sensitive tool input" without the failing field, so stay with this form.
|
|
6
|
+
|
|
7
|
+
## Choosing `memory.kind`
|
|
8
|
+
|
|
9
|
+
| What the user wants remembered | kind |
|
|
10
|
+
|---|---|
|
|
11
|
+
| A design or technology choice and why | `architecture_decision` |
|
|
12
|
+
| Something that must always hold ("never call X without Y") | `invariant` |
|
|
13
|
+
| How the team does things (naming, layout, patterns) | `convention` |
|
|
14
|
+
| A known defect or gotcha that is still present | `bug` |
|
|
15
|
+
| Why a failure happens | `root_cause` |
|
|
16
|
+
| What resolved a failure | `fix` |
|
|
17
|
+
| Something that was tried and didn't work | `failed_approach` |
|
|
18
|
+
| A personal or team preference (tools, style) | `preference` |
|
|
19
|
+
| Where something important lives in the code | `code_landmark` |
|
|
20
|
+
| Who owns or maintains a component | `ownership_boundary` |
|
|
21
|
+
| Steps to do a recurring task (release, migration) | `procedure` |
|
|
22
|
+
|
|
23
|
+
## Template
|
|
24
|
+
|
|
25
|
+
Example for "Remember that the deploy fails if migrations run after wrangler deploy":
|
|
26
|
+
|
|
27
|
+
```json
|
|
28
|
+
{
|
|
29
|
+
"idempotency_key": "mr-20261002-deploy-order-7f3a9c2e",
|
|
30
|
+
"memory_request": {
|
|
31
|
+
"schema_version": 1,
|
|
32
|
+
"memory": {
|
|
33
|
+
"kind": "root_cause",
|
|
34
|
+
"title": "Deploy smoke check fails because migrations run after deploy",
|
|
35
|
+
"summary": "scripts/deploy.sh runs wrangler deploy before pnpm db:migrate, so new code briefly sees the old schema. Run migrations first.",
|
|
36
|
+
"valid_time": { "from": "2026-10-02T12:00:00Z", "to": null }
|
|
37
|
+
},
|
|
38
|
+
"entities": [],
|
|
39
|
+
"assertions": [
|
|
40
|
+
{
|
|
41
|
+
"ref": "a1",
|
|
42
|
+
"assertion_type": "descriptive",
|
|
43
|
+
"predicate": "has_property",
|
|
44
|
+
"statement": "Deploys fail intermittently because migrations run after wrangler deploy; running pnpm db:migrate first fixes it.",
|
|
45
|
+
"subject": { "context_entity": "project" },
|
|
46
|
+
"object": { "literal": { "type": "string", "value": "run pnpm db:migrate before wrangler deploy" }, "qualifier": "deploy_order" },
|
|
47
|
+
"confidence": 0.9,
|
|
48
|
+
"importance": 4,
|
|
49
|
+
"valid_time": { "from": "2026-10-02T12:00:00Z", "to": null },
|
|
50
|
+
"git_applicability": { "rule": "all_commits" },
|
|
51
|
+
"evidence_refs": ["e1"],
|
|
52
|
+
"provenance_refs": ["p1"]
|
|
53
|
+
}
|
|
54
|
+
],
|
|
55
|
+
"assertion_relations": [],
|
|
56
|
+
"memory_relations": [],
|
|
57
|
+
"evidence": [
|
|
58
|
+
{ "ref": "e1", "kind": "user_attestation", "locator_version": 1, "locator": {}, "summary": "User asked to remember this root cause." }
|
|
59
|
+
],
|
|
60
|
+
"provenance": [
|
|
61
|
+
{ "ref": "p1", "origin": "direct_api", "adapter": "codex", "source_id": "op-8a2d5f0c9e1b4a7d" }
|
|
62
|
+
]
|
|
63
|
+
}
|
|
64
|
+
}
|
|
65
|
+
```
|
|
66
|
+
|
|
67
|
+
Field notes:
|
|
68
|
+
|
|
69
|
+
- `project_id`: leave it out; the server uses the connection's one authorized project. If the call fails with `project_not_found`, or says `project_id` is required (an older server), get the id once from `projects_list`, add it as the top-level `"project_id"` and retry with the same `idempotency_key`.
|
|
70
|
+
- `idempotency_key`: any unique string of 16 to 128 printable characters that you compose yourself (date, short slug, a few random characters). No command is needed to generate it or the other values. Reuse the same key with the identical request if you retry.
|
|
71
|
+
- `valid_time.from` (in both places): the current UTC time, ending in `Z`.
|
|
72
|
+
- `qualifier`: lowercase snake_case, starting with a letter, such as `package_manager` or `deploy_order`. The literal `value` is a short string, at most 512 bytes.
|
|
73
|
+
- `evidence`: keep exactly one `user_attestation` item with an empty `locator`, and summarize what the user said. Don't add other evidence. If the user agreed to your offer, say so, for example "User agreed to save this root cause after the agent offered."
|
|
74
|
+
- `provenance.source_id`: an opaque id you make up (for example `op-` plus 16 hex digits); it is not a session, commit, or file id.
|
|
75
|
+
|
|
76
|
+
If the call fails with `project_not_found`, or says `project_id` is required, use the `project_id` fallback in the field notes first. If the call is rejected for any other reason, compare your request with the template field by field and retry once with the same `idempotency_key`. If it still fails, tell the user nothing was saved.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: memroot-status
|
|
3
|
+
description: Checks whether Memroot is installed, connected, and capturing sessions, and which project it uses. Use when the user asks if Memroot is set up, signed in, connected or working, whether sessions or memories are being captured, or when Memroot tools are missing or failing. Not for looking up or saving memories.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Memroot status
|
|
7
|
+
|
|
8
|
+
Answer from live checks rather than assumptions, because an installed plugin doesn't prove the account is connected.
|
|
9
|
+
|
|
10
|
+
1. Run the bundled status script for the plugin version and capabilities, including whether session capture is enabled:
|
|
11
|
+
```sh
|
|
12
|
+
node "<plugin root>/scripts/status.mjs"
|
|
13
|
+
```
|
|
14
|
+
The plugin root is two directories above this SKILL.md, so the script is `../../scripts/status.mjs` relative to this file.
|
|
15
|
+
2. Call the memroot MCP server's `connection_status` tool for the account, authorized project, and retrieval mode. In Codex these are the tools of the `memroot` MCP server: `projects_list`, `memory_retrieve`, `memory_create` and `connection_status`.
|
|
16
|
+
3. Report briefly: plugin version, connected or not, project id, retrieval mode, and whether session capture is on.
|
|
17
|
+
|
|
18
|
+
If the memroot tools aren't available or `connection_status` fails, say that Memroot isn't connected in this session and suggest `npx memroot setup --agent codex --yes`, then `npx memroot doctor` for diagnostics. A successful connection check doesn't prove a memory was saved; only a save followed by a retrieval in a fresh session does.
|
|
19
|
+
|
|
20
|
+
Don't read transcripts or credential files to answer, and don't invent endpoints.
|
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "memroot",
|
|
3
|
-
"version": "0.1.0-alpha.
|
|
4
|
-
"description": "Memroot
|
|
3
|
+
"version": "0.1.0-alpha.4",
|
|
4
|
+
"description": "Memroot status, memory usage guidance and opt-in session capture.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Memroot"
|
|
7
7
|
},
|
|
@@ -1,14 +1,20 @@
|
|
|
1
1
|
# Memroot for Grok Build
|
|
2
2
|
|
|
3
|
-
This is the complete, self-contained Memroot plugin root, version `0.1.0-alpha.
|
|
3
|
+
This is the complete, self-contained Memroot plugin root, version `0.1.0-alpha.4`. The setup utility copies this folder into a durable installation before native registration. Node.js is the only runtime requirement. Every script in `scripts/` is generated from the Memroot CLI source and bundled with its dependencies; no script refers to `npx`, the npm cache or files outside this bundle.
|
|
4
4
|
|
|
5
|
-
The status skill and `node scripts/status.mjs` explain this release's capabilities.
|
|
5
|
+
The memroot-status skill and `node scripts/status.mjs` explain this release's capabilities. Setup registers the production MCP server with Grok at user scope (`grok mcp add --scope user --transport http memroot https://api.memroot.dev/mcp`); its tools provide explicit save and retrieval. Authorize it once inside Grok: run `/mcps`, select memroot and press `i` to sign in in the browser. Grok runs the OAuth flow itself and keeps the tokens in its own store (`~/.grok/mcp_credentials.json`); Memroot never reads or copies them. Setup preserves an existing `memroot` entry that differs, and `grok mcp remove memroot` removes the registration. Grok also reads the `memroot` server that Claude Code setup wrote to `~/.claude.json`, but it still needs its own authorization in `/mcps`.
|
|
6
6
|
|
|
7
|
-
|
|
7
|
+
Hooks only read the stdin envelope (at most 64 KiB, waiting at most 500 ms) and never echo event fields. They print nothing on SessionEnd, never open a transcript and make no network request. The PostToolUse hook prints one static sentence about memory retrieval once per session, after the first tool call that ran, and only when setup recorded the MCP registration; otherwise it prints nothing. Its once-per-session marker is an empty file named by a salted hash of the session id (0600 under `$XDG_STATE_HOME/memroot/capture/reminded`; markers older than 14 days are removed when a later session is marked). It runs after every tool call and typically returns in about 30 ms. When the user has opted in with `memroot capture on`, the SessionEnd hook writes one small job file (identifiers and paths only; 0600 under `$XDG_STATE_HOME/memroot/capture`) and starts the bundled `scripts/capture-worker.mjs` fully detached, resolved next to the hook script itself. Without consent it does nothing.
|
|
8
|
+
|
|
9
|
+
The bundled worker reads only the referenced session transcript, keeps user and assistant text plus tool names and file paths (never tool output), redacts secrets, personal email addresses and home paths locally and fails closed, runs your own agent CLI headless with no tools to propose memories, validates them, and sends only typed memories labeled session-extracted (not user-attested) to `https://api.memroot.dev/mcp` with the separate Memroot CLI capture connection. Each memory includes up to 3 short evidence quotes (at most 200 characters) from the redacted transcript, repo-relative paths and symbols, the normalized repository remote, and salted hashes of the session id and quoted segments; one retrieval query per session contains only the repository name. Raw transcripts are never uploaded. At most 3 memories per session and 10 per 24 hours. `memroot capture off` stops capture and deletes queued work.
|
|
10
|
+
|
|
11
|
+
Grok ignores stdout for passive hook events, including SessionStart, and discards UserPromptSubmit output, so this bundle declares a PostToolUse hook for the session reminder (timeout 3 s) and a SessionEnd hook (timeout 5 s; it typically returns in about 25 ms). Grok also loads the Claude Code plugin from `~/.claude`. When both plugins are installed they share the name `memroot` and Grok 1.0.46 loads only the Claude Code copy, so its SessionEnd hook captures the Grok session and no session reminder is shown in Grok; the MCP tools and skills still work there. A user-level `~/.grok/hooks` entry that does not depend on which plugin copy Grok loads is the planned follow-up. The reminder is emitted once per session and is not emitted again after Grok compacts the conversation, so a long session can lose it. It uses the documented Claude-compatible plugin manifest.
|
|
8
12
|
|
|
9
13
|
Inspect the installed plugin through the agent's native plugin interface.
|
|
10
14
|
|
|
11
|
-
Official references verified
|
|
15
|
+
Official references verified October 7, 2026 (Grok Build 1.0.46):
|
|
12
16
|
|
|
13
17
|
- [Plugin loading and Claude compatibility](https://docs.x.ai/build/features/skills-plugins-marketplaces)
|
|
14
18
|
- [Hook contract and passive stdout behavior](https://docs.x.ai/build/features/hooks)
|
|
19
|
+
- [MCP servers, native OAuth and Claude Code compatibility](https://docs.x.ai/build/features/mcp-servers)
|
|
20
|
+
- [Hook output delivery (`10-hooks.md`) and MCP (`07-mcp-servers.md`) user guides](https://github.com/xai-org/grok-build/tree/main/crates/codegen/xai-grok-pager/docs/user-guide)
|
|
@@ -1,3 +1,26 @@
|
|
|
1
1
|
{
|
|
2
|
-
"hooks": {
|
|
2
|
+
"hooks": {
|
|
3
|
+
"PostToolUse": [
|
|
4
|
+
{
|
|
5
|
+
"hooks": [
|
|
6
|
+
{
|
|
7
|
+
"type": "command",
|
|
8
|
+
"command": "node \"${GROK_PLUGIN_ROOT}/scripts/session-reminder.mjs\"",
|
|
9
|
+
"timeout": 3
|
|
10
|
+
}
|
|
11
|
+
]
|
|
12
|
+
}
|
|
13
|
+
],
|
|
14
|
+
"SessionEnd": [
|
|
15
|
+
{
|
|
16
|
+
"hooks": [
|
|
17
|
+
{
|
|
18
|
+
"type": "command",
|
|
19
|
+
"command": "node \"${GROK_PLUGIN_ROOT}/scripts/session-end.mjs\"",
|
|
20
|
+
"timeout": 5
|
|
21
|
+
}
|
|
22
|
+
]
|
|
23
|
+
}
|
|
24
|
+
]
|
|
25
|
+
}
|
|
3
26
|
}
|