shadcn/improve:审计代码库、给便宜模型写执行计划的 agent skill

improve 是 shadcn 出的一个 agent skill,审计代码库、写执行计划,自己从不写代码。计划就是产品。前提是一笔经济账:把你最强的模型花在智能会复利的那部分,也就是读懂仓库、把真正值得做的事写成规格,然后把机械执行交给便宜模型或者别的 agent。

这个想法,以及它为什么有意思

大多数 coding agent 工作流用一个贵模型干所有事,包括那些小模型也够用的死板改动。improve 把这件事拆开。advisor 模型做 recon、审计和规划。executor 可以是个小得多的模型,照着规格走。整条链是三个角色:

你           →  /improve                    (贵模型,出主意)
plans/       →  001-fix-n-plus-one.md       (自包含规格)
另一个 agent  →  实现、测试、交付            (便宜模型,执行)

省不省钱看你的定价。当你 advisor 和 executor 两档模型的差距大时,这个收益是实的;当你本来就只用一个中档模型时,收益就小。更耐久的好处是结构性的:把”决定做什么”和”去做”分开,中间多出一个可评审的产物,这是单个端到端 agent 跑完永远给不了你的。

一次运行怎么走

流水线有五个阶段,每个阶段的设计取舍,正是它和泛泛的”帮我看看代码”提示词的区别所在。

Recon。 它摸清技术栈和约定,抽出仓库精确的 build、test、lint 命令,这些会变成每份计划里的验证关卡。有的话它还会吃进意图文档,比如 docs/adr/ 下的 ADR、PRD、CONTEXT.md、DESIGN.md、PRODUCT.md,这样已经定下的取舍不会被重新当成问题报出来,建议也扎在写明的产品方向上。

Audit。 并行子 agent 铺开,覆盖九个类别:正确性、安全、性能、测试覆盖、技术债、依赖与迁移、开发体验、文档、方向。每条发现都必须带 file:line 证据、影响、工作量和置信度。方向类建议必须引用仓库里的证据,不是泛泛的点子。

Vet。 这一步是大多数评审工具跳过的。子 agent 会过度上报,所以 advisor 在给你看之前,自己把每个被引用的位置重读一遍。误报删掉,错误归属改正,被否的连同理由记下来,免得下次又冒出来。

Prioritize 与 plan。 发现落进一张表,按杠杆排序(影响除以工作量,再用置信度加权)。你挑哪些变成计划。每条选中的发现变成 plans/ 里的一个文件,带索引、优先序和依赖图。

计划凭什么能被执行

这些计划是为最弱的可能执行者写的,一个没见过 advisor 会话、可能小得多的模型。三个属性扛住这个担子。计划是自包含的,文件路径、当前代码摘录、仓库约定、核实过的命令全部内联,没有”如上所述”。每一步都以一条命令和它的预期输出结尾,所以完成标准是机器可校验的,执行者从不需要自己判断成没成。计划还设硬边界:明确的范围外清单,以及当现实和规格不符时的 STOP 条件,而不是让小模型即兴发挥。每份计划还盖上它所针对的 git commit,执行者动手前先跑一遍漂移检查。

闭环

计划不是发完就不管。/improve execute <plan> 在一个隔离的 git worktree 里起一个便宜的执行者,把计划交给它,然后像 tech lead 那样审结果:重跑每条完成标准,检查范围合规,对着意图读 diff。结论是通过、打回返修(最多两轮),或者拦下来重修计划。合并永远是你拍板。/improve reconcile 处理上次之后的变化,核实落地的计划、把卡住的绕开重写、把已经被独立修掉的发现退役。--issues 把计划发成 GitHub issue,任何 agent 或人都能接手。

安全模型

那几条硬规矩,正是你敢把它指向真实仓库的原因。它自己从不改源码,唯一的写入去 plans/。执行者只在一次性 worktree 里改,合并永远归你。它从不跑会动你工作树的命令,只做读取、搜索和只读分析。它从不复现 secret 的值,只报位置和凭证类型,且永远建议轮换。被要求直接实现时,它拒绝,把你指向计划或 execute。对一个跑自主审计的工具来说,这些约束就是有用和危险之间的分界。

安装

npx skills add shadcn/improve

它在任何支持 Agent Skills 格式的 agent 里都能用。因为它写出的计划是纯 Markdown,任何 agent 或人都能接一份过来,哪怕从没跑过 improve。

值得知道的命令

/improve 跑完整审计;/improve quick 是便宜的热点扫描;/improve deep 是穷尽式。
/improve security(还有 perf、tests、bugs)把审计收窄到一个类别。
/improve branch 只审当前分支改了什么,是天然的 PR 前检查。
/improve next 给项目方向建议,要求带证据。
/improve plan <描述> 跳过审计,只为一件事写规格;/improve review-plan <file> 批评并收紧一份现有计划。

适合与不适合

有一个攒了技术债的真实代码库、又想要一份排好序、可评审的待办,而不是一个立刻开改的 agent 时,用 improve。发布前、接手别人的仓库、或者想靠把贵模型只留给判断来压低算力成本时,它都很强。

它不太适合新项目,那时还没多少东西可审;也不太适合小脚本,规划开销盖过任务本身。计划的写法刻意啰嗦,因为它瞄的是弱执行者,所以琐碎的修法,规格可能比改动还长。而且执行者仍然是质量天花板:一份交给小到跟不上的模型的计划,会卡在验证关卡上,这是设计意图,但仍是一个你得处理的失败。

它怎么比

star 数截至 2026-06。

仓库	Stars	切入点
improve	~4.7k	审计现有代码、核实发现、为便宜执行者写计划
github/spec-kit	~112k	规格驱动开发,先写规格再生成,偏新项目
DanMcInerney/architect-loop	~430	给 agent 的架构师加执行者规划循环
obra/superpowers	~227k	宽口径的 agentic 方法论与 skill 框架

最清楚的对照是 spec-kit。spec-kit 从你写的规格起步、往前搭脚手架,适合新工作。improve 从已经存在的代码起步,找出值得改的,然后替你把规格写出来。architect-loop 在精神上更近,同样把架构师和执行者分开,但 improve 多了审计前端和只读的安全保证。

star 曲线

曲线是 2026 年 6 月一次陡峭的发射,背后有作者本来的受众,这解释了它起得快。和任何只有几天的 skill 一样,目前的形状是注意力,耐久性要更长的窗口才读得出。

FAQ

improve 会改我的代码吗? 不会。它只写 plans/。execute 命令在一次性 git worktree 里跑便宜模型,合并永远是你的决定。advisor 自己只做只读分析,从不改你的工作树。

哪些 agent 支持它? 任何实现 Agent Skills 格式的宿主,清单在 agentskills.io。用 npx skills add shadcn/improve 安装。因为计划是纯 Markdown,连跑不了这个 skill 的 agent 也能执行它产出的计划。

improve 和 spec-kit 有什么不同? spec-kit 是规格驱动开发:你写一份规格,它从那里生成,偏向新项目。improve 反着来,从一个已有的代码库往回走,审计它、核实发现,自己把规格写出来。两者在中间相遇,但起点相反。

quick、deep、security 各做什么? quick 是对热点和高位发现的便宜一遍,deep 是扫遍每个包和每个类别的穷尽式,security(同 perf、tests)把整轮审计收窄到一个类别。从 quick 起步压成本,某条发现值得时再升级。

它免费吗? 免费,MIT 许可。skill 是免费的;你的成本是它在审计和规划上花的模型 token,而便宜执行者这一拆分正是为压低这块设计的。