autocli-skill: a Claude Code skill that drives a Rust CLI over your Chrome sessions

The gap autocli-skill fills: agent has no platform access

An agent that can read your repository and run shell commands still cannot read Bilibili trending, search Zhihu, or pull your WeRead highlights. The README frames the problem exactly that way: you want Claude or OpenClaw to browse these sites, but the assistant has no access to them. The standard workarounds each cost something. Playwright automation means writing and maintaining selectors plus handling login state yourself. Official platform APIs often require an application process that individual users cannot complete. autocli-skill takes a third route: it wraps an existing command-line tool, nashsu/AutoCLI, and teaches the agent when and how to call it. The skill itself is not the thing that talks to the web. It is the instruction layer that turns a natural-language request into a specific autocli invocation.

How the Chrome session reuse actually works

Three components sit in a chain. First, a Rust binary named autocli, described in the README as a 4.7MB single binary with zero runtime dependencies. Second, a Chrome extension, downloaded from the AutoCLI GitHub releases page, which lets the binary drive the browser. Third, this skill, which supplies the agent with command knowledge. The README splits platforms into three modes. Public mode needs no browser and calls an API directly; HackerNews, Dev.to, Lobsters, StackOverflow, Wikipedia, Arxiv and BBC are listed there. Browser mode requires Chrome plus the extension, and covers Twitter/X, Bilibili, Reddit, Zhihu, Xiaohongshu, YouTube, Weibo, Douban, WeRead, Xueqiu, BOSS直聘, Facebook, Instagram, TikTok, Jike, Medium, Substack, LinkedIn and Yahoo Finance. Desktop mode requires the target application to be running; Cursor, Notion, ChatGPT, Discord and Codex fall into it. The login reuse is the design decision that matters here. Because autocli drives a Chrome instance you are already signed into, there is no OAuth flow and no API key to store.

Install path: npx skills add and a binary you install separately

The README gives two installation routes for the skill. The first is conversational: you paste the repository URL to your agent and ask it to install the skill. The second is a single command, npx skills add https://github.com/nashsu/AutoCLI-skill, followed by a restart of Claude Code. Note what is not included. The skill installation does not install autocli. The prerequisites section lists Chrome open and logged in to the target platforms, plus the autocli Chrome extension from the AutoCLI releases page, and then sends you to github.com/nashsu/AutoCLI for the CLI itself. So a working setup is at minimum three installs across two repositories. Once running, invocation is plain language. The README's examples include "Search YouTube for LLM tutorials", "Get the top 20 stories on HackerNews", and "Check AAPL stock price". Underneath, those map to commands such as autocli bilibili hot --limit 10 --format json, autocli reddit hot --subreddit MachineLearning, and autocli yahoo-finance quote --symbol AAPL. The --format json flag appears repeatedly, which matters if you want the agent to parse output rather than read a table.

Where this design breaks: headless servers, timeouts, login drift

The architecture has a hard dependency on a running Chrome with a loaded extension. That rules out the common deployment shape where an agent runs in a container or on a remote host with no desktop session. Desktop mode narrows things further: Cursor, Notion, ChatGPT, Discord and Codex commands only work while those applications are open. The troubleshooting table in the README is itself a list of failure modes. Browser commands can time out, and the suggested check is autocli doctor. Login state may not be recognized, and the fix is to log in to the target site manually in Chrome first. If Chrome is not being controlled, you verify the extension is loaded. There is also the question of account risk. Commands like post, reply, like, follow, comment and batchgreet act on your real logged-in accounts, and the README does not discuss rate limits, platform terms, or what happens when a platform changes its front end and the extension stops matching. Treat write commands as the risky half of the command surface.

What the repository does not tell you

The material supplied here lists the primary language as unknown and the licence as unknown, and no releases were retrieved. For a tool whose core value is driving authenticated sessions, that is a real gap. You cannot check what licence governs redistribution, and there is no tagged release to pin. The README credits nashsu/AutoCLI as a Rust rewrite of opencli and states it is up to 12x faster with 10x less memory, but that comparison is the upstream project's claim, not something this review verified. The supported-platform table lists 55+ platforms while naming roughly thirty in detail and pointing at autocli --help for the rest, so the exact command surface for the tail is something you discover locally. None of this makes the project unusable. It does mean the skill is best treated as a convenience layer over an upstream binary whose own documentation you will need to read.

Alternatives: Playwright scripts, official APIs, and MCP servers

The closest alternative is writing your own Playwright or Puppeteer scripts. That gives you explicit control over selectors, retries and storage state, and it runs headless on a server, which autocli-skill cannot do in browser mode. The cost is that you maintain every platform's scraper yourself, and login state becomes your problem again. The second alternative is official platform APIs. They are stable and documented, but the README's own framing is that many platforms require an application process ordinary users cannot complete, and each API has its own auth model, so a multi-platform agent ends up holding many credentials instead of one Chrome profile. A third pattern is an MCP server per platform. That fits agents with MCP support more natively than a shell-command skill does, but you would be assembling and configuring several servers rather than installing one skill plus one binary. autocli-skill's bet is breadth through a single interface and a single login source.

Maintenance cost and licence exposure

Upgrade cost concentrates upstream. This repository has no releases, so there is nothing here to version against. When a platform changes its markup, the fix lands in AutoCLI or in the Chrome extension, and you take it by updating those, not by editing the skill. Practically that means your agent's reliability tracks a project you did not install through the skill command. The licence question is unresolved in the supplied material: with the licence field unknown, you cannot reason about whether you may redistribute the skill internally or bundle it into a product. That is a fact to establish before any commercial use, not a legal conclusion. If you only need public sources, the Public-mode platforms (HackerNews, Wikipedia, Arxiv, StackOverflow and similar) avoid the Chrome dependency entirely and are the lower-risk place to start.

Editorial conclusion

Adopt autocli-skill if you already run Claude Code or OpenClaw, keep Chrome open with the target sites logged in, and accept that the skill is only a thin instruction layer over a separate Rust binary and a Chrome extension you install yourself. Skip it if you need headless execution on a server, a documented licence, or a pinned release to audit, because the README supplies none of those. Before installing, verify three things: that the AutoCLI binary at github.com/nashsu/AutoCLI builds or ships for your platform, that the autocli Chrome extension from its releases page loads, and that autocli doctor returns clean output once Chrome is open.

Official sources

1. Issues
2. nashsu/autocli-skill on GitHub
3. README