---
name: respond-to-review
description: Address review feedback on your own merge request — resolve threads fixed by a commit, reply to threads you are not addressing
license: MIT
compatibility: opencode
metadata:
  provides:
    - respond-to-review
  requires:
    - source-control
    - tdd
    - push
    - verify
---

1. **Fetch all open review threads** via your `source-control` capability. Note thread ID, file, line, comment body, author, resolved status.

2. **Plan a stance per thread** as a list — `fix`, `decline-with-reason`, or `defer-with-issue` — before any code changes.

3. **Verify the plan** via your `verify` capability: every thread has a stance, fix-stance has a test-first approach, decline-stance has a substantive reason. Apply findings.

4. **Work through every thread:**
   - **Fix:** follow strict red/green/refactor via `tdd`. Present a per-file summary (reviewer comment beside addressing diff) and wait for acknowledgement, then commit with a message referencing the feedback. Resolve the thread via `source-control` — no reply needed.
   - **Decline:** do NOT resolve. Post an inline reply on the thread (not a top-level comment) via `source-control` using the thread's top comment ID, explaining why the code isn't changing.

5. **Push** via your `push` capability. The source control host ties thread resolution to the commit, so push before resolving or replying.

6. **Verify coverage.** Re-fetch threads; every one must be either resolved or have a reply from you. Never hand back with threads that have neither.

7. **Re-request review** from every reviewer who previously reviewed, via `source-control`.

**Rules:**

- Resolve silently when a commit fixes — no "fixed" reply.
- Reply without resolving when declining — never silently resolve a disagreement.
- Never resolve a thread you didn't fix.
- Show proposed replies to the user and wait for approval before posting.