Social OS Starter: the control surface before the post

You do not have a social-posting problem yet.

You have an inbox full of public signals. Reddit threads. Hacker News comments. Product Hunt feedback. GitHub issues. Replies from people who might be serious, confused, annoyed, useful, or pure noise. One builder described the job as separating “real signals from noise” across public threads, then deciding what becomes a feature, docs, positioning, a reply, or nothing.

That decision happens before the post exists. So this page should be read as the operating design before the clone link exists: what the starter has to make visible, what it has to constrain, and what a reviewer should inspect before a social workflow earns a schedule.

The caveat matters. No public social-os-starter repo, clone URL, README, license, setup path, shipped file tree, or starter-specific CTA was verified in this run.

The draft is the visible artifact. The system is everything around it.

Social starts before the post

A model can write a reply. Most good models can do that now. Give it a thread, a voice note, and a point of view, and you will get words back.

The harder question is whether that thread deserved a reply in the first place.

Some public feedback should become product work. Some should become documentation. Some should change how you describe the category. Some is worth answering in public. Some should be ignored, even if it is loud.

That selection step matters because social work carries brand risk. A product builder can batch posts and still worry that the output becomes “rushed or off-brand”. A social workflow can be “more than a scheduler” because approvals, onboarding, internal context, client context, and brand voice all sit around the calendar.

The useful unit is not “a post.”

It is a reviewable batch.

That is the job Social OS Starter should organize: source intake, target selection, voice and claim rules, output queues, human review, and a record of the decision. The closest concept is folder-as-program: a folder that gives an agent the entry point, config, state, examples, and outputs for a repeated job.

The folder makes the work visible

A credible starter needs to make the repeated job inspectable.

Not fancy. Inspectable.

At minimum, we would want the starter to expose an instruction file, a README, config.yaml, steering docs, content output folders, review records, and examples. Treat those as intended operating surfaces, not as a verified public file tree for this page yet.

The config.yaml tells the workflow what it is trying to do: platforms, source rules, target communities, cadence, approval rules, and stop conditions. The steering/ docs tell it what it is allowed to sound like and what it is not allowed to claim. The output folders show what happened: candidates, drafts, approved items, rejected items, revision notes, and batch state.

A long chat thread hides that work inside model context. A folder makes the work visible enough to inspect. That is why the pattern belongs beside source-grounded workflows like agentic research workflow: repeated agent work needs stable inputs, visible outputs, and state you can audit.

Instruction files are context, not review

Folder-aware agents make this practical because scoped instruction and tool-context surfaces are real now. The pattern shows up in repository AGENTS.md guidance for Codex, project CLAUDE.md memory for Claude Code, OpenCode AGENTS.md rules, and Model Context Protocol tool context.

All of that helps.

It does not make instructions safety. A voice file can steer a draft, but it cannot decide whether this reply should go out today. A claims file can tell the agent what is approved, but it cannot prove that a new situation is safe. Tool connections can fetch context, but they do not create editorial judgment or approval state by themselves.

That is why the starter needs a human gate and visible artifacts. The files give the agent context. The review gate decides what becomes public. The record tells the next run what the human decided.

Approval needs a packet

The obvious objection is fair. If the workflow is “agent drafts and human approves,” did the agent help, or did it create a new job? One operator put the anxiety more bluntly as “babysitting the bot”.

The fix is not to pretend approval disappears. The fix is to make approval worth doing.

A useful approval packet is small enough to read and specific enough to decide.

For example:

• Source: a public thread where someone is trying to separate “real signals from noise.”
• Selection reason: the question is about workflow judgment, not a generic content idea.
• Draft action: reply, save for docs, turn into product feedback, or ignore.
• Voice basis: the brand rule that says when to be direct, when to be careful, and what not to promise.
• Claim boundary: no invented customer proof, no outcome metric, no “we solve this automatically.”
• Decision: approve, revise, reject, escalate, or save as product or docs feedback.
• State after review: what changed, who decided, and what the next run should remember.

Now the reviewer is not grading random text. They are deciding whether a specific public action should leave the system.

That distinction matters because social mistakes are usually context mistakes. The reply might be well-written and still answer the wrong thing. The caption might sound fluent and still drift from the client’s voice. The draft might be true and still imply a claim the brand cannot defend.

The review record is part of the product of the run. This is the same reason we care about how to review AI social content and Content QA as Code: the decision is more useful when it can shape the next workflow.

Manual Sync is a control feature

The naive automation story says manual execution is primitive. For public brand conversations, that is backwards.

Manual Sync mode is where you inspect the workflow before you trust a schedule. You run one batch yourself. You look at the sources it selected. You read the drafts. You inspect the approval packet. You reject the weird calls. You tune the steering docs.

Only then does scheduled Async execution make sense. The paid path is not “AI writes posts while you sleep.” That is how unattended loops become brand risk. The paid path is reliable execution, team approvals, history, secrets, tuning, and someone owning the operational work once the manual workflow has proved itself.

Services sit one step later: setup, tuning, and operated delivery when the workflow matters enough that you do not want to maintain it alone.

What to inspect before a schedule

Before you trust a Social OS starter, ask five questions.

Can you see the source conversation and why it was selected? Can you see the voice and claim rules used for the draft? Can you see what the reviewer is approving, rejecting, or escalating? Can you see where the output lands after approval? Can you see what decision survives into the next run?

If those surfaces are missing, you do not have a social operating system. You have a prompt folder, a scheduler, or a very confident bot.

The public repo can arrive later. When it does, this page should become more concrete: actual file tree, setup path, examples, clone link, and outputs. Until then, the honest version is the useful one. Start with source, constraint, review, state, and decision memory around the words an agent writes.

The schedule is earned when the decision survives the run.