social-push: a Claude Code skill that drives agent-browser to post on Chinese social platforms

The gap social-push fills: browser automation that survives a redesign

Publishing the same article to Xiaohongshu, Zhihu, Weibo, WeChat and Juejin means five different editors, five image-handling rules, and five sets of selectors that break whenever a frontend ships. The README states the problem directly: traditional scripts struggle with complex page changes, and playwright mcp consumes a large number of tokens and is slow. social-push is aimed at people who already live in Claude Code and want the publishing step to happen inside the same session where they wrote the post. It is not a scheduling service and not an API client. It is a skill, meaning a directory of instructions plus reference files that Claude Code loads on demand. The target user is a solo operator or small team publishing Chinese-language content, comfortable with a terminal, willing to log in manually once per platform, and content to approve a draft rather than fire and forget. If you publish through official platform APIs, this is the wrong layer entirely.

How the mechanism works: markdown workflows, browser refs, and a draft-only rule

The architecture is thin by design. social-push/ contains SKILL.md, the skill definition, and references/, one markdown file per platform and content type: 小红书图文.md, 小红书长文.md, X推文.md, 掘金文章.md, with the README noting more can be added. The model reads the relevant reference file, then drives agent-browser, which parses page elements into interaction refs. That ref layer is the token argument in the README: instead of dumping page HTML into context, agent-browser exposes a compact reference the model can act on. Because the procedure lives in prose rather than compiled selectors, a layout change is a text problem. That is what the self-evolution bullet means in practice: the workflow is a document the agent can inspect and correct, not a script with hard-coded paths. Two other design choices matter. First, --state keeps a login session across runs, so authentication is a one-time manual step. Second, the README's safety bullet says the skill stages drafts only and does not auto-publish, leaving final confirmation to the user. That last point is the most consequential line in the whole repository, because it reframes the tool from an automation bot into a drafting assistant.

Installation and the first-run browser handshake

The README's install path assumes Claude Code is already present. Dependencies come first: npm install -g agent-browser, then npx skills add https://github.com/vercel-labs/agent-browser --skill agent-browser, then agent-browser install to download Chromium. The skill itself installs with npx skills add jihe520/social-push, or by copying the .claude/skills/social-push directory into a project. Invocation is manual: the README says to type /social-push in Claude Code. The first-run story is where the documentation gets honest about friction. The default is --auto-connect, which attaches to the browser you already use, and the README recommends this because your own browser's state is stable. Alternatives are listed with their trade-offs spelled out: --state ~/my-state.json preserves login but not article drafts, while --profile ~/my-profile preserves both but may have compatibility problems. Some platforms cannot be logged into through automation at all and require a manual swipe or captcha. The README supplies a prompt to paste into Claude Code that walks through locating the ms-playwright Chrome for Testing app, opening it with --remote-debugging-port=9222, verifying with curl -s http://localhost:9222/json/version, connecting via agent-browser connect with the websocket URL, and finally agent-browser state save ~/my-state.json. The README also instructs enabling remote debugging at chrome://inspect/#remote-debugging. Customisation is a single documented edit point: the # Rules section of SKILL.md.

Where this breaks: manual login, no releases, and an undefined licence

The largest practical constraint is authentication. The README concedes that some sites cannot be logged into with automation and need a manual step, which means a fresh machine, a cleared profile, or an expired session can stall the whole flow until a human intervenes. There is no documented token refresh, no credential store beyond a state file or profile directory, and no headless story: the README leans on --headed visible browsing for debugging and monitoring, which suits a desktop operator and not a server. The distribution side is equally thin. No releases are listed, so installation is a git clone or an npx pull from the default branch, and there is no version pin to hold a working setup steady. The licence is not identified in the supplied material, which means anyone embedding this in a commercial pipeline should read the repository's own licence file before doing so; I cannot state terms that are not present. Finally, the self-evolution claim is the least verifiable part. The README asserts that workflows can detect and repair themselves after a redesign. What is visible in the repository layout is markdown reference files, which is consistent with that claim, but the mechanism for detecting a break, and what the agent does when a repair fails, is not described. Treat self-repair as a convenience for small layout shifts, not a guarantee.

Compared with Playwright scripts and hosted publishing tools

The nearest conventional alternative is a Playwright script per platform: a Node or Python file with explicit selectors, run from cron or CI. That approach is deterministic and testable, and it fails loudly when a selector disappears. social-push trades that determinism for adaptability. Its selectors are resolved at run time by the model reading the page through agent-browser's refs, so a renamed button often costs nothing, while a genuinely new dialog costs a model round trip and possibly a manual correction. The other common alternative is a hosted cross-posting service, which typically asks for platform credentials or OAuth and publishes on a schedule. That is a different trust model: you hand over account access and get unattended posting. social-push keeps credentials in a local browser profile and keeps the human in the loop by staging drafts only. Neither is strictly better. If you need scheduled, unattended, auditable publishing, a hosted tool or the platforms' own APIs fit better. If you want the publishing step to sit next to the writing step and you are willing to click the final button, social-push is the smaller commitment.

Maintenance cost and what to check before relying on it

Running cost is mostly environmental. agent-browser and Chromium need periodic updates, and a browser upgrade can invalidate the remote-debugging handshake described in the README, which is why the connection sequence is worth keeping as a script rather than retyping. Because there are no releases, upgrades mean pulling the default branch again, and a change to SKILL.md's # Rules section or to a references/ file can alter behaviour between runs with no version marker to point at. Adding a platform is the documented extension path: create a markdown file in references/ following the existing format, and the README invites contributions on exactly that basis. That is cheap maintenance, but it is maintenance you own. The licence question remains open in the material supplied here, so a team planning to redistribute the skill or ship it inside a product should confirm the terms from the repository itself rather than from this description.

Editorial conclusion

Adopt social-push if you already run Claude Code, already have agent-browser installed, and post to Chinese platforms often enough that a repeatable draft-staging flow beats copy-paste. Do not adopt it if you need unattended publishing, a documented API, or a stable licence position: the repository ships no licence file that the supplied material identifies, and no releases are listed. Before installing, verify three things: that agent-browser is installed and Chromium downloaded, that remote debugging is enabled for the browser instance you intend to connect to, and that the platform reference file you need actually exists under references/.

Official sources

1. Issues
2. jihe520/social-push on GitHub
3. README