| name | pr-comment |
| description | This skill should be used when reviewing someone else's pull request and you want to turn gate / gate-wf findings into posted GitHub comments — each comment drafted through humanizer and posted as a standalone inline comment at its file:line, after one confirmation. Triggers on "post these as review comments", "comment the gate findings on the PR", "draft and post my review", "leave review comments", after a gate / gate-wf run on a PR you're reviewing. |
| argument-hint | [pr-number-or-url] [tiers — e.g. 'all' | 'B,M' | specific IDs] |
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:
- The findings already in this conversation (the gate verdict you just saw), or
- 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:
- 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. For NIT findings, prefix the body with nit:.
- 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.
- 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 placement (file:line inline, or "conversation") — then post the whole batch only after a single confirmation.
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="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.
