adom-video-post

The AI-driven studio for finishing demo videos. Capture a demo as a series of clips, then review every snippet, flag and re-record the weak ones ("clip 3 is awful, redo it with…"), speed up the dead air, narrate, mux + auto-level the audio, validate the final cut, and publish to the wiki, driven end-to-end by your AI, no DaVinci Resolve.

The Review / Narrate / Publish phases live behind one tab. Narrate over the sped-up cut with a 3-2-1 countdown, then auto-level the audio:

Slow sections become labelled timelapses with a clear on-screen banner so the viewer always knows what was happening:

Why this exists

We are building a lot of demo recordings of Adom apps, skills, molecules, libraries, and datasheets. Every recording follows the same pattern:

1. Start a Hydrogen screen recording
2. Walk through a sequence of steps where Claude Code drives the workflow on the user's behalf (open a file, run a search, export gerbers, pull files back to Docker, etc.)
3. Stop the recording and upload it to the Adom Wiki for the artifact you were demoing

This works, but the videos that come out the other end are unwatchable. 80% of the runtime is dead air, the viewer staring at unchanged screens while Claude Code waits for a Fusion 360 export to complete, or while the Fusion cloud BFS walker enumerates folders, or while a 30-second AI tool call processes in the background. A 12-step demo turns into a 5-minute video where most of the time nothing visible is happening, even though the AI is doing real work the whole time.

We tried recording with manual edits afterwards. Manual editing is slow, requires a separate video tool, breaks the "Claude Code drives the demo end to end" workflow, and is the kind of work no Adom user signed up for. The team should be able to record a demo and end up with a polished video without ever opening DaVinci Resolve.

We also tried recording at a faster monitor refresh rate to make the playback feel snappier. That doesn't help, the slow operations are still slow, and the user still has to wait through them.

The actual fix is explicit "this part is boring, speed it up later" markers dropped during the demo flow, then a single post-process pass that turns the marked sections into 10x-100x timelapses with a clear visual indicator (a "20x SPEEDUP: Exporting gerbers" red banner). The viewer sees the slow part happen, understands what was happening, and isn't asked to sit through 30 seconds of an unchanged screen.

That's adom-video-post phase 1. Phase 2 is the Adom Video Post-Processing app: open the sped-up video in a Hydrogen webview, hit record, narrate over it, auto-level the audio (EBU R128 broadcast standard), keep every take and every auto-leveled version as separate tabs, save whichever you like as the final. Phase 3 adds wiki publishing so the final narrated video gets attached to the wiki page for the artifact you demoed.

What's in the Adom Video Post-Processing app (phase 2)

The voiceover subcommand is a full webview app, not just a "record button". Running adom-video-post voiceover --input sped-up.webm --markers markers.jsonl opens a Hydrogen tab with:

• Speedup Timeline card showing the source video as a horizontal bar, speedup regions highlighted, summary stats (source vs output duration, seconds saved, % shorter, number of speedup segments). Populated from the markers file the process step wrote.
• Video tab strip above the player: "Original" (silent source), "Take 1" (your raw voiceover mux), "Take 1 auto-leveled" (same take with loudness normalized), "Take 2", "Take 2 auto-leveled", and so on. Every finalize produces two new tabs at once. Click any tab to play that version. Every tab is a separate file on disk; nothing is ever overwritten.
• Record voiceover button with a caption-based 3-2-1 countdown, automatic video playback from 00:00, live timer, wrap-up countdown in the final 5 seconds so you can cleanly close your narration, and auto-stop when the video ends.
• Finalize & mux runs ffmpeg to combine the captured audio with the video, then immediately auto-runs ffmpeg loudnorm (EBU R128, -16 LUFS target, -1.5 dBTP peak ceiling) to produce the auto-leveled sibling, both tabs appear at once.
• Save as final copies whichever tab you picked over the canonical output path. Sidecars stay on disk.
• Reveal in VS Code button opens the currently playing file in VS Code's file explorer.
• Audio waveform visualization of the current take, raw vs normalized, for visual before/after comparison.
• Takes history card below the player lists every take on disk with size, modified time, and click-to-switch.
• 2-way HTTP comms: every user-visible action has a curl-addressable endpoint so an AI can drive the full flow end to end without clicking anything, and UI state always reflects server state (400ms poller, server as single source of truth).
• JS console forwarding: every console.log/warn/error in the frontend is mirrored to the server and readable via GET /console, so an AI debugging UI behavior has a log surface to read without DevTools.

The full feature list, endpoint catalog, and recovery flows live in SKILL.md. The patterns used here (relative URLs, state poller, eval channel, tooltips, brand-compliant styling, now-playing indicator, save-before-publish gating) are documented in gallia/skills/app-creator as the canonical reference for building any Adom app.

The whole pipeline takes any Adom user from "raw silent recording" to "polished narrated demo video on the wiki page" in four commands and under 10 minutes of wall-clock work, regardless of how long the source recording was.

Why this lives in its own repo (not in adom-desktop or gallia)

The user originally asked for this as a "post-process script for the Fusion demo I'm recording right now". I started writing it inside adom-desktop/scripts/demo-record.sh as a one-off helper, but the use case generalizes immediately:

• Anyone recording any kind of demo (KiCad workflow, pup automation, molecule import, datasheet annotation, library publishing) hits the same dead-air problem
• The marker + speedup + overlay technique works on any .webm from any Hydrogen recording, not just adom-desktop ones
• The voiceover overlay is also a generic workflow, it doesn't know or care what was being recorded
• Wiki publishing should work for any wiki page type (apps, skills, molecules, libraries, datasheets, footprints, symbols, 3dcomps), not just adom-desktop

So it lives in its own repo, follows the standard Rust + clap + SKILL.md + wiki-discovery pattern (the tool-publisher skill), and gets installed by any container that needs it via the Adom Wiki auto-discovery flow. Same model as adom-molecule, shotlog, and other on-demand tools.

Recording skills live here now. The full demo-recording skill (script → record → mux → storyboard → publish, with the Hydrogen / pup / native-browser capture mechanics) is bundled under skills/demo-recording/, homed in this repo since gallia was retired. Recording the user's real, logged-in browser at full framerate in the background is the adom-browser-extension's native-browser-recording skill.

adom-desktop's scripts/demo-record.sh is the consumer, it calls adom-video-post mark init after Hydrogen recording starts and adom-video-post process after it stops. But adom-video-post itself doesn't know about adom-desktop. Any other recording orchestrator (even a hand-rolled bash script for a one-off demo) can use adom-video-post the same way.

What it does (3 phases)

Phase 1, Speedup post-processor

Drop start/end markers around slow sections during the demo, then run a single command after recording to produce a sped-up version with overlay captions.

# At the start of recording
adom-video-post mark init

# Wrap any slow command (this is the most common pattern)
adom-video-post wrap --speed 20 --label "Exporting gerbers" -- adom-desktop fusion_export_gerbers
adom-video-post wrap --speed 15 --label "Pulling source files" -- pull_and_analyze "C:/tmp/foo.fbrd"

# Or drop manual start/end markers if you need finer control
adom-video-post mark start --speed 50 --label "Cloud search"
# ... slow operation ...
adom-video-post mark end

# After Hydrogen recording stops, post-process
adom-video-post process \
  --input  /home/adom/project/recordings/demo.webm \
  --markers /tmp/adom-video-post-markers.jsonl
# → produces /home/adom/project/recordings/demo-fast.webm

The output video has the marked sections accelerated (default cap 100x) with a red "20x SPEEDUP: Exporting gerbers" banner. Normal sections play at 1x. Audio is dropped (phase 1 expects silent recordings).

Phase 2, Voiceover overlay ✅ shipped

adom-video-post voiceover --input demo-fast.webm

Starts a tiny HTTP server and opens a Hydrogen webview tab with a video player, a record button, and a real-time audio waveform indicator. You watch the sped-up video and narrate over it. When you stop recording, ffmpeg muxes the audio with the video to produce the final narrated output.

Phase 3, Wiki publish ✅ shipped

adom-video-post publish \
  --input demo-fast-narrated.mp4 \
  --page adom/adom-desktop-fusion-bridge \
  --caption "Fusion 360 deep dive: BQ25792 manufacturing pipeline"

Pushes the final narrated video into the wiki page's repo via adom-wiki repo push, so it lands in the page's Files tab and serves at https://wiki.adom.inc/api/v1/pages/<slug>/files/<file>. The command returns that served URL so you can embed it. Now the polished demo video lives alongside the artifact it documents, so anyone visiting the page sees the demo, not just the docs. (The old adom-wiki asset upload pillar this used to wrap was removed; repo push is the supported path.)

The full pipeline

# 1. Record (silent, no voiceover)
adom-cli hydrogen sharing request --share screen --reason "Demo recording"
adom-cli hydrogen recording start --countdown 3
adom-video-post mark init

# (run your demo, wrapping slow sections with `adom-video-post wrap`)

adom-cli hydrogen recording stop  # → demo.webm

# 2. Speedup pass
adom-video-post process --input demo.webm

# 3. Voiceover (Phase 2)
adom-video-post voiceover --input demo-fast.webm

# 4. Publish (Phase 3)
adom-video-post publish \
  --input demo-fast-narrated.webm \
  --page apps/adom-desktop \
  --caption "Fusion 360 deep dive"

Four commands. Total wall-clock time under 10 minutes for a demo that captured 30+ minutes of raw recording.

How the AI uses it

Adom users mostly don't run adom-video-post directly, their Claude Code session does. The skill file (SKILL.md) is auto-installed to ~/.claude/skills/adom-video-post/ and Claude Code finds it via trigger words like "speed up demo recording", "timelapse video", "voiceover after recording", "publish demo to wiki".

Once Claude finds the skill, it knows the marker workflow and the four-command pipeline above. The AI drops markers as it runs commands during the demo, then runs process automatically after the recording stops, and offers to run voiceover and publish next.

This is the same pattern as adom-molecule (Claude drives the molecule import workflow) and shotlog (Claude annotates screenshots during a debug session). Build the CLI well, write the SKILL.md well, and the AI does the rest.

Install

# From source
git clone https://github.com/adom-inc/adom-video-post
cd adom-video-post
./build.sh

# After v0.1.0 release: from the wiki auto-discovery flow
gh release download v0.1.0 --repo adom-inc/adom-video-post --pattern adom-video-post -D /usr/local/bin
chmod +x /usr/local/bin/adom-video-post
adom-video-post install

adom-video-post install deploys the SKILL.md to ~/.claude/skills/adom-video-post/ so Claude Code in this container picks it up immediately.

Prerequisites

• ffmpeg and ffprobe (sudo apt-get install ffmpeg)
• Rust toolchain to build from source (rustup default stable)
• For the integration with adom-desktop/scripts/demo-record.sh: a working Hydrogen recording setup

Status

• Phase 1 (speedup): ✅ shipped in v0.1.0
• Phase 2 (voiceover web server): 🚧 planned for v0.2.0
• Phase 3 (wiki publish): 🚧 planned for v0.3.0

License

MIT