cli-anything

CLI-Anything is HKUDS's Claude Code marketplace plugin (and parallel installs for Pi, OpenClaw, OpenCode, Codex, Goose, Qodercli, GitHub Copilot CLI) that takes a path or GitHub URL of a GUI application and emits a complete Python Click CLI for it — /cli-anything ./gimp runs a 7-phase pipeline that ends with pip install -e . and cli-anything-gimp on PATH. The framing in the README is "Today's software serves humans. Tomorrow's users will be agents" — the pitch is that GUI automation, screenshot-and-click RPA, and dumbed-down SaaS APIs all fail at giving an agent the real capabilities of professional software, and the right shape is a generated CLI that calls the actual backend (bpy for Blender, melt for Shotcut/Kdenlive, sox for Audacity, headless LO for LibreOffice) with no toy reimplementation.

How it works

The methodology is a single document — cli-anything-plugin/HARNESS.md — that every agent integration loads as a skill. The seven phases:

1. Codebase analysis — find the backend engine (the GUI is a thin shell over a library), map GUI actions to API calls, identify the project file format, catalog any command/undo system.
2. CLI architecture design — pick stateful REPL + subcommand CLI (default: both), define command groups around the app's logical domains (project, core ops, import/export, config, session), design the JSON state model, plan dual --json / human output.
3. Implementation — start at the data layer, add probe commands before mutations, build a utils/<software>_backend.py that wraps the real software's CLI, add session management with file locking, and wrap everything in a unified REPL via the shared repl_skin.py. The Click group is set up with invoke_without_command=True so cli-anything-gimp with no args drops into the REPL.
4. Test plan — write TEST.md listing planned test files, unit-test inventory, E2E workflows, and what output properties each E2E test will verify. This file is required before test code exists.
5. Test implementation — unit tests with synthetic data, E2E tests that invoke the real software backend (no graceful skip if the software is missing — tests fail), output verification by magic bytes / ZIP structure / pixel analysis / RMS levels, and CLI-subprocess tests against the installed command.
6. Documentation — update TEST.md with results, generate SKILL.md (Phase 6.5) from Click decorators, setup.py, and README via skill_generator.py.
7. Publish — setup.py, pip install -e ., the binary lands in PATH.

A /cli-anything:refine ./gimp [focus] command runs gap analysis between the software's full capability surface and current CLI coverage, then implements new commands incrementally — non-destructive, run-as-many-times-as-you-like.

Two outputs per harness: CLI binary + SKILL.md

Every generated harness ships a canonical SKILL.md at skills/cli-anything-<software>/SKILL.md (the monorepo is consumable via npx skills add HKUDS/CLI-Anything --skill <name>) and a packaged compatibility copy at cli_anything/<software>/skills/SKILL.md. The REPL banner prints the skill's absolute path so the agent driving the REPL can read it.

This is precisely the pattern mcp-vs-skills argues for — the CLI binary is the capability (with proper auth, real backend, structured JSON output), the SKILL.md is the knowledge (how to use it, parameter gotchas, output format). CLI-Anything generates both halves at once. It's not a counter-example to Mohl's argument; it's a worked instance of the hybrid pattern, where the "service" is a local subprocess and the SKILL.md annotates how the agent should drive it.

The flip side: a generated CLI is still a local binary, not a remote MCP. Portability across compute-less environments (mobile Claude, web ChatGPT) doesn't apply — agents need shell access. CLI-Anything explicitly only targets compute-equipped agent harnesses (flue, Claude Code, Pi, pi-coding-agent, OpenClaw, Codex).

CLI-Hub: the catalog and the meta-skill

pip install cli-anything-hub gives a package manager (cli-hub install <name> / update / uninstall) backed by public_registry.json — sources include pip, npm, brew, and bundled tools, so it's not just a wrapper for the in-tree harnesses. The web frontend at clianything.cc browses both CLI-Anything CLIs (in-tree generated harnesses) and Public CLIs (third-party tools they curate).

The interesting piece is the meta-skill — a separate skill an agent installs once that points at a live catalog (reeceyang.sgp1.cdn.digitaloceanspaces.com/SKILL.md) listing every available CLI with one-line install commands. The agent reads the meta-skill, picks whichever CLI fits the task, runs the install, then reads that CLI's own SKILL.md. Auto-updates whenever registry.json changes — new community CLIs appear without re-publishing the meta-skill. This makes the registry agent-discoverable rather than human-discoverable.

Coverage and testing claims

The README enumerates 18 demo applications with 2,269 passing tests as of April–May 2026 — GIMP (107), Blender (208), Inkscape (202), Audacity (161), LibreOffice (158), OBS Studio (153), Kdenlive (155), Shotcut (154), plus FreeCAD (258 commands), QGIS, Godot, Krita, Draw.io, Mermaid, Excalidraw, RenderDoc, MuseScore, Zotero, Obsidian, n8n, WireMock, Exa, VideoCaptioner, ComfyUI, Stable Diffusion WebUI, AnythingLLM, Slay the Spire II, and others. The tests-must-fail-not-skip rule is load-bearing: it's how the CLAIM "we exercise the real backend" is enforced.

There are real demo videos (FreeCAD building a Curiosity-style rover, Blender building an orbital relay drone, Draw.io producing an HTTPS handshake diagram, agent playing Slay the Spire II) — the demos use a preview + preview live + trajectory.json triplet so the human can watch state evolve while the agent runs. Trajectory replay is part of the harness, not a one-off demo prop.

Limitations

• Python ≥3.10 only. No support for Go/Rust/Node-shaped harnesses; the plugin assumes Click + setup.py.
• Requires the target software installed locally. The find_<software> helpers in utils/<software>_backend.py raise RuntimeError with install instructions, but they don't install anything — agents need to know to run apt/brew/winget themselves.
• Generated quality varies with codebase legibility. The 7-phase pipeline assumes the GUI is a shell over a library with a clean command/API surface. Apps with tightly coupled UI logic, opaque proprietary backends, or no scripting hook will produce shallow harnesses (or fail at Phase 1).
• Stateful REPL state is JSON files on disk. Concurrent agents on the same harness need to coordinate via the file-locking pattern; the harness doesn't ship a daemon mode.
• Windows compatibility is best-effort. Several CLIs require cygpath (Git for Windows or WSL); the README notes specific workarounds for Claude Code on Windows.

Use cases that genuinely fit

• An agent that needs to render a 3D scene end-to-end with bpy without GUI overhead.
• Pipelining LibreOffice → PDF / DOCX / XLSX / PPTX in a CI job from agent-generated content.
• Audio production where the agent chains Audacity + sox without screenshot-driven RPA.
• Building per-customer agent-driven workflows over an open-source SaaS competitor (NextCloud, Mattermost, Plane, n8n) without writing 50 REST wrappers.
• Synthesizing benchmark tasks for GUI agents — once the CLI exists, you can generate evaluators and trajectories in code rather than recording UI sessions.

Stars and license

github.com/HKUDS/CLI-Anything — 33,258★, Apache-2.0, primary language Python, created 2026-03-08, last push 2026-05-02. HKUDS = Hong Kong University Data Science lab; multi-author research org behind LightRAG and other agent-tooling work. Active community contribution flow with merged CLIs from external authors (@TianyuFan0504, @WEIFENG2333, @zhangxilong-43, etc.) — not single-vendor.