# Speckit Resolve Pr > Address actionable review feedback on a pull request, push the fixes, and resolve review threads. Reads the PR comments, updates the code, runs project verification, replies to review threads, and reports what changed. - Skill: `racecraft-lab/speckit-resolve-pr-2` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add racecraft-lab/speckit-resolve-pr-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/racecraft-lab/speckit-resolve-pr-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: racecraft-lab (https://skillmd.com/u/racecraft-lab) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/racecraft-lab/speckit-resolve-pr-2 --- # SpecKit Resolve PR ## Capability discovery & grounding Before researching or recommending, enumerate the tools and skills your session actually exposes — do not assume a fixed set; the user may have installed anything — and select the best fit per `speckit-pro/skills/speckit-autopilot/references/capability-discovery.md`. Ground every external fact you assert in a real tool, skill, or file result per `speckit-pro/skills/speckit-autopilot/references/grounding.md`, and abstain when nothing grounds it. ## Scope Use this skill when the user wants review feedback addressed on an existing pull request. The goal is not a general code review. The goal is to read the unresolved review feedback, make the necessary code changes, verify the branch, reply to the review comments, and resolve the threads. If the user wants a fresh review of a PR, use a review workflow instead. If they want to learn how the post-PR loop works, redirect to `$speckit-coach`. This skill is for remediation and closure. ## Input Accept either: - a pull request number - a pull request URL - a review-comment URL anchored to a specific PR review If only a PR number is supplied, derive the repository from `git remote -v`. Never assume the remote is named `origin`; inspect the actual remotes first. ## Preconditions Before editing anything: - ensure the current checkout is on the PR branch or switch to it safely, and verify the actual code behavior in that checkout; never review or remediate from the diff alone - confirm `gh` is available and authenticated if thread resolution is required - inspect the repo state with `git status` so you know whether unrelated user changes are already present Do not overwrite unrelated dirty worktree changes. If the current checkout cannot safely host the remediation, create or switch to the correct branch without discarding existing work. ## Discover Project Verification Commands Read the project guidance files and package manifests to determine the real verification commands. For JavaScript or TypeScript projects, detect the package manager from the lockfile before running anything. Capture, when available: - build - typecheck - lint - lint-fix - unit tests - integration tests Run the narrowest relevant checks while fixing each comment, then run the full required verification before finishing. ## Gather Review Feedback Use the best available source for unresolved review feedback: - prefer GitHub connector tooling for PR metadata and flat comment reads when available - use `gh api` GraphQL when you need thread IDs, resolution status, or reply context The important data for each unresolved thread is: - thread ID - file path - line number or diff context - comment body - original reviewer If there are no unresolved threads, report that clearly and stop. ## Process Threads — Partition by File, Parallel Across Files **Partition the unresolved threads by file path first**, then dispatch parallel-per-partition. Within a partition (same file), process serially — concurrent `apply_patch` calls to the same file race. Across partitions (different files), spawn one `spawn_agent` per partition in ONE tool turn, then `wait_agent` on all handles. Before partitioning, scan each thread's comment body for cross-file hints (e.g., "rename and update all callers", references to other paths). Cross-file threads are NOT partitioned — they are processed serially in the lead session after parallel partitions return. For each partition: 1. `spawn_agent` (background) a worker that addresses ALL threads on that file in order: - Read the referenced file and surrounding code - Make the smallest correct fix per thread; reply-only for questions - Run the targeted tests / typecheck / lint-fix - Commit all fixes for that file in one intentional commit - Return: thread IDs handled, per-thread action taken, commit SHA, verification result, per-thread reply text - Do NOT push, post replies, or resolve threads — the lead handles those serially after all partitions return 2. Use `general-purpose` (or `phase-executor` as fallback) as the worker agent type. Use Sonnet for the worker — focused execution. After all `wait_agent` calls return, process `CROSS_FILE` threads serially in the lead session. When a reviewer is simply asking a question and the existing code is correct, do not churn the code just to make the thread go away. Reply with a grounded explanation instead. ## Verification Standard Do not resolve a thread until the relevant code path has been verified. At minimum: - run typecheck and the unit tests locally before posting any review comment or reply - run the targeted tests or checks needed for the fix - ensure the broader project verification required by the repo still passes - scope every finding to files the PR changed unless the user explicitly asks for a broader review If verification fails, keep working until you either fix it or can clearly explain why the repo was already failing independently. Never reply “fixed” on a thread while the branch is still broken. ## Commit Strategy Group related review fixes into intentional commits. Avoid one commit per comment if several comments are part of the same issue. Use clear commit messages. Then finish in one pass: run the full project verification, push the branch, and confirm with `git status -sb` that the branch line does not read `ahead`. Do not report completion until that confirmation is in hand. Use the package manager the lockfile names for every command. Do not amend or rewrite history unless the user explicitly asks for it. If the repo already has unrelated local changes, work around them rather than reverting them. ## Reply and Resolve After a thread is addressed: - reply with what changed, or with the rationale for no code change - post a new finding of your own inline through `gh api` on the exact diff `path`, `line`, `side`, and `commit_id`, not as a summary comment - resolve the review thread using the real thread ID, not just the comment ID If GitHub tooling is unavailable, stop after making and verifying the fix and tell the user that thread resolution could not be completed from the current environment. ## Reporting Finish with a concise summary that includes: - PR identifier - number of threads processed - whether fixes were code changes, replies only, or both - verification commands run - whether the push was confirmed (`git status -sb` with no `ahead`) - whether all unresolved threads were resolved If anything remains open, list the blocker explicitly: missing auth, failing verification, ambiguous feedback, or a thread that needs a human decision. ## Boundaries Stay within files touched by the PR unless a review comment forces a broader change. Do not turn a review-remediation task into a drive-by refactor. The goal is to satisfy the actionable review feedback and leave the branch in a mergeable state.