pr-review-comments
installsforks
How to install pr-review-comments?
giuseppe-trisciuoglio/developer-kit/pr-review-comments
$npx -y skills add giuseppe-trisciuoglio/developer-kit --skill pr-review-commentsPosts review findings from a JSON file as inline comments on a GitHub Pull Request, attaching each comment to its file and line. Use when you have a list/JSON of review findings (each with a file path, line number, and a message such as summary/failure_scenario) and want them pub
SKILL.md
| 1 | # PR Review Comments |
| 2 | |
| 3 | Publish a JSON array of review findings as inline comments on a GitHub Pull Request, |
| 4 | each anchored to its file and line. Uses the GitHub API through the authenticated |
| 5 | `gh` CLI, so no token handling is needed. |
| 6 | |
| 7 | ## Prerequisites |
| 8 | |
| 9 | - `gh` CLI installed and authenticated (`gh auth status`). The script auto-detects the |
| 10 | repo with `gh repo view`; pass `--repo OWNER/REPO` to override. |
| 11 | - The PR number to comment on. |
| 12 | - A JSON file: an **array** of objects. Required keys per object: `file`, `line`. |
| 13 | Message comes from `summary` and/or `failure_scenario` (combined into the body), or an |
| 14 | explicit `body`. See [references/json-schema.md](references/json-schema.md) for the full |
| 15 | schema and a sample. |
| 16 | |
| 17 | ## Key constraint: only diff lines are commentable |
| 18 | |
| 19 | GitHub only accepts an inline comment if the target line is part of the PR's diff. |
| 20 | `line` is the line number in the **new** file (use `side: "LEFT"` for removed lines). |
| 21 | The script fetches the PR diff, validates every finding against the actual hunks, and |
| 22 | **skips** any whose line is outside the diff — reporting them at the end so nothing is |
| 23 | lost silently. There is no way to attach a line comment to an unchanged, undiffed line. |
| 24 | |
| 25 | ## Workflow |
| 26 | |
| 27 | 1. Confirm the JSON path and the PR number. If the repo isn't obvious, run `gh repo view`. |
| 28 | 2. **Dry-run first** to see what will be posted and what gets skipped: |
| 29 | ```bash |
| 30 | scripts/post_pr_comments.py --pr <N> --json <path> --dry-run |
| 31 | ``` |
| 32 | 3. Review the "Postable" / "Skipped" counts with the user. If lines were skipped because |
| 33 | the diff moved, the line numbers in the JSON may be stale — reconcile before posting. |
| 34 | 4. Post for real, choosing the mode (see below): |
| 35 | ```bash |
| 36 | # Grouped (default): one PR review bundling all comments |
| 37 | scripts/post_pr_comments.py --pr <N> --json <path> --event COMMENT |
| 38 | |
| 39 | # Individual: one separate inline comment per finding |
| 40 | scripts/post_pr_comments.py --pr <N> --json <path> --mode individual |
| 41 | ``` |
| 42 | 5. Report back the created review/comment URLs and the list of any skipped findings. |
| 43 | |
| 44 | ## Choosing the mode |
| 45 | |
| 46 | | Mode | Endpoint | Use when | |
| 47 | |------|----------|----------| |
| 48 | | `grouped` (default) | `POST /pulls/{n}/reviews` | Publishing a set of findings as one review. One notification; can set `--event APPROVE \| REQUEST_CHANGES \| COMMENT`. | |
| 49 | | `individual` | `POST /pulls/{n}/comments` | Adding standalone comments incrementally, or when each finding should be its own thread/notification. | |
| 50 | |
| 51 | Default to `grouped` with `--event COMMENT` unless the user wants a verdict or separate threads. |
| 52 | |
| 53 | ## Options reference |
| 54 | |
| 55 | ``` |
| 56 | --pr N PR number (required) |
| 57 | --json PATH JSON array of findings (required) |
| 58 | --repo OWNER/REPO Override auto-detected repo |
| 59 | --mode grouped|individual Default: grouped |
| 60 | --event COMMENT|APPROVE|REQUEST_CHANGES Grouped-mode verdict (default COMMENT) |
| 61 | --review-body TEXT Top-level summary body for the grouped review |
| 62 | --commit SHA Commit to anchor to (default: PR head SHA) |
| 63 | --dry-run Validate and print payloads without posting |
| 64 | ``` |
| 65 | |
| 66 | ## Notes |
| 67 | |
| 68 | - Multi-line range comments: include `start_line` (and optional `start_side`) in the JSON |
| 69 | object alongside `line`; the script passes them through. |
| 70 | - Always `--dry-run` before a real post on an unfamiliar PR — stale line numbers are the |
| 71 | most common failure and the dry-run surfaces them as "skipped" without side effects. |
| 72 | - The script is the reliable path; don't hand-roll `gh api` calls for this — it handles |
| 73 | diff validation, repo/commit detection, and body assembly consistently. |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
