pr-review-comments
giuseppe-trisciuoglio/developer-kit
Post review findings as inline comments on GitHub PRs, anchored to file and line.
What is pr-review-comments?
Publishes a JSON array of review findings as inline comments on a GitHub Pull Request, with each comment attached to its specific file and line number. Use this when you have structured review data (file path, line number, message) and want to post them as PR comments via the GitHub API.
- Converts JSON array of review findings into GitHub PR inline comments
- Validates each comment against the PR diff to ensure the line is commentable
- Supports grouped mode (one review with multiple comments) or individual mode (separate comments per finding)
- Allows setting review verdict (COMMENT, APPROVE, REQUEST_CHANGES) in grouped mode
- Dry-run validation to preview what will post and what will be skipped
- Handles multi-line range comments with start_line and start_side
How to install pr-review-comments
npx skills add https://github.com/giuseppe-trisciuoglio/developer-kit --skill pr-review-comments- gh CLI installed and authenticated (gh auth status)
- PR number to comment on
- JSON file with array of objects containing: file, line, and message (summary/failure_scenario or explicit body)
How to use pr-review-comments
- 1.Prepare a JSON file with review findings as an array of objects, each with file, line, and a message field
- 2.Run a dry-run to validate: scripts/post_pr_comments.py --pr <N> --json <path> --dry-run
- 3.Review the output to see which findings are postable and which are skipped (outside the diff)
- 4.Post the comments using grouped mode (default): scripts/post_pr_comments.py --pr <N> --json <path> --event COMMENT
- 5.Or use individual mode for separate comment threads: scripts/post_pr_comments.py --pr <N> --json <path> --mode individual
Use cases
- Post automated code review findings to a PR with line-specific feedback
- Publish linting or security scan results as inline PR comments
- Attach test failure details to the exact lines that caused them
- Convert structured review data into GitHub's native comment interface
- Batch-post multiple review findings in a single grouped review
- Developers automating code review workflows
- CI/CD pipelines generating structured review output
- Code quality or security scanning tools
- Teams using GitHub for collaborative code review
pr-review-comments FAQ
GitHub only allows inline comments on lines that are part of the PR's diff. If a line number is outside the changed hunks, it cannot be commented on. Use --dry-run to identify skipped findings before posting.
Grouped mode (default) bundles all comments into one PR review with a single notification and optional verdict. Individual mode posts each comment separately, creating independent threads and notifications.
Yes, in grouped mode use --event REQUEST_CHANGES or --event APPROVE. Individual mode does not support verdicts.
No, the skill uses the authenticated gh CLI, so no token handling is needed. Just ensure gh auth status shows you are logged in.
Yes, use side: "LEFT" in the JSON object for lines removed in the PR. The line number should still refer to the original file.
Full instructions (SKILL.md)
Source of truth, from giuseppe-trisciuoglio/developer-kit.
name: pr-review-comments description: Posts 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 published on a PR as inline review comments. Triggers include "post these review comments on the PR", "associate comments to files in the PR", "publish review findings to PR #N", or having a JSON array of {file, line, summary} to turn into PR comments. allowed-tools: Read, Write, Bash
PR Review Comments
Publish a JSON array of review findings as inline comments on a GitHub Pull Request,
each anchored to its file and line. Uses the GitHub API through the authenticated
gh CLI, so no token handling is needed.
Prerequisites
ghCLI installed and authenticated (gh auth status). The script auto-detects the repo withgh repo view; pass--repo OWNER/REPOto override.- The PR number to comment on.
- A JSON file: an array of objects. Required keys per object:
file,line. Message comes fromsummaryand/orfailure_scenario(combined into the body), or an explicitbody. See references/json-schema.md for the full schema and a sample.
Key constraint: only diff lines are commentable
GitHub only accepts an inline comment if the target line is part of the PR's diff.
line is the line number in the new file (use side: "LEFT" for removed lines).
The script fetches the PR diff, validates every finding against the actual hunks, and
skips any whose line is outside the diff — reporting them at the end so nothing is
lost silently. There is no way to attach a line comment to an unchanged, undiffed line.
Workflow
- Confirm the JSON path and the PR number. If the repo isn't obvious, run
gh repo view. - Dry-run first to see what will be posted and what gets skipped:
scripts/post_pr_comments.py --pr <N> --json <path> --dry-run - Review the "Postable" / "Skipped" counts with the user. If lines were skipped because the diff moved, the line numbers in the JSON may be stale — reconcile before posting.
- Post for real, choosing the mode (see below):
# Grouped (default): one PR review bundling all comments scripts/post_pr_comments.py --pr <N> --json <path> --event COMMENT # Individual: one separate inline comment per finding scripts/post_pr_comments.py --pr <N> --json <path> --mode individual - Report back the created review/comment URLs and the list of any skipped findings.
Choosing the mode
| Mode | Endpoint | Use when |
|---|---|---|
grouped (default) | POST /pulls/{n}/reviews | Publishing a set of findings as one review. One notification; can set --event APPROVE | REQUEST_CHANGES | COMMENT. |
individual | POST /pulls/{n}/comments | Adding standalone comments incrementally, or when each finding should be its own thread/notification. |
Default to grouped with --event COMMENT unless the user wants a verdict or separate threads.
Options reference
--pr N PR number (required)
--json PATH JSON array of findings (required)
--repo OWNER/REPO Override auto-detected repo
--mode grouped|individual Default: grouped
--event COMMENT|APPROVE|REQUEST_CHANGES Grouped-mode verdict (default COMMENT)
--review-body TEXT Top-level summary body for the grouped review
--commit SHA Commit to anchor to (default: PR head SHA)
--dry-run Validate and print payloads without posting
Notes
- Multi-line range comments: include
start_line(and optionalstart_side) in the JSON object alongsideline; the script passes them through. - Always
--dry-runbefore a real post on an unfamiliar PR — stale line numbers are the most common failure and the dry-run surfaces them as "skipped" without side effects. - The script is the reliable path; don't hand-roll
gh apicalls for this — it handles diff validation, repo/commit detection, and body assembly consistently.
Related skills
More from giuseppe-trisciuoglio/developer-kit and the wider catalog.

prompt-engineering
Design, debug, and optimize LLM prompts with few-shot learning, chain-of-thought, and template systems.

qdrant
Qdrant vector database integration for Java with LangChain4j—semantic search and RAG pipelines.

qwen-coder
Delegate coding tasks to Qwen Coder CLI with safe approval workflows and explicit model selection.

rag
Document chunking, embedding generation, and vector storage for Retrieval-Augmented Generation systems.

ralph-loop
Ralph Wiggum-inspired automation loop for specification-driven development with context window management.

react-code-review
Comprehensive code review for React applications with architecture, hooks, performance, and accessibility validation.