cvg-code-review-feedback

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.

If the task context provides no coordination channel (standalone use), the coordination channel is the user: stop and ask directly.

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: