Newly installed Python skill is unavailable to child kernels of an older session

[pcarielo]

prime-agent 0.8.1, Linux, forkserver on (default).

Problem

Install a Python-backed skill while a session is already running. Children of that session fork from a kernel template that predates the install, so the skill arrives pre-imported as a placeholder and the import fails. Verbatim from inside an rlm child:

IMPORT FAIL: ModuleNotFoundError("No module named 'zonk_probe'")
preimported name type: _PrimeAgentUnavailableSkill
src on sys.path: False

A fresh root session started afterwards loads the same skill directory natively:

IMPORT OK: /home/carielo/.prime/agent/skills/zonk-probe/src/zonk_probe/__init__.py
src on sys.path: True

So the skill works or not depending on which kernel asks, and the child has no way to know it got a stale environment. The system prompt still advertises the skill, which makes it worse: the child believes the capability exists and fails at call time instead.

Reproduction

1. Start a prime-agent session (daemon, forkserver on).
2. Drop a throwaway Python skill into ~/.prime/agent/skills/zonk-probe/ (SKILL.md, pyproject.toml with the hatchling template, src/zonk_probe/init.py).
3. From the running session, spawn a child that imports zonk_probe. It gets ModuleNotFoundError, the pre-imported name is _PrimeAgentUnavailableSkill, and the skill src is not on sys.path.
4. In a new terminal, prime-agent -p with the same import. It resolves from the skill directory.

Observed twice: with a real skill we use daily (the placeholder text was <unavailable Python skill 'advisor': No module named 'advisor'>) and with the throwaway probe above.

Likely mechanism

The editable install for Python skills lands in the kernel venv at kernel startup (skill-creator docs: install is editable, keyed on a hash of pyproject.toml; we confirmed the .pth appears only after a kernel start). The forkserver template process started before the install, its site processing already ran, and forked children inherit the stale sys.path. New root kernels process the new .pth and work.

A template refresh on skill install (or on pyproject hash change) would close it. Restarting the session or daemon clears it, which is the current workaround.

Related

#1507 shows the same placeholder symptom with a different trigger (compaction and kernel restore). #298 introduced the forkserver.

This surfaced while building an advisor skill; the field report is here: #1924

[snimu]

Addressed by #1685