## TL;DR
Address the feedback, push the fixes, and get the reviewer to re-review - only a new approving review (or a dismissal by someone with permission) clears the block. Replying in comments alone doesn't clear it, and pushing code doesn't auto-clear it either.

## The error
```text
"changes requested must be addressed before merging" error
```

## Steps to fix
1. Read the requesting reviewer's comments and make the code changes they asked for.
   - Expected: every piece of feedback has a corresponding change or a written reason it doesn't apply.
2. Push the fixes to the PR branch.
   - Expected: the PR timeline shows the new commits.
3. Re-request the reviewer's review (or ask them to take another look) so they can approve the new head.
   - Expected: the reviewer is notified; nothing auto-notifies them that you pushed.
4. Wait for their approving review.
   - Expected: the block clears when the approval lands; a dismissal by someone with permission clears it too.

## Use this when
- The merge box says changes were requested and must be addressed.
- A reviewer left a "request changes" review and the PR is otherwise ready.
- You pushed fixes but the block is still there (the re-review hasn't happened).

## Not for this skill when
- The blocker is missing reviews rather than requested changes (get a first review instead).
- The blocker is a failing check (fix the check).
- The team norm is that anyone's approval unblocks (check branch protection - "request changes" is still a veto there by default).

## Variant phrasings
- changes requested must be addressed before merging
- PR blocked changes requested github
- how to clear request changes review
- requested changes blocking merge

## Why it happens
A "request changes" review is a persistent veto in branch protection: it stays blocking until that reviewer (or someone with dismiss permission) resolves it. Pushing code doesn't auto-clear it because GitHub can't tell whether the push addressed the feedback - only the reviewer can judge that, so the veto waits for their verdict.

## Edge cases
- The reviewer is unavailable: someone with dismiss-review permission can dismiss the stale request.
- Stale-dismissal settings may auto-dismiss the request on push - then you just need any fresh approval.
- Multiple reviewers requested changes: each requester must resolve; one approval doesn't override another's veto.
- If you disagree with the feedback, say so in the thread and ask for dismissal rather than pushing changes you don't believe in.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_fjbBTaasyJGj0KQ2Iv9E6Q