feat(core): implement skills-over-MCP SEP extension

[olaservo]

Draft PR against the fork's main — not proposed to upstream yet.

What this adds

Host support for the Skills-over-MCP SEP (io.modelcontextprotocol/skills). MCP servers can publish skills at skill://index.json (or any <scheme>:// the server chooses); the host discovers them, surfaces them through the existing SkillManager, and lazy-loads the SKILL.md body on activation via resources/read.

Filesystem and MCP-served skills share one namespace, one /skills list view, and one activate-skill tool. A <location> starting with skill:// is the only difference in the model's context.

Where the logic lives

• packages/core/src/skills/mcpSkillDiscovery.ts — new. Reads skill://index.json, validates entries, applies name/description sanitization, returns SkillDefinition[] with source: 'mcp' and empty body. declaresSkillsExtension() checks both extensions (SEP-2133) and experimental capability slots.
• packages/core/src/skills/skillLoader.ts — SkillDefinition gains optional source?: 'mcp' and mcp?: { serverName, skillUri }. Filesystem skills leave them unset.
• packages/core/src/skills/skillManager.ts — new setSkillsForSource(tag, skills) channel for dynamic providers. Two backing stores: localSkills (filesystem) and sourcedSkills: Map<tag, skills[]> (keyed by mcp:<serverName>). Filesystem wins on name collision; first MCP source wins among MCPs; each shadowed skill emits one warning.
• packages/core/src/tools/mcp-client.ts — discoverSkills() slots into discoverInto() after tool/prompt/resource discovery. Gates: admin-enabled, folder-trust, per-server skillsEnabled, resources-or-extension capability. Every short-circuit calls setSkillsForSource(tag, []) so config toggles take effect mid-session. disconnect() clears the slot too.
• packages/core/src/tools/activate-skill.ts — MCP branch fetches the body via resources/read, enforces a 256 KiB cap, rejects frontmatter name drift, XML-escapes every server-derived string, and wraps the body in <instructions trust="untrusted">. Does not call WorkspaceContext.addDirectory() (the filesystem-branch affordance) — granting filesystem read scope based on server-controlled content would widen the agent's blast radius on every activation.
• packages/core/src/tools/mcp-client-manager.ts — findResourceByUri falls back to raw-URI match across all servers. Lets the model emit read_mcp_resource("skill://foo/references/GUIDE.md") with no server-name argument; the host resolves it from the registry.
• packages/cli/src/ui/… — /skills list tags MCP skills [mcp:<serverName>]; /mcp list <server> grows a Skills section.
• packages/cli/src/config/settingsSchema.ts — per-server skillsEnabled, includeSkills, excludeSkills. Merged in mcp-client-manager.ts:mergeMcpConfigs with case-insensitive intersection (include) and union (exclude).

Key design choices

• Discovery is ungated by capability. The TS MCP SDK's ServerCapabilitiesSchema strips unknown extensions keys during parse, so gating on capabilities.extensions["io.modelcontextprotocol/skills"] would silently hide every conforming server using the SEP-2133 slot. declaresSkillsExtension() is logged for observability; skill://index.json is probed on every MCP server regardless.
• Stock read_mcp_resource tool, unchanged. Its description was left at its pre-SEP wording. Testing against the unchanged description stresses the SEP's design ("the tool description shouldn't need to know about skills") rather than host prompt engineering.
• Scheme-agnostic everywhere. The SEP SHOULDs skill:// but permits any URI scheme. Accepted in discovery, registry, activation, and sibling enumeration.
• Server name resolved host-side. ReadMcpResourceTool takes { uri } only; McpClientManager.findResourceByUri resolves the server from the ResourceRegistry fallback.

Trust boundaries

Server-supplied content (names, descriptions, SKILL.md body, sibling URIs) is treated as untrusted model input — XML-escaped on the way to the model, size-capped, control-bytes stripped, and wrapped in <instructions trust="untrusted">. Two non-obvious calls worth flagging:

• WorkspaceContext.addDirectory(...) is skipped on the MCP branch, per the SEP's MUST against local-execution mechanisms from MCP skills without per-skill user opt-in.
• Empty includeSkills is deny-all (matches the existing includeTools contract); cross-config intersection in mergeMcpConfigs is case-insensitive so two configs with intersecting allowlists don't produce [] that accidentally reads as "no allowlist configured."

Testing

• Unit + subprocess integration: 128 tests pass across the touched and new files, including a subprocess-based end-to-end that spins up the in-repo template server and drives the full SEP pipeline.
• Live HTTP smoke (no LLM): scripts/skills-e2e-smoke.js against olaservo/github-mcp-server @ 890ea55 — PASS.
• Live agent activation (gemini-2.5-flash, non-interactive -p): 2/2 first-try successes. Server launched with --read-only, which filters pull_request_review_write and add_comment_to_pending_review out of tools/list entirely — yet the model named both tools (with the correct method: "submit_pending" argument value) in both runs. Those names only appear in the SKILL.md body, making the fingerprint unambiguous proof of skill activation.

Out of scope (follow-ups)

• type: "mcp-resource-template" index entries + completion-API discovery UI
• resources/subscribe for live index invalidation
• Dedicated UI surface for per-skill enable/disable beyond settings.skills.disabled[] + per-server includeSkills/excludeSkills
• Eager-to-filesystem materialization