PR 改进器
通过运行 /code-improver:improve 改善当前分支——这是一个动态工作流，它将 PR 审查器和修复子代理循环作用于分支的变更，直到审查报告为零严重/主要问题。循环、其分类账和防护机制都存在于工作流中；该技能根据分支差异推导出作用范围并传递结果。
启动循环
用户提供了：$ARGUMENTS（如果为空，则从对话中获取基础分支和偏好）。
1. 解析分支及其变更面
- 仓库根目录：
git rev-parse --show-toplevel。在仓库外部失败并报错。 - 基础分支：如果给出参数则使用，否则使用仓库的默认分支（
git symbolic-ref refs/remotes/origin/HEAD的短名称，回退到main）。如果当前分支就是基础分支，则拒绝运行——因为没有差异可以改进。 - 更改的文件：
git diff --name-only <base>...HEAD。如果为空，则说明并停止。 - 作用范围：将更改的文件映射到其目录，并加宽——按文件通配符限制太严格（PR 修复可能会在更改的代码旁边添加测试）。将每个更改的文件映射到其仓库相对目录通配符
<dir>/**（只有在根目录下文件发生更改时，才使用**），然后去重并删除被其他通配符覆盖的。
2. 解析循环脚本
循环是该插件中的动态工作流 workflows/improve.js。通过路径启动：scriptPath 接受已解析的绝对路径，而 Workflow 工具的 name 解析内置和项目工作流，因此市场安装的工作流可能不会响应 code-improver:improve。依次尝试，先赢——主目录排在 . 之前，因此安装的副本优先于市场签出：
Bash: ls -d -- "${CLAUDE_PLUGIN_ROOT}/workflows/improve.js"Bash: ls -d -- "${CODEX_PLUGIN_ROOT}/workflows/improve.js"（如果设置了该变量）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: "<步骤2中的路径>", args: {...}}：
{
"target": "<仓库根目录>",
"reviewer": {
"kind": "skill",
"name": "pr-review-toolkit:review-pr",
"notes": "审查工作树相对于 <base> 的变更，如同一个 PR：检查正确性、测试、错误处理，以及该技能规定的审查维度。"
},
"scope": ["<推导出的目录通配符>/**"],
"pluginRoot": "<步骤2中的插件目录>",
"maxRounds": 5
}
reviewer——上述默认值需要pr-review-toolkit插件。当用户指定不同的 PR 审查器（技能或代理）时，使用该审查器，并相应设置kind。maxRounds仅在用户要求不同上限时设置。pluginRoot允许运行找到其指标收集器；仅当步骤2回退到工作流名称时省略该键——工作流随后会自行搜索。finalize默认值适用于 PR：不进行版本升级（除非分支位于插件内），叙述剥离和文档传递继续。decision仅在继续时使用（见下文）。
循环的基线快照是循环开始时的树——其作用范围保护机制保护了分支的未提交工作；PR 自身的提交是审查器审查的内容。
工作流在后台运行，无需监视：它审查、修复、重新审查，每次修复后检查作用范围，并且只能在审查通过时完成。它从不提交；所有更改保留在工作树中。
如果 Workflow 工具不可用或被拒绝，请停止并说明。 请勿通过直接编辑即兴实现循环——分类账、作用范围保护和升级保障都存在于工作流中，而内联模仿则没有这些。
如果结果是 halted: "reviewer-unavailable"，请传递该信息并停止。 审查器未在此会话中安装；告诉用户哪个插件提供了该审查器（默认需要 pr-review-toolkit），并在安装后重新运行。请勿自行审查分支。
不要在循环运行时结束你的回合。 Workflow 工具立即返回任务 ID；结果稍后到达。在交互式会话中，完成通知会重新调用你——等待它。在非交互式运行（脚本、CI、评估）中，没有后续回合：停止会放弃正在进行中的循环，因此启动后，轮询任务（使用返回的任务 ID 调用 TaskOutput，或 sleep-and-recheck）直到完成，然后传递结果。回答“循环正在运行，我稍后将报告”的会话会丢失运行。
传递结果
工作流返回结构化结果。诚实报告它——区别很重要：
converged: true——最后一个操作是审查，发现零严重/主要问题。报告使用的轮数、剩余的次要问题（open_minor_count）以及工件路径（ledger_path、metrics）。capped: true——修复预算耗尽，最终审查仍然发现阻塞性问题。明确说明：已上限，未收敛，并列出open_blocking。不要将其呈现为成功。escalation——循环检测到它没有收敛（反复出现的问题、未减少的问题计数、或修复将问题转移到别处）。向用户传递升级消息和问题 ID：这需要设计决策，而不是更多轮次。halted——防护机制触发（作用范围违规、未注册的新文件、死亡或不可用的审查器、或者最终化传递中的自身编辑未能通过后续检查）。传递violations/new_untracked_files中的路径、finalize_regressions中的位置以及说明。notes——始终随结果传递；展示它们；它们包含诸如“已初始化 git 仓库”之类的显眼警告。
升级后继续
按照设计，循环在升级时停止。当用户做出决定时，使用相同的参数开始一次新的运行，并添加：
{ "decision": "<用户裁决，逐字>" }
新的运行会重新加载磁盘上的分类账，因此每个问题、拒绝和判决都会延续——轮次重新开始，但不会重新推导。
要停止正在运行的循环，停止工作流任务（TaskStop）；磁盘上的分类账保持到最后一个轮次的最新状态，重新运行将从该处恢复。
何时不使用
- 一次性审查：直接运行 PR 审查技能；循环的价值在于迭代
- 一种技能：使用
skill-improver入口——它会连接正确的审查器 - 未推送的探索性工作：审查-修复循环会固化 diff；当形态还不稳定时，手动迭代提供更多控制