Case study — a content factory

What you will learn How to join everything so far into a production pipeline that runs automatically every day. Follow the structure as-is.

What you are building

Every morning, one short video on a set topic is finished and waiting.

The only human job is checking it at the end and publishing.

graph TD
  A["1 Collect<br/>terminal"] --> B["2 Script<br/>task"]
  B --> C["3 Audio<br/>terminal + model API"]
  B --> D["4 Images<br/>terminal + model API"]
  C --> E["5 Render<br/>terminal"]
  D --> E
  E --> F["6 Check<br/>task"]
  F --> G["A person reviews and publishes"]

That 3 and 4 sit side by side matters. Once the script exists, audio and images have no reason to wait for each other — the independence of micro-sprints used directly.

Split into two folders

Why split: because the working directory is the area of operation. The render project has code and runs builds, so its character differs. Split, you can also give them different autonomy.

Stage by stage

1. Collect — terminal

Fetch material from a fixed location and save it as out/01-collected.json.

Why not task: there is no judgement. It fetches from a fixed address and saves in a fixed format, so a command is cheap and deterministic.

2. Script — task

That is the four parts of a good instruction applied directly.

"If missing, do nothing and report it" is the key line. If collection failed and the script stage runs anyway, it invents a plausible script out of nothing.

3. Audio — terminal + model API

Split the script by paragraph and call text to speech.

Two things are mandatory.

Splitting by paragraph exists so a failure means regenerating that paragraph only.

4. Images — terminal + model API

Extract the [image: ...] markers from the script and call image generation.

Keep the prompts in a file. Apply style fields (palette, composition rules) across all of them so the tone does not drift between episodes.

5. Render — terminal

Take the audio and images and assemble the video. One command in the render project.

Why this is terminal is obvious — a build command has no judgement and must produce the same result every time.

6. Check — task

The last line matters. Once the checking stage starts fixing things, you can no longer tell what the original result was.

The judgements in this design

Why a person is at the end

Publishing is irreversible. The criterion from guardrails applies directly — reversible means automatic, irreversible means a person.

Why every stage writes a file

Why only two task stages

Of six stages, only script and check need judgement. The rest are fixed commands. Since most of the cost comes from task, this split is the running cost.

The first two weeks

Do not automate it all at once.

Skip days 1–3 and you watch six stages run for the first time simultaneously, with no way to tell which one is the problem.

Common failures

The last is surprisingly common. A closed laptop runs no schedules.

Reshaping it

Swap the pieces and the same structure becomes a different pipeline.

The structure is identical — collect → judge → process → assemble → check → a person.

Check yourself

1. Why are only two of the six stages task?

2. Why put "if there is no material, do nothing" in the script stage?

3. Why does only publishing need a person?

That completes the Extending it part. From here you can take HyperTeams beyond the screen — joined to other programs and running by itself.

If something is stuck → Troubleshooting · Guide contents