run-repair-loop

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Skill: Run Repair Loop (Review + Test + Fix)

技能：运行修复循环（Review + Test + Fix）

Purpose

用途

Converge a codebase or change set to "clean" by running a multi-iteration loop:

Review (find problems early and prevent regressions),
Test (get executable signal),
Fix (apply the smallest correct patch),
Repeat until no blocking issues remain or a stop condition is hit.

通过运行多迭代循环将代码库或变更集收敛到「干净」状态：

审查（Review）：尽早发现问题，预防回归
测试（Test）：获取可执行的反馈信号
修复（Fix）：应用最小的正确补丁
重复以上步骤，直到无遗留阻塞问题或触发停止条件

Core Objective

核心目标

Primary Goal: Converge the repository to a "clean" state — all tests passing and no

critical

major

review findings — using a bounded, evidence-driven review-test-fix loop.

Success Criteria (ALL must be met):

✅ Definition of done resolved: Pre-flight choices (scope, test mode, max iterations, allowed actions) are confirmed before the loop starts
✅ Evidence-first each iteration: Each iteration produces at least one of: a new test result, a new review signal, or a concrete code change
✅ Tests rerun after fixes: The failing test command (or a targeted subset) is always rerun after applying a fix within the same iteration
✅ Bounded loop: The loop terminates due to convergence or an explicit stop condition — no infinite retries
✅ Structured final report: Output includes a Repair Loop Report (Appendix: Output contract) with commands run, failures, patches, and remaining risks

Acceptance Test: Does the final report show either (a) tests passing with no blocking review findings, or (b) an explicit stop condition with clear remaining issues and options for the user?

首要目标：通过有边界、证据驱动的审查-测试-修复循环，将仓库收敛到「干净」状态——所有测试通过，无

critical

major

级别的审查问题。

成功标准（必须全部满足）：

✅ 完成定义确认：循环启动前确认前置配置（范围、测试模式、最大迭代次数、允许操作）
✅ 每轮迭代基于证据：每轮迭代至少产出以下一项内容：新的测试结果、新的审查信号、具体的代码变更
✅ 修复后重跑测试：同一迭代内应用修复后，必须重跑失败的测试命令（或对应的目标子集）
✅ 循环有界：循环会因达到收敛状态或明确的停止条件终止，不会无限重试
✅ 结构化最终报告：输出包含修复循环报告（附录：输出约定），记录执行的命令、失败内容、补丁和剩余风险

验收测试：最终报告是否满足以下任一情况：(a) 测试全部通过，无阻塞性审查问题；(b) 触发明确的停止条件，清晰说明剩余问题和用户可选方案？

Scope Boundaries

范围边界

This skill handles:

Multi-iteration review → test → fix loops
Diff-scoped and codebase-scoped review using
```
review-diff
```
and
```
review-code
```
Test execution via
```
run-automated-tests
```
(fast/ci/full modes)
Minimal targeted patches with preserved API contracts
Stop condition detection (no progress, environment blockers, flaky tests, iteration limit)
Structured repair loop report output

This skill does NOT handle:

Installing dependencies without explicit user confirmation
Using network or starting Docker/services without user confirmation
Large refactors without explicit user approval
Modifying unrelated sibling repositories
Disabling tests, weakening assertions, or deleting coverage without explicit user approval

Handoff point: When the loop converges or hits a stop condition, present the Repair Loop Report to the user. For risky changes (schema migration, auth changes, broad refactor), pause and ask for explicit approval before applying.

本技能支持：

多轮迭代的审查→测试→修复循环
基于
```
review-diff
```
和
```
review-code
```
的 diff 范围/全代码库范围审查
通过
```
run-automated-tests
```
执行测试（快速/CI/全量模式）
保留API契约的最小针对性补丁
停止条件检测（无进展、环境阻塞、测试抖动、达到迭代上限）
结构化修复循环报告输出

本技能不支持：

无用户明确确认的情况下安装依赖
无用户明确确认的情况下使用网络或启动Docker/服务
无用户明确批准的情况下进行大规模重构
修改无关的同级仓库
无用户明确批准的情况下禁用测试、弱化断言或删除覆盖率统计

交接节点：当循环达到收敛状态或触发停止条件时，向用户展示修复循环报告。如果是高风险变更（schema迁移、权限变更、大范围重构），需要暂停并征求用户明确批准后再执行。

Use Cases

使用场景

"Keep fixing until tests pass."
"Do a review-test-fix loop and make the repo green."
"Stabilize this PR/change set with iterative testing and targeted fixes."
"Run CI-like tests, fix failures, repeat until stable."

"持续修复直到测试通过。"
"执行审查-测试-修复循环，让仓库状态变绿。"
"通过迭代测试和针对性修复，稳定这个PR/变更集。"
"运行类CI测试，修复失败用例，重复直到稳定。"

Behavior

行为逻辑

1. Pre-flight (must resolve once)

1. 前置校验（只需执行一次）

Confirm or default the following:

Target: repo path (default
```
.
```
) and scope:
- ```
diff
```
  (default): focus on current changes, prioritize
```
review-diff
```
  .
- ```
codebase
```
  : review a specified path set, prioritize
```
review-codebase
```
  /language skills via
```
review-code
```
  .
Definition of done:
- Tests: chosen test plan passes (fast/ci/full).
- Review: no
```
critical
```
  /
```
major
```
  review findings remain.
- If only
```
minor
```
  /
```
suggestion
```
  findings remain, list them and ask whether to address them.
Loop bounds:
- ```
max_iterations
```
  default:
```
5
```
  .
- ```
time_budget
```
  default: "best effort"; if user provides a time limit, honor it strictly.
Allowed actions (ask if unclear; default to safer choice):
- Modify repo files: Yes (this skill is for fixing), but keep changes minimal.
- Install dependencies: No without confirmation.
- Network access: No without confirmation.
- Docker/services (DB/Redis/etc.): No without confirmation.
- Large refactors: No without confirmation.

确认或使用默认值配置以下项：

目标：仓库路径（默认
```
.
```
）和范围：
- ```
diff
```
  （默认）：聚焦当前变更，优先使用
```
review-diff
```
- ```
codebase
```
  ：审查指定路径集合，优先通过
```
review-code
```
  调用
```
review-codebase
```
  /对应语言技能
完成定义：
- 测试：选定的测试方案执行通过（快速/CI/全量）
- 审查：无
```
critical
```
  /
```
major
```
  级别的审查问题遗留
- 如果仅剩余
```
minor
```
  /
```
suggestion
```
  级别的问题，列出问题并询问用户是否需要处理
循环边界：
- ```
max_iterations
```
  默认值：
```
5
```
- ```
time_budget
```
  默认值：「尽力而为」；如果用户指定了时间限制，严格遵守
允许操作（不明确时询问用户，默认选择更安全的选项）：
- 修改仓库文件：是（本技能用于修复），但保持变更最小化
- 安装依赖：否，除非获得用户确认
- 网络访问：否，除非获得用户确认
- Docker/服务（数据库/Redis等）：否，除非获得用户确认
- 大规模重构：否，除非获得用户确认

2. Iteration loop

2. 迭代循环

For

i = 1..max_iterations

Collect current signals (evidence-first)
- If scope =
```
diff
```
  : run/perform a
```
review-diff
```
  pass over the current diff/untracked additions.
- If scope =
```
codebase
```
  or user wants deeper review: run
```
review-code
```
  (or the relevant atomic review skill(s)).
- If a previous iteration had test failures, prioritize resolving those failures first.
Run tests
- Use
```
run-automated-tests
```
  to discover and run the best matching test command(s) in the selected mode:
  - ```
  fast
```
  (default): unit tests only, minimal setup.
- ```
ci
```
    : mirror CI steps as closely as possible.
  - ```
  full
```
  : include integration/e2e (only with explicit confirmation for dependencies/services).
- Capture:
  - the first failing command + exit code
  - the most relevant error excerpt (do not dump massive logs unless asked)
Synthesize a fix plan (smallest correct patch)
- Choose one primary issue to fix first:
  - First failing test/command usually wins (highest signal).
  - If review found a
```
critical
```
    security/correctness issue, fix that before or alongside tests.
- Prefer fixes that:
  - change the smallest surface area
  - preserve API/contracts unless explicitly approved
  - add or adjust tests when fixing a bug (when feasible)
Apply fix
- Implement the patch.
- Avoid unrelated formatting or churn.
- If the fix requires a risky change (schema migration, auth changes, broad refactor), pause and ask.
Re-run the minimal validation
- Re-run the most relevant failing test subset if the framework supports it; otherwise re-run the same test command.
- If fixed, proceed to the next remaining failure/finding within the same iteration only if it is trivial; otherwise go to the next loop iteration.
Stop early when converged
- If tests pass and there are no
```
critical
```
  /
```
major
```
  review findings, stop.

当

i = 1..max_iterations

时：

收集当前信号（证据优先）
- 如果范围 =
```
diff
```
  ：对当前diff/未跟踪的新增内容执行
```
review-diff
```
  扫描
- 如果范围 =
```
codebase
```
  或用户需要更深层的审查：运行
```
review-code
```
  （或对应的原子审查技能）
- 如果上一轮迭代存在测试失败，优先解决这些失败问题
运行测试
- 使用
```
run-automated-tests
```
  发现并运行所选模式下最匹配的测试命令：
  - ```
  fast
```
  （默认）：仅运行单元测试，最小化配置
- ```
ci
```
    ：尽可能镜像CI执行步骤
  - ```
  full
```
  ：包含集成/E2E测试（仅在用户明确批准依赖/服务的前提下使用）
- 捕获以下内容：
  - 第一个失败的命令 + 退出码
  - 最相关的错误摘要（除非用户要求，否则不输出大量日志）
制定修复方案（最小正确补丁）
- 优先选择一个核心问题优先修复：
  - 通常优先处理第一个失败的测试/命令（信号优先级最高）
  - 如果审查发现
```
critical
```
    级别的安全/正确性问题，在修复测试问题的同时或之前优先修复该问题
- 优先选择符合以下要求的修复方案：
  - 修改的影响范围最小
  - 除非获得明确批准，否则保留API/契约
  - 修复bug时尽可能新增或调整对应的测试用例
应用修复
- 实现补丁
- 避免无关的格式调整或无效变更
- 如果修复需要高风险变更（schema迁移、权限变更、大范围重构），暂停并询问用户
重跑最小化验证
- 如果框架支持，重跑最相关的失败测试子集；否则重跑相同的测试命令
- 如果修复成功，仅当剩余失败/问题非常简单时，在同一迭代内继续处理；否则进入下一轮循环
达到收敛状态时提前停止
- 如果测试全部通过且无
```
critical
```
  /
```
major
```
  级别的审查问题，停止循环

3. Stop conditions (must not loop forever)

3. 停止条件（禁止无限循环）

Stop and ask the user for direction if any occur:

No progress: the same failure repeats for 2 iterations with no new information.
Environment blocker: missing toolchain, missing secrets, or unavailable dependency (DB/Docker) and user has not approved required setup.
Flaky tests: non-deterministic failures suspected (e.g., passes on retry without changes).
Iteration limit reached:
```
max_iterations
```
exhausted with remaining failures.

When stopping, provide the shortest path options:

run a different test mode (
```
fast
```
->
```
ci
```
->
```
full
```
)
allow installs/network/Docker
narrow scope (fix only first failing test)
increase iteration limit

如果出现以下任一情况，停止循环并征求用户下一步指示：

无进展：相同的失败连续出现2轮迭代，无新信息输入
环境阻塞：缺少工具链、密钥或依赖不可用（数据库/Docker），且用户未批准所需的配置操作
测试抖动：疑似非确定性失败（例如无代码变更的情况下重试后测试通过）
达到迭代上限：
```
max_iterations
```
已耗尽，仍有失败问题遗留

停止时向用户提供最短路径可选方案：

运行不同的测试模式（
```
fast
```
→
```
ci
```
→
```
full
```
）
允许安装依赖/网络访问/Docker
缩小范围（仅修复第一个失败的测试）
提高迭代上限

Input & Output

输入与输出

Input

输入

Target path (default
```
.
```
)
Scope:
```
diff
```
(default) or
```
codebase
```
(+ paths)
Test mode:
```
fast
```
(default),
```
ci
```
,
```
full
```
Constraints: allow installs/network/Docker/services (yes/no)
```
max_iterations
```
(default
```
5
```
)
Optional: time budget

目标路径（默认
```
.
```
）
范围：
```
diff
```
（默认）或
```
codebase
```
（+路径）
测试模式：
```
fast
```
（默认）、
```
ci
```
、
```
full
```
约束：是否允许安装依赖/网络访问/Docker/服务（是/否）
```
max_iterations
```
（默认
```
5
```
）
可选：时间预算

Output

输出

Repair Loop Report:
- Definition of done used
- Evidence sources (which files/CI configs informed test plan)
- For each iteration:
  - test command(s) run and result
  - first failure excerpt (if any)
  - changes made (files touched + intent)
  - remaining failures/findings
- Final state:
  - tests passing (which commands)
  - remaining review items (if any) and whether they are blocking

修复循环报告：
- 使用的完成定义
- 证据来源（哪些文件/CI配置影响了测试方案）
- 每轮迭代详情：
  - 运行的测试命令和结果
  - 第一个失败内容摘要（如果有）
  - 做出的变更（修改的文件+目的）
  - 剩余的失败/问题
- 最终状态：
  - 测试是否通过（哪些命令通过）
  - 剩余的审查项（如果有）以及是否是阻塞性的

Restrictions

限制条件

Hard Boundaries

硬性边界

Do not install dependencies, use network, start Docker/services, or run destructive commands without explicit confirmation.
Do not ask the user to paste secrets into chat. Prefer local env files or documented dev flows.
Do not "fix" by disabling tests, weakening assertions, or deleting coverage unless the user explicitly approves and the tradeoff is documented.
Avoid large refactors as a default; prioritize minimal patches that unblock correctness.
Keep changes scoped to the target repository; do not modify unrelated sibling repos.

无用户明确确认的情况下，不得安装依赖、使用网络、启动Docker/服务或运行破坏性命令
不得要求用户在聊天中粘贴密钥，优先使用本地环境变量文件或文档化的开发流程
除非用户明确批准且记录了权衡取舍，否则不得通过禁用测试、弱化断言或删除覆盖率的方式「修复」问题
避免默认进行大规模重构，优先使用能解决正确性问题的最小补丁
保持变更在目标仓库范围内，不得修改无关的同级仓库

Skill Boundaries (Avoid Overlap)

技能边界（避免功能重叠）

Do NOT do these (other skills handle them):

Test execution only (no review or fix loop): Use
```
run-automated-tests
```
Test quality assessment (coverage, structure, edge-case adequacy): Use
```
review-testing
```
Comprehensive code review (without test-fix iteration): Use
```
review-code
```
Diff-only review (without test execution or fix iteration): Use
```
review-diff
```
Writing new tests from scratch (not fixing existing failures): Use development skills

When to stop and hand off:

Loop converges (tests pass, no blocking findings) → Present Repair Loop Report and stop
Stop condition hit (no progress, environment blocker, flaky tests, iteration limit) → Present options and wait for user direction
User asks for a one-time code review without fixing → Hand off to
```
review-code
```
or
```
review-diff
```
User asks to only run tests without fixing → Hand off to
```
run-automated-tests
```

不要执行以下操作（其他技能负责）：

仅执行测试（无审查或修复循环）：使用
```
run-automated-tests
```
测试质量评估（覆盖率、结构、边缘场景完备性）：使用
```
review-testing
```
全面代码审查（无测试-修复迭代）：使用
```
review-code
```
仅diff审查（无测试执行或修复迭代）：使用
```
review-diff
```
从零编写新测试（不是修复现有失败用例）：使用开发类技能

停止并交接的场景：

循环收敛（测试通过，无阻塞性问题）→ 展示修复循环报告并停止
触发停止条件（无进展、环境阻塞、测试抖动、达到迭代上限）→ 展示可选方案，等待用户指示
用户要求单次代码审查且不需要修复→ 交接给
```
review-code
```
或
```
review-diff
```
用户要求仅运行测试且不需要修复→ 交接给
```
run-automated-tests
```

Self-Check

自检

Core Success Criteria

核心成功标准

Process Quality Checks

流程质量检查

Minimal patch surface: Each fix touched only the files necessary to resolve the identified issue — no unrelated formatting or churn.
Flaky-test awareness: Non-deterministic failures were detected (e.g., pass-on-retry without code change) and flagged rather than "fixed" blindly.
Risky-change pause applied: Schema migrations, auth changes, or broad refactors triggered an explicit user confirmation before proceeding.
Progress tracked per iteration: Each iteration log shows a clear delta (new signal or new fix) — no hollow iterations.

补丁影响最小化：每个修复仅修改解决对应问题必需的文件，无无关格式调整或无效变更
测试抖动感知：检测到非确定性失败（例如无代码变更的情况下重试后通过）时会标记出来，而不是盲目「修复」
高风险变更暂停确认：schema迁移、权限变更或大范围重构会触发用户明确确认流程后再继续
每轮迭代进度可追踪：每轮迭代日志有明确的增量（新信号或新修复），无空迭代

Acceptance Test

验收测试

Does the final report show either (a) tests passing with no blocking review findings, or (b) an explicit stop condition with clear remaining issues and options for the user?

最终报告是否满足以下任一情况：(a) 测试全部通过，无阻塞性审查问题；(b) 触发明确的停止条件，清晰说明剩余问题和用户可选方案？

Examples

示例

Example 1: Fix failing unit tests in a Node repo

示例1：修复Node仓库中失败的单元测试

User: "Make tests pass. Keep fixing until green."

Agent:

Pre-flight: scope=
```
diff
```
, test mode=
```
fast
```
, max_iterations=5; confirm installs allowed (
```
npm ci
```
) and network allowed.
Iteration 1: run
```
npm test
```
, fix first failing test, rerun
```
npm test
```
.
Iteration 2: run
```
review-diff
```
to catch edge cases introduced by the fix; rerun
```
npm test
```
.
Stop when
```
npm test
```
passes and there are no major review findings.

用户：「让测试通过，持续修复直到状态变绿。」

Agent：

前置校验：范围=
```
diff
```
，测试模式=
```
fast
```
，最大迭代次数=5；确认允许安装依赖（
```
npm ci
```
）和网络访问
迭代1：运行
```
npm test
```
，修复第一个失败的测试，重跑
```
npm test
```
迭代2：运行
```
review-diff
```
捕获修复引入的边缘场景问题；重跑
```
npm test
```
当
```
npm test
```
全部通过且无重大审查问题时停止

Example 2 (Edge case): Integration tests require Docker and secrets

示例2（边缘场景）：集成测试需要Docker和密钥

User: "Mirror CI and fix failures."

Agent:

Pre-flight: propose test mode=
```
ci
```
, but detect CI uses
```
docker compose
```
and env secrets.
Stop condition triggered: environment blocker (Docker + secrets not approved/available).
Ask the user to choose:
- run only
```
fast
```
  unit tests locally, or
- allow Docker and provide a non-chat secret workflow, or
- run only the failing CI job steps that don't require secrets.

用户：「镜像CI流程并修复失败用例。」

Agent：

前置校验：建议测试模式=
```
ci
```
，但检测到CI使用
```
docker compose
```
和环境密钥
触发停止条件：环境阻塞（Docker+密钥未获批准/不可用）
询问用户选择：
- 仅在本地运行
```
fast
```
  模式的单元测试，或
- 允许使用Docker并提供非聊天式的密钥配置流程，或
- 仅运行不需要密钥的失败CI任务步骤

Appendix: Output contract

附录：输出约定

Each skill execution MUST produce a Repair Loop Report in this exact JSON format:

json

{
  "repair_loop_report": {
    "definition_of_done": {
      "tests": "test command passes",
      "review": "no critical/major findings"
    },
    "scope": "diff | codebase",
    "mode": "fast | ci | full",
    "max_iterations": 5,
    "iterations": [
      {
        "iteration": 1,
        "review": {
          "skill_used": "review-diff",
          "findings_count": {"critical": 0, "major": 1, "minor": 2},
          "blocking": ["unused import in utils.js"]
        },
        "tests": {
          "command": "npm test",
          "status": "failed",
          "exit_code": 1,
          "first_failure": "FAIL src/utils.test.js"
        },
        "fix": {
          "files_changed": ["src/utils.js"],
          "intent": "remove unused import"
        },
        "re_run": {
          "command": "npm test",
          "status": "passed"
        }
      }
    ],
    "final_state": {
      "tests_passing": true,
      "commands_passed": ["npm test"],
      "blocking_issues_remaining": [],
      "minor_suggestions": ["consider adding type hints"]
    },
    "stop_condition": "converged | max_iterations | environment_blocker | no_progress"
  }
}

Element	Type	Description
`definition_of_done`	object	What constitutes success
`scope`	string	`diff` or `codebase`
`mode`	string	Test mode: `fast` , `ci` , or `full`
`max_iterations`	number	Loop limit
`iterations`	array	Each iteration's review, test, fix, re-run
`final_state`	object	End state: tests passing, remaining issues
`stop_condition`	string	Why loop ended: `converged` , `max_iterations` , `environment_blocker` , `no_progress`

This schema enables Agent consumption without prose parsing.

每个技能执行必须输出严格遵循以下JSON格式的修复循环报告：

json

{
  "repair_loop_report": {
    "definition_of_done": {
      "tests": "test command passes",
      "review": "no critical/major findings"
    },
    "scope": "diff | codebase",
    "mode": "fast | ci | full",
    "max_iterations": 5,
    "iterations": [
      {
        "iteration": 1,
        "review": {
          "skill_used": "review-diff",
          "findings_count": {"critical": 0, "major": 1, "minor": 2},
          "blocking": ["unused import in utils.js"]
        },
        "tests": {
          "command": "npm test",
          "status": "failed",
          "exit_code": 1,
          "first_failure": "FAIL src/utils.test.js"
        },
        "fix": {
          "files_changed": ["src/utils.js"],
          "intent": "remove unused import"
        },
        "re_run": {
          "command": "npm test",
          "status": "passed"
        }
      }
    ],
    "final_state": {
      "tests_passing": true,
      "commands_passed": ["npm test"],
      "blocking_issues_remaining": [],
      "minor_suggestions": ["consider adding type hints"]
    },
    "stop_condition": "converged | max_iterations | environment_blocker | no_progress"
  }
}

元素	类型	描述
`definition_of_done`	object	成功的判定标准
`scope`	string	`diff` 或 `codebase`
`mode`	string	测试模式： `fast` 、 `ci` 或 `full`
`max_iterations`	number	循环迭代上限
`iterations`	array	每轮迭代的审查、测试、修复、重跑详情
`final_state`	object	结束状态：测试是否通过、剩余问题
`stop_condition`	string	循环终止原因： `converged` （收敛）、 `max_iterations` （达到迭代上限）、 `environment_blocker` （环境阻塞）、 `no_progress` （无进展）

该schema支持Agent直接消费，无需解析自然语言。