docs(skills): route /slideshow as a workflow, not a domain capability

[WaterrrForever]

What

Moves /slideshow out of the /hyperframes capability map (the on-demand
domain skills) and into the intent router as a top-level workflow. Adds its
cheat-sheet row, a disambiguation bullet, and the per-workflow detail block, so
/slideshow is described consistently in all three places the router lists a
workflow. Skill-content only — one section set in skills/hyperframes/SKILL.md,
no code.

Why

/slideshow sat in the capability map beside the atomic /hyperframes-*
ingredients (core, animation, creative, media, cli, registry), but it isn't an
ingredient: it's an intent-gated orchestration that produces a deliverable —
a navigable deck. It even confirms intent ("do you want this as a HyperFrames
slideshow?") before authoring, which is router behavior, not capability
behavior. The bare slideshow name also read like a workflow next to the
namespaced domain skills.

Surfacing it in the router forced the framing to be honest: a workflow need
not output a video. The router was worded around "make me a video", yet
/remotion-to-hyperframes already produces a composition (migration, not
creation) and /slideshow produces a deck. The intro now says so explicitly.

How

• Capability map — removed the /slideshow row; the map is back to pure
  on-demand ingredients.
• Routing intro — one sentence: most workflows produce a video; /slideshow
  builds a navigable deck and /remotion-to-hyperframes ports a composition.
• Workflow cheat-sheet — added a /slideshow row (output is a deck, not a
  rendered video).
• Disambiguation — added a bullet for the deck-vs-video intent, noting the
  skill confirms before authoring.
• Workflow details — added the ### /slideshow block (Input / Output /
  Triggers), matching every other workflow entry.

Scope

Skill-content only — skills/hyperframes/SKILL.md, no package code. oxfmt +
commitlint clean. Branches off current main. /slideshow's own skill file is
untouched.

🤖 Generated with Claude Code

[miga-heygen]

Clean, well-motivated reclassification. The reasoning is solid — /slideshow produces a deliverable (a navigable deck), which is workflow behavior, not an atomic capability ingredient. Moving it to the router alongside the other workflows is the correct home.

A few things I like:

1. Honest framing — the router intro now explicitly acknowledges that not all workflows produce a video (/slideshow → deck, /remotion-to-hyperframes → migration). That makes the mental model more accurate.

2. Consistent structure — the /slideshow entry in the cheat-sheet, disambiguation, and detail block all follow the exact pattern of the existing entries. No format drift.

3. Smart disambiguation — the bullet distinguishes explicit "slideshow" requests (proceed directly) from adjacent triggers like "deck / slides / presentation" (confirm first, then switch if it's not actually a slideshow). That prevents false positives without adding friction to the happy path.

4. Alphabetical ordering preserved — /slideshow slots in between /music-to-video and /general-video in both the cheat-sheet and the detail blocks, keeping /general-video as the catch-all anchor at the bottom (before /remotion-to-hyperframes).

No issues found. LGTM.

Review by Miga

[jrusso1020]

LGTM pending James's stamp call — clean docs-only recategorization, framing is correct per source.

Verified the move against the actual /slideshow skill at skills/slideshow/SKILL.md:

• Intent-gated: the skill's "Intent confirmation" section explicitly defines the pause-and-confirm pattern ("Do you want this as a HyperFrames slideshow?") for adjacent triggers — exactly the router-shaped behavior the body cites.
• Produces a deck, not a video: skill describes the output as "a normal HyperFrames composition … with one extra ingredient: a JSON island … the player's SlideshowController reads the island and turns the continuous GSAP timeline into a discrete, navigable deck."
• Not an atomic ingredient: every other entry in the capability map (/hyperframes-core, /hyperframes-animation, /hyperframes-creative, /hyperframes-media, /hyperframes-cli, /hyperframes-registry) is a domain-namespaced building block loaded on demand inside a workflow. /slideshow was the only bare-name entry, and it's an orchestration that produces a deliverable. Moving it to the workflow router is the right shape.

Diff itself:

• Capability-map row removed cleanly (the table is now homogeneous: pure on-demand ingredients).
• Workflow cheat-sheet row added with consistent shape (path → one-line role).
• Disambiguation bullet added, mirroring the skill's intent-confirmation behavior.
• Per-workflow detail block follows the same Input/Output/Triggers structure as /general-video, /music-to-video, etc.
• Router intro updated honestly: "most workflows produce a video; /slideshow builds a navigable deck and /remotion-to-hyperframes ports a Remotion composition" — exposes the existing truth that not every workflow outputs an MP4.

8 LOC, single file, CI green. No issues.

Stamp posture: COMMENT only — WaterrrForever is an external contributor (not in trusted-stampers list); routing through James per the customer-partner-PR discipline. James's call on stamp.

— Jerrai

[jrusso1020]

LGTM — greenlit by James.