Download the kit: client-demo-video.zip. The skill and generator behind the demo in this guide. 42 KB, no audio files inside.
I recently made a short demo video almost entirely by talking to Claude Code.
The video itself was simple: a few interface moments, some typed text, cards moving on and off screen, and a clean closing line. The kind of thing you might normally build in After Effects or hand over to an editor.
Instead, I described what I wanted, reviewed still frames, watched rough renders, and gave notes in plain English:
Slow the opening down.
Make the click feel more deliberate.
The icon is getting clipped in this shot.
That was most of the process.
This guide shows you how to do the same thing. It is not a recipe for one particular video. Think of it as a starting framework for making short product demos, explainers, launch clips, and simple motion pieces in Claude Code.
The basic idea
A video is a sequence of frames. If you can build a frame with HTML and CSS, then animate it on a timeline, you can turn it into a video.
That is what HyperFrames is useful for. You create the visuals as a web page, animate them with GSAP, and HyperFrames renders the timeline frame by frame into an MP4.
Claude Code is good at writing both the layout and the animation. More importantly, it is good at changing them when you say things like:
- “Hold this frame for another second.”
- “Move the headline higher.”
- “Make the transition feel sharper.”
- “Show me the moment before and after the cut.”
You are still directing the video. You just do it through conversation instead of dragging layers around a timeline.
What you need
Three free tools, each installed once:
- Claude Code. The AI assistant you will be talking to. Install it from claude.com/code.
- Node.js (version 20 or newer). This lets your computer run the video tool. Download it from nodejs.org and run the installer.
- FFmpeg. The program that turns the finished frames into a video file. On a Mac, open Terminal and type
brew install ffmpeg.
If any of that feels unfamiliar, ask Claude Code to walk you through it. Installing tools is something it is good at.
Next, make an empty folder for your video. Open Terminal in that folder and paste this line:
npx hyperframes init my-video --example blank --non-interactive
That sets up a blank video project and, quietly, teaches Claude Code how the video tool works. Without that step, Claude would build a normal web animation, which looks fine in a browser but falls apart when it is turned into video.
Now open Claude Code inside that folder. You are ready to start.
If you would rather not do any of that by hand, there is a shortcut. Install Claude Code, open it in an empty folder, and paste this in (every box in this guide has a copy button):
I want to make short videos with Claude Code and HyperFrames. Please:
1. Check whether Node.js 20 or newer and FFmpeg are installed on this computer.
If either is missing, tell me the simplest way to install it and wait for me.
2. Create a blank HyperFrames project here with
npx hyperframes init my-video --example blank --non-interactive
and work inside that folder from now on.
3. Make sure the HyperFrames skills are installed so you know the rules of the renderer.
4. Then ask me for a brief, one question at a time: who the video is for, the one
thing they should understand, where it will be shown, what it should feel like,
and what role sound should play.
5. Turn my answers into a beat-by-beat storyboard and show it to me before building anything.
Claude does the setup, asks you the five questions, and stops at the storyboard so you can read it first.
There is one optional extra. If you sign in to HyperFrames, you get access to their hosted voices, music, stock images, and cloud rendering:
npx hyperframes auth login
You do not need this to begin. Everything in this guide works on your own computer without it.
Start with a brief, not a prompt
You can open Claude Code and say “make me a video,” but you will usually get a better result if you give it a short creative brief first.
It does not need to be elaborate. You just need to answer five questions:
- Who is the video for?
- What is the one thing they should understand?
- Where will the video be used?
- What should it feel like?
- What role should sound play?
Use this template:
Audience:
[Who is watching? What do they already know?]
Main message:
[The one sentence they should remember.]
Format:
[Approximate length, dimensions, and where it will be shown.]
Visual direction:
[Colours, typography, references, pace, and overall mood.]
Sound:
[Voiceover, music, sound effects, or silence.]
Structure:
[A rough beginning, middle, and end.]
For example:
Audience: People seeing this product for the first time.
Main message: A complicated task can be completed with one simple request.
Format: Around 30 seconds, landscape, for a website and LinkedIn.
Visual direction: Warm neutral background, restrained colour, crisp interface cards,
and confident movement. Clean rather than futuristic.
Sound: No voiceover. Light interface sound effects only.
Structure: Show the problem, demonstrate the interaction, reveal the result,
and finish on one clear line.
Ask Claude to turn the brief into a beat-by-beat storyboard before it builds anything. Read that first. Changing a line in a storyboard is much easier than rebuilding a finished scene.
A simple structure for short demo videos
Most short demos do not need a complicated story. This structure is enough:
1. The hook
Give the viewer a reason to keep watching. This might be a question, a familiar problem, a bold result, or the product already in motion.
2. The action
Show the central interaction. Keep it focused. If the important moment is typing a request and pressing a button, let the viewer actually see it happen.
3. The result
Reveal the finished output clearly. Do not rush past the thing the audience came to see.
4. The close
End with one idea: a benefit, a product name, a next step, or a short call to action.
If you have several features to show, repeat the action-and-result section. Change the composition or entrance each time so the video does not feel like the same scene played three times.
The workflow I use
The process is a loop, not a single prompt.
1. Plan the beats
Ask Claude for a short storyboard with timestamps, on-screen text, the main visual in each section, and the intended transition.
Do not worry about perfect timings yet. You are checking whether the story makes sense.
2. Build the first pass
Once the storyboard feels right, ask Claude to build the composition. Keep important timings in named constants so they can be adjusted without hunting through the code later.
3. Check the project
Run:
npx hyperframes check
This catches problems that are easy to miss in a browser preview: elements that disappear when the timeline is seeked, text with poor contrast, content outside the frame, and animations that do not render reliably.
Fix the errors before moving on.
4. Review still frames
Before rendering the whole video, take snapshots at the important moments:
npx hyperframes snapshot --at 3,8,14,21
Choose times that cover the hook, each major reveal, and the closing frame.
This is the fastest way to catch layout problems. Look for wrapped headlines, awkward spacing, clipped badges, weak hierarchy, or anything sitting too close to the edge.
5. Render a draft
When the frames look right, make a low-quality draft:
npx hyperframes render --quality draft --output draft.mp4
Watch it from beginning to end, preferably with sound on. Still frames tell you whether the design works. The draft tells you whether the timing works.
6. Give specific notes
Talk to Claude as if you were giving notes to an editor. Mention the time, the object, and the change you want.
Instead of:
Make it better.
Try:
At 12 seconds, hold the result card for one more second before the next transition.
Or:
The cursor reaches the button too quickly. Slow the final part of its movement, then make the press more obvious.
Specific notes produce specific changes.
7. Render the final version
Only render at high quality once you are happy with the draft:
npx hyperframes render --quality high --output final.mp4
Prompts worth reusing
These are useful because they describe how the video should behave, not what a particular video should contain.
Before building
Turn this brief into a beat-by-beat storyboard before writing any animation code.
For each beat, include the approximate time, the main visual, the on-screen copy,
and how we enter and leave the scene.
Before rendering
Show me snapshots of the opening, every major reveal, and the closing frame
before you render the full video.
For better interaction
Make the interaction readable: move the cursor to the target, pause briefly,
show the press, then reveal the result. Do not let all four actions happen at once.
For typed text
Keep the camera focused on the part of the sentence being typed.
The movement should follow the caret smoothly without making the text hard to read.
For variety
Give each major result a different entrance, but keep the motion language consistent.
The scenes should feel related, not repeated.
For sound timing
Derive every sound cue from the same timing constants as the matching animation.
Do not place audio timings separately by hand.
Before a revision
Save the current working version before making this change so we can compare them.
Sound: use less than you think
Sound can make a basic animation feel finished, but it does not need to be complicated.
For a short interface demo, a small set of sounds is usually enough:
- typing
- a click or tap
- a soft pop when an item lands
- a whoosh for a larger movement
- a light confirmation sound
Use them to clarify what is happening, not to decorate every movement.
Music is optional. It can help a launch video feel energetic, but it can also make a straightforward demo feel like an advertisement. Decide based on where the video will be used.
The important technical rule is to keep sound and motion tied to the same timings. If the click moves, the click sound should move with it.
Common problems
A few issues come up repeatedly:
- An element that starts hidden needs an explicit visible end state.
- Masks and clipping paths can accidentally cut off shadows, badges, or icons.
- Audio elements need clear IDs and durations.
- Avoid applying CSS transforms to elements that GSAP is also transforming.
- Check text contrast instead of trusting how it looks on your screen.
- Use fonts that will still be available when the video renders elsewhere.
- Use fictional names, addresses, and customer data in public demos.
- Keep text short enough to read at the speed of the final video.
The project checker will catch some of these. Snapshots and draft renders will catch the rest.
The part that still needs you
Claude can build the scenes, write the animation, move timings around, and fix a surprising number of visual problems. What it cannot decide for you is what deserves attention.
You still need to choose the message, remove anything the viewer does not need, and decide when a moment feels rushed or flat.
That is the real job: not moving every layer yourself, but directing the viewer's attention.
Start here
Pick one short video you genuinely need. Keep it under 30 seconds for your first attempt.
Write the brief using the template above. Ask Claude for the storyboard. Review a few frames before you render anything. Then make one rough version and give it concrete notes.
You do not need to understand every line of the animation code before you begin. You need a clear idea, a simple visual system, and the patience to make two or three passes.
That is usually enough to get from a blank folder to something worth showing.
— Alex Sidhu