Respond to Code Review
Treat review comments as hypotheses and decisions to evaluate, not commands that automatically override current evidence.
Workflow
- Capture every comment with its author, location, revision, requested outcome, and whether it is still current.
- Restate the technical claim and inspect the relevant code, contract, test, or platform evidence.
- Classify the comment as
accept, reject, defer, clarify, or already addressed, with evidence.
- Resolve conflicting feedback by identifying the governing requirement or decision owner.
- Implement accepted in-scope changes only when the user authorized implementation.
- Add regression evidence for defect claims and rerun affected gates.
- Prepare concise responses that explain evidence, changes, and remaining uncertainty.
- Send responses or resolve threads only when that external write is authorized.
Boundaries
- Do not accept feedback merely because it sounds authoritative.
- Do not dismiss feedback without checking the actual claim.
- Do not resolve a thread as a substitute for implementing or verifying the agreed change.
- Review approval, passing checks, merge, and deployment remain separate states.
Output
Return a table with Comment, Verdict, Evidence, Action, and Response, followed by validation and unresolved decisions.
1---2name: respond-to-code-review3description: Evaluate code review feedback against current code, tests, contracts, and authority before accepting, rejecting, or deferring it. Use when review comments contain claims or requested changes that require technical verification.4license: MIT5---67# Respond to Code Review89Treat review comments as hypotheses and decisions to evaluate, not commands that automatically override current evidence.1011## Workflow12131. Capture every comment with its author, location, revision, requested outcome, and whether it is still current.142. Restate the technical claim and inspect the relevant code, contract, test, or platform evidence.153. Classify the comment as `accept`, `reject`, `defer`, `clarify`, or `already addressed`, with evidence.164. Resolve conflicting feedback by identifying the governing requirement or decision owner.175. Implement accepted in-scope changes only when the user authorized implementation.186. Add regression evidence for defect claims and rerun affected gates.197. Prepare concise responses that explain evidence, changes, and remaining uncertainty.208. Send responses or resolve threads only when that external write is authorized.2122## Boundaries2324- Do not accept feedback merely because it sounds authoritative.25- Do not dismiss feedback without checking the actual claim.26- Do not resolve a thread as a substitute for implementing or verifying the agreed change.27- Review approval, passing checks, merge, and deployment remain separate states.2829## Output3031Return a table with `Comment`, `Verdict`, `Evidence`, `Action`, and `Response`, followed by validation and unresolved decisions.
JovaniPink