CtrlK
BlogDocsLog inGet started
Tessl Logo

check-pr

Check a single PR's CI status, review comments, and requested changes. Fix actionable failures and address feedback. "check PR 1234", "what's the status of my PR", "address review comments on #500".

99

Quality

100%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Advisory

Suggest reviewing before use

SKILL.md
Quality
Evals
Security

Check PR

Do one pass over PR $ARGUMENTS: check CI, read reviews, fix what's actionable, report status.

1. Gather PR state

# Overall state
gh pr view $ARGUMENTS --repo docker/docs --json state,title,url,headRefName

# CI checks
gh pr checks $ARGUMENTS --repo docker/docs --json name,state,detailsUrl

# Top-level reviews
gh pr view $ARGUMENTS --repo docker/docs --json reviews,reviewDecision

# Inline (line-level) comments — NOT included in the above
gh api repos/docker/docs/pulls/$ARGUMENTS/comments \
  --jq '[.[] | {id: .id, author: .user.login, body: .body, path: .path, line: .line}]'

Always check both the reviews endpoint and the inline comments endpoint. A review with an empty body may still have line-level comments requiring action.

2. If merged

Report the final state. Then check for any unanswered review comments (both top-level and inline) and reply to each one explaining what was done or that the issue was addressed in a follow-up. Skip to step 6 after.

3. If closed without merge

Read the closing context to understand why:

gh pr view $ARGUMENTS --repo docker/docs --json closedAt,comments \
  --jq '{closedAt, lastComment: .comments[-1].body}'

Report the reason. Common causes: rejected by maintainers, superseded by another PR, closed by automation.

4. If CI is failing

  • Read the failure details (follow detailsUrl if needed)
  • Determine if the failure is in the PR's changed files or pre-existing
  • Actionable: check out the branch, fix, commit, push
    git checkout <branch>
    # fix the issue
    git add <files>
    git commit -m "fix: <description>"
    git push
  • Pre-existing / upstream: note it, do not block

5. If review comments or changes requested

  • Read each unresolved comment
  • Address feedback in a follow-up commit
  • Push, then reply to each comment explaining what was done:
    gh api repos/docker/docs/pulls/$ARGUMENTS/comments \
      --method POST \
      --field in_reply_to=<comment-id> \
      --field body="<response>"
  • End every comment reply with an accurate agent-disclosure footer that names the active coding agent, for example Generated by Codex or Generated by Claude Code.
  • Resolve each thread via GraphQL after replying:
    # Get thread IDs
    gh api graphql -f query='
      query($owner:String!, $repo:String!, $pr:Int!) {
        repository(owner:$owner, name:$repo) {
          pullRequest(number:$pr) {
            reviewThreads(first:50) {
              nodes { id isResolved comments(first:1) { nodes { path } } }
            }
          }
        }
      }' -f owner=docker -f repo=docs -F pr=$ARGUMENTS \
      --jq '.data.repository.pullRequest.reviewThreads.nodes[] | select(.isResolved == false) | {id, path: .comments.nodes[0].path}'
    
    # Resolve a thread
    gh api graphql -f query='
      mutation($id:ID!) { resolveReviewThread(input:{threadId:$id}) { thread { isResolved } } }
    ' -f id=<thread-id>
  • Re-request review if changes were requested

6. Report

## PR #$ARGUMENTS: <title>

**State:** <open|merged|closed>
**CI:** <passing|failing|pending>
**Review:** <approved|changes requested|pending>
**Action taken:** <what was done, or "none needed">
Repository
docker/docs
Last updated
Created

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.