claude-skill-social-post ships with the send switch turned off

A skill that learns a voice, plans a calendar and posts after you confirm

claude-skill-social-post installs into Codex or Claude Code as a skill directory, and there is also a reduced ChatGPT Chat version. The pipeline it describes is the interesting part: it learns the voice of your local writing profile, plans content, writes platform-specific posts, publishes only after a confirmation step, manages comments on Facebook, Instagram and Threads through a logged-in Chrome that it controls, and stores cross-platform insights as structured, verifiable data.

The repository description adds a concrete claim about results, saying the project was validated with 80K reach, 448 likes and 500 comments on a first post, and that it includes a postmortem of a day two flop. Those are the author's own numbers for their own account rather than a measured benchmark, and they are the kind of figure worth treating as a prompt to look at the calendar and the ledger rather than as a promise. The claim also names a 14-day content calendar, which matches the planning stage of the pipeline.

The target user is therefore someone posting as themselves, on their own accounts, who wants an agent to do the drafting and the bookkeeping but not to publish without a human in the loop. That positioning is deliberate and it is repeated in the governance files.

The project is written in JavaScript, MIT licensed, and released as versioned tags such as Social Post v2.5.1.

Reading and sending are separate switches on the main branch

The single most important line in the README is a warning about the current state of the send path. The main branch separates the read switch from the send switch, target-only backfill of a designated native comment has been demonstrated on Facebook, Instagram and Threads, whole-thread scanning is not open, and live_browser_actuation_enabled still defaults to false.

That default is the whole design philosophy of the project in one flag. A comment reader can be pointed at one specified comment and fill in that comment's author, full body and source evidence. It refuses to claim a full thread scan was completed. For Threads, the reader requires an explicit root and focus pagelet context, native time links and a full body, and it performs a double read of the account to confirm it is looking at the right comment. Wrong parent layer, truncated text, still-loading content, or a URL or account mismatch all end in rejection. The phrase no reply yet is recorded only as a candidate signal, never as proof of an empty thread and never as permission to send.

The Facebook reader got its own full-body reader in this release, covering image alt text and line breaks, author ambiguity, online-status links and parent-child URLs, plus negative tests for a page change during verification. One real exact-tab reuse and a private ledger backfill were completed there, and no Facebook comment was sent.

The Threads icon-style reply button got a separate semantic SVG node binder that keeps the existing Instagram and generic text recognition. Hidden text, extra icons, a mismatched label or node drift cause a rejection, and the helper is explicitly not allowed to click, type or authorise a send.

The ledger is what stops a duplicate post

Publishing is guarded by a durable ledger rather than by a string return value. Since v2.5.0 a bare WRITE_OK string is no longer accepted. browser-begin must first write to an append-only ledger atomically, and only then emit a field-bound SUBMIT_CLAIM. A process-wide reservation combined with the durable ledger is what blocks concurrent attempts, a rebuilt actor and cross-process replay.

The binding is strict. An approved action is re-hashed with SHA-256 and tied to the action, a fresh locator plan, a strong comment anchor, the same parent layer reply controls and a zero-own-reply baseline, and a mutable locator expected value cannot overwrite the approved evidence.

Post-send verification is equally narrow. A send counts as verified only when the thread is fully expanded, every reply item is inspectable, the exact parent layer goes from zero to exactly one own-account exact reply, and the total reply count is at least the pre-send baseline plus one. A reply count that goes backwards, pre-existing evidence, hidden, malformed or duplicate items all fail closed.

Failure has a dedicated state. Any timeout, navigation, contradictory state or unknown result moves the record to needs_reconcile, and a circuit breaker blocks further actions and preflight for that session, platform, account and post until reconciliation is done. When re-checking stays unclear the outcome is NO_CHANGE rather than a retry, and the resume never auto-reclicks. browser-scan persists a completion event so that a request that never ran can be told apart from a scan that finished and found nothing.

In one real Instagram run the sequence was a single send, an immediate read-back that was not sufficient, a stop, a new session read-only recovery and finally a ledger confirmation of sent, with no resend.

Three levels of evidence, and the one that is still missing

The project keeps a closed-world capability ledger that separates a contract being green, a real browser fixture passing, and a live Meta canary. The distinction exists so a missing browser backend or a missing login authorisation cannot be dressed up as a completed capability.

The evidence in this release is layered as well. The new process passed 18 native governance tests and 28 isolated Chromium interface checks, and the interface checks use fictional data rather than real Meta accounts. Localhost browser end-to-end runs on Facebook, Instagram and Threads scanned two posts per platform, accepted one send, and verified the exact parent and the exact reply, but the resulting evidence is still tagged as a localhost test only candidate and in-memory only, with promotion and live actuation both false.

Fixtures are labelled test_only and the Python live ledger rejects them outright. URLs are checked too: credentials in the URL, a non-default port, or a different host, path or query are refused. The browser client uses a single approved lazy import, and before loading it the code verifies a pinned revision, the bytes and a SHA-256 checksum, writing an architecture receipt; a missing file, a duplicate import, an eager import or any drift in those fields fails closed.

The Chrome runtime itself is pinned, and this release moves the Codex Chrome runtime to version 26.825.51511 with byte and SHA-256 verification retained.

What is explicitly not proven is the headline: the candidate release still has not completed three-platform real auto-reply acceptance, and offline tests cannot stand in for login operations on Facebook and Threads, for a full reply thread, or for parent-layer verification.

The voice profile is frozen, versioned and never auto-applied

The learning side is where the private writing contract comes in. New data becomes an observation or a candidate modification only. A formal update follows a fixed path: full context and evidence first, then author review of a designated version, then a separate activation, and that activation affects only the approved platform and media partitions. The original sources and the previous version are kept.

The contract itself freezes the installed voice, the F writing style and the rule sources, and binds each draft to a designated F, a format and an official version. Expired versions, source drift and structural violations are rejected. The README is explicit that a structural check cannot replace semantic and factual review by a human, and that is a fair statement about any linting of prose.

The workbench behind this was updated to version 0.2.0 and divides learning into ten partitions, five platforms by image or video. Comparability is restricted: within a platform, cases are chosen by content type, surface and maturity, and a winner from another partition is never used to fill a gap. External cases and your own outcomes are stored separately.

Structured analysis stores more than reach numbers. It keeps the SHA of the original text, a deterministic length, layout attributes such as white text on black, keywords, entities, numeric language, voice, call to action, full Unicode punctuation, and the date, weekday, HH:mm and daypart. A coverage gate then has to prove that the full text, length, layout, keywords, tone, punctuation, publish time and outcome actually reached the feature matrix, with newly named fields routed to extended_analytics and low-confidence placeholders kept out of the pattern.

On causality the project holds a firm line. Planning and drafting must read canonical comparables first, and only same platform, same maturity, same content type and same surface outcomes may be compared. Posting minute is treated as a candidate factor with causal_claim_allowed set to false, so two posts published minutes apart are not treated as proof that the minute caused the traffic difference.

Installing the skill for Codex, Claude Code or ChatGPT

Installation is a clone followed by a copy of the social-post directory into the skills folder of whichever tool you use:

git clone https://github.com/Hao0321/claude-skill-social-post.git

On Windows with PowerShell, for Codex, create the skills directory and copy the skill into it:

New-Item -ItemType Directory -Force "$env:USERPROFILE\.codex\skills" | Out-Null
Copy-Item -Recurse ".\claude-skill-social-post\social-post" "$env:USERPROFILE\.codex\skills\social-post"

For Claude Code the destination changes to .claude\skills\social-post, and on macOS and Linux the same copy goes to ~/.codex/skills/social-post/ or ~/.claude/skills/social-post/. The first use creates a personal profile that exists only on the local machine, starting from the style_profile example file that ships with the skill.

There is a genuinely different third option. The ChatGPT Chat version uses the public rules in chatgpt-socialpost/SKILL.md through the skill creation flow, while the personal voice note stays in your own settings. That reduced version contains no local analysis scripts, no Chrome comment operations and none of the author's private samples, so installing it does not amount to a completed personal voice calibration. The README also asks that private posts, account data and credentials never be committed to the repository.

What is public, what is local and what stays unproven

The published repository contains generic code and anonymised tests only. Real comments, drafts, account insights, original text, photos and private credentials are outside the release scope. The private voice, real posts, account outcomes and comments stay on each contributor's own machine, and the public tests use fictional data.

That split explains the shape of the codebase. The top-level listing holds the skill itself in social-post/, the reduced ChatGPT version in chatgpt-socialpost/, tooling in tools/, documentation in docs/, and the governance files CONTRIBUTING.md, GOVERNANCE.md and ROADMAP.md, plus an audit.config.json. The README notes that Cleanup deliberately keeps fixed code length warnings and untested items in place instead of raising thresholds to make them disappear, and that some cross-language diagrams and a private no-origin update source are still not verified by Cleanup.

So there are limits beyond the send switch. Whole-thread scanning is not open, so the reader gives you one specified comment rather than a conversation view. The three-platform real auto-reply path has not been accepted. Chrome disconnection recovery is narrow: it reselects only once, only after an exact disconnection error on the cached browser, only for the same source and Chrome family, and it never clears the anti-duplicate record. An empty tab, a general timeout, an invalid page or a permission refusal will not trigger a reconnect, and even after one real recovery the project does not claim every disconnection cause is handled.

If your need is unattended multi-account publishing, this skill is the wrong instrument by design, since the send switch defaults to false and every send is bound to an approved action and an explicit confirmation.

MIT licence, single maintainer, fast release cadence

The licence is MIT and the project states that it stays MIT licensed as it grows. The governance model is explicit: anyone can open an issue or a pull request, the author keeps sole top-level administration, merge review and release authority, and recognised partners can take part in module development and review. Each pull request is expected to state the use case it improves, the evidence before and after the change, and its limitations, and it then goes through tests and maintainer review.

Release cadence has picked up. Tags include Social Post v2.5.1 on 2026-10-15, v2.2.0 on 2026-08-23, described as a privacy-safe learning engine, and v2.1.1 on 2026-08-13, described as adding account-level outcome records. The last push was on 2026-10-15, so the project is changing quickly and the newest tag tracks the branch closely.

That velocity is a cost as well as a benefit for adopters. The README is explicit that this release does not promote a production capability that has not yet been accepted, which is the right call, but it also means the documented behaviour of a given version can be rewritten weeks later. If you adopt it, pin a tag rather than following main, and expect to read the changelog entries for the version you pinned to see which capability claims apply to it.

Editorial conclusion

claude-skill-social-post suits one person or a small team that already posts on their own accounts and wants the drafting, voice capture and comment bookkeeping handled locally by a skill they can inspect. It is the wrong tool for unattended publishing, for multi-account operations, or for anything that needs a documented guarantee that a reply reached a platform, because live_browser_actuation_enabled is still false and the three-platform reply path has not been accepted. Before adopting it, read GOVERNANCE.md and ROADMAP.md in the repository, then confirm on your own account that the comment readers behave correctly on the interface version the Chrome runtime is pinned to.

Frequently asked questions

Official sources

1. Hao0321/claude-skill-social-post on GitHub
2. License: MIT
3. Project website
4. README
5. Releases