S4L does not make visuals. It reads the visual in the thread before it replies.

The problem: replying text-blind to a picture

A huge share of the tweets worth replying to are not really text. They are a screenshot of a chart, a demo video, a meme, or a link-card to a launch. If the drafting model only receives the tweet's caption, it has to guess at what the post is about, and the reply gives the game away: a generic "love this, so true" under an image the model never saw reads like a bot, because it was written like one.

S4L closes that gap deterministically. The prep step of the posting cycle forbids the model from opening the browser itself. Instead the shell pre-fetches the media of every candidate in one cheap pass, and the model only ever sees a tidy description it can react to. Here is the difference in the prompt the writer receives.

What actually happens, step by step

This is the Phase 2b-prep path in skill/run-twitter-cycle.sh (the thread-media feature, shipped 2026-06-03). Every arrow is a real handoff, not a metaphor.

The detail nobody else has: empty array is not NULL

The captured media is a JSON array of {url, alt, type} objects, where type is one of image, video, gif, or card. The subtle part is how the column treats absence. The script is careful never to confuse "I looked and there was nothing" with "I never looked."

That one rule, persist [] only when the page genuinely rendered, is what keeps the column honest. Without it, a single flaky page load would stamp "no media" onto a tweet that actually had a chart, and the model would go on replying blind to it forever.

One script, two outputs

The capture script writes to two places at once: it persists the structured media to the database, and it emits a human-readable block for the prompt. The database copy is for durability and audit; the prompt block is for the model that is about to reply.

What the model actually reads

This is the block _build_block() emits, verbatim shape. A candidate that is not listed had no media (or capture was skipped), so the model replies to its text as usual. Notice the repost handling: the model is told the content belongs to the original author, not whoever reposted it.

## MEDIA IN THESE THREADS
Some candidate threads contain images, videos, GIFs, link-cards, or are
reposts. This is part of the content you are replying to: react to what
the tweet VISUALLY shows, not just its text, and treat reposted content
as the original author's. A candidate NOT listed here had no media and is
not a repost (or capture was skipped); reply to its text as usual.
Descriptions marked [no description] mean the media had no alt-text, so
infer from the thread text and the media type.

Candidate 7211:
  - image: "dashboard showing 3 line charts trending up" (pbs.twimg.com/media/<id>)

Candidate 7218:
  - video: [no description] (video.twimg.com/<id>)

Candidate 7224:
  - REPOST: this is a repost surfaced by @some_account. The tweet text
    and any media below were written by the ORIGINAL author, not the
    reposter. Reply to the original author's content; do not address
    the reposter.
  - card: "Show HN: a tiny local-first vector store" (github.com/<user>/<repo>)

Generated at runtime by scripts/capture_thread_media.py during Phase 2b-prep.

Why a self-hosted tool bothers with this

Most autoposter writeups stop at "find a thread, draft a comment, post it." They treat a tweet as a string. But the threads most worth engaging are exactly the ones carrying a chart, a screenshot, or a demo clip, and a reply that ignores the picture is the fastest way to look automated. Capturing the visual first is cheap insurance against the single most common tell.

It is also why the capture is deterministic shell work rather than something the model is trusted to do on its own. The prep prompt forbids the writer from opening the browser, so there is exactly one media fetch per cycle, the result is logged, and the same media is available for audit long after the reply went out. The model never decides whether to look; it always already has.