@empirical-gauzza/cli 1.0.23 → 1.0.25
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 +63 -63
- package/bin/empirical.js +1 -1
- package/lib/doc.js +1 -1
- package/lib/env.js +49 -49
- package/lib/installers/detect.js +47 -47
- package/lib/installers/hooks.js +3 -3
- package/lib/installers/skill-variants/SKILL.both.md +170 -165
- package/lib/installers/skill-variants/SKILL.cli.md +166 -161
- package/lib/installers/skill-variants/SKILL.mcp.md +145 -140
- package/lib/memoryCommands.js +10 -2
- package/lib/oauthClient.js +222 -222
- package/lib/policyCommands.js +144 -144
- package/lib/workspaceContext.js +47 -47
- package/package.json +1 -1
|
@@ -1,165 +1,170 @@
|
|
|
1
|
-
---
|
|
2
|
-
name: empirical-memory
|
|
3
|
-
description: Use Empirical to recall/save durable project context across sessions and projects, and to look up how to use Empirical itself - CLI commands, install/auth/workspace/kit/skill setup, docs.
|
|
4
|
-
---
|
|
5
|
-
|
|
6
|
-
# Empirical Memory
|
|
7
|
-
|
|
8
|
-
Use Empirical to carry durable context across projects and clients, and as the first stop for
|
|
9
|
-
"how do I use Empirical" questions — CLI command syntax, install/auth/workspace/kit/skill setup,
|
|
10
|
-
or what Empirical can do. Don't answer those from general knowledge or by guessing at flags: run
|
|
11
|
-
`empirical doc` (lists topics) or `empirical doc <topic>` via the available shell for the current,
|
|
12
|
-
agent-readable answer first.
|
|
13
|
-
|
|
14
|
-
This variant is for installs where the user chose to have both the CLI and MCP tools available.
|
|
15
|
-
Both paths now run through the same write pipeline (dedupe and auto-link on by default), so
|
|
16
|
-
either is safe to use for reads and writes. The CLI is the default choice below because it avoids
|
|
17
|
-
an extra MCP tool-discovery round trip and is easier to script, but that is a latency preference,
|
|
18
|
-
not a safety one — if the CLI is unavailable in this environment, use the equivalent MCP tool
|
|
19
|
-
instead without hesitation.
|
|
20
|
-
|
|
21
|
-
**This is a required step in the workflows listed below, not optional guidance you weigh against
|
|
22
|
-
the current task.** The most common way this skill fails is not a broken tool — it's an agent
|
|
23
|
-
mid-task deciding a memory check "isn't worth pausing for" and skipping it. That decision is wrong
|
|
24
|
-
by default: the entire point of querying first is to catch context you don't know you're missing.
|
|
25
|
-
If you are not sure whether a task qualifies, treat it as if it does.
|
|
26
|
-
|
|
27
|
-
## Before doing work — MUST, not discretionary
|
|
28
|
-
|
|
29
|
-
1. Query relevant memories BEFORE your first substantive response or tool call whenever the task
|
|
30
|
-
is: research, debugging, a spec/PRD, a status update, a handoff, personal health, leads/CRM, or
|
|
31
|
-
assistant operations. This applies even if you believe you already have enough context — you
|
|
32
|
-
cannot know what you're missing without checking. Only outside this list is discretionary use
|
|
33
|
-
("query when it seems useful") the right frame.
|
|
34
|
-
2. Before using the CLI, load its authoritative command reference:
|
|
35
|
-
|
|
36
|
-
```text
|
|
37
|
-
empirical doc memory
|
|
38
|
-
```
|
|
39
|
-
|
|
40
|
-
Follow the documented flags exactly; never guess a positional query form. Use the `empirical`
|
|
41
|
-
CLI first when it is available — both it and the MCP tools carry the same dedupe/auto-link
|
|
42
|
-
guarantees, so this is a convenience choice, not a safety one:
|
|
43
|
-
|
|
44
|
-
```text
|
|
45
|
-
empirical memory query --match "<specific relevant context>" --top-k 3
|
|
46
|
-
```
|
|
47
|
-
|
|
48
|
-
Add `--category` or `--tags` when known. Omit `--pretty` for routine recall because graph-rich
|
|
49
|
-
results can be large. A slow response alone is API latency, not an outage; report an outage
|
|
50
|
-
only when the CLI returns an actual error, and use `empirical doctor` to verify connectivity.
|
|
51
|
-
|
|
52
|
-
3. Scope recall to the project you are in. Derive a project tag from the repository name
|
|
53
|
-
(`git rev-parse --show-toplevel`, then the folder name) or, outside a repo, the working
|
|
54
|
-
directory name, lowercased with spaces as hyphens. Pass it as `tags: ["<project>"]` on every
|
|
55
|
-
`query_memories` call and add it to `tags` on every `record_graph_memory` call. If a scoped
|
|
56
|
-
query comes back with a `retrievalNote`, nothing from this project matched: the results are
|
|
57
|
-
from other projects, so use them as background only and say so if you rely on one.
|
|
58
|
-
4. If the CLI is unavailable, use the connected MCP `query_memories` tool. Use filters such as
|
|
59
|
-
`category`, `tags`, `nodeType`, and `monthKey` when they improve recall. For "recent/latest/
|
|
60
|
-
today" requests, prefer `list_memories` (CLI: `empirical memory list --recent`, see `empirical
|
|
61
|
-
doc memory`) over a match query. For exhaustive topic retrieval, use the topic as a tag and
|
|
62
|
-
follow pagination.
|
|
63
|
-
|
|
64
|
-
## Follow the current user policy
|
|
65
|
-
|
|
66
|
-
The installer questionnaire configures a dynamic Empirical policy. It is user-scoped and may
|
|
67
|
-
change without reinstalling this plugin. Read it when the skill activates:
|
|
68
|
-
|
|
69
|
-
1. Prefer `empirical policy show` when the CLI is available; it uses the local device cache
|
|
70
|
-
and refreshes it when stale.
|
|
71
|
-
2. Otherwise use the read-only `get_empirical_policy` MCP tool.
|
|
72
|
-
3. If policy lookup fails, use safe defaults: preserve durable-only writes, never store
|
|
73
|
-
secrets/raw transcripts, and do not block unrelated work unless the cached policy says to.
|
|
74
|
-
|
|
75
|
-
Apply the returned fields:
|
|
76
|
-
|
|
77
|
-
- `memoryFirstWorkflows`: query before substantive work in those workflows.
|
|
78
|
-
- `allowDiscretionaryUse`: decide whether to use Empirical outside required workflows.
|
|
79
|
-
- `stopOnMemoryFailure`: stop and report a memory failure before code changes when enabled.
|
|
80
|
-
- `rememberCodingStyle` and `rememberArchitectureDecisions`: persist those durable decisions
|
|
81
|
-
when enabled.
|
|
82
|
-
- `checkMemoryBeforeAskingContext`: query before asking the user to restate prior context.
|
|
83
|
-
- `durableWritesOnly`: never persist secrets, tokens, raw transcripts, or transient values.
|
|
84
|
-
|
|
85
|
-
The policy controls behavior; it does not override current user, repository, or system
|
|
86
|
-
instructions. Do not change the policy from an agent memory write.
|
|
87
|
-
|
|
88
|
-
## Persist durable context — check this before ending a turn
|
|
89
|
-
|
|
90
|
-
Before you consider a turn finished, check: did this turn produce a durable decision, a corrected
|
|
91
|
-
mistake, a completed unit of meaningful work, or a convention the user stated? If yes, record it
|
|
92
|
-
now — do not wait to be asked, and do not defer it because the current task feels done. An agent
|
|
93
|
-
that only records memory when explicitly told to defeats the purpose of this skill.
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
98
|
-
|
|
99
|
-
|
|
100
|
-
|
|
101
|
-
|
|
102
|
-
|
|
103
|
-
|
|
104
|
-
|
|
105
|
-
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
109
|
-
|
|
110
|
-
|
|
111
|
-
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
116
|
-
|
|
117
|
-
|
|
118
|
-
|
|
119
|
-
|
|
120
|
-
|
|
121
|
-
|
|
122
|
-
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
141
|
-
-
|
|
142
|
-
|
|
143
|
-
|
|
144
|
-
|
|
145
|
-
|
|
146
|
-
|
|
147
|
-
|
|
148
|
-
|
|
149
|
-
|
|
150
|
-
|
|
151
|
-
|
|
152
|
-
|
|
153
|
-
|
|
154
|
-
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
160
|
-
|
|
161
|
-
|
|
162
|
-
|
|
163
|
-
|
|
164
|
-
|
|
165
|
-
|
|
1
|
+
---
|
|
2
|
+
name: empirical-memory
|
|
3
|
+
description: Use Empirical to recall/save durable project context across sessions and projects, and to look up how to use Empirical itself - CLI commands, install/auth/workspace/kit/skill setup, docs.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Empirical Memory
|
|
7
|
+
|
|
8
|
+
Use Empirical to carry durable context across projects and clients, and as the first stop for
|
|
9
|
+
"how do I use Empirical" questions — CLI command syntax, install/auth/workspace/kit/skill setup,
|
|
10
|
+
or what Empirical can do. Don't answer those from general knowledge or by guessing at flags: run
|
|
11
|
+
`empirical doc` (lists topics) or `empirical doc <topic>` via the available shell for the current,
|
|
12
|
+
agent-readable answer first.
|
|
13
|
+
|
|
14
|
+
This variant is for installs where the user chose to have both the CLI and MCP tools available.
|
|
15
|
+
Both paths now run through the same write pipeline (dedupe and auto-link on by default), so
|
|
16
|
+
either is safe to use for reads and writes. The CLI is the default choice below because it avoids
|
|
17
|
+
an extra MCP tool-discovery round trip and is easier to script, but that is a latency preference,
|
|
18
|
+
not a safety one — if the CLI is unavailable in this environment, use the equivalent MCP tool
|
|
19
|
+
instead without hesitation.
|
|
20
|
+
|
|
21
|
+
**This is a required step in the workflows listed below, not optional guidance you weigh against
|
|
22
|
+
the current task.** The most common way this skill fails is not a broken tool — it's an agent
|
|
23
|
+
mid-task deciding a memory check "isn't worth pausing for" and skipping it. That decision is wrong
|
|
24
|
+
by default: the entire point of querying first is to catch context you don't know you're missing.
|
|
25
|
+
If you are not sure whether a task qualifies, treat it as if it does.
|
|
26
|
+
|
|
27
|
+
## Before doing work — MUST, not discretionary
|
|
28
|
+
|
|
29
|
+
1. Query relevant memories BEFORE your first substantive response or tool call whenever the task
|
|
30
|
+
is: research, debugging, a spec/PRD, a status update, a handoff, personal health, leads/CRM, or
|
|
31
|
+
assistant operations. This applies even if you believe you already have enough context — you
|
|
32
|
+
cannot know what you're missing without checking. Only outside this list is discretionary use
|
|
33
|
+
("query when it seems useful") the right frame.
|
|
34
|
+
2. Before using the CLI, load its authoritative command reference:
|
|
35
|
+
|
|
36
|
+
```text
|
|
37
|
+
empirical doc memory
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
Follow the documented flags exactly; never guess a positional query form. Use the `empirical`
|
|
41
|
+
CLI first when it is available — both it and the MCP tools carry the same dedupe/auto-link
|
|
42
|
+
guarantees, so this is a convenience choice, not a safety one:
|
|
43
|
+
|
|
44
|
+
```text
|
|
45
|
+
empirical memory query --match "<specific relevant context>" --top-k 3
|
|
46
|
+
```
|
|
47
|
+
|
|
48
|
+
Add `--category` or `--tags` when known. Omit `--pretty` for routine recall because graph-rich
|
|
49
|
+
results can be large. A slow response alone is API latency, not an outage; report an outage
|
|
50
|
+
only when the CLI returns an actual error, and use `empirical doctor` to verify connectivity.
|
|
51
|
+
|
|
52
|
+
3. Scope recall to the project you are in. Derive a project tag from the repository name
|
|
53
|
+
(`git rev-parse --show-toplevel`, then the folder name) or, outside a repo, the working
|
|
54
|
+
directory name, lowercased with spaces as hyphens. Pass it as `tags: ["<project>"]` on every
|
|
55
|
+
`query_memories` call and add it to `tags` on every `record_graph_memory` call. If a scoped
|
|
56
|
+
query comes back with a `retrievalNote`, nothing from this project matched: the results are
|
|
57
|
+
from other projects, so use them as background only and say so if you rely on one.
|
|
58
|
+
4. If the CLI is unavailable, use the connected MCP `query_memories` tool. Use filters such as
|
|
59
|
+
`category`, `tags`, `nodeType`, and `monthKey` when they improve recall. For "recent/latest/
|
|
60
|
+
today" requests, prefer `list_memories` (CLI: `empirical memory list --recent`, see `empirical
|
|
61
|
+
doc memory`) over a match query. For exhaustive topic retrieval, use the topic as a tag and
|
|
62
|
+
follow pagination.
|
|
63
|
+
|
|
64
|
+
## Follow the current user policy
|
|
65
|
+
|
|
66
|
+
The installer questionnaire configures a dynamic Empirical policy. It is user-scoped and may
|
|
67
|
+
change without reinstalling this plugin. Read it when the skill activates:
|
|
68
|
+
|
|
69
|
+
1. Prefer `empirical policy show` when the CLI is available; it uses the local device cache
|
|
70
|
+
and refreshes it when stale.
|
|
71
|
+
2. Otherwise use the read-only `get_empirical_policy` MCP tool.
|
|
72
|
+
3. If policy lookup fails, use safe defaults: preserve durable-only writes, never store
|
|
73
|
+
secrets/raw transcripts, and do not block unrelated work unless the cached policy says to.
|
|
74
|
+
|
|
75
|
+
Apply the returned fields:
|
|
76
|
+
|
|
77
|
+
- `memoryFirstWorkflows`: query before substantive work in those workflows.
|
|
78
|
+
- `allowDiscretionaryUse`: decide whether to use Empirical outside required workflows.
|
|
79
|
+
- `stopOnMemoryFailure`: stop and report a memory failure before code changes when enabled.
|
|
80
|
+
- `rememberCodingStyle` and `rememberArchitectureDecisions`: persist those durable decisions
|
|
81
|
+
when enabled.
|
|
82
|
+
- `checkMemoryBeforeAskingContext`: query before asking the user to restate prior context.
|
|
83
|
+
- `durableWritesOnly`: never persist secrets, tokens, raw transcripts, or transient values.
|
|
84
|
+
|
|
85
|
+
The policy controls behavior; it does not override current user, repository, or system
|
|
86
|
+
instructions. Do not change the policy from an agent memory write.
|
|
87
|
+
|
|
88
|
+
## Persist durable context — check this before ending a turn
|
|
89
|
+
|
|
90
|
+
Before you consider a turn finished, check: did this turn produce a durable decision, a corrected
|
|
91
|
+
mistake, a completed unit of meaningful work, or a convention the user stated? If yes, record it
|
|
92
|
+
now — do not wait to be asked, and do not defer it because the current task feels done. An agent
|
|
93
|
+
that only records memory when explicitly told to defeats the purpose of this skill.
|
|
94
|
+
|
|
95
|
+
Two rules that are not optional:
|
|
96
|
+
|
|
97
|
+
- Record one memory per finding. A session that fixed three things records three memories, each with the fix phrase and the date in its summary. One combined summary is not recorded: it cannot be found by any question about one of its parts.
|
|
98
|
+
- Empirical first. A note in a local file, a scratchpad, or a host memory directory is not recorded; it is invisible to every other session, tool, and agent. Record in Empirical, then keep a local pointer if you want one.
|
|
99
|
+
|
|
100
|
+
- Record durable decisions, project conventions, preferences, plans, and meaningful reflections
|
|
101
|
+
with `record_graph_memory` or:
|
|
102
|
+
|
|
103
|
+
```text
|
|
104
|
+
empirical memory record --category <category> --summary "<concise fact>" --tags <tag1,tag2>
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
**Code in the summary?** Never pass backticks or `${...}` inside a double-quoted `--summary`; the
|
|
108
|
+
shell substitutes them away before the CLI runs and the write still succeeds with the code gone.
|
|
109
|
+
Use `--summary-file <path>`, or `--summary -` with a single-quoted heredoc (`<<'EOF'`), or the MCP
|
|
110
|
+
`record_graph_memory` tool, which takes JSON and never touches a shell.
|
|
111
|
+
|
|
112
|
+
Both dedupe against near-duplicate existing memories and auto-link related ones by default; pass
|
|
113
|
+
`--no-dedupe` / `--no-auto-link` on the CLI only when you deliberately want to skip one of those.
|
|
114
|
+
|
|
115
|
+
**Record facts about the USER, not about your own work.** You are a scribe here. "Matt prefers
|
|
116
|
+
short status updates" is a memory; "refactored the cluster selector, tests pass" is your diary
|
|
117
|
+
and belongs in the work-history skill, tagged and with `mass: 1`. The distinction is the
|
|
118
|
+
SUBJECT, not who typed it — an agent writing down something real about the user is exactly what
|
|
119
|
+
this tool is for.
|
|
120
|
+
|
|
121
|
+
If you find yourself recording what you just did, what you fixed, or what you concluded about a
|
|
122
|
+
codebase, stop: that is work-history or scar-tissue, and filing it here makes it indistinguishable
|
|
123
|
+
from something the user actually said or lived. Downstream features read these as the user's life.
|
|
124
|
+
|
|
125
|
+
- Append a correction or follow-up to an existing memory with `add_note_by_query` / `empirical memory note`.
|
|
126
|
+
- Patch an existing memory with `update_memory_by_query` / `empirical memory update`.
|
|
127
|
+
- Delete only when the user explicitly asks; use the delete tool with confirmation, or `empirical memory delete --match "<memory>" --confirm`.
|
|
128
|
+
- For graph work, use `get_memory_neighbors` to walk relationships from a memory instead of
|
|
129
|
+
reconstructing them through many unrelated queries, and `update_memory_relationships` to add or
|
|
130
|
+
remove edges directly.
|
|
131
|
+
- Keep writes concise, factual, and easy to search. Never store passwords, API keys, OAuth tokens, or other secrets.
|
|
132
|
+
|
|
133
|
+
## Authored Skills and Kits — push what you write
|
|
134
|
+
|
|
135
|
+
Empirical can sync a `SKILL.md` you author across every machine/agent the user has installed it
|
|
136
|
+
on, via Skills Kits. Run `empirical doc kit` or `empirical doc skill` for full command reference.
|
|
137
|
+
|
|
138
|
+
- If you author a new `SKILL.md` for the user, or substantially edit an existing one, during a
|
|
139
|
+
session, tell the user about `empirical skill push path/to/SKILL.md [--kit "Kit Name"]`
|
|
140
|
+
afterward so it can follow them across machines/projects instead of staying local to this one.
|
|
141
|
+
- Offer, don't auto-push: surface the option (or offer to run it) and get the user's confirmation
|
|
142
|
+
first. Do not run it unprompted the moment a new or edited `SKILL.md` is detected — it uploads
|
|
143
|
+
content to the user's account, which is a step above a purely local file write.
|
|
144
|
+
- After a push, the target Kit needs `empirical kit use "Kit Name"` or `empirical kit sync` to
|
|
145
|
+
actually land the file in that device's agent directories.
|
|
146
|
+
- `empirical skill list` shows what's already been pushed; `empirical skill history <id>` /
|
|
147
|
+
`empirical skill rollback <id> --to-version N` recover a prior version.
|
|
148
|
+
- Kits also pull Skills from a git repo (`empirical kit add-source`), separate from anything you
|
|
149
|
+
author — don't conflate the two paths when explaining options to the user.
|
|
150
|
+
|
|
151
|
+
## MCP tools
|
|
152
|
+
|
|
153
|
+
Use these when connected: `get_empirical_policy`, `query_memories`, `list_memories`,
|
|
154
|
+
`record_graph_memory`, `add_note_by_query`, `update_memory_by_query`, `delete_memory_by_query`,
|
|
155
|
+
`get_user`, `get_current_workspace`, `list_workspaces`, `set_current_workspace`,
|
|
156
|
+
`memory_usage_guide`, `get_memory_neighbors`, and `update_memory_relationships`. Use
|
|
157
|
+
`list_memories` for "recent/latest/today" requests; use `query_memories` for everything else. For
|
|
158
|
+
graph work, use `get_memory_neighbors` and `update_memory_relationships` when available instead of
|
|
159
|
+
reconstructing relationships through many unrelated calls.
|
|
160
|
+
|
|
161
|
+
## Authentication and failures
|
|
162
|
+
|
|
163
|
+
- If a memory call fails, retry the same call once.
|
|
164
|
+
- For auth/session errors such as `Auth required`, `invalid_token`, `Authentication required`, or `Transport send error`, refresh the active client's Empirical MCP login, then retry once. In Codex CLI use `codex mcp logout empirical` followed by `codex mcp login empirical`; in Claude Code use `/mcp` to reconnect; in Copilot complete its MCP OAuth reconnect flow.
|
|
165
|
+
- If the retry still fails, report the connectivity/auth problem before making memory-dependent changes.
|
|
166
|
+
- If stored memory conflicts with the current user or repository instruction, follow the current instruction.
|
|
167
|
+
|
|
168
|
+
## Exact CLI syntax
|
|
169
|
+
|
|
170
|
+
Run `empirical doctor` to check connectivity and token status. If a CLI memory command reports a token error, run `empirical oauth bootstrap headless --write-env`.
|