CLI-Anything for Hermes Agent

Use this skill when the user wants Hermes Agent to act like the CLI-Anything builder.

Before implementation, use the full methodology source of truth when available:

If this skill is being used from inside the CLI-Anything repository, read ../cli-anything-plugin/HARNESS.md first.
If that local file is unavailable, clone or download cli-anything-plugin from https://github.com/HKUDS/CLI-Anything/tree/main/cli-anything-plugin, then use HARNESS.md and the resources around it from that folder.
Only if both local and network retrieval fail, follow the condensed rules below.

Inputs

Accept either:

A local source path such as ./gimp or /path/to/software
A GitHub repository URL

Derive the software name from the local directory name after cloning if needed.

Hermes Tool Bindings

Hermes agents build harnesses by combining these built-in tools:

Tool	Role in Harness Workflow
`terminal`	Run shell commands, install packages, execute CLI tools, run tests
`execute_code`	Generate and write Python files (Click CLI, backend modules, tests)
`delegate_task`	Parallelize analysis or generation subtasks
`read_file` / `write_file`	Read and write harness source files
`patch`	Make targeted edits to generated code

Consult the Hermes Agent documentation for the exact tool invocation syntax.

Modes

Build

Use when the user wants a new harness.

Produce this structure:

<software>/
└── agent-harness/
    ├── <SOFTWARE>.md
    ├── setup.py
    └── cli_anything/
        └── <software>/
            ├── README.md
            ├── __init__.py
            ├── __main__.py
            ├── <software>_cli.py
            ├── core/
            ├── utils/
            └── tests/

Implement a stateful Click CLI with:

one-shot subcommands
REPL mode as the default when no subcommand is given
--json machine-readable output
session state with undo/redo where the target software supports it

Refine

Use when the harness already exists.

First inventory current commands and tests, then do gap analysis against the target software. Prefer:

high-impact missing features
easy wrappers around existing backend APIs or CLIs
additions that compose well with existing commands

Do not remove existing commands unless the user explicitly asks for a breaking change.

Test

Plan tests before writing them. Keep both:

test_core.py for unit coverage
test_full_e2e.py for workflow and backend validation

When possible, test the installed command via subprocess using cli-anything-<software> rather than only module imports.

Validate

Check that the harness:

uses the cli_anything.<software> namespace package layout
has an installable setup.py entry point
supports JSON output
has a REPL default path
documents usage and tests

Backend Rules

Prefer the real software backend over reimplementation. Wrap the actual executable or scripting interface in utils/<software>_backend.py when possible. Use synthetic reimplementation only when the project explicitly requires it or no viable native backend exists.

Packaging Rules

Use find_namespace_packages(include=["cli_anything.*"])
Keep cli_anything/ as a namespace package without a top-level __init__.py
Expose cli-anything-<software> through console_scripts

Workflow

Acquire the source tree locally (clone or use existing path).
Analyze architecture, data model, existing CLIs, and GUI-to-API mappings.
Design command groups and state model.
Implement the harness.
Write TEST.md, then tests, then run them.
Update README usage docs.
Verify local installation with pip install -e .

Existing Harnesses (Reference)

For an up-to-date list of supported harnesses and their backend patterns, see registry.json at the repository root.

Output Expectations

When reporting progress or final results, include:

target software and source path
files added or changed
validation commands run
open risks or backend limitations

cli-anything-hermes