Give and receive code review with LingCode

When a PR comes back with review comments, the naïve workflow is "the reviewer is senior, apply the change." This breaks in two predictable ways:

• Confident wrong feedback gets shipped. Reviewers misread context, miss a nearby helper, or apply a pattern that doesn't fit. Implemented blindly, the suggestion regresses behavior or adds dead code.
• Correct feedback gets argued away. The first instinct on "this is wrong" is to defend the design choice rather than re-read the code with fresh eyes. Real bugs survive.

The skill in this tutorial gives LingCode an explicit protocol: read the comment, verify the claim against the code, classify it (agree / disagree / unclear), and only then act. The output is either a precise fix or a precise reply explaining why the suggestion doesn't apply.

• LingCode — download the installer.
• A PR with review comments. Works for GitHub, GitLab, and any reviewer-pasted-into-chat workflow. gh pr view --comments is the easiest pull path.
• The branch checked out locally so LingCode can read the code the reviewer was looking at — not just the diff.

Open the chat panel on the branch and ask LingCode to fetch the review thread, not just summarize the diff:

Fetch review comments on this PR (use `gh pr view --comments` or
`gh api`). For each comment, capture: file, line, reviewer's claim,
and any suggested code. Don't act on anything yet — list them.

You want the raw thread, line-anchored. A summary by a different model that's already collapsed five comments into "address feedback" is the version that ships bad fixes.

This is the step the skill exists to enforce. Ask LingCode to read the cited file, then verify whether the reviewer's claim holds:

For each comment, open the referenced file and verify the claim:
- Quote the actual code at that line.
- State whether the reviewer's description of it is accurate.
- Note any context they may have missed (helpers, callers, tests).
- Only then classify: AGREE, DISAGREE, or UNCLEAR.

Do not classify a comment AGREE without first reading the code.
"Looks reasonable" is not verification.

"Verify before classify" is the rule that kills the blind-agreement failure mode. If LingCode can't quote the code the reviewer is talking about, it doesn't get to agree with them.

The defensive failure mode is treating every reviewer comment as a thing to satisfy. The productive one is treating "I disagree, here's why" as a normal response. Ask LingCode to write the rebuttal as carefully as the fix:

For every DISAGREE classification, write a short reply (3-6 lines)
that:
1. Restates the reviewer's concern in your own words so they know
   you read it.
2. Quotes the code that actually addresses the concern, OR
   explains the constraint they may have missed.
3. Proposes a path forward — "leave as-is," "rename for clarity,"
   "add a comment explaining the constraint."

Don't be defensive. Don't be apologetic. Just be precise.

The goal is a reply the reviewer can either accept or push back on with one more round. Vague "thanks, will look into it" responses are the worst outcome — they leave the thread open and the disagreement unresolved.

Some review comments are simply incorrect — wrong about the language, the framework, or the constraint. The skill teaches LingCode to say so plainly, with evidence:

If a reviewer claim is technically incorrect (wrong about an API,
a language behavior, a framework lifecycle, etc.), reply with:
- The specific incorrect claim.
- The actual behavior, with a link to docs or a small repro
  snippet.
- Why this matters for the PR — does it change the suggested fix?

Be willing to write "this is not how X works" with evidence. That
is not rude. Implementing wrong feedback to be polite is rude to
the next maintainer.

Once verification and classification are done, the AGREE pile is mechanical. Have LingCode apply them in a single pass, then re-run tests:

For every AGREE classification:
1. Apply the suggested change (or a close variant if the suggestion
   has a small flaw you noticed during verification).
2. Run the affected tests.
3. If anything fails, stop and surface the failure — don't paper
   over it with a follow-up tweak.

Then write one commit per logical group of related changes —
not one commit per comment.

One-commit-per-comment looks tidy on the PR but makes the diff hard to review. Group by intent: "address naming feedback," "tighten error handling around X," "add the missing test for Y."

The UNCLEAR pile is where most accidental scope creep happens — LingCode guesses what the reviewer meant, implements something, and triggers a fresh round of comments. The protocol is to ask:

For every UNCLEAR classification, write a reply that:
- Quotes the comment.
- States the two or three interpretations you considered.
- Asks the reviewer which one they meant.

Do not guess and implement. A clarifying question is cheap;
re-reviewing a wrong implementation is not.

This is also the right place to push back on out-of-scope feedback — "good idea, let's track it as a follow-up issue rather than expanding this PR." The reviewer will usually agree; if they don't, you've surfaced a real disagreement worth resolving before more code lands.

Before posting the PR for human review at all, run LingCode's /review against your own branch and feed the output through this same protocol. You catch the "agree, fix it" feedback yourself before a human spends time on it, and you arrive at the human review with only the genuinely contentious comments left.

This compounds. Self-review with the receiving-review skill on top of /review means human reviewers get cleaner PRs, which means faster merges, which means smaller PRs next time.

The full protocol is packaged as a skill — drop it into your LingCode skills folder and ask LingCode to "process this PR's review comments" to invoke it:

---
name: receiving-code-review
description: Use when receiving code review feedback, before implementing suggestions — especially if feedback seems unclear or technically questionable. Triggers: 'fix the review comments', 'address feedback', 'apply review', 'reviewer said X', PR comments fetched, code review thread, 'agree with the review and apply'. Actions: verify each claim against the actual code (quote the line), classify AGREE/DISAGREE/UNCLEAR, push back when wrong (write rebuttal with evidence), implement when right, ask reviewer when ambiguous. Anti-patterns: blind agreement, reflexive defense, summarizing reviews into 'address feedback' before reading line-by-line.
---

Process incoming code review feedback with technical rigor. The
two failure modes are blind agreement (implement bad suggestions)
and reflexive defense (ignore good ones). Avoid both.

For each review comment:

1. Fetch the raw thread (gh pr view --comments or equivalent).
   Preserve file + line anchors. Do not summarize away detail.

2. Verify the claim. Open the cited file. Quote the actual code.
   State whether the reviewer's description is accurate. Note
   missed context (helpers, callers, tests).

3. Classify only after verification: AGREE, DISAGREE, UNCLEAR.
   "Looks reasonable" is not verification.

4. For AGREE: apply the change, run tests, group commits by
   intent (not one per comment).

5. For DISAGREE: write a short reply that restates the concern,
   quotes the code that addresses it (or names the missed
   constraint), and proposes a path forward. Not defensive,
   not apologetic — precise.

6. For technically-incorrect feedback: say so with evidence
   (docs link or minimal repro). Politely implementing wrong
   feedback is rude to the next maintainer.

7. For UNCLEAR: ask the reviewer which interpretation they
   meant. Do not guess and implement.

Compose with /review on your own draft before posting for
human review.

Save as ~/.lingcode/skills/receiving-code-review/SKILL.md — see Install a skill for the exact location and how skills get discovered.

Get LingCode →