the pipeline that posts itself: how m4d’s instagram content actually ships

Every post on @march4orthdesign is decided, built, and shipped by one file, and nobody opens it to check what’s next.

Most content calendars are a decision someone has to keep making: what format today, what topic, who’s writing the caption. M4D replaced that decision with a state machine. `content/queue.md` holds the whole rotation — carousel, specimen, reel, quote, blog post, repeating in order, with one row always marked Next. A router skill reads that row, resolves the topic (a Carousel anchors a “content cluster,” and every Reel or Blog Post tied to it just inherits the same topic instead of getting reinvented), and calls exactly one producer skill for that format.

Reels render through HyperFrames: the composition is HTML, timing lives in literal `data-start`/`data-duration` attributes, and one paused animation timeline drives the whole thing frame by frame until it compiles to an MP4. Nothing about that step touches a video editor. Before anything posts, the render syncs to a second, public repo, because Instagram’s Graph API can only fetch media from a public URL — a detail that would otherwise be an invisible failure point.

The actual publish call branches by type: an image is one container then publish, a carousel wraps child containers in a parent container, a reel has to poll a status code until it reports finished before it’s allowed to publish. A GitHub Actions cron runs that whole sequence three times a day, so posting isn’t a task anyone has to remember, and a separate deploy workflow watches the same repo but only fires when a push actually touches site files, so a content commit never triggers a wasted redeploy.

The mechanism is the point: the same shape — one state file, format-specific specialists, a render step, a public sync hop, a scheduled trigger — is portable to any other repo that needs to ship content on a schedule without a person in the loop.