/cvg-plan-review-feedback

name: cvg-plan-review-feedback
description: "Handle plan-review blocker findings returned to the planner session. Validate feedback, revise plan-owned artifacts, or pause dependent work on missing decisions."

Plan Review Feedback

Use this skill in the planner session after a plan reviewer returns blocker findings.

The input is the reviewer blocker findings appended to the prompt, plus the original planning goal, source prompt, current plan, behavior contract if present, and relevant codebase evidence.

Do not treat reviewer findings as an edit list. First decide whether each finding is valid under the accepted goal and current code reality, then revise only plan-owned artifacts.

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 planning authority

Read:

• original user goal, issue, acceptance criteria, and non-goals,
• current plan document,
• behavior contract or linked design notes, if present,
• relevant codebase evidence for each reviewer finding,
• 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:

• **Valid plan gap**: the plan misses a required surface, lifecycle, invariant,

matrix cell, ownership boundary, or verification gate.

• **Source-backed contract gap**: the source authority defines the behavior, but

the plan or contract failed to capture it.

• **Decision-required contract gap**: neither the plan nor source authority

defines the behavior clearly enough to proceed.

• **Reviewer clarification needed**: the finding cannot be mapped to concrete

plan or code evidence after re-reading the relevant context.

• **Invalid or out of scope**: the finding is stale, already covered, contradicts

the accepted goal, or asks for work outside the agreed scope.

3. Revise only planner-owned artifacts

For valid plan gaps and source-backed contract gaps:

• update the plan, contract, surfaces, invariant matrix, slices, or verification

gates as needed,

• keep the revision scoped to the accepted goal,
• preserve reviewer finding ids or exact wording so re-review can check them.

For decision-required contract gaps:

• pause dependent work and callback through the coordination channel,
• state the missing material decision and its affected plan section; resolve

source-backed details without repeating user approval,

• do not invent behavior.

For reviewer clarification:

• callback with the exact ambiguity and evidence checked.

For invalid or out-of-scope findings:

• keep the plan unchanged for that finding,
• explain why it does not apply.

Output

Before editing, write a compact intake summary:

Plan review feedback intake:
1. Finding: <reviewer finding id or short quote>
   Decision: <valid plan gap / source-backed contract gap / decision-required contract gap / clarification needed / invalid or out of scope>
   Action: <plan edit / contract edit / stop for decision / ask reviewer / no change>
   Evidence: <plan/code reference>

After acting, report:

• findings addressed,
• plan or contract sections changed,
• findings rejected or needing clarification,
• decisions still blocking the planner,
• verification gates added or changed.

Rules

• Do not edit implementation code.
• Do not hide implementation bugs by reducing plan scope.
• Do not invent behavior for contract gaps.
• Do not silently drop invalid or out-of-scope findings.