shadcn/improve：代码库审计与实施计划技能
本文目录
improve#
一个智能体技能（agent skill），可审计任何代码库，并编写实施计划供其他智能体执行。
理念：把智能叠加的部分——理解代码库、判断什么值得做、编写规格——交给能力最强的模型，把执行交给更便宜的模型。该技能本身从不实施任何东西。计划就是产品。
你 → /improve（昂贵模型，提供建议）
plans/ → 001-fix-n-plus-one.md（自包含的规格）
其他智能体 → 实施、测试、交付（便宜模型，执行）安装#
npx skills add shadcn/improve适用于任何支持 Agent Skills 格式的智能体。它编写的计划是纯 Markdown，因此任何智能体（或人类）都可以接手。
用法#
/improve 完整审计 → 按优先级排列的发现 → 计划
/improve quick 廉价的快速检查：热点、仅最重要的发现
/improve deep 穷尽式：每个包、每个类别
/improve security 聚焦安全审计（也支持：perf、tests、bugs 等）
/improve branch 只审计当前分支改动的部分
/improve next 功能建议——项目接下来该往哪走
/improve plan <description> 跳过审计，直接为一个事项编写规格
/improve review-plan <file> 批判并收紧现有计划
/improve execute <plan> 派发更便宜的执行者，审查其工作
/improve reconcile 刷新待办：验证、解除阻塞、淘汰
/improve ... --issues 同时将计划发布为 GitHub issue如何使用#
一次典型的首次运行，从头到尾：
- 在仓库中打开你的智能体并运行
/improve（或运行/improve quick以保持低成本）。 - 它会绘制仓库结构、进行审计，并返回一张发现表。回复你想要制定计划的项目——「plan 1、3 和 5」。
- 计划落在
plans/中——每个文件一个，外加一个给出推荐顺序的索引。阅读它们；它们本来就是供审查的。 - 把计划交给任何智能体（「implement plans/001-*.md」），或让技能运行它：
/improve execute 001。它会在隔离的 worktree 中派发一个更便宜的模型，对照计划审查 diff，并带回结论。合并仍由你决定。 - 下一次会话运行
/improve reconcile清理待办：验证已经落地的内容、刷新偏离的计划、解除卡住的事项。 - 提交 PR 前，
/improve branch做同样的事，但仅针对分支改动的范围。
示例#
一次针对 shadcn/ui 的运行返回了这样的发现：
| # | 发现 | 类别 | 工作量 | 置信度 |
|---|---|---|---|---|
| 1 | shadow-config 在 search.ts/view.ts 中重复，副本已经漂移（search.ts:31 有 TODO） | 技术债 | M | HIGH |
| 2 | O(n²) 图标迁移（migrate-icons.ts:168） | 性能 | S | HIGH |
……并驳回了一些发现，同时记录原因，以免它们在下次运行时再次出现：
- [SEC-01] https_proxy 环境变量「SSRF」：设计如此——标准代理约定，
每个 CLI 都遵循它。不是发现。选择 #1 后生成了这份计划——摘录当前代码、确切步骤、将仓库自身的测试/lint 命令作为验证门，以及当现实与计划不符时的 STOP 条件。
工作原理#
侦察（Recon）：绘制仓库结构：技术栈、约定，以及确切的构建/测试/lint 命令——这些将成为每份计划中的验证门。它还会在存在时读取意图和设计文档——ADR（docs/adr/）、PRD、CONTEXT.md、DESIGN.md、PRODUCT.md——这样已决定的权衡不会被重新标记为发现，方向建议始终扎根于已声明的产品意图，计划也使用仓库自己的词汇。可与任何已维护这些文档的仓库组合使用。
审计（Audit）：在九个类别中并行展开子智能体：正确性、安全性、性能、测试覆盖率、技术债、依赖与迁移、开发者体验、文档和方向（功能建议——每条都必须引用仓库自身的证据，不允许泛泛的想法垃圾）。每条发现都带有 file:line 证据、影响、工作量和置信度。
核查（Vet）：子智能体容易过度报告，因此顾问会在向你展示任何内容之前，亲自重读每个被引用的位置——误报被剔除，错误归因被纠正，驳回被记录。
排序（Prioritize）：发现进入一张按杠杆（影响 ÷ 工作量，并按置信度加权）排序的表。你选择哪些变成计划。
计划（Plan）：每个选中的发现对应一个文件，写入 plans/，并带有索引、优先级顺序和依赖图。
为什么这些计划可执行#
计划是为最弱的可能执行者编写的——一个从未见过顾问会话、可能小得多的模型。三个特性支撑了这一点：
- 自包含：所有上下文都内联：确切文件路径、当前状态代码摘录、仓库约定及示例文件、已验证的命令。没有「如上所述」。
- 验证门：每一步都以命令及其预期输出结束。完成标准可机器检查。执行者永远不必判断自己是否成功。
- 硬边界：明确的范围外列表，以及 STOP 条件——「如果 X，停止并报告」——而不是让小模型在现实与计划不符时即兴发挥。
每份计划还记录其编写时对应的 git 提交，因此执行者在动手前会运行机械的漂移检查。
闭环#
计划不是「发射后不管」：
execute <plan>在隔离的 git worktree 中启动更便宜的执行者子智能体，把计划交给它，然后像技术负责人一样审查结果——重新运行每个完成标准、检查范围合规性、对照意图阅读 diff。结论：批准（合并仍由你决定）、退回修订（最多 2 轮），或阻止并改进计划。reconcile处理此后发生的事：验证 DONE 计划仍然成立、调查 BLOCKED 计划并绕过障碍重写、刷新漂移的计划、淘汰已被独立修复的发现。--issues将计划发布为 GitHub issue——同样是自包含的正文，因此任何智能体或人类都可以在工作所在之处接手。
硬性规则#
- 从不自行修改源代码。唯一的写入是
plans/；执行者只在一次性 worktree 中编辑，合并始终由你完成。 - 从不运行会改变工作树的命令——只进行读取、搜索和只读分析。
- 从不复制秘密值。只记录位置和凭证类型，并始终建议轮换。
- 被要求实施时？它会拒绝并指向计划（或提议执行）。
许可证#
MIT © shadcn
关于#
用你能力最强的模型审计代码库，并为更便宜的模型编写可执行的计划。
资源：Readme、MIT license
活动：10.8k stars、29 watching、442 forks