orchestrate: the slice-executor's skills: preload is unverified, and a miss leaves it with no procedure and no error #375

Slice #360 ships the two slice-executor agent definitions. Each declares skills: orchestrate:slice-pipeline, relying on the skills frontmatter field to inject the pipeline procedure at startup — that injection is the whole reason the ~470-line procedure lives in one skill instead of being duplicated into both definitions. The vendor mirror documents the contract at docs/claude-code/subagents/creating-custom-subagents.md:285: skills to preload into the subagent's context at startup, with "the full skill content injected, not only the description".

A probe series could not confirm the field preloads

During run prd352-20260803-015333, a probe series was run against this contract. The one clean observation: a project-level subagent whose definition demonstrably loaded — its body was in the system prompt and its tools: Write restriction was enforced — declared skills: [tdd] for an enabled user-level skill, and reported that no skill content was in its context. CLI version 2.1.220, above every relevant version floor; the skills field carries no min-version annotation.

Limits of that result, stated honestly. It is a single clean observation, on a project subagent, whereas the claim under test is scoped to plugin subagents. The plugin path could not be tested: plugin agent definitions register only at session start, so probe definitions dropped into the plugin cache mid-session never loaded, and every one of them self-reported inconclusive rather than negative. Five of eight probes in the series were inconclusive for exactly this reason — itself worth knowing, since a probe that does not verify its own definition loaded produces false negatives that read like data.

Why a miss is dangerous

creating-custom-subagents.md:488 — "If a listed skill is missing or disabled, Claude Code skips it and logs a warning to the debug log." So a non-preloading executor launches successfully with no procedure at all, and nothing surfaces it. #360 mitigates this with a body-prose guard instructing the executor to stop and emit a blocked envelope when it cannot see the preloaded procedure, which converts a silent failure into a classified one — but the guard is a safety net, not a verification.

What to do

Verify the preload empirically in a fresh session, where plugin agent definitions register normally: spawn orchestrate:slice-executor-standard and have it report whether the slice-pipeline procedure is in its context. If it is not, the namespaced identifier form or the field's plugin-subagent behaviour needs revisiting, and the delegation layer needs a different mechanism for getting the procedure to the executor.

Note that the two candidate identifier forms — bare slice-pipeline versus namespaced orchestrate:slice-pipeline — cannot be distinguished by trying both: listing both makes the debug log ambiguous, and the miss is silent either way. extend-claude-with-skills.md:108 supports the namespaced form ("Plugin skills use a plugin-name:skill-name namespace"), which is what #360 ships.

Related

• orchestrate: slice-executor agent definitions (standard and deep) with variant parity test #360 — ships the executor definitions that declare the skills field.
• orchestrate: orchestrator spine restructure — delegate the slice, map the failure class #362 — the first slice that actually spawns the executor.