插件形态：装进 Claude Code 是怎么装的
CLI-Anything 仓库根目录下有一堆看起来像宿主适配层的目录，cli-anything-plugin/ 是其中之一，宿主是 Claude Code。我们采集时（2026-08-10，对应仓库快照 39634a6）这个目录有 26 个文件、5865 行。
如果你按「装一个插件 = 多一个能跑的工具」的预期去看它，第一眼会对不上号。这篇就是把这个目录的清单摊开，说清它到底把什么东西交给了宿主。至于一个 harness 本身的四件套目录结构长什么样，那是另一篇专门讲的内容，本篇不重复。
清单本身极薄
先看宿主认这个插件靠的是哪份文件：.claude-plugin/plugin.json，整份 7 行，只有 name、description、author 三个键。没有 version 字段。
对比一下同仓的分发工具 cli-hub，它的版本号 0.4.1 在 setup.py 与包 __init__.py 两处都写了。插件这边没有这样一个可供对账的版本源。
再看它交出去的命令。commands/ 下 5 个 Markdown：
| 文件 | 行数 |
|---|---|
commands/list.md | 237 |
commands/cli-anything.md | 147 |
commands/validate.md | 123 |
commands/refine.md | 104 |
commands/test.md | 73 |
这 5 个 md 没有 YAML frontmatter，直接以 # … Command 开头。这一点和同仓 opencode-commands/ 下那 5 个带 frontmatter、带 description 字段的 md 是两种写法——那边的差异另有一篇在讲，这里只是提醒你别把两处的文件形态记混。
反直觉的那一处：装进去的不是运行时，是一份会被复制走的源码
这个目录里行数最多的几个文件，没有一个是给宿主当运行时用的：
| 文件 | 行数 | 它的角色 |
|---|---|---|
HARNESS.md | 747 | 造 harness 的方法论规范 |
skill_generator.py | 586 | 从 harness 目录抽元数据生成 SKILL.md |
repl_skin.py | 567 | 要被复制进产物的统一 REPL 皮肤 |
tests/test_skill_generator.py | 536 | 生成器自己的测试 |
preview_bundle.py | 468 | 预览包与轨迹的协议实现 |
README.md | 462 | 插件说明 |
PUBLISHING.md | 307 | 发布说明 |
QUICKSTART.md | 242 | 上手说明 |
repl_skin.py 最能说明问题。这份文件的文件头（第 3 到 4 行）写明的是它自己该被放到哪去：cli_anything/<software>/utils/repl_skin.py。也就是说它不是在插件进程里被 import 的模块，而是一份标好了落点、等着被搬进生成产物里的源文件。
skill_generator.py 是同一个路子：它有 16 个顶层函数与 dataclass（grep -n "^def \|^class " 数出来的），其中包括 extract_commands_from_cli、generate_skill_md、generate_skill_file——读一个已经写好的 harness 目录，生成那份给 agent 读的 SKILL.md。它配套的模板是 templates/SKILL.md.template，123 行，用的是 {{ skill_name }}、{% if system_package %} 这种 Jinja 风格占位。
preview_bundle.py 定义了两个协议常量：preview-bundle/v1 与 preview-trajectory/v1，用 sha256 做指纹。
把这几样摆在一起，这个插件的形态就清楚了：它是一套「怎么造 harness」的规范加工具箱，交给宿主里的模型去执行，产物是另一个独立的 Python 包。插件 README 里那条 7 阶段方法论的两头也印证了这一点——Phase 6.5 是 SKILL.md 生成，Phase 7 是 PyPI 发布与安装。生成物那边的结构约束（cli_anything/ 要是 namespace package、不放 __init__.py，cli_anything/<software>/ 才有）写在插件 README 第 230 到 231 行与 249 到 250 行，那条约束我们另有一篇讲透了，这里不展开。
所以，「装进 Claude Code」之后你手上多的是几条会驱动模型干活的命令，以及一批准备被复制进你自己产物里的文件，不是一个装完就能对某个软件下指令的工具。真正能对软件下指令的那个东西，得等 7 个阶段跑完、生成出来、装到 Python 环境里之后才存在。
四处可以自己核对的对不上
这个目录里有几处内部口径不一致，都能在几分钟内自己核完。
一、plugin.json 没有版本，安装脚本里有。 .claude-plugin/plugin.json 第 1 到 7 行没有 version 字段，而 scripts/setup-cli-anything.sh 第 29 行硬编码了 PLUGIN_VERSION="1.0.0" 并把它打印出来。两处，一处没有、一处是写死的常量。说到这里为止。
二、verify-plugin.sh 的必需文件清单漏了最长的那个命令文件。 这个脚本只做结构检查：查 9 个必需文件、校验 plugin.json 是合法 JSON、检查 setup 脚本的可执行位（第 19 到 46 行）。它逐个检查的命令文件是 commands/cli-anything.md、refine.md、test.md、validate.md 四个（第 24 到 27 行），没有 commands/list.md。而 commands/list.md 存在，237 行，是 5 个命令文件里最长的一份；插件 README 第 122 行也把 /cli-anything:list 列为正式命令。
三、setup 脚本打印的可用命令也是 4 条。 scripts/setup-cli-anything.sh 第 88 到 91 行打印的命令列表是 build / refine / test / validate，同样没有 /cli-anything:list。插件 README 与同仓的 Pi 扩展那边算的都是 5 个命令。
四、HARNESS.md 的位置有两说。 插件 README 的 Prerequisites 一节（第 47 行）写 HARNESS.md 在 ~/.claude/plugins/cli-anything/HARNESS.md；而同仓的 scripts/setup-cli-anything.sh 第 38 行检查的是硬编码的 /root/cli-anything/HARNESS.md，第 102 行也照这个路径打印。两个路径写在同一个目录下的两份文件里。
这四处我们只陈述差异，不推断哪个是对的、也不据此评价什么。
Windows 侧要单独说一句
scripts/setup-cli-anything.sh 第 14 到 25 行有一段专门的 Windows bash 处理：检测到是 Windows bash 环境、而 cygpath 不存在时，脚本直接报错退出。
这段判断加上面第四条里那个硬编码的 /root/cli-anything/HARNESS.md，是 Windows 读者在动手之前值得先读一眼的两处。这两个事实分别在脚本的哪几行，上面都给了，你打开文件就能对。
README 自称与我们没有核实的部分
插件 README（cli-anything-plugin/README.md）第 7 行声称这套方法论已经为 GIMP、Blender、Inkscape、Audacity、LibreOffice、OBS Studio、Kdenlive 生成过 CLI，并有 “over 1,100 passing tests”。这个数字是 README 自称，它所指的测试分布在各个 harness 子目录里，我们没有统计核实过。我们数过的只有插件自己的测试：tests/test_skill_generator.py 有 38 个测试函数。
另一处值得原样记下来的是 HARNESS.md 第 117 行——“Test Inventory Plan” 那一节要求列出计划测试文件与 estimated test counts。estimated 这个词是规范原文写的，也就是说这一节里填进去的数从设计上就是预估值。
顺带一提，我们没有读过 HARNESS.md 全文（747 行），只核了其中 “estimated test counts” 这一处，也没有读 QUICKSTART.md、PUBLISHING.md 与 guides/ 那 8 篇的正文（guides/ 下按文件列表计是 8 篇：preview-methodology 284 行、skill-generation 135、pypi-publishing 117、auto-save-dry-run 87、mcp-backend 64、session-locking 39、filter-translation 26、timecode-precision 22）。方法论的具体内容不在本文的核实范围内。
两条不能省的前提
第一，注册表里有条目不等于你装上就能用。仓库根 registry.json 我们实读是 79 条，但这 79 条各自的 harness 齐不齐、能不能驱动宿主，是另一回事——仓库里确实有 harness 缺件的情况，缺件清单另有一篇专门统计。更基础的一条写在仓库根 README.md 第 236 行：包装真实桌面软件的那些 CLI，需要你自己先把上游应用装上。插件这一层生成的是「怎么对那个软件下指令」的代码，不负责把那个软件搬到你机器上。
第二，这条链路上从头到尾都在本机执行外部程序与脚本。插件的安装走的是一个 shell 脚本，verify-plugin.sh 会检查它的可执行位；生成出来的 harness 要真的去驱动本机的 Blender、OBS、GIMP 这类软件，靠的是起子进程之类的手段。要不要在自己的机器上跑这一套，请结合自身环境评估。同仓的 SECURITY.md 自己也列了五类攻击面（子进程参数、Script-Fu 注入、XML/SVG 内容、路径穿越、凭据泄露），并且明确写了它面向人类贡献者与安全评审、不是 CLI 生成方法论的一部分。
你可以自己跑一遍的核对动作
上面每一处都是从文件里读出来的，clone 下来在 cli-anything-plugin/ 目录里跑这几条就能自己复现：
cat .claude-plugin/plugin.json
sed -n '19,46p' verify-plugin.sh
ls commands/
grep -n "HARNESS.md" README.md scripts/setup-cli-anything.sh
head -3 commands/*.md
第一条看有没有 version 字段；第二条打印出来的那段必需文件检查，拿去和第三条的 ls 结果比，差的就是 list.md；第四条把 HARNESS.md 的两个路径一次性拉到眼前；第五条看这 5 个命令文件是不是都直接以 # 开头、没有 frontmatter。以上为按仓库中的文件结构组合的核查示例，未经实测，以官方文档与脚本的实际输出为准。
数字会随上游更新变动。真正值得记住的不是 26 个文件和 5865 行，而是这个插件的形态：它交给宿主的是规范与生成器，不是运行时；以及在动手之前，先把 HARNESS.md 到底该放哪、Windows 上那段 cygpath 判断，这两件事在自己的机器上确认清楚。
本文依据 CLI-Anything 官方仓库（github.com/HKUDS/CLI-Anything）的 README、registry.json、
docs/ 与各 agent-harness/ 下的源码整理，核对日 2026-08-10，对应仓库快照 39634a6。
本文内容为仓库源码与文档口径，我们没有安装或运行过其中任何一个 harness，
也没有在本机驱动过任何一款宿主软件，因此不涉及实际操控效果的任何描述。
这类 harness 会在本机执行外部程序与脚本，是否使用请结合自身环境评估。
注册表与 harness 内容随上游更新而变动，请以仓库最新内容为准。
安全相关做法请结合自身环境评估，本文不构成安全方案建议。