HyperTeamsCase 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.
| Folder | Autonomy |
|---|---|
| Source | auto-approve file edits |
| Render | plan only → raise after verifying |
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.
| Period | What you do |
|---|---|
| Days 1–3 | run each stage by hand once. See where it sticks |
| Days 4–7 | put it on a schedule but check the result daily by eye |
| Week 2 | raise autonomy and read only the check stage's report |
| After | intervene only when a failure alert arrives |
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
| Symptom | Cause | Response |
|---|---|---|
| An empty script every day | collection fails but the script stage keeps running | precondition check in the instruction |
| Audio and image counts disagree | failures skipped and it carried on | compare counts in the check stage |
| Tone differs between episodes | image style is not shared | common fields in the prompts |
| Cost higher than expected | judgement-free stages as task | move them to terminal |
| Nothing for days | the machine was off | background run or startup item |
The last is surprisingly common. A closed laptop runs no schedules.
Reshaping it
Swap the pieces and the same structure becomes a different pipeline.
| Swap | You get |
|---|---|
| Collect → internal logs, render → a document | a daily operations report |
| Collect → support tickets, render → a table | a weekly customer issue summary |
| Collect → competitor pages, render → a comparison | price monitoring |
| Collect → meeting recordings, using speech-to-text | meeting notes automation |
The structure is identical — collect → judge → process → assemble → check → a person.
Check yourself
1. Why are only two of the six stages task?
Answer
Because only the script and check stages need judgement. The rest are fixed
commands, where terminal is cheap and deterministic. Most of the cost comes
from task, so this split is the running cost.
2. Why put "if there is no material, do nothing" in the script stage?
Answer
Because if collection failed and the script stage runs anyway, it invents a plausible script out of nothing. In a pipeline running while nobody watches, a wrong result hardens in place.
3. Why does only publishing need a person?
Answer
Because it is irreversible. Collection, script, audio, images and render can all be remade; publishing is hard to retract. The guardrail criterion applies directly.
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