html-to-interaction-prompts

name	html-to-interaction-prompts
description	Convert a supplied HTML page or generated HTML reference into a screenshot-backed article containing multiple reusable interaction prompts. Use when the user provides an HTML file, exported page, generated-page.html, or local/live reference and asks to extract animation/interactions, create prompts, capture screenshots for each prompt, add them to an article, or commit the resulting article/assets.
allowed-tools	Bash Read Write Edit Glob Grep WebFetch
compatibility	Authored for Codex CLI workflows; portable to any agent with filesystem and shell access. Some steps need the tool named in the skill body (browser capture, ffmpeg, Gmail, X/Twitter, ElevenLabs).
license	MIT
metadata	{"tags":"html, interaction, prompts, mengto-skills, codex-workflow","version":"1.0","source":"https://github.com/MengTo/Skills/tree/main/agent-skills/codex/html-to-interaction-prompts"}

HTML To Interaction Prompts

When to use this skill

• Use when the user provides an HTML file, exported page, generated-page.html, or a local/live reference and asks to extract its animations/interactions.
• Use when the goal is a screenshot-backed article containing multiple reusable, brand-agnostic interaction prompts (core idea, technology, implementation, interaction, success).
• Use for the daily UI inspiration capture workflow that requires exactly 5 inspirations, each with a still image, an embedded local MP4, motion frames, source metadata, and one detailed AI-builder prompt.
• Use when capturing and organizing screenshots/videos per prompt, including full-page scroll screenshots with contiguous section crops for live websites or Framer templates.
• Use when deciding which animation library or API (CSS, IntersectionObserver, Framer Motion, GSAP ScrollTrigger, Lenis, Embla/Swiper, Rive/Lottie, Three.js) to recommend inside a prompt, or when creating/updating the target article and committing only the intended assets.
• Do not use this skill for general web development, unrelated content authoring, or repo-wide commit work — route those to standard development workflows; this skill is scoped to converting an HTML reference into an interaction-prompt article.

Goal

Turn an HTML reference into an article-ready prompt pack: identify the important interactions, capture the right visual evidence, write flexible prompts, insert screenshots under each prompt title, verify the article renders, and commit only the intended files.

Daily UI Inspiration Capture Contract

When this skill is used for a daily UI inspiration workflow:

• Each daily inspiration article must contain exactly 5 inspirations, not 20.
• Do not ship a screenshot gallery or append 20 shallow prompts.
• Each of the 5 inspirations must include a representative local still image, an embedded local MP4 video, multiple local screenshots or motion frames, motion/interaction notes, source metadata, and one super detailed AI-builder prompt.
• If the source is a Framer template or any other live website, record the actual landing page or preview URL while scrolling through the website itself. A marketplace cover image, thumbnail, screenshot pan, or static asset slideshow is not acceptable live-video evidence.
• For Framer, inspect the marketplace detail page for Full Live Preview or the embedded previewUrl, save that URL as pageUrl, and record the MP4 from that page.
• For live websites, save one full landing-page scroll screenshot as a single tall image. Then cut section-by-section screenshots from that exact full image so the article includes both the whole page and each section separately.
• Section crops must be contiguous and pixel-complete relative to the full-page image. Do not miss pixels between sections, do not use arbitrary viewport screenshots as section substitutes, and only allow overlap when sticky elements make it unavoidable.
• Include as many section crops as the page has meaningful sections. At minimum include the hero, each major middle section in page order, and the footer. Use purpose-based labels when possible, such as proof, features, process, gallery, pricing, faq, or final-cta; otherwise use ordered labels like section-02.
• In content.md, match the established daily capture article structure from recent examples. Use ### Full-Page And Section Evidence, render the full-page screenshot as a normal Markdown image, then use #### Section Crops and render each crop as a normal Markdown image in top-to-bottom order. Do not rename this block to Local Evidence, do not use text links, filename lists, Markdown tables, raw HTML grids, or crop-coordinate captions for this block.
• Do not put crop-coordinate captions under screenshots in content.md; keep crop coordinate details in manifest.json.
• Extract multiple motion frames from the live website video. The frames should show real page states across scroll, not repeated crops of the same cover image.
• If live capture is blocked, prefer replacing the candidate with another live website. Only create a local fallback video from still evidence when replacement is impossible or the source is image-only, and state the fallback reason in and .

Workflow

1. Inspect the real source first.

   • Read the HTML, CSS, and scripts. Search for interaction terms such as mousemove, pointermove, canvas, webgl, ScrollTrigger, requestAnimationFrame, hover, sticky, pin, parallax, magnetic, glow, shader, and animation.
   • Treat source behavior as truth. Do not infer exact effects from a screenshot alone when the HTML is available.
   • Check the current git status before editing. Dirty worktrees are normal; keep staging narrow.

2. Decide the prompt list.

   • Split prompts by reusable interaction idea, not by implementation line count.
   • If one user bullet contains two distinct effects, split it only when that makes the article more useful.
   • Name each section by the interaction concept: for example, Hero Particle Field That Follows The Mouse, Cursor Glow Hover On Cards, or Scroll Behavior And Section Reveal System.

3. Write reusable prompts.

   • Keep prompts flexible enough for any brand, color system, card size, layout, or content model.
   • Focus on core idea, technology, implementation shape, interaction behavior, scroll choreography, performance, and accessibility.
   • Avoid hard-coded values unless the user explicitly asks for exact recreation. Do not lock prompts to one color, one size, one threshold, one DOM id, one card type, or one asset.
   • Prefer this structure:
     • Core idea
     • Technology
     • Implementation
     • Interaction
     • Success
   • For landing pages, expand the structure with a Section anatomy block. For each section, include:
     • Purpose: what the section must do in the story, trust-building, or conversion path.
     • Layout: grid, column behavior, media placement, sticky regions, card structure, CTA placement, spacing, and responsive collapse.
     • Visual details: typography, color behavior, surfaces, borders, shadows, media treatment, iconography, and density.
     • Animation: initial state, trigger, easing, duration, stagger, transform origin, opacity, blur, clip/mask, parallax depth, looping behavior, and settled state.
     • Interaction: hover, focus, tap/click, active/pressed, cursor, accordion, carousel, form, keyboard, loading, disabled, and error states.

Prompt Style Rules

• Make prompts portable. Say "derive colors from the page theme" instead of naming one color.
• Make sizing adaptive. Say "scale density to the layout and device" instead of naming one particle count or card size.
• Make interaction clear. Describe how it should feel, what drives it, what data is measured, and how it settles.
• Make implementation practical. Name likely APIs and libraries, but allow the project's existing stack to win.
• Include reduced-motion and performance notes for animation-heavy prompts.
• Keep screenshots as evidence for the motion idea, not as exact style specs.

Library Guidance

• Name a library only when it helps the builder choose an implementation path. Prefer the project's existing stack over adding a new dependency.
• Use CSS transitions/keyframes for simple hover, focus, opacity, transform, color, underline, background, and looping decorative states.
• Use IntersectionObserver or the Web Animations API for lightweight reveal-on-scroll when no timeline control is needed.
• Use Framer Motion or Motion One for React component entrances, layout transitions, shared element transitions, staggered lists, modals, drawers, and state-driven UI motion.
• Use GSAP with ScrollTrigger for complex scroll work: pinned sections, scrubbed timelines, multi-layer parallax, image-sequence scrubbing, masked text reveals, background transitions, and precise section handoffs.
• Use Lenis only when smooth scrolling materially supports the scroll choreography; do not add it as generic polish.
• Use CSS scroll-snap first for simple horizontal strips. Use Embla, Keen Slider, or Swiper when carousel controls, looping, drag physics, or responsive slide logic are needed.
• Use Rive or Lottie for authored vector/interface animations that need designer-controlled timelines. Pause or simplify them offscreen.
• Use Three.js/WebGL only for real 3D, shader, particle, or canvas scenes. Cap pixel ratio, pause offscreen, reduce density on mobile, and provide static fallbacks.
• Use CSS position: sticky for simple sticky panels. Use GSAP pinning only when the section needs timeline control, scrubbed values, or multi-element handoff.
• Every animation plan must include prefers-reduced-motion, touch-device behavior, keyboard/focus behavior, and performance constraints.

References

• Upstream source: MengTo/Skills — html-to-interaction-prompts
• agents/openai.yaml — bundled OpenAI agent interface metadata for this skill