pr-review-post

Post PR Review Replies

Preview draft replies from the plan artifact, ask for explicit confirmation, then batch-post replies and resolve threads on GitHub. This is the only skill that touches GitHub in the PR review pipeline.

This skill posts public, irreversible comments. It always shows a preview and asks for confirmation before posting.

Prerequisites

• A plan artifact exists at .pr-review/pr-<N>-plan.md with status fixed
• The plan was created by /pr-review:pr-review-plan and fixes applied by /pr-review:pr-review-apply
• gh CLI authenticated with permissions to comment on PRs
• jq installed

Step 1: Locate and validate the plan file

Find the most recent plan file in .pr-review/. Check the **Status** header:

• fixed → proceed
• triaged → refuse: "Fixes haven't been applied yet. Run /pr-review:pr-review-apply first."
• fixing → refuse: "Fixes are still in progress. Finish /pr-review:pr-review-apply first."
• posted → refuse: "Replies have already been posted for this plan."

Step 2: Preview all draft replies

Show the user the complete list of draft replies as they appear in the plan file. The user may have edited them since triage. Format as a clear table or list:

## Replies to post on PR #<N>

Thread <id> (src/Foo.kt:42) — fixed
  Reply: "Applied the suggestion, thanks."

Thread <id> (src/Bar.kt:10) — skipped (disagree)
  Reply: "Disagree — this value is runtime-computed from config."

Thread <id> (src/Baz.kt:25) — fixed
  Reply: "Fixed — added null check for the timeout case."

Total: N replies to post, all threads will be resolved.

Ask the user for explicit confirmation: "These replies will be posted publicly and threads resolved. Proceed?"

Do not post without confirmation. If the user says no, stop and let them edit the plan file.

Step 3: Build payload and post

Extract the repo, PR number, thread IDs, replies, and resolve flags from the plan file. Build a JSON payload file at /tmp/pr-<N>-post-payload.json:

{
  "repo": "owner/repo",
  "pr_number": 123,
  "actions": [
    {"thread_id": "12345", "reply": "Applied the suggestion, thanks.", "resolve": true},
    {"thread_id": "67890", "reply": "Disagree — runtime value.", "resolve": true}
  ]
}

Invoke the batch post script:

bash ${CLAUDE_PLUGIN_ROOT}/scripts/gh-review-post.sh /tmp/pr-<N>-post-payload.json

The script:

• Fetches the GraphQL thread-id map once
• Posts each reply via REST API
• Resolves each thread via GraphQL mutation
• Continues on per-action failure
• Prints summary: posted: N/M, resolved: N/M

Step 4: Update plan and report

Read the script's exit code and stdout summary:

• Exit 0: all actions succeeded. Update plan header to **Status**: posted. Mark each thread [x] posted.
• Exit 1: partial success. Update plan header to **Status**: partial. Mark succeeded threads [x] posted, failed threads [ ] post_failed. Report which threads failed so the user can retry or manually resolve.
• Exit 2: fatal error (auth, bad input). Report the error. Don't update the plan.

Tell the user:

• How many replies were posted and threads resolved
• If anything failed, what to do about it
• Ask:

"Replies posted. Want to check for recurring patterns across recent reviews?

1. Run extract-lessons now
2. Skip for now

Which option?"

Wait for the user's response.

• Option 1: Announce: "Analyzing patterns across recent reviews." Then use pr-review:pr-review-extract-lessons to continue.
• Option 2: Stop here.

Important guidelines

• Always preview before posting. The user must see every reply and confirm.
• Never post without confirmation. This is the most dangerous skill in the pipeline — it creates irreversible public comments.
• Honor user edits. If the user edited draft replies in the plan file, post their version.
• Do not modify source files. That's /pr-review:pr-review-apply's job.
• Do not commit. The user decides when to commit.
• Resolve all threads. Both fixed and skipped threads get resolved — the reply explains why.