Pr Comment

PR Comment

Post gate / gate-wf findings on a PR you're reviewing as standalone inline comments — one independent comment per finding, placed at its file:line. Each is drafted through humanizer and posted only after one confirmation. There is no review wrapper and no summary comment. Out-of-diff findings (can't be inline) go to the PR conversation. This skill never approves or requests changes — that stays a manual call.

Prerequisites

Findings come from a prior gate / gate-wf run, in priority order:

1. The findings already in this conversation (the gate verdict you just saw), or
2. The state file for the current branch — whichever skill ran: ~/.claude/gate-state/<repo-slug>/<branch>.json (gate) or ~/.claude/gate-wf-state/<repo-slug>/<branch>.json (gate-wf) → .findings[].

Both produce the same shape: id (B1/M1/N1), tier (BLOCKER/MAJOR/NIT), file, line, location (diff-line | adjacent), message, suggested_fix.

Also resolve the PR and its head commit:

• gh pr view <n> --json number,headRefOid,headRepositoryOwner,headRepository — owner/repo + headRefOid (the commit_id every inline comment needs).

Drafting goes through the humanizer skill — that dependency is mandatory, not optional.

The loop

tier orders the work (BLOCKER → MAJOR → NIT). For each selected finding:

1. Draft the comment — turn message + suggested_fix into a 1–3 sentence reviewer comment. Route it through the humanizer skill. Never post a raw draft — always route it through humanizer first.
2. Label the tier — prepend the tier marker to the humanized body, in this order (humanizer runs on the prose only, never on the marker, so it can't rewrite or drop it): **blocker:** / **major:** / nit: . Verify the final body still starts with the marker before batching; re-add it if humanizer's output lost it.
3. Place it — location: diff-line → standalone inline comment at file:line. location: adjacent (legacy code outside the diff) cannot be inline (GitHub only accepts comments on diff lines) → post as a top-level PR conversation comment citing file:line.
4. Collect it — add the drafted comment to the pending batch (inline or conversation) for one preview.

Show the one batch preview — every comment with its tier marker and placement (file:line inline, or "conversation") — then post the whole batch only after a single confirmation. A comment in the preview with no tier marker is a bug: fix it before posting.

Done when every selected finding has been posted as either an inline comment (diff-line) or a conversation comment (adjacent), and the summary reports the counts (inline / conversation / skipped-stale) with comment links.

Submit (after confirmation)

Post each comment independently — no review object. After the single confirmation:

diff-line → one standalone inline comment per finding:

gh api repos/{owner}/{repo}/pulls/<n>/comments \
  -f commit_id=<headRefOid> -f path=src/db/users.ts -F line=42 \
  -f body="**blocker:** User input is concatenated into raw SQL — use a parameterized query."

adjacent → one top-level PR conversation comment per finding:

gh api repos/{owner}/{repo}/issues/<n>/comments \
  -f body="\`src/legacy.ts:88\` — …"

Notes:

• GitHub only accepts inline comments on lines present in the diff; adjacent findings go to the conversation, never to pulls/<n>/comments.
• This skill never submits APPROVE or REQUEST_CHANGES — comments only.
• A finding whose file:line is not on the diff (stale location) is skipped and reported, not posted.