---
name: motion-video-creator
description: Plan, script, build, and validate original short-form motion videos using sourced ideas, timed storyboards, and code-based animation workflows.
license: MIT
---

# Motion Video Creator

Use this skill to turn a sourced idea or verified audience problem into an original short-form motion video, production-ready storyboard, or reviewed code-built render. It supports silent and narrated work, uses no-camera formats, and can be used with or without HyperFrames.

## When to use it

Use this workflow when asked to research, write, storyboard, build, revise, or validate a short-form motion video. Follow the user's platform and duration constraints. If none are supplied, target 15 seconds or less and keep the video under 20 seconds. Do not force a word-rate target; time an actual read and simplify rushed copy.

## Required inputs

Before drafting, identify:

- Audience, named vertical if supported, and the one problem, curiosity, or useful result.
- Source evidence for the audience problem and each specific claim, number, quote, and product behavior. Distinguish an observed fact, an owner's exact words, an inference, an idea hypothesis, and an illustrative scenario.
- Source post and the abstract mechanism if adapting a successful piece. Record its URL and retrieval date; do not copy its words, footage, sound, identity, distinctive visual expression, or claims.
- Platform, aspect ratio, target duration, audio approach, available motion/B-roll assets, and intended CTA.
- Whether any generated person or voice will appear, and the required disclosure for the destination platform and asset record.

If a critical fact, permission, capability, or destination is missing, mark it **Unknown** and write around it. Never invent a statistic, customer result, testimonial, market claim, source, or product behavior. A like or save is evidence of the researcher's interest, not proof of audience-wide demand.

## Workflow

### 1. Research the viewer's problem

Capture the original source, date, audience, pain in the owner's words when available, visible artifact, consequence, uncertainty, and source/usage rights. If the pain is not yet confirmed, label it a hypothesis and propose how to validate it. A view count indicates attention; it does not prove leads or sales.

### 2. Set one truthful promise

Write one sentence describing what the viewer will understand or be able to do after watching. Keep the promise proportional to the evidence. Choose one problem and one useful next step. Do not start with an AI tool unless the source evidence shows that the tool itself is the viewer's problem.

### 3. Choose one story mechanism

Choose a single dominant mechanism, such as an object reveal, visible before/after, useful-system demonstration, numbered checklist, simple workflow, branching decision, or human handoff. Adapt the abstract mechanism only. Use new wording, examples, design, and proof.

### 4. Write the complete script and timed storyboard

Write the exact opening hook, complete spoken narration or full on-screen transcript, on-screen headline and labels, CTA, and captions. Give every beat start/end time, viewer purpose, exact words, visual action, transition, sound, and source/asset note. Make the premise understandable in the first three seconds and the whole story understandable with sound off.

For narrated video, calculate the spoken word count and estimate its duration using an actual read. For silent video, hold each text block long enough to read comfortably. Reduce copy before speeding delivery. Keep display text short and captions accurate.

### 5. Design the motion treatment

Use motion to clarify the idea. Specify composition, hierarchy, entry/exit, transitions, camera movement, UI/artifacts, captions, sound, and safe areas. Reuse existing assets only after confirming that they are portable and approved for the intended use. Use local fonts for offline rendering. Do not rely on network font imports.

For HyperFrames projects, preserve required composition IDs, `data-*` timing attributes, `.clip` classes, registered GSAP timelines, and existing project conventions. Do not rename selectors or alter timing semantics casually. Run the project's canonical validation command.

### 6. Make the CTA deliverable

Choose one action. If the CTA promises a download, DM, lead capture, comment automation, or email sequence, verify that the asset exists and that the entire destination and delivery path works from a clean test account. Record the test. If it is not verified, use an honest non-delivery CTA or mark the CTA **Draft; destination unverified**. Never describe automation as active without a successful end-to-end test.

### 7. Build with cleared media

Use only owned, licensed, public-domain, or specifically approved video, music, fonts, logos, and images for the intended use. Record source and license/clearance. If footage clearance is uncertain, build the visual in code or hold the clip. Label fictional interfaces and examples **Illustrative example** so they cannot be mistaken for customer evidence.

Never use private customer data in mockups. Do not make a generated person appear to be a real customer or expert. Disclose generated people or voices wherever required by the user, platform, or applicable rules, and record the disclosure in the asset notes.

### 8. Validate and review the render

Run the documented project check, such as `npm run check` for the relevant HyperFrames project. Fix structural errors and triage overflow warnings. Render a review copy and inspect the entire video at full speed and on a phone-sized display. Check:

- First-frame clarity, story comprehension with sound off, caption accuracy, and real-read duration.
- Phone readability, platform-safe areas, contrast, crop, transition continuity, and motion timing.
- Music/SFX rights, narration intelligibility, audio levels, and disclosure.
- Factual claims against cited sources; examples against their labels; CTA against its test receipt.
- Actual render dimensions, frame rate, duration, playback, and remaining issues.

A successful code check is not a visual review. A rendered file is not approval to publish.

### 9. Record evidence and hand off

Return a complete package with paths to editable source and local assets, source URLs and retrieval dates, license/clearance notes, actual validation command and result, render inspection evidence, unknowns, and reviewer. Keep publication approval separate from production approval.

## Required output package

For research or scripting requests, return:

1. **Concept:** audience, verified pain point or explicit hypothesis, one-sentence promise, source, abstract mechanism, and what makes this adaptation original.
2. **Hook and full script:** exact opening line, complete narration/transcript, and CTA.
3. **Timed storyboard:** time ranges, viewer beat, exact speech/captions, on-screen text, motion, transition, sound, and asset source.
4. **Copy check:** word count, actual-read duration or text-reading check, and any lines that remain too dense.
5. **Claim and asset check:** sources, unknowns, illustrative labels, media licenses/clearance, and generated-media disclosure.
6. **CTA check:** action requested, promised asset, destination, delivery-path test, and result; if untested, clearly mark draft.

For build or render requests, include the above plus:

7. **Build files:** exact editable composition and local asset paths.
8. **Validation:** command and actual result, render dimensions/duration, full visual review performed, device/readability check, and unresolved defects.
9. **Publication status:** explicitly identify whether the work is draft, approved for review, or separately approved to publish. Never publish or schedule without explicit authorization.

## Acceptance checklist

- [ ] One specific, sourced viewer problem or clearly labeled hypothesis.
- [ ] Original expression; no copied script, footage, sound, distinctive assets, identity, or unsupported claims.
- [ ] Complete hook, transcript/narration, CTA, timecoded storyboard, motion and sound directions.
- [ ] Timing checked by actual read or comfortable silent reading.
- [ ] Understandable without sound and legible on a phone.
- [ ] Every fictional UI/example is clearly labeled; no fake customer proof.
- [ ] All media has documented rights for the intended use.
- [ ] Generated people/voices are disclosed as required.
- [ ] CTA destination and delivery are verified or clearly left as draft.
- [ ] Project validation passed and the full rendered video received a visual review.
- [ ] Publication remains a separate approval.