pr-check

DLC: PR Review Compliance

Fetch PR review comments, implement fixes for unresolved items, and report compliance.

Before running, read [../dlc/references/ISSUE-TEMPLATE.md](../dlc/references/ISSUE-TEMPLATE.md) now for the issue format, and read [../dlc/references/REPORT-FORMAT.md](../dlc/references/REPORT-FORMAT.md) now for the findings data structure.

This skill uses progressive disclosure. The orchestration skeleton (fetch, categorize, reply, coverage-verify, commit) lives in SKILL.md. Conditional branches — fixable implementation, discussion handling, and follow-up issue creation — live in references/ and are read only when their triggering condition fires:

• [references/fixable-workflow.md](references/fixable-workflow.md) — context read, confidence-gated evaluation, implementation guardrails (Step 3)
• [references/discussion-workflow.md](references/discussion-workflow.md) — classification, auto-action criteria, AskUserQuestion routing (Step 3.5)
• [references/followup-and-summary.md](references/followup-and-summary.md) — follow-up issue creation, decision-aware replies, PR summary (Step 5)

Do not preload these references — each Step pointer below names its file and its skip condition.

No GitHub mentions in posted text: Any text this skill posts to GitHub —

inline replies, review-body replies, issue-comment replies, follow-up issue

bodies, and the PR summary — MUST NOT contain an @-prefixed username or bot

name. Write the bare login instead. This applies to bots (copilot,

coderabbitai, gemini-code-assist, greptile-apps, qodo-code-review)

and humans alike — GitHub turns an @-prefixed username into a live

mention notification even for bot accounts, which can trigger unwanted

bot actions such as an auto-generated duplicate PR.

- Wrong: attributing a fix to a reviewer with an @-prefixed name

- Right: Fixed: constrained values to exact literals (copilot)

This applies even when quoting a reviewer's own words: when embedding an

excerpt of the original comment (e.g. Step 4's `{first 100 chars of

original body}), neutralize every @` character in the excerpt before

writing it — insert a space immediately after it, don't delete it — so a

reviewer's own self-mention or tag can't resurrect a live notification

when re-posted, while the excerpt still reads recognizably close to the

original (an email address or scoped package name the reviewer quoted

stays legible instead of turning into different text). Note that not

every bot mention goes through GitHub's markdown renderer — some bots

(Copilot's coding agent among them) react to a raw substring scan of the

comment body, not to rendered links. Neutralizing the @ character is

the only reliable defense against both; code-fencing or blockquoting an

excerpt is not sufficient on its own.

This applies just as much to {reply text} itself — the description the

agent composes to explain a fix, dismissal, or answer — not only to the

quoted excerpt. A composed reply describing a fix can legitimately contain

an @-prefixed technical token (a scoped package bumped as part of the

fix, a decorator added, an email in a config example): insert a space

after the @ there too, the same as in a quoted excerpt. The only case

that uses the bare-name form instead of space-insertion is the agent

naming a reviewer or bot itself, as in the (copilot) example above.

No text that gets posted to GitHub may pass through shell-string

interpolation or a heredoc — a heredoc's delimiter only disables

expansion inside it, not collision with reviewer-controlled text that

happens to match the delimiter itself. See each Step's reply-routing block

below for the file-based mechanism (Write tool + --body-file /

-F body=@file) that enforces this.

Step 1: Fetch PR Data

Parse arguments

The skill accepts two arguments, in any order:

• <PR_NUMBER> — numeric PR reference. Optional; when omitted, auto-detect from the current branch.
• --unattended — optional flag. When present, set UNATTENDED=true and carry it through downstream steps. Gates the autonomy ladder in Step 3.5, suppresses AskUserQuestion in Steps 3, 3.5, and 5a, activates Pending-Human classification, and emits the Step 6 Pending-Human: summary line. When absent (default), behavior is identical to attended mode.

Parse --unattended out of the argument string before invoking the script; only the PR number (if any) goes to pr-comments.sh.

Run pr-comments.sh

Run the pr-comments.sh script from the plugin's scripts/ directory:

# If PR number provided as argument
sh "${CLAUDE_SKILL_DIR}/../../scripts/pr-comments.sh" <PR_NUMBER>

# If no argument — auto-detect from current branch
sh "${CLAUDE_SKILL_DIR}/../../scripts/pr-comments.sh"

Validate the response:

• Check stderr for a JSON error object — if present, abort with the error message
• Extract from the JSON output and store as variables:
• PR_NUMBER ← .pr.number
• PR_TITLE ← .pr.title
• PR_BRANCH ← .pr.branch
• PR_STATE ← .pr.state
• PR_AUTHOR ← .pr.author
• PR_VIEWER ← .pr.viewer
• PR_URL ← .pr.url
• PR_OWNER ← .pr.owner
• PR_REPO ← .pr.repo
• REVIEW_DECISION ← .pr.reviewDecision
• REVIEW_BODIES ← .review_bodies
• ISSUE_COMMENTS ← .issue_comments (unfiltered — includes PR author + authentic DLC sentinel replies, used for "already replied" detection)
• REVIEWER_ISSUE_COMMENTS ← .reviewer_issue_comments (filtered — excludes PR author + authentic DLC sentinels, used for categorization and coverage)

State check: If PR_STATE is not OPEN, abort with: "PR #{PR_NUMBER} is {PR_STATE} — only open PRs can be checked."

Truncation warning: If .summary.truncated is true, warn: "Review data was truncated — some threads or review bodies may be missing from the analysis."

Print reviewer inventory from the pre-built .reviewers array:

Reviewer inventory ({summary.reviewer_count} reviewers, {summary.total_comments} total comments, {summary.total_threads} threads, {summary.total_review_bodies} review bodies, {summary.total_issue_comments} issue comments):
  - {reviewer.login}: {reviewer.total_comments} comments ({reviewer.top_level_threads} threads, {reviewer.review_bodies} review bodies, {reviewer.issue_comments} issue comments)

Store each reviewer's top_level_threads, review_bodies, and issue_comments counts as the coverage targets for Step 4b.

Step 1b: Verify and Checkout PR Branch

Before making any changes, verify you are on the PR's source branch (PR_BRANCH from Step 1).

CURRENT=$(git branch --show-current)

if [ "$CURRENT" = "$PR_BRANCH" ]; then
  echo "Already on PR branch $PR_BRANCH — proceeding."
else
  # Check for uncommitted changes (tracked and untracked)
  if [ -n "$(git status --porcelain)" ]; then
    echo "ERROR: Current branch ($CURRENT) does not match PR branch ($PR_BRANCH) and worktree is dirty."
    echo "Stash or commit your changes, then re-run."
    exit 1
  fi

  # Clean worktree — attempt to checkout the PR branch
  echo "Switching to PR branch $PR_BRANCH..."
  gh pr checkout $PR_NUMBER

  # Post-checkout verification (defense-in-depth)
  VERIFY=$(git branch --show-current)
  if [ "$VERIFY" != "$PR_BRANCH" ]; then
    echo "ERROR: Checkout failed — expected $PR_BRANCH but on $VERIFY. Aborting."
    exit 1
  fi
  echo "Successfully checked out $PR_BRANCH."
fi

If verification fails, abort with the error above. Do not proceed to Step 2 on the wrong branch — commits and pushes would target the wrong remote branch.

Step 2: Categorize Comments

Thread categorization

Using the .threads array from Step 1, classify each top-level review thread:

| Category | Criteria | |----------|----------| | Resolved | is_resolved == true, OR PR author replied with affirmative language, OR thread alrea