[gaord]

What

GET /v1/skills/{name} returns one skill's SKILL.md body plus the routing metadata around it (source, invocation, aliases, bundled_tier, enabled).

Why

A skill is its body, and no route served it. /skill <name> works in the TUI because the body is already in the process; a client outside it — the VS Code GUI — could list skills and toggle them but not activate one, so the same /skill <name> meant "switch this on" there and "apply this now" in the terminal. This is the read that closes that gap without moving activation into the engine: the client composes the same instruction the TUI composes.

Details

• Discovery is the listing's own walk, so a name the listing shows resolves here; an alias resolves to the canonical body.
• Plugin skills serve from the content-bound snapshot: authority re-verified per request (PluginActivationCapability::Skills), workspace checked, and no mutable on-disk path in the response.
• A native skill whose SKILL.md has since been deleted answers 404 rather than serving the instructions it cached at discovery.
• GET /v1/skills rows gain invocation, aliases and bundled_tier, so a picker or autocomplete needs no second request per row. Both routes build their row through one helper, so the listing and the detail cannot drift; the curated tier is reported only where is_bundled is true.
• Advertised as capabilities.skill_detail on GET /v1/runtime/info. Clients should feature-detect rather than probe: a 404 here means "no such skill" and cannot be told from "no such route". (GET /v1/skills/install does answer 405, but that only proves the install route.)

Trust boundary

This route hands a skill body to a client, so it is worth a maintainer's eye: it reuses the existing authority checks (plugin receipt/trust/enablement, workspace containment) and adds no new surface, and it never returns a plugin's mutable path. Flagging it rather than assuming, per CONTRIBUTING.

Tests

• skill_detail_returns_body_and_routing_metadata — body, invocation, aliases, path, and alias lookup
• skill_detail_404s_for_unknown_skill
• skill_list_rows_carry_routing_metadata
• listed_tier_belongs_to_the_bundled_copy_only — fails against the previous tier logic (it reported tools for a non-bundled copy)
• runtime_info_advertises_skill_detail_capability
• the existing auth test now also covers GET /v1/skills/{name} (401 without a token)

Verified on this branch: rustfmt --check clean on the touched files; cargo clippy -p codewhale-protocol -p codewhale-tui --all-features --locked -- -D warnings -A clippy::uninlined_format_args -A clippy::too_many_arguments -A clippy::unnecessary_map_or -A clippy::collapsible_if -A clippy::assertions_on_constants clean; runtime_api::tests::skill* 23/23 green; and an end-to-end run of the built binary over HTTP (detail + alias, 404, 401, list metadata, audit, capability flags).

No CHANGELOG entry, per CONTRIBUTING.

No-Issue: Expose the existing reviewed skill body through the authenticated Runtime API.

[Hmbown]

yes thank you!!! this is so wonderful