check-pr-comments
Fetch unresolved PR review threads, triage them, implement fixes, validate, reply in-thread, and resolve.
Best use case
check-pr-comments is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Fetch unresolved PR review threads, triage them, implement fixes, validate, reply in-thread, and resolve.
Teams using check-pr-comments should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/check-pr-comments/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How check-pr-comments Compares
| Feature / Agent | check-pr-comments | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Fetch unresolved PR review threads, triage them, implement fixes, validate, reply in-thread, and resolve.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Address PR Comments
## Steps
### 1. Identify the PR
Run `gh auth status`. Use the user-supplied PR number/URL, or detect from
current branch: `gh pr view --json number,title,url,headRefName,baseRefName`.
If no PR found, ask the user.
### 2. Fetch unresolved review threads
Get repo owner/name: `gh repo view --json owner,name -q '.owner.login + " " + .name'`
Fetch threads via GraphQL:
```bash
gh api graphql -f query="
query(\$owner:String!, \$repo:String!, \$number:Int!) {
repository(owner:\$owner, name:\$repo) {
pullRequest(number:\$number) {
reviewThreads(first:100) {
pageInfo { hasNextPage endCursor }
nodes {
id isResolved isOutdated
comments(first:20) {
pageInfo { hasNextPage endCursor }
nodes { id author{login} body path line url }
}
}
}
}
}
}" -F owner=<OWNER> -F repo=<REPO> -F number=<PR_NUMBER>
```
If `hasNextPage` is true, re-run the query adding `after: "<endCursor>"`
to the corresponding connection (e.g., `reviewThreads(first:100, after:"<cursor>")`).
Focus on `isResolved: false` threads.
### 3. Triage table -- stop for approval
Present a Markdown table before any edits:
| Comment | File | Triage |
| --- | --- | --- |
| <paraphrase> | `path` or `PR-level` | Implement / Reply only / Blocked |
Wait for **explicit** user approval before proceeding.
### 4. Apply fixes
Address one thread at a time, minimal changes. Fix root cause once when
multiple threads share it.
### 5. Validate
Run smallest meaningful validation for the changed area. Do not claim
"fixed" without running validation or stating it is unverified.
### 6. Reply and resolve
Reply in-thread:
```bash
gh api graphql -f query="mutation(\$threadId:ID!, \$body:String!) {
addPullRequestReviewThreadReply(input:{pullRequestReviewThreadId:\$threadId, body:\$body})
{ comment { url } }
}" -F threadId=<ID> -f body='Addressed in <summary>.'
```
Resolve only after reply and real fix:
```bash
gh api graphql -f query="mutation(\$threadId:ID!) {
resolveReviewThread(input:{threadId:\$threadId}) { thread { id isResolved } }
}" -F threadId=<ID>
```
For explanation-only replies, leave thread open unless user says to resolve.
## Guardrails
- No edits, replies, or resolves before user approves the triage table.
- No unrelated cleanups while addressing comments.
- No silent thread resolution without a reply and real fix.Related Skills
check-coverage
Run test coverage measurement, analyze results, and fix gaps when coverage falls below the 80% threshold.
write-tests
Write or update unit tests for changed code, following project conventions and ensuring coverage meets the 80% threshold.
update-pr
Stage, commit, and push follow-up changes to an existing feature branch or PR. Use for quick iterations.
setup-environment
Set up or verify the local development environment. Use when starting work in a fresh clone or new machine, when commands fail with missing dependencies or broken imports, or before running `make check`/`make test` for the first time in a session.
review-architecture
Review architecture quality, maintainability, and developer experience.
make-yt-issue
Ensure a YouTrack issue exists before starting work. Validates existing tickets or creates new ones.
local-code-review
Review local code changes for correctness, regressions, missing tests, and Databao-specific risks.
eval-skills
Run structured evaluations on skills to measure quality and track improvements.
create-pr
Stage, commit, push, and open a GitHub PR following project conventions. Use when code is ready to ship.
create-branch
Create a feature branch following project naming conventions. Use when starting work on a ticket, after understanding the scope, or when the agent needs to branch off main for new work.
autosteer
Run the full development pipeline autonomously without pausing between phases. Stops only on quality-gate failures.
ward-identity-checker
Ward Identity Checker