Problem
claude-blocking-review.yml posts each review as a new top-level PR comment via gh pr comment (line 284). Those land in the issues/comments API, which — unlike pulls/{n}/comments (review comments) — returns no original_commit_id field.
Consequence: any downstream tool that enumerates bot feedback on a PR (e.g. post-push-status.sh → FINDING lines) cannot tell which comments belong to the current commit vs previous commits. Each push re-surfaces every prior review as if it were live feedback, including ones whose concerns were already addressed. The local post-push-loop skill explicitly warns about this case:
"Note on issues/comments staleness: Findings from the PR conversation thread (issues/comments) cannot be filtered by commit — that API provides no original_commit_id field. These findings may include bot comments from previous commits."
Concrete occurrence: during an autonomous post-push-loop iteration on smartwatermelon/dotfiles#59, the thread accumulated 4 review comments across 3 commits + 1 rebase. One of them was a VERDICT: BLOCK from an earlier commit whose underlying cause was already fixed, but the status script couldn't distinguish it from live findings and had to escalate for human judgment.
Suggested fixes (not mutually exclusive)
Option A (smallest change, recommended) — embed commit SHA as HTML-comment metadata.
In the prompt at line ~284, instruct Claude to prepend a machine-parseable line to /tmp/review.md:
<!-- claude-review commit=<SHA> run=<GITHUB_RUN_ID> -->
Downstream tools can then filter comments by matching the current HEAD SHA. The HTML comment is invisible in rendered markdown but preserved in the raw API payload.
Expose commit_sha as a workflow input (or derive from github.event.pull_request.head.sha) and inject it into the prompt.
Option B — update the previous review instead of appending.
Before posting, query existing PR comments from the bot (gh pr view --json comments), identify the prior claude-review comment (e.g. by a well-known header line), and gh api --method PATCH to edit it in place rather than creating a new one. Keeps the PR thread clean.
Tradeoff: loses per-commit history for humans scrolling the PR. Option A preserves that.
Option C — post as a formal review instead of an issue comment.
Switch from gh pr comment to gh api POST /repos/{owner}/{repo}/pulls/{n}/reviews. Formal reviews are attached to a commit SHA and appear in GET /pulls/{n}/reviews with commit_id populated. Downstream tools could use that API instead.
Tradeoff: bigger change; the review-events API has different comment formatting and UI placement.
Downstream consumer
The local tool that surfaces this: post-push-status.sh in smartwatermelon/claude-config, used by the post-push-loop skill in the ci-workflows plugin marketplace. Happy to coordinate a matching consumer change if you go with Option A (SHA filter) or Option C (API swap).
Priority
Low/medium. Human reviewers don't trip on this — the staleness only bites automation. But as more consumer repos adopt this workflow + the loop skill, the papercut multiplies.
Problem
claude-blocking-review.ymlposts each review as a new top-level PR comment viagh pr comment(line 284). Those land in theissues/commentsAPI, which — unlikepulls/{n}/comments(review comments) — returns nooriginal_commit_idfield.Consequence: any downstream tool that enumerates bot feedback on a PR (e.g.
post-push-status.sh→FINDINGlines) cannot tell which comments belong to the current commit vs previous commits. Each push re-surfaces every prior review as if it were live feedback, including ones whose concerns were already addressed. The localpost-push-loopskill explicitly warns about this case:Concrete occurrence: during an autonomous post-push-loop iteration on
smartwatermelon/dotfiles#59, the thread accumulated 4 review comments across 3 commits + 1 rebase. One of them was aVERDICT: BLOCKfrom an earlier commit whose underlying cause was already fixed, but the status script couldn't distinguish it from live findings and had to escalate for human judgment.Suggested fixes (not mutually exclusive)
Option A (smallest change, recommended) — embed commit SHA as HTML-comment metadata.
In the prompt at line ~284, instruct Claude to prepend a machine-parseable line to
/tmp/review.md:Downstream tools can then filter comments by matching the current
HEADSHA. The HTML comment is invisible in rendered markdown but preserved in the raw API payload.Expose
commit_shaas a workflow input (or derive fromgithub.event.pull_request.head.sha) and inject it into the prompt.Option B — update the previous review instead of appending.
Before posting, query existing PR comments from the bot (
gh pr view --json comments), identify the prior claude-review comment (e.g. by a well-known header line), andgh api --method PATCHto edit it in place rather than creating a new one. Keeps the PR thread clean.Tradeoff: loses per-commit history for humans scrolling the PR. Option A preserves that.
Option C — post as a formal review instead of an issue comment.
Switch from
gh pr commenttogh api POST /repos/{owner}/{repo}/pulls/{n}/reviews. Formal reviews are attached to a commit SHA and appear inGET /pulls/{n}/reviewswithcommit_idpopulated. Downstream tools could use that API instead.Tradeoff: bigger change; the review-events API has different comment formatting and UI placement.
Downstream consumer
The local tool that surfaces this:
post-push-status.shinsmartwatermelon/claude-config, used by thepost-push-loopskill in the ci-workflows plugin marketplace. Happy to coordinate a matching consumer change if you go with Option A (SHA filter) or Option C (API swap).Priority
Low/medium. Human reviewers don't trip on this — the staleness only bites automation. But as more consumer repos adopt this workflow + the loop skill, the papercut multiplies.