Treat skills as privileged mounts
What enters `capability_directories` is not a shared tip. It is install policy: versioned instructions and scripts that steer planning, tool choice, and shell. Inventory and pin skills the way you already inventory registries, agent docs, and extension allowlists.
OpenAI’s Skills docs say the quiet part out loud. Treat skills as privileged code and instructions. Do not expose an open skills catalog to end users. Map skills to bounded product workflows. Keep arbitrary skill selection out of consumer hands. Gate write and high-impact actions behind approval. That is not productivity advice. That is control-plane language.
In the Agents API, the managed Codex harness discovers skills from sandbox directories you register in environment.capability_directories. Paths must be absolute, unique, already present, and capped at 32. The harness finds each SKILL.md, puts name and description into context, and lets the model load full instructions and supporting files on demand. Hosted Responses skills attach as versioned skill_reference bundles, including an explicit version or “latest.” Local shell mounts a path you control. Either way, a skill is a directory with a manifest plus references, scripts, and assets. Once mounted, it can change what the agent plans and what it runs.
Progressive disclosure does not make the mount safe. Name and description enter context first so the model knows the skill exists. Full SKILL.md and scripts load when selected. OpenAI also warns that skills with network access raise prompt-injection and data-exfiltration risk. A malicious or sloppy skill is not a bad tip. It is untrusted instruction sitting next to shell. Review it like privileged code before the session template goes live.
Microsoft Agent Framework made the same surface visible from another angle on September 16. Tommaso Stocchi’s post migrates ski-resort specialists from Agent-to-Agent loops to distributed skills over MCP. Domain services stay remote. Specialist instructions move into SKILL.md. Operations become typed MCP tools. Reasoning moves to the parent. In their demo traces, wall time dropped about 60 percent while total tokens rose about 22 percent. Fewer nested model loops did not mean thinner context. SEP-2640 skill transport was still drafty at their check: the sample used skill://index.json, while a later revision pointed at skills/list and skills/get. Pin the transport you actually ship.
The useful split is not “markdown good, agents bad.” It is which specialists still need their own autonomous loop, and which are really a competence plus tools. A research agent with private context may stay an agent. Weather conditions and lift wait times can become a skill and MCP tools. Microsoft keeps that hybrid on purpose. OpenAI keeps developer-integrated skills on purpose. Both are saying the same operator thing: installed capability is not a tip jar.
This continues the control-surface series. Issue 7 treated registries as a publish surface. Issue 8 treated agent-facing docs as install policy. Issue 9 treated extension allowlists as agent policy. Issue 10 put System One decisions in the harness. Issue 11 is the mount list itself. A skill is not a helpful markdown tip. It is installed capability that changes planning and execution. Treat mounts like allowlists: owned, version-pinned, reviewed before production.
Inventory these moves before the next session template ships:
- List every directory or path registered as a capability or skill mount, with an owner and a review cadence.
- Pin skill versions in production sessions. Do not float “latest” on hosts that can run shell or network tools.
- Review
SKILL.mdand scripts like privileged code before mount. Gate network-capable skills harder than read-only reference packs. - Prefer developer-integrated skills over end-user open catalogs. Map skills to product workflows, not a free browse.
- Decide which specialists stay autonomous agents and which become skills plus MCP tools. Keep autonomy only where the nested loop earns its cost.
- Log which skill loaded before which tool or shell action, so a bad mount has an owner to page.
If it can steer planning and shell, it is part of the allowlist. Mount it on purpose.