verify-unresolved-pr-comments

Files (1)

• SKILL.md

SKILL.md (first lines)

Follow these steps exactly and in order. Do not substitute your own approach,
output format, or API calls. Do not produce any output until all data-gathering
steps are complete.

## Operating mode

This prompt is read-only triage. Do not modify files, apply patches, stage
changes, commit changes, run formatters, run lint, run tests, resolve review
threads, or post PR comments. On success, the only output should be the triage
table and the one-line summary requested below. On failure to retrieve review
thread data, do not produce a table.

When a review comment is valid, recommend the minimal fix in the table only. Do
not implement the fix. When a review comment is invalid or should not be fixed,
write the exact response the developer can post manually. Do not post it.

## Fetch the PR and collect review feedback

The goal of this step is to retrieve all review feedback on the active pull
request, including:

- Inline review threads with their resolution status (`isResolved`)
- Review-level bodies, such as requested-changes or commented reviews
- PR-level conversation comments (issue comments on the PR)

Resolution status is required for inline review threads, without it you cannot
distinguish resolved from unresolved threads. PR-level comments and review
bodies do not have thread resolution status, so evaluate them separately as
described below.

Inspect the available integration surfaces for GitHub PR access, such as tools
or toolsets, MCP servers and resources, skills or slash commands, plugins, and
custom agents or subagents. Use an internal capability only when it returns
review-thread resolution state and PR-level comments, otherwise it cannot be
the source of truth for the full PR feedback set. If no such capability is
available, or it cannot expose thread resolution status, fall back to the CLI
approach below.

### CLI fallback

**Constraints for this option:**

- Do NOT use `/pulls/.../comments` to fetch review threads, it does not expose
  `isResolved`. Use the GraphQL API for review thread data.
- Do not guess the PR number or repository owner/name, retrieve them as shown
  below.

Get the active PR number from the current branch and the repository owner/name:

```bash
gh pr view --json number,headRefName,reviewDecision
gh repo view --json nameWithOwner
```

Pass `OWNER`, `REPO`, and `NUMBER` as variables via `-F`. Leave cursor variables
unset on the first request. On follow-up requests, pass the relevant `endCursor`
value back with `-F threadsCursor=END_CURSOR` or `-F reviewsCursor=END_CURSOR`
or `-F prCommentsCursor=END_CURSOR`:

```bash
gh api graphql \
  -F owner=OWNER \
  -F repo=REPO \
  -F number=NUMBER \
  -f query='
query($owner: String!, $repo: String!, $number: Int!, $threadsCursor: String, $reviewsCursor: String, $prCommentsCursor: String) {
  repository(owner: $owner, name: $repo) {
    pullRequest(number: $number) {
      reviewDecision
      reviewThreads(first: 100, after: $threadsCursor) {
        pageInfo {
          hasNextPage
          endCursor
        }
        nodes {
          id
          isResolved
          comments(first: 100) {
            pageInfo {
              hasNextPage
              endCursor
            }
            nodes {
              author { login }
              path
              line
              body
            }
          }
        }
      }
      reviews(first: 100, after: $reviewsCursor) {
        pageInfo {
          hasNextPage
          endCursor
        }
        nodes {
          author { login }
          state
          body
          submittedAt
        }
      }
      comments(first: 100, after: $prCommentsCursor) {
        pageInfo {
          hasNextPage
          endCursor
        }
        nodes {
          author { login }
          body
          createdAt
        }
      }
    }
  }
}'
```

From ioncache/ioncache-ai-tools, MIT.

More from ioncache/ioncache-ai-tools