Joakim Persson
7551947466
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.
2.5 KiB
Vendored fallback skills
Most directories here are image-baked skills that entrypoint-user.sh
symlinks into ~/.agents/skills/ on container start (only when a skill of the
same name is not already present, so a mounted skillset repo or a user
override always wins).
| skill | owner | how it gets here |
|---|---|---|
pi-devbox-environment |
pi-devbox (this repo) | authored here; the canonical copy |
pi-extensions |
the pi-extensions package repo (skill/) |
vendored fallback + refreshed at build |
mempalace |
the skillset repo |
vendored fallback (snapshot only) |
Why fallbacks exist
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 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)
pi-extensions— Option 1 + Option 2. The committed copy here is the floor; at build timeDockerfile.variantcopies/opt/pi-extensions/skill/(the pinned, package-owned source) over it, so a normal build ships the fresh package copy and a stale-ref / mirror build still ships the snapshot. Keepevaluate-extension-usage.pyalongsideSKILL.md— the skill calls it via./.mempalace— Option 2 only. Themempalaceconsumer skill lives only in the privateskillsetrepo (themempalace-toolkitrepo ships a different skill,opencode-mempalace-bridge), so there is no public package source to copy from. This snapshot is refreshed manually per release.
Refreshing the snapshots
cp <skillset>/skills/pi-extensions/SKILL.md pi-extensions/SKILL.md
cp <skillset>/skills/pi-extensions/evaluate-extension-usage.py pi-extensions/
cp <skillset>/skills/mempalace/SKILL.md mempalace/SKILL.md
Snapshot provenance at last refresh: skillset 8e8db64, pi-extensions pkg a7f3044.