| name | receiving-code-review |
| description | Use when receiving or addressing code review feedback about changes you made, including pasted reviewer comments, inline PR comments, requested changes, review summaries, questions, nits, or direct user critique that may require replies or revisions. |
Receiving Code Review
Treat review as technical collaboration.
Account for every comment,
but do not assume every suggestion is correct or should be implemented.
Build The Feedback Ledger
Before editing code:
- Read the complete feedback without acting on individual comments.
- Establish the reviewed diff before deciding scope.
Identify its base and inspect the files and hunks introduced or modified by
that diff,
or record the explicit boundary supplied by the user.
- Give every comment a stable number,
including questions, nits, and repeated-looking comments.
- Correlate each comment with its code-level context.
Inspect the referenced lines, surrounding symbol, callers, tests,
relevant contracts, and history when they affect the claim.
- Determine the scope of each comment.
A comment's location is an anchor,
not necessarily the full scope of the feedback.
When a comment describes a pattern, rule, or invariant,
identify every semantically equivalent occurrence introduced or modified by
the current change.
- Record a visible ledger in chat that preserves each comment's stable ID,
feedback, code context, scope, assessment, action, and status.
Every raw comment must map to one ledger entry.
Keep comments separate even when one change may address several.
For pattern feedback,
the entry must account separately for every verified in-scope occurrence.
Choose a representation that keeps comments, occurrences,
and their statuses unambiguous.
The current change is the default scope.
An explicitly narrower or broader scope from the reviewer or user overrides the
default.
Do not modify matching occurrences in untouched pre-existing code unless the
reviewer or user explicitly expands the scope.
Do not use a textual match alone as proof that two occurrences are equivalent;
inspect their behavior and note intentional exceptions.
Ask for clarification only when the requested scope conflicts with this default
or the change boundary cannot be established.
