The Command Line for Everything: The Hub, the Install, and the Part Most Agent Demos Skip

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 -y

The 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-anything

Then point the generator at a local source directory or public repository:

/cli-anything /path/to/software

or

/cli-anything https://github.com/owner/repository

The generator follows seven phases:

1. Analyse. Inspect the source and map real application actions to usable APIs or project formats.
2. Design. Decide the command groups, state model and output formats.
3. Implement. Build the CLI, REPL and structured output.
4. Plan tests. Define unit and end-to-end scenarios before claiming coverage.
5. Write tests. Exercise functions, commands and real application outputs.
6. Document. Record supported workflows, requirements and results.
7. 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/software

The 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:

1. Discovery. Ask for --help and confirm the command actually exists.
2. Creation. Produce a new artifact in an isolated folder.
3. Native render. Open or export through the real backend rather than a substitute.
4. 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

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.