feat(skills): add mempalace proactive-load directive for containers
Baking the mempalace fallback skill fixed *availability*, but mempalace had no proactive-load directive anywhere (pi-toolkit's global AGENTS.md only points to pi-extensions), so a new container would still surface it only via description-matching — the same under-utilisation the pi-extensions directive was created to fix. Add a session-start pointer to the pi-devbox managed AGENTS.md block (pi-global-AGENTS.append.md): gated to pi-devbox containers and conditional on the MemPalace MCP tools being present. Memory continuity matters most in a frequently-recreated container — the palace is its only cross-recreate memory. - pi-global-AGENTS.append.md: '## Session start: load the mempalace skill'. - smoke-test: assert the pointer merges into the global AGENTS.md at build. - docs: VENDORED.md, README, CHANGELOG [Unreleased]. Now both skills are complete in pi-devbox: directive + skill file. pi-extensions = directive (pi-toolkit) + baked skill; mempalace = directive (this block) + baked skill.
This commit is contained in:
@@ -18,3 +18,14 @@ be discovered at runtime, never assumed. And interactive shell aliases
|
||||
(`dssh`, `dscp`, `cat`→`bat`) do **not** exist in your non-interactive bash
|
||||
tool, so spell out the underlying command (e.g.
|
||||
`ssh -F "$HOME/.ssh-local/config" mac …`).
|
||||
|
||||
## Session start: load the mempalace skill
|
||||
|
||||
If MemPalace MCP tools (e.g. `mempalace_search`, `mempalace_diary_write`) are in
|
||||
your tool list, **read `~/.agents/skills/mempalace/SKILL.md` before doing
|
||||
non-trivial work** and follow its protocol: search the palace before answering
|
||||
about past work, and write a diary entry before the session ends. This is
|
||||
especially load-bearing here — a pi-devbox container is frequently recreated, so
|
||||
the palace is your only memory across recreates. Without the habit it is just
|
||||
storage, not memory. (The skill is the consumer side; feeding the palace is the
|
||||
separate `opencode-mempalace-bridge` skill, if present.)
|
||||
|
||||
@@ -16,9 +16,14 @@ override always wins).
|
||||
The pi-toolkit global `AGENTS.md` tells every pi session to read
|
||||
`~/.agents/skills/pi-extensions/SKILL.md` at start (to fix fork/recall
|
||||
under-utilisation). That pointer dangles in a container started **without** the
|
||||
private `skillset` repo mounted. Baking the skill closes that gap. `mempalace`
|
||||
is baked for the same reason (memory continuity), though nothing in `AGENTS.md`
|
||||
points to it directly.
|
||||
private `skillset` repo mounted. Baking the skill closes that *availability*
|
||||
gap. `mempalace` is baked for the same reason (memory continuity); since
|
||||
nothing in pi-toolkit's `AGENTS.md` points to it, the pi-devbox managed block
|
||||
(`pi-global-AGENTS.append.md`) also adds the matching *proactive-load*
|
||||
directive ("load the mempalace skill at session start") so a new container
|
||||
actually picks it up rather than relying on description-matching.
|
||||
`pi-extensions`'s directive already ships in pi-toolkit's `AGENTS.md`, so only
|
||||
its skill file needed baking.
|
||||
|
||||
## Freshness model (layered — see Dockerfile.variant)
|
||||
|
||||
|
||||
Reference in New Issue
Block a user