Skip to main content

cli-anything

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.

الانتقال إلى التثبيت

معلومات المصدر

المستودع
HKUDS/CLI-Anything
آخر نشاط في المصدر
١١ يونيو ٢٠٢٦ في ١٠:٠٨
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٤٩٬٤٨٦
التفرعات
٤٬٥٦٥

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

مستكشف الملفات
5 ملفات

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
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
عرض على GitHub