git:20261025.83f68e3 to git:20261026.9076015

23 added, 15 removed. Audit A to A.

---

name: code-review-loop

description: Review, remediate, and verify code through bounded rounds. Use for review-and-fix requests; use code-review for one read-only review.

---

# Code Review Loop

Own assessment, repairs, verification, and completion. Read [code-review](../code-review/SKILL.md) and the original requirements. Preserve the requested target, exclusions, authority, and unrelated work. Do not commit, push, publish comments, change branches, stash, reset, or clean the checkout without authorization.

- ## Coordinate agents

+ ## Coordinate review

- Keep handoffs minimal: requirements, repository/target, and important limits. Agents inspect Git and source themselves; do not send diffs, source dumps, snapshots, or manifests. Inside T3 Code, follow [T3 coordination](../code-review/references/t3-runtime.md) and use a fresh `delegate_task` for every review round; do not continue a review in an earlier task's child thread. Outside T3, use the harness's native controls. Apply [Subagent roles and reasoning](../execute-plan/references/subagent-reasoning.md) when delegating. Keep ownership clear, serialize overlapping edits, and join all assigned work before advancing.

+ Give reviewers the requirements, repository/target, important limits, and [code-review](../code-review/SKILL.md) instructions. They inspect Git and source themselves; do not send diffs, source dumps, snapshots, or manifests. Inside T3 Code, follow [T3 coordination](../code-review/references/t3-runtime.md) and use a fresh `delegate_task` per round. Outside T3, use native controls and a fresh reviewer when independent scrutiny is useful. Apply [Subagent roles and reasoning](../execute-plan/references/subagent-reasoning.md) when delegating. Keep ownership clear and join assigned work before advancing.

- Outside T3, use a fresh reviewer when independent scrutiny is useful. Report independence accurately. T3 rounds include concise prior findings, responses, and unresolved objections required by the host; these are claims to verify, not an expected verdict. Do not carry repair-agent history into a reviewer unnecessarily.

+ Report independence accurately. T3 rounds include concise prior findings, responses, and unresolved objections required by the host; these are claims to verify, not an expected verdict. Omit unrelated repair history. Reviewers and repair agents must reason from requirements and current evidence, rather than defer to each other's conclusions.

- ## Assess and remediate holistically

+ ## Assess findings independently

- Assess the complete review and open findings together. Verify claims against requirements, source, and reachable behavior; accept, partially accept, or decline with evidence. Track findings and checks in context. Useful findings from a partial review remain assessable; partial coverage is not a clean result.

+ Assess the complete review and open findings before editing. For each distinct claim, check the requirement or invariant, reachable trigger, impact, and attribution to the target. Accept, partially accept, or reject it with a concise evidence-based reason. Separate a valid defect from the reviewer's proposed solution. Check disputed facts directly; do not implement a suggestion merely because a reviewer repeats it or assigns high priority. Do not reject a valid defect merely because its repair is inconvenient.

- Group related findings by root cause. Trace ownership, boundaries, callers, data flow, and invariants. Plan a proportionate integrated correction and regression checks before editing. Refactor when local patches would duplicate rules, conceal inconsistent behavior, or leave the cause intact. Preserve required behavior, data, explicit compatibility, and scope. Do not add unrelated redesign or cleanup.

+ Reject unsupported claims, preferences, and scope expansion without routine user confirmation. Resolve material requirement ambiguity from existing authority; ask the user only when it remains necessary, and continue independent work. Keep a compact in-context ledger of findings, decisions, repairs, and check evidence. Partial acceptance retains the valid defect; a genuinely unresolved claim remains open. Useful findings from partial inspection remain assessable, but partial coverage cannot establish a clean result.

- Verify the original failure and surviving behavior across affected consumers. Add regression coverage when practical, perform directly related cleanup, and inspect the combined diff. Apply [Check evidence and reuse](../final-pass/references/check-evidence.md); unaffected passing checks can remain valid, but an edited result still needs fresh review.

+ ## Repair coherently

- ### Escalate persistent findings

+ Group accepted defects by root cause. Trace affected ownership, boundaries, callers, data flow, and invariants; choose a proportionate correction and checks before editing. Refactor when local patches would duplicate rules or leave the cause intact. Preserve required behavior, data, explicit compatibility, and scope. Repair agents independently verify the diagnosis and approach, and return evidence for any disagreement instead of implementing a faulty request. Do not add unrelated redesign or cleanup.

- If reviews still require repairs after two remediation stages, reassess the cumulative implementation before the next edit. Re-read affected code and earlier repairs, trace shared invariants, and revise the repair/verification plan. Different findings can expose the same structural problem. Use a bounded refactor when warranted; independent local defects do not force a rewrite. This is coordinator analysis, not another review round or a reset of the cap.

+ Verify the original failure and surviving behavior across affected consumers. Add regression coverage when practical, perform directly related cleanup, and inspect the combined diff. Apply [Check evidence and reuse](../final-pass/references/check-evidence.md); unaffected passing checks can remain valid, but an edited result still needs fresh review.

+ If accepted defects persist after two repair stages, reassess cumulative changes and shared invariants before the next edit. Revise the repair plan and use a bounded refactor when warranted. Repeated rejected suggestions do not trigger refactoring or scope expansion. This reassessment does not reset the round cap.

## Run bounded rounds

- Keep review and remediation sequential; do not edit the target during review. Let reviewers discover the current changes themselves. Use at most ten model-bearing review attempts in one invocation. Count genuine failed or cancelled attempts, but do not turn formatting cleanup into a new model call. A clean first broad review is sufficient; the cap is not a quota.

+ Keep review and remediation sequential; do not edit the target during review. Use at most ten completed review rounds per invocation. Failed attempts do not consume a round; retry the same numbered round under the recovery policy below. Parallel inspections form one coordinated round. Stop after a complete broad review has no remaining supported defects and required checks pass; the cap is not a quota.

- Rounds 1-3 cover the complete current target and all lenses. If needed, rounds 4-9 emphasize repairs, open findings, affected invariants and consumers, and immediate regressions while allowing other concrete issues. After focused convergence, use the next available round for a broad closing review. Round 10 is the final broad read-only audit. Do not skip available follow-up review after edits, restart a loop to evade its cap, or require unused rounds after a broad clean result.

+ Rounds 1-3, when needed, cover the complete current target with all relevant review lenses. Rounds 4-9 may focus on repairs, open defects, affected invariants and consumers, and regressions. After focused convergence, use the next available round for a broad closing review; round 10 is always broad and read-only. After edits, obtain fresh review while rounds remain. Do not restart the loop to evade the cap.

+ Evidence-based rejection does not require reviewer agreement or another call solely to obtain a `No findings` verdict. A complete broad review can close after all its claims are resolved without edits. Preserve the reviewer's reported findings and explain the caller's disposition; do not describe a disputed review as the reviewer reporting no findings. A real unresolved objection prevents clean closure.

Choose a reasonable per-round budget from scope and complexity. Wait on the same active work; do not infer a hang from silence or create duplicate calls. Keep task handles and confirm owned work has stopped before replacing a failed call.

### Recover failed attempts

- Assess the review content, not its formatting. Prose, Markdown, wrappers, missing IDs, or absent schema bookkeeping are not review failures. Normalize useful content in caller context and verify substantive claims. Do not discard a useful partial review or invent missing inspection to call it clean.

+ Assess content, not formatting. Normalize prose, Markdown, or missing bookkeeping in caller context without another model call. Retain useful partial findings without inventing missing inspection.

- For a genuine launch, authentication, transport, cancellation, or unavailable-workspace problem, record the cause and any useful partial findings separately. Diagnose and correct what is supported by evidence, then use the next fresh attempt when needed. Do not repeatedly relaunch unchanged failures or silently switch providers. Report concrete limits when required input, access, or external state is unavailable.

+ For a model-capacity, rate-limit, API, launch, transport, timeout, authentication, or workspace failure, record the cause and retain useful partial findings. Retry the same round against the unchanged target, preserving its scope, provider, model/options, and broad or focused purpose. Advance the round only after required inspection completes and its findings are assessed. A failed broad closing review remains a broad closing review on retry.

+ Use up to three attempts per round unless the user specifies otherwise. For transient failures, honor retry-after guidance or use increasing delays within the chosen budget. For configuration or access failures, correct the cause before retrying; stop as incomplete if required input or access is unavailable. A user-directed cancellation stops work. Do not duplicate active calls or silently switch providers. If retries or the round budget are exhausted, report the failed round and blocker without advancing it or claiming the review-round cap was reached.

+ Track round and attempt separately. In T3, retry an uncertain launch with its existing `clientRequestId`; inspect the retained task before assuming failure. Once the task is confirmed failed or stopped, use a fresh `delegate_task` and launch key for its replacement attempt in the same round. Outside T3, use a fresh reviewer/session after a confirmed failure.

## Finish

- A loop is clean when a complete broad review covers the final unchanged target, no accepted findings or task-relevant residuals remain, and required checks pass. During an active loop, verified repairs await the next fresh review before closure.

+ A loop is clean when a complete broad review covers the final unchanged target, every finding has an evidence-backed disposition, no supported defect or material objection remains unresolved, and required checks pass. Verified repairs await fresh review before closure.

After the cap or a real continuation blocker, hand residual findings and missing coverage to [final-pass](../final-pass/SKILL.md) for authorized direct repair and verification. Preserve the loop's actual incomplete/capped status and identify repairs verified without fresh review. A cap ends that review invocation, not authorized implementation work. Do not label direct inspection as a clean external review.

- During plan execution, follow [Completion and review checkpoints](../execute-plan/SKILL.md#completion-and-review-checkpoints). Return findings, fixes, reached rounds, checks, and material limits in plain language. Keep requested deliverables and unrelated files; remove only task-owned scratch after use and verify cleanup. Save reports or transcripts only when requested.

+ During plan execution, follow [Completion and review checkpoints](../execute-plan/SKILL.md#completion-and-review-checkpoints). Report material findings, fixes, rejected claims and reasons, reached rounds, checks, and limits concisely. Remove only task-owned scratch and verify cleanup. Save reports or transcripts only when requested.