pi
b9039f577e
- Add image-baked fallback skills (opencode-devbox-environment, mempalace) + harness instruction (instructions/opencode-devbox.md) under /usr/local/share/opencode-devbox/, symlinked in by entrypoint-user.sh (skills only-when-absent; instruction symlink to image, never copied into the devbox-opencode-config volume). Ported from pi-devbox v1.2.0/v1.2.1, adapted to opencode's ~/.config/opencode/instructions/ auto-load model. No pi-extensions skill (opencode has no fork/recall). - Bump opencode 1.17.8 -> 1.17.10. - Bump mempalace 3.4.0 -> 3.5.0 (lockstep with pi-devbox v1.2.2); remove the obsolete diary_write anyOf perl workaround (fixed upstream, issue #1728). - Fix stale ssh-lan.conf ProxyJump guidance comment in setup-lan-access.sh (mirrors pi-devbox 8de0fad); comment-only. - smoke-test.sh + recreate-sanity-check.sh assert baked source + resolved links. - Docs: README Custom skills, AGENTS.md duties + MINOR example, CHANGELOG.
2.3 KiB
Vendored fallback skills + harness instruction
This tree is image-baked content that entrypoint-user.sh links into place
on container start so the container behaves correctly even when no private
skillset repo is mounted:
skills/*→ symlinked into~/.agents/skills/(only when a skill of the same name is not already present, so a mountedskillsetor the OMOS bundled skills always win).instructions/*.md→ symlinked into~/.config/opencode/instructions/, which opencode auto-loads as a session-start system prompt (only when a real file of the same name is not already there).
| item | owner | how it gets here |
|---|---|---|
skills/opencode-devbox-environment |
opencode-devbox (this repo) | authored here; the canonical copy |
skills/mempalace |
the skillset repo |
vendored fallback (snapshot only) |
instructions/opencode-devbox.md |
opencode-devbox (this repo) | authored here; the proactive-load pointer |
Why fallbacks exist
opencode discovers skills under ~/.agents/skills/ and loads harness
instructions from ~/.config/opencode/instructions/*.md at session start. A
container started without the private skillset repo mounted would have
neither — so the agent would not know the container-shaped facts and would not
follow the MemPalace continuity protocol. Baking opencode-devbox-environment
and mempalace closes that availability gap, and the baked
instructions/opencode-devbox.md adds the matching proactive-load directive
(read those two skills at session start) so a fresh container actually picks
them up rather than relying on description-matching.
Note there is no pi-extensions skill here: opencode has no fork/recall
extensions (that is a pi-only concern), so the pi-devbox vendored set does not
carry over 1:1.
Filename discipline
instructions/opencode-devbox.md deliberately uses a name distinct from the
skillset's instructions/mempalace.md. Both can be deployed at once (a mounted
skillset adds its own); the distinct name means our fallback is collision-free
and the entrypoint's never-overwrite-a-real-file guard never has to arbitrate.
Refreshing the snapshots
cp <skillset>/skills/mempalace/SKILL.md skills/mempalace/SKILL.md
Snapshot provenance at last refresh: skillset 8e8db64.