joakimp
d2f2396c4a
This snapshot was byte-identical to skillset and therefore MISSING the
Temporal grounding guidance, which had been authored only into pi-devbox's
vendored copy (pi-devbox 904fe85) and never back-ported to the owner repo. So
opencode-devbox containers — and any host consumer reading skillset directly —
never saw it, while pi-devbox containers did.
skillset 63f3bf5 is now canonical again and carries the section with wording
generalized to cover both devboxes ("a devbox container (pi-devbox or
opencode-devbox)"). Snapshot + VENDORED.md provenance updated to match.
Substance for the agent: establish "now" and compute now - entry.timestamp
before saying "yesterday"/"last week" — a container recreate or fresh session
is not a day boundary, and two diary entries 90 minutes apart can straddle one.
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 63f3bf5.