Skills extension phase 3: CLI methods, TUI pane, resources/directory/read, and paginated mode

[cliffhall]

Follow-up to #2234, which lands phases 1 and 2 of the Skills extension (SEP-2640) — capability detection, the Zod wire module, skills/list cursor walking, skills/get, digest verification, the conformance checks, the web Skills tab, and the skills-http.json test-server fixture with its three deliberately non-conforming skills.

Everything in #2234's Acceptance list ships there. This issue is the "Reach" phase that issue names but does not gate on, kept separate so the first PR stays reviewable rather than spanning all three clients at once.

Scope

• clients/cli — skills/list and skills/get through handlers/method-types.ts + handlers/run-method.ts, plus a --verify mode reporting the digest and conformance results. The CLI equivalent of --app-info, and the natural home for a scriptable conformance report.
• clients/tui — a Skills pane, now that the web shape has settled.
• resources/directory/read — the Inspector already reads and surfaces the directoryRead sub-flag in Connection Info (Support the Skills extension (SEP-2640): skills/list, skills/get, and digest verification #2234); everything else is missing and is this issue's work: the result schema in core/mcp/skillsSchemas.ts, the client method, and the UI that walks a directory resource. Support the Skills extension (SEP-2640): skills/list, skills/get, and digest verification #2234 deliberately ships no schema for it — an unexercised guess in the module that is meant to be the authority on the wire format could sit wrong indefinitely without failing anything — so define it against the normative text here, alongside the call that uses it. skills-http.json likewise declares the extension bare; turn directoryRead: true on only once the fixture serves the method, or Connection Info reports "Supported" for something that answers -32601.
• Paginated mode — ManagedSkillsState walks every page on connect. The other lists have a paged counterpart (PagedPromptsState / usePagedPrompts) that drives the sidebar when the paginatedLists server setting is on; skills has none, so that setting does nothing on the Skills tab. Add PagedSkillsState + usePagedSkills if a server with a very large skill set makes the all-page walk a real cost, or decide deliberately that it does not and record why.

Out of scope, deliberately

Host machinery — activation, per-skill consent, content-bound approval, the window during which a host is "acting on" a skill. SEP-2640 is explicit that a resources/read of a SKILL.md is not a load and confers no standing. The Inspector surfaces and verifies; it is not a host. #2234 states the same boundary.

Settle the SEP-2549 caching attributes for skills/get

Half of this is now done in #2234. The skills/list half was settled during that PR's review, which quoted the normative text — "In protocol versions 2026-07-28 and later, the result also carries … ttlMs and cacheScope" — so core/mcp/skillsSchemas.ts now has a ModernListSkillsResultSchema requiring the base list envelope, InspectorClient.listSkills picks it from the negotiated era, and the legacy shape stays permissive.

What is still open is whether a skills/get result carries the same attributes. #2234's GetSkillResultSchema requires only the { skill } envelope and is not era-aware. Read the normative text and either mirror the list treatment (a modern variant selected by era in InspectorClient.getSkill, legacy permissive) or record in the module that skills/get does not carry them.

Note the SDK is no help either way: skills/* are consumer-owned methods, absent from its cacheable-method registry, so nothing stamps or validates these fields. test-servers/src/skills.ts already stamps the full envelope on every skills result, so a modern fixture is available to test against.

Acceptance

• The CLI can run skills/list and skills/get, and a --verify mode reports digest and conformance results.
• The TUI has a Skills pane.
• resources/directory/read has a result schema defined against the normative text, is callable, and is surfaced when the server declares directoryRead: true — with skills-http.json actually serving it.
• The skills/get caching-attribute question above is settled either way, in code or in a comment.
• A decision on paged mode is recorded — either implemented, or the reason it is not.
• Per-file coverage clears the ≥90 gate on all four dimensions.
• Frontmatter cross-check — SEP-2640 requires an entry's frontmatter to match the fetched SKILL.md's frontmatter field by field, and Support the Skills extension (SEP-2640): skills/list, skills/get, and digest verification #2234 deliberately does not check it (the module header says so). The digest cannot cover this: a digest is taken over the bytes the server served, so it proves the file was not altered in transit and says nothing about whether the listing described it honestly. A server can advertise one description, serve another, and pass every check today. Closing it needs a YAML parser — a new runtime dependency and a [Dependency placement] decision of its own, which is why it is here rather than there.