git:20260623.3c918da to git:20260702.0958934

---

name: cvg-code-review-feedback

description: "Handle cvg-code-review blocker findings in the worker session. Validate feedback, repair implementation-owned issues, or stop for 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. Workers

must stop for plan gaps, contract gaps, and systemic design gaps.

## Process

### 1. Reload implementation authority

Read:

- 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

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.

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

- stop and callback through the coordination channel,

- state the missing plan or contract decision,

- do not edit plans, contracts, surface matrices, acceptance criteria, or scope,

- do not continue implementation until the planner or coordination channel

resolves the gap.

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 continue implementation after identifying a plan, contract, or systemic

design gap.

- Do not silently drop invalid or out-of-scope findings.