cvg-code-review-feedback git:20260913.5b2ea3cA

Immutable. This exact content is served forever at /api/v1/blob/d8f7db18675430ba.

---
name: cvg-code-review-feedback
description: "Handle code-review blocker findings returned to the worker session. Validate feedback, repair implementation-owned issues, or pause dependent work on plan and contract gaps."
---

# Code Review Feedback

Use this skill in the worker session after a code reviewer returns blocker
findings.

The input is the reviewer blocker findings appended to the prompt, plus the
accepted plan, behavior contract if present, implementation notes, base/head
refs, current diff, and relevant changed files.

Do not treat reviewer findings as a patch list. First decide whether each finding
is an implementation-owned issue under the accepted plan and contract. Pause only work dependent on a material unresolved behavior or scope decision.

If the task context provides no coordination channel (standalone use), the
current conversation is the channel. Ask only for a material unresolved decision;
continue independent authorized work.

## Process

### 1. Reload implementation authority

Read:

- original user outcome, non-goals and authorized changes,
- accepted plan and "done when" criteria,
- behavior contract or linked design notes, if present,
- implementation notes,
- current diff and changed files,
- exact reviewer blocker findings.

### 2. Evaluate each blocker

Recheck the original outcome, non-goals, authorized changes and current product
constraints before treating plan text as a requirement. A contract gap blocks
only when it prevents required behavior or critical verification. Use the
orchestrator's evidence-based adjudications as input, retaining the original
finding and explaining any disagreement or new evidence.

For materially added mechanisms, ask what required outcome or concrete
constraint fails if they are removed. Consider deleting the cause or reusing
existing behavior before prescribing more coordination, recovery, or guards.
A counterfactual explanation is not an executed ablation experiment. Run an
isolated removal experiment only when uncertainty could change the choice and
it is within your role; preserve the baseline and verify affected behavior.
Keep necessary privacy, integrity and failure protection even for rare schedules.
Use existing finding fields to explain the consequence and smallest effective
change; do not add a separate complexity report or demand a deletion quota.

For each finding, decide whether it is:

- **Local code bug**: accepted behavior is clear, and implementation is wrong in
  a bounded place.
- **Pattern bug**: the same implementation mistake may appear across adjacent
  surfaces covered by the accepted plan.
- **Verification gap**: implementation may be correct, but required proof from
  the accepted plan is missing.
- **Plan gap**: the reviewer exposed a missing surface, invariant, slice, matrix
  cell, or gate that the plan does not define.
- **Contract gap**: expected behavior is not defined well enough to patch safely.
- **Systemic design gap**: the architecture, ownership, state model, or protocol
  assumptions are insufficient for a worker patch.
- **Reviewer clarification needed**: the finding cannot be mapped to concrete
  evidence after re-reading the relevant context.
- **Invalid or out of scope**: the finding is stale, already fixed, contradicts
  the accepted plan, or is outside the implementation scope.

### 3. Repair only worker-owned issues

For local code bugs, pattern bugs, and implementation-owned verification gaps:

- add or update the required regression test or verification gate first,
- repair the implementation,
- for pattern bugs, audit adjacent planned surfaces and report what was checked,
- update implementation notes when the feedback reveals a deviation, assumption,
  or audited pattern the reviewer needs to know — written as standing decisions
  without review provenance (no round numbers, finding IDs, or fix-status
  claims): the next fresh reviewer must inherit the decision record, not this
  round's search map.

For plan gaps, contract gaps, and systemic design gaps:

- pause dependent work and callback through the coordination channel,
- state the missing plan or contract decision,
- do not edit plans, contracts, surface matrices, acceptance criteria, or scope,
- let the planner or orchestrator resolve source-backed technical omissions;
  ask the user for changed product semantics, broader authorization or new risk
  acceptance. Continue independent work within the existing goal.

For reviewer clarification:

- callback with the exact ambiguity and evidence checked.

For invalid or out-of-scope findings:

- keep code unchanged for that finding,
- explain why it does not apply.

## Output

Before editing, write a compact intake summary:

```text
Code review feedback intake:
1. Finding: <reviewer finding id or short quote>
   Decision: <local code bug / pattern bug / verification gap / plan gap / contract gap / systemic design gap / clarification needed / invalid or out of scope>
   Action: <repair / audit and repair / add verification / stop for planner / ask reviewer / no change>
   Evidence: <plan/code/test reference>
```

After acting, report:

- findings repaired,
- tests or verification gates added or run,
- adjacent surfaces audited for pattern bugs,
- findings rejected or needing clarification,
- plan, contract, or systemic gaps that stopped implementation.

## Rules

- Do not edit plans, behavior contracts, surface matrices, acceptance criteria, or
  scope.
- Do not patch through missing behavior decisions.
- Do not implement through a material unresolved behavior decision. Continue
  independent authorized work; ordinary implementation choices are yours.
- Do not silently drop invalid or out-of-scope findings.