A social media marketing automation tool that cannot double-post, by construction.

Those tools are schedule-first. They wrap platform APIs with a calendar, a unified inbox, and an analytics dashboard. S4L is engagement-first: it posts comments and replies through a real logged-in browser, and the spine of the codebase is the crash-safety contract around that browser. skill/engage.sh starts with a SQL statement that auto-resets any reply stuck in 'processing' for more than 2 hours, then for every Reddit reply it runs one browser_run_code call whose first act is to read OUR_USERNAME ('Deep_Ad1959') out of the DOM. No top-10 social media automation listicle describes what happens to a queued reply when the bot crashes. S4L is built around that question.

skill/engage.sh, around lines 186 through 220. The snippet is embedded as part of the engagement prompt itself. The bot navigates to the target comment URL, runs a single mcp__reddit-agent__browser_run_code call, and inside that Playwright function it selects #thing_t1_COMMENT_ID, calls thing.$$('.child .comment') to get all existing replies, $evals '.author' on each, and compares to const OUR_USERNAME = 'Deep_Ad1959'. If the match hits, the function returns the string 'already_replied' and never opens the reply box. If no match, only then does it click the reply link, fill the textarea, and click save.

Two hours is the upper bound on one engagement batch's realistic run time including retries. A reply that has been stuck in 'processing' for more than two hours is not mid-post, it is a crash scar from a killed or timed-out Claude session. The UPDATE statement at the top of every engage.sh run puts those rows back to 'pending' so the next batch picks them up. The idempotency check above prevents that second attempt from ever writing a duplicate comment. Shorter windows risked stepping on in-flight batches; longer windows meant users waited hours for their queue to unblock after a crash.

Three reasons. First, LinkedIn's commenting API is effectively off-limits unless you are an enterprise partner. Second, Twitter's API priced organic engagement out of small operators. Third, Reddit's modern API shadowbans tools that post the same content shape across subreddits. S4L posts as a real logged-in user via per-platform MCP browser agents (mcp__reddit-agent__*, mcp__twitter-agent__*, mcp__linkedin-agent__*). Each agent owns its own browser lock; the prompt explicitly forbids falling back to generic tooling like mcp__playwright-extension__ or mcp__isolated-browser__, because those would bypass the per-platform lock and cause session conflicts.

pending -> processing -> replied, with skipped and error as terminal branches. Writes go through scripts/reply_db.py only. The flow is: python3 reply_db.py processing ID before any browser action claims the row with processing_at = NOW(); then the browser_run_code call does the DOM check and, if clear, fills the textarea and clicks save; then python3 reply_db.py replied ID 'text' [url] [engagement_style] promotes to 'replied'. If Step 3 fails, the row stays at 'processing' and the 2-hour UPDATE at the top of the next run moves it back to 'pending'. The prompt's instruction 'NEVER use psql directly' is a correctness rule, not a style preference: reply_db.py is the only code path that respects the state transitions.

Speed and determinism. The engage.sh prompt says it directly: 'Do NOT use browser_snapshot, browser_click, or browser_type for Reddit replies. browser_run_code is 5x faster.' A single Playwright function inside the page has full DOM access, runs all selectors and evaluations in-process, and returns one value. The snapshot-then-click pattern requires a serialized YAML of the page, an LLM parse of that YAML to find element refs, then a separate click/type round-trip per action. On a batch of 200 replies, that difference is the gap between a 10-minute run and a 50-minute run.

The 'processing' status is the lock. python3 reply_db.py processing ID uses a conditional UPDATE (status = 'pending' -> 'processing') so the second agent sees zero rows affected and moves on. Reply discovery runs separately from reply posting (com.m13v.social-scan-reddit-replies on its own launchd schedule), so the posting loop never competes with itself for discovery. Per-platform browser agents each own their own lock file; the prompt forbids fallback to a generic agent specifically because that would break the lock and cause session conflicts in the browser profile.

Twitter and LinkedIn engagement are handled by engage-twitter.sh and engage-linkedin.sh, on their own launchd schedules. Each script ships an analogous DOM check: the Playwright snippet looks for the account's own handle or display name among the existing reply list before typing. The split into per-platform scripts, each with its own lock, is deliberate. engage.sh comments it: 'Each runs on its own launchd schedule so a single-platform failure cannot block the others.' This is the opposite of the unified-queue design most autoposters use.

Yes. Every reply prompt ends with an explicit guardrail block: never suggest calls, meetings, demos; never offer to DM; never make time-bound promises; never promise to share files you don't currently have. This is embedded directly in the prompt so the drafting model cannot volunteer actions that the automation has no way to fulfill. It is the reason the bot will not promise to 'send you a link tomorrow' even when a comment asks for one. If the link is in config.json, it shares it now. If not, it keeps the conversation in-thread.

You don't. S4L does not have a posting calendar, a unified inbox for customer support, brand-asset management, or a team approval workflow. It is a comment and reply engine with a data-driven tone selector on top. If you need a schedule and an inbox, keep Buffer or Hootsuite. If you need a bot that posts through a real browser and cannot double-reply even when it crashes, run S4L alongside them. The two do not overlap on the thing S4L is actually trying to automate.