task-reviewer-prompt: requiring file:line for every passed check makes reviewers compute line numbers from diff offsets

Author: tpischkeCreated Oct 1, 2026Updated Oct 1, 2026

Summary

skills/subagent-driven-development/task-reviewer-prompt.md contains two instructions that conflict:

  • Lines 135-137: "Your report should point at evidence: file:line references for every finding and for any check you would otherwise answer with a bare 'yes.'"
  • Earlier in the same prompt: "Read the diff file once […] do not Read a changed file separately unless a hunk you must judge is cut off mid-function", "Do not re-run git commands", "Do not crawl the broader codebase."

A reviewer that obeys both has one way to produce a source line number for a passed check: derive it from the diff's hunk offsets. That is slow, error-prone work that adds nothing to the review.

What we saw

A task review of a small mechanical diff (7 files, +26/−8: an optional parameter forwarded through two services and passed at four call sites, plus one test). Dispatched from the unmodified template, on main as of 2026-09-27.

Attempt Prompt Reviewer output
1 template as is 32,768 tokens of reasoning, no report
2 template as is, fresh reviewer 32,768 tokens of reasoning, no report
3 controller rewrote the prompt: file:line for findings only, four-line report about 4,000 tokens, approved, 2.3 minutes

Same diff, same model, same settings in all three. Attempt 3 still cited the lines that mattered (the four call sites and the generated overload), and got them with two quick greps.

In attempts 1 and 2 the reviewer had reached its conclusion early (nothing to fix) and then spent most of the turn establishing line numbers for the checks that passed. Excerpts from its reasoning:

diff 93→34, 94→35, 95→36, 96→37 […] So the changed line is app.ts:44. Hmm, wait — but actually I realize I mis-mapped earlier for account-list too. Let me redo account-list with the correct rule: within a hunk, new-side line numbers increase by 1 […]

Wait, that can't be right — line 135 in the received output was });? […] OK, from the actual tool result (I'll trust my reading of it): lines 130-137 […]

STOP. This doesn't matter at all for the review.

It never opened the files to read the numbers off, which is what the template tells it not to do.

Scope of the evidence

  • Model: GLM-5.3-Flash (local, MLX 4-bit) at maximum reasoning effort, under OpenCode 2. We see the same habit of counting from memory instead of re-reading in Qwen3.8-Flash-Next under the same template, at smaller cost.
  • The empty reports in attempts 1 and 2 are ours, not Superpowers': our harness capped the turn at 32,768 output tokens. What this issue claims is the wasted work, about 8x the tokens for the same verdict. On a model with a smaller reasoning allowance the cost would be a longer review rather than a lost one.
  • We have not measured Claude models on this.

Suggested fix

Require line references for findings only:

diff
-    Your report should point at evidence: file:line references for every
-    finding and for any check you would otherwise answer with a bare
-    "yes." A tight report that cites lines gives the controller everything
-    it needs.
+    Your report should point at evidence: file:line references for every
+    finding. A tight report that cites lines gives the controller everything
+    it needs.

Alternatively keep the requirement and allow the means: say that a reviewer may read a changed file to get a line number.

Related: #1930 (reviewer verbosity), #2054 (reviewer turns spent on mechanical facts).