The Command Line for Everything
Give Claude, Codex and other agents a real interface to the software they could never reliably use.
CLI-Anything is an open-source project that gives agents command-line interfaces for desktop and backend software. Start with CLI-Hub, search the registry, and install an existing harness. If the software is missing, its generator can inspect a source repository and build a new CLI through a seven-phase process covering analysis, design, implementation, tests, documentation and packaging. The important limit is that a generated CLI still needs the real software and must verify the artifact it produces. Section seven is the part to read before trusting it with serious work.
Why can an AI agent write an application from scratch, then struggle to make one dependable change inside GIMP, Blender or LibreOffice?
Because most software was designed for hands and eyes. A person can look around a menu, notice that a window changed, and recover when a button moves. An agent needs something stricter: named commands, documented options, structured output and a result it can check.
Browser automation and computer use can imitate the person. That works until a dialog appears in a different place, a render takes longer than expected, or the agent clicks the right-looking control in the wrong panel.
CLI-Anything takes the other route. It builds command-line harnesses around the real application, so the agent can ask for an operation directly and receive a predictable response. The project has more than 48,000 GitHub stars, an Apache 2.0 license, and a registry covering creative software, office tools, automation systems, developer tools and scientific applications.
The useful part is not the size of that list. It is that there are two ways in: install an existing interface now, or generate a new one when the registry does not cover the software you need.
What CLI-Anything is, and what it is not
CLI-Anything is a system for making software agent-accessible through command lines.
For existing integrations, CLI-Hub acts like a package manager. You can search for a task or application, inspect the available harness, install it, and launch it from one place.
For unsupported software, the generator studies the source code, maps application capabilities into command groups, implements the harness, writes tests, documents the result, and packages it for use.
Each completed harness aims to give an agent three things:
- A normal command interface for scripted work.
- A stateful REPL for longer interactive sessions.
- Structured JSON output the agent can read without guessing what a success message meant.
It is not a replacement for GIMP, Blender or LibreOffice. The harness should invoke the real application or produce a valid native project that the real application can render. That boundary matters. A wrapper that quietly substitutes its own simplified renderer may produce a file, but not the file you asked the original software to make.
Choose the right starting point
There are two paths, and most people should start with the first.
| Situation | Start here | What you are doing |
|---|---|---|
| The application or task is already in the registry | CLI-Hub | Search, inspect, install and launch an existing CLI. |
| The application is missing, but its source is available | CLI-Anything generator | Build a new harness from the codebase, then test and refine it. |
| The target is closed-source and exposes no useful API or project format | Pause before generating | Coverage may be shallow. Decide whether browser or desktop automation is the more honest interface. |
Do not generate a new integration just because the generator is interesting. A reviewed harness from the Hub is the shorter route and gives you a known command surface to test.
Install CLI-Hub and inspect what already exists
Install the Hub package manager:
pip install cli-anything-hubThen browse or search the registry:
cli-hub list
cli-hub search image
cli-hub search diagram
cli-hub info drawioOnce you find the right harness, install and launch it:
cli-hub install drawio
cli-hub launch drawio --helpThe info step is worth keeping. Some harnesses wrap desktop software that must already be installed. Others depend on an API, local service or credential. Finding that out before handing the task to an agent saves a long failure that ends with a missing backend.
Start with a reversible task. Ask the CLI to create a new artifact in a fresh folder, not edit the only copy of something important.
The rest of this playbook is below.
Enter your email to read it. You also get one new playbook every week.
One email a week. Unsubscribe any time.
Give your agent the Hub instead of memorising commands
You can also install the CLI-Hub meta-skill into a SKILL-compatible agent:
npx skills add HKUDS/CLI-Anything --skill cli-hub-meta-skill -g -yThe project lists support for Claude Code, Codex, OpenClaw, Nanobot and other agents that understand SKILL files.
After installation, do not begin with a vague instruction like “use CLI-Anything.” Give the agent the task, the output and the verification rule:
Find the appropriate CLI in CLI-Hub and create a Draw.io diagram of our HTTPS request lifecycle.
The output must include DNS lookup, TCP handshake, TLS negotiation, the application request and termination.
Save the editable source and export a PNG. Open or inspect both outputs and verify that every stage is present before finishing.The last sentence is doing more work than it looks. It prevents the agent from treating a zero exit code as proof that the result is correct.
Build a new CLI when the Hub does not have one
If the target application is missing and you can provide its source repository, install the CLI-Anything plugin in Claude Code:
/plugin marketplace add HKUDS/CLI-Anything
/plugin install cli-anythingThen point the generator at a local source directory or public repository:
/cli-anything /path/to/software
or
/cli-anything https://github.com/owner/repositoryThe generator follows seven phases:
- Analyse. Inspect the source and map real application actions to usable APIs or project formats.
- Design. Decide the command groups, state model and output formats.
- Implement. Build the CLI, REPL and structured output.
- Plan tests. Define unit and end-to-end scenarios before claiming coverage.
- Write tests. Exercise functions, commands and real application outputs.
- Document. Record supported workflows, requirements and results.
- Publish. Package the harness and install it on the path.
One pass may not cover the entire application. The project includes refine, test and validate commands because a serious interface usually needs another round after the first workflows are exercised.
/cli-anything:refine /path/to/software "the workflow that is still missing"
/cli-anything:test /path/to/software
/cli-anything:validate /path/to/softwareThe first workflow to test
Choose one task that has an output a human can recognise immediately.
For Blender, render one simple scene. For LibreOffice, create a one-page report and export it as PDF. For Draw.io, build a small diagram and keep the editable source. For GIMP, apply one obvious transformation to a copy of an image.
Run the workflow in four passes:
- Discovery. Ask for
--helpand confirm the command actually exists. - Creation. Produce a new artifact in an isolated folder.
- Native render. Open or export through the real backend rather than a substitute.
- Verification. Check the file type, structure and visible result.
A good test prompt is narrow:
Use the installed LibreOffice CLI to create a Writer document called test-report.
Add one heading, one paragraph and a 3x3 table. Export it to PDF through LibreOffice.
Verify that the PDF opens, begins with a valid PDF signature, and contains the heading and table. Keep the editable source and the PDF.If the first real task fails, refine that path before expanding coverage. A list of 200 commands is not useful if the one workflow you need cannot survive an end-to-end run.
The part most demos skip: the real backend still decides whether it worked
A command can exit successfully while producing the wrong artifact.
Creative and office applications often store instructions in project files, then apply effects only during native rendering. If a harness edits the project correctly but exports it with a simpler library, those effects can disappear. The file exists. The automation reports success. The result is still wrong.
CLI-Anything’s own methodology treats the real software as a hard dependency for this reason. Blender work should be rendered by Blender. LibreOffice documents should be opened or exported by LibreOffice. Video projects should go through the correct rendering backend.
Verification has to match the artifact:
- For PDF, check the signature, page count and extracted content.
- For images, inspect dimensions and visible pixels.
- For audio, check duration and that the signal is not silent.
- For video, verify duration, frame output and audio streams.
- For editable projects, reopen the file in the target application.
The rule: a zero exit code proves that a process ended. It does not prove that the requested result exists or is correct.
This is the difference between an agent demo and an agent workflow you can trust without watching every step.
Three useful ways to apply it
One, give agents access to serious creative software. An agent can build a Blender scene, edit an image, create a Draw.io diagram or assemble a LibreOffice document through commands it can discover and verify.
Two, turn internal software into an agent tool. If your company has an application with a codebase but no clean automation layer, the generator can create the first structured interface. Keep it internal, test only the workflows you need, and avoid waiting for a vendor integration.
Three, build reusable skills around complete workflows. The CLI handles deterministic operations. A SKILL file tells the agent when to use those operations, in which order, and how to check the output. The result is more durable than prompting a computer-use agent to rediscover the interface each time.
The third use is where this becomes more than a collection of wrappers. A command is an ability. A tested skill turns that ability into a repeatable job.
If something goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| The command is installed but cannot render | The real application or backend is missing | Install the upstream software, confirm its executable is available, then rerun the smallest test. |
| The file exists but effects are missing | The harness used the wrong export path | Force native rendering and add a visual or structural assertion to the end-to-end test. |
| The agent cannot find the right command | The skill or help surface is incomplete | Run the bare command and --help, then update the SKILL file with the exact workflow. |
| A generated harness covers only basic operations | The first pass did not map the workflow deeply enough | Run refine with the missing workflow named explicitly, then add a real end-to-end test. |
| A closed-source application produces shallow coverage | There is no code, API or stable project format to map | Use a supported public CLI, vendor API, or browser/desktop automation instead of pretending the harness is complete. |
Honest limits
It works best when the source is available. The generator needs something real to inspect. A public codebase, documented API or stable project format gives it a dependable surface. Compiled software with no useful interface gives it less to work with.
The real application may still be required. Installing a harness does not automatically install Blender, GIMP, LibreOffice or every service dependency behind it.
Generation quality depends on the model. The project recommends frontier-class coding models for the full seven-phase pipeline. Smaller models may produce an incomplete interface that needs manual repair.
Coverage is not correctness. A large command list says what is exposed. Only end-to-end tests tell you whether your workflow produces the right artifact.
Not every job belongs in a CLI. A stable command interface is excellent for repeatable operations. A one-off task inside an inaccessible, visual-only application may still be faster through computer use.
Permissions still matter. An agent with a CLI can act quickly. Give it access only to the files, services and environments needed for the job, and keep destructive operations approval-gated.
What this changes
Most arguments about AI agents focus on whether the model is smart enough. That is often not the limiting factor.
The model can understand the task. The software simply has no interface the model can use without pretending to be a person.
CLI-Anything treats that as an engineering problem. Give the application named commands. Give every command structured output. Use the real backend. Test the finished artifact rather than trusting the process.
Once that layer exists, the agent stops relearning where the buttons are and starts working against a stable contract. The intelligence may come from Claude, Codex or another model. The dependable part is the interface underneath it.
Start with CLI-Hub, pick one reversible workflow, and keep the first test small enough that you can inspect every part of the result. If the harness survives that, you have something worth building into a skill.
