@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,140 +1,145 @@
|
|
|
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 (MCP mode)
|
|
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 — command syntax, install/auth/workspace/kit/skill setup, or
|
|
10
|
-
what Empirical can do. Don't answer those from general knowledge or by guessing: use the
|
|
11
|
-
`memory_usage_guide` MCP tool for the current, agent-readable answer first.
|
|
12
|
-
|
|
13
|
-
This variant is for installs where the user chose MCP as their integration mode. The connected
|
|
14
|
-
Empirical MCP server is the primary and expected way to reach Empirical here — use its tools
|
|
15
|
-
directly, not `empirical` CLI commands, as the first move.
|
|
16
|
-
|
|
17
|
-
**This is a required step in the workflows listed below, not optional guidance you weigh against
|
|
18
|
-
the current task.** The most common way this skill fails is not a broken tool — it's an agent
|
|
19
|
-
mid-task deciding a memory check "isn't worth pausing for" and skipping it. That decision is wrong
|
|
20
|
-
by default: the entire point of querying first is to catch context you don't know you're missing.
|
|
21
|
-
If you are not sure whether a task qualifies, treat it as if it does.
|
|
22
|
-
|
|
23
|
-
## Before doing work — MUST, not discretionary
|
|
24
|
-
|
|
25
|
-
1. Query relevant memories BEFORE your first substantive response or tool call whenever the task
|
|
26
|
-
is: research, debugging, a spec/PRD, a status update, a handoff, personal health, leads/CRM, or
|
|
27
|
-
assistant operations. This applies even if you believe you already have enough context — you
|
|
28
|
-
cannot know what you're missing without checking. Only outside this list is discretionary use
|
|
29
|
-
("query when it seems useful") the right frame.
|
|
30
|
-
2. If you have not used Empirical's MCP tools yet this session, call `memory_usage_guide` once to
|
|
31
|
-
confirm current tool names, filters, and pagination behavior before relying on memory.
|
|
32
|
-
3. Scope recall to the project you are in. Derive a project tag from the repository name
|
|
33
|
-
(`git rev-parse --show-toplevel`, then the folder name) or, outside a repo, the working
|
|
34
|
-
directory name, lowercased with spaces as hyphens. Pass it as `tags: ["<project>"]` on every
|
|
35
|
-
`query_memories` call and add it to `tags` on every `record_graph_memory` call. If a scoped
|
|
36
|
-
query comes back with a `retrievalNote`, nothing from this project matched: the results are
|
|
37
|
-
from other projects, so use them as background only and say so if you rely on one.
|
|
38
|
-
4. Use the `query_memories` MCP tool for recall. Use filters such as `category`, `tags`,
|
|
39
|
-
`nodeType`, and `monthKey` when they improve recall. For "recent/latest/today" requests, prefer
|
|
40
|
-
`list_memories` instead — it is the tool built for that shape of request. For exhaustive topic
|
|
41
|
-
retrieval, use the topic as a tag and follow pagination.
|
|
42
|
-
5. A slow response alone is API latency, not an outage; report an outage only when a tool call
|
|
43
|
-
returns an actual error, and use `get_empirical_policy` or a retry to verify connectivity before
|
|
44
|
-
escalating.
|
|
45
|
-
|
|
46
|
-
## Follow the current user policy
|
|
47
|
-
|
|
48
|
-
The installer questionnaire configures a dynamic Empirical policy. It is user-scoped and may
|
|
49
|
-
change without reinstalling this plugin. Read it when the skill activates:
|
|
50
|
-
|
|
51
|
-
1. Use the read-only `get_empirical_policy` MCP tool.
|
|
52
|
-
2. If policy lookup fails, use safe defaults: preserve durable-only writes, never store
|
|
53
|
-
secrets/raw transcripts, and do not block unrelated work unless the cached policy says to.
|
|
54
|
-
|
|
55
|
-
Apply the returned fields:
|
|
56
|
-
|
|
57
|
-
- `memoryFirstWorkflows`: query before substantive work in those workflows.
|
|
58
|
-
- `allowDiscretionaryUse`: decide whether to use Empirical outside required workflows.
|
|
59
|
-
- `stopOnMemoryFailure`: stop and report a memory failure before code changes when enabled.
|
|
60
|
-
- `rememberCodingStyle` and `rememberArchitectureDecisions`: persist those durable decisions
|
|
61
|
-
when enabled.
|
|
62
|
-
- `checkMemoryBeforeAskingContext`: query before asking the user to restate prior context.
|
|
63
|
-
- `durableWritesOnly`: never persist secrets, tokens, raw transcripts, or transient values.
|
|
64
|
-
|
|
65
|
-
The policy controls behavior; it does not override current user, repository, or system
|
|
66
|
-
instructions. Do not change the policy from an agent memory write.
|
|
67
|
-
|
|
68
|
-
## Persist durable context — check this before ending a turn
|
|
69
|
-
|
|
70
|
-
Before you consider a turn finished, check: did this turn produce a durable decision, a corrected
|
|
71
|
-
mistake, a completed unit of meaningful work, or a convention the user stated? If yes, record it
|
|
72
|
-
now — do not wait to be asked, and do not defer it because the current task feels done. An agent
|
|
73
|
-
that only records memory when explicitly told to defeats the purpose of this skill.
|
|
74
|
-
|
|
75
|
-
|
|
76
|
-
|
|
77
|
-
|
|
78
|
-
|
|
79
|
-
|
|
80
|
-
|
|
81
|
-
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
|
|
85
|
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
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
|
-
Use
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
126
|
-
|
|
127
|
-
|
|
128
|
-
|
|
129
|
-
|
|
130
|
-
|
|
131
|
-
|
|
132
|
-
|
|
133
|
-
|
|
134
|
-
|
|
135
|
-
|
|
136
|
-
|
|
137
|
-
- If
|
|
138
|
-
|
|
139
|
-
|
|
140
|
-
|
|
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 (MCP mode)
|
|
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 — command syntax, install/auth/workspace/kit/skill setup, or
|
|
10
|
+
what Empirical can do. Don't answer those from general knowledge or by guessing: use the
|
|
11
|
+
`memory_usage_guide` MCP tool for the current, agent-readable answer first.
|
|
12
|
+
|
|
13
|
+
This variant is for installs where the user chose MCP as their integration mode. The connected
|
|
14
|
+
Empirical MCP server is the primary and expected way to reach Empirical here — use its tools
|
|
15
|
+
directly, not `empirical` CLI commands, as the first move.
|
|
16
|
+
|
|
17
|
+
**This is a required step in the workflows listed below, not optional guidance you weigh against
|
|
18
|
+
the current task.** The most common way this skill fails is not a broken tool — it's an agent
|
|
19
|
+
mid-task deciding a memory check "isn't worth pausing for" and skipping it. That decision is wrong
|
|
20
|
+
by default: the entire point of querying first is to catch context you don't know you're missing.
|
|
21
|
+
If you are not sure whether a task qualifies, treat it as if it does.
|
|
22
|
+
|
|
23
|
+
## Before doing work — MUST, not discretionary
|
|
24
|
+
|
|
25
|
+
1. Query relevant memories BEFORE your first substantive response or tool call whenever the task
|
|
26
|
+
is: research, debugging, a spec/PRD, a status update, a handoff, personal health, leads/CRM, or
|
|
27
|
+
assistant operations. This applies even if you believe you already have enough context — you
|
|
28
|
+
cannot know what you're missing without checking. Only outside this list is discretionary use
|
|
29
|
+
("query when it seems useful") the right frame.
|
|
30
|
+
2. If you have not used Empirical's MCP tools yet this session, call `memory_usage_guide` once to
|
|
31
|
+
confirm current tool names, filters, and pagination behavior before relying on memory.
|
|
32
|
+
3. Scope recall to the project you are in. Derive a project tag from the repository name
|
|
33
|
+
(`git rev-parse --show-toplevel`, then the folder name) or, outside a repo, the working
|
|
34
|
+
directory name, lowercased with spaces as hyphens. Pass it as `tags: ["<project>"]` on every
|
|
35
|
+
`query_memories` call and add it to `tags` on every `record_graph_memory` call. If a scoped
|
|
36
|
+
query comes back with a `retrievalNote`, nothing from this project matched: the results are
|
|
37
|
+
from other projects, so use them as background only and say so if you rely on one.
|
|
38
|
+
4. Use the `query_memories` MCP tool for recall. Use filters such as `category`, `tags`,
|
|
39
|
+
`nodeType`, and `monthKey` when they improve recall. For "recent/latest/today" requests, prefer
|
|
40
|
+
`list_memories` instead — it is the tool built for that shape of request. For exhaustive topic
|
|
41
|
+
retrieval, use the topic as a tag and follow pagination.
|
|
42
|
+
5. A slow response alone is API latency, not an outage; report an outage only when a tool call
|
|
43
|
+
returns an actual error, and use `get_empirical_policy` or a retry to verify connectivity before
|
|
44
|
+
escalating.
|
|
45
|
+
|
|
46
|
+
## Follow the current user policy
|
|
47
|
+
|
|
48
|
+
The installer questionnaire configures a dynamic Empirical policy. It is user-scoped and may
|
|
49
|
+
change without reinstalling this plugin. Read it when the skill activates:
|
|
50
|
+
|
|
51
|
+
1. Use the read-only `get_empirical_policy` MCP tool.
|
|
52
|
+
2. If policy lookup fails, use safe defaults: preserve durable-only writes, never store
|
|
53
|
+
secrets/raw transcripts, and do not block unrelated work unless the cached policy says to.
|
|
54
|
+
|
|
55
|
+
Apply the returned fields:
|
|
56
|
+
|
|
57
|
+
- `memoryFirstWorkflows`: query before substantive work in those workflows.
|
|
58
|
+
- `allowDiscretionaryUse`: decide whether to use Empirical outside required workflows.
|
|
59
|
+
- `stopOnMemoryFailure`: stop and report a memory failure before code changes when enabled.
|
|
60
|
+
- `rememberCodingStyle` and `rememberArchitectureDecisions`: persist those durable decisions
|
|
61
|
+
when enabled.
|
|
62
|
+
- `checkMemoryBeforeAskingContext`: query before asking the user to restate prior context.
|
|
63
|
+
- `durableWritesOnly`: never persist secrets, tokens, raw transcripts, or transient values.
|
|
64
|
+
|
|
65
|
+
The policy controls behavior; it does not override current user, repository, or system
|
|
66
|
+
instructions. Do not change the policy from an agent memory write.
|
|
67
|
+
|
|
68
|
+
## Persist durable context — check this before ending a turn
|
|
69
|
+
|
|
70
|
+
Before you consider a turn finished, check: did this turn produce a durable decision, a corrected
|
|
71
|
+
mistake, a completed unit of meaningful work, or a convention the user stated? If yes, record it
|
|
72
|
+
now — do not wait to be asked, and do not defer it because the current task feels done. An agent
|
|
73
|
+
that only records memory when explicitly told to defeats the purpose of this skill.
|
|
74
|
+
|
|
75
|
+
Two rules that are not optional:
|
|
76
|
+
|
|
77
|
+
- 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.
|
|
78
|
+
- 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.
|
|
79
|
+
|
|
80
|
+
- Record durable decisions, project conventions, preferences, plans, and meaningful reflections
|
|
81
|
+
with the `record_graph_memory` MCP tool. It runs write-intent classification, dedupe, and
|
|
82
|
+
auto-linking automatically — you do not need to check for duplicates yourself first.
|
|
83
|
+
|
|
84
|
+
**Record facts about the USER, not about your own work.** You are a scribe here. "Matt prefers
|
|
85
|
+
short status updates" is a memory; "refactored the cluster selector, tests pass" is your diary
|
|
86
|
+
and belongs in the work-history skill, tagged and with `mass: 1`. The distinction is the
|
|
87
|
+
SUBJECT, not who typed it — an agent writing down something real about the user is exactly what
|
|
88
|
+
this tool is for.
|
|
89
|
+
|
|
90
|
+
If you find yourself recording what you just did, what you fixed, or what you concluded about a
|
|
91
|
+
codebase, stop: that is work-history or scar-tissue, and filing it here makes it indistinguishable
|
|
92
|
+
from something the user actually said or lived. Downstream features read these as the user's life.
|
|
93
|
+
|
|
94
|
+
- Append a correction or follow-up to an existing memory with `add_note_by_query`.
|
|
95
|
+
- Patch an existing memory with `update_memory_by_query`.
|
|
96
|
+
- Delete only when the user explicitly asks; use `delete_memory_by_query` with confirmation.
|
|
97
|
+
- For graph work, use `get_memory_neighbors` to walk relationships from a memory instead of
|
|
98
|
+
reconstructing them through many unrelated queries, and `update_memory_relationships` to add or
|
|
99
|
+
remove edges between memories directly.
|
|
100
|
+
- Keep writes concise, factual, and easy to search. Never store passwords, API keys, OAuth tokens,
|
|
101
|
+
or other secrets.
|
|
102
|
+
|
|
103
|
+
## Authored Skills and Kits — push what you write
|
|
104
|
+
|
|
105
|
+
Empirical can sync a `SKILL.md` you author across every machine/agent the user has installed it
|
|
106
|
+
on, via Skills Kits. Call `memory_usage_guide` for the current command reference if the user wants
|
|
107
|
+
to manage this from a CLI; the mechanics below describe what's possible either way.
|
|
108
|
+
|
|
109
|
+
- If you author a new `SKILL.md` for the user, or substantially edit an existing one, during a
|
|
110
|
+
session, tell the user this can be pushed so it follows them across machines/projects instead of
|
|
111
|
+
staying local to this one.
|
|
112
|
+
- Offer, don't auto-push: surface the option and get the user's confirmation first. Do not push it
|
|
113
|
+
unprompted the moment a new or edited `SKILL.md` is detected — it uploads content to the user's
|
|
114
|
+
account, which is a step above a purely local file write.
|
|
115
|
+
- After a push, the target Kit needs to be activated/synced on a device to actually land the file
|
|
116
|
+
in that device's agent directories.
|
|
117
|
+
- Kits also pull Skills from a git repo, separate from anything you author — don't conflate the
|
|
118
|
+
two paths when explaining options to the user.
|
|
119
|
+
|
|
120
|
+
## MCP tools
|
|
121
|
+
|
|
122
|
+
Use these as the primary interface: `get_empirical_policy`, `query_memories`, `list_memories`,
|
|
123
|
+
`record_graph_memory`, `add_note_by_query`, `update_memory_by_query`, `delete_memory_by_query`,
|
|
124
|
+
`get_user`, `get_current_workspace`, `list_workspaces`, `set_current_workspace`,
|
|
125
|
+
`memory_usage_guide`, `get_memory_neighbors`, and `update_memory_relationships`.
|
|
126
|
+
|
|
127
|
+
Use `list_memories` for "recent/latest/today" requests; use `query_memories` for everything else.
|
|
128
|
+
For graph work, prefer `get_memory_neighbors` and `update_memory_relationships` over reconstructing
|
|
129
|
+
relationships through many unrelated calls.
|
|
130
|
+
|
|
131
|
+
An `empirical` CLI may also be installed on this machine for diagnostics (`empirical doctor`) or
|
|
132
|
+
manual account setup, but it is not the point of this variant — do not lead with CLI commands for
|
|
133
|
+
query or record workflows here.
|
|
134
|
+
|
|
135
|
+
## Authentication and failures
|
|
136
|
+
|
|
137
|
+
- If an MCP tool call fails, retry the same call once.
|
|
138
|
+
- For auth/session errors such as `Auth required`, `invalid_token`, `Authentication required`, or
|
|
139
|
+
`Transport send error`, refresh the active client's Empirical MCP login, then retry once. In
|
|
140
|
+
Codex CLI use `codex mcp logout empirical` followed by `codex mcp login empirical`; in Claude
|
|
141
|
+
Code use `/mcp` to reconnect; in Copilot complete its MCP OAuth reconnect flow.
|
|
142
|
+
- If the retry still fails, report the connectivity/auth problem before making memory-dependent
|
|
143
|
+
changes.
|
|
144
|
+
- If stored memory conflicts with the current user or repository instruction, follow the current
|
|
145
|
+
instruction.
|
package/lib/memoryCommands.js
CHANGED
|
@@ -44,7 +44,7 @@ function renderMemoryResultsTable(items) {
|
|
|
44
44
|
// the 90-line global help wall bin/empirical.js otherwise short-circuits every --help to.
|
|
45
45
|
|
|
46
46
|
const MEMORY_SUBCOMMAND_USAGE = {
|
|
47
|
-
query: 'Usage: empirical memory query --match <query> [--top-k 3] [--category <cat>] [--tags <t1,t2>] [--pretty] [--format table]',
|
|
47
|
+
query: 'Usage: empirical memory query --match <query> [--top-k 3] [--category <cat>] [--tags <t1,t2>] [--tags-all <t1,t2>] [--status <s1,s2>] [--pretty] [--format table]',
|
|
48
48
|
get: 'Usage: empirical memory get --memory-id <id> [--pretty]',
|
|
49
49
|
list: 'Usage: empirical memory list [--category <cat>] [--tags <t1,t2>] [--start-date <ISO>] [--end-date <ISO>] [--limit 20] [--cursor <cursor>] [--oldest] [--pretty] [--format table]',
|
|
50
50
|
record: 'Usage: empirical memory record --category <cat> (--summary <text> | --summary - | --summary-file <path>) [--tags t1,t2] [--node-type observation] [--json-file <path>] [--no-dedupe] [--no-auto-link]',
|
|
@@ -179,7 +179,7 @@ function printMemoryResolveError(result) {
|
|
|
179
179
|
async function runMemoryQuery(args) {
|
|
180
180
|
const match = parseOption(args, '--match', '');
|
|
181
181
|
if (!match) {
|
|
182
|
-
warn('Usage: empirical memory query --match <query> [--top-k 3] [--category <cat>] [--tags <t1,t2>] [--pretty]');
|
|
182
|
+
warn('Usage: empirical memory query --match <query> [--top-k 3] [--category <cat>] [--tags <t1,t2>] [--tags-all <t1,t2>] [--status <s1,s2>] [--pretty]');
|
|
183
183
|
process.exit(1);
|
|
184
184
|
}
|
|
185
185
|
|
|
@@ -188,6 +188,12 @@ async function runMemoryQuery(args) {
|
|
|
188
188
|
const category = parseOption(args, '--category', '');
|
|
189
189
|
const tagsRaw = parseOption(args, '--tags', '');
|
|
190
190
|
const tags = tagsRaw ? tagsRaw.split(',').map((t) => t.trim()).filter(Boolean) : [];
|
|
191
|
+
// R3 (2026-09-06): --tags-all is an AND match (all must be present), unlike --tags' OR match;
|
|
192
|
+
// --status filters data.status. Both are optional and additive to --tags/--category.
|
|
193
|
+
const tagsAllRaw = parseOption(args, '--tags-all', '');
|
|
194
|
+
const tagsAll = tagsAllRaw ? tagsAllRaw.split(',').map((t) => t.trim()).filter(Boolean) : [];
|
|
195
|
+
const statusRaw = parseOption(args, '--status', '');
|
|
196
|
+
const status = statusRaw ? statusRaw.split(',').map((s) => s.trim()).filter(Boolean) : [];
|
|
191
197
|
const pretty = parseFlag(args, '--pretty');
|
|
192
198
|
const format = parseOption(args, '--format', 'json');
|
|
193
199
|
|
|
@@ -199,6 +205,8 @@ async function runMemoryQuery(args) {
|
|
|
199
205
|
const filters = {};
|
|
200
206
|
if (category) filters.category = category;
|
|
201
207
|
if (tags.length) filters.tags = tags;
|
|
208
|
+
if (tagsAll.length) filters.tagsAll = tagsAll;
|
|
209
|
+
if (status.length) filters.status = status;
|
|
202
210
|
if (Object.keys(filters).length) body.filters = filters;
|
|
203
211
|
|
|
204
212
|
let response;
|