review-fix

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/review-fix — Review a change, address findings, commit clean, force-push

/review-fix — 审查变更、处理结果、清晰提交、强制推送

Run six reviewers over a change, apply the meaningful suggestions, fold the fixes into clean commits, and force-push with lease. Works on four kinds of target:

Uncommitted changes (no arg, dirty working tree) — apply fixes, commit. No push.
Current feature branch (no arg, commits ahead of
```
main
```
) — fold fixes, force-push.
GitHub PR (
```
#1234
```
,
```
1234
```
, or a
```
.../pull/1234
```
URL) — check out, fix, force-push.
GitLab MR (a
```
.../merge_requests/1234
```
URL) — check out, fix, force-push.

通过六个审查工具处理变更，应用有意义的建议，将修复内容整合为清晰的提交，并使用lease参数强制推送。支持四种目标类型：

未提交的变更（无参数，工作区未清理）——应用修复并提交，无需推送。
当前功能分支（无参数，提交领先于
```
main
```
分支）——整合修复内容并强制推送。
GitHub PR（
```
#1234
```
、
```
1234
```
或
```
.../pull/1234
```
格式的URL）——检出分支、修复问题并强制推送。
GitLab MR（
```
.../merge_requests/1234
```
格式的URL）——检出分支、修复问题并强制推送。

Argument

参数

Optional. The target. If omitted, operate on the current branch and working tree.

可选参数，指定目标。如果省略，则对当前分支和工作区进行操作。

Workflow

工作流程

0. Resolve the target into a local working state

0. 将目标解析为本地工作状态

bash

git branch --show-current
git status --short
git log origin/main..HEAD --oneline

No arg — work on the current branch / working tree as-is.
GitHub PR (
```
#N
```
, bare
```
N
```
, or
```
github.com/.../pull/N
```
) — the working tree must be clean first (
```
git status --short
```
empty); if dirty, stop and ask the user to stash or commit. Then
```
gh pr checkout N
```
.

GitLab MR (

gitlab.../merge_requests/N

) — same clean-tree check, then

glab mr checkout N

Identify the base branch (usually

main

); the reviewers diff against it.

bash

git branch --show-current
git status --short
git log origin/main..HEAD --oneline

无参数——直接处理当前分支/工作区。
GitHub PR（
```
#N
```
、纯数字
```
N
```
或
```
github.com/.../pull/N
```
）——工作区必须先清理（
```
git status --short
```
无输出）；若未清理，则停止操作并提示用户暂存或提交。随后执行
```
gh pr checkout N
```
。
GitLab MR（
```
gitlab.../merge_requests/N
```
）——同样需要先检查工作区是否清理，随后执行
```
glab mr checkout N
```
。

确定基准分支（通常为

main

）；审查工具将基于该分支进行差异对比。

1. Review-and-fix loop (repeat until a round is clean)

1. 审查-修复循环（重复执行直至一轮审查无问题）

This is a loop, not a one-shot. Keep cycling until a full review round surfaces no meaningful findings. Do not stop after the first pass, and do not ask the user to say "re-run" — the loop is the whole point of this skill.

Each round:

1a. Run the six reviews in parallel (report-only subagents). Spawn six subagents in a single message so they run concurrently. Pin each reviewer's model per the Model column below: one correctness reviewer (

code-review

) runs on Opus as the bug anchor (a missed bug costs more than the tokens); the rest run on Sonnet (holds up fine, saves the bulk of the spend across up to 5 rounds). You (the orchestrator) stay on the session model to triage and apply fixes. They are read-only: each one only reports findings — none of them writes files, commits, or pushes. You are the single writer (1c); concurrent

/simplify

/code-review --fix

in one working tree would race on edits.

Before you build the prompts, resolve

<ask-exemplar-dir>

ask-exemplar

sets

disable-model-invocation

, so a subagent cannot invoke it as a skill. Replace the placeholder with the absolute path of the

ask-exemplar

skill directory (a sibling of this skill's directory) so the subagent reads the files directly.

Subagent	Model	Prompt
code-review	opus	"Invoke the `/code-review` skill (high effort, no `--fix` , no `--comment` ) on the current branch diff vs `<base>` . Do not modify, commit, or push anything. Return the meaningful findings as a numbered list: file:line, the issue, and the suggested change."
simplify	sonnet	"Run the `/simplify` skill's analysis on the current branch diff vs `<base>` , but DO NOT write any files. Instead return the simplifications it would make as a numbered list: file:line, what to simplify, and the proposed edit."
brooks-review	sonnet	"Invoke the `/brooks-review` skill on the current branch diff vs `<base>` . Do not modify any files. Return the findings as Symptom → Source → Consequence → Remedy."
review	sonnet	"Invoke the `/review` skill on the current branch diff vs `<base>` (review the diff directly — do not assume a PR exists). Do not modify, comment, commit, or push anything. Return the meaningful findings as a numbered list: file:line, the issue, and the suggested change."
ask-exemplar	sonnet	"Read the `ask-exemplar` skill at `<ask-exemplar-dir>` (SKILL.md, then REFERENCE.md when it applies) and run its Embedded Evaluation on the current branch diff vs `<base>` . Do not modify, commit, or push anything. Return the Top Fixes as a numbered list: the finding, the fix, the Confidence, and the tradeoff. Return exactly `No Top Fixes.` when clean."
zero-tech-debt	sonnet	"Run the `/zero-tech-debt` skill's analysis on the current branch diff vs `<base>` , but DO NOT write any files. Instead return what it would rework within the diff's footprint as a numbered list: file:line, the dead compatibility path or accidental complexity, and the proposed edit."

Wait for all six to return.

Treat

No Top Fixes.

from

ask-exemplar

as a clean report.

1b. Triage findings → the meaningful set. Merge and dedupe the six reports. Keep only what is worth a code change:

Keep: real correctness bugs, genuine simplifications/reuse (including dead compatibility paths with no current caller and accidental complexity), true design or maintainability problems with a concrete remedy.
Drop: stylistic nits that already match the repo's conventions, anything that conflicts with the user's documented code style, speculative or out-of-scope "improvements", and likely false positives.

When a finding is borderline low value, prefer skipping it — surgical changes beat churn. Print the kept set and the dropped set (one line each) so the user sees the call.

1c. Apply the accepted fixes (you are the only writer). Read each file before editing it. Apply the kept findings as tight, surgical edits. Every changed line should trace to a kept finding — do not "improve" adjacent code. Leave the edits in the working tree; defer committing until step 2.

1d. Verify — fast checks and behavior. Run the project's fast checks (tests / lint / type-check) for the files you touched (

ruff

ty

, and the relevant

pytest

here). Treat green as necessary, not sufficient: a passing suite says nothing about output no test asserts on. So when the diff touches an output path — help/usage text, rendered or formatted output, ANSI/rich markup, templates, serializers, log formatting — also run the affected surface and read the result, diffing against the base version's output where feasible. Deleting an escape/quote/encode/sanitize/validate call is the sharpest case: it reads as a clean simplification but is often a load-bearing guard, and only rendering shows the breakage. When you find such a bug, lock it with an assertion on the rendered output so these cheap checks catch a recurrence. Fix any red check or wrong render before the next round; do not commit while checks are red.

1e. Decide whether to loop again.

If this round kept one or more findings → go back to 1a. The new round reviews the now-fixed code and catches issues the fixes introduced or exposed.
If this round kept zero findings (all six reviewers came back clean or drop-only) → the change is settled. Exit the loop and go to step 2.

Stop conditions to avoid spinning. Cap at 5 rounds. Also bail out early if you notice oscillation (a later round re-proposes an edit you deliberately dropped, or reverses a fix from an earlier round). If you hit the cap or detect oscillation before a clean round, stop, list what is still outstanding, and ask the user how to proceed instead of looping further.

这是一个循环流程，而非单次执行。持续循环直至完整的一轮审查未发现有意义的问题。不要在第一次执行后停止，也无需等待用户触发“重新运行”——循环是该技能的核心设计。

每一轮循环包含以下步骤：

1a. 并行运行六个审查工具（仅报告结果的子Agent）。在一条消息中生成六个子Agent以实现并发运行。按照下表的Model列固定每个审查工具的模型：一个正确性审查工具（

code-review

）使用Opus模型作为错误检测核心（遗漏错误的代价远高于消耗的令牌）；其余工具使用Sonnet模型（表现稳定，且在最多5轮循环中能大幅降低令牌消耗）。你作为编排者将使用会话模型来筛选和应用修复。这些子Agent均为只读：每个工具仅报告审查结果——不会修改文件、提交或推送。你是唯一的写入者（步骤1c）；在同一工作区中并发执行

/simplify

/code-review --fix

会导致编辑冲突。

构建提示词前，先解析

<ask-exemplar-dir>

：

ask-exemplar

技能设置了

disable-model-invocation

，因此子Agent无法将其作为技能调用。将占位符替换为

ask-exemplar

技能目录的绝对路径（与当前技能目录同级），以便子Agent直接读取文件。

子Agent	模型	提示词
code-review	opus	"在当前分支与 `<base>` 的差异上调用 `/code-review` 技能（高投入，不使用 `--fix` ，不使用 `--comment` ）。请勿修改、提交或推送任何内容。将有意义的审查结果以编号列表形式返回：文件:行号、问题描述及建议修改方案。"
simplify	sonnet	"在当前分支与 `<base>` 的差异上运行 `/simplify` 技能的分析，但请勿修改任何文件。相反，将其会执行的简化操作以编号列表形式返回：文件:行号、简化内容及提议的编辑方案。"
brooks-review	sonnet	"在当前分支与 `<base>` 的差异上调用 `/brooks-review` 技能。请勿修改任何文件。以‘症状→根源→影响→补救方案’的格式返回审查结果。"
review	sonnet	"在当前分支与 `<base>` 的差异上调用 `/review` 技能（直接审查差异——不要假设存在PR）。请勿修改、评论、提交或推送任何内容。将有意义的审查结果以编号列表形式返回：文件:行号、问题描述及建议修改方案。"
ask-exemplar	sonnet	"读取 `<ask-exemplar-dir>` 路径下的 `ask-exemplar` 技能文件（先读SKILL.md，适用时再读REFERENCE.md），并在当前分支与 `<base>` 的差异上运行其嵌入式评估。请勿修改、提交或推送任何内容。将首要修复项以编号列表形式返回：审查结果、修复方案、置信度及权衡点。若无问题则返回 `No Top Fixes.` 。"
zero-tech-debt	sonnet	"在当前分支与 `<base>` 的差异上运行 `/zero-tech-debt` 技能的分析，但请勿修改任何文件。相反，将其会在差异范围内重构的内容以编号列表形式返回：文件:行号、无用兼容路径或冗余复杂度，以及提议的编辑方案。"

等待所有六个子Agent返回结果。

将

ask-exemplar

返回的

No Top Fixes.

视为无问题报告。

1b. 筛选审查结果→保留有意义的内容。合并并去重六个报告的结果。仅保留值得修改代码的内容：

保留：真实的正确性错误、真正的简化/复用（包括无当前调用者的无用兼容路径和冗余复杂度）、有具体补救方案的设计或可维护性问题。
剔除：已符合仓库规范的风格细节、与用户文档化代码风格冲突的内容、推测性或超出范围的“改进”，以及可能的误报。

若某一结果的价值较低且处于边界，优先跳过——精准修改优于无意义的变更。打印保留和剔除的结果集（各一行），以便用户了解筛选依据。

1c. 应用已接受的修复方案（你是唯一的写入者）。编辑前先读取每个文件。将保留的审查结果作为精准、针对性的编辑应用。每一处修改都应对应一个保留的审查结果——请勿“优化”相邻代码。将编辑内容留在工作区；推迟至步骤2再提交。

1d. 验证——快速检查+行为验证。针对你修改的文件运行项目的快速检查（测试/ lint/类型检查）（此处使用

ruff

、

ty

及相关

pytest

）。通过检查是必要条件，但非充分条件：测试套件通过并不代表未被测试断言覆盖的输出无问题。因此，若差异涉及输出路径——帮助/使用文本、渲染或格式化后的输出、ANSI/rich标记、模板、序列化器、日志格式——还需运行受影响的功能并查看结果，尽可能与基准版本的输出进行对比。删除转义/引用/编码/ sanitize/验证调用是最危险的情况：这看起来是简洁的简化，但往往是关键的防护措施，只有通过渲染才能发现问题。若发现此类错误，在渲染输出上添加断言，以便后续的快速检查能检测到重复问题。在下一轮循环前修复所有失败的检查或错误的渲染结果；检查失败时请勿提交。

1e. 决定是否继续循环。

若本轮保留了一个或多个审查结果→回到1a。新一轮审查将针对已修复的代码，捕捉修复引入或暴露的问题。
若本轮未保留任何审查结果（六个审查工具均返回无问题或仅返回需剔除的内容）→变更已稳定。退出循环并进入步骤2。

避免无限循环的停止条件。最多执行5轮循环。若发现循环振荡（后续循环重新提议你故意剔除的编辑，或反转之前循环的修复），也需提前终止。若在达到无问题状态前触发了循环上限或检测到振荡，停止操作，列出仍未解决的问题，并询问用户如何继续，而非继续循环。

2. Commit clean

2. 清晰提交

Uncommitted target (nothing ahead of base) — commit the fixes. Use the
```
git-hunk
```
CLI to split into logical commits. Stop here: there is nothing to force-push.
Branch / PR / MR target (commits ahead of base) — fold each fix into the commit it belongs to.
```
git commit --fixup
```
only captures staged changes, so stage each logical group before committing it:
bash
```
git add <paths-for-this-group>                          # stage just this group's fix
git commit --fixup=<sha-of-the-commit-being-fixed>      # repeat per logical group
GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash --autostash <base>
```
(To split different hunks of one file across separate fixups, use
```
git-hunk
```
to stage at hunk granularity rather than whole files.) Interactive rebase is unavailable in this environment;
```
GIT_SEQUENCE_EDITOR=true
```
runs the autosquash non-interactively. If the autosquash stops on a merge conflict, resolve it and
```
git rebase --continue
```
; if that is not clean,
```
git rebase --abort
```
and commit the fix as its own commit rather than leaving the tree mid-rebase. If a fix is genuinely new behavior rather than a correction to an existing commit, make it its own commit via
```
git-hunk
```
instead.

Never add a

Co-authored-by

trailer.

未提交的目标（无领先于基准分支的提交）——提交修复内容。使用
```
git-hunk
```
CLI将修改拆分为逻辑提交。到此为止：无需强制推送。
分支/PR/MR目标（提交领先于基准分支）——将每个修复内容整合至对应的原始提交中。
```
git commit --fixup
```
仅捕获已暂存的变更，因此需先暂存每个逻辑分组的内容再提交：
bash
```
git add <paths-for-this-group>                          # 仅暂存该分组的修复内容
git commit --fixup=<sha-of-the-commit-being-fixed>      # 每个逻辑分组重复执行此步骤
GIT_SEQUENCE_EDITOR=true git rebase -i --autosquash --autostash <base>
```
（若需将同一文件的不同代码块拆分至不同的fixup提交中，使用
```
git-hunk
```
按代码块粒度暂存，而非按整个文件暂存。）此环境中无法使用交互式变基；
```
GIT_SEQUENCE_EDITOR=true
```
将自动执行autosquash而非交互式操作。若autosquash因合并冲突停止，解决冲突后执行
```
git rebase --continue
```
；若无法顺利解决，执行
```
git rebase --abort
```
并将修复内容作为独立提交，而非让工作区处于变基中途状态。若修复内容是真正的新行为而非对现有提交的修正，使用
```
git-hunk
```
将其作为独立提交。

请勿添加

Co-authored-by

标记。

3. Confirm, then force-push with lease

3. 确认后使用lease参数强制推送

Force-pushing is hard to undo. Stop and show the user: the kept-findings summary,

git log <base>..HEAD --oneline

, and

git diff <base>..HEAD --stat

. Ask for explicit permission to push. Earlier approval of the overall task is not this permission.

Only after the user says go:

bash

git push --force-with-lease

For a fresh-from-

main

uncommitted target there is nothing to push — end at step 2 and say so.

强制推送难以撤销。停止操作并向用户展示：保留的审查结果摘要、

git log <base>..HEAD --oneline

的输出，以及

git diff <base>..HEAD --stat

的输出。请求用户明确的推送许可。用户此前对整体任务的批准不能替代此许可。

仅在用户确认后执行：

bash

git push --force-with-lease

对于刚从

main

分支检出且未提交的目标，无需推送——在步骤2结束并告知用户即可。

Notes

注意事项

The six reviewers must stay report-only. If you ever let
```
/simplify
```
,
```
/zero-tech-debt
```
, or
```
/code-review --fix
```
write in a subagent, parallel runs corrupt each other's edits.
"Meaningful" is a judgment call, not a checklist. Defend the drops if asked.
The six reviewers (1a) are static — they cannot see bugs that only surface at runtime; that is what the behavioral half of 1d exists to catch, not them.
If prior work was stashed to check out a PR/MR in step 0, remind the user it is stashed when you finish.

六个审查工具必须保持只读状态。若允许
```
/simplify
```
、
```
/zero-tech-debt
```
或
```
/code-review --fix
```
在子Agent中写入内容，并行运行会破坏彼此的编辑结果。
“有意义”是主观判断，而非 checklist。若被询问，需说明剔除内容的理由。
六个审查工具（步骤1a）是静态的——无法检测仅在运行时出现的bug；这正是步骤1d中行为验证部分存在的意义，而非依赖这些审查工具。
若在步骤0中为检出PR/MR而暂存了之前的工作内容，完成后需提醒用户该内容仍处于暂存状态。