resolve-pr-comments-c11644 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited resolve-pr-comments-c11644 (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.
Fetch unresolved review comments from a GitHub PR (inline threads, review-body observations, and issue-comment observations from the PR conversation), evaluate each one, fix or skip based on confidence, answer reviewer questions using the recalled rationale behind the change, and reply. Inline threads are answered with thread replies; issue-comment findings from people are answered with new PR conversation comments. Review-body findings and AI-reviewer issue comments flow through the same evaluate-and-fix pipeline; their outcomes land only in the summary.
At the start, use update_plan to track each step, restating any remaining steps of a parent workflow alongside them:
$interpret-feedback skill$evaluate-findings skill$resolve-findings skill$reply-to-pr-threads skill$reply-to-pr-conversation skillAuto-detect owner, repo, and PR number from current branch if not provided. Then run scripts/fetch-pr-data.sh, which handles full pagination (reviews, review threads, inner comment pages for long threads, issue comments, commits) and emits a single merged JSON document:
bash <skill-dir>/scripts/fetch-pr-data.sh <owner> <repo> <pr_number>Output shape:
{
"meta": { "title", "url", "headRefName", "baseRefName", "body" },
"reviewThreads": [ { "id", "isResolved", "isOutdated", "comments": { "nodes": [ { "author", "body", "path", "line", "originalLine", "diffHunk" } ] } } ],
"reviews": [ { "author", "body", "state", "submittedAt" } ],
"issueComments": [ { "author", "body", "createdAt", "url" } ],
"commits": [ { "commit": { "oid", "abbreviatedOid", "message", "committedDate" } } ]
}Filter review threads to unresolved only. Filter reviews to those with a non-empty body, excluding PENDING state (unsubmitted drafts). Filter issue comments to those with a non-empty body.
Review bodies and PR conversation comments (issue comments) often pack multiple distinct concerns into one comment. Split each non-empty, non-PENDING review body and each non-empty issue comment into atomic observations, one per paragraph or bullet, so each can be evaluated on its own merits.
For every observation, check whether a subsequent commit already addresses it. Compare the source timestamp (submittedAt for review bodies, createdAt for issue comments) against each commit's committedDate; only commits after the source was posted can address it. Start with commit messages; read git show <oid> only when the message is ambiguous. A commit addresses an observation when its changes clearly resolve that specific concern. Touching the same area is not enough for an observation.
When an observation asserts a requirement or an intended behavior, compare that assertion against meta.body. The PR description is the author's own current statement of intent, so a description stating the opposite leaves a premise for Step 5 to settle. Record the contradiction against the observation and carry it forward, so Step 5 settles that premise once instead of re-deriving it for every finding the premise produced.
Classify each observation:
source (review-body or issue-comment), the author, the observation text, any recorded contradiction with the PR description, and (for review bodies) the review state.Review-body and issue-comment findings have no diffHunk, file path, or line reference. The downstream pipeline handles findings without a code location.
Triage inline threads on their replies. Look for a later reply that claims the concern is fixed and names the commit that fixed it. Verify two things about that commit. First, it is on the branch: it appears in commits, or git branch --contains <sha> reports the head branch. Second, it changed or deleted the thread's path. When both hold, classify the thread Addressed with that SHA and skip Steps 3 through 8 for it. Classify the rest Unaddressed and carry them into Step 3.
$interpret-feedback SkillRun the $interpret-feedback skill on the union of:
Skip AI-reviewer accounts — match by known login (e.g., coderabbitai, copilot-pull-request-reviewer, github-advanced-security), not the [bot] suffix alone. Their structured feedback routes directly to $evaluate-findings.
If that leaves no items to interpret, skip the skill invocation.
For inline threads, include the diffHunk so the interpreters can see the code the reviewer was looking at. For outdated comments where line is null, use originalLine. For review-body and issue-comment findings, provide the observation text and the PR's changed-file list as context.
Tag each item with its source (inline-thread, review-body, or issue-comment) so later steps can route replies correctly.
Classify each interpreted item as either a question or a change request based on the reconciled intent from Step 3.
When in doubt, treat the item as a change request. The verdict from $evaluate-findings in Step 5 will catch genuine non-issues.
Produce two lists. Each entry retains the source tag, identifier (thread id for inline threads; a generated id for review-body and issue-comment findings), file path and line (use originalLine when line is null; omit for review-body and issue-comment findings), the reviewer's original text, any recorded contradiction with the PR description, and the reconciled intent from Step 3. Questions skip Step 5 and feed Step 9. Change requests feed Step 5.
$evaluate-findings SkillIf Step 4 produced no change requests and Step 3 routed no AI-reviewer items here, skip the skill invocation.
Run the $evaluate-findings skill on the change requests from Step 4 and the AI-reviewer items Step 3 routed here, to triage each one. Questions are not evaluated here.
Review-body and issue-comment findings have no file or line reference. Scope their assessment to the PR's changed files as a whole, and do not treat the absent code location as a "code has diverged" early exit.
Collect items assigned an Escalate verdict by $evaluate-findings. If there are none, skip to Step 7.
Output all escalated items as a numbered list. For each item, show:
Then use request_user_input to ask how to handle them. State each question as the decision the user owns: what the code should do. Leave the reviewer's wording and code location to the numbered list above. Per item, the options are:
Whenever the item is costly to reverse (its resolution establishes a pattern others will follow, defines an interface, commits to a data shape, or imports a pattern the codebase has not used), and whenever you cannot recommend one of the others with conviction, present a Get a second opinion option, in place of Skip when Ask the reviewer is offered, keeping the question at three options or fewer. It runs the $consult-claude skill for the soundest resolution on technical merit alone, independent of the changeset's original scope, naming any scope cost with the answer. On an item that turns on product intent, run it for what each resolution commits to, what reversing it costs, and what the prevailing convention is. Then resolve the item with that answer in hand, re-asking when the choice stays the user's. A freeform answer that declines the item removes it from processing.
$resolve-findings SkillIf there are no accepted findings to implement, skip to Step 9.
Run the $resolve-findings skill on the accepted findings from Step 5, including any items reclassified in Step 6. It commits and pushes before returning; Steps 11 and 12 replies reference that commit SHA.
For each finding that was fixed in Step 7, verify the fix actually addresses the reviewer's concern:
diffHunk when available).If the fix did not address the concern (wrong location, incomplete change, or the issue is still present), downgrade the item to Skip. Record the reason (the attempted fix did not resolve the reviewer's concern, with a brief explanation of what remains) so Step 11 (for inline threads), Step 12 (for the issue-comment findings it replies to), and Step 13 (for the rest) report it correctly.
For each question item whose source is inline-thread, run the $recall-rationale skill with <path>:<line> and compose a one-or-two-sentence answer from the rationale it returns, quoting or paraphrasing the implementer's own words where they explain the decision. When it finds no session history, compose the answer from the current code and record that grounding for Step 13. Leave out any mention of Codex, session history, or recalled rationale, and leave voice rules and reply formatting to Step 11.
Issue-comment questions are composed during Step 12's assembly and posted by $reply-to-pr-conversation. They have no file and line to ground with $recall-rationale, so the composition draws on the reconciled intent and the PR's changed code. Review-body questions have no destination to post to and are listed for manual follow-up in Step 13.
If there are no inline-thread questions, skip this step.
Skip this step when Step 7 pushed no commit, or when no inline thread whose first comment is from an AI-reviewer account as matched in Step 3 came out of Steps 5 through 8 fixed or skipped.
For each AI reviewer with such a thread, check whether it is re-reviewing the pushed head commit: a pending review request for it, a queued or in-progress check or workflow run from it on that commit, or a review it already submitted on that commit. Leave github-advanced-security out of this check. Repeat the check until each of those reviewers has shown one, or until 3 minutes have passed since the push. When none has, skip the rest of this step.
Otherwise poll the PR's reviews (reviews(last: 20) { nodes { author { login } commit { oid } } }) in a shell loop that ends once each reviewer found re-reviewing has submitted a review whose commit is the pushed head, or after 15 minutes. Then run scripts/fetch-pr-data.sh again. Drop from processing every inline thread that is now resolved, and leave threads and review bodies that arrived since Step 1 for a later run; record both for the Step 13 summary.
$reply-to-pr-threads SkillAssemble the processed-thread list from inline-thread items only:
$evaluate-findings, plus any downgraded in Step 8. Payload: the skip reasoning.Give each fix and skip entry whose first comment is from an AI-reviewer account as matched in Step 3 a resolution reason: ADDRESSED for a fix, INVALID for a skip that refuted the finding as incorrect, and WONT_FIX for a skip that declined a valid one. Give every resolve-only entry ADDRESSED. Give none to a thread downgraded in Step 8, to a skip that neither refuted nor declined the finding, or to any other thread, leaving it for its reviewer to resolve.
A thread whose first comment is from github-advanced-security carries a code-scanning alert. Give each such skip entry that carries a resolution reason the alert number from the comment's /security/code-scanning/<n> link and a dismissal reason: used in tests when the flagged code runs only in tests, otherwise false positive for INVALID and won't fix for WONT_FIX.
Issue-comment findings go to Step 12. Review-body findings have no destination to post to, Addressed inline threads outside the resolve-only entries already carry the reply naming the commit, and threads Step 10 dropped were resolved during the wait; all three surface only in Step 13.
If there are no inline-thread items to reply to or resolve, skip the skill invocation.
Run the $reply-to-pr-threads skill with the assembled list.
$reply-to-pr-conversation SkillAssemble the processed-item list from issue-comment items only. Each entry includes the generated id, the author, the original comment body (for quoting), the category, and the per-category payload:
$evaluate-findings, plus any downgraded in Step 8. Payload: the skip reasoning.Review-body findings have no destination to post to, and issue comments from AI-reviewer accounts, matched as in Step 3, get no conversation reply. Exclude both from this list; their triage status is reported in Step 13.
If there are no issue-comment items to reply to, skip the skill invocation.
Run the $reply-to-pr-conversation skill with the assembled list.
After processing all items, present a summary grouped by source.
Inline threads:
Review-body findings:
Issue-comment findings:
Overall: list of files modified.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.