mrudisill26 Arcade Booth Generate
Overview
Takes one source-content file — the per-subtopic output of arcade-source-content —
and generates the Red Hat booth video for it: same seven-scene template, same layouts,
different copy and footage.
One file per run. If the user wants all eight subtopics, that is eight invocations, so each video can be judged before the next is worth generating.
The template lives in prompt-template.md in this directory. Read it before writing
anything. It is the deliverable's shape; this file is only the procedure around it.
Process
1. Parse the source file
Extract PRODUCT, SUBTOPIC, KEY POINTS: <N>, and every scene's fields. The file's
key point count sets the scene count: key point scenes are 4..(3+N), closing is 4+N.
Copy is verbatim. Every kicker, title, bullet, pillar label and pillar description goes into the prompt character for character. These files are a finished deliverable written under a field contract — the lowercase word opening the closing subtitle and the pillar descriptions that duplicate their scene titles are both intentional.
2. Resolve demos to flowIds
Each DEMO: line is <name> — <link>. The link is a redhat.com marketing URL, not an
Arcade ID. Call list_demos and match on name; workspace demos are usually prefixed
(Ansible-CY26Q2-...) and worded slightly differently, so match on substance.
No match: pick the closest demo, use it, and record the substitution. Report it prominently at the end — name the demo the file asked for, the one you used, and which scene now has footage that does not match its words.
Scene 2's demo is often also a key point demo. flowIds is a set of source material, not
a per-scene list — pass each unique ID once, and let the prompt say where each one goes.
3. Resolve the brand kit
Call list_brand_kits. Exactly one ready kit for the product's domain → use it. More than
one → ask the user which. Do not pick and do not justify a pick with usage history;
the tool exposes no history to reason from.
Red Hat is already decided: use hxjQ19oUlVfVSTJCiab2. The workspace has two ready
kits both named redhat.com; this is the one. Do not ask again.
4. Build the prompt
Substitute into prompt-template.md. Set targetLength from the key point count:
| Key points | Scenes | targetLength |
|---|---|---|
| 1 | 5 | 30s |
| 2 | 6 | 45s |
| 3 | 7 | 60s |
| 4 | 8 | 90s |
5. Generate
create_video with brandKitId, prompt, flowIds, targetLength. Then poll
get_generation_status back to back until status != "processing" — it sleeps ~30s
server-side per call. Measured: 60s video ≈ 6–7 min, 90s video ≈ 11 min.
Then preview_video with the returned videoId. It will exceed the tool timeout and get
backgrounded; the notification that comes back often has url: null and progress: 0.75
because generation finished but the mp4 export has not. That is not a failure — wait and
call preview_video again until url is populated and progress: 1.
6. Verify against the template
Download the mp4 from the returned url and check it. drawtext is missing from this
machine's ffmpeg build — the working contact sheet command is:
ffmpeg -v error -i video.mp4 -vf "fps=1/2.5,scale=440:-1,tile=4x3" -frames:v N sheet%02d.png
Each sheet covers 30s, so N is 2 at 60s and 3 at 90s. Tiles read left-to-right, four per
row, twelve per sheet: tile k on sheet s is at t = 30(s-1) + 2.5(k-1). Work the
timestamp out before pulling a full-res frame — guessing puts you on a cut and you get a
near-empty frame.
Read the sheets and confirm, scene by scene:
- Scene count matches the source file
- Subtopic top-left and Red Hat logo top-right on every frame
- Pillar cards are numbered, in one row, with red top borders
- Key point scenes share one layout: text left, recording right
- Closing has both beats — wordmark and the interact.redhat.com CTA card
- Copy matches the source file (crop the left third at full resolution to read it:
-ss <t> -vf "crop=iw*0.42:ih:0:0,scale=900:-1")
Known renderer behavior, worth reporting but not worth regenerating for: the closing subtitle loses its trailing period, and Scene 3's cards can sit at the bottom of the frame with a wide gap under the headline instead of directly beneath it.
Also ffprobe for duration/resolution/fps, and -af volumedetect — these videos carry a
music bed at roughly −25 dB mean. Silence means something went wrong.
7. Report
The edit link, the local path, a scene-by-scene verification table, and every substitution and judgment call. Flag anything visible in the footage that the source file could not have predicted — real people's names, customer data, visible browser chrome.
Common Mistakes
Every one of these came from watching two agents build this prompt without the template. They are the default behavior, not hypotheticals.
| Mistake | Fix |
|---|---|
| Cutting the closing CTA card as unwanted marketing | It is the template's final beat. Both closing beats ship. |
| Instructing "muted, no narration, booth screens play silent" | These videos have a music bed. Do not suppress audio. |
| Specifying the top-left label but forgetting the top-right logo | Both, every scene, stated in the global rules block. |
| Pillars as an unnumbered grid or rail | One row of numbered cards, red numerals, red top border. |
| Scene 1 as a full-bleed centered title card | Headline left, brand graphic right. |
| Scene 2's recording as a dimmed background wash | A crisp floating browser window beside the text. |
| Budgeting Scene 3 ten or twelve seconds | It is a ~3s beat at 60s. Long pillars starve the key points. |
| Uppercasing the top-left subtopic label | Title case, exactly as the source file writes it. |
| Handing over the link without watching the output | Verification is step 6, not optional. |
Before handing off
- Every field in the video traces to the source file, unedited
- Every substituted demo is named in the report
- Brand kit was chosen by the user, not guessed
- Contact sheets were actually read, not just generated