Reasonix Skill

---
name: cli-anything
description: Use when the user wants Reasonix to build, refine, test, or validate a CLI-Anything harness for a GUI application or source repository. Adapts the CLI-Anything methodology to Reasonix without changing the generated Python harness format.
runAs: subagent
---

# CLI-Anything for Reasonix

Use this skill when the user wants Reasonix to act like the `CLI-Anything` builder.

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

1. If the current workspace is the `CLI-Anything` repository, read `cli-anything-plugin/HARNESS.md`.
2. If Reasonix is running from this adapter directory, also check `../cli-anything-plugin/HARNESS.md`.
3. If neither local file is available, 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.
4. Only if local and network retrieval both 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.

## Reasonix Tool Bindings

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

| Reasonix Tool | Role in Harness Workflow |
|---------------|--------------------------|
| `bash` | Run shell commands, install packages, execute CLI tools, run tests, clone repos |
| `write_file` | Generate Python files (Click CLI, backend modules, tests, setup.py) |
| `edit_file` | Make targeted edits to generated code (single replacement) |
| `multi_edit` | Apply multiple atomic edits to a single file in one pass |
| `read_file` | Read target software source files, existing harness code, test results |
| `grep` | Search for patterns across the target software codebase (APIs, CLI tools, data models) |
| `glob` | Find files matching patterns in the source tree (*.py, *.xml, *.json, etc.) |
| `ls` | List directory contents to understand project structure |
| `mcp__codegraph__search` / `mcp__codegraph__context` | Optional code graph analysis when CodeGraph is enabled (Reasonix strips the `codegraph_` raw prefix, so the model-visible names omit it) |
| `web_fetch` | Fetch documentation, API references, or remote files from the web |

### Recommended Workflow with Reasonix Tools

**Phase 1 (Analysis)** — Use `ls` + `glob` to survey the source tree, `grep` to find API surfaces and CLI entry points, and `read_file` to inspect key files. When CodeGraph is enabled and its tools are available, use `mcp__codegraph__search` and `mcp__codegraph__context` for deeper symbol and architecture analysis.

**Phase 2-3 (Design & Implementation)** — Use `write_file` to create new harness files, `edit_file` / `multi_edit` to refine generated code, and `bash` to run `pip install -e .` for installation.

**Phase 4-6 (Testing)** — Use `bash` to run `pytest` and capture results, `read_file` to inspect test output, and `write_file` to update TEST.md.

**Phase 7 (Packaging)** — Use `write_file` for setup.py, `bash` for `pip install -e .` and `which cli-anything-<software>` verification.

## Step Budget

A full harness build typically requires 25–40 tool-call rounds (architecture inspection, 10+ file writes, installation, and multiple test runs). When invoked via `run_skill`, the subagent inherits a step budget derived from the parent agent's `agent.max_steps` setting in `reasonix.toml`:

- If `max_steps = 0` (the default, meaning unlimited), the subagent also runs with no step cap — this is the recommended configuration for the CLI-Anything workflow.
- If `max_steps` is set to a finite value, the subagent receives half that budget (minimum 5), which may truncate a complex build before completion.

Users who have configured a finite `max_steps` should ensure it is set to 0 or a sufficiently high value (e.g., 64 or more) before running a CLI-Anything build, so the subagent has enough rounds to complete all seven phases.

## Modes

### Build

Use when the user wants a new harness.

Produce this structure:

```text
<repo-root>/
├── skills/
│   └── cli-anything-<software>/
│       └── SKILL.md
└── <software>/
    └── agent-harness/
        ├── <SOFTWARE>.md
        ├── setup.py
        └── cli_anything/
            └── <software>/
                ├── README.md
                ├── __init__.py
                ├── __main__.py
                ├── <software>_cli.py
                ├── core/
                ├── utils/
                ├── tests/
                └── skills/
                    └── SKILL.md
```

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
- has matching canonical and package-local `SKILL.md` files
- 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`
- Include `cli_anything.<software>/skills/SKILL.md` in package data

## Workflow

1. Acquire the source tree locally (clone or use existing path).
2. Analyze architecture, data model, existing CLIs, and GUI-to-API mappings.
3. Design command groups and state model.
4. Implement the harness.
5. Write `TEST.md`, then tests, then run them.
6. Update README usage docs and generate both `skills/cli-anything-<software>/SKILL.md` and `cli_anything/<software>/skills/SKILL.md`.
7. Verify local installation with `pip install -e .`

## Existing Harnesses (Reference)

For an up-to-date list of supported harnesses and their backend patterns, locate `registry.json` at the `CLI-Anything` repository root when it is available.

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