120 lines
4.7 KiB
Markdown
120 lines
4.7 KiB
Markdown
---
|
|
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.
|
|
|
|
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 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 "$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 "$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 -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 -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.
|