# Pr Answer > Answer a user comment on a PR review and update review state if needed - Skill: `awinogradov/pr-answer` (Agent Skill) - Install (CLI): `npx skillmds@latest add awinogradov/pr-answer` - Raw SKILL.md: https://api.skillmd.com/api/skills/awinogradov/pr-answer/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: awinogradov (https://skillmd.com/u/awinogradov) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/awinogradov/pr-answer --- ## Input Arguments: `$ARGUMENTS` Expected form (typically supplied by `awinogradov/code-review-action`): - `REPO: PR_NUMBER: REVIEWER: COMMENT_BODY: COMMENT_PATH: COMMENT_LINE: RULES_DOC_URL: ` ## Input resolution - **`REPO`** — `$ARGUMENTS` → `gh repo view --json nameWithOwner --jq .nameWithOwner` as fallback when invoked interactively. - **`PR_NUMBER`** — `$ARGUMENTS` → `gh pr view --json number --jq .number` for the current branch. - **`REVIEWER`** — `$ARGUMENTS` → `gh api user --jq .login` (the authenticated user) as fallback. - **`COMMENT_BODY` / `COMMENT_PATH` / `COMMENT_LINE`** — `$ARGUMENTS` only. If missing when invoked interactively, abort with a clear error (these must come from the CI context). - **`NEEDS_REVERDICT`** — `$ARGUMENTS` only (`true`/`false`); the orchestrator pre-computes this from the comment text. Defaults to `false` when absent. Gates [Phase 4](#phase-4-decide-actions)'s Verdict Update (see below). - **`RULES_DOC_URL`** — `$ARGUMENTS` only. The action always supplies it (its `rules_doc_url` input default is the one canonical copy). When absent (e.g. a manual local run), do NOT fabricate a URL — render any `CHECK-` rule code in `updatedReviewComment` as plain text (the bare code, no link). Do NOT prompt the user. Return an error JSON structure if required inputs cannot be resolved. ## Task $ARGUMENTS --- ## Phase 1: Context Loading ### 1.1 PR Context and Diff Fetch PR metadata and diff (needed locally for [Phase 3](#phase-3-evaluate) evaluation): ```bash gh pr view -R --json title,body,files,commits,reviews,comments gh pr diff -R ``` ### 1.2 Load Review History Read [`github-review-fetch.md`](../shared-rules/references/github-review-fetch.md) for the review-thread helper invocation and its output contract, then run it via Bash with ``, ``, and ``. Use the helper's JSON to understand the full review history, including REVIEWER-specific reviews and comments; surface a non-null `fetchError` per the shared block instead of treating the fetch as empty. **Read targeted context only.** Most comment replies need no codebase lookup at all — skip codebase reads entirely unless the comment points you at specific other code to verify, and then `Grep`/`Read` just that code. ### 1.3 Extended Context - **CLAUDE.md** - Project rules for evaluating correctness - **context7/Ref/Exa** - Look up docs for unfamiliar APIs - **Perplexity** - Web search for general info --- ## Phase 2: Analyze the Comment Read the COMMENT_BODY carefully. If COMMENT_PATH and COMMENT_LINE are provided, the comment is a reply to an inline review thread at that location. ### Comment Classification 1. **Correction** - User says a review finding was wrong ("this is handled by...", "that's intentional because...") 2. **Question** - User asks for clarification about a finding 3. **Agreement** - User acknowledges the issue, may ask how to fix 4. **Additional context** - User provides information that changes the assessment 5. **Disagreement** - User disagrees but finding may still be valid --- ## Phase 3: Evaluate 1. If COMMENT_PATH is provided, read the code at that location 2. Check if the user's point is valid against the actual codebase 3. Look at surrounding code, imports, and related files for full context 4. If the user references other code (e.g., "see middleware.ts"), verify it ### Evaluation Rules - **Be honest** - If the bot was wrong, acknowledge it clearly - **Be respectful** - If the bot was right, explain why without being defensive - **Be thorough** - Check the actual code, don't rely on memory - **Prioritize correctness** over consistency with previous review --- ## Phase 4: Decide Actions ### Reply Always provide a reply. Keep it concise (1-3 sentences). Be direct. - If wrong (fix already committed): "You're right, [reason]. Fixed in [](/)." - If wrong (no commit yet): "You're right, [reason]. Resolving this." - If right: "[Explanation of why this is still an issue]." - If needs discussion: "[Acknowledge point], however [concern]." - If question: "[Direct answer]." Format the reply per [RFC-0001](/rfc/0001-reference-formatting.md) — the **Reference formatting & readability** rules inlined at the end of this skill; they apply to the text inside the `reply` string value, not the JSON envelope. The reference kind that recurs here is the commit SHA: when the reply cites the commit that fixes the thread, render the SHA as a markdown link `[](/)` built from `REPO` — never a bare or backticked SHA. Because replies post as GitHub comments, every other reference resolves only as an absolute link built from `REPO`: render any `CHECK-` rule code as a `RULES_DOC_URL` link exactly as the [`pr-review` skill's §2.5](../pr-review/SKILL.md#25-rule-codes) does, and link any file, doc, skill, agent, or section you cite as a `/path#anchor` URL — never a bare name or a repo-relative path (relative paths do not resolve in a comment). Before returning the reply, self-check it: a bare 7–40-char hex token or a bare tracker id (`[A-Z][A-Z0-9]*-[0-9]+`) is a violation — link it per the rules above. ### Thread Resolution Add to `resolveComments` when: - The bot's finding was incorrect - The user has addressed/will address the issue - The user provided valid justification Do NOT resolve when: - The finding is still valid despite user's response - The user only asked a question (not a correction) ### Verdict Update **PR-level resolution language** is prose asserting the PR's blocking verdict is lifted or the PR is now approvable — e.g. "resolved", "this is addressed", "looks resolved", "good to go", "approved". It is distinct from thread-level resolution (`resolveComments`), which only marks one specific finding handled. PR-level resolution language is allowed ONLY when this pass emits `updatedVerdict: "approve"`. **Invariant:** the reply and the verdict must never diverge — the bot must not use PR-level resolution language while leaving a blocking verdict in place (issue #275). **Gate:** Only perform the verdict pass when `NEEDS_REVERDICT` is `true`. When it is `false`, set `updatedVerdict: null` and `updatedReviewComment: null` and do NOT scan threads or re-review. The reply may still acknowledge the specific fix, and you may add the discussed finding to `resolveComments`, but it MUST NOT use PR-level resolution language — phrase it as state, not a promise: "Noted — the blocking verdict stands until a re-review confirms the fix." A genuine verdict change still lands on the next review run (a push) or when the author explicitly asks for a re-review. When `NEEDS_REVERDICT` is `true`, decide from the LIVE unresolved bot-thread state — not the author's claim — by checking ALL remaining unresolved bot threads (not just the one being discussed): - If ALL 🚧 blockers are now resolved/retracted → `updatedVerdict: "approve"` (PR-level resolution language is now permitted in the reply) - If this creates a NEW blocker → `updatedVerdict: "requestChanges"` - Otherwise → `updatedVerdict: null` (no change); the reply MUST NOT claim PR-level resolution ### Review Body Update Only provide `updatedReviewComment` if `updatedVerdict` is non-null. Follow the same format as the original review body (see the pr-review skill for format rules) — including `CHECK-` rule codes rendered exactly per the [`pr-review` skill's §2.5](../pr-review/SKILL.md#25-rule-codes). Do not read agent files. --- ## Output Format ```json { "reply": "Concise response to the user's comment", "resolveComments": [ {"path": "src/file.ts", "line": 42} ], "updatedVerdict": "approve" | "requestChanges" | "comment" | null, "updatedReviewComment": "Updated review body or null" } ``` ### Rules - `reply` is REQUIRED and must be non-empty - `resolveComments` defaults to empty array - `updatedVerdict` defaults to null (no change) - `updatedReviewComment` must be provided when `updatedVerdict` is non-null - `updatedReviewComment` must be null when `updatedVerdict` is null ### Include - Direct, confident language - References to specific code when relevant - Acknowledgment when the bot was wrong ### Exclude - Defensive language or excuses - Lengthy explanations when a short one suffices - Repeating the user's comment back to them - Code examples or implementation suggestions ## Reference formatting Before writing any output that mentions a file, standard, section, commit, or issue, read [`reference-formatting.md`](../shared-rules/references/reference-formatting.md) (RFC-0001) and apply it verbatim — link files, docs, skills, agents, and sections, and never leave a reference as bare text.