A content calendar that fills itself

Video tools make one video. Schedulers post what you already have. Between them sits the actual job, which is turning a product into fifty honest, distinct videos and getting them onto a calendar, and nobody does that for you. If you run several products, you have neither the hours to make that many videos nor the ideas to keep them from looking the same.

Season Reels is a content calendar that fills itself. It shows every brand, every platform and every day in one view. An empty day is the unit of work.

Click the empty day

Click an empty day and the brand, platform and date are already selected. There are two things you can do: plan this day, or plan this gap, which is the run of empty days around it, or the month.

Either way the result is a plan, not a video. A plan is text: a lane, a hook, a one-line concept, a music mood, and which footage to use. It costs nothing to redo. The planner does not start from a blank page. It reads the brand’s facts sheet, so it cannot plan a claim the product does not support. It reads the brand’s research, so seasonal slots land in their posting windows, ten to twenty-one days ahead of the date. And it reads the brand’s log of everything already made, so it does not plan a mechanic the brand has used recently.

A brand with no memory gets season setup first: the facts sheet, the research and the brand kit. That is the one place honesty is structural rather than a convention, and the calendar will not plan a day for a brand that has not been through it.

Four states

empty → planned → built → scheduled / posted (text) (mp4 + stills)

You approve plans. Then builds run in waves, one agent per lane, on your machine. Each build reports stills back to the calendar, so a slot shows “built” with five frames beside it before you ever open the video. You review from stills, leave redo notes in plain words, and the agent that built the video fixes it. Then you schedule, and the server posts when the slot is due.

Plans first, stills second. There is no editor and no timeline, because a timeline makes you the bottleneck of fifty videos, and the point of the calendar is that you are not.

Where the work happens

Creative work and rendering happen on your machine, in a folder in your own git repository. A small server holds the accounts, the brands’ memory, the finished files and the schedule, and does the posting. The repository is the source of truth; the cloud is the outbox.

The same app runs in two places. On the web it is accounts, teams, brands, the calendar, approvals and posted results, and it works with no local machine at all. Locally, the same app talks to a daemon on your machine, which reports build progress, stills and renders back. You see “building 3 of 5, stills ready” on the web calendar while the renders run on your Mac.

Several brands sit in one view, and each keeps its own memory. The planner for one brand reads that brand’s log and that brand’s facts sheet, not the others’.

Any agent can fill a day

The calendar and the agents never talk to each other directly. They share files and a handful of CLI verbs.

brand/ FACTS.md RESEARCH.md brand.ts LESSONS.md made.jsonl seasons/<season>/ slots/<date>.<brand>.<platform>.md lane, hook, concept, footage, music, status src/lanes/<lane>/ the build out/ renders and stills

A slot is a small file. The calendar writes it through the server; an agent on your machine reads it from the folder and builds it with season build <slot>. Claude Code is the first agent we run, but nothing in the contract is specific to it. Any coding agent, or a person, can read a slot file and build it, and season sync reports the result back.

That is the whole idea. A day is empty. You click it. Something with memory of the brand plans it honestly, something builds it on your hardware, you look at five frames, and it posts when it is due.