Joakim Persson
a7d6a7d235
The pi-toolkit global AGENTS.md tells every pi session to read
~/.agents/skills/pi-extensions/SKILL.md at start (the fork/recall
under-utilisation fix), but that skill lived only in the private skillset
repo — so the pointer dangled in any container started without skillset
mounted. Bake fallbacks so the pointer always resolves.
- pi-extensions (Option 1 + Option 2, layered):
* Canonical skill promoted to the public pi-extensions package repo under
skill/ (separate commit there); co-located with the code it documents.
* rootfs/ carries a committed snapshot (the floor).
* Dockerfile.variant copies /opt/pi-extensions/skill/ over the snapshot
after the pinned clone, so a normal build ships the fresh package copy
(recorded via PI_EXTENSIONS_REF) and an old-ref/mirror build still ships
the snapshot. Helper evaluate-extension-usage.py travels with it.
- mempalace (Option 2 only): snapshot in rootfs/. Its consumer skill has no
public package home (mempalace-toolkit ships a different skill,
opencode-mempalace-bridge), so no build-time refresh.
- entrypoint links both (only-when-absent; mounted skillset still wins).
- smoke-test: build-time presence + package-match check + runtime symlink
assertions; readiness gate now waits on the last-linked skill.
- docs: skills/VENDORED.md (provenance + refresh), README, AGENTS.md,
CHANGELOG [Unreleased].
Note: shipped in the NEXT release; v1.2.0 (run 409) predates this.
2.1 KiB
2.1 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 gap. mempalace
is baked for the same reason (memory continuity), though nothing in AGENTS.md
points to it directly.
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.