memgineering 0.25.3 → 0.26.0
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/CHANGELOG.md +44 -0
- package/assets/MEMGINEERING.md +1 -1
- package/assets/memgineering-setup/SKILL.md +14 -5
- package/dist/index.js +513 -141
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -11,6 +11,50 @@ language the reader wants. The bilingual rule the monorepo applies to
|
|
|
11
11
|
|
|
12
12
|
## [Unreleased]
|
|
13
13
|
|
|
14
|
+
## [0.26.0] — 2026-10-10
|
|
15
|
+
|
|
16
|
+
### Changed
|
|
17
|
+
|
|
18
|
+
- **The before-edit check costs almost nothing after its first answer in a
|
|
19
|
+
session.** On a machine signed in to a hosted brain, the `PreToolUse` hook
|
|
20
|
+
started node on every file tool an agent used — about 110 ms each, measured
|
|
21
|
+
(about 490 ms on 0.21.0 and earlier, which also asked the server each time).
|
|
22
|
+
On macOS and Linux it is now a short shell script in front of
|
|
23
|
+
`memgineering guard` that answers a session already shown its rules from a
|
|
24
|
+
marker `guard` leaves: about 20 ms. Everything it is not sure of — the first
|
|
25
|
+
call, a folder brain, a brain switch, a sign-out, a path into an agent's own
|
|
26
|
+
memory folder — still goes to `memgineering guard`, 5–14 ms slower than
|
|
27
|
+
before. Windows keeps the plain `memgineering guard` command.
|
|
28
|
+
- **A hosted brain with no rules is asked at most every two minutes**, not on
|
|
29
|
+
every tool call. A rule written on this machine with `remember --rule` or
|
|
30
|
+
`revise --rule` reaches the next tool call; one written elsewhere — another
|
|
31
|
+
machine, a chat app's connector — arrives within two minutes.
|
|
32
|
+
- **On a folder brain, `guard` reads the brain once per session, not on every
|
|
33
|
+
tool call.** It takes the session's turn before reading and hands it back
|
|
34
|
+
when the brain had no rules, so a rule written later in the session still
|
|
35
|
+
arrives. A read that outlives the hook's five-second limit now costs that
|
|
36
|
+
session's rules from that brain, instead of five seconds on every tool call.
|
|
37
|
+
|
|
38
|
+
### Added
|
|
39
|
+
|
|
40
|
+
- **`memgineering update` brings memgineering's own hooks along.** The first
|
|
41
|
+
time the new version runs — the next agent session's start, or any command you
|
|
42
|
+
type — it rewrites the hook commands memgineering installed in Claude Code's
|
|
43
|
+
`settings.json` and Codex's `hooks.json` to this version's shape, and says so
|
|
44
|
+
once. Only a command exactly as memgineering shipped it is changed: matchers,
|
|
45
|
+
timeouts, other tools' hooks, a command you edited, a hook you removed, a
|
|
46
|
+
symlinked or unparseable settings file all stay as they are (the last two are
|
|
47
|
+
mentioned once). Codex runs a changed hook only after you trust it, so it asks
|
|
48
|
+
you to review it at its next start; until you do (press `t`), neither
|
|
49
|
+
memgineering hook runs in Codex.
|
|
50
|
+
|
|
51
|
+
### Agent guidance
|
|
52
|
+
|
|
53
|
+
- `memgineering-setup`: an update refreshes memgineering's own hook commands
|
|
54
|
+
in Claude Code and Codex by itself — nothing to re-run after an update — and
|
|
55
|
+
a changed Codex hook asks for one review, which is worth relaying with the
|
|
56
|
+
key.
|
|
57
|
+
|
|
14
58
|
## [0.25.3] — 2026-10-06
|
|
15
59
|
|
|
16
60
|
### Fixed
|
package/assets/MEMGINEERING.md
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
name: memgineering
|
|
3
3
|
description: Use whenever the user refers to something they told you before, asks what was decided, tells you something worth keeping, or settles something that should hold next time. The memory lives in their own folder and outlives this session; check it before answering from guesswork, and write to it when you learn something durable.
|
|
4
4
|
type: skill
|
|
5
|
-
version: 0.
|
|
5
|
+
version: 0.26.0
|
|
6
6
|
---
|
|
7
7
|
|
|
8
8
|
# memgineering
|
|
@@ -12,11 +12,11 @@ allowed-tools: Bash(memgineering:*)
|
|
|
12
12
|
Answer this from here, not from a guess. The line is capability, not brand, so
|
|
13
13
|
it does not move as products come and go:
|
|
14
14
|
|
|
15
|
-
|
|
|
16
|
-
|
|
|
17
|
-
| **Any tool that can run a shell command**
|
|
18
|
-
| **A chat app that takes a custom MCP connector, no shell**
|
|
19
|
-
| **Neither**
|
|
15
|
+
| | |
|
|
16
|
+
| ---------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
|
17
|
+
| **Any tool that can run a shell command** | Reads and writes the same brain. Nothing has to be built for a tool that does not exist yet. |
|
|
18
|
+
| **A chat app that takes a custom MCP connector, no shell** | Reads and writes the **hosted** brain on their account through `https://mcp.memgineering.com/mcp`, once they add that connector in the app and sign in with Google. Not a folder brain. |
|
|
19
|
+
| **Neither** | **Not yet.** |
|
|
20
20
|
|
|
21
21
|
`memgineering setup` writes its guidance into the agent tools it finds on the
|
|
22
22
|
machine, and `setup --dry-run` names the ones it actually found rather than
|
|
@@ -182,6 +182,15 @@ answered, and the trust is recorded per hook CONTENT
|
|
|
182
182
|
so an upgrade that changes a hook asks again. Somebody who is not told this
|
|
183
183
|
reads the silence as an install that did not take.
|
|
184
184
|
|
|
185
|
+
**An update brings the hooks along.** The first `resurface` (session start)
|
|
186
|
+
after an update — or the next command anybody types — replaces memgineering's
|
|
187
|
+
own hook commands with the new version's, in both Claude Code and Codex, and
|
|
188
|
+
says so once. It replaces only a command memgineering itself shipped: a hook
|
|
189
|
+
someone edited (an absolute path, say), a removed hook, a symlinked or
|
|
190
|
+
unreadable settings file are left exactly as they are, and the last two are
|
|
191
|
+
named once. When a Codex hook changed this way, Codex asks for the review
|
|
192
|
+
above again at its next start — relay that, with the key.
|
|
193
|
+
|
|
185
194
|
Grok is the case worth knowing, because the obvious guess is wrong: it has
|
|
186
195
|
hooks, more events than either of those two, and `~/.grok/hooks/` needs no
|
|
187
196
|
trust prompt — but a hook there cannot say anything to the model. Measured
|