cli-anything

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

CLI-Anything for Codex

适用于Codex的CLI-Anything

Use this skill when the user wants Codex to act like the

CLI-Anything

builder.

If this skill is being used from inside the

CLI-Anything

repository, read

../cli-anything-plugin/HARNESS.md

before implementation. That file is the full methodology source of truth. If it is not available, follow the condensed rules below.

当用户需要Codex充当

CLI-Anything

构建器时使用本技能。

如果是在

CLI-Anything

仓库内部使用本技能，请在实现前先阅读

../cli-anything-plugin/HARNESS.md

，该文件是完整方法论的权威来源。如果无法访问该文件，请遵循下述精简规则。

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.

接受以下任意一种输入：

本地源码路径，例如
```
./gimp
```
或
```
/path/to/software
```
GitHub仓库URL

如有需要，可在克隆仓库后从本地目录名称推导软件名称。

Modes

模式

Build

构建

Use when the user wants a new harness.

Produce this structure:

text

<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

当用户需要新建运行套件时使用。

生成如下目录结构：

text

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

实现有状态的Click CLI，需满足：

支持单次执行的子命令
未传入子命令时默认进入REPL模式
支持
```
--json
```
机器可读输出
在目标软件支持的场景下提供支持撤销/重做的会话状态

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.

当运行套件已存在时使用。

首先盘点现有命令和测试，再针对目标软件进行差距分析。优先实现：

影响范围大的缺失功能
对现有后端API或CLI的简易封装
可与现有命令良好组合的新增功能

除非用户明确要求破坏性变更，否则不得移除现有命令。

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.

编写测试前先规划测试用例。需同时保留两类测试：

```
test_core.py
```
用于单元测试覆盖
```
test_full_e2e.py
```
用于工作流和后端校验

条件允许的情况下，通过子进程调用

cli-anything-<software>

测试安装后的命令，而非仅测试模块导入。

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

检查运行套件是否满足以下要求：

采用
```
cli_anything.<software>
```
命名空间包布局
包含可安装的
```
setup.py
```
入口点
支持JSON输出
提供默认REPL入口
包含使用说明和测试文档

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.

优先使用真实的软件后端而非重新实现。条件允许的情况下，在

utils/<software>_backend.py

中封装实际可执行文件或脚本接口。仅当项目明确要求或无可用原生后端时，才使用模拟实现。

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

使用

find_namespace_packages(include=["cli_anything.*"])

保留
```
cli_anything/
```
作为命名空间包，不添加顶层
```
__init__.py
```
通过
```
console_scripts
```
暴露
```
cli-anything-<software>
```
命令

Workflow

工作流

Acquire the source tree locally.
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 .
```

本地获取源码树
分析架构、数据模型、现有CLI以及GUI到API的映射关系
设计命令分组和状态模型
实现运行套件
编写
```
TEST.md
```
，随后编写测试并运行
更新README使用文档
使用
```
pip install -e .
```
验证本地安装

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

汇报进度或最终结果时，需包含以下内容：

目标软件和源码路径
新增或修改的文件
执行过的验证命令
未解决的风险或后端限制