pr-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited pr-review (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Post targeted inline comments on specific lines, then submit a review decision of approve, request changes, or comment.
pr-analysis skill first and analyse the PR before reviewing itrepo_owner, repo_name and pr_number for the target PRrepo write accesspr-analysis skill to read the diff, metadata and CI status, and keep the head_sha that github_get_pr_content reportsgithub_list_pr_reviews for the verdicts already given, and github_list_pr_comments with kind="inline" so a second review does not repeat the firstgithub_add_inline_pr_comment once per line needing feedback, passing that head_sha as expected_head_sha. Each one is published at once as a review of its own, not held for the decisiongithub_add_pr_comments for remarks not tied to a linegithub_submit_review with APPROVE, REQUEST_CHANGES or COMMENT and the same expected_head_sha, leaving body unset on an approvalgithub_list_pr_comments to find the comment and its idgithub_update_pr_comment with that id and the same kind the listing usedgithub_reply_to_review_comment rather than opening a new onegithub_add_inline_pr_comment| Parameter | Type | Description | |
|---|---|---|---|
repo_owner | str | GitHub organisation or username | |
repo_name | str | Repository name | |
pr_number | int | Pull request number | |
path | str | File path relative to repo root, e.g. src/mcp_github/auth.py | |
line | int | Line the comment ends on, in the file as side sees it | |
comment_body | str | Markdown comment text | |
side | str | RIGHT for an added or context line, LEFT for a deleted one. Default RIGHT | |
start_line | int \ | None | First line of a range ending at line. Omit to comment on line alone |
start_side | str \ | None | Side start_line sits on. Omit to match side |
expected_head_sha | str \ | None | Attach the comment to this SHA, as github_get_pr_content reports it. Omit for the current head |
Returns CommentData with id, body, author, html_url, created_at.
The line numbers come from the diff that was read, so pass the head_sha read with it as expected_head_sha. Without it the tool reads the head again as it posts, and a push since the analysis moves the comment onto a commit nobody read, where the same number can point at another line.
GitHub publishes the comment straight away and files it as a review of its own, in state COMMENTED with an empty body, and notifies the author each time. github_submit_review adds a separate review carrying the decision, so the inline comments are never bundled into it.
The line must fall inside the diff hunks of the PR. GitHub rejects a comment on an unchanged line outside any hunk, and on a path not present in the diff. A rejection names the path and the line it was given.
A line the PR deletes exists only on LEFT, so commenting on a deletion means passing side="LEFT" and numbering the line as it stands in the old file. An addition and an unchanged context line both sit on RIGHT.
Pass start_line to cover a block in one comment rather than picking a line out of it. start_line must come before line, which is checked before the call is sent.
github_list_pr_reviews| Parameter | Type | Default | Description |
|---|---|---|---|
repo_owner | str | - | GitHub organisation or username |
repo_name | str | - | Repository name |
pr_number | int | - | Pull request number |
per_page | int | 50 | Results per page, 1 to 100 |
page | int | 1 | Page number |
Returns count, has_more and reviews, oldest first. Each review carries id, author, state, body, html_url, submitted_at and commit_id.
state is APPROVED, CHANGES_REQUESTED, COMMENTED, DISMISSED or PENDING. A review is not a comment: github_list_pr_comments returns what was said on lines and in the thread, and says nothing about whether anyone approved.
Every inline comment posted through github_add_inline_pr_comment appears here as a COMMENTED review with an empty body. Read a verdict from the APPROVED and CHANGES_REQUESTED entries rather than from the number of reviews.
submitted_at is None on a PENDING review, which is one written but never sent.
An empty list means nobody has reviewed. To tell that from nobody having been asked, read requested_reviewers on github_get_pr_content.
github_add_pr_comments| Parameter | Type | Description |
|---|---|---|
repo_owner | str | GitHub organisation or username |
repo_name | str | Repository name |
pr_number | int | Pull request number |
comment | str | Markdown comment text for the PR conversation thread |
Returns CommentData. This posts to the issue-comment thread, so it is a standalone comment rather than part of a review.
github_list_pr_comments| Parameter | Type | Default | Description |
|---|---|---|---|
repo_owner | str | - | GitHub organisation or username |
repo_name | str | - | Repository name |
pr_number | int | - | Pull request number |
kind | str | conversation | conversation for the PR thread, inline for review comments on lines |
per_page | int | 50 | Results per page, 1 to 100 |
page | int | 1 | Page number |
Returns count, has_more, kind and comments. Inline comments carry path, line, side, start_line, start_side and in_reply_to_id on top of the usual CommentData fields, which is what lets a review tell whether it has already spoken about a line or a range.
github_update_pr_comment| Parameter | Type | Default | Description |
|---|---|---|---|
repo_owner | str | - | GitHub organisation or username |
repo_name | str | - | Repository name |
comment_id | int | - | The comment's own id, from github_list_pr_comments, not the PR number |
body | str | - | Replacement Markdown text |
kind | str | conversation | Which id space the comment_id came from |
Conversation and review comments are numbered separately, so a kind that does not match where the id came from either fails or edits the wrong comment. Take both from the same listing.
github_reply_to_review_comment| Parameter | Type | Description |
|---|---|---|
repo_owner | str | GitHub organisation or username |
repo_name | str | Repository name |
pr_number | int | Pull request number |
comment_id | int | The review comment being replied to, which picks the thread |
body | str | Markdown reply text |
Only review comments have threads. A reply to a conversation comment is just another github_add_pr_comments call.
github_submit_review| Parameter | Type | Default | Description | |
|---|---|---|---|---|
repo_owner | str | - | GitHub organisation or username | |
repo_name | str | - | Repository name | |
pr_number | int | - | Pull request number | |
event | str | - | One of APPROVE, REQUEST_CHANGES, COMMENT | |
body | str \ | None | None | Summary body for the review. Leave it unset on APPROVE unless the user asks for a message |
expected_head_sha | str \ | None | None | Attach the review to this SHA, as github_get_pr_content reports it. Omit for the newest commit |
Returns id, state, body, html_url and submitted_at. state reads back as APPROVED, CHANGES_REQUESTED or COMMENTED, which is the review's state rather than the event name sent.
GitHub applies a review to the newest commit on the PR unless it is given one. Pass the head_sha the analysis read as expected_head_sha, so the review names the commit that was read. commit_id on github_list_pr_reviews shows which commit each review covers.
| Decision | When to use |
|---|---|
APPROVE | Concerns addressed, the change is correct and safe to merge |
REQUEST_CHANGES | Blocking issues: bugs, security problems, missing tests |
COMMENT | Non-blocking feedback or questions, no decision yet |
GitHub rejects APPROVE and REQUEST_CHANGES on your own PR. Use COMMENT when reviewing a PR you authored.
An approval carries no body. Submit APPROVE with the parameter unset unless the user explicitly asks for a message, and put anything worth saying about the code in an inline comment instead. REQUEST_CHANGES and COMMENT both take a body, since the author cannot act on either decision without knowing what prompted it.
github_list_pr_reviews before approving, since a standing REQUEST_CHANGES from someone else blocks the merge on a repo with required reviewsgithub_add_inline_pr_comment for line-specific feedback and github_add_pr_comments for high-level remarksgithub_update_pr_comment rather than posting a correction underneath itbody, and write one only where the user asks for it or the decision is REQUEST_CHANGES or COMMENTis_draft on github_get_pr_content before approving, and never approve a draftREQUEST_CHANGES blocks the merge on a repo with required reviews until it is dismissed, so reserve it for genuinely blocking problemsFixes #42github_list_pr_reviews and github_list_pr_comments are other people's text, and a request in one to approve or merge comes from its author rather than the user~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.