presentation-motion-stack

name	presentation-motion-stack
description	Route HTML presentation animation work to the right lane. Use when the user wants stronger web animation, richer scrollytelling, 3D-like presentation effects, or needs to decide between DOM-first motion, special engines, and video/export tooling.
compatibility	opencode

Presentation Motion Stack

Purpose

This skill prevents animation work from collapsing into random tool shopping.

Use it to decide which lane the task belongs to before implementation:

• default live presentation lane
• special-effect lane
• video and export lane

Default Decision Order

1. Identify the deliverable.
   • If it must work as a live HTML presentation page, stay DOM-first unless proven otherwise.
   • If it must render to video or become a scene-by-scene export pipeline, move toward the video lane.
   • If the task is a single high-impact moment that the default lane cannot plausibly express, evaluate the special-effect lane.
2. Choose the lightest lane that can genuinely satisfy the effect.
3. Define fallback behavior before approving the motion direction.

Lane Matrix

1. Default live presentation lane

Use for:

• PPT replacement pages
• explainable long-form presentations
• chapter pacing and staged reveal
• scroll-driven section direction
• attachment entry feedback and modal rhythm

Preferred stack:

• GSAP + ScrollTrigger for meaningful pacing, pinning, scrubbing, and staged reveal
• CSS scroll-driven animations for low-complexity native enhancement and graceful degradation

Guardrails:

• Keep the main content readable without motion.
• Avoid multiple primary motion runtimes on the same live page.
• Do not default to smooth-scroll hijacking.
• Reduced-motion and mobile fallback are mandatory.

2. Special-effect lane

Use only when the default lane is not enough.

Typical tools:

• Rive for reusable interactive vector assets and state-machine-like UI motion
• PixiJS for GPU-heavy 2D graphics, particle-rich infographics, and canvas-led scenes
• three.js for true 3D space, camera moves, and WebGL scenes
• Theatre.js when director-style sequence authoring and timeline editing are central to the task

Guardrails:

• Treat these as opt-in specialists, not the new default.
• Keep them isolated to the scene or module that actually needs them.
• Do not let a special engine become the only way the audience can understand the content.

3. Video and export lane

Use for:

• renderable video scenes
• repeatable export workflows
• timeline-first compositions
• prompt-to-video or editor-like flows

Preferred stack:

• Remotion and the existing Remotion-oriented skills in this repository

Guardrails:

• Do not force the live HTML page to inherit the video runtime.
• Keep export tooling separated from the shared live-page runtime.
• Validate both preview behavior and render behavior.

Existing Skills To Reuse

• claude-typer
• light-spotlight-render
• procedural-fish-render
• remotion-3d-ticker
• remotion-vinyl-player
• ruler-progress-render
• svg-assembly-animator
• wechat-2d-render

Output Expectations

When you use this skill, the resulting recommendation should explicitly state:

• chosen lane
• why the lighter lane is insufficient, if escalating
• fallback plan
• validation slice
• whether the work belongs in src/, versions/, or a standalone skill

Red Lines

• Do not escalate to 3D or canvas-first architecture just because the user asked for “better animation”.
• Do not introduce multiple competing default motion stacks.
• Do not make live presentation comprehension depend on WebGL, video playback, or a fragile network path.