# Review Pr > Review a Lunatik pull request end to end. Use when asked to review a PR or prepare review feedback. - Skill: `luainkernel/review-pr` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add luainkernel/review-pr` - Raw SKILL.md: https://api.skillmd.com/api/skills/luainkernel/review-pr/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: luainkernel (https://skillmd.com/u/luainkernel) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/luainkernel/review-pr --- The process is AGENTS.md, "Reviewing a pull request" — before the verdict, findings, fixups, comments, after a round. Follow it whole; this card is only the GitHub mechanics. # Reading and driving the branch - `git fetch origin pull//head:review/` brings the author's head; check it out in a worktree of its own (`git worktree add /w review/`, then `git submodule update --init`), since a worktree named for a task may be another session's; build and run it with the lunatik-cycle skill. - Read the pull request through the REST API, which needs no `read:org` scope: `gh api repos/luainkernel/lunatik/pulls/` for the PR, `gh api repos/.../issues//comments` and `gh api repos/.../pulls//comments` for the conversation, `gh api -X PATCH repos/.../pulls/ -f title=... -F body=@file` to edit. # Before the verdict - Write the matrix the change is held to: for each guard or mechanism it adds, the operations by types by outcomes, and read the tests against it, cell by cell. A test set taken as given because it came with the branch, or with the branch a rewrite replaces, is the review not done. # Reviewing as an agent that can die A review that lives only in one agent's context is lost the moment the provider drops that agent, and a long one is dropped often enough to plan for it. Three rules, and `review.js` beside this card is the workflow that follows them (`Workflow({scriptPath: '.agents/skills/review-pr/review.js', args})`): - Findings go to a checkpoint file as they close, one line each (`file:line | what | disposition`), not to the final message; the message is assembled from the file, and a successor reads the file first and continues from it instead of reading the branch again. - A review is phases, not one agent: hunt the findings, check the rules and the harness, then build and run. Each phase returns a `schema`, so a crash loses one phase and the cache replays the ones that completed under `resumeFromRunId`. - A head the suite already passed is not built again by the review: the totals and the core srcversion go in the briefing (`args.validated`), and the build phase runs only when a fixup changed the code. # Posting the review (only when asked; placement is decided BEFORE posting) Each finding goes inline on its line; the review body is only the verdict, opening with the author's @handle (AGENTS.md, "Comments and the verdict"). `tools/checks/review-post-guard.sh` refuses a post that lacks `REVIEW_POST_OK=1`: show the exact text, get the OK, then prefix the marker to the command. - Review with inline comments in one shot: `gh api -X POST repos/.../pulls//reviews -f commit_id= -f event=REQUEST_CHANGES -f body=@` with a JSON `comments` array (`path`, `line`, `side: "RIGHT"`, `body`) — build the payload with `--input file.json`. - A single inline comment after the fact: `gh api -X POST repos/.../pulls//comments -f commit_id= -f path=... -F line=... -f side=RIGHT -F body=@file`. - Fix a submitted review's body: `gh api -X PUT repos/.../pulls//reviews/ -F body=@file`. - A submitted review cannot be deleted, only dismissed. Getting the placement wrong means editing the body down to the verdict and re-posting each finding inline — rework, not repair. - Once the review is posted, label the pull request as read end to end: `gh api -X POST repos/.../issues//labels -f 'labels[]=workflow-reviewed'`; `tools/pr-status.sh` reads that label as the sign that someone read it.