CodePanel

Nit

A nit, short for nitpick, is a minor review comment the author is free to ignore, such as a variable name, a comment's wording or a long line.

Updated Also: nitpick

Reviewers write nit: in front of it to say it won't hold up the approval, and "LGTM with nits" approves the change while leaving the nits to the author. Between agents the prefix stops working. CodePanel's reviewers are told to report every issue, low-severity ones included, so nits arrive on most diffs, and a coding agent that treats every comment as a task fixes a nit as eagerly as a bug. So the difference has to be in the data, not the wording.

How CodePanel grades a nit

There is no nit severity. A finding is critical, warning or suggestion, and a nit is a suggestion: an optional improvement.

  • Reviewers are told to skip them, and to report everything. Every built-in reviewer role ends "Skip style nits other reviewers will cover.", but the task under it asks for every issue, low-severity ones included, and its scale files style under suggestion. So nits get through. On CodePanel's own PR 43, on 13 October 2026, two reviewers reported "The edited doc comment line is far longer than the surrounding wrapped lines" as a suggestion, and the agent fixed it.
  • A nit never blocks at the default gate. The default gate level is warning, so unless a repository changes it, the CodePanel status passes and the verdict reads ready with suggestions open. Only at gate level all does a suggestion block. The levels are in merge gate.
  • The benchmark doesn't count one as a false alarm. On a clean pull request, only a warning or worse counts against the model on the benchmark, because a suggestion doesn't claim anything is broken.

A nit is still an open finding. With only suggestions open and nothing blocking, get_review returns a nextAction of rate, whose reason says to rate each with rate_finding and not to push a commit for suggestions alone, since every push starts another review round. Ratings measure which models and prompts raise findings worth raising, and a rating with a reason becomes a verdict that later reviews of the same file weigh.

How an agent should answer a nit

Pick the answer that is true, not the one that makes the finding go away fastest.

The nit is Do Answer
Real and cheap Fix it in the next push /feedback F1 up fixed --agent claude-code
Real, but belongs elsewhere Track it, leave the code /feedback F2 up deferred <where it is tracked> --agent claude-code
Not worth doing Say why, with evidence /feedback F3 down nit <reason> --agent claude-code
  • deferred is for nits that really are tracked. It answers the finding at once and is never disputed, so it is not a polite way to say no. On PR 75, on 14 October 2026, an agent deferred a suggestion about a round-limit condition written in three places with "tracked as a proposed follow-up task", naming the task.
  • nit is shorthand for not-worth-fixing, and from an agent it is a dispute. The orchestrator reads the reason against the code within about three minutes of the first dispute on the pull request, and withdraws, revises or upholds the finding. Deciding it is a review call that counts toward the per-PR and monthly limits. Cite the code: on the same pull request, a not-worth-fixing dispute of one suggestion pointed at the CHANGELOG lines that already documented the behaviour, and the orchestrator withdrew it; a false-positive dispute of another rested on code the orchestrator couldn't see, and it was upheld.
  • At gate level all, the choice matters for the merge. fixed and deferred answer a nit straight away; a dispute answers it only once withdrawn or revised, and an upheld one blocks until it is fixed or deferred.

Every reason and its effect is in verdict reasons, and the full /feedback syntax is in commands.