# Resolve PR

Source: https://flow-next.dev/skills/resolve-pr/

Resolve PR review feedback - fetch threads, triage, dispatch resolver agents, reply + resolve via GraphQL.

`/flow-next:resolve-pr` coordinates resolution of unresolved GitHub PR review threads, top-level comments, and review-submission bodies.

The skill fetches the work, triages it, dispatches per-thread resolver agents (in parallel on Claude Code and Codex; serial on Copilot and Droid), then replies and resolves through GraphQL.

## Invocation

| Invocation                            | Behavior                                |
| ------------------------------------- | --------------------------------------- |
| `/flow-next:resolve-pr`               | Detect PR from the current branch.      |
| `/flow-next:resolve-pr <pr-number>`   | Full mode on that PR.                   |
| `/flow-next:resolve-pr <pr-url>`      | Same as PR number.                      |
| `/flow-next:resolve-pr <comment-url>` | Targeted mode - one thread only.        |
| `--dry-run`                           | Fetch and plan without making edits.    |
| `--no-cluster`                        | Skip cross-invocation cluster analysis. |

## Triage discipline

Threads are separated before any resolver agent runs:

* **New** - actionable threads with no prior reply.
* **Pending** - already replied; waiting on the reviewer.
* **Non-actionable** - review-wrapper boilerplate, approval-only LGTMs, CI summary comments.

Cluster analysis groups related threads when a prior resolved thread on the same surface gives signal - for example, three nits on the same function that the reviewer raised in different threads.

## Bounded fix-verify loop

A resolver gets up to two fix-verify cycles per thread before escalation. If a third cycle is needed on a recurring theme, the skill stops and surfaces a pattern summary instead of looping further. The user decides whether to keep going or rethink at the architecture level.

This bound exists because the third cycle is almost never a small fix; it is usually a hint that the spec needs revisiting.

## Safety

* Never executes shell from comment bodies. Reviewer text is untrusted.
* Stages only files the resolver agent explicitly reports. No `git add -A`.
* Never resolves a thread marked `needs-human`.
* The same safety rules apply in `--dry-run`; only the write phase is suppressed.

## Verdict spectrum

Each resolver returns one verdict per thread, routed differently in the reply + resolve step:

| Verdict             | Reply                                 | Resolve           |
| ------------------- | ------------------------------------- | ----------------- |
| `fixed`             | Cite the fix and commits.             | Yes.              |
| `fixed-differently` | Explain the chosen approach.          | Yes.              |
| `replied`           | Answer the question or push back.     | Reviewer decides. |
| `not-addressing`    | Explain the deferral or disagreement. | No.               |
| `needs-human`       | Surface to the user.                  | No.               |

## Worked example

```plaintext
/flow-next:resolve-pr
```

```text
PR #214 detected from branch. Unresolved threads: 3
Triage: 2 actionable, 1 decline-with-reason (style preference contradicting repo convention)
Dispatching per-thread resolvers... 2 fixes committed (f7c8d9e)
Replies posted + threads resolved via GraphQL.
RESOLVE_PR_VERDICT=RESOLVED threads=3 fixed=2 needs_human=0
```

Each thread gets an isolated resolver; replies cite the fix commit and file, and threads resolve only after the fix lands.

* Declining is a first-class outcome - a reasoned reply-and-resolve beats a reluctant fix that fights the codebase.
* The loop is bounded (2 fix-verify cycles) before escalation; a thread that survives both cycles genuinely needs you.
* Run it once per review wave rather than per comment - the combined-state validation catches fixes that contradict each other.

## Dynamic usage

Recipes that compose with resolve-pr in the [cookbook](https://flow-next.dev/guides/cookbook/):

* [Autonomy dial](https://flow-next.dev/guides/cookbook/#autonomy-dial) - [land](https://flow-next.dev/autonomy/land/) dispatches resolve-pr automatically on the pull request you named, before it looks at CI.
* [Team patterns](https://flow-next.dev/guides/cookbook/#team-patterns) - human reviewers comment, the pipeline resolves, the thread record stays honest.

## Next step

After the loop closes, push and re-request review. If the same theme returns, run `/flow-next:plan-review` on the underlying spec instead of looping resolvers.