当 AI 代理需要调用 Java 库时，它直接写 Java interop 代码，从来不会先问一句"有没有现成的 Clojure wrapper？"。Clojure 社区有大量对 Java 库的包装库，它们提供了更函数式、更符合 Clojure 习惯的 API。一个有经验的 Clojure 开发者遇到 Java 类时，第一反应是搜索对应的 wrapper，而不是直接上手 interop。代理的这种直接跳过包装库的做法，导致代码不够地道，维护成本更高。

Clojure 项目普遍使用 cljfmt 之类的代码格式化工具。当代码被修改后，格式化工具可能调整缩进，哪怕只移动了一个空格，代理后续基于文本匹配的 str_replace 操作就会因为空白字符不匹配而失败。作者观察到代理的行为模式是：替换失败、重试、再次失败、最终放弃并重写整个文件。这造成了巨大的 token 浪费。

测试失败时，代理的调试手段非常原始：在代码里插入 println 语句，跑测试，看输出，删掉 println ，恢复代码，循环往复。这种调试方式在任何语言中都很低效，在 Clojure 项目中尤其浪费，因为 Clojure 有 REPL（一种交互式编程环境，让你可以在不修改源代码的情况下即时执行表达式、检查变量值、测试假设）。作者已经通过 brepl 命令行工具给代理提供了 REPL 访问能力，但代理从来没有主动用过。

这个 skill 解决的是第三个问题：代理用 println 调试。

Clojure 的正确做法是用 REPL 调试，步骤是这样的：

1. 用 def 把函数的返回值绑定到一个变量上（比如 (def result (fetch-user id))=），这样 =result 就固定住了，随时可以查看
2. 用 (keys result) 看这个值有哪些字段
3. 用关键字当函数来取值（比如 (:name result) ），逐层深入查看内部结构

全程不用动源代码。

clj-debug 在代理准备插入调试日志时介入，把它引向 REPL 的工作流：先把可疑的值用 def 绑定住，再逐步探索它的结构。代理不再需要反复编辑代码、跑测试、查输出、再恢复代码，直接在 REPL 里交互就够了。

这个 skill 对应第一个问题：代理直接写 interop 代码。

有经验的 Clojure 开发者遵循一个明确的探索流程：先搜索有没有 Clojure wrapper 库（通常都有），没有的话通过反射（一种在运行时检查类的方法和字段等结构的技术）探查 Java 类，如果是宏就先展开它看它生成什么代码。

clj-discover 把这个流程写进规则，强制代理在写集成代码之前先调研。效果很明显：代理不再一股脑写 interop，代码干净多了，也好维护。

这个 skill 解决第二个问题：格式化工具导致的替换失败。

这里利用了 Clojure 的一个核心特性：同像性（homoiconicity，代码即数据）。两个 S 表达式在语义上是等价的，即使它们的格式不同。专业的编辑器通过结构化编辑来自动处理这种差异。

clj-replace 用 rewrite-clj 库，按 S 表达式的结构来比较和替换，忽略空白差异，同时保留原文件的格式风格。格式化工具怎么改缩进都不影响替换操作。

前三个 skill 是自动触发的，这个不同，需要用户主动调用。

它针对的问题是：代理把可复用的机制和业务策略混在一起。这里的区分来自 Arne Brasseur 的机制/ 策略分离原则：机制（mechanism）是与业务无关的、稳定的、可复用的代码；策略（policy）是特定于某个场景的、多变的代码。两者混在一起，代码就僵硬且难以维护。

clj-refactor 扫描代码寻找提取机会：硬编码的值变成参数，隐式的上下文依赖变成显式的函数参数，把可复用的逻辑独立出来。纠缠在一起的一坨函数拆成可组合的机制后，更容易测试、复用和推理。