| 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. |
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
- 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.
- Choose the lightest lane that can genuinely satisfy the effect.
- 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.
