---
name: address-review
description: Fetch the code-review comments left in this playpen tab's review pane, address each one (edit code + post an inline reply), and resolve the thread. Use when the user says "address the review", "check the review", "any review comments?", or runs /address-review.
---

# Address the review in this tab

Playpen serves a GitHub-style review UI for the repository the current tab is
working in. The user leaves line-level comments in the review pane and clicks
**Submit review**; this skill pulls those comments, addresses them in code, and
replies inline so the responses appear live in the pane — no copy-pasting from
the terminal.

## 1. Find the review

Every terminal pane in playpen is handed its own tab's review endpoint:

```bash
BASE="$PLAYPEN_REVIEW_URL"      # e.g. http://127.0.0.1:8420/t/tab3
```

That variable is the whole of the addressing. It names **this tab's** review, so
there is no repository to pass and no way to address comments meant for another
worktree.

Give every call a deadline — `--max-time 30`. The server runs `git` for some of
these, and a repository being built in another pane can make that slow; a curl
with no deadline turns that into a tool timeout that says nothing about what
went wrong. If one does trip, say so and try once more rather than treating it
as a missing review: the answer was late, not absent.

If it is empty — you are running outside playpen, or in a shell started before
the server came up — discover it instead:

```bash
curl -s --max-time 30 http://127.0.0.1:8420/api/tabs
```

That lists every tab with the `path` it is reviewing. Match `path` against
`git rev-parse --show-toplevel` and build the URL as
`http://127.0.0.1:8420/t/<id>`. Do **not** guess: reviewing the wrong tab means
addressing another branch's comments. If nothing matches, or the connection is
refused, tell the user to open a review pane in this tab (**Ctrl+Shift+D**) and
stop.

Confirm the review is open:

```bash
curl -s --max-time 30 "$BASE/api/repo"
```

- `{"open":true,…}` — good, go on.
- `{"open":false}` or a 409 — this tab has no review pane. Ask the user to open
  one and stop.

## 2. Fetch the pending comments

```bash
curl -s --max-time 30 "$BASE/api/review/pending"
```

Returns this review's submitted, unresolved comments. Each has:

- `id` — use this to reply and resolve
- `level` — how it's anchored:
  - `line` → `file` + `side` (`new`/`old`) + `line`..`endLine` (a line or range)
  - `file` → `file` only (a comment about the whole file)
  - `review` → not tied to anything (a comment about the overall change set)
- `file`, `side`, `line`, `endLine` — the anchor, per `level` above
- `body` — what the reviewer wants
- `author` — `user` for the reviewer's own comment, `claude` for one left by a
  review you ran yourself (the `leave-review` skill). Both are real work and both
  are addressed the same way; just say which is which in your summary. If the
  user asked specifically for *their* comments, filter to `author: "user"`.
- `replies` — any prior back-and-forth on the thread

Treat each level appropriately: for `line` address the specific lines or range;
for `file` consider the file as a whole; for `review` weigh it against the entire
change set.

If the array is empty, say there's nothing to address and stop.

## 3. Address each comment

For every pending comment, in order:

1. **Read the context.** Open `file` around `line` (on the given `side`) so you
   understand what the reviewer is pointing at.
2. **Decide the response type:**
   - **Change request** → make the edit with your normal file-editing tools.
   - **Question / discussion** → don't necessarily edit; answer in the reply.
   - **Unclear** → ask a clarifying question in the reply and leave the thread
     open (skip the resolve step).
3. **Post an inline reply** describing exactly what you did (or your answer):

   ```bash
   curl -s --max-time 30 -X POST "$BASE/api/comments/<id>/replies" \
     -H 'Content-Type: application/json' \
     -d '{"body":"Done — main() now logs and returns the error instead of printing.","author":"claude"}'
   ```

4. **Resolve the thread** once it's fully handled (skip if you asked a question):

   ```bash
   curl -s --max-time 30 -X POST "$BASE/api/comments/<id>/resolve"
   ```

Replies and resolutions appear in the review pane immediately over its live
connection.

## 4. Summarize

Report back: which comments you addressed and how, which you left open (and why),
and any code changes you made. Do **not** commit unless the user asks. If your
edits changed line numbers, mention that the reviewer may want to hit
**↻ Refresh diff** in the pane to re-anchor against the new code.

## Notes

- Keep replies concise and specific — they're read inside a comment thread.
- Comment ids are unique per review. A `404` from a reply or resolve usually
  means `$PLAYPEN_REVIEW_URL` points at a different tab than you think.
- Anchoring is by line number in the diff at comment time; after your edits the
  original line may have moved. That's expected — the reply plus resolve keeps
  each round coherent, and the user refreshes the diff for the next round.