automate-repair

Skill: Run the fix loop (review + test + fix)

Purpose

By running multiple iteration loops converge the codebase or change set to "clean":

Review(detect issues early and prevent regressions),
Test(obtain executable signals),
Fix(apply the minimal correct patch),
Repeat untilno blocking issues remainor astop condition。

Core Objective

Primary objective: Use a bounded, evidence-driven review-test-fix loop to converge the repository to a "clean" state—all tests pass and there are no "critical"/"major" review findings.

Success criteria(all requirements must be met):

✅ Completed parsed definition: Confirm the preflight selections (scope, test mode, maximum iterations, allowed actions) before the loop begins
✅ Evidence first in each iteration: Each iteration produces at least one of the following: a new test result, a new review signal, or a concrete code change
✅ Rerun tests after fixes: A failed test command (or target subset) is always rerun in the same iteration after applying the fix
✅ Bounded loop: The loop terminates due to convergence or an explicit stop condition - no infinite retries
✅ Structured final report: The output includes a fix loop report (Appendix: Output Contract), containing commands run, failures, patches, and remaining risks

AcceptanceTest: Does the final report show (a) tests pass and there are no blocking review findings, or (b) an explicit stop condition, with clear remaining issues and options provided to the user?

Scope Boundaries

This skill is responsible for：

Multiple iteration review → test → fix loop
Using "review-diff" and "review-code" for diff-scope and codebase-scope reviews
Executing tests via "run-automated-tests" (quick/ci/full modes)
Minimal targeted patches that preserve API contracts
Stop condition detection (no progress, environmental blockers, flaky tests, iteration limit)
Structured fix loop report output

This skill is not responsible for：

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

Handoff point: When the loop converges or reaches a stop condition, present the fix loop report to the user. For risky changes (architecture migrations, authentication changes, broad refactors), pause and request explicit approval before applying.

Usage Scenarios (Use Cases)

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

Behavior (behavior)

1. Preflight (must be resolved once)

If CLAUDE.md or .ai-cortex/config.yamlexists, prioritize reading the test_command etc. within it; otherwise obtain it according to the discovery logic. See docs/guides/project-config.md。

Confirm or default the following:

Target: repository path (default ".") and scope:
- diff(default): focus on the current changes, prioritizingreview-diff。
- codebase: review the specified path set, prioritizing viareview-codeprioritizingreview-codebase/language skill.
Definition of done：
- Tests: the selected test plan passes (fast/ci/full).
- Review: no retained "critical"/"major" review findings.
- If only "minor"/"suggestion" findings remain, list them and ask whether to resolve them.
Loop boundaries：
- max_iterations default:5。
- time_budget default: "best effort"; if the user provides a time limit, strictly comply.
Allowed actions(ask when unclear; default to the safer choice):
- Modify repository 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 refactoring:No, without confirmation.

2. Iteration loop

For "i = 1..max_iterations":

Collect current signals (evidence first)
- If scope = diff: run/execute review-diff pass on the current diff/untracked additions.
- If scope = "codebase" or the user wants a deeper review: run "review code" (or the relevant atomic review skill).
- If test failures occurred in the previous iteration, prioritize resolving those failures first.
Run tests
- Use "run-automated-tests" to discover and run the best-matching test command in the selected mode:
  - fast(default): unit tests only, minimal setup.
  - ci: mirror the CI steps as closely as possible.
  - full: include integration/e2e (only with explicit confirmation for dependencies/services).
- Capture:
  - first failing command + exit code
  - the most relevant error excerpt (do not dump large logs unless requested)
Synthesize a fix plan (minimal correct patch)
- Choose the first to resolveonemain issue:
  - The first failing test/command usually wins (highest signal).
  - If the review finds "critical" security/correctness issues, fix that issue before or alongside testing.
- Prefer fixing:
  - Make the smallest surface-area change
  - Preserve the API/contract unless explicitly approved
  - Add or adjust tests when fixing bugs (if feasible)
Apply the fix
- Implement the patch.
- Avoid unrelated formatting or churn.
- If the fix requires risky changes (architecture migration, authentication changes, broad refactoring), pause and ask.
Re-run minimal verification
- If the framework supports it, re-run the most relevant subset of failing tests; 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 proceed to the next loop iteration.
Stop early when converged
- If tests pass and there are no "critical"/"major" review findings, stop.

3. Stop conditions (must not loop forever)

If any of the following occurs, stop and ask the user for direction:

No progress: the same failure repeated for 2 iterations with no new information.
Environment blocker: missing toolchain, missing secrets, or unavailable dependencies (DB/Docker) and the user has not yet approved the required setup.
Flaky test: suspected nondeterministic failure (e.g., 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 install/network/Docker
Narrow the scope (fix only the first failing test)
Increase the iteration limit

Report persistence

By default, do not write a standalone report file. If the user explicitly asks to keep it, write to the path resolved from the project specification, or default to "docs/calibration/repair-loop.md" and overwrite the specification file, unless a snapshot is explicitly requested.

Input & Output

Input

Target path (default.）
Scope: "diff" (default) or "codebase" (+ path)
Test mode:fast(default),ci、full
Constraints: allow install/network/Docker/services (yes/no)
max_iterations(default5）
Optional: time budget

Output

Repair loop report：
- Definition of done used
- Evidence sources (which files/CI configuration informed the test plan)
- For each iteration:
  - Test commands run and results
  - First failure excerpt (if any)
  - Changes made (files touched + intent)
  - Remaining failures/findings
- Final status:
  - Tests pass (which command)
  - Remaining review items (if any) and whether they are blocked

Limits

Hard Boundaries

Do not install dependencies, use the network, start Docker/services, or run destructive commands without explicit confirmation.
Do not ask the user to paste secrets into the chat. Prefer local environment files or a documented development workflow.
Do not "fix" by disabling tests, weakening assertions, or removing coverage unless the user explicitly approves and the trade-off is documented.
Avoid large refactors by default; prefer the smallest patch that unlocks correctness.
Keep the change scoped to the target repository; do not modify unrelated sibling repositories.

Skill Boundaries (avoid overlap)

Do not do these (other skills can handle them)：

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

When to stop and hand off：

Loop convergence (tests pass, no blocking findings) → report the current fix loop and stop
Encounter a stop condition (no progress, environment blocker, flaky test, iteration limit) → show options and wait for user instruction
User requests a one-time code review without fixes → hand off to "review-code" or "review-diff"
User asks to only run tests without fixing → hand off to "run-automated-tests"

Self-Check

Core success criteria

Completed definition of resolution: Confirm pre-flight selections (scope, test mode, maximum iterations, allowed actions) before the loop starts
Evidence first in every iteration: Each iteration produces at least one of the following: new test results, a new review signal, or a concrete code change
Re-run tests after fixes: After a fix is applied in the same iteration, the failing test command (or target subset) is always re-run
Bounded loop: The loop terminates due to convergence or an explicit stop condition - no infinite retries
Structured final report: Output includes a fix loop report (Appendix: Output Contract) containing commands run, failures, patches, and remaining risks

Process quality check

Minimal patch surface: Each fix touches only the files needed to resolve the identified problem - no unrelated formatting or churn.
Flaky test awareness: Non-deterministic failures (e.g., passing on retry without code changes) are detected and flagged instead of blindly "fixed".
Risk-laden changes paused: Architecture migrations, authentication changes, or broad refactors trigger explicit user confirmation before proceeding.
Progress tracked per iteration: Each iteration log shows a clear increment (new signal or new fix) - no empty iterations.

Acceptance tests

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?

Examples (Illustrative)

Example 1: Fixing a failing unit test in a Node repository

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

Agent:

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

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

User: "Mirror CI and fix the failures."