mcpField
C
code-improver

code-improver

github.com/trailofbits测试与质量7.9k1.1k 次安装今天更新
代码仓库

关于 code-improver

code-improver 是一个代码改进技能，通过命名的审查者与修复 Agent 反复审查和修正指定目录，直到没有严重或主要问题。它要求明确目标、审查者和可修改范围，并依赖工作流中的范围保护与记录机制。

主要功能

  1. 01循环执行审查与修复
  2. 02要求指定审查者
  3. 03限定可修改的文件范围
  4. 04记录审查与修复过程
  5. 05报告收敛、阻断或升级结果

适用场景

  1. 01迭代改进指定目录中的代码
  2. 02在明确范围内处理审查发现
  3. 03追踪未解决问题和循环结果

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/trailofbits/skills --skill code-improver

安装后在 Claude Code 中输入/code-improver确认已加载。

详细介绍

代码改进器

运行 /code-improver:improve，即可改进任意代码目标——这是一个动态工作流，会循环调用指定的审查者和修复子 Agent，直到审查结果中没有严重或主要问题，然后清理自身残留。循环、问题记录和防护机制都位于工作流中；此技能会收集通用入口所需的三项输入，并反馈执行结果。

启动循环

用户提供了：$ARGUMENTS（如果为空，则从对话中获取详细信息）。

1. 收集三项必需输入——不要猜测
  1. 目标：待改进目录的绝对路径。相对路径需基于工作目录解析；确认目录存在。
  2. 审查者：执行每次审查的已安装技能或 Agent。用户必须指定——没有默认选项，也没有捆绑的审查者。确定其类型：
    • 命名空间 Agent（例如 plugin-dev:skill-reviewer）→ "kind": "agent"
    • 已安装技能（例如 pr-review-toolkit:review-pr）→ "kind": "skill" 如果名称可能对应两者，请查看会话的技能列表；如果仍有歧义，请询问用户。如果用户没有指定审查者，请询问——不要自行选择。
  3. 范围：循环可以修改的、相对于仓库的 glob。通用入口要求必须明确提供范围；如果用户没有提供，请提出目标目录（<repo-relative-target>/**）并在启动前确认。
2. 确定循环脚本

循环是此插件中的动态工作流 workflows/improve.js。按路径启动：scriptPath 接受解析后的绝对路径，而 Workflow 工具的 name 会解析内置和项目工作流，因此从市场安装的工作流可能无法通过 code-improver:improve 调用。按顺序尝试，命中第一个即止——主目录优先于 .，因此已安装的副本优先于此市场项目的检出副本：

  1. Bash: ls -d -- "${CLAUDE_PLUGIN_ROOT}/workflows/improve.js"
  2. Bash: ls -d -- "${CODEX_PLUGIN_ROOT}/workflows/improve.js"（如果设置了该变量）
  3. Bash: find ~/.claude ~/.codex . -maxdepth 7 -path '*/code-improver/workflows/improve.js' -print -quit 2>/dev/null

使用输出的确切路径。其插件目录（即移除 /workflows/improve.js 后的路径）就是 pluginRoot。如果三项都没有结果，请尝试一次 {name: "code-improver:improve"}；如果仍然不可用，请停止并说明无法找到该循环。不要手动拼接路径，也不要自行编造循环。

3. 调用工作流

使用 Workflow 工具运行，参数为 {scriptPath: "<the path from step 2>", args: {...}}：

{
  "target": "<absolute target path>",
  "reviewer": { "kind": "agent|skill", "name": "<namespaced-name>", "notes": "<what the reviewer should know about the target>" },
  "scope": ["<repo-relative-glob>/**"],
  "pluginRoot": "<the plugin directory from step 2>",
  "maxRounds": 5
}
  • 仅当用户要求使用不同的上限时，才设置 maxRounds。
  • pluginRoot 用于让运行过程找到其指标收集器；只有当第 2 步回退到工作流名称时，才省略此键——此时工作流会自行查找。
  • 仅当要覆盖默认值时，才设置 finalize（{"version_bump": bool, "narration_strip": bool, "docs_pass": bool}）：当目标位于插件内时进行版本号递增；始终进行叙述清理和文档检查。
  • 仅在继续运行时设置 decision（见下文）。

工作流会在后台运行，无需看管：它会审查、修复、再次审查、每轮修复后检查范围，并且只有审查通过后才能完成。 它不会提交；所有更改都会保留在工作树中。

如果 Workflow 工具不可用或访问被拒绝，请停止并说明情况。 不要自行在行内循环并直接编辑——记录、范围保护和升级保障都由工作流提供，行内模拟并不具备这些保障。

如果结果为 halted: "reviewer-unavailable"，请转达结果并停止。 此会话未安装指定的审查器；告知用户由哪个插件提供该审查器，并在安装后重新运行。不要自行审查目标。

工作流仍在运行时，不要结束当前回合。 Workflow 工具会立即返回任务 ID，稍后才会返回结果。在交互式会话中，完成通知会再次调用你——请等待。在非交互式运行中（脚本、CI、评测），后续不会再有回合：停止会导致循环中途放弃，因此启动后请轮询任务（使用返回的任务 ID 调用 TaskOutput，或等待后重新检查），直到任务完成，再转达结果。如果回复“循环正在运行，我之后再报告”，就等于放弃了这次运行。

转达结果

工作流会返回结构化结果。请如实报告——这些区别很重要：

  • converged: true — 最后一步是审查，且没有严重或主要问题。报告已用轮数、剩余次要问题数量（open_minor_count）以及产物路径（ledger_path、metrics）。
  • capped: true — 修复预算已用尽，最终审查仍发现阻塞问题。请明确说明：已达上限，未收敛，并列出 open_blocking。不要将其描述为成功。
  • escalation — 循环检测到未能收敛（问题反复出现、数量未减少，或修复将问题转移到了其他位置）。请将升级消息和问题 ID 转达给用户：这需要设计决策，而不是继续增加轮数。
  • halted — 某项保护机制触发（范围违规、新文件未登记、审查器已失效或不可用，或最终处理步骤产生的更改未通过后续检查）。请转达 violations/new_untracked_files 中的路径、finalize_regressions 中的位置，以及备注。
  • notes 始终随结果一同返回——请一并说明；其中可能包含“已初始化 git 仓库”等重要警告。

升级后继续运行

循环会按设计在升级时停止。用户作出决定后，请使用相同的 target 和 reviewer，并启动一次新的运行：

{ "decision": "<the user's ruling, verbatim>" }

新运行会重新加载磁盘上的记录，因此所有问题、驳回和结论都会保留——轮数会重新开始，但推导过程不会重来。

若要停止正在运行的循环，请停止工作流任务（TaskStop）；磁盘上的记录会更新到最后一轮，重新运行时会从那里继续。

不适用场景

  • Claude Code 技能：使用 skill-improver 条目——它会接入合适的审查器
  • 分支 / 拉取请求：使用 pr-improver 条目——它会根据差异推导范围
  • 一次性审查：直接调用审查器；循环的价值在于迭代
  • 快速单项修复：直接编辑文件

评论

支持 Markdown