leosssvip-dot/remotion-ad-video-skill/remotion-ad-video

Remotion Ad Video

Overview

Use this skill to make performance-oriented ad videos with an AI agent plus a deterministic code renderer. The agent owns the creative and production workflow. Remotion is the default renderer; Hyperframes is supported when the user asks for HTML-based video authoring or an existing Hyperframes project.

When To Use

Use for:

• Product link to 15s ad video by default, or 30s/45s only when the user asks for a longer format.
• Google Play, App Store, SaaS, or landing page to product explainer ad.
• Batch variants for TikTok, Reels, Shorts, Meta square, or YouTube landscape.
• Turning a product brief into a script, storyboard, Remotion props or Hyperframes variables, and render QA checklist.

Do not use for:

• Long-form editorial videos where ad conversion is not the goal.
• Genuinely off-limits assets: licensed/third-party music, celebrity or identifiable-person likeness, or paid stock/fonts you do not have rights to.
• Regulated medical, financial, legal, or earnings claims unless the user supplies approved copy.

Asset and claim policy (default to pragmatic, not restrictive):

• This skill makes ad creative for advertisers running paid campaigns (performance/UA/affiliate/agency), not the product's internal staff. Treat the product or app's own public assets as standard creative inputs: store icon, screenshots, feature graphic, Open Graph image, logo, and brand colors. Harvest and use them by default. Do not stall the job waiting for "rights confirmation" on public store assets.
• Public store metrics — rating, downloads, review count — are usable. Use the real numbers, attributed to the store (e.g. "Google Play 4.0★, 10M+ downloads"). Never fabricate or inflate a number.
• The advertiser owns final trademark, comparative-claim, and licensing decisions for their channel. Flag any residual responsibility in the handoff; do not gate the build on it.
• Generated placeholders are a fallback for genuine gaps (e.g. you cannot reliably isolate the right screenshots), not the default. Prefer real harvested assets.

Core Workflow

1. Intake

Collect only the source material needed for the ad. For URLs, inspect the live page when tools are available; otherwise ask for product name, target customer, core offer, screenshots, logo, and brand constraints.

Load references/ad-intake.md when source quality, claim safety, or asset rights are unclear. Load references/ad-brief-contract.md for every URL job before storyboard or code. Create or update ad-brief.json after source classification and keep preflight answers/defaults there. Load references/asset-harvest.md for URL-based jobs before writing the storyboard. Load references/fast-test-workflow.md for skill tests, first-pass iterations, or when the user cares about speed. Load references/hyperframes-output.md when the user asks for Hyperframes, the target repo already uses Hyperframes, open-source renderer licensing is a priority, or ad-brief.json has renderEngine: "hyperframes". Load references/preflight-questionnaire.md for URL-only jobs before storyboard or code. Ask exactly two required preflight choices first: format and creative route. Only skip questions when the user explicitly asks for no questions, fastest possible defaults, or a benchmark run with inferred defaults. Ask optional follow-ups only after those choices, and only when they materially change the ad. Load references/platform-presets.md when the user needs to choose vertical, square, or landscape output. Load references/industry-angle-library.md when the product category is not obviously covered by games or social-feed patterns. Load references/game-ad-patterns.md for casual games, mobile games, app-store game listings, puzzle games, hypercasual games, or simple gameplay loops. Load references/social-feed-ad-patterns.md for short-video, social, creator, UGC, live shopping, community, or content-feed apps. Load references/variant-system.md when the user wants options, batch ads, or a commercial-quality ad rather than a single sample. Load references/motion-language.md before implementing motion in either engine; it is the ease, stagger, and kinetic-typography vocabulary (Remotion src/motion.ts + KineticText, or GSAP for Hyperframes) that keeps motion from defaulting to flat linear interpolation.

Language policy:

• Ask user-facing preflight questions in the user's current interaction language. If the user is chatting in Chinese, ask the format and creativeRoute questions in Chinese even when the source URL is English.
• Detect the source/link language from the harvested title, description, screenshots/listing copy, or page text. Generate video script, captions, CTA, and on-screen copy in that detected source language by default.
• Record interactionLanguage, sourceLanguage, and outputLanguage in ad-brief.json. Only change outputLanguage when the user explicitly asks for a different video language.

Required decisions:

• Product or app name.
• Target customer and pain point.
• Size preset and exact dimensions: vertical, square, or landscape unless a platform-specific format is supplied.
• Duration: default 15s for short-form ads; use 30s or 45s only when the brief needs explanation depth or the user requests it.
• One primary conversion goal.
• Usable assets and rights status.
• Remotion license suitability for the intended commercial use.
• Render engine: resolve in this order: explicit user/caller choice, existing target project stack, then local renderer availability. If both Remotion and Hyperframes are available, ask which to use. If neither is available, recommend choosing one to install.

Recorded defaults, not required user decisions:

• Audio mode defaults to sfx-only for quick URL jobs, fast tests, and first-pass iterations. Commercial-quality, batch, or "make it more creative" requests default to a full soundscape — music-sfx plus a scripted voiceover — without asking. A bold ad with no voice and one repeated click sounds thin. Still ask only if the user requests silent-safe, a specific music plan, or a platform-specific sound plan.

Minimum URL jobs must attempt to harvest favicon, touch icon, Open Graph image, visible logo or screenshots, and brand colors. Ecommerce product URLs must also attempt a product main image with scripts/harvest-ecommerce-assets.mjs before creative work starts; the linked item is the ad subject, and platform/store context stays secondary. Store usable public assets locally in the generated project public/<brand>/ folder, create or update an asset manifest when practical, and reference assets with staticFile().

Run scripts/classify-ad-source.mjs for URL jobs before creative work, passing --interaction-language <current-user-language> when known, --project-dir <target-project> when working inside an existing project, and --render-engine remotion|hyperframes only when the user explicitly chose one. Otherwise let --render-engine auto detect the engine. Write its output to ad-brief.json when a project directory exists. The brief is the source of truth for source type, language plan, render engine, render-engine reason, preflight defaults or answers, format, audio mode, blockers, and asset requirements. If ad-brief.json has blockers, includes preflight_answers_required, render_engine_choice_required, render_engine_install_required, or assetPlan.status is blocked/user_required, stop and ask for the missing decision or asset. Use interactionPlan.choiceQuestions for the first creative preflight step: ask only format and creative route first, in interactionLanguage. If the agent supports structured choice UI, present the choices there; otherwise use a text fallback with the same options. Audio defaults to audible synced SFX; ask about audio only when the user requests silent-safe, music, voiceover, or a platform-specific sound plan. Do not front-load the longer open-question list. Use --preflight-mode defaults only when the user explicitly approved skipping questions.

2. Strategy

Pick one primary ad angle before writing scenes. Load references/creative-direction.md before implementation to avoid static slide-deck output. Start from an insight (the one true customer tension or surprising approved fact), not from the template.

• Pain-point hook: problem first, product solves it.
• Demo proof: show the product or app doing the work.
• Offer conversion: discount, trial, bundle, or deadline.
• Social proof: rating, review, result, or usage proof.
• Comparison: before vs after or old way vs new way.
• Gameplay spectacle: imitate the high-energy core loop for simple games instead of explaining features.
• Feed-native spectacle: imitate fast swipe, creator clips, live/shop overlays, comment/like rails, and sound-reactive cuts for social or short-video apps.

Tag claims as observed (on-page facts plus public store metrics like rating, downloads, and review count), user_supplied, inferred, or blocked. Render observed and user_supplied freely — including real public store numbers attributed to the store. Do not render inferred or blocked numbers, and never fabricate or inflate a figure.

Every real commercial sample needs a thumb-stopping visual idea, not just copy. Examples: chat bubbles becoming completed tasks, before/after workflow collapse, a product screenshot exploding into features, or a terminal command triggering visible automation.

Every concept also needs a bold layout idea before storyboard or code: poster-scale type, one dominant visual, asymmetric composition, aggressive crop, oversized product/app frame, kinetic split screen, or a staged reveal. Avoid neat centered slide layouts unless the contrast or motion makes them feel like an ad.

Default to bold. A tasteful, restrained, presentation-safe ad loses the scroll. Push each concept past comfortable: dramatize the feeling with at least one spectacle move (surreal-scale, impossible-physics, world-bend, hyperbolic-before-after, maximal-kinetic-burst, dramatized-stakes, ui-comes-alive, or time-break — the spectacleMove enum) so there is a "wait, what?" beat. Exaggeration lives in the visual and emotional register only — every numeric and factual claim stays honest and source-backed. Load references/creative-direction.md (Bold By Default) and references/ad-exemplars.md (Spectacle / Exaggeration Mechanics) for the mechanics.

When source-backed numeric proof exists, plan it as motion instead of static copy: ratings count up, discounts snap from 0 to the final percent, prices or savings roll into place, download/review counts tick upward, and scores burst like a game HUD. Use the exact approved number as the final value and never animate unsupported or inflated claims.

For simple games, especially app-store listings, the visual idea should usually be a gameplay-style simulation: falling pieces, swaps, merges, collisions, score pops, explosions, level-up moments, near-fail rescues, or reward cascades. Static screenshots alone are proof assets, not the ad.

For short-video, creator, or social-feed apps, the visual idea should usually be a feed-native simulation: a phone frame that scrolls or swaps content, creator imagery, UI rails, sound/effect stickers, LIVE or Shop chips when source-supported, and quick cuts that feel like the platform itself rather than a product explainer.