A useful product demo shows someone where to click, what happens next, and why the result helps them. Making one means deciding what to show, recording the interaction, and giving each moment enough time to read.
If you’re preparing a demo with Ditto’s video-authoring skills, you can now choose Hyperframes or Raea for the composition. You can make a walkthrough with visible clicks, create a looping GIF for a presentation, or revise a close-up while keeping the rest of your deck intact.
These skills guide coding agents working in Ditto’s video studio. They are the authoring workflow our team uses to prepare demos; using them requires the coding workspace and the chosen renderer. Here’s how to approach a piece with the updated skills.
Start with the action you want to teach
Give your coding agent a brief that describes the viewer’s job and the result they should recognize. For example:
Use the ditto-demo-video skill to prepare a short walkthrough of this screen. Start with the full interface, show the click that opens the menu, then focus on the field being edited. Hold the completed result long enough to read. Make a looping GIF for the recording deck and preserve the editable source.
That brief gives the demo a sequence: context, action, result. The skill asks the author to show the navigation entry before a close-up, mark the first click, and show the menu or modal it opens. A viewer can follow the path instead of seeing a field appear without context.
For a walkthrough of the app, verify the interaction in the simulator before capturing it. A faithful illustration can also explain an interface, provided you label it as an illustration. Keep that choice clear in the deck and narration.
Choose the renderer for the piece
For a new demo without a renderer preference, the workflow starts with Hyperframes. You can ask for Raea when you want to author with it or when its native 3D or footage workflow suits the composition.
| Your starting point | How to proceed |
|---|---|
| A new walkthrough with no renderer preference | Start with Hyperframes, the default in the skills |
| A composition you want to author with Raea | Name Raea in the brief and use its current authoring instructions |
| A revision to an existing demo | Keep the renderer the project already uses |
| A plan to change an existing demo’s renderer | Treat the change as a source migration and review the result |
Hyperframes provides HTML composition authoring. The skills retain the studio’s existing capture, voice, and render workflow for it.
Raea documents React and TypeScript composition authoring with a native GPU renderer built on Bevy. The skills point authors to its current repository and instructions for rendering a video, inspecting a frame, and checking the output. Raea’s renderer runs without a browser; recording a real simulator interaction and reviewing Slides playback still involve their own tools.
The choice applies to the source project. It doesn’t add a renderer switch inside the Ditto app, convert an existing composition, or automatically send a failed render to the other engine. Raea’s upstream documentation describes a canary release, so check the version and current instructions before authoring. This release adds the authoring guidance and selection support; we haven’t measured a speedup between the renderers or validated a finished Raea production demo through this change.
Revise the part that needs work
A demo often needs a second pass: a click is hard to see, a field is too small on the slide, or the final answer disappears before the presenter finishes speaking.
You can give a focused revision brief:
Revise the field-entry GIF in this deck. Keep the opening view and the other GIFs. Make the first click visible, enlarge the field text in the close-up, and extend the final hold. Use the project’s existing renderer and check the loop in Slides.
The updated workflow keeps the renderer choice with the project. Your agent should use that choice when revising the piece, rather than changing tools as a side effect of an edit. Keep the composition, assets, master video, and GIF settings together so the next revision has a starting point.
Check what the viewer will see
Review the encoded GIF itself. Watch the click, the opened state, the typing, and the reset at the loop boundary. Then play it in the presentation at the size the audience will see. A readable source composition can become a tiny field when the slide scales it down.
Leave room for captions in the final video frame. Keep essential labels, controls, and the presenter’s face above the area where captions will appear. Check the longest cues and transitions, since those are the moments most likely to cover something useful.
With either renderer, the goal is a demo someone can follow: they can find the starting point, see the action, and read the result. Start with that sequence, choose the tool for the piece, and keep enough source material to improve it after the first viewing.