Summary
The claude-code-review reviewer is ending PR-posted review comments with a
terminal-recap marker:
Stopping Point: Clean stopping point reached — review complete, findings and an authoritative not-fully-clean determination reported; no further action pending in this turn.
That convention exists for a human reading a session recap in a terminal.
A review comment is not that: it is an artifact posted to a thread and read
later by people and agents who never saw the session.
Measured, 2026-08-27
Three of today's review comments carry it:
Derived with:
for n in 670 672 676 677 680 683 693; do
gh api repos/Morrison-Lab/gha/issues/$n/comments --paginate \
| jq -r '[.[]|select(.body|test("\\*\\*Claude finished"))|select(.body|test("Stopping Point"))]|length'
done
Why it is worth fixing rather than tolerating
Noise is the mild case. The real risk is that this convention is written
last by construction, and a harness that posts an agent's final message
takes that line instead of the review.
That is not hypothetical --- it is
d-morrison/rme#1081, where
installing the shared corpus as a plugin made every prose reply collapse to a
one-line stopping-point declaration: the pre-plugin reply was 1182 characters
and substantive, the three post-plugin replies were 233, 356 and 501
characters and each began with the marker. One run diagnosed the bug itself
and had its diagnosis swallowed by the bug.
claude-code-review.yml currently posts the review from a packed artifact
rather than from the last assistant message, so the swallowing failure is not
live here today. The marker is still wrong in the artifact, and the upstream
guidance already says so: the corpus's own
shared/workflow/flag-session-boundaries.md carves out exactly this case ---
"when the final message is not being read by a person ... put the declaration
inside the substantive reply rather than after it, or omit the declaration."
Suggested fix
Add a line to the reviewer's --append-system-prompt in
.github/actions/run-claude-review-attempt/action.yml instructing it not to
emit a stopping-point declaration, since its output is a posted artifact
rather than a terminal recap.
Two related observations from the same sweep, worth noting here rather than
filing separately unless they recur:
Filed by Claude Code (AI agent) --- not written by a human.
Summary
The
claude-code-reviewreviewer is ending PR-posted review comments with aterminal-recap marker:
That convention exists for a human reading a session recap in a terminal.
A review comment is not that: it is an artifact posted to a thread and read
later by people and agents who never saw the session.
Measured, 2026-08-27
Three of today's review comments carry it:
Derived with:
Why it is worth fixing rather than tolerating
Noise is the mild case. The real risk is that this convention is written
last by construction, and a harness that posts an agent's final message
takes that line instead of the review.
That is not hypothetical --- it is
d-morrison/rme#1081, whereinstalling the shared corpus as a plugin made every prose reply collapse to a
one-line stopping-point declaration: the pre-plugin reply was 1182 characters
and substantive, the three post-plugin replies were 233, 356 and 501
characters and each began with the marker. One run diagnosed the bug itself
and had its diagnosis swallowed by the bug.
claude-code-review.ymlcurrently posts the review from a packed artifactrather than from the last assistant message, so the swallowing failure is not
live here today. The marker is still wrong in the artifact, and the upstream
guidance already says so: the corpus's own
shared/workflow/flag-session-boundaries.mdcarves out exactly this case ---"when the final message is not being read by a person ... put the declaration
inside the substantive reply rather than after it, or omit the declaration."
Suggested fix
Add a line to the reviewer's
--append-system-promptin.github/actions/run-claude-review-attempt/action.ymlinstructing it not toemit a stopping-point declaration, since its output is a posted artifact
rather than a terminal recap.
Two related observations from the same sweep, worth noting here rather than
filing separately unless they recur:
the Verdict --- the findings section did not make it into the comment.
which is good behaviour, but it leaves two verdicts in one body and
check-pr-fully-clean.pyparses the phrases rather than the structure.Filed by Claude Code (AI agent) --- not written by a human.