@empirical-gauzza/cli 1.0.20 → 1.0.21
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/bin/empirical.js +1 -1
- package/lib/installers/coreMemoryBlock.js +91 -91
- package/lib/installers/skill-variants/SKILL.both.md +154 -154
- package/lib/installers/skill-variants/SKILL.cli.md +150 -150
- package/lib/installers/skill-variants/SKILL.mcp.md +134 -134
- package/lib/installers/skillVariants.js +59 -59
- package/lib/memoryCommands.js +45 -10
- package/lib/skillPaths.js +25 -25
- package/package.json +1 -1
package/bin/empirical.js
CHANGED
|
@@ -1,91 +1,91 @@
|
|
|
1
|
-
'use strict';
|
|
2
|
-
|
|
3
|
-
const { readUtf8IfExists, writeFile, ensureDir } = require('../fsUtils');
|
|
4
|
-
const path = require('path');
|
|
5
|
-
const { CORE_PLUGIN_NAME, OPTIONAL_PLUGIN_NAMES } = require('./nativePlugin');
|
|
6
|
-
|
|
7
|
-
// 2026-08-24: added after a real incident where an agent (Claude Code) ignored Empirical's
|
|
8
|
-
// memory skill for an entire session despite its reminder hooks firing on every turn, and
|
|
9
|
-
// defaulted instead to a competing BUILT-IN memory feature baked into its own system prompt in
|
|
10
|
-
// first-person, identity-framed language ("You have a persistent, file-based memory system...").
|
|
11
|
-
// That framing -- "this is what you are", not "here is a tool you could call" -- is what won by
|
|
12
|
-
// default. The fix is not a stronger hook; it's writing the SAME kind of identity-framed
|
|
13
|
-
// statement into the one place every agent reads unconditionally every session: its global
|
|
14
|
-
// instructions file (CLAUDE.md / AGENTS.md / copilot-instructions.md). Prior versions of the
|
|
15
|
-
// installers deliberately left these files untouched ("native plugin guidance is authoritative")
|
|
16
|
-
// -- that trust was real-world false; hooks and an installable skill were not enough on their own.
|
|
17
|
-
const BEGIN_MARKER = '<!-- BEGIN EMPIRICAL CORE MEMORY -->';
|
|
18
|
-
const END_MARKER = '<!-- END EMPIRICAL CORE MEMORY -->';
|
|
19
|
-
|
|
20
|
-
const PLUGIN_DESCRIPTIONS = {
|
|
21
|
-
[CORE_PLUGIN_NAME]: 'query and save durable project/user context - the core memory skill',
|
|
22
|
-
'empirical-work-history': 'record concise summaries of completed work for future agents',
|
|
23
|
-
'empirical-scar-tissue': 'record recurring failure patterns and prevention guidance',
|
|
24
|
-
'empirical-todo': 'track actionable follow-ups by project'
|
|
25
|
-
};
|
|
26
|
-
|
|
27
|
-
function describePlugin(name) {
|
|
28
|
-
return PLUGIN_DESCRIPTIONS[name] || 'an installed Empirical skill';
|
|
29
|
-
}
|
|
30
|
-
|
|
31
|
-
/**
|
|
32
|
-
* Builds the identity-framed core memory block. Dynamic: lists exactly the plugins this install
|
|
33
|
-
* run actually installed, not a static "here's everything that could exist" list, so it stays
|
|
34
|
-
* accurate as skills are added or removed on a later `empirical install`/`empirical plugin` run.
|
|
35
|
-
*/
|
|
36
|
-
function buildCoreMemoryBlock({ pluginNames = [CORE_PLUGIN_NAME] } = {}) {
|
|
37
|
-
const names = Array.isArray(pluginNames) && pluginNames.length ? pluginNames : [CORE_PLUGIN_NAME];
|
|
38
|
-
const skillLines = names.map((name) => `- \`${name}\` - ${describePlugin(name)}`).join('\n');
|
|
39
|
-
|
|
40
|
-
return `${BEGIN_MARKER}
|
|
41
|
-
## Persistent memory: Empirical
|
|
42
|
-
|
|
43
|
-
You have access to Empirical, a persistent, queryable, cross-session memory graph. This is your
|
|
44
|
-
durable memory system for this project and user - not a feature you might use, the actual place
|
|
45
|
-
durable context lives. It takes priority over inventing your own local notes: writing project
|
|
46
|
-
findings to ad-hoc local markdown files instead of Empirical produces something no other session,
|
|
47
|
-
tool, or agent can search or reuse, and defeats the reason this is installed at all.
|
|
48
|
-
|
|
49
|
-
Before substantive work (research, debugging, a spec or PRD, a status update, a handoff, or
|
|
50
|
-
picking up previously completed work), query Empirical first - do not assume you already have
|
|
51
|
-
enough context. After completing meaningful work, or discovering a mistake worth not repeating,
|
|
52
|
-
record it in Empirical, not in a local file.
|
|
53
|
-
|
|
54
|
-
Installed Empirical skills in this environment:
|
|
55
|
-
${skillLines}
|
|
56
|
-
|
|
57
|
-
Run \`empirical doc\` for the full command reference, or \`empirical doc memory\` for exact query/record syntax.
|
|
58
|
-
${END_MARKER}`;
|
|
59
|
-
}
|
|
60
|
-
|
|
61
|
-
/**
|
|
62
|
-
* Replaces the block between BEGIN/END markers if present, otherwise appends a fresh block
|
|
63
|
-
* (with a leading blank line if the file already has content). Never touches anything outside
|
|
64
|
-
* the markers, so a user's own instructions in this file are preserved untouched. Creates the
|
|
65
|
-
* file (and its parent directory) if it does not exist yet.
|
|
66
|
-
*/
|
|
67
|
-
function upsertCoreMemoryBlock(filePath, block) {
|
|
68
|
-
ensureDir(path.dirname(filePath));
|
|
69
|
-
const existing = readUtf8IfExists(filePath) || '';
|
|
70
|
-
|
|
71
|
-
const beginIndex = existing.indexOf(BEGIN_MARKER);
|
|
72
|
-
const endIndex = existing.indexOf(END_MARKER);
|
|
73
|
-
|
|
74
|
-
if (beginIndex !== -1 && endIndex !== -1 && endIndex > beginIndex) {
|
|
75
|
-
const before = existing.slice(0, beginIndex);
|
|
76
|
-
const after = existing.slice(endIndex + END_MARKER.length);
|
|
77
|
-
writeFile(filePath, `${before}${block}${after}`);
|
|
78
|
-
return;
|
|
79
|
-
}
|
|
80
|
-
|
|
81
|
-
const trimmed = existing.replace(/\s+$/, '');
|
|
82
|
-
const next = trimmed ? `${trimmed}\n\n${block}\n` : `${block}\n`;
|
|
83
|
-
writeFile(filePath, next);
|
|
84
|
-
}
|
|
85
|
-
|
|
86
|
-
module.exports = {
|
|
87
|
-
BEGIN_MARKER,
|
|
88
|
-
END_MARKER,
|
|
89
|
-
buildCoreMemoryBlock,
|
|
90
|
-
upsertCoreMemoryBlock
|
|
91
|
-
};
|
|
1
|
+
'use strict';
|
|
2
|
+
|
|
3
|
+
const { readUtf8IfExists, writeFile, ensureDir } = require('../fsUtils');
|
|
4
|
+
const path = require('path');
|
|
5
|
+
const { CORE_PLUGIN_NAME, OPTIONAL_PLUGIN_NAMES } = require('./nativePlugin');
|
|
6
|
+
|
|
7
|
+
// 2026-08-24: added after a real incident where an agent (Claude Code) ignored Empirical's
|
|
8
|
+
// memory skill for an entire session despite its reminder hooks firing on every turn, and
|
|
9
|
+
// defaulted instead to a competing BUILT-IN memory feature baked into its own system prompt in
|
|
10
|
+
// first-person, identity-framed language ("You have a persistent, file-based memory system...").
|
|
11
|
+
// That framing -- "this is what you are", not "here is a tool you could call" -- is what won by
|
|
12
|
+
// default. The fix is not a stronger hook; it's writing the SAME kind of identity-framed
|
|
13
|
+
// statement into the one place every agent reads unconditionally every session: its global
|
|
14
|
+
// instructions file (CLAUDE.md / AGENTS.md / copilot-instructions.md). Prior versions of the
|
|
15
|
+
// installers deliberately left these files untouched ("native plugin guidance is authoritative")
|
|
16
|
+
// -- that trust was real-world false; hooks and an installable skill were not enough on their own.
|
|
17
|
+
const BEGIN_MARKER = '<!-- BEGIN EMPIRICAL CORE MEMORY -->';
|
|
18
|
+
const END_MARKER = '<!-- END EMPIRICAL CORE MEMORY -->';
|
|
19
|
+
|
|
20
|
+
const PLUGIN_DESCRIPTIONS = {
|
|
21
|
+
[CORE_PLUGIN_NAME]: 'query and save durable project/user context - the core memory skill',
|
|
22
|
+
'empirical-work-history': 'record concise summaries of completed work for future agents',
|
|
23
|
+
'empirical-scar-tissue': 'record recurring failure patterns and prevention guidance',
|
|
24
|
+
'empirical-todo': 'track actionable follow-ups by project'
|
|
25
|
+
};
|
|
26
|
+
|
|
27
|
+
function describePlugin(name) {
|
|
28
|
+
return PLUGIN_DESCRIPTIONS[name] || 'an installed Empirical skill';
|
|
29
|
+
}
|
|
30
|
+
|
|
31
|
+
/**
|
|
32
|
+
* Builds the identity-framed core memory block. Dynamic: lists exactly the plugins this install
|
|
33
|
+
* run actually installed, not a static "here's everything that could exist" list, so it stays
|
|
34
|
+
* accurate as skills are added or removed on a later `empirical install`/`empirical plugin` run.
|
|
35
|
+
*/
|
|
36
|
+
function buildCoreMemoryBlock({ pluginNames = [CORE_PLUGIN_NAME] } = {}) {
|
|
37
|
+
const names = Array.isArray(pluginNames) && pluginNames.length ? pluginNames : [CORE_PLUGIN_NAME];
|
|
38
|
+
const skillLines = names.map((name) => `- \`${name}\` - ${describePlugin(name)}`).join('\n');
|
|
39
|
+
|
|
40
|
+
return `${BEGIN_MARKER}
|
|
41
|
+
## Persistent memory: Empirical
|
|
42
|
+
|
|
43
|
+
You have access to Empirical, a persistent, queryable, cross-session memory graph. This is your
|
|
44
|
+
durable memory system for this project and user - not a feature you might use, the actual place
|
|
45
|
+
durable context lives. It takes priority over inventing your own local notes: writing project
|
|
46
|
+
findings to ad-hoc local markdown files instead of Empirical produces something no other session,
|
|
47
|
+
tool, or agent can search or reuse, and defeats the reason this is installed at all.
|
|
48
|
+
|
|
49
|
+
Before substantive work (research, debugging, a spec or PRD, a status update, a handoff, or
|
|
50
|
+
picking up previously completed work), query Empirical first - do not assume you already have
|
|
51
|
+
enough context. After completing meaningful work, or discovering a mistake worth not repeating,
|
|
52
|
+
record it in Empirical, not in a local file.
|
|
53
|
+
|
|
54
|
+
Installed Empirical skills in this environment:
|
|
55
|
+
${skillLines}
|
|
56
|
+
|
|
57
|
+
Run \`empirical doc\` for the full command reference, or \`empirical doc memory\` for exact query/record syntax.
|
|
58
|
+
${END_MARKER}`;
|
|
59
|
+
}
|
|
60
|
+
|
|
61
|
+
/**
|
|
62
|
+
* Replaces the block between BEGIN/END markers if present, otherwise appends a fresh block
|
|
63
|
+
* (with a leading blank line if the file already has content). Never touches anything outside
|
|
64
|
+
* the markers, so a user's own instructions in this file are preserved untouched. Creates the
|
|
65
|
+
* file (and its parent directory) if it does not exist yet.
|
|
66
|
+
*/
|
|
67
|
+
function upsertCoreMemoryBlock(filePath, block) {
|
|
68
|
+
ensureDir(path.dirname(filePath));
|
|
69
|
+
const existing = readUtf8IfExists(filePath) || '';
|
|
70
|
+
|
|
71
|
+
const beginIndex = existing.indexOf(BEGIN_MARKER);
|
|
72
|
+
const endIndex = existing.indexOf(END_MARKER);
|
|
73
|
+
|
|
74
|
+
if (beginIndex !== -1 && endIndex !== -1 && endIndex > beginIndex) {
|
|
75
|
+
const before = existing.slice(0, beginIndex);
|
|
76
|
+
const after = existing.slice(endIndex + END_MARKER.length);
|
|
77
|
+
writeFile(filePath, `${before}${block}${after}`);
|
|
78
|
+
return;
|
|
79
|
+
}
|
|
80
|
+
|
|
81
|
+
const trimmed = existing.replace(/\s+$/, '');
|
|
82
|
+
const next = trimmed ? `${trimmed}\n\n${block}\n` : `${block}\n`;
|
|
83
|
+
writeFile(filePath, next);
|
|
84
|
+
}
|
|
85
|
+
|
|
86
|
+
module.exports = {
|
|
87
|
+
BEGIN_MARKER,
|
|
88
|
+
END_MARKER,
|
|
89
|
+
buildCoreMemoryBlock,
|
|
90
|
+
upsertCoreMemoryBlock
|
|
91
|
+
};
|
|
@@ -1,154 +1,154 @@
|
|
|
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. If the CLI is unavailable, use the connected MCP `query_memories` tool. Use filters such as
|
|
53
|
-
`category`, `tags`, `nodeType`, and `monthKey` when they improve recall. For "recent/latest/
|
|
54
|
-
today" requests, prefer `list_memories` (CLI: `empirical memory list --recent`, see `empirical
|
|
55
|
-
doc memory`) over a match query. For exhaustive topic retrieval, use the topic as a tag and
|
|
56
|
-
follow pagination.
|
|
57
|
-
|
|
58
|
-
## Follow the current user policy
|
|
59
|
-
|
|
60
|
-
The installer questionnaire configures a dynamic Empirical policy. It is user-scoped and may
|
|
61
|
-
change without reinstalling this plugin. Read it when the skill activates:
|
|
62
|
-
|
|
63
|
-
1. Prefer `empirical policy show` when the CLI is available; it uses the local device cache
|
|
64
|
-
and refreshes it when stale.
|
|
65
|
-
2. Otherwise use the read-only `get_empirical_policy` MCP tool.
|
|
66
|
-
3. If policy lookup fails, use safe defaults: preserve durable-only writes, never store
|
|
67
|
-
secrets/raw transcripts, and do not block unrelated work unless the cached policy says to.
|
|
68
|
-
|
|
69
|
-
Apply the returned fields:
|
|
70
|
-
|
|
71
|
-
- `memoryFirstWorkflows`: query before substantive work in those workflows.
|
|
72
|
-
- `allowDiscretionaryUse`: decide whether to use Empirical outside required workflows.
|
|
73
|
-
- `stopOnMemoryFailure`: stop and report a memory failure before code changes when enabled.
|
|
74
|
-
- `rememberCodingStyle` and `rememberArchitectureDecisions`: persist those durable decisions
|
|
75
|
-
when enabled.
|
|
76
|
-
- `checkMemoryBeforeAskingContext`: query before asking the user to restate prior context.
|
|
77
|
-
- `durableWritesOnly`: never persist secrets, tokens, raw transcripts, or transient values.
|
|
78
|
-
|
|
79
|
-
The policy controls behavior; it does not override current user, repository, or system
|
|
80
|
-
instructions. Do not change the policy from an agent memory write.
|
|
81
|
-
|
|
82
|
-
## Persist durable context — check this before ending a turn
|
|
83
|
-
|
|
84
|
-
Before you consider a turn finished, check: did this turn produce a durable decision, a corrected
|
|
85
|
-
mistake, a completed unit of meaningful work, or a convention the user stated? If yes, record it
|
|
86
|
-
now — do not wait to be asked, and do not defer it because the current task feels done. An agent
|
|
87
|
-
that only records memory when explicitly told to defeats the purpose of this skill.
|
|
88
|
-
|
|
89
|
-
- Record durable decisions, project conventions, preferences, plans, and meaningful reflections
|
|
90
|
-
with `record_graph_memory` or:
|
|
91
|
-
|
|
92
|
-
```text
|
|
93
|
-
empirical memory record --category <category> --summary "<concise fact>" --tags <tag1,tag2>
|
|
94
|
-
```
|
|
95
|
-
|
|
96
|
-
Both dedupe against near-duplicate existing memories and auto-link related ones by default; pass
|
|
97
|
-
`--no-dedupe` / `--no-auto-link` on the CLI only when you deliberately want to skip one of those.
|
|
98
|
-
|
|
99
|
-
**Record facts about the USER, not about your own work.** You are a scribe here. "Matt prefers
|
|
100
|
-
short status updates" is a memory; "refactored the cluster selector, tests pass" is your diary
|
|
101
|
-
and belongs in the work-history skill, tagged and with `mass: 1`. The distinction is the
|
|
102
|
-
SUBJECT, not who typed it — an agent writing down something real about the user is exactly what
|
|
103
|
-
this tool is for.
|
|
104
|
-
|
|
105
|
-
If you find yourself recording what you just did, what you fixed, or what you concluded about a
|
|
106
|
-
codebase, stop: that is work-history or scar-tissue, and filing it here makes it indistinguishable
|
|
107
|
-
from something the user actually said or lived. Downstream features read these as the user's life.
|
|
108
|
-
|
|
109
|
-
- Append a correction or follow-up to an existing memory with `add_note_by_query` / `empirical memory note`.
|
|
110
|
-
- Patch an existing memory with `update_memory_by_query` / `empirical memory update`.
|
|
111
|
-
- Delete only when the user explicitly asks; use the delete tool with confirmation, or `empirical memory delete --match "<memory>" --confirm`.
|
|
112
|
-
- For graph work, use `get_memory_neighbors` to walk relationships from a memory instead of
|
|
113
|
-
reconstructing them through many unrelated queries, and `update_memory_relationships` to add or
|
|
114
|
-
remove edges directly.
|
|
115
|
-
- Keep writes concise, factual, and easy to search. Never store passwords, API keys, OAuth tokens, or other secrets.
|
|
116
|
-
|
|
117
|
-
## Authored Skills and Kits — push what you write
|
|
118
|
-
|
|
119
|
-
Empirical can sync a `SKILL.md` you author across every machine/agent the user has installed it
|
|
120
|
-
on, via Skills Kits. Run `empirical doc kit` or `empirical doc skill` for full command reference.
|
|
121
|
-
|
|
122
|
-
- If you author a new `SKILL.md` for the user, or substantially edit an existing one, during a
|
|
123
|
-
session, tell the user about `empirical skill push path/to/SKILL.md [--kit "Kit Name"]`
|
|
124
|
-
afterward so it can follow them across machines/projects instead of staying local to this one.
|
|
125
|
-
- Offer, don't auto-push: surface the option (or offer to run it) and get the user's confirmation
|
|
126
|
-
first. Do not run it unprompted the moment a new or edited `SKILL.md` is detected — it uploads
|
|
127
|
-
content to the user's account, which is a step above a purely local file write.
|
|
128
|
-
- After a push, the target Kit needs `empirical kit use "Kit Name"` or `empirical kit sync` to
|
|
129
|
-
actually land the file in that device's agent directories.
|
|
130
|
-
- `empirical skill list` shows what's already been pushed; `empirical skill history <id>` /
|
|
131
|
-
`empirical skill rollback <id> --to-version N` recover a prior version.
|
|
132
|
-
- Kits also pull Skills from a git repo (`empirical kit add-source`), separate from anything you
|
|
133
|
-
author — don't conflate the two paths when explaining options to the user.
|
|
134
|
-
|
|
135
|
-
## MCP tools
|
|
136
|
-
|
|
137
|
-
Use these when connected: `get_empirical_policy`, `query_memories`, `list_memories`,
|
|
138
|
-
`record_graph_memory`, `add_note_by_query`, `update_memory_by_query`, `delete_memory_by_query`,
|
|
139
|
-
`get_user`, `get_current_workspace`, `list_workspaces`, `set_current_workspace`,
|
|
140
|
-
`memory_usage_guide`, `get_memory_neighbors`, and `update_memory_relationships`. Use
|
|
141
|
-
`list_memories` for "recent/latest/today" requests; use `query_memories` for everything else. For
|
|
142
|
-
graph work, use `get_memory_neighbors` and `update_memory_relationships` when available instead of
|
|
143
|
-
reconstructing relationships through many unrelated calls.
|
|
144
|
-
|
|
145
|
-
## Authentication and failures
|
|
146
|
-
|
|
147
|
-
- If a memory call fails, retry the same call once.
|
|
148
|
-
- 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.
|
|
149
|
-
- If the retry still fails, report the connectivity/auth problem before making memory-dependent changes.
|
|
150
|
-
- If stored memory conflicts with the current user or repository instruction, follow the current instruction.
|
|
151
|
-
|
|
152
|
-
## Exact CLI syntax
|
|
153
|
-
|
|
154
|
-
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`.
|
|
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. If the CLI is unavailable, use the connected MCP `query_memories` tool. Use filters such as
|
|
53
|
+
`category`, `tags`, `nodeType`, and `monthKey` when they improve recall. For "recent/latest/
|
|
54
|
+
today" requests, prefer `list_memories` (CLI: `empirical memory list --recent`, see `empirical
|
|
55
|
+
doc memory`) over a match query. For exhaustive topic retrieval, use the topic as a tag and
|
|
56
|
+
follow pagination.
|
|
57
|
+
|
|
58
|
+
## Follow the current user policy
|
|
59
|
+
|
|
60
|
+
The installer questionnaire configures a dynamic Empirical policy. It is user-scoped and may
|
|
61
|
+
change without reinstalling this plugin. Read it when the skill activates:
|
|
62
|
+
|
|
63
|
+
1. Prefer `empirical policy show` when the CLI is available; it uses the local device cache
|
|
64
|
+
and refreshes it when stale.
|
|
65
|
+
2. Otherwise use the read-only `get_empirical_policy` MCP tool.
|
|
66
|
+
3. If policy lookup fails, use safe defaults: preserve durable-only writes, never store
|
|
67
|
+
secrets/raw transcripts, and do not block unrelated work unless the cached policy says to.
|
|
68
|
+
|
|
69
|
+
Apply the returned fields:
|
|
70
|
+
|
|
71
|
+
- `memoryFirstWorkflows`: query before substantive work in those workflows.
|
|
72
|
+
- `allowDiscretionaryUse`: decide whether to use Empirical outside required workflows.
|
|
73
|
+
- `stopOnMemoryFailure`: stop and report a memory failure before code changes when enabled.
|
|
74
|
+
- `rememberCodingStyle` and `rememberArchitectureDecisions`: persist those durable decisions
|
|
75
|
+
when enabled.
|
|
76
|
+
- `checkMemoryBeforeAskingContext`: query before asking the user to restate prior context.
|
|
77
|
+
- `durableWritesOnly`: never persist secrets, tokens, raw transcripts, or transient values.
|
|
78
|
+
|
|
79
|
+
The policy controls behavior; it does not override current user, repository, or system
|
|
80
|
+
instructions. Do not change the policy from an agent memory write.
|
|
81
|
+
|
|
82
|
+
## Persist durable context — check this before ending a turn
|
|
83
|
+
|
|
84
|
+
Before you consider a turn finished, check: did this turn produce a durable decision, a corrected
|
|
85
|
+
mistake, a completed unit of meaningful work, or a convention the user stated? If yes, record it
|
|
86
|
+
now — do not wait to be asked, and do not defer it because the current task feels done. An agent
|
|
87
|
+
that only records memory when explicitly told to defeats the purpose of this skill.
|
|
88
|
+
|
|
89
|
+
- Record durable decisions, project conventions, preferences, plans, and meaningful reflections
|
|
90
|
+
with `record_graph_memory` or:
|
|
91
|
+
|
|
92
|
+
```text
|
|
93
|
+
empirical memory record --category <category> --summary "<concise fact>" --tags <tag1,tag2>
|
|
94
|
+
```
|
|
95
|
+
|
|
96
|
+
Both dedupe against near-duplicate existing memories and auto-link related ones by default; pass
|
|
97
|
+
`--no-dedupe` / `--no-auto-link` on the CLI only when you deliberately want to skip one of those.
|
|
98
|
+
|
|
99
|
+
**Record facts about the USER, not about your own work.** You are a scribe here. "Matt prefers
|
|
100
|
+
short status updates" is a memory; "refactored the cluster selector, tests pass" is your diary
|
|
101
|
+
and belongs in the work-history skill, tagged and with `mass: 1`. The distinction is the
|
|
102
|
+
SUBJECT, not who typed it — an agent writing down something real about the user is exactly what
|
|
103
|
+
this tool is for.
|
|
104
|
+
|
|
105
|
+
If you find yourself recording what you just did, what you fixed, or what you concluded about a
|
|
106
|
+
codebase, stop: that is work-history or scar-tissue, and filing it here makes it indistinguishable
|
|
107
|
+
from something the user actually said or lived. Downstream features read these as the user's life.
|
|
108
|
+
|
|
109
|
+
- Append a correction or follow-up to an existing memory with `add_note_by_query` / `empirical memory note`.
|
|
110
|
+
- Patch an existing memory with `update_memory_by_query` / `empirical memory update`.
|
|
111
|
+
- Delete only when the user explicitly asks; use the delete tool with confirmation, or `empirical memory delete --match "<memory>" --confirm`.
|
|
112
|
+
- For graph work, use `get_memory_neighbors` to walk relationships from a memory instead of
|
|
113
|
+
reconstructing them through many unrelated queries, and `update_memory_relationships` to add or
|
|
114
|
+
remove edges directly.
|
|
115
|
+
- Keep writes concise, factual, and easy to search. Never store passwords, API keys, OAuth tokens, or other secrets.
|
|
116
|
+
|
|
117
|
+
## Authored Skills and Kits — push what you write
|
|
118
|
+
|
|
119
|
+
Empirical can sync a `SKILL.md` you author across every machine/agent the user has installed it
|
|
120
|
+
on, via Skills Kits. Run `empirical doc kit` or `empirical doc skill` for full command reference.
|
|
121
|
+
|
|
122
|
+
- If you author a new `SKILL.md` for the user, or substantially edit an existing one, during a
|
|
123
|
+
session, tell the user about `empirical skill push path/to/SKILL.md [--kit "Kit Name"]`
|
|
124
|
+
afterward so it can follow them across machines/projects instead of staying local to this one.
|
|
125
|
+
- Offer, don't auto-push: surface the option (or offer to run it) and get the user's confirmation
|
|
126
|
+
first. Do not run it unprompted the moment a new or edited `SKILL.md` is detected — it uploads
|
|
127
|
+
content to the user's account, which is a step above a purely local file write.
|
|
128
|
+
- After a push, the target Kit needs `empirical kit use "Kit Name"` or `empirical kit sync` to
|
|
129
|
+
actually land the file in that device's agent directories.
|
|
130
|
+
- `empirical skill list` shows what's already been pushed; `empirical skill history <id>` /
|
|
131
|
+
`empirical skill rollback <id> --to-version N` recover a prior version.
|
|
132
|
+
- Kits also pull Skills from a git repo (`empirical kit add-source`), separate from anything you
|
|
133
|
+
author — don't conflate the two paths when explaining options to the user.
|
|
134
|
+
|
|
135
|
+
## MCP tools
|
|
136
|
+
|
|
137
|
+
Use these when connected: `get_empirical_policy`, `query_memories`, `list_memories`,
|
|
138
|
+
`record_graph_memory`, `add_note_by_query`, `update_memory_by_query`, `delete_memory_by_query`,
|
|
139
|
+
`get_user`, `get_current_workspace`, `list_workspaces`, `set_current_workspace`,
|
|
140
|
+
`memory_usage_guide`, `get_memory_neighbors`, and `update_memory_relationships`. Use
|
|
141
|
+
`list_memories` for "recent/latest/today" requests; use `query_memories` for everything else. For
|
|
142
|
+
graph work, use `get_memory_neighbors` and `update_memory_relationships` when available instead of
|
|
143
|
+
reconstructing relationships through many unrelated calls.
|
|
144
|
+
|
|
145
|
+
## Authentication and failures
|
|
146
|
+
|
|
147
|
+
- If a memory call fails, retry the same call once.
|
|
148
|
+
- 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.
|
|
149
|
+
- If the retry still fails, report the connectivity/auth problem before making memory-dependent changes.
|
|
150
|
+
- If stored memory conflicts with the current user or repository instruction, follow the current instruction.
|
|
151
|
+
|
|
152
|
+
## Exact CLI syntax
|
|
153
|
+
|
|
154
|
+
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`.
|