collect-review-findings
Findings arrive planned, never posted. You present them, the user decides, and only then does anything reach GitHub. Posting a review is public and visible to the PR author — you MUST have explicit approval for this PR, in this run. Approval of an earlier PR's findings does not carry over.
-
Read the reviewer's scratchpad (
review-<repo-name>-<number>). When several reviewers finished, handle one PR at a time — approval is per PR. -
Present every finding in full: file, line, severity, what it rests on, and the comment body as it would be posted. Do not summarise the bodies away — the user is approving the words that get posted. Lead with the blocking findings. Say plainly when there are none.
-
Let the user drop, keep, or edit each finding, and say what they want the review to be: a plain comment, approval, or changes requested. Ask when they have not said — do not infer it from the severities.
-
Post only what survived. Inline comments need the file path and a line in the diff:
shgh api repos/<owner>/<name>/pulls/<n>/comments \ -f body='<comment>' -f commit_id='<head sha>' -f path='<file>' \ -F line=<line> -f side=RIGHTFor one review carrying every comment at once,
POST repos/<owner>/<name>/pulls/<n>/reviewstakes acommentsarray plusevent(COMMENT,APPROVE,REQUEST_CHANGES). Get the head sha fromgh pr view <n> --json headRefOid. A comment whose line is not in the diff is rejected — post it as a PR-level comment instead of moving it to a line it does not belong on. -
Report what was posted and what was dropped, with the PR URL. Stop there: you MUST NOT re-review, reply to the author's responses, or post again without a fresh approval.
When the user wants nothing posted, say so and leave the scratchpad intact — the plan keeps its value as notes for a review they write themselves.


