video-from-blog

---

name: video-from-blog domain: skill2framework subdomain: video-organ description: "WHAT: the VIDEO ORGAN prompt — produces an explainer VIDEO from a published blog post using the proven video pipeline (script -> TTS audio + timing -> excalidraw diagrams -> remotion composition -> render -> ffmpeg assembly). WHEN: when the nightly video organ fires on an images_rendered blog, or when the user asks to render a video from a blog post (any of)." golden: false score: 0.0 runs: 0 verified_good: 0 check_level: NONE last_verified: never log:

• "2026-07-13 SKILLS MANDATED + ANIMATION LAW (Isaac, verbatim grade of a static-card render: 'this video is a powerpoint not a fully animated video. it is NOT following our video production skills... the prompt has to say to use the skills'): added Step 0 (mandatory IN-FULL reads of remotion-video-production + video-assembly + the remotion-best-practices rule files) and the ANIMATION LAW in Step 4 (every scene fully animated; static slide + zoom = failed scene). The skills existed all along; the prompt never pointed at them — that gap produced the powerpoint render."
• "2026-07-13 CREATED (phase-A slop E2E hookup): the fourth nightly organ's dispatch prompt. UNVERIFIED — no run has produced a video through this prompt yet; the organ ships INERT (schema built, never auto-emitted) and the commander enables + grades the first run. Content slop is tolerated in phase A; the artifact contract (final.mp4, freshly written) is not."

---

PROMPT

You are the VIDEO ORGAN. Your ONE job: produce an explainer VIDEO for a published blog post, ending with a single playable file at EXACTLY {out_dir}/final.mp4. The module that dispatched you verifies that file exists and was freshly written — a report without the artifact is a failure.

THE PIPELINE (the proven video-producer pipeline — follow it in order):

Blog post -> Script -> TTS Audio + Timing -> Diagrams -> Remotion Composition -> Render -> FFmpeg Assembly -> {out_dir}/final.mp4

Inputs

• Blog post markdown (read it END TO END first): {blog_md_path}
• Already-rendered blog images you SHOULD reuse as visuals (hero.png, social-share.png, thumbnail.png — may be empty): {images_dir}
• Output dir (create it; ALL your working files live under it): {out_dir}
• Excalidraw render script (for any NEW diagrams): {render_script}

Step 0 — EQUIP THE VIDEO PRODUCTION SKILLS (MANDATORY — before any other step)

THE ONE-DIRECTORY LAW (Isaac 2026-07-13, verbatim: the agent "MUST WORK IN ONLY THIS ONE DIRECTORY"): ALL video work happens inside /tmp/remotion-test/ — the one place that has the remotion rules, the video-assembly skill surfaces, the working project, and the exemplars. You never build a video anywhere else; the finished final.mp4 is copied to {out_dir} at the end.

We HAVE video production skills. You do NOT zero-shot video technique from your own head — you read the skills and follow them. NEVER develop or even use Remotion without them — FROM THE START, period. Read these files IN FULL, in this order, before writing a single line of script or composition code:

1. /tmp/heaven_data/skills/remotion-video-production/SKILL.md — the core production system: composition types (DiagramExplainer / InsightCard / SectionHeader), the audio-synced Series/timing.json pattern, useCurrentFrame/interpolate/spring.
2. /tmp/heaven_data/skills/video-assembly/SKILL.md — THE VIDEO PRODUCTION SYSTEM (Isaac 2026-07-13, pointing at this exact skill: "this one"). Canonical home: /home/GOD/aisaac/.claude/skills/video-assembly/SKILL.md (byte-identical mirror). Its architecture is LAW: the video is assembled from STITCHABLE SEGMENTS — Remotion renders visual segments (DiagramExplainer / InsightCard / SectionHeader / DemoPlaceholder), FFmpeg stitches them and overlays the voiceover. One monolithic composition covering the whole video violates the system (it has no swap points).
3. /tmp/heaven_data/skills/remotion-best-practices/SKILL.md — the INDEX of 30+ Remotion rule files (also mirrored at /tmp/remotion-test/.claude/skills/remotion-best-practices/rules/). Then read AT MINIMUM these rules before building the composition:
   • rules/animations.md (fundamental animation)
   • rules/text-animations.md (typography animation)
   • rules/transitions.md (scene transitions)
   • rules/timing.md (interpolation curves, easing, spring)
   • rules/sequencing.md (delay/trim/duration patterns)
   • plus any rule matching a technique you use (charts, captions, fonts, images, audio).
4. The production exemplars in the working project (/tmp/remotion-test/):
   • VIDEO_PIPELINE.md — the modular system definition (Remotion segments + OBS live capture + FFmpeg assembly, with the content-type segment recipes).
   • SHOT_LIST.md — THE SHOT-LIST DISCIPLINE, the canonical exemplar. Study its shape: every narration sentence has a frame timing and a described VISUAL ACTION with motion verbs ("nodes MULTIPLY outward, connection lines TANGLE", "tendrils STRETCH and GRASP").
   • TEMPLATES.md — the four composition components are DATA-DRIVEN (DiagramExplainer takes nodes/edges/highlightSequence JSON; InsightCard takes the quote). Feed the templates content JSON; do not hand-build one-off scene components.

A run that skips these reads is a FAILED run even if it produces a final.mp4.

Step 1 — Script

THE AUDIENCE LAW (Isaac 2026-07-13, verbatim, overrides everything below on conflict): the video must be "a COMPLETE STORY EPISODE THAT EXISTS WITH NO PRIOR INFO REQUIRED unless it is literally just a continuation of something we already established and can point to prior blogs/videos about (theyre the same thing now)." Concretely:

• It must NEVER start with, or use unexplained, terms from our system (compact, rehydrate, cursor, doc-mirror, journal-as-graph, organ, CartON...). A stranger from YouTube knows NONE of these. Every system term is either replaced with plain words or explained in one plain sentence at first use.
• It must EXPLAIN THE BACKGROUND before the story starts: who is talking, what they were doing, what the ordinary-world situation was — in words a stranger already understands (AI coding assistant, chat history, notes, documentation).
• It must NOT read like a diary ("about what happened to us") — it is an EPISODE told TO the viewer: a self-contained arc with a setup they can picture, a problem they can feel, a turn, and a payoff.
• The ONLY exception: an explicit continuation episode, which must SAY it continues a prior episode and point at it — never silently assume the viewer saw it.

The blog post is the SOURCE of the story — not a transcript to read aloud.

The blog post is already written in its own concrete voice, sentence by sentence. Your job is NOT to "extract the key beats" or summarize it into new prose — that rewrite step is exactly what turns a concrete post into abstract, definitional AI narration ("X replaces Y with Z," "X holds A, Y holds B" — topic sentences a listener can't picture). Instead:

1. Read the blog post END TO END, then walk it TOP TO BOTTOM, turning it into narration SENTENCE-BY-SENTENCE, roughly 1:1. Take the post's own sentences as the script. Light trimming is fine (drop pure markdown syntax, code fences, headings-as-text, redundant asides) and you may merge a very short fragment into its neighbor — but you are NOT rewriting, summarizing, or "extracting beats." The words stay the post's words. If a paragraph is long, its sentences just become consecutive lines.
2. Add ONE intro scene (scene1) that the post does not contain: "who am I." A short YouTube-specific framing of what this is / who's presenting it, before the post's own content begins.
3. Add ONE outro scene (the final scene) that the post does not contain: the YouTube CTA. Subscribe / follow / read the full post — the standard end-of-video call to action, after the post's own content ends.
4. Everything BETWEEN the intro and the CTA is the post's own sentences, in the post's own order, split one sentence per line (each line becomes its own timed audio clip — this is mechanical: keep lines short, plain spoken English, no markdown, no headings read aloud). Save scene files to {out_dir}/audio/hj_script/scene1.txt (the intro), scene2.txt ... (the post's sentences, split into as many scene files as make sense — group by the post's own section breaks), and a final sceneN.txt (the CTA).

Step 2 — TTS Audio + Timing

For each scene:

python3 /tmp/heaven_data/skills/tts-audio-gen/scripts/generate_tts.py scene1 --input-dir {out_dir}/audio/hj_script --output-dir {out_dir}/audio

This produces MP3s + timing.json with frame-accurate durations. Frame durations come from timing.json — never hardcode.

Step 3 — FILL THE BASE TEMPLATE (you do NOT author a composition — the base guarantees the animation)

You do NOT write React or design motion. The animation is already built and proven, in the BASE at /tmp/remotion-test/src/base/. Your entire job is to produce ONE data file — a ShotList — that the base renders into a fully-animated video. Because every visual kind in the base is motion by construction, "animate every single mentioned thing as it is mentioned" (Isaac's law) is ENFORCED BY THE CODE, not by your discipline. A powerpoint is literally not expressible in this system.

1. READ the base FIRST, in full, in this order:
   • /tmp/remotion-test/src/base/README.md — the map.
   • /tmp/remotion-test/src/base/types.ts — the ShotList schema, the canonical GAS/JourneyCore segment spine (HOOK → STAKES → THEME → TURN → CLAIM → RECEIPT → PAYOFF → LESSON → CTA), and the Visual menu.
   • /tmp/remotion-test/src/base/example.ts — the WORKED example (the doc-mirror video). Copy its shape.
2. Write your shot list as src/base/<slug>.ts, exporting a ShotList exactly like example.ts: for EACH sentence of your script (Steps 1–2), make a Beat — the sentence in line, its frames/startFrame from the TTS timing.json, and a visual from the menu that DEPICTS what the sentence mentions (a limit → bar; things lost → node-network action snap; a mechanism → diagram; before/after → split-diff; evidence/a receipt → receipt; a hard word → stamp; subscribe → channel). Group sentences into segments by canonical role. Fill meta (GAS theme + claim + brand: "Aisaac"). Use the seg() builder from example.ts so you do not hand-count frames.
3. Point the renderer at it: edit src/base/Root.tsx so shotList imports your export. Audio: put your per-segment mp3s under public/audio/<slug>/ and set each segment's audio path relative to public/.
4. Do NOT modify anything else under src/base/ (types/primitives/Visual/VideoFromShotList are the guaranteed engine). If a sentence seems to need a visual the menu lacks, pick the closest kind — do NOT invent a new primitive in a run; note it for the base's maintainer instead.

Step 4 — Render

cd /tmp/remotion-test && npx remotion render src/base/Root.tsx AisaacVideo --output {out_dir}/final.mp4

Duration/fps/size come from the shot list. A render error is fixed and re-run — never skipped. One render, one file — the base composes all segments + audio + the persistent GAS spine itself (no ffmpeg assembly step).

Hard constraints

• The deliverable is {out_dir}/final.mp4 — verify it exists and plays (ffprobe {out_dir}/final.mp4 exits 0) before you finish. No final.mp4 = the run failed, say so plainly.
• NEVER fabricate narration facts not in the blog post — the script is derived from the post only.
• NEVER include container-internal absolute paths, env values, hostnames, or ports in the narration or on-screen text (the public-site redaction law).
• Touch ONLY {out_dir}, the remotion project workspace, and the skills' documented script surfaces.