Skip to content
Workflow Programming

Story-to-Video Workflow: From Chapter to Narrated Video

By Romi Fadli, S.Kom. 11 min read AI & Media Production
On this page
Five stages in a row — chapter, scenes and shots, voice and music, images, video — joined by arrows, with a note that a gate after every stage refuses unfinished work

Story-to-Video Workflow: From Chapter to Narrated Video is the procedure I follow every time a new chapter of a serialised story is ready to become a narrated video. It takes the chapter text in, and it ends with a finished video: every passage spoken, every few seconds illustrated, music underneath, and a thumbnail that promises what the chapter is about.

This page is not a tutorial, and it does not share the tools that run it; they are my own. It describes how I turned a long, creative job into a sequence of decisions I only have to make once: which stage comes first, which ones an AI agent runs on its own, which ones I keep for myself, and why.

At a glance

TriggerA new chapter of the story is ready to be produced
FrequencyOnce per chapter
InputsThe chapter text, and the record of the story's characters, props, and places
OutputA narrated video of the chapter in each configured language, with music and a thumbnail
Done whenEvery image has passed its inspection, the chapter audit is clean, and I have reviewed the chapter and rendered it
When the workflow runs, what it needs, and how I know it is finished.

The recurring work

Turning one chapter into a video means dozens of small creative choices: where one mood ends and the next begins, which moment of a paragraph deserves a picture, what a character looks like in this scene, which music sits under a sad passage without turning it into a horror film. Made fresh each time, those choices drift. A character's face changes between images, the pace of the pictures speeds up and slows down for no reason, and a chapter opens with music that drives viewers away in the first minute.

So I fixed the order of the work, wrote down every rule that a past chapter taught me, and put a gate after each stage that refuses to let the next one start on incomplete or unverified results. An AI agent does the production work stage by stage; I decide when each stage runs, and I keep the final review and the render for myself.

The flow

  1. Bring in the chapter, rewrite it in Indonesian, and record the characters, props, and places it introduces.
  2. Divide the chapter into scenes and shots, before any audio exists.
  3. Generate the narration, in every configured language.
  4. Choose the music, before a single image is made.
  5. Plan and generate the images, inspecting every one.
  6. Make the thumbnail once the images are complete.
  7. Review the chapter, then render the video.

Steps and the decisions behind them

  1. Bring in the chapter and rewrite it. An AI agent collects the chapter text and rewrites it into natural Indonesian prose, told from the main character's point of view. I chose rewriting over literal translation because the narration is listened to, not read: a sentence that is merely correct sounds stiff when it is spoken aloud.

  2. Record the characters, props, and places. In the same stage, the agent extracts every character, prop, and location the chapter introduces into a story record — what I call the object bible — with a description of each and of its states, such as a school uniform or an adult version of the same person. This happens before any production, and the production stages only read it. The reason is consistency: every later image depends on these descriptions, and a description that changes in the middle of a chapter would change a face in the middle of a story.

  3. Divide the chapter into scenes and shots, before audio. A scene is a run of the story that shares one mood. A change of place does not start a new scene by itself, but a change of mood inside one place does, because the music will later follow the scenes and must never have to cover two opposing moods. A shot is a group of whole paragraphs inside one scene, sized so that its narration lasts well under a minute. Paragraphs are never cut, so the narration stays exactly the text that was written. The boundaries are set before any audio exists, so they follow the story rather than a timing that has not been measured yet.

  4. Generate the narration. Each shot is turned into speech by a text-to-speech service, one shot at a time, with the voice, speed, and format fixed per language in the project settings. The agent never chooses a voice by guessing from the language; a fixed setting means every chapter of the story sounds like the same narrator. When I want a second language, its narration is written for every shot from the story's context before this step, and both languages are generated here.

  5. Choose the music before the images. As soon as every shot has audio, the agent groups neighbouring scenes that share a mood into a few music blocks and picks a licensed track for each. Music does not depend on the pictures, so there is no reason to wait for them. The rule that matters most came from a failed chapter, whose opening sounded like a horror film because a track was chosen for being sad and happened to be dark as well: the narration supplies curiosity, the music supplies comfort, and when both are tense, viewers leave in the first minute. The opening block therefore may never be dark or minor.

  6. Plan the images from the measured audio. Only now is the number of images decided, because it is derived from how long each shot's narration actually lasts — a new image every few seconds, counted from the longest language, so that all languages share the same pictures. The agent divides the shot's text into as many continuous, complete parts as there are images, and chooses one distinct moment of the story for each. For every visible character it records which version of them appears, what they wear, and who does what to whom. A plan that does not cover every word of the text, or that repeats a moment, is refused by the gate before any image is made.

  7. Generate each image with its references. Each character, prop, and place has one accepted reference image, tied to the exact description it was drawn from. If the description changes, the reference is marked stale and redrawn, never silently reused. An image request carries only the references for what is visible in that moment, because a reference that is merely nearby leaks into the picture: an adult version of a character, a companion who is not in the scene.

  8. Inspect every image before it is installed. The agent looks at every finished image against its narration and a fixed checklist: style, anatomy, framing, identity, action, continuity, and safety. Each accepted image is recorded together with a fingerprint of its exact bytes, so the record proves that this file, and not an earlier one, was the one inspected. Only images with that record pass the gate into the chapter.

  9. Make the thumbnail last. The thumbnail is a single piece of key art that shows the chapter's central conflict, made only after every image in the chapter has passed. It reuses the accepted references and a few relevant images, so its characters look like the ones in the video. It shows what is at stake in the chapter, never its outcome.

  10. Review the chapter, then render. I review the finished chapter in a small review application of my own, and I start the render there myself. Rendering is only possible once every shot is complete and a thumbnail exists, and it produces one video per language.

What I automated, and what I did not

StepAutomated or manualWhy
Starting each stagemanualI decide when a chapter moves on, so I always know which stage it is in
Rewriting and recording the story's objectsautomatedthe same careful reading for every chapter, and a record that every later image can rely on
Scenes and shotsautomated, with fixed rulesmood and paragraph boundaries follow written rules rather than a fresh judgement each time
Narrationautomateda fixed voice per language keeps one narrator across the whole story
Musicautomated, with rules the server enforcesthe rule against dark openings is too important to rely on taste
Images and their inspectionautomated, behind a gatemany images in every chapter; only a recorded inspection of each one keeps them consistent
Thumbnailautomatedbuilt from the same accepted references, so it cannot drift from the video
Review and rendermanualwhether a chapter is worth publishing is a judgement, and the render is the point after which it is finished
Each step, whether it runs on its own, and the reason behind that choice.

When it fails

Each stage ends at a gate, so a failure shows up at the gate that caught it rather than in the finished video, and the gate's output says what is wrong.

If a gate refuses a plan, an installation, or the chapter audit, its report names the shot and the rule: a part of the text left uncovered, a reference that is stale, an image without an inspection record. Only that part is redone. Everything that already passed stays as it is.

If an image fails its inspection, it is generated again with the complete context it had the first time, plus one focused correction for the specific fault, such as a wrong hand, the wrong version of a character, or an action that does not match the narration. Starting from scratch would lose the context that made the rest of the image right.

If the server refuses to render, the cause is the music: an opening block that is dark, or a sad passage given a track that is also eerie or aggressive. The music plan is corrected, and the render is started again.

Why this order

Each stage needs something only the stage before it can provide. The images depend on the measured length of the narration, the narration depends on the shots, and the shots depend on the scenes; the music depends only on the scenes and the audio, so it comes before the images rather than after them. The thumbnail summarises a finished chapter, so it comes last. And the story's objects are recorded before everything else, because every picture of a character must start from the same description. Changing the order would mean producing work on a foundation that has not been decided yet, and producing it again when it is.

Variations

More than one narration language. A second language adds its own narration before the audio step, and its own audio, title, and video at the end. The images are shared: they are planned from the Indonesian text and timed against the longest of the languages.

Redoing only part of a chapter. A single shot, a scene, or one image can be redone on its own. The structure of a chapter that has already been accepted is never re-divided just to make a later step easier.

Continuing after an interrupted session. Work resumes from the last checkpoint the gates recorded. A finished image or a single installed shot is a checkpoint, not the end of the chapter, and no stage is considered complete just because the conversation that ran it was cut short.

Terms

Scene
A continuous run of the story that shares one mood; the unit the music follows.
Shot
A group of whole paragraphs inside one scene, narrated as one piece of audio.
Beat
One image and the few seconds of narration it illustrates; a shot holds several.
Object bible
The record of every character, prop, and place in the story, with a description of each and of its states.
Reference image
The one accepted drawing of a character, prop, or place that every later image must match.
Text-to-speech
Software that turns written text into spoken audio.
Key art
A single illustration that represents a whole chapter, used here as the video's thumbnail.
Gate
A check between two stages that refuses to let the next stage start on results that are incomplete or unverified.

About the author

Photo of Romi Fadli

Romi Fadli, S.Kom.

Solution Architect · Backend Engineer · Embedded Systems

In my day job I work as a solution architect. I design the system, lead the team that builds it — quality assurance, backend developers, a UI developer, DevOps and DevSecOps — and write the most critical modules myself, such as a certificate authority, a long-term PDF signer, and the core API of a personnel system.

I work across the whole stack that a running system actually needs. On the hardware side that means PCB design, microcontrollers, and embedded firmware — including RISC-V boards running FreeRTOS and Embassy, speaking MQTT over mutually authenticated TLS on a microcontroller with 64 KB of SRAM.

Most of my day-to-day work is software: Rust backends and API modules built on Clean Architecture, an OAuth2/OpenID Connect authorization server written from scratch, PAdES document signing, and certificate authorities — root CAs, timestamping authorities, and OCSP responders. I also build the frontends that sit on top of them.

Running all of that means infrastructure: Docker Compose stacks, networking, Mikrotik and RADIUS, observability with OpenTelemetry, and a steady habit of writing command-line tools and utilities for Linux when the existing ones do not fit.

Share

Enjoyed this?

Get an email when a new article is published.

Related Articles

Four flat layers stacked on the left — routes, controllers, services, repositories — joined by short lines, with an orange line labelled later: refactor leading to the concentric circles of Clean Architecture on the right

One folder per kind of code at a single level, a short path from route to repository, one file per operation — the shape I give a Rust service that must work fast or fit a local AI agent's context, before it grows into Clean Architecture.

7 min read Read more →
A panel of code lines, some starting with highlighted names, connected by three curves to a person, a clock, and a chat window whose older history is faded above a dashed line.

My code is read by people who were not there when it was written: colleagues, me months later, or an AI agent that forgets on every reset. The clean code rules from Robert C. Martin I apply in every language, shown in a Rust service.

24 min read Read more →