Build in the review tool.
This commit is contained in:
Greyson Parrelli
@@ -0,0 +1,119 @@
|
||||
---
|
||||
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.
|
||||
Reference in New Issue
Block a user