playpen/.claude/skills/address-review/SKILL.md

name, description

name	description
address-review	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:

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:

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:

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

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):

   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):

   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.